Mobilizing SQL Injection Attacks: Same Pig, New Lipstick?

Supply Channel Coordination

In-brief: New research from Akamai suggests that attackers are using new methods to carry out and cover up for malicious attacks, among them: harnessing harmless mobile carrier networks to carry out attacks such as SQL injection. 

In the past years we have seen an increase in distributed attacks against web applications. By using many attacking resources to target the same destination, attackers are obscuring their identity while boosting attack bandwidth, placing a greater challenge to defensive forces. Most of the distributed attacks use “volumetric” methods such as Distributed Denial of Service (DDoS) or brute force techniques such as “slow and low” to attack web applications.

The most prevalent way to execute these kinds of distributed attacks is by using a remote attacker who controls botnet members or re-routing traffic through open proxies. In both cases the attacker is trying to hide the origin of the attack against the targeted application from the intended victims.

Or Katz, Akamai
Katz is a principal security researcher for Akamai’s Cloud Security Intelligence platform.

 

But recently Akamai’s Threat Research Team uncovered a distributed attack campaign that differs from the common distributed attack model described above in two important aspects.

Specifically: this attack relied on non-volumetric, targeted SQL injection attacks against target applications. Second: the attackers executed their attack from within a mobile carrier network, abusing native functionalities to hide their origin.

The Target

The target of the attack campaign was a vulnerable government-owned and operated web application running on top of Joomla platform. The application was linked to tourism. The attack caught the attention of our researchers first through the execution of a SQL injection attack over 3 hours that comprised 1500 SQL injection payloads, sent from nearly 150 different IP addresses.

 

[Read more Security Ledger columns by Or Katz here.]

Connecting the Dots

Typically, when analyzing an attack campaign, our first step is to analyze the activity for each of the attacking source separately. In this case, however, that approach led us to the wrong conclusion, which was that these were low impact attacking sources sending few, unrelated SQL injection attacks to the target application. Only when we were able to correlate the attacking sources and uncover the relationship between those attacking sources were we able to get new insights on the threat that allowed us to identify its true nature: a high impact SQL injection attack, targeting specific functionalities within the application.

When Many Are Considered as One

How are we able to do that? It is not a trivial task to classify many attacking sources into a single attacker. However, in the campaign presented above we had a few things going for us and used a few methods that helped us correlate between the attacking sources:

  1. Common HTTP headers: In our analysis we were able to see a unique and common User-Agent header value that was used by 143 IP Addresses. This information indicated on the existence of a single attacker running the same SQL injection-scanning tool while distributing his attacks across several mobile carrier networks.
  2. SQL injection attack payloads: An attacker that executes a SQL injection attack without having any knowledge of the targeted database schema would have to inject many SQL queries that contain an evolving SQL injection payload. For example, in order to know the exact amount of database columns, the attacker will use column enumeration technique. When using a column enumeration technique the attacker will get a successful server response once he will send a query with the right amount of columns. Typically the payloads would be sent in succession from the same single IP address.
  3. Source IP GEO location: When looking at the geographical information of the attacking sources we can see that most of them are coming from China.
Attacking IP addresses mapped, globally. China was the leading source of malicious traffic. Image courtesy of Akamai.
Attacking IP addresses mapped, globally. China was the leading source of malicious traffic. Image courtesy of Akamai.

The Mobile Era

Once we found the link between all those attacking sources, something else caught our eye: most of these IP addresses belonged to Chinese mobile carrier networks.

Why mobile carriers? We suspect that the reason for that lays in the ability of mobile carrier networks to enable both resilient and obfuscated attacks. After all, each mobile carrier IP Address is shared among many users connected to the same wireless network. Protecting against attacks initiated from shared networks is much more challenging. It requires enhanced selective detection capabilities that give the ability to differ between “good” and “bad” traffic initiated from the same IP Address.

Also, mobile carrier networks allocate dynamic IP addresses which can frequently change based on user location. This is boon to malicious actors. Defending against rapidly changing sources of attack is challenging. Attack sources are classified as malicious based on on-going malicious activity, but a change in the attack source will require re-initiating the classification process.

Finding the Hole in the Wall

The final step in the analysis is to try to find the attacker’s objective; finding the targeted web application resource (i.e. – URL, cookie) can result with discovering hidden vulnerabilities in the application being exploited in the wild. In this attack campaign, two pieces of evidence led us to identifying the vulnerable application and understanding how it is vulnerable:

First, the same URL in the targeted Joomla application was heavily targeted by the SQL injection attack. That suggested to us that the attack was not just probing for a possible vulnerability, but focusing on penetrating an existing vulnerability known to the attackers.

Second, when we looked at the application response, we saw evidence of information leaks including suspect SQL queries. In many cases web applications mistakenly output SQL queries as part of error handling. The detection of requests that included SQL injection attack payloads followed by web application responses that contained error leakage gave us confidence that a SQL injection vulnerability was being used to harvest information from the vulnerable application.

Conclusion

Even though we have a comprehensive view on the attack campaign there are still some questions left unanswered. Among them:

  • What method did the attackers use to abuse those mobile carrier networks?
  • Did the attackers use several pre-paid SIM cards while roaming across different locations?
  • Did the attackers use infected mobile devices as Botnet members?
  • Which organization, state or individual is standing behind this campaign?

Or Katz is a principal security researcher for Akamai’s Cloud Security Intelligence platform.