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

[Nrrqshrr]

I just sent you a SYN request, send a SYN-ACK back to ten friends and the crush of your life will start noticing you.

Re:Remote Death Packet...

[Ihmhi]

Now now, don't be so synackal.

Re:Remote Death Packet...

[kmoser]

An hour after being hacked by Chinese researchers, you're hungry for data again. It's known as a having a "SYN-ACK Attack".

Is this the hole that was patched one Tuesday?

[bemymonkey]

Or something entirely new?

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

[bemymonkey]

*on* Tuesday...

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!

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

[Sir_Sri]

Just below your comment there's one from an AC titled "Missed the real story" indicating the exploit code was released from within MS.

That might mean some jackass got the brilliant idea that if there's going to be an exploit soon anyway, it may as well be the original one, and that will scare people into deploying the patch *right now*.

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

[arth1]

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.

That does not follow. The original discoverer might have disclosed it to other resources who leaked it, or leaked it himself.

If that exact packet is an obvious way of doing it, it could also have been an independent discovery.

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

[Abalamahalamatandra]

That does not follow. The original discoverer might have disclosed it to other resources who leaked it, or leaked it himself.

If that exact packet is an obvious way of doing it, it could also have been an independent discovery.

Why doesn't it follow? This has been a risk since day one of Microsoft's advance notification program.

In this article, Luigi Auriemma, the guy who discovered the flaw and reported it to Microsoft, explains the changes he made to the packet and the fact that the same packet was in the released exploit code.

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

[hairyfeet]

Well in a way I honestly can't say that I blame them. Just look at how many here are pissing and moaning they are gonna have to go and deploy this patch across their system, aka doing their jobs, when we ALL know it is SOP for the script kiddies to reverse engineer every single patch MSFT releases and to use that for making easy attacks. Look at how many "ZOMFG Windows got horribly hacked!" we have seen where it was fucking patched MONTHS AGO but corps drug their feet and ended up getting pwned.

To use a /. car analogy if you park your car on the railroad track to take a nap and someone comes along and says "hey i live around here and there is a train coming down that track, let me help you move to someplace safe" and you go "nahhh, hitting those bumps might shake loose a screw, give me time to crawl under the hood and check everything out" and you drag your feet until the train hits you? Well stupid fucking you, you deserved what you got. Its not like this isn't common knowledge, or some new thing the script kiddies are doing, its been SOP since Win9X. MSFT releases a patch, script kiddies reverse engineer, a dozen variants are out in the wild within hours of patching. If you are so damned worried about compatibility you need to be running a test bed anyway just for this scenario, and when a nasty bug is patched your ass damned well better be on the ball and ready to deploy because those script kiddies aren't gonna go "Its okay, we'll wait, just let us know when you're ready". Like it or not folks malware and exploits are a billion dollar business and with that kind of money at stake you damned well better bring your A game, anything less is your ass.

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

[arth1]

In this article, Luigi Auriemma, the guy who discovered the flaw and reported it to Microsoft, explains the changes he made to the packet and the fact that the same packet was in the released exploit code.

That doesn't in any way preclude him from having sent the same code to others. We don't know that Microsoft is to blame here. And I'm not a MS fanboi - I just want there to be more information before anyone draw any conclusions.

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

[jdastrup]

You have 3 days to deploy this critical patch throughout production? Are you saying you have RDP exposed on the Internet, or you have in-house employees that are capable of exploiting the flaw? If it's the former, you are in the wrong field and might be better off working in retail or fastfood somewhere. If it's the latter, I truly feel sorry for you - the employees in my office can barely turn a computer on, therefore I don't have to worry much about them exploiting it until I can get around to patching.

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.

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.

Re:Missed the real story

[Anonymous Coward]

Reread your article. They seem to claim that the leak came from one of Microsofts partners, not Microsoft itself. Posting as AC since I don't want my inbox flooded with the usual haters going on about grammar subtleties.

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?

[xorbe]

That's the point, that someone may turn the crash into a root.

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?

[benzaholic]

I of course have not RTFA, but if your organization is running stone-age ERP, or DNS/DHCP, or Active Directory Server, on the machine configured as your RDP host, then it logically follows that this must be the only computer in your entire organization, because nobody with a clue is likely to distribute core apps/services like that.

