Exploit for the critical flaw Windows ASN.1 Released !!!

Exploit for the critical flaw MS04-007 was released on the k-otik.com's website :eek:

http://www.k-otik.com/exploits/02.14.MS04-007-dos.c.php

the good news is that there is no shellcode on this exploit (not yet ?)

yup! most of the other boards are alive with activity about this. probly just a matter of hours before the **** hits the fan.

I am still at the stage of PC knowledge that remains hopefully optomistic that the knowledge I am exposed to will somehow stick to the grey cells ?
to the point: this exploit aimed at W2K Pro, is it aimed at any in particular, or are all of us out here at risk ?
I looked through the link, but my capability was quickly overhauled by ignorance,
also : will the delivery system be along the lines of the poisened EMails ?

All advice gratefully accepted : so long as it's not attached to any mail :)

its not only win2k its all nt based systems and it isnt aimed at anyone as yet. this code is just a proof of concept that the hole is there and can be exploited. all it does it cause the computer to re-boot. many are hard at work trying to insert shell code into it and im sure the virus writers are hard at work with it as well.

this is perfect worm material because any vulnerable system exposed to the internet can be compromised and in turn attack more systems. if there is an email attack that wont occur until after the internet attacks have played out somewhat but as a worm its not required that anyone run antthing just be there.

Foxy,

Don't worry mate you are doomed.......I have already coded PE4 (C4) into assembler and my tomcat tells me he will have it in binary by the end of the week........

That guy wrote that for nothing?.....if I could only get 10,000 like him, I could give Mr. William Gates III a run for his money?

Just my perverted thoughts?

Cheers

foxyloxley - Do not quote me, but a quick look at the code makes me think that e-mail is definately not a direct delivery method for this exploit. For the exploit to work, a malicious NetBIOS session is initiated and some weird flags are passed in the packets to create an overflow with enough space for some code to fit in near the "/* mechToken: NTLMSSP (room for shellcode here) */" comment. Possible shell code would have to fit in there...

Now, e-mail could be a delivery method if the virus/worm contained this code and used some vulnerability in Outlook Express's Preview HTML stuff or got the user to click on an attachment that scanned through a subnet (internal or external, although internal might be more devastating) looking for target machines to exploit... As long as NetBIOS is disabled on the target machine, so a connection can't take place, I think that you would be safe. So just set up a firewall to block ports related to NetBIOS...


And as to nihil's PE4 (C4)... I'm afraid that all computers are vulnerable. It is completely cross-platform and is known to devastate hardware. The only avaliable protection is an active physical firewall placed to completely surround a workstation, although the solution requires careful planning and can only successfully defend a computer for a few minutes before hardware failure is inevitible. And the delivery mechanism is completely ingenious, nihil. :D

Tim_axe according to the original discriptions of this vuln because of the nature of it (one packet), it could bypass firewalls and enter networks disabling authentication methods allowing the attacker access with system privilages. this may just be a way to rush it out using existing exploit methods to take credit for being the first even though eeye were the ones that reported it to microsoft. this netbios thing surprises me is what im trying to say.

