Tuesday, February 28, 2012

some pcap analysis - CVE-2003-0533

I had a look at pcap file from a honeynet challenge and it was quite interesting. Its about analyzing an attack which has taken place, having to figure out the vulnerability etc. There are 2 hosts involved, A( and B(

Looking at the pcap, lets start by tracing the tcp streams quickly. Looking at the hex representation of the stream(A=>B), you see lots of nops; it seems we have some shellcode in between the same.

The second TCP stream(A=>B) also seems to have something interesting for us.

Certain FTP commands seem to be written into the file "o" and the ftp client seems to be getting invoked in order to execute the commands in the file "o", which involve logging in, getting a file and quitting. After that the downloaded file is run. This is

The third TCP stream seems to have relevant data flowing both ways. The Blue indicates A=>B and Red indicates vice versa.

Haha, that was funny. :) So, as expected a file seems to be transferred. At this point, I'd guess the next TCP stream to be an executable of some sort; the "smss.exe" shown above.

Looking at the hexdump of the file, we can see that the file starts with "MZ" - the file format signature for PE files.

A bit of guessing :-
Everything you just saw, happened in a timespan of 16 seconds which is quite quick. Also, you can do an OS detection on the packets involved and notice that A is a Windows machine(an infected machine?) while B is a Linux machine(honeypot?).
In order to identify the vulnerability, I had another look at the protocols and ports involved in the first tcp stream. Around packet 28(in stream 1), you have a DCERPC request, you have the shellcode being sent, and you have a DsRoleUpgradeDownlevelServer request. Making a few searches we get that, this and this suggesting that we are dealing with a case of CVE-2003-0533.

just a few tshark commands

Just a few tshark commands to get you some information on a pcap file involved.

  • List the hosts involved(if you need a guess the canonical name, dont use "-n")

             tshark -r my.pcap -z ip_hosts,tree -qn

  • Try out OS fingerprinting on the hosts involved in the pcap by doing

             p0f -s my.pcap -N

  • if you wanna see the sessions involved, you can do

             tshark -r my.pcap -qnz conv,tcp

  • To view information about the pcap files like details about the duration across which the packets were captured, you could do :-
             capinfos attack-trace.pcap 

Monday, February 20, 2012

CVE-2011-4612 and icecast2

The vulnerability allows a person to modify whats written into a logfile by crafting a certain GET request to the icecast2 server. You can view the CVE details here and the bug details here.

Saturday, February 18, 2012

CVE-2010-3076 and smbind

This is just another issue I verified for Maverick - I did not write the patch/debdiff for the same. There does seem to be a upstream patch(debian lenny) for the same, so probably it'll be a fake sync rather than a patch in Ubuntu.

I just had a look at the highlighted packages for the week here and decided to look at the web frontend for BIND. You can view the CVE details here.

Tuesday, February 14, 2012

CVE-2011-2921 and ktsuss

ktsuss is a setuid that works more or less like a graphical "su". Lets install it on Maverick and play around with it.

Monday, February 13, 2012

CVE-2010-3387 and vdrleaktest

I recently helped triage and fix this one in Ubuntu(maverick) and thought of writing up a post about it. First of all, lets see how zero-length directories mess things up.

CVE-2011-0996 and dhcpcd

Debian did not seem to have any discussion/patches on this one; however a bit of searching showed me that opensuse had fixed the issue. As reading a patch file would be a lot better use of my time that trying to rediscover it by reading the source fully, I did a bit more of searching and found this(check out the dhcpcd-3.2.3-option-checks.diff file).

As the name suggests, check_domain_name does the domain name sanitizing, making sure you dont have anything other than alphabets, numbers and dots, no two consecutive dots, no "_" or "-" at the start of the domain name, a total length < 255. Inside check_dhcp_option you have the rootpath being checked for symbols of any kind. If the message type was a DHCP_DNSSEARCH, then you are going to need a sanitation check on each of the hostnames retrieved, and hence you have check_domain_name_list.

Saturday, February 11, 2012

CVE-2012-0065 and usbmuxd

While I have been involved in the triaging/patch creation for most CVE's(for Maverick) discussed here, this is one that I picked up because of sheer curiosity. I was not involved in triaging or bugfixing it. The fix was provided by Leo Iannacone.

Lets start off here; we can notice that versions after Maverick are affected. There is not much to explore as most of it has been discussed on various mailing lists and forums already; it seems like a case of a straightforward heap overflow to me.

Check out the diff here if you are curious.

CVE-2010-4000 and gnome-shell

You can view a description of the issue here. From this we can understand that the error is in the exporting of the LD_LIBRARY_PATH. Get the source, try to locate the vuln quickly.

Thursday, February 9, 2012

Ubuntu's symlink restriction

I had a look at a CVE-2011-3618(you can view the launchpad discussion here) recently that was posted in the debian mailing lists. It was related to a symlink vulnerability in the atop package. You can view the proposed patch here.

The attack vector would be the ability to overwrite files by guessing the value of tmpname2. The patch would be to use mkstemp.

I just had a look at Ubuntu's security features(check out the one on symlink restrictions) and it seems that symlinks are not followed in world-writable directories, if the process and the directory owners are not the same as the symlink owner.

If you are curious about how this is implemented, its in the form for an LSM - the commit diff of which you can view here. Its implemented in the yama_inode_follow_link function.