Analyzing Defcon Traffic – NOP Detection

The DefCon network is called the most hostile network in the world. For this very reason the Defcon network spawns a unique opportunity for security researchers and analysts such as yours truly. While connected to the wall-of-sheep tap I observed approximately 7 minutes worth of network traffic. That small amount of traffic has provided me with some very interesting information to research. I will be conducting a series of blog posts offering insight into some of the traffic that I observed while connected to the DefCon network in order to help others determine what has occured in light of specific attacks or detection alerts. In this particular investigation we will simply look into one of the SNORT alerts that was observed.

In particular, the alert that stuck out was the ?SHELLCODE x86 inc ecx NOOP? alert. This particular alert stuck out because, well, shellcode is bad and a bunch of consecutive NOP’s (said NO-OP) is sometimes an indicator that shellcode might be traversing a network. Furthermore, the assessment of this particular alert is an excellent segway into a conversation about the effectiveness of IPS alerts. Unfortunately, you will find that in this particular investigation there was not enough information to make a determination of exactly what happenned in this event. However, following the process to that point does in fact give some insight into how to tackle IDS/IPS events involving non-perscriptive shellcode detection.

If you are not familiar with it, shellcode is basically special code written to give an attacker the necessary framework to perform different activities on an exploited machine. This type of code is particularly common in attacks that exploit buffers. Shellcode tends to be the code that is run in the space located outside of the specifically allocated buffer. When you hear about a vulnerability that ?allows for arbitrary code to be run? it typically is referring to an issue where shellcode could be run.

Before we begin, let’s look at the actual signature that is triggering

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:”SHELLCODE x86 inc ecx NOOP”; content:”AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA“; classtype:shellcode-detect; sid:1394; rev:10;)

See the issue with this alert? The issue is that this alert is focused on an exploit and not on a vulnerability. Actually it’s not even really focused on an exploit, it’s focused on an aspect of a possible exploit. This type of non-perscriptive exploit focused alert is a magnet for unneeded IPS alerts. The reason for this is because there is no indication if the attack was actually successful. In other words, the traffic could bounce around all day causing alerts without actually affecting anything. Furtheremore, the alert itself is not particularly prescriptive and there are a myriad of reasons why it would generate a false positive.

Regardless looking at the particular instances of the alert in question, I decided to take a little bit deeper of a dive one of the alerts. I decided that I would look at x.x.x.165 because it has several hits on the particular the “SHELLCODE x86 inc ecx NOOP” alert. The traffic came over port 110/TCP which leads lead me to my first thought which was, POP3? At DefCon???? This could be a false-positive or someone just messing around trying to send a fake POP3 password to the wall-of-sheep or trigger a whole bunch of High SNORT alerts (since the Wall of Sheep openly runs Sourcefire SNORT). For those not familiar, the Wall of Sheep is a team of people at DefCon that monitor traffic for usernames/passwords and other goodies such as sensitive cookies. Since POP3 is a cleartext protocol, it tends to be a no-no when the Wall of Sheep is monitoring the network.

In digging a little bit deeper one of the packets certainly looks a touch malicious, or at least you can tell why the alert triggered. A series of thirty one “0×41 ecx inc’s,” represented by the ASCII character “A” ,would have triggered an alert, the particular packet observed holds roughly 65 0×41 ecx inc’s.

Looking at another packet you will also note the usage of 0×43 ebx inc. This is another method for writing NOP, of course a series of thirty-one of these 0×43′s would have triggered yet another event. Furthermore, the usage of these NOP slides instead of the traditional 0×90 may mean someone was trying to slip by detection or of course it could be someone trying to trigger it. Regardless the usage of both the 0×43 and 0×41 NOP slides is a little bit peculiar since by standard POP3 uses traditional 0×90 NOP (for session kep-alives).

Unfortunately, it’s not really the NOP slides that we are worried about, it’s the payload that comes after the NOP slides. Furthermore, it’s whether or not there is an actual vulnerability that be could exploited here. Neither of these things could be determined from the traffic observed. Therefore the logical next steps in an attack like this would be to

  1. Determine whether the attacking IP Address was a blacklisted IP Address
  2. Monirotr traffic immediately after the alert for more indicative traffic
  3. Assess the box to determine if POP3 is actually running (*Note Sourcefire’s commercial offering would likely not show this alert if the box is not vulnerable, however I was running free SNORT)
  4. Do a full forensic investigation on the system if POP3 is running and possibly vulnerable

Comments are closed.