Re:How important is this?

[tom17]

My understanding is that if you fill a buffer overflow with random data (or just wrong data) it can cause the kernel to panic if it unexpectedly stumbles upon this incorrect/corrupt data and thus BSODs.

Now, if you are more crafty, you can inject valid code/data rather than panic-inducing random data. This valid code/data could then potentially allow a thorough rooting.

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?

[ThePiMan2003]

The idea is that a specially crafted payload could root the box instead of crashing the system. Right now the payload only crashes the system because the researches didn't spend the time making it worse.

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?

[LordLimecat]

Mitigate means "reduces the severity of". If fewer machines are vulnerable, that mitigates some risk.

Re:How important is this?

[DarkOx]

Never heard of Microsoft Small Business server have you?

Re:How important is this?

[Alioth]

*Yet*. The vulnerability according to the original CVE is a double free of memory that ends up calling a function pointer in the already-freed block of data. Now if the exploit can change the address to their shellcode, they have just gained unauthorized access.

This might not be easy to do; it might not be possible on some architectures due to the NX bit, but it's possible it could result in a remote execution vulnerability.

Re:How important is this?

[eldorel]

Small businesses who know better but can't afford the extra expense of an additional server when they barely use the resources on the primary one do this also. Holy run on sentence batman!

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?

[hellkyng]

Windows Server 2008 64 bit is vulnerable to the POC, I've confirmed it myself.

Re:How important is this?

[gregarican]

Actually from what I see it appears to be newer versions of Windows as well...

Re:How important is this?

[omglolbah]

Mmmmmm, virtualization

Re:How important is this?

[darkpixel2k]

Windows Server 2008 64 bit is vulnerable to the POC, I've confirmshgo7xny3978ty78+++ATH NO CARRIER

Fixed that for you... ;)

Re:How important is this?

[djdanlib]

Wow, that was a well-written post on the subject. I hope you're working for the good guys.

Re:How important is this?

[kermidge]

Thanks for the most clear explanation I've read about this.

[I'm old and not terribly bright; I've never understood why stuff isn't checked to see if it fits before it is used.]

Re:How important is this?

[KingMotley]

It may be vulnerable to the denial of service (or just crashing the remote desktop service), but likely, it isn't vulnerable to running arbitrary code/privilege escalation. But I could be wrong.

Re:How important is this?

[NatasRevol]

Never been in a small business, have you?

Hint: There is no IT guy, maybe a consultant, definitely no one who knows what platform vSphere runs on.

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:How important is this?

[afidel]

Windows 2003 has extended support until 7/14/2015 which means you still get critical security patches (like this one), most large organizations will be moving stuff off 2003 until Q2 2015 if not longer. According to vcenter I have 49 production 2003 machines (out of 131 total) and there's probably 20-30 more physical machines (I'd have to look at one of the monitoring tools to get an exact count). Most of those are being phased out but we don't have the resources to replace every application that was deployed prior to 2011 in one or two years (Windows Server 2008 sucks much like it's workstation brother Vista, 2008 R2 didn't come out until Q4 2010 and only fools deploy anything from MS at launch).

Re:How important is this?

[omglolbah]

I have worked for several years in a fairly small business. I was the only person with technical knowledge and had to support a myriad of odd setups.

If a business cannot afford the tech, then they'll have to live with the downside.. as we did.

Re:How important is this?

[NatasRevol]

If a business cannot afford the tech, then they'll have to live with the downside.. as we did.

Absolutely agree. Which is why things are usually not set up right and virtualization will never be an answer.

Question: Virtualbox's VRDE/RDP

[MickyTheIdiot]

I haven't found the answer to this yet: Virtualbox uses a flavor of RDP (or backwards compatible to RDP) called VRDE. Someone where I worked said this was a protocol problem, so exploit apply to virtualbox or is this just the implementation of RDP that Microsoft uses?

Re:Question: Virtualbox's VRDE/RDP

[Tastecicles]

interesting question. Any Virtualbox devs in the house?

Re:Question: Virtualbox's VRDE/RDP

[Anonymous Coward]

Tested it on my VirtualBox VMs and it did not work.

Re:Question: Virtualbox's VRDE/RDP

