RDP Proof-of-Concept Exploit Triggers Blue Screen of Death

mask.of.sanity writes "A working proof of concept has been developed for a dangerous vulnerability in Microsoft's Remote Desktop Protocol (RDP). The hole stands out because many organizations use RDP to work from home or access cloud computing services. Only days after a patch was released, a bounty was offered for devising an exploit, and later a working proof of concept emerged. Chinese researchers were the first to reveal it, and security professionals have found it causes a blue screen of death in Microsoft Windows XP and Windows Server 2003 machines. Many organizations won't apply the patch and many suspect researchers are only days away from weaponizing the code."

Comments

Remote Death Packet...

[fuzzyfuzzyfungus]

I heard a rumor that if you send an SYN-ACK after SYN request from a certain IP, you die.

It totally happened to my cousin's friend.

Re:Remote Death Packet...

[Ihmhi]

Now now, don't be so synackal.

Missed the real story

[Anonymous Coward]

The exploit is one thing, but the real story is that the exploit code was leaked from somewhere inside Microsoft, likely the MSRC. There's a string in the exploit that points to a folder on an internal MSRC server. This is about as bad as it gets. See here: https://twitter.com/#!/jduck1337/status/180495975377408001 and here: https://threatpost.com/en_us/blogs/ms12-020-rdp-exploit-found-researchers-say-code-may-have-leaked-security-vendor-031612

Re:Missed the real story

[fuzzyfuzzyfungus]

It has come to our attention that some of our customers may not have purchased upgrades in a timely manner... We encourage them to remedy this situation as swiftly as their checkbooks allow.

How important is this?

[darkmeridian]

The exploit doesn't allow unauthorized access or remote root. It only allows a denial of service against Windows XP and Windows Server 2003 products. It doesn't seem that Windows 7 and Windows Server 2008 are vulnerable. That really mitigates that risk. I have a Windows Home Server 2011 box that shouldn't be vulnerable because it's based on the WS2008R2 code base. Furthermore, there's already a patch for this bug. Therefore, if you're still running an old version of Windows that you neglected to patch, then your server might be crashed remotely. I don't think it's really that deadly or scary.

Re:How important is this?

[Anonymous Coward]

The sourcecode linked in the summary is just a proof-of-concept. A much more devastating payload, in principle, certainly can be delivered. MS says the vulnerability could allow arbitrary code execution https://technet.microsoft.com/en-us/security/bulletin/ms12-020

Re:How important is this?

[remus.cursaru]

Windows 2003 crashed remotely because you didn't applied a 3 days old patch doesn't seem scary to you? Just wait for the bean counters on the second floor to stone you to death because their stone-age old ERP crap is down. Or the DNS/DHCP server. Or the hole freaking AD.

Re:How important is this?

[EliSowash]

That really mitigates that risk.

I question your definition of 'mitigates' sir. You are describing systems that are not vulnerable to this particular exploit. If you're infrastucture runs on Linux or Mac or oranges with electrodes sticking out of them, you havn't mitigated dick. You just aren't vulnerable.

Re:How important is this?

[Tastecicles]

... If your mission critical server is still running Windows, then you're doing it wrong...

FTFY. :)

(just to please up the anti-microsoft crowd...)

Re:How important is this?

[squiggleslash]

It depends on what the exploit is.

A BSoD is a sign that the kernel space has been tampered with in some way. Now, it could be that there's no way to predictably tamper with the kernel using this exploit (eg all it does is, say, to cause some kernel routine to divide by zero, and thus crash), or it could be something like a buffer overflow exploit, where you can, using this technique, set a specific part of the memory to contain specific code, and by a little finagling, cause that code to be executed.

Now, it's a whole lot easier to demonstrate that a flaw like a buffer overflow can be used to cause a DoS situation like a BSoD than to spend days or weeks getting it to do something more "useful", so what we have here is a quick and dirty proof of concept to demonstrate there is a flaw to begin with.

Basically, the fact the proof-of-concept causes a BSoD doesn't mean that exploits of the flaw are limited to a BSoD. If it's a buffer overflow or something similar, then in theory anyone could exploit this bug to gain remote kernel level access to a Windows computer, without you ever knowing or seeing anything out of the ordinary.

Re:How important is this?

[NatasRevol]

You'd be wrong. Dead wrong.

MS shops do this.
Shops that avoid MS at all costs and give control of it to finance/ms person, who have no clue about security do this.
Small businesses that just don't know better do this.

Re:How important is this?

[Alioth]

