Why does the methodology work?

First, ask yourself :

How do you tell a human from a computer?

The CAPTCHA solution : You test the target to recognize some text in an image. If the target passed the test, it’s likely human. If not, it’s likely computer. The idea is that computers cannot do image recognition well, and actually quite bad.

Generalizing, we ask the target to do things only a human can do well but not computers. If the target being tested fails our human test, we conclude it with certain confidence that it is not human.

Well, CAPTCHA works for computers and humans. What about real services and emulated services?

In the same manner, the concept is that : an emulated service and a real service is technically different in implementation, and that difference makes them distinguishable. By targetting these differences, it gives you a hint to the identity of the service.

Let’s go through yet another real example. One question people loves to ask is :

How do I analyze a malware with anti-virtual-machine technology? It does not run in my vmware! Should I use a physical machine?

Wait, but it runs in my VirtualBox. Oh!

Go download any SdBot online or any found in the wild. They are normally armed with an anti-VM (anti-virtual machine) module, which stops the bot execution if it detects it’s in a VM. You can try that in VMWare, specifically VMWare. Then, go try it in VirtualBox. But, save yourself some time, I have tested already. =)

Wrong question, what you shouldask is :

How does the SdBot tell between VMware and a physical machine?

It works because there are technical differences between the implementation of a VM and a physical machine. It is the same idea of emulated services and real services mentioned in the previous article. When I said that it is because of technical differences, it means it is related to its implementation.

Precisely, SdBot running in VirtualBox but not VMware means that SdBot is not anti-VM but anti-VMWare because it is specifically targetting VMWare, but not VirtualBox.

Consider these points :

• VMWare could set a register when a physical machine doesn’t.
• There’s a dhcpd service provided by the VMware which is not generally present in real machines.
• Some instructions in physical CPU are not implemented/supported in VMware.

These techniques are all based on the principle above.

Though, the above also implicated something else : the anti-vm techniques are specific to certain implementations, and you can use some less common virtual machine implementation (VirtualBox, Xen, etc… ) and the SdBot WILL execute, because the anti-vm technique does not apply to VirtualBox, Xen, etc. However, there is no guarantee the anti-vm technique can only hit one implementation, it can target multiple implementation weaknesses.

So, if you have to analyze SdBot in a virtualized environment. You do not need to run it on a physical machine with test automation to take care of the environment. You can create an environment or disable the technique or whatsoever. That is how it works behind the scenes. That goes the same for honeypots in the general idea. So, happy honeypot hunting!

Here is the scan without service probes (sanitized) :

# Nmap 4.90RC1 scan initiated Sat Jul 11 00:39:13 2009 as: nmap -oN result.sS.txt -v -sS <XXXXXX>

Host <xxxxxx> (aaa.bbb.ccc.ddd) is up (0.092s latency).
Interesting ports on <xxxxxx> (aaa.bbb.ccc.ddd):
Not shown: 550 filtered ports, 434 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
110/tcp  open  pop3
139/tcp  open  netbios-ssn
143/tcp  open  imap
443/tcp  open  https
465/tcp  open  smtps
993/tcp  open  imaps
995/tcp  open  pop3s
1023/tcp open  netvenuechat
1025/tcp open  NFS-or-IIS
2103/tcp open  zephyr-clt
2105/tcp open  eklogin
2107/tcp open  unknown
3372/tcp open  msdtc
Read data files from: /usr/local/share/nmap
# Nmap done at Sat Jul 11 00:41:08 2009 — 1 IP address (1 host up) scanned in 114.52 seconds

Here is the scan with service probes :

