Microsoft accused of leaking RDP attack code The newly-found attack code that exploits critical flaws in Microsoft's RDP (Remote Desktop Protocol) system appears to have been leaked by Microsoft or one of its partners, says the researcher who originally discovered it. Luigi Auriemma, an Italian security researcher who originally reported the flaw to Microsoft, has …
That's my weekend then.
*ring*
"Oh god, oh god, oh god, are we patched?"
"Yes."
"Are you sure?"
"Yes."
“How can you possibly be 100% sure?”
"Because I didn't sleep on Tuesday. I checked every single system on every single network. I emailed you the report that shows the patch level of all your systems."
"Well, but...something this important you can't trust to e-mail!"
"According to the operations panel you have 43 unchecked voicemails..."
"Voicemail isn't proper either!"
"I will endeavor to do better next time."
"Good!"
*click*
*ring*
This is a good way to go about ending the nightmare of WP7's Android rounding-error level sales, and the imminent car wreck of Windows 8 which will make Vista seem like their golden era of user happiness in comparison. Coding a hole in RDP then telling everyone about it is even dumber than basing your entire Cloud offering on a calendar written by a 5 year old who'd never heard of leap years. Oh, wait...
How many people are even affected? I mean RDP used to make a lot of sense way back as "Windows Terminal Services" way back in Windows 2000. You could actually use the network in a civilized way, by setting up one server and having the clients only be "dumb" terminals. I've seen installations with 30 users running on a single 300 MHz server with, back then huge, 512 Mb of RAM. Since its all the same kernel, much of the data can be shared.
But then XP came out, and RDP was used for some fairly useless remote control application, which wasn't even in all versions of XP. Even back then VNC existed and worked just fine. So what's the use of it now?
> So what's the use of it now?
A colleague of mine uses it to set up known-working desktops for disparate (and poorly-controlled) users. As long as the user has a RDP client, he can log in to a controlled box and use it without incident.
I'm still in two minds as to whether or not this is the right way to do things - but he does seem to use it to good effect.
Vic.
I guess there are easily hundreds of thousands of PCs in the intertubes with an open RDP port in the DSL router, so that people can access their private PC from work or from the road.
There was a reason X11 was developed and RDP is a $hitty variant of the X11 idea.
Also, in the corporate intarwebs, it is used to give people access to machines with more "muscles", when they have to run a large data analysis job, simulate an FPGA or load a complex model of something like an A380 into a CAD app.
So, plenty of reasons to do that.
It is used in hospitals. And airports.
In hospitals it's even running life-critical functions.
The main point of that famous clause is to indemnify Microsoft, not to improve safety.
- You find that clause in the spec. literature of damn near everything, from PCB material on upwards, so what do you do?
When its open source software some people are quick to argue that one of the main advantages is that possible flaws are immediately out in the open so that people can fix them. The obvious advantage should be obvious: because its open source many people can take a shot at it.
Note that I don't question this what so ever, its a simple given fact.
And the obvious counter-argument against closed software is that developers can keep stuff secret from you.
So here we are; there is a nasty issue with a remote root exploit (IMO that's the best description), a fix has long been released and now the proof of concept is in the open. Whats the problem?
Honestly; if people claim that "The risk of getting attacked became higher" then I honestly question their priorities and qualities in systems administration then and there. As sysadmin you don't gamble with remote root exploits, no matter the platform. You also /don't/ go "calculate the risks" to validate you postponing to apply the patch / update ("nah, hardly anyone knows about this. We should be safe for 2 more weeks").
What you do is take care of the problem one way or the other ASAP. This stuff should get priority. Patching, turning the service off for a while, limiting the service. Heck; maybe some people finally realize that RDP is a dish best served over VPN.
When "closed source" companies keep exploit code away from the common public they're the bad guys and when they allegedly do publish the code they're bad guys as well ?
Well, with a lot of open-source projects, if you report a security related bug, often the bug will be marked as such, preventing it from being viewed by anyone except a select group.
That select group includes developers on the project, and the bug reporter. Others may be added to that group as time goes on, but it still remains hidden from public view.
What does not make sense to me is that anyone would allow RDP to run directly on a public link.
I presume that if you are clever enough to do NAT/PAT then you should also be clever enough to realise that to create/provide a VPN as the first layer of protection and that RDP should NEVER be available publically.
Unless of course we are talking about internal LANS being hacked, thats another ball game..
A few points for you.
You're placing faith that there will never be an exploit discovered in whatever VPN client/server/protocol you've decided to use. That's exactly as reasonable as placing faith in RDP - which is an encrypted protocol - only moving the vulnerability to some other software stack.
Second, RDP has been available since Windows Server 2000, released February 2000. Twelve years for this vulnerability to be discovered. Yes, it's been there the whole time, but again... there could be an undiscovered issue that's been lurking in whatever VPN solution you've been advocating for the last decade.
Third, RDP is used for Terminal Servers which have the most utility when exposed to the Internet for access. Doing so is no more unreasonable than exposing a web server or mail server. Yes, a Terminal Server will generally have access to internal resources and yes there are ways to have public-facing web servers in a DMZ but ultimately we're still talking about software that is most useful if not behind a VPN.
Am I supposed to keep my IIS sites with Outlook Web Access behind a VPN? That'll be great... all my users with phones relying on that site for ActiveSync just... can't get e-mail. Anyone who wants to check their e-mail via OWA at a kiosk in a hotel just... can't because they can't install the VPN client I force them to use.
There's a difference between best-practices and practical-for-this-application.
Finally let's not forget the Small & Medium Business market. There's a whole whack of real-life reasons in that market that make it impractical sometimes to add layers of complexity. Sometimes Good Enough is the difference between losing a client and keeping one. And I point out again... twelve years we've had no meaningful discoveries in this technology.
As for internal LANs, there's another great point. Someone brings an infected laptop into the network where we DO have exposed RDP for maintenance purposes and wham... the entire building starts executing arbitrary code. Including the domain controllers. Yay.
So hopefully you understand that there are reasons to expose protocols other than SSH to the Internet from time to time, and that regardless... everyone* needs to patch NOW.
*Everyone = those who have RDP enabled.
Hi Paul
A couple of points
We currently use Cisco VPN with RSA Keys which I would consider a "lot" harder to break than RDP.
The fact that RDP is encypted changes nothing because the initial authentication method is nothing more than a Name / Password ( 2 step method). Cisco requires Name/Password + RSA Key ( 3 step method) which greatly increases the difficulty.
>Twelve years for this vulnerability to be discovered
The same could be said for any and all protocols, HTML, IMAP, POP, SMTP , PowerShell etc.
>Doing so is no more unreasonable than exposing a web server
I must disagree, RDP can be turned of when it is not an essential application.
Is Root usage possible on your public RDP port ????.
>Am I supposed to keep my IIS sites with Outlook Web Access behind a VPN.
That depends on company policy, our OWA is behind a VPN.
If I remember correctly ActiveSync requires OWA to be present on the Exchange server but does not require OWA to be on a public interface, OWA could be restricted to 127.0.0.1 or internal LAN access ( Unless of course OWA is made available outside of the company LAN - again thats another set of problems.).
>There's a difference between best-practices and practical-for-this-application
If pratical = huge decrease in defense/security then it might be time to rethink policy.. If you get hacked, "practical" suddenly becomes a lot less "practical". The IT Guy should be explaining to the company manager that "exposure" = risk for mangers company..... Let the Manager decide and change company before you get the blame for his decisions........ .-)
I agree that Small companies can't afford complexity but at the same time they can't afford to get hacked either. I know the difficulty of this subject and this is where I believe Open Source can be a very viable solution ( cost is no longer a problem but knowledge is - always a dilema , I agree).
RDP on internal lans should be reduced to a minumum but again I agree that that is a pain. Educating user to use their laptops correctly/securely helps a long way to helping avoid all kinds of problems ( although that are not completely avoidable).
All in good faith
I disagree with some notions of your post. First, adding an additional layer of security is called "Defence In Depth" and even though this is not a panacea, it is generally accepted as a strong method in security. So putting RDP behind a firewall and granting access only via VPN makes some sense - depending on the situation.
Regarding your intranet infection scenario; what you describe is probably the case with many, many companies and even large corporations. BUT, if you take security seriously you should partition your intranet into many small networks which only have well-defined inter-connectivity, so that they can access shared resources such as corporate web servers, email servers, ERP and internal database and application servers. Also. all your internal servers should be secured with a firewall which only grants access to the server ports which are required to deliver a certain service to internal users.
So an "outbreak" should be limited to (say) the R&D department subnet and should not effect finance, nor marketing nor the sales dept. Of course, that outbreak should be detected by the sensors inside and at the borders of your intranet in more or less real-time. I know that many companies can't even be fscked to inspect firewall logs and they don't have any more sensors in their net, so the reality is very often very dire...
Whist there are plenty of internet-facing Windows servers out there (ever request a Windows VPS from one of the myriad of VPS hosting companies out there and you'll end up with a Windows server on the internet using RDP as the primary access method) the risk is much bigger than this.
If someone was to comprimise any internal or DMZ hosts (whatever the OS), this vulnerability leaves all your valuable Windows hosts (Exchange, SQL etc) open to also be pwned using the published RDP vulnerability without having to be internet facing.
When you consider your entire internal network as potentially hostile (as one should) then having such a vulnerability that can be remotely executed against a commonly-enable port/service is BAD NEWS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
