Adversaries may attempt to take advantage of a weakness in an Internet-facing computer or program using software, data, or commands in order to cause unintended or unanticipated behavior. The weakness in the system can be a bug, a glitch, or a design vulnerability. These applications are often websites, but can include databases (like SQL), standard services (like SMB or SSH), network device administration and management protocols (like SNMP and Smart Install), and any other applications with Internet accessible open sockets, such as web servers and related services. Depending on the flaw being exploited this may include Exploitation for Defense Evasion.
If an application is hosted on cloud-based infrastructure, then exploiting it may lead to compromise of the underlying instance. This can allow an adversary a path to access the cloud APIs or to take advantage of weak identity and access management policies.
For websites and databases, the OWASP top 10 and CWE top 25 highlight the most common web-based vulnerabilities.
Detection Profile
Triggers
- An internal host sends requests to a Web server and embeds SQL fragments into HTTP Post data or the URL to gain access to the backend database; the requests appear machine generated due to the large volume and rate of arrival
Possible Root Causes
- An infected system that is part of targeted attack is looking for vulnerabilities in an internal Web app through which to access the database integrated into it, or is harvesting information for later exfiltration
- An IT-operated vulnerability scanner is scanning for Web app vulnerabilities
- A software application on the host uses the unsafe practice of passing passes SQL statements in HTTP Post data or in a URL
Business Impact
- Probing and potentially exploiting an internal Web application’s vulnerabilities can be a prelude to a targeted attack getting access to data and then exfiltrating it
- Application software that passes SQL statements in HTTP Post data or as part of a URL may be vulnerable to attackers as they can send very different input than the application writer expects
Steps to Verify
- Verify systems identified as the source of SQL injection attacks should be communicating directly with SQL servers; download the PCAP to see the entire HTTP Post data or the URL to determine if its behaving as expected
- If this pattern is coming from neither an IT-run vulnerability scanner nor from software that by design sends SQL statements in requests, check for presence of malware on the host
Example of an SQL Injection activity
For this example, we’re going to pivot from a detection, if you come across an SQL Injection Activity detection you can follow these steps to investigate further. First identify active SQL Injection Activity detections within the detect platform that are not triaged, navigate to Detections > Advanced Search and type the following query into the search field:
detection.detection_type:”SQL Injection Activity” AND detection.is_ triaged:false AND NOT detection.state:inactive
Pick one of the detections and review the details, note the source, target, the X-Forwarded-For header, port used and bytes received. If the bytes received is large it could indicate a successful SQL injection and database information was returned to the adversary, review the pcap to see what response data the requests were being met with. The response codes are not reliable here for SQL Injection, a server could respond to the clients request with an error code and yet still return valid data as the SQL statement was successful.
Next review the X-Forwarded For header IP, it’s likely your web server will be behind a proxy or load balancer and the source IP will not be the true source. With the X-Forwarded For header configured it will append the true public source as a header to the HTTP request allowing the Vectra AI-driven platform to parse this information and present it within the UI.
Pivot into Vectra Recall and under Discover > metadata_httpsessioninfo* search for the X-forwarded-For IP using the proxied field and review all requests from this source. Start with a small window of maybe 10 to 20 minutes and gradually expand out your search time. Review the user-agent, targeted uri and bytes sent/received. These fields can help identify if this activity was an automated tool and if any of the requests were successful.