Almost no big company is using Win10. Its way too early for its adoption. Even then, they'd have a domain policy that requires passwords and the RDP group would also be controlled by GPO. Even then, they'd be using VPN or Remote Desktop Gateway to run this, not opening thousands of ports 3389 and one-to-one natting them to desktop machines. I could see small ma&pop companies vulnerable to this, but they're probably vulnerable to a host of things. Most small shops I've worked with have no idea what RDP is anyway, and use third party remote products, if any.
Is exploit code out there? If not, then that's quite a leap yet for hackers. In a week or two every win10 machine in the world will have this patched. That's a very short window for what looks like to be an ugly, but tiny edge case.
This is further evidence that Win10 is far from fully cooked. We're not touching it until 2018 with preliminary testing starting in 2017. MS rushed this pretty badly after the poor reception to 8. Also further evidence that remote technologies like ssh, rdp, etc should always be wrapped in something else like VPN or at least strictly firewalled off to known good IPs. Surprises happen.
Ok. I'm glad you have a survey of every business out there.
> Is exploit code out there?
You use any non-Win10 RDP client and enter the username with the blank password.
> Also further evidence that remote technologies like ssh, rdp, etc should always be wrapped in something else like VPN or at least strictly firewalled off to known good IPs
RDP seems like a shitty remote access protocol wrt security, but VPN products are certainly worse than OpenSSH.
How long large enterprise takes to move to a new windows has been studied and published. The typical update is close to 4-5 years. Hell, many shops only recently moved from XP to 7. Hell, Win7 is almost seven years old!
>You use any non-Win10 RDP client and enter the username with the blank password.
What username? What code generates the correct name? That's what I was referring to. Say there is a win10 pro machine with rdp enabled for the account 'jmpendergrast' with no password and listening to 3389 with no firewall blocking it. Wonderful, how many passess until you guess that? Where is the automation code?
Note, by default windows will not let you use a password-less account for RDP:
So that's another hurdle someone has to get through.
Also, when RDP is enabled, it default to the newer versions which don't have this bug. You need to specify legacy access as well. Another hurdle.
So let me summarize what needs to happen for this attack to work: Win10 needs RDP enabled with legacy access explicitly allowing non-NLA connections. Then Win10 needs a firewal rule for 3389 from its router or put on the internet without a NAT/Firewall. Then Win10 needs someone to make an account with a password (passwords are mandatory for rdp). Then someone needs to change the registry to allow blank passwords for a RDP user. Then that user needs to remove the password from that account. Then that user needs to be put in the RDP group.
And if a home user does this, he or she isn't using a local account they're probably using a MSN account.
This is very much an edge case here.
>RDP seems like a shitty remote access protocol wrt security, but VPN products are certainly worse than OpenSSH.
Everything sucks but FOSS right? How non-biased of you. I won't mention heartbleed and shellshock then.
> Everything sucks but FOSS right? How non-biased of you. I won't mention heartbleed and shellshock then.
Nope, but OpenSSH (not PAM) is leaps and bounds above everything else.
Almost all of your beloved VPN software was probably susceptible to heartbleed.
But mostly I've looked at software from "security" companies, and overall it's a steaming pile of shit.
It's probably not going to get popped by non-state actors. I'd say the same things about ssh & rdp in general, but rdp has had a non-trivial amount of bugs in it.
Corporate VPNs aren't OpenSSL, they're usually IPSec implementations and not susceptible to heartbleed.
>It's probably not going to get popped by non-state actors.
Not too long ago people were making this argument but including both OpenSSL and OpenSSH. Now its just OpenSSH. Funny how that works. The reality is that layered security is a best practice and just expecting something to be perfect forever because of past performance is a very questionable premise.
What corporate network uses local accounts as opposed to Active Directory/Domain accounts?
If your business is not managing accounts over the domain via Active Directory and is individually setting up unmanaged local accounts for employees, you have far far bigger security issues than this remote desktop exploit.
Any internal corporate network where a lot of R&D is done. AD accounts are typically for users and generic accounts, but if you're just spinning up a VM to test something, or you rebuild hosts regularly, local accounts speed up workflows. And a lot of people don't have solid security practices in place.
I've been crucified in irc for suggesting moving away from samba and towards using chef/puppet/ansible/salt to manage windows user accounts (if coupled with pxe booting for dynamic image loading on user machines...) I still like the idea. OpenLDAP, etc also aren't cutting it to me... but don't confuse me misunderstanding the current importance of AD lock-in and the man/mind-hours needed to transition away from it.
Wait, so how does this classify as a vulnerability, then? If you explicitly set up a user account with no password (not something you're ever going to do by accident on windows).. people will be able to log into the account with no password.
Still really easy to trigger even by accident. All you need is to check a box to enable RDP while logged on with a local account with no password (though I hasn't tested, you may also need to uncheck another checkbox restricting logon to NLA).
I disagree. It falls in a sweet spot where consumers won't be impacted (because they're utilising Microsoft Accounts/don't enable RDC), and enterprises won't be impacted (because they don't set up accounts with no password).
And then on top of that you need RDC on a Windows 10 box to be exposed to the internet or a LAN with malicious users on it.
It is a legitimate bug that should be patched. But a miniscule subset of users will be impacted, because the pre-conditions are so niche.
Windows 10 hosts running RDP services fail to prevent remote logon to accounts that have
no passwords set.
An attacker could exploit this vulnerability by using an older version of the RDP client
to connect to the Windows 10 host. Once connected, the attacker could generate a list of
user accounts on the host and attempt to log on as those users. If one of the user
accounts has no password set, then the attacker is allowed to log on as that user,
despite the default system setting that restricts access to accounts without passwords to
local logon only.
Is the user enumeration a feature and not a vulnerability of its own?
Windows displays a "Welcome" screen with all user accounts listed when you connect via RDP. I don't know how to automate enumeration, though. Perhaps scraping a screenshot after connecting and then OCRing the usernames.
It might be even easier than that, since RDP remotes the screen at the GDI level, so if you're looking at the protocol, you'll see a regular pattern of DrawText calls.
yuhong is correct: RDP rides inside a TLS connection (if I recall, pre-Vista didn't use TLS but there was some other encryption scheme). I'm not sure how much work it would be to sniff/log session keys and display the decrypted traffic in a nice format. I've never seen a tool for it. I'd be surprised if Microsoft doesn't have at least some netmon.exe tooling for it but it may not be released.
I think we'll be hearing about MS16-007 for a while into the future. Many organizations have a hard time keeping all of their machines up-to-date -- I've had a lot of experience with this while conducting penetration tests -- and vulnerabilities like this live on for a very long time. MS08-067 is still super common to find in the wild.
Building complex software is hard work, so I won't judge the development team that released software this vulnerable. That said, this one seems pretty severe.
> The most severe of the vulnerabilities could allow remote code execution if an attacker is able to log on to a target system and run a specially crafted application.
That reads to me like "RCE if you have RCE". Which I guess is a fair description of the DLL vulnerabilities if you ignore the privilege-escalation parts.
The DirectShow and (perhaps) passwordless RDP vulnerabilities seem rather more severe to me.
And once again I have to manually check the list of windows updates not to install so the Windows 10 upgrade malware is avoided. No matter how many times these updates are hidden they still show up again and again for install. In this instance KB2952664.
Requires:
- Windows 10 Pro or higher.
- RDC to be enabled (not default).
- A non-Microsoft Account to be utilised (not default).
- That local account to have no password set.
Essentially you really need to TRY to get your machine exploitable with that one.