# Nmap 4.90RC1 scan initiated Sat Jul 11 00:43:00 2009 as: nmap -oN result.sS.O.sV.txt -O -sV -v -sS <xxxxxx>
Increasing send delay for aaa.bbb.ccc.ddd from 0 to 5 due to 24 out of 79 dropped probes since last increase.
Initiating OS detection (try #1) against <xxxxxx> (aaa.bbb.ccc.ddd)
Retrying OS detection (try #2) against <xxxxxx> (aaa.bbb.ccc.ddd)
Host <xxxxxx> (aaa.bbb.ccc.ddd) is up (0.091s latency).
Interesting ports on <xxxxxx> (aaa.bbb.ccc.ddd):
Not shown: 550 filtered ports, 434 closed ports
PORT     STATE SERVICE       VERSION
21/tcp   open  ftp           Nepenthes HoneyTrap fake vulnerable ftpd
22/tcp   open  ssh           OpenSSH 5.1p1 Debian 5ubuntu1 (protocol 2.0)
25/tcp   open  smtp?
110/tcp  open  pop3?
139/tcp  open  netbios-ssn?
143/tcp  open  imap?
443/tcp  open  ssh           OpenSSH 5.1p1 Debian 5ubuntu1 (protocol 2.0)
465/tcp  open  smtps?
993/tcp  open  imaps?
995/tcp  open  pop3s?
1023/tcp open  netvenuechat?
1025/tcp open  NFS-or-IIS?
2103/tcp open  zephyr-clt?
2105/tcp open  eklogin?
2107/tcp open  unknown
3372/tcp open  msdtc?
4 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :

…
…

Read data files from: /usr/local/share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
# Nmap done at Sat Jul 11 00:48:38 2009 — 1 IP address (1 host up) scanned in 338.94 seconds

Nmap shows a lot of question marks because these services all show odd behaviour from many known implementations. That’s because a low interaction honeypot only emulates a part of the target service, which means its missing basic behaviour could be detected as something unknown by Nmap service probes. The service probes are used to identify the software version and actual software using the port. If you see similar output, this is unlikely a real computer – an emulated service, i.e. a honeypot. Of course, this is just one of the ways, and you can probably think of other ways to accomplish the same as well.

Oh yes, this works for some other low interaction honeypots other than Nepenthes, too. In my next post, I will talk about how VM-detection, honeypot-detection and how to analyze a malware that does not run in VM.

Problem
Network managers always want to or are forced to control the information flowing around a network. Most of the time, filtering is a good way to do the control. Inside this big category, we always like to use block list to prevent information comes in or goes out, to and from the network.

Scenarios
Flora doesn’t want her daughter wallow in Japan pop star. Flora knows that her daughter always navigate to some sites with domain name ending as ‘.jp’, she is looking for a tool that can control what kinds of websites their PC can reach.

IT administrator in PC middle school discovered that their mail system started receiving porn advertisement and students are trying to share these links through the mail system, they are planning to have a filter that can block all such mail flows.

Justin loves blogging so much, he is writing them weekly. He loves to collect and read feedbacks from the audiences. However, he hates those spammer pasting unrelated advertisement on his posts. He want to figure out a way to stop them appearing from other audiences.

Solution
The trivial filtering solution to help these people out is bad word filtering. The basic idea is the same as general block list, users can specify the tokens they want to look for when deciding to block the information. In general, there are at least two different definitions to distinguish whether we found the bad word or not. Given an input message M,

1. Split the message M into a sequence of words Ws, we found a bad word bW is in the message only if Ws contains bW.
2. Take the message M as an input stream, we found a bad word bW when there is a list of consecutive characters equals bW.

Both definition has there own advantages and disadvantages, but we will keep this discussion later since the current topic is how to test the filter. Let’s say we pick the first definition for our filter, then what should we test? (Take some time to think about scenarios before continue reading)

Functional Test
According the input of this filter (input message M), we can design few functional test cases. Basic scenarios are,

• empty message [Expected: Accept];
• only a word (either good or bad word) [Expected: good - Accept, bad - Reject];
• two words (good and bad) with different delimiter [Expected: Depends on how the feature define delimiter];
• a list of word and contains (0, 1, 2, all) bad words [Expected: all reject];
• a bad word is embedded in a word (eg. assume evil is bad word, message conatins residentevil.com) [Expect: By design, this message will be accepted]

Beside these functional test cases, we should to have a lengthy message to check boundary cases of the feature. Assume the longest message we accept is N characters, we need to have message with length N, N+1 and N+2. On the other hand, globalization and localization test may be required, depends on who is your target user.

Security Concern
Then we would ask: is there other way to bypass the filter (eg. message using different encoding)? Is it possible to have code injection or script injection attack? Who can use the feature? Where is the bad word list? Who have rights to touch the list? These are security concerns when testing the feature. Drawing a data flow diagram always help to identify what kind of security issues we may have. However, this post only focus on functional testing a feature. May be next time we can discuss how to design security test cases of a feature.

Conclusion
We have only discussed some elementary skills to design the test plan of a feature. You can consider what kind of input the feature can have, both valid and invalid input. Output is another way to discover new scenarios, output is anything that the feature shown. Since we assumed that this filter only say accept or reject of a message and throw some exceptions (eg. input size exceed), the test cases we found here are almost dominated by what we found with the input. Now, you are able to test your program more systematically!

Have a good weekend!

Practice (Just for fun)
Should you want to have some practice, we can discuss how to test an IP block list filter. Here is a simple definition:

INPUT: Only allow IPv4 address, one at a time
IMPLEMENTATION: An IP block list is stored as a text file in the same folder of the filter, user need to directly modify the text file if he want to Add/Remove/Edit an IP address in the block list. The filter will perform a binary search to see if the input address is on the list. If it is, then it will announce reject, otherwise output accept.
OUTPUT: Accept/ Reject the address