Injection Attacks


Injection Attacks

Hey everyone to this new post on Injection attacks. We had already discussed the SQL Injection attack in one of our previous posts. Since SQL Injection was a big topic, we discussed it separately. Take a look at that post here. In this post, we are going to talk about the other well-known Injection Attacks.

But first thing’s first. What really is an Injection Attack?

Injection is at the top of the most critical web application vulnerabilities in the OWASP Top 10.
Let’s suppose you have an application and the data which someone enters passes through the interpreter. Now, if the attacker sends untrusted data to the interpreter to get some details out of it, it is what’s called an Injection Attack. It can be really critical if the attacker knows the target interpreter because then he/she just needs to do simple text-based attacks to exploit its syntax.

Possible Impacts on a company:

Injection attacks are the easiest to exploit actually. The major problem is that in Black box testing when you don’t have the source code, testing for Injection can be really painful. But it’s definitely not the case in Grey-box or white-box testing when the company provides you with the source code of the application.
But the important fact is that the consequences of a successful injection attack can be quite serious to the company. It can lead to the total system being compromised. All the data regarding your users, products, sales etc. can be stolen.

Different Injection Attacks:

Apart from SQL Injection, there are different kinds of Injection attacks available to the attacker. Let’s see some of them for more details:

    • OS Command Injection: In this attack, the attacker tries to execute OS commands to a web server. That basically means is that the attacker does some changes in the request send to the web server to execute an OS command. Any web interface in which the input has not been properly sanitized is vulnerable to this exploit.

      Just think for a second, if the server being used is Linux, then if the attacker can find a way to execute the command /etc/shadow or the /etc/passwd, he/she can get the encrypted password and thereby use the suitable algorithm to decrypt it. This can be quite a dangerous thing, right? If the attacker gets his hand on the admin’s password, then the whole web application will be doomed simply.

      Let’s say this is the URL of a certain page of a web application using PHP.

      http://salestarget.com/files.php?dir=12abc
      Now to check for command injection, try inserting ;cat /etc/shadow in URL encoded form. The URL will then look something like this

      http://salestarget.com/files.php?dir=%3Bcat%20/etc/shadow
      If the data is not being sanitized properly it will lead to the execution of the cat /etc/shadow command which will give the list of all the password hash files.

      Possible Remediation:
      The URL and form data needs to be sanitized for unwanted characters. It’s better to make a “whitelist” of the allowed characters to validate the user input.
      To read more about Command Injection, take a look at this page.

    • LDAP Injection:
      LDAP Injection is actually a server-side attack. LDAP is used to store information about hosts, users and many other objects inside the company.
      A successful LDAP Injection can lead to granting the rights to modify or remove anything inside the LDAP tree. Not only this, the attacker will be able to access unauthorized content.
      To see some practical test cases for LDAP Injection, have a look at this OWASP page.
    • XPATH Injection:
      Some attacks are only possible if the application is using XML data. XPATH injection is one of them.
      In this attack, the attacker first tries to know how the XML data has been structured. He/she will then try to access some sensitive data or try to escalate his/her privileges on the website.
      So what is XPATH?
      Let’ see how OWASP describes XPATH:

      XPath is a standard language; its notation/syntax is always implementation independent, which means the attack may be automated. There are no different dialects as it takes place in requests to the SQL databases.

      Because there is no level access control it’s possible to get the entire document. We won’t encounter any limitations as we may know from SQL injection attacks.

      That means it’s possible to get the entire data for users, sales etc. anything in the application through XPATH Injection attack.

      Possible Countermeasure:
      There are two ways to avoid XPATH injection:

      • Use a parameterized XPATH interface if one is available.
      • Escape the user input to make it safe to include a dynamically constructed query.

      To learn more about LDAP Injection practical case, check this page.

Now there are other types of Injection attacks also possible. It is not possible to discuss each kind of Injection attack in a single post. Since we want to keep this post to the point, we will be providing the links for you to go and explore that particular attack.

XML Injection
XXE Injection
ORM Injection
NoSQL Injection

It will be good if you read about all the above injection attacks from their associated links for testing purposes. Moreover, practising the different attacks from Webgoat and Mutillidae will make it easier for you to understand.

Final Points:

We just saw how critical Injection attacks can be to a company. Now there are some general guidelines which one should follow to have the first line of defense against this kind of attacks:

    • Avoid accessing external interpreters.
    • Validate the user-supplied input to ensure it doesn’t have any malicious intent.
    • Take a whitelist approach to list out all the terms and characters that one can supply as input. “Blacklisting” of certain terms will also be favorable. OS commands special characters should be blacklisted.

These are some of the basic measures to take against Injection Attacks. Of course, you need to learn more about what it is and then try out different defenses. For that take a look at this page.

So this is all for this post. We hope, this post will give you some starting point. We didn’t discuss all the test cases for each attack, else it would have become a boring post for you. That’s why we have included the different links and added the names of all the Injection Attacks I can remember as of now.
Do read them carefully because bug bounty companies also provide awesome bounties for successful exploitation of Injection Attacks. Hope this will give you more motivation.;)

In any case, if you think that you didn’t understand something in this post or something you are unclear about Injection Attacks, feel free to comment below and someone from ENCIPHERS will get back to you as soon as possible.

Till then Keep Learning and Happy Hacking 🙂

Blogger
I am the one who publishes all the blogs for ENCIPHERS :-)