[Alioth]

It's an implementation problem. It depends on whether Virtualbox has the same issue in its implementation. According to the original CVE for the vulnerability, the cause is a double free of some memory, the crash actually occuring when the system reads a function pointer that is no longer valid.

Re:M$ Windoesn't

[Abalamahalamatandra]

Because this one is bigger than usual - I know of quite a few small companies that use RDP as a "poor man's VPN" and open it from their internal server(s) directly to the Internet. Insanely stupid and I've never allowed any SMBs that I've set up to do it, but it definitely happens quite a bit.

Interestingly, scanning for 3389 over the Internet has been quite prevalent for quite awhile. I'm sure there are many, many bad guys out there with big lists of system IP addresses all set to go once this (inevitably) turns into a remote code exploit rather than just a DoS.

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?

[Anonymous Coward]

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.

Re:Who uses RDP without a VPN?

[parlancex]

Who uses a VPN without a VPN? If you connect to a VPN without first tunneling it through a secure VPN, you're just asking for issues regardless of any exploit.

Re:Who uses RDP without a VPN?

[NatasRevol]

This:
for i in {1..254}; do nc -v -n -z -w 1 207.46.130.$i 3389; done
will scan Microsoft's public IP space for RDP.

Feel free to test it on your infrastructure.

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:Who uses RDP without a VPN?

[Abalamahalamatandra]

Wow. Shill much?

First of all, your ever-so-awesome RDP changes that started with Vista don't seem to have helped a ton here, unless you took the non-default step of turning on NLA which breaks accessing the server from XP clients that haven't had an upgrade to the RDP client.

Secondly, given the choice between opening RDP to a Windows box or SSH to a Linux box, I'll place my bets on SSH any day of the week. OpenSSH was designed from the start to be a highly-secure protocol. It has, of course, had to evolve over the years to stay ahead of threats just as RDP has. But looking at the history of RDP and the changes that MS has had to make to the protocol, I think it's pretty clear at this point that "giving the user a remote graphical interface" was quite a bit higher of a priority than security from the beginning.

Encryption != security. Thanks for proving my earlier point about people often making that mistake.

Re:Who uses RDP without a VPN?

[Anonymous Coward]

Important to note that this is a "no authorization required" vulnerability. Merely the correct sequence of malformed packets leads to a kernel-level remove code execution. If RDP is listening to the port and it recieves this sequence.... *bork* The BSOD mentioned is just a crude proof of concept in the wild. Be afraid of the attacks that DO NOT BSOD, and in fact leave no real trace.

Re:Who uses RDP without a VPN?

[webheaded]

I run mine on a completely non-standard port via port forwarding at the router. :D

Extra security through obscurity, yes, but hey, most people only bother with the low hanging fruit. It's already encrypted and me not using that port probably stops a shit ton of attacks.

Re:Who uses RDP without a VPN?

[Rich0]

Sure, but all it takes is some code getting run anywhere on a corporate LAN to run through it like wildfire. Firewalls are an obvious layer of protection, but you can't have big security holes on the other side, otherwise you're talking worm city.

Re:Who uses RDP without a VPN?

[kangsterizer]

Well you should start nmap then. I see 3389 open every-f-where. Seriously.

Just think web hosting on windows. That's not SSH. That's RDP. Everywhere.

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:Another story about bad bad Windows and M$

[DeathFromSomewhere]

Did we ever really stop? ;)

Re:M$ Windoesn't

[DigiShaman]

For clarification, I didn't mean VPN, I meant VNC.

Re:M$ Windoesn't

[LordLimecat]

With VPN, encryption is iffy at best and may not be enabled by default depending on the client you use.

If you are setting up a VPN on basically any point-and-click interface, encryption will be enabled by default.

Have fun

[koan]

http://pastebin.com/nSp1Qxpi

Re:Have fun

[hellkyng]

That code is not real, it was a fake release from yesterday. Actual POC code is available in a number of places though and looks very similar.

Re:Have fun

[kangsterizer]

http://pastebin.com/48XkG9sq

nice payload :P

but not very useful for exploiting the bug. lol.

Re:Have fun

[eulernet]

Here is the real one:
http://115.com/file/be27pff7

