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

[Gurou]

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

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 ?)

[Tedob1]

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

[foxyloxley]

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

[Tedob1]

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.

[nihil]

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

[Tim_axe]

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.

[Tedob1]

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.

[Tim_axe]

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...

[TheTempest]

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.

[Tim_axe]

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