Once upon a patch

Once upon a patch

Once upon a time, there was a poor sysadmin, Hal, and Hal was oh so diligent and industrious. Hal’s passion were windows servers and in particular patching  these. He loved patches so much, that he couldn’t wait to install the next patches. Every month, Hal was looking for the new security advisories that would explain what new ugly things Mama Microsoft had found out about her products and what she did about these.

Mama Microsoft used to issue several patches each month, so always a lot of work for Hal. Since he didn’t trust automatic updating, he preferred to download and install them manually, after hours at night, when the office was sound asleep.

One day, Mama Microsoft said, from now on, she would only release one monthly patch named CU, a cumulative update. Hal was deeply disappointed – what should he do with all the free time that he would have now, no longer needing to download and install many patches, but just one?

Hal decided, he would use the time for reading. He would not only read the description of the big CU but also these that he hadn’t looked at before, those detailed descriptions for IT professionals. He had read those earlier, until some day, it became boring, reading about all the file versions page by page and in the end, the result was still the same: “install the patch immediately”. But now, with all this free time, he would have another look at them.

One night, going through the pages of https://portal.msrc.microsoft.com/en-us/security-guidance with pleasure, he became all exited.  He discovered something that he had never seen before: an advisory about a vulnerability that sounded like it could be abused by any fool right away! An advisory that he could test out without fondling with these proof of concept scripts that he usually didn’t understand, nor understood the output or effect they produced. This advisory  went

A tampering vulnerability exists in Microsoft Windows that could allow an authenticated attacker to modify the C:\Users\DEFAULT folder structure. An attacker who successfully exploited this vulnerability could potentially modify files and folders that are synchronized the first time when a user logs in locally to the computer.

He had seen that path before – it is the default profile folder, the one that he could use to place certain shortcuts on the desktop of new users of his terminal server. Oh, he liked that, whenever a new user logged on, those shortcuts were already there. And now anyone should be able to write to that folder, and create new shortcuts? That cannot be! But wait, the patch would resolve that and of course, Hal had already downloaded it. So he installed it and went to bed, knowing that his IT world was again a little safer.

A week later, a new secretary was hired. Lisa  was young and pretty. Hal was really looking forward to introducing her to his IT world in the morning after she was shown around. So he sat beside her, started her thin client and, digitally holding her hand, connected to his terminal server to show her these important office desktop icons to work with.

Imagine Hal’s face when instead of his dearest fellows, word, excel and powerpoint, only three text files You.txt, havebeen.txt and pwned.txt showed! Irritated, he opened pwned.txt and in there, in large letters,

HAL LOVES LISA!

appeared before both his and Lisa’s eyes. His blood froze. Quickly closing the text file, blushing, he stuttered  “something… is not right here” and fled from the room.

After downing a mug  of cold coffee, he tried to get  his act together. Sitting locked in the server room, his head whirring and buzzing louder than the fans, he was desperately trying to find out what might have happened. Who put these files there? Lisa was hired only days ago and the user profile was all new - but it had been tampered with already. Tampered… that rang a bell. This patch he installed just last week, wasn’t it against tampering with the default user profile, the profile that was used as template for new users? But why wouldn’t that patch have worked?

He logged on to that server and examined the c:\users\default folder – yes indeed; the desktop folder was holding these three text files, which he immediately deleted, and was still writable for anyone! How could that be? His mobile was beeping and Mr. Smith, Lisa’s boss was calling.

“Hal, god damn it, will you come back and not let Miss Lisa sit here, not knowing what to do!”

“But Mr. Smith, um… I can’t, it’s…it’s an IT emergency!”

“An emergency!?”

“Yes, an emergency, we have been hacked”

“Hacked? Hell, I mean, Hal, what are you talking about?”

Hal was summoned to his Boss’s office where both the head of IT and Lisa’s boss where expecting him.

He had no explanations for all the questions he was asked. How it happened, when it happened, who might have done it. All he was able to ensure them was that the server was updated and setup using the security hardening guidelines that they had worked out. He mentioned the tampering patch, which kind of confused the other two: “So you installed that patch but you didn’t restart the server?” - “NO!”  “So you didn’t install it, you only planned to install it” “No, no, I did”… poor Hal was at loss. He felt attacked, attacked on his home ground, but still not able to defend. But then he had an idea: “Let me test that on a virtual machine!” They let him – what else could they do.

So he setup a clean server that was unpatched. He looked at the folder permissions for c:\users\default. As he was already aware of, they were set dangerously wrong, write permissions for everyone! He used 

icacls c:\users\default /t > dump_before.txt

to dump them to a file. Then, he applied the patch, rebooted the server, dumped them again and compared. To his surprise, the patch actually did something, it changed some permissions, but not all.