I really hope I didn't take your post the wrong way... I'm assuming you're talking about the original topic... Otherwise I've made a complete mess of this and I appologize. :(


It doesn't appear to be one packet... Note that I'm still trying to get DevC++ to compile the code, which although all of the functions are defined in winsock2.h it still complains that the functions are not defined...

I haven't read any articles explaining this exploit, so I'm working entirely off of the proof of concept code I looked at. Note that in no way could I program this, nor do I do any winsock programming, so these are just observations suggesting why I think there is more than 1 packet involved, and why I think it can be protected against by disabling NetBIOS or using a firewall. I haven't had a chance to read any literature on this exploit, but here is my analysis on the proof of concept which I still can't compile...


Reasons I believe that more than one packet is involved:

First, gethostbyname would have to look at either the name cache of the local computer, or send out a broadcast message on the network asking which computer owns that name, which is resolving the name. If an IP or MAC address is provided, this function could be eliminated, making it slightly more stealth, although it is completely normal on a large Windows network to have a massive amount of broadcast data as computers try to keep up to date.

Next, a socket is created. Probably through normal connection creation, so a few packets would go back and forth. Stuff like this probably also happens when you select a shared folder or try to list shared files/printers on another computer on the network. This part simply ensures that the packet will get to the client, and you are not sending to a "dead" pc.

After that, a NetBIOS session request is initiated with "server_fd", which is the target computer. The attacking computer waits for a response to ensure that NetBIOS is running, and that the computer isn't "dead." If it is dead, it says "recv(NetBIOS Session Response) failed\n", which is on line 246. Line 250 looks at what is returned to see if the connection was closed. If buf != 0x83, the connection is assumed to still remain open and the attack can continue.

Line 262 sets up the session with that 2nd big variable from the beginning of the file. This part is valid, although I don't know why a length one less than the actural length is given. Could be malicious, although I thought that happens later on. Or it might be the correct way to use the function? It also awaits the response and if the response size is 0 the connection is probably dead, and obviously failed. No overflow yet...? And that counts as a packet.

Lastly, the malicious packet is created. Some other session is initiated, and the variables are combined in some weird way with some bit shifting and other things, and finally that one big bad packet is sent. Lastly, a response is waited for and the connection is closed. I'm assuming that this isn't needed as the damage is already done, but instead lets the attacking computer end the program cleanly.


So at least 4 packets are passed in this code, with 3 of them leading up to the actural overflow. There may be others like resolving the name, etc., but at least 4 are used I think. Since the connection is checked to ensure that the computer is dead, the coder asumes that it isn't a one-shot deal. Checks are made to see if it works, so there has to be a reason; that it might not work. Of course after that last packet is sent it is not possible to know the results since it quickly ends the session after that without checking return values. Because they coded it to take into account failing, I am sure it has to be able to fail...?


BTW, has anyone managed to compile it? I've had to do a lot of type-casting from char* to const char* and etc because of how the buf[] is constantly reused with many variable types. But for some reason DevC++ says that the functions in winsock2.h are undefined...? PM me if you can compile it in DevC++ please, or is this for MSVC++ and I have to compile it with that? I would think that since it should be compilable on *nix, DevC++ should be able to compile it... :confused:

tim,

to get the code to compile you need to do this:

1) add "#include <winsock2.h>" in your includes
2) add "ws2_32.lib" to your linker stuff

and try that...

btw, its only one packet :)

the whole proof of concept builds the packet and at the end, it sends once and recv's once, at least thats my interp.

With TheTempest's help, I managed to compile it.

I set netcat to listen on port 40, and had the proof of concept connect to port 40 on my machine. I used netcat since Ethereal didn't pickup anything on the loopback interface.

I guess I see Tedob1's and TheTempest's saying that it is only 1 packet after playing with it for a while. But I saw two packets while testing, though the first was benign and simply initiated a NetBIOS session that the second packet would exploit it. I overreacted a little bit and overlooked that the first conditional where a packet was sent from was for a special case that is not normally used; passing a netbios name along with the other arguments. So I appologize for the overeaction, and my ignorance on the topic by not taking time to read any material that discusses this exploit. I should have read some background information before jumping into the proof of concept...but at least I learned a little bit of networking and linking from this.


I have attached the data that was exchanged by the proof of concept to netcat, with the data redirected into disk files. I seperated the two packets by prematurely ending the first session without a response (CTRL+C), thus causing the "recv(Negotiate Protocol Response) failed" response on the proof of concept. Then I redid the entire thing replying approprately, and then hex-edited out the first packet so that the two were seperate. Finally, I redid it for the full capture. BTW, this was with two arguments, the IP and portnumber. Adding the netbios argument would result in the first few bytes in another packet being different for each name, and would not be consistent during testing or analysis. I guess that a data sniff of this explot may have been posted elsewhere, but if not at least AO has one now...even if it might not include any of the flags from the packets and other low level information...



