The Battle for My Home Network

In considering new topics for blog posts, I came to realize that it may be interesting to spend a few posts discussing aspects of my home network. While I do not by any means consider my home infrastructure the Fort Knox of home network security, I would venture to say it is a little bit above and beyond the average home network. To start the series, I would like to talk about something very near and dear to my heart, Vulnerability Management. Several years ago, after progressing in my entry-level position as a State Police Information Security Officer, I was given a lateral promotion into a Vulnerability Management Coordinator (VMC) position within a large state government.

Due in no small part to the fact that I was still a little “wet behind the ears” I was extremely dependent on tools in the early phases of my transition into the role of VMC. Thus, I am very selective when it comes to choosing the right vulnerability scanner, even in my home. Over the next two days I will be selecting a primary vulnerability scanner for my home network by researching industry leading freeware/community/trial vulnerability management solutions. In particular the following vulnerability scanners will be considered:

• Tenable Nessus (Home Feed)
• Rapid7 NeXpose (Community Edition)
• SAINT
• eEye Retina

| The Battle For My Home Network

A Brief Analysis of Shodan

What Is Shodan

Shodan (http://shodan.surtri.com) is an engine that searches a database of banners and headers recovered from scans conducted over port 21/TCP, 22/TCP, 23/TCP, and 80/TCP. In many ways utilizing the Shodan engine is much like a more reconnaissance specific Google Hacking engine. On the one hand the Shodan engine does not produce sensitive data that a search engine such as Google might produce (password files, spreadsheets, etc.). On the other hand, conducting reconnaissance activities on Shodan can be far more efficient than similar attempts utilizing other search engines to try to find system information.

The reason for this primarily pertains to the fact that Shodan specifically produces IP addresses/hostnames, header information, and banner grabs. Thus, Shodan is a highly functional tool for finding victims for targeted attacks with less false-positives. Furthermore, Shodan produces information that typically is not published on a site that would be indexed within a search engine like Google.

What Does This Mean?

These capabilities have several significant implications. Most notably this shifts a great deal of system-level reconnaissance to be more passive in nature. In other words, attackers can view the results of reconnaissance such as a banner grab, without actually touching a system to get that information (Shodan already hit the system). This allows attackers to passively:

1. Conduct vulnerability assessments without alerting a potential target in anyway.

2. Determine victims for a specific exploit.

What Is The Impact On Defense?

For security monitoring teams, Shodan may present some serious challenges. It is highly unlikely that security monitoring teams will ever be alerted to an attack that is using Shodan. This is again due to the fact that it will not touch their systems. Instead security monitors can expect to see attacks utilizing Shodan for reconnaissance to trigger less alarms. This means that there may be no alerts before an attempted exploit against a vulnerable system. Common alerts may have previously included network or vulnerability scans or banner grabbing attempts.

In addition, hack attempts that attempt to find vulnerable systems by trying to exploit a multitude of non-vulnerable targets will also be less prevalent in an attack utilizing Shodan for reconnaissance. To clarify these attacks can be viewed much like an person who has found a key to an apartment. This person may try every single apartment within the complex in order to find the doors where the key works. The result in this type of attack is typically a large number of alerts in an IPS. However, if Shodan is utilized for reconnaissance, the attacks will become more targeted and therefore will trigger less alerts.

Potential Prevention Techniques

Unfortunately, there is not a simple way to prevent an organization from showing up in the Shodan database. Although the Shodan scan engine is likely custom written (based on the developers biographic information), the scans will likely trigger similar events to any other reconnaissance scan. It may be possible to isolate future Shodan scans as they are likely to come out of the San Diego area, possibly from an ISP such as Cox Communications (again based on the developers biographic information). Unfortunately, this would likely require trending and analysis beyond what I currently have access to.

Shodan Usage

Shodan works much like any other search engine, however one can specifically target systems via a number of methods. This syntax even includes a switch that allows a user to specify geographic location by country. (May be good for future Cyberwar)

Syntax Options:

1. + (equivalent to an AND operation)
2. - (equivalent to a NOT operation)
3. * (wildcard)
4. country:
5. hostname:
6. ports: (limited to 21/TCP,22/TCP,23/TCP, and 80/TCP)
7. net: (in CIDR notation)
8. *Note Shodan only produces 100 results for free

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