Directly from the author's blog:
http://aluigi.altervista.org/adv/ms12-020_leak.txt

Re:M$ Windoesn't

[Abalamahalamatandra]

Well, for starters, because Web servers don't run as SYSTEM for quite some time now.

And in any case, opening up port 80 from the Internet to an internal server, rather than one on a DMZ designed to do nothing but host Web content is just as insanely stupid. Same goes for port 443, even though I've lost count of the number of times people have told me 443 is okay "because it's secure!".

Re:M$ Windoesn't

[DarkOx]

This is by far not the first vulnerability in RDP. I know what you mean though its supposed to be a remote management solution; saying its insanely stupid to expose RDP to the net is like saying its insanely stupid to put SSH on the net.

The truth is minimize you attack surface and pick your poison. Have SSH? good tunnel your RDP, have a VPN? even better use it, want to use RDP? ideally use Microsofts terminal server gateway, if not fine put one 'terminal server' open to the outside and access other boxes thru it don't run your critical infrastructure on that box etc.

The fewer services you have the fewer ways you can be attacked. You probably have to run one more web servers, dns, and mail, most business need some sort of remote access solution, pick ONE vpn, terminal services gateway, citrix, ssh, and the administrative people might need a back door should the remote access solution fail for emergencies. My advice on that good old fashion modem listing on an unpublished phone number; and very strong passwords.

If by purchase

[Sycraft-fu]

You mean "download for free" then maybe. You realize that all Windows updates for the entire life cycle of the product are included with the purchase price of the original copy, correct? They do not charge a maintenance fee. They are also very up front about life cycle and end of life. 10 years minimum for all OSes. It can be (and often is) extended, but it is never less than that.

Re:XP, Server 2003

[Rasperin]

Sure, what product do you sell? If I'm interested and it's affordable, I will send you a check in the form of purchasing said product. And if a lot of people like your product they will send you a check for receivable goods or services. Those proceeds will then amount up to this thing called "profit", once you have that you can buy new licenses.

The same people who use SSH without a VPN?

[Sycraft-fu]

There is no particular reason RDP needs to be behind a VPN any more than any other protocol. It is fully encrypted, does secure password exchange and all that jazz. Same as SSH. So if you run any SSH servers that are open to the world, well there's your answer.

