CVE-2016-0019 in particular is uninteresting and unlikely to be widely exploited.

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.

The first 3 bullet points seem like they would happen on corporate networks without really trying too hard.

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.

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:

https://support.microsoft.com/en-us/kb/303846

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.

>Note, by default windows will not let you use a password-less account for RDP:

That is what this bug is about. I think there is a chance that the login screen may show the usernames.

Update: reproed and confirmed how it shows the usernames, in fact in some cases it can login automatically!

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.

>You use any non-Win10 RDP client and enter the username with the blank password.

I think they are referring to automated attacks.

But typically that environment would fail bullet 4, right?

You have to create an account, then remove the password from it. You can't create a new account[1] without a password.

[1] http://windows.microsoft.com/en-us/windows-8/disable-remove-...

That's when using a microsoft account. Local accounts can be created without password directly from the install (at least in W10).

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.

Sounds like it only takes one local account, and there's got to be a local admin account in order to add the machine to a domain.

Yes, it has to be a local admin account or it would have to be manually added to the group.

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.

Out of interest, is there something like a Wireshark dissector that'd show this level of detail?

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.

There is a dissector, but no, it doesn't show this level of detail.

It is encrypted I think.

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.

Well, we are talking about Win10 here, which either has forced updates or uses WSUS.

And is also likely not in the hands of an org that has problems keeping things up to date; those orgs are likely still on 7 if that.

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

How is that leader quote appropriate?

It seems like basically a local elevation of privilege. Useful to malware and/or wayward secretaries.

My entire enterprise communicates using SPICE under Gentoo Linux, so I get to watch and laugh from the sidelines.

You can repro on modern mstsc by using enablecredsspsupport:i:0 in the .rdp file BTW.

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.

find kb3035583, right click -> hide update. no more worrying about windows 10. if you haven't already, uninstall kb3035583.

I think you're fighting a war you can't win.

Not trying to win a war as much as show that the old ms is still there.