With buffer overflows the way it usually works is that a buffer that is allocated on the stack (let's say, a temporary buffer where some user input goes to have something done on it) isn't properly bounds checked. Local function variables are on the stack. What is below them (on x86 and amd64) will be first the saved base pointer of the calling function, and then the return address of the next instruction in the calling function. So on a 32 bit arch, if we imagine the buffer is the first thing on the stack, the first 4 bytes of the buffer overflow will overwrite the calling function's saved %ebp register, and then the next 4 bytes you overwrite will be the return address of the calling function. When the function finishes and executes the RET statement, what happens is the address put on the stack by the CALL is popped off, and the program counter is set to this address.

Normally, this address is the valid return address, but in this case, where you've been able to overflow the buffer, it's whatever the 4 bytes were set to in the overflowing data. In a userland program, the program will usually crash with "Segmentation fault". In kernel land, you may get a kernel panic.

To exploit this, when the attacker overwrites the return address, if they can have this address point to their code instead, they can then gain control of the machine with whatever privilege level the process they are attacking has. Usually, the whole exploit is in the buffer that's overflowed, the attacker basically has to figure out what the address of their payload will be in the stack, and set the function's return address to this, and voila, they can execute arbitrary code.

A number of things have been done in recent years to frustrate this: randomizing the address of the heap and stack to make it harder to predict the address your attacking code will be at, and also making the stack and heap non-executable if the CPU supports it (or using a software emulation of the NX bit) so even if you do overwrite the return address with the address of your code, the program dies with "Segmentation fault" because the processor won't allow code to execute in that memory page.

Re:How important is this?

[afidel]

For userland applications these type of stack smashing attacks have become much harder to exploit due to DEP and ASLR. ASLR basically randomizes where the buffers will allocated from for each run of a program while DEP marks memory pages as being either data or code and data pages are not able to execute (this is hardware enforced on modern processors). However ASLR is not implemented in XP/2003 and DEP is not available for kernel code.

Re:Is this the hole that was patched one Tuesday?

[Abalamahalamatandra]

Yes. The guy who discovered it reported it to both the TippingPoint Zero Day Initiative and to Microsoft, and sent them the packet that triggers the exploit. That exact same packet showed up in this exploit, meaning somebody either at ZDI or Microsoft or part of the MAPP program leaked it.

So much for responsible disclosure! Although as soon as I saw that TippingPoint had released a signature for this on Tuesday, I figured that would be enough information for people to figure out what was up. Leaking the exact packet made things even easier and quicker, though.

Gee, I do so love it when I get three days to deploy a critical patch throughout my entire production environment. That makes for some wonderful conversations with the admin staff, let me tell you!

Who uses RDP without a VPN?

[Kenja]

I have never seen RDP open to the world. If you do that, you're asking for issues regardless of any exploit.

Re:Who uses RDP without a VPN?

[parlancex]

Then you don't have much exposure to the MANY SMB's that are setup like this. I even know of some otherwise competent consultants that do this. Stating that the traffic is secure.

I've closed this hole many times at new clients.

Ah yes, another incompetent *nix admin with his head in the sand. Since this was posted as AC I know you're probably trolling but I'll bite. Since the RDP changes starting with Windows Vista and Server 2008 (pre-R2, even) the RDP connection handshake resembles that of TLS, SSH, and other VPN protocols, utilizing RSA, certificate based identity verification, and AES (with keys transmitted during the RSA encrypted during setup).

If modern RDP is insecure, I have really bad news for SSH, e-commerce and the entire fucking world that uses TLS.

Re:M$ Windoesn't

[DigiShaman]

Insanely stupid

Aside from this nasty RDP bug, how exactly is this "insanely stupid" any more so than leaving a web server connected to the Internet? I've seen plenty of web servers get rooted and turned into zombie spewing infected machines throwing spam and hosting fake AV advertisements.

For over ten years now, a major exploit of RDP is a first that I can recall. And BTW, the RDP connection is encrypted. With VPN, encryption is iffy at best and may not be enabled by default depending on the client you use.

Just because RDP provides a GUI remote desktop and looks more exposed visually doesn't mean it technically is any less secure than other protocols used.

Re:Is this the hole that was patched one Tuesday?

[Abalamahalamatandra]

I have employees who are allowed to come in to the VPN with their home (non-corporate-managed) machines, and no restrictions on their network traffic. I'm working on changing that but it hasn't happened as yet. Additionally, I have way too much experience with malware running on Windows machines while their installed antivirus software is happily telling anyone who asks there's nothing wrong at all.

You need to stop thinking about internal risks in terms of deliberate actions by malicious employees (which is still a risk) and start thinking more in terms of the malware they're almost inevitably running and what actions it can take without their knowledge. This is a highly wormable exploit - think SQL Slammer. I would suggest you consider your soft center as well as your hard crunchy outside for this one.