Injection vulnerabilities can exist in languages that intermingle commands and data. For example, the most famous type of injection vulnerability is SQL injection, which takes advantage of the fact that database queries in a web application commonly include user-provided data.

For example, an SQL query for looking up a user record might be SELECT * FROM users WHERE username=’<username>’, where <username> is a value provided by the user on a login page. If the user entered the username Bob’ OR ‘1’=’1, the command would be changed to SELECT * FROM users WHERE username=’B’ OR ‘1’=’1’. Since ‘1’ always equals ‘1’, this query would return the records of every user in the database.

While SQL injection is the most famous type of injection vulnerability, it is far from the only one. Other common examples include command, NoSQL, Lightweight Directory Access Protocol (LDAP), Object Relational Mapping (ORM), and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection.

What is the Risk?

The risk associated with injection vulnerabilities depends on the vulnerable code and the role that it performs within the application. For example, SQL injection vulnerabilities are commonly used to access sensitive data stored within an SQL database. However, they can also potentially be exploited to modify that data or delete it entirely.

OS command injection attacks take advantage of the fact that a web application may execute code within the system terminal via eval() or similar functions. In this case, an attacker who exploits the vulnerability can run their own commands on the webserver, potentially accessing sensitive data, deploying malicious code on it, or using it as a stepping stone to access and infect the rest of the network.

Examples of Attack Scenarios

The mechanics of exploiting an injection vulnerability depend on the language and query in question. However, they generally involve an attacker crafting malicious input that causes some of the user-provided input to be interpreted as a command.

This is what happened in the SQL example from earlier in this article. For an OS command injection example, consider a command designed to print the content of a user-specified file with the command cat filename.

One way to exploit this vulnerability would be to perform directory traversal to print the contents of files that the web application didn’t intend to reveal. For example, a user-provided filename of ../../../etc/shadow might print the usernames and password hashes of the various accounts on the system. This is possible because each ../ in the filename moves up one level in the directory structure.

Another option would be to terminate the existing command and run another of the attacker’s choosing. For example, a filename of test.txt; pwd would change the command to cat test.txt; netstat. Since a Linux terminal allows multiple commands on the same line separated by semicolons, this would print the contents of the file followed by information on the webserver’s current network connections.

Case Study: MOVEit

In 2023, a zero-day SQL injection vulnerability was discovered in the MOVEit Transfer and MOVEit Cloud file transfer solutions. The SQL injection vulnerability was first exploited by the CL0p ransomware group on May 27th, and Progress Software released a patch for it on May 31st. 

This vulnerability had wide-reaching effects since the attackers could exploit it to access highly sensitive data being transferred using the file transfer tool. Additionally, the vulnerability enabled the attackers to install the LEMURLOOT web shell, providing persistent access to compromised web servers. This custom web shell was designed to make it easier for the attackers to download sensitive data being transferred via the compromised application.

How to Remediate Injection Vulnerabilities

Injection attacks use malicious and malformed user input to change the functionality of a query or command. Some methods of remediating these vulnerabilities include:

• Parameterized Queries: Parameterized queries provide user input as a parameter to a query rather than concatenating it into the query string. This approach protects against portions of the user input being interpreted as part of the query or command.
• Input Sanitization: Input sanitization blocks potentially dangerous characters from being included within user-provided input. For example, sanitization of SQL queries may include blocking single and double quotes, which are commonly used to delineate data vs commands in an SQL query.
• Input Validation: Input validation verifies that user-provided input meets expectations before including it in a query. For example, an SQL query may use a regular expression to verify that user input is a valid name, username, or email address.
• Escaped Characters: If special characters must be permitted in user-provided input, they should be escaped within a query. For example, this might indicate that a quotation mark is part of a username rather than the end of the username field within an SQL query.
• Language-Specific Controls: Some languages vulnerable to injection have controls that can be used to mitigate the risk. For example, LIMIT statements in SQL queries can restrict the number of records revealed. For OS command injection, limiting the access and privileges assigned to the web application reduces the damage that a malicious terminal command can do.

How IONIX Can Help

Injection vulnerabilities and other security risks listed in the OWASP Top 10 are some of the most common vulnerabilities in web applications. Identifying and remediating these vulnerabilities in a web application eliminates many of the top attack vectors that a cybercriminal will target.

IONIX helps organizations manage their risk exposure by proactively simulating attacks against OWASP vulnerabilities as part of a risk assessment. To learn more about how the IONIX platform can help your organization reduce its exposure to cyberattacks, sign up for a free demo.