It did for example change the permissions of

C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Now why would it change those but not the permissions of the desktop? The desktop folder is important, too – in the end it’s the folder that we all see when logging on…

He held his breath… what the hell. The startup folder was writable by default!? My stars, that would mean, all the time, from day one that we setup that server 2016, someone could have modified the startup folder so that it would possibly hold malicious scripts, executed by any new user? Wasn’t that folder even whitelisted in applocker, because too many users complained!?

“Mama Microsoft” had let him down. Not only had she not kept her promise to properly patch this folder tampering disaster, but she also hadn’t even issued the slightest warning or excuse about this whole incident. Every windows 2016 server vulnerable to this nobrainer attack? Every win10? Incredible. He imagined what amount of work he was facing. Not only verify all that startup folders in the default profiles, but also go through all existing startup folders in the whole company. They could all have been tampered with just waiting for a new admin to logon and then execute that bad script from the startup folder. And how to tell legitimate startup entries from bad ones? Just from the name, you cannot tell. Even after the patch, people would be able to modify the desktop folder or start menu for new users – they could still link malicious scripts in there and call them “word” or whatever. What a hoot.

He went through that advisory again and became angry reading those assessments

“Exploited – no”, “Exploitation more likely” for the “latest software release” or “older software releases not affected”… ha, what would that even mean for server 2016, there was only one release so far... Bitterness came up – he felt betrayed. And he could not even present a plan of action now, at a point where he definitely needed one.

Luckily, an idea came to his mind and he raced off to Mr. Smith’s office: “Mr. Smith whoever has created that files on Lisa’s desktop, will have left some traces – maybe even his name. Yes, his name will be recorded as file owner on these three damn text files and we will have him in a jiffy!”

Now that was good news. They rushed to Lisa’s office just to find Lisa who had already started to work and was composing a letter. “Lisa, give us a minute with your machine, will you?” But Lisa had already deleted these desktop files and even emptied the recycle bin – it seems she was ashamed of these files as well.

So poor Hal had nothing. He had just lost the only evidence that he could have used. He had deleted the original three files from the template desktop folder too hastily while he was in panic and Lisa had deleted hers. So nothing was left but to tell his boss that he had to disappoint them once more.

Surprisingly, his boss was in no bad mood. “Hal, what can I do for you” he said with a big smile on his face. Hal explained. He did not miss to make his boss aware what a strange thing Microsoft was pulling off here, that to him, it begins to look like a cover up of their own negligence. When he started about the deleted evidence, his boss said “Hal, why not just undelete these files”? Immediately, they RDP’d to the server and started some undeletion tool. While it was searching for files to undelete, Hal’s boss said: “Hal, say, do we know this undeletion software works? Can it even restore the owner information of a file? Or will I become the owners of the file, because my user started the undeletion process? I mean, can we rely on what we get here and maybe even use this info in court?” Hal was stunned, his boss really thought of everything. So they stopped the search and made yet another test by deleting and undeleting a test file – the owner info was retained – thank god!

So they let the tool run and, lo and behold, it could recover those files they were searching  for. The big moment came, they looked at the owner info. To Hal’s surprise, it was his boss' user, after all.

“What the heck, we have tested this tool, it could retain the owner info, why didn’t that work!” Hal exclaimed. “It did work. It did work, Hal”, replied his boss – “it was me, I pulled off this prank. Over the years, you became so withdrawn to your nightly patching, just like a hermit.  It was time to teach you a lesson what it means to be responsible for patching, the way I see it. That’s why I wrote down this fairy tale”

The End

---------------------------------------------------------------------------------------------------------------

To all of you who are still looking for a "the moral of the story" - ask yourself:

-do you realize this is for real? This is a huge hole that you need to fix. After a month, no comment on the true contents has been added to this article, which could mean, people are taking it for what it is not: a fairy tale.

-did you understand the need to not only apply this patch but also do manual steps like for example apply this ACL:

icacls C:\Users\Default
      NT AUTHORITY\SYSTEM:(OI)(CI)(F)
      BUILTIN\Administrators:(OI)(CI)(F)
      BUILTIN\Users:(RX)
      BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
      Everyone:(RX)
      Everyone:(OI)(CI)(IO)(GR,GE)

using https://msdirectoryservices.wordpress.com/2012/01/13/set-ntfs-folder-permissions-using-gpo/

-and last but not least: please acknowledge that patching alone is not the answer. We need to verify that these patches actually worked. That means a lot of work - we need to understand the scope of the vulnerability and also have example code to verify it - we cannot rely on others, not even on Microsoft to do that for us as this example has shown!