5 crazy windows security problems that are homemade

About the motivation that got me here: 

The other day, I was looking at some info about a security problem with hard drive encryption and there was this interesting discussion about whether or not Microsoft should have trusted the drive manufacturers to do a good job on their end before they let Bitlocker work with it.

Anyway, there was that related tweet by a cryptography professor that went 

Being earnest now: Microsoft trusting these devices to implement Bitlocker has to be the single dumbest thing that company has ever done. It’s like jumping out of a plane with an umbrella instead of a parachute

with his next tweet even going

And not even a real umbrella. More like one of these

Well, now he had me laughing :-)

OK, he has a point, Microsoft was relying on third party technology that is not under their direct control and utilizes it within bitlocker, a core security feature… but really, this is surely not "the single dumbest thing that company has ever done", not even security-wise. But what was the single dumbest thing, then?

So I felt motivated to tweet an answer, listing three Microsoft security design failures that I think do easily trump that which I came across in the last 10 years.

Those and other failures, which I will give a closer look in this article, are all obvious design problems, some of them so grave, you might find them hard to believe. 

If we think of Microsoft as a company that has a huge user base, with their OS’ running within critical infrastructure and companies of any kind, we can safely assume, that their design decisions are never taken by single persons, are never implemented into the OS without thorough testing, but first of all, they are surely taken by responsible people, who are aware that security matters and that they are working for a company, that has declared "trustworthy computing" finally one of its main goals for the future over a decade ago.

Question: what would you do, if you were Microsoft and you discovered a security problem in your products due to bad design decisions so big, that admitting your mistake would really damage your reputation? Let’s see what I could gather about these 5 I am about to describe.

Let me start with the first security issue, dating back to about early 2012 (that was when the problem became known): I will call it 

Free passwords for everyone

The problem, in a nutshell: group policies can be used to deploy all kind of settings to client machines. Let’s say, you are the system admin of your company’s network and you want to mass-deploy a password to your client machines, as in "I want to change the local administrator password on all machines to something really complicated, to improve security". 

OK, how did that work? The GPO creation mechanism encrypted the password, saved it to an XML file and the clients’ group policy service's components (that knew the key) read it and set the password. Since the users are able to read GPO XML files by default as well, it’s good that Microsoft encrypted the passwords, right? Well, encryption is only useful is the key is kept secret, and, guess what, Microsoft has published that encryption key on their website – (still) retrievable by anyone. Is this jaw-dropping, or what?

So what does that mean for you, the admin, when you read, that all those years, the password of the local admin account of any machine was readable by anyone if they only wanted to? I’ll tell you what that means: all these machines, all the data and know-how on it could be already sold to the highest bidder, plain and simple. If any of your colleagues knew that problem existed only one day earlier than you did, he might have had enough time to fill up whole hard drives with all data he could get his hands on, since he had admin access to ALL machines. Attackers had all the time in the world since this issue was present already in server 2008, but it had not been disclosed to the public and patched until 4 years later

So how did Microsoft disclose this? Look at the following: MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege: May 13, 2014, the original security advisory.

You’ll notice some funny things:

First, although the advisory is incredibly long, the "Aggregate Severity Rating" is only "important", which is not the highest rating they have. Hm, why would that be? 

Secondly, the method to detect that you are vulnerable, is at the very end, after scrolling through pages and pages of this "important" advisory. You will find a 200-line-script, that you can execute as domain admin on your DC which helps you find the policies that hold passwords… ok. 

Trouble is, what Microsoft does not tell you: the position the attacker was in. To find out that you are vulnerable, you will not even have to have logon to a DC nor be a domain admin, you can simply run a one-liner script anywhere you like, on a client, with any weak user account. So guess what, very probably, this has been exploited for years, in countless domains.

Then, what does the patch against it do? It simply destroys the ability to use passwords with GPOs in the future, but it does not clean up the old passwords – you have to do that yourself. But, nowhere in the article, they urge you to do it. There are no "people, you GOT TO ACT, don't only install the patch, but change these passwords and delete these saved credentials" anywhere to be seen. Is that responsible behaviour? Would Microsoft argue that they expect admins to understand the importance, anyway?

Let’s move on to the next big thing. I’ll call it 

The bitlocker dilemma

and it dates back some years as well, parts of the problem even over a decade. This dilemma arises when your company tries to upgrade your OS. OS upgrades require restarts. So let’s assume, they have windows 10 and they would like to upgrade it to the newest version by means of scripts or WSUS or SCCM. Surely, the drive will be bitlocked, since your data is important. 

Surely, this update will be done, when no one is near the machine since it would be unpleasant for the user to wait for the update to finish. It might be done after hours. Since the machine needs to restart at least three times, would this mean, the admins will somehow be racing around, having to provide the bitlocker key each time one of the many machines does one of its three restarts? No. Think again.