If you are all VPN all the time, ok, though I will caution you to carefully check your setup, VPN is often a false sense of security (particularly since in many configurations it punches through the user's NAT and host based firewall and can expose them). However if you are ok with things like SSH to your UNIX systems but not RDP to your Windows systems that just means you have a poor understanding of the protocols.

Re:The same people who use SSH without a VPN?

[MightyMartian]

That applies to Server 2008/Windows 7 RDP (maybe Vista, not sure about that). The versions found in Windows 2000, XP and Server 2003 are not nearly as secure.

Re:The same people who use SSH without a VPN?

[rdebath]

If you're running SSH open to the world you SHOULD be forcing keys not passwords. It only takes one user with a poor password to allow an attacker access to try a local admin exploit or use you as a 'bounce server'.

RDP cannot be put into a key/certificate only mode.

Add to that Microsoft's past performance with security applications (eg pptp) and I have always strongly recommended that RDP be only used within some sort of secure pipe (VPN, ssh!!, zebedee etc). or at the very least moved off the default port and given an IP address filter.

It seems I was right.

As for SSH, despite random number 'issues' I believe overall that it is still more trustworthy and the only protection I think it needs is to have a rate limiter so that the "skiddies" trying passwords go off and bother someone else.

Re:The same people who use SSH without a VPN?

[afidel]

RDP cannot be put into a key/certificate only mode.

Yes but you can use IPSEC with machine certificates to achieve the same goal, or you can put the RDP machine behind a RDS Gateway and use certificates as the authentication method on the website however this does limit the usefulness as it limits your users to only having access from company owned assets (well technically you could issue the certificates and have them install them on other machines but I'm not sure everyone in our IT department would get it right, let alone random business users).

Re:M$ Windoesn't

[aztracker1]

I recall seeing a handful of OpenSSL/SSH vulnerabilities over the years as well... IMHO RDP is no more/less dangerous.. though I was planning on closing off VNC/RDP access and tunneling via SSH myself... I tend to stay on top of these issues more than a lot of small/home office types though.

Re:Who, Who???

[aztracker1]

I use them mainly for IIS, because I happen to work with .Net based web applications... And IIS is a path of less resistance than shoehorning a solution into Mono/Linux. That said IIS is a pretty damned nice web server. There's also AD and Exchange. Those are probably the biggest reasons to run windows based servers.

Re:M$ Windoesn't

[Rasperin]

I'm sorry, mod parent up, so freaking right not even funny.

Was going to post anon, but to hell with my Karma, if you can't recognize that Microsoft isn't the same company it was 12 years ago you are part of the problem and not part of the solution. Not saying they are the best at anything, that's in the eye of the beholder. I'm just saying that Windows 7 (while needing it's code optimized like KDE4 had) is a far superior OS to Windows XP and Windows XP wasn't a bad platform to start off with. In 1999 (when it was released) it was far superior to linux in many ways and it was far worst in others. Today, the same case applies, however MS is actually now contributing to the OS community, working with the development community (see Kinect, their Sony reaction only lasted a few days).

Want to talk about Security, there are 13 known rootkits for Linux which rootkit (the application that scans for them) can't detect. There are viruses, there are kernel dumps, and worst of all there is LIBHELL, this look familiar?
$ someapp
Someapp can't find libboost.so.14
$ find / -name "libboost.so.*"
/usr/lib/libboost.so.15
$ yes QQ
QQ
QQ
QQ
QQ
QQ
^C
$

or my favorite one
Couldn't find /boot perhaps run fschk without -j or -f?
root$ ls /boot
grub boot ...
root$ :'(
>)';
Couldn't find command: :'( )':

So yeah, Linux has it's own stability and security issues, some that make me want to throw myself off a 30floor building sometimes, but I love it too, but I think Microsoft puts out an upstanding product and so does Linux.

I really don't know why I was so verbose, esp with the BS commands.

Ouch...

[gregarican]

I tried to go to the March 2012 Microsoft Security Bulletin on their website and got a 404 Error. Guess they're updating it with new info? BTW I tested the sample Ruby code that was published and the BSOD worked like a champ on a couple of my older boxes here at work. Good thing I don't use RDP on any Internet-facing hosts. Only through a VPN...

Re:Solution

[MightyMartian]

I can't imagine anyone with any important data leaving an X session port open balls-to-the-walls to the Internet, so why on Earth would anyone let RDP, particularly the rather weakly-protected pre-Server 2008 variants, run basically naked like that (not that I would allow a Server 2008 Terminal Server or any other RDP service from a newer OS be visible to the outside world).

We have a Windows Terminal Server plus a few workstations that people can remote into, but they have to come in on our VPN. I closed that channel years ago when I looked on one of our DC security logs and saw a stunning number of dictionary attacks against the Terminal Server.

Re:M$ Windoesn't

[webheaded]

I've seen so many exploits with VNC over the years that it is ridiculous. I'm not a huge fan of Microsoft, but if you're trying to tell me that the VNC servers are a more secure product, you're insane. I was once sitting at my computer and actually had a delightful conversation with someone that hacked into my server while I was physically sitting at it. I immediately switched VNC vendors but I'll never forget that. I always kept it up to date so that was rather horrifying. I hear things like this about VNC server ALL THE TIME. There seem to constantly be new exploits like this and I'm not sure why. Maybe because most Linux users are on SSH and most Windows users use RDP?

Maybe it's just the Windows versions, I dunno, but holy shit. The command line is just so crappy and foreign to me in Windows that I can't get anything done without GUI (and I'm quite fast with GUI). Give me good old SSH on a Linux box and I'm good to go but I need my GUI tools in Windows unfortunately. As it is right now, I've got the webserver and whatnot running inside a virtualbox on my Windows machine that runs all my media center software as well as various other kinds of servers (minecraft etc). Quite frankly, it's just easier to RDP into it than anything else because there are several different types of things I need to dick with.

Re:XP, Server 2003

[gregarican]

Actually newer versions of Windows are also included in the patch. Of course learning this would require one to read past the often-incorrect or often-shortsighted summaries :-P

Re:M$ Windoesn't

[ratboy666]

Are you serious? I guess I have been trolled:

$ someapp
Someapp can't find libboost.so.14
$ find / -name "libboost.so.*" /usr/lib/libboost.so.15

Um... I guess you didn't launch the application from it's starter script, OR use yum or a package aware system to install it, OR you used the "force" option.

In any of these cases - you should know what you're doing. Now -

# sudo ln -s /usr/lib/libboost.so.14 /usr/lib/libboost.so.15
# sudo lddconfig

has around a 80% (possibly greater) chance of fixing it anyway. Free advice.

$ yes QQ
QQ
QQ
QQ
QQ
QQ
^C
$

Un... yes, yes does that -- it's to be used like this:

yes | other stuff that will prompt

The reason it repeats is that it is expected that YES/yes/ok/OK, whatever, is what the application will keep requesting.

Practical use -- a FORTRAN application that uses the PAUSE statement. Run as follows:

grep $p cards > /dev/null && yes go | ./$p >> results;

Ok?

or my favorite one
Couldn't find /boot perhaps run fschk without -j or -f?
root$ ls /boot
grub boot ...

More details please -- what couldn't find /boot?

root$ :'(
>)';
Couldn't find command: :'( )':

The message depends on your shell. Nothing prevents putting newlines into filenames. Don't do it -- it makes the files difficult to type at the shell.

As none of these are security issues, or even bugs, they won't be "fixed" (nothing to fix here).

Now, I want to here more about the root kits. It is rather difficult to insert a rootkit into an SELinux system. Either a shell account would be needed, or a method to get around the service audits and denials. For example, Apache under SELinux is denied the ability to open files outside of its assigned subdirectory. Since this priviledge (or lack of) is inherited by the subprocesses, they also cannot access system files. Simply introducing code won't work. You would need to introduce kernel code. A buffer overflow may introduce code into Apache (also difficult, but possible), but that doesn't have the necessary security to broach the kernel.

Of course SELinux (MAC level security) is only really enabled for services, and not for arbitrary user level code. Simply separate the boxes physically, and don't put user dev accounts on the external facing server. Pretty much done.

And yes, I admit it, I've been trolled good.

Re:Solution

[hawkinspeter]

To be fair, RDP does use encryption, so it isn't wildly wrong to expose RDP to an external site. I wouldn't want to do it myself, but then I use much prefer Linux and use VNC behind SSH tunnels (use -localhost for the VNC server so that it only allows connections from itself).

Hiding RDP behind a VPN should protect from external attacks on this, so security through layers is the answer. I often wonder why FWKNOP http://cipherdyne.org/fwknop/isn't more widely used to hide and protect services.

Re:M$ Windoesn't

[Rasperin]

I really should have put more coherent thought into this response, however it wasn't a troll it was a puking of my brain.

Now, I want to here more about the root kits. It is rather difficult to insert a rootkit into an SELinux system. Either a shell account would be needed, or a method to get around the service audits and denials. For example, Apache under SELinux is denied the ability to open files outside of its assigned subdirectory. Since this priviledge (or lack of) is inherited by the subprocesses, they also cannot access system files. Simply introducing code won't work. You would need to introduce kernel code. A buffer overflow may introduce code into Apache (also difficult, but possible), but that doesn't have the necessary security to broach the kernel.

I'll come back when I'm home to pull up the rootkits, I will not pull up the list while at work. I will first put the ones that are known and are in the rootkit scan application, then I will link to the article about the others (that don't show up on the list in the rootkit scan application, no I don't remember the name off the top of my head).

$ yes QQ....
Un... yes, yes does that -- it's to be used like this:

root$ :'( >)'; Couldn't find command: :'( )':
The message depends on your shell. Nothing prevents putting newlines into filenames. Don't do it -- it makes the files difficult to type at the shell.

Ok yeah so my brain puked my usual response when I see that (the sad thing is I cleaned it up from the poor choice of language)... Lucky you, I decided not to put sex output down (which I originally had).

Ok back to the real meat of this instead of criticizing the waste lines that I decided to put in there.

# sudo ln -s /usr/lib/libboost.so.14 /usr/lib/libboost.so.15 # sudo lddconfig

The problem with this is that methods tend to be deleted more than deprecated in a lot of these libraries. The k's and q's (kde/Qt) are a good example of this, or if they deprecated they're functionality still doesn't work. Let's also talk about hard links to certain libraries and WHY they do that (and why you shouldn't do what you just did above). Let's say I download applicationX and applicationX was developed using libraries with good code quality standards around them (aka they deprecate and don't delete), applicationX is critical to my business. I have to have this application because maybe our code depends on it, maybe it's just really good, maybe it's all my people know. Well applicationX hasn't been updated since 2006 and fills niche market, it depends on libX.so.30 while the current version is libX.so.51, libX has had a complete overhaul for performance and awesomeness reasons. However the developers (for performance reasons) have finally after so many years removed the waste methods that my applicationX depends on. Now I'm left with one of two choices, completely rewrite applicationX (because I was lucky it wasn't closed source), statically link it to the lib (which can cause serious issues if libX is a kernel module and they aren't using a static link and they reaching for libX.so.*), or well no that's all I can think of.