BTW, the first time I ran this I pointed it at the correct port on my PC..., and then looked at my switch and noticed that for some odd reason my PC was maxing out the 100mbit link... I disconnected and tried to figure out what went on, and with the help of Ethereal it turned out to be HTTP data and apparently was a concidence that it happened at about the same time as my testing. Still, if anyone compiles this be very careful and watch your workstation carefully. Only recommended for a disconnected LAN testing environment, and not for a PC you use daily. Luckily I had already patched this, so I didn't shutdown after 1 minute... Still, it scared the **** out of me.


-Tim_axe

http://www.eeye.com/html/Research/Ad...D20040210.html

Description:
eEye Digital Security has discovered a critical vulnerability in Microsoft's ASN.1 library (MSASN1.DLL) that would allow an attacker to overwrite heap memory on a susceptible machine and cause the execution of arbitrary code. Because this library is widely used by Windows security subsystems, the vulnerability is exposed through an array of avenues, including Kerberos, NTLMv2 authentication, and applications that make use of certificates (SSL, digitally-signed e-mail, signed ActiveX controls, etc.).

Technical Description:
The MSASN1 library is fraught with integer overflows. In this advisory, we'll describe a pair of arithmetic errors in a generic and low-level part of ASN.1 BER decoding that allow a very large swath of heap memory to be overwritten. This vulnerability affects basically any client of MSASN1.DLL, the most interesting of which are LSASS.EXE and CRYPT32.DLL (and therefore any application that uses CRYPT32.DLL).
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

this one only crashes lsass.exe

BTW it compiles as is w/gcc

I spent what was left of last night, trying to get a grip on this sort ot threat. Needless to say it went pear shaped when I fell asleep ??
The input from Tim_axe and Tedob 1 is the stuff of nightmares for me. Two attacks in the last 4 months, both times required a clean install !!!
So, for now: F/W at high security, and netbios blocked In and Out ?
So, finally AO has a member, who if not actually MORE paranoid than nihil, is fast getting there !!

You know, every time this kind of threat comes up people start to get all excited about firewalls, and although they offer some degree of protection there are some important considerations.

1) Your firewall won't protect you from the ******* who brings in a worm-infected laptop from home.
2) It's not rocket science to ZIP the worm up and send it by email. MyDoom again showed that businesses were vulnerable to infected ZIP files, especially ones that spread very quickly. The infected ZIP file doesn't even need to be self-propagating, if you've got access to a spam list you could just email the darned thing out.. enough dumb users will double-click anything to ensure you get the worm dropper through.

The best solution to this kind of threat is "defense in depth". Make an assumption that a worm will penetrate a large network and base your strategy on containing in when it's inside.

So, my recommended steps are:
[list=1][*]Patch everything you can[*]Ensure you have anti-virus signatures set for auto-distribution[*]Switch off unpatched PCs when not in use[*]Education users that equipment must not be used outside the firewall, and non-patched kits (e.g. visitor's laptops) must not be attached inside the firewalled environment. Use a big stick against anyone who violates this, like firing them.[/list=1]

it seems that getting a shell is very hard, so at the moment only a DoS epxloit is in the wild ...

thx for the files

i dont know if you all read the other threads on this topic but it seems that eeye has a few other reports in to MS that they have yet to respond to. lets hope that someone dosnt find them before ms fixes them or at least announces a work around.

I'm still a bit confused about this exploit...

Are there any workarounds besides installing the patch (manual tweaks, etc)? I'm always a bit hesitant when it comes to installing a MS patch. From my experience, there's usually a 50/50 chance it will either fix the problem or make matters worse. :|

MS claims there are no workarounds, but I wonder if that's really true.