Instead, Microsoft kindly designed setup to silently suspend bitlocker protection automatically before any restart of the whole upgrade process. Don't say you never noticed :-) - Let's think about the consequences...

What if the user is next to the machine after all when that happens? What if the cleaning personnel is present, or what if the update starts while the user is taking the machine home with his kids around? So whoever is near that device while it upgrades, can possibly own the device. To make it even easier, Microsoft had even enabled unauthorized users to start a shell with system rights (all possible permissions) during setup so you can enter commands at will and gain permanent admin access, manipulate files, read all data – whatever you like.

So, let’s say, some guy over at Microsoft finally realizes the implications of what they have done, and feels this needs to be changed, what will he do? Years after this behaviour was observed for the first time, Microsoft removed the ability to start a shell during setup. Is that all they did? 

Yes, that’s all, bitlocker still suspends itself during upgrades. Still, anyone may own the machine when it upgrades, he just needs to turn off the machine right when it restarts and take out the drive. Oh wait, they have done something else, they added a switch to setup.exe of the upgrade set up so that your admin can tell bitlocker to stay on at all times. Problem is: this only works for those of you use bitlocker "passwordless", in transparent mode, which is not considered the safest mode. See again the dilemma: those who want it secure will use pre-boot authentication and therefore, they cannot safely upgrade unless the device is guarded.

• Is there even a warning about this behaviour? No.
• Can it be configured somehow not to do this? No.
• Is there a security advisory? Not that I know of. 
• Was there a scandal? Well, a little. Some tech bloggers blogged a little, sometimes calling it a “crazy bug”, while this is clearly nothing but an incredibly short-sighted design and not a bug and as it looks, it will not get revised.

On to the next, which I will call 

The patch that never was

It happened in 2016, that some admin discovered a really odd thing after he had installed windows 10-anniversary update ("1607"). He discovered, that ordinary users were allowed to write to certain folders, where they shouldn’t be allowed to write under all circumstances. The folder access control list of the default profile was set incorrectly. This might not ring alarm bells at once, but please consider this: if an ordinary user may dictate what programs an administrator may run, the fun stops – and right that was possible. 

There is an autostart folder within that profile and whatever the attacker puts there, will be executed by ANY user scripts, virii, you name it. Only caveat: this affects only users that happened to log in to this machine for the first time and at a later time than the attacker. Got that? So possibly no one, but again, possibly everyone or even an admin, maybe even a domain admin, since it affects server 2016, too. Believe me, this is super-bad.

So Microsoft was informed and what did they do, did they call it “important”, too? Right, they did. Did they also fix it pretty soon? Well, if you call 1 year "soon", then yes. 

But wait, it is not fixed, they only said they did. They write "The security update addresses the vulnerability by correcting permissions on folders inside the DEFAULT folder structure" while in reality, they only corrected the folder the most important, the autostart folder and all the rest remains writable. YES, you read correctly. Still partly unpatched, still exploitable on server 2016. Still exploitable on any Windows 10, that, at some point in time, was on the anniversary update. 

Although the patch cured the worst part of it, the advisory fails to even mention that this problem continues to exist if you upgraded from 1607 to a newer, seemingly unaffected win10 build. Is this thorough documentation, Microsoft?

And what about that patch? MS technicians have been informed years ago that the problem was only partly addressed, why don’t they care? Oh wait, they did care after all... Microsoft Knowledge Base Archive (pkisolutions.com)  is a second advisory (original taken down by Microsoft, this is an archived version), that calls the admins to action to correct it themselves. By the way, they did not change the original advisory, nor did they link the new one.

Speaking of patches, does anybody here remember the 29^th of September 2015? It was another patch day and could have been the mother of all disasters for Microsoft, you, me, basically the whole windows world. I’ll refer to it as 

The day someone possibly let his 5-year-old son administer the world’s most important server

Let me explain it this way: imagine, you would be able to dictate what piece of code would run on ALL windows machines worldwide. Does that sound like fun? Well... Does that sound like it could possibly mean big trouble? Oh yes. So what had happened was, that for whatever reason, the windows update servers, who deploy patches to half a billion machines or so delivered an update that clearly should never have existed in the first place. In case you missed it, as the update was taken down only hours later: The update description started with a meaningful word "gYxseNjwafVPfgsoHnzLblmm..."(google that) and the descriptive links went, for example, https://jNt.JFnFA.Jigf.xnzMQAFnZ.edu which suggests, they were randomly created – but by whom? What was the payload of that update and who was it intended for?  

When asked, Microsoft did NOT answer that but simply replied "We incorrectly published a test update and are in the process of removing it" Oh, you are? Well, what a relief, because else, I would have thought your world update headquarters admin No.1 had maybe taken his 5-year-old kid to the server room so while his son takes over for a while, he could take a nap.

Hypothetically, if this was really just a test and not a hack, what does that tell us about the processes over at their update servers?