I think the best example of this was when I used to use gaim and kde 3.5, I updated kde and gaim (with linking) wouldn't work. I actually have a lot of examples including but not limited to KDE, Gnome, XFCE, Xorg, gaim/pidgin, qbittorrent, libtorrent, libboost, gimp libraries, linux (the kernel module on arch linux here).

Then again, I may very well be jaded from using things like FreeBSD and Arch Linux since 2002 (only recently shifted to arch from fbsd). So maybe that's it.

More details please -- what couldn't find /boot?

This is during bootup of about any *nix *BSD I've used when a hard shutdown had to happen, or if fschk on boot had an e

Re:M$ Windoesn't

[ratboy666]

Got it -- makes more sense now.

The solution is to retain .so.14, .so.15, etc. The interface to the KERNEL is consistent, so all you need is multiple environments.

This can be achieved by several means -- using LXC (linux containers) is a good choice.

You can also use chrpath to change rpath.

You can also just leave the various library versions. I generally don't do this. After a "while" (defined as several versions), I will gather the application (and attendant libraries) into /opt/... and modify rpath first. After a longer while, I will consider containers (coming from a Solaris background). Anyway, the idea is always to have the application and its environment in a functional form, and deal with both the applications and the library layers above the kernel as an entity.

As to the management of SELinux -- yes, it's a pain. It will require an investment into learning how and what to tag files. However, the same pain you are feeling in simply trying (for example) to get Apache to read from a directory other than /var/www even via symlink is also felt by the attacking program. So, it's a good thing to study up on. Pretty well all MAC systems will exhibit the same pain. The gain? A very limited attack surface.

