Structured Query Language or SQL is a programming language designed for creating, manipulating, and processing information stored in a relational database. These are made up of tables where information is stored and accessed using rows and columns to represent different data attributes and relationships. These databases are ubiquitous; even though we, the users, may not interact with them directly they are used by virtually every modern application. If an application uses data, it needs a database, and most of those are SQL databases. The data stored can be anything from personally identifiable information to payment data to anything and everything an application collects and stores.
Consequently, SQL injection, the practice of injecting malicious SQL code into an application, has also become extremely prevalent. SQL injection is the primary source of web application vulnerabilities, reported to make up 23.4% of all critical web application vulnerabilities globally in 2023. Injection attacks, which includes SQL injection, was first on the OWASP Top 10 Web Application Security Risks prior to 2021 when it was moved down to third. The impact of a successful SQL injection attack can be disastrous for organizations and in many cases their consumers. Follow along to learn more about what this attack looks like, what to look out for, and how to protect your data from this type of attack.
What is SQL Injection?
SQL queries are crafted to insert, update, delete, and select data based on defined conditions. The classic example of illustrating SQL injection is a username and password being passed from an application login screen to a backend database. If the password matches what is stored in the database, the statement is true, and the user can login. Now let’s say an attacker wants to log in, but they don’t know the password. If the application is vulnerable to a SQL injection which allows the attacker to pass a statement which always returns true, such as “1=1”, then the attacker is allowed to log in without the password.
This is the classic example which illustrates the concept of SQL injection, but modern techniques are well past “1=1”. More sophisticated versions of the attack abuse things like tracking cookies which might make some subtle change in the response based on whether the cookie value is accurate or not. This essentially allows an attack to issue true/false statements to the database which can be used to infer or request information about the data stored in the database such as “the first character of the administrator’s password is the letter a”. This type of request, carried out enough times, will allow the attacker to derive the administrator’s password. This technique is known as blind Boolean-based SQL injection.
There are numerous other techniques that make up this class of injection, but they all generally follow the same formula: escape the original request, append some type of SQL query, and close with a comment to prevent the server reading the rest of the original query. In practice, this looks something like:
SELECT * FROM users WHERE username = 'administrator' AND password = ''OR 1=1#'
where the single quote (‘) escapes the input field and the octothorpe (#) designates the start of a comment. The specific syntax and characters used depends on the version of SQL being used but this is one very simple payload that attempts to execute a first-order SQL injection that returns true for whatever the original request is.
First-order SQL injection occurs as the result of the application processing user-supplied input directly from an HTTP request. Second-order SQL injections, however, occur when that user-supplied input is stored for future use and later retrieved, usually as the result of the attacker taking some later action. This type of attack usually occurs when data retrieved from a database is deemed trusted and handled unsafely. Take for instance this example from PortSwigger, the makers of the security tool Burp Suite:
In this example, an attacker can inject an SQL statement into their username that changes the database administrator’s password. Later, the database requests the username as part of another query which executes the malicious code. Now that we’ve seen a few examples, let’s look at some recent threat actor activity involving real-world SQL injection.
GambleForce
The group GambleForce, so named due to their focus in targeting the gambling industry, was first discovered in September of 2023. The attackers could be Chinese as the identified version of Cobalt Strike used on the group’s server used Chinese commands, however no other information is known regarding their geographical location. This threat actor is most notably associated with a string of SQL injection attacks carried out against companies in the Asia-Pacific region. GambleForce uses a set of publicly available penetration testing tools configured with near-default settings. This tactic is basic but delivers remarkable results as these tools are easy to use and highly effective. Among these tools is a well-known open-source project named sqlmap.
Remember Low Orbit Ion Cannon (LOIC), the network stress-testing tool used by Anonymous to carry out DDOS attacks against various companies in 2010? The tool is extremely user-friendly and as a result many individuals opted to participate in these DDOS attacks because all they needed to do was point and fire. Well, sqlmap isn’t quite that easy to use, but it isn’t too far off either.
Sqlmap automates the process of detecting and exploiting SQL injection vulnerabilities. An inexperienced attack can quite easily pass a URL with a vulnerable parameter to sqlmap, follow the prompts on the screen, and perform a successful SQL injection. The tool even includes a feature which dumps and stores the database contents into a local database if the attack is successful. This is barely scratching the surface of the features offered by sqlmap, and you can see why it serves a valuable purpose in the field of web-application penetration testing. Unfortunately, you can also imagine the dangers of such a powerful tool in the wrong hands.
In addition to sqlmap, the gang’s toolkit also includes dirsearch, tinyproxy, redis-rogue-getshell, and the aforementioned Cobalt Strike. They were also detected attempting to exploit a vulnerability in Joomla! CMS, CVE-2023-23752, which allows unauthorized access to webservice endpoints. The exploit was successful, but this incident did not result in data exfiltration.
GambleForce Indicators of Compromise:
| Domains | Dns-supports[.]online, Windows.updates[.]wiki |
| IP | 212.60.5[.]129, 38.54.40[.]156 |
ResumeLooters
Another group recently active in the Asia-Pacific region is ResumeLooters. ResumeLooters focuses primarily on employment agencies and retail shops, using SQL injection and Cross-Site Scripting (XSS) as their initial intrusion vector. The group has been credited with the theft of over 2 million user records, compromising as many as 65 websites between November 2023 and December 2023 according to Group-IB security researchers.
Similar to GambleForce, ResumeLooters also leverages sqlmap to carry out SQL injections against its targets. The group also uses other open-source tools enumeration such as diresearch, X-ray, ARL, acutenix, Metasploit, and BeEF to enumerate targets and find vulnerabilities. The tool X-Ray is notable in that it is a Chinese tool, which may hint to the group’s origin. After identifying weaknesses in the target website, the attackers will carry out XSS attacks by injecting malicious scripts into the webpage HTML. If successful, the malicious script will execute and generate a phishing form in the victim’s browser prompting them for personal information.
ResumeLooters Indicators of Compromise:
| Domains | Recruit.iimjobs[.]asia, recruiter.foundit[.]asia, admin.cloudnetsofe[.]com, 8t[.]ae, 9gp[.]cc, sb8[.]co, qu3[.]cc, 8r[.]ae, 3×1[.]me, 7o[.]ae |
| IP | 139.180.137[.]107, 139.84.168[.]189, 139.84.130[.]232, 139.84.62[.]151, 173.199.122[.]65 |
Mitigations
SQL injection vulnerabilities are the result of an application not properly validating user-supplied input. A flawed design allows attackers to pass malicious code to a database through things like login fields, vulnerable URL parameters, and even analytics tokens. OWASP advises two broad solutions for preventing SQL injections: stop writing dynamic queries using string concatenation or prevent the malicious SQL input from being included in executed queries. The following techniques describe how to prevent SQL injection and can be implemented across different programming languages and databases.
Parameterized queries, sometimes called prepared statements, are different from dynamic queries in that they define the SQL statement first and pass the parameter later. This means that developers control what input is passed to the SQL statement, not users. If implemented correctly, the database will always distinguish between code and data, and an attacker cannot change the intent of a query.
Another option for preventing SQL injection flaws is safe stored procedures. In this implementation, the SQL statements are predefined, like prepared statements, and stored in the database. The procedure is then called by the application. Both this approach and parameterized queries are generally regarded as being very effective in preventing SQL injection, though be advised that implementing stored procedures in MS SQL can introduce new risks to the application and database.
Input validation or input sanitization is the practice of validating user input based on a set of prescribed rules. These rules can be things like rejecting or encoding certain special characters and strings or defining the expected format for something like a phone number. Input validation can be effective in blocking injection attacks; however, it should not be the primary method for doing so. Validating input is good practice but only as effective as its implementation. For example, a rule blocking the string “script” might allow “ScRiPt” to go through if it is not properly defined. Sounds simple, but this exact technique was used by the previously mentioned threat actor, ResumeLooters, in an XSS attack late last year.