Don’t get me wrong, I am not accusing Microsoft for their bugs, but rather how they handle the aftermath (if they handle it at all).

The final flaw I am going to present was again disclosed in 2015. It happens to be applicable to all windows versions and it’s so severe but yet so simple that it’s truly hard to believe that it hasn’t been abused for decades… which would have been possible, since it was there 15 years before it got disclosed, already. I will refer to it rather simple and technical as 

"Credential cache poisoning"

and it’s about breaking into a windows system which is domain-joined whose screen is locked or which is booted to the logon screen. It is a pretty long story for itself, but I promise, it's worth it.

In case you don’t know, the logon process on domain computers works like this (simplified): We enter username and password, the domain controller verifies whether that user name exists, whether the password is correct, whether the account and password are not expired and lastly, whether that computer is even part of the domain in the first place to determine if we are allowed to log in and only after doing that, the screen is unlocked. 

Of course, the domain controller is a highly secured machine which is not physically accessible by users and this authentication process will normally work via LAN cable or WiFi. Let’s assume we have a hard-wired machine and we just leave the room to go for a bite. We lock our screen, of course, knowing that some untrusted people might be around that would like to have a look at our data, possibly even a colleague.

Let’s now change the perspective and become Mr. nice-colleague-become-hacker, sitting in the same office. What chances does he have to get into your locked machine? He sees the logon screen and obviously knows your user name, but he does not know your password and he cannot guess it. Your machine is encrypted and its firewall is active, hmm. So if not your machine, what other components are involved that he could possibly tamper with? The DC maybe? Oh no, it’s behind closed doors, hard to tamper with, right? But wait, what if he created a fake DC?

A fake DC could be used to "fool" the target machine into thinking, that the account that we are trying to impersonate has a different password than it actually has. Are you following? 

Say, User John Doe has the (unknown to us attackers) password ABC123 but on our fake DC, we create the same user with a (known) password of XYZ456, so that we can unlock the screen with this faked password. So we try and connect the machine we attack to our fake DC, which is installed on our personal laptop by simply using the two ends of a network cable. Will this work? No, it won’t. The windows authentication mechanisms use another password in the background, the so-called "machine password", which is unique for every computer, in order to determine if both machines actually "know" each other as in "the client is indeed affiliated to the domain of this domain controller". So if our fake DC has no knowledge of that machine password (how should it?), the logon will fail.

Hm, let’s see if we can try without a DC, somehow. Even the most stupid hacker will sooner or later get the idea to try and logon without an active network connection. With the cable unplugged, like a laptop working offline, there must be a way to get in somehow without a DC – laptop users do that from time to time, don’t they?. 

You got it. There is a password hash saved to the machine itself, ready to authenticate against in case we work offline and no domain controller can be reached. If we could somehow read or modify that password hash, we would surely find a way in. Unfortunately, the hard drive is encrypted and thus inaccessible as well.

Well, this would be where most wannabe hackers would stop. However, some smart guy some day discovered, that the fake DC can be used, after all. It works like this: on the fake DC, the attacker takes the fake account and sets its password to expired (needs to be changed at the next logon). What happens now, is simply unbelievable, too bad to be true. 

When we try to authenticate that account against the fake DC, it will tell us "password has expired" and we may actually change it right at the logon screen. Afterwards, we may still not logon to the fake DC, but due to the nature of how password changes work, the local (formerly unknown!) password hash has been exchanged, too, and now matches that of the fake password. Now for the final step: simply disconnect the network cable, type XYZ456 and you are in. The trick is blood simple, we abused the "poisoned" password hash which was cached locally on the client to authenticate against.

Guys, this is no wild fantasy, it’s for real and hackers were able to pull this trick in minutes if not seconds, I mean, they could have prepared it already at home. They break into your account, steal your data that is saved locally and lock the machine again, leaving no trace. You cannot even notice the (temporary) existence of the fake password since your old password will still work to unlock it.

Now for the (hopefully) best part: I did not learn about this trick until last weekend. I completely missed it, I even remember reading the security advisory and thinking "oh, just another Kerberos security issue fixed". Guess what, again, the severity rating was once more 2^nd highest, only "important", not critical.

Again, if that is not critical, what is? And why in the world does the advisory read 

"An attacker could bypass Kerberos authentication on a target machine and decrypt drives protected by BitLocker. The bypass can be exploited only if the target system has BitLocker enabled without a PIN or USB key and the computer is domain-joined"

which can be misunderstood and led many into thinking that bitlocker must be in the game, here, which is utterly wrong. It works anywhere, encrypted or not. It is no problem just for those with bitlocker, but for all. 

The advisory talks about "a security feature" being bypassed, while it's simply the logon screen itself. For 15 years, from Win2k right to Win10 v1511, for domain users, logon screen security was nothing but a joke!

I can't help to finish asking: how on earth do they get away with that?