To know when you have achieved the "Zen" of SELinux? It probably comes around the time when you can incant the spell needed to move /home to /export/home, and still have the system work without spewing everywhere.

Start at:

http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/

and note that, although the underlying MAC is stable, the "UI" is still being tweaked. This is genuinely hard stuff.

SELinux is manageable, but, it requires a philosophical understanding of what it is doing.

I agree that Linux/Unix isn't perfect. But it is universal, open, peer reviewed, and usable.

Looking forward to your list of undetected rootkits. Note that the Unix/Linux philosophy was to allow /boot, /usr, /bin, /sbin, /lib to be mounted read-only. Again, makes it rather difficult to install a root kit. I generally do something like that, and run tripwire (available in your repository). tripwire can be set up with a ruleset of files to CRC, and can detect tampering of any of those files. I generally run tripwire against a known-good off-machine set of CRCs on a weekly or monthly basis, and daily with a set that are on-machine.

Tripwire will email you reports on any suspicious changes (and, really, there shouldn't be any -- maybe a /etc/hosts change if anything).

Now, it is best if your machine can be booted via PXE as well as locally. A separate "clean" set of OS and application images can be maintained off-machine as well.

I watched a machine being rooted back in the Linux 2.0 days. Last time for me. Maybe I am being a bit paranoid, but a combination of these things basically solves the problem. I may get a web-site defacement, but that is about as far as an attack will go (unless its 0-day against SELinux, of course, but I will detect that in either a day, or a week).

Re:Solution

[unencode200x]

You can also use Remote Desktop Gateway (RD Gateway). It's a proxy that uses SSL and RADIUS to hit RD Session Hosts behind it. AFAIK, it is not susceptible to this.