Hi everyone!
It's been a while as I had a nice summer and a busy Techmentor conference after my holiday, and hence I haven't really had the chance to blog :/
Now many of you have seen me point out how hacking into company computers is many times a lot easier than banging on every door with Kali Linux and an armada of different exploits. I'm what I call a conceptual hacker more that a shooting hacker. I like to use deep knowledge of the OS for my benefit and try to find weaknesses based on that. And... I also luckily know a lot of smart people and networking is your core skill for all matters IT.
When I start to look into an environment one of the first things is to PXE boot a machine and hunt for MDT etc. that store passwords in all the wrong places. Now MS has gotten better on this and you know that they remove those quite well... I'll take that back... Not that well it seems.
A good friend of mine and a fellow MVP, Mikko Järvinen (@mikko_jarvinen) sent me a great summary of so many passwords stored in so many wrong places :) Most installation systems should use an account that is just a limited account with delegated privileges to join computers to a domain etc. BUT... We've all seen it, many just put in the Domain Admin accounts and passwords.
Here is Mikko's quote:
I discovered that username, domain and password of the
user account used in installation of Windows from Windows Deployment Server
will be left on the disk after Windows installation is finished and are
readable by any user.
In Windows PE phase, Windows Setup creates a file "setupinfo" in
"X:\Windows\Panther" (X: is the WinPE RAM disk). The username,
password and domain of the user account which has authenticated to the Windows
Setup (WDS mode) will be written in to this file in a readable format
immediately after authentication. The information can be easily found by
searching the following strings inside "setupinfo":
C r e d U s e r
C r e d D o m a i n
C r e d P a s s w o r d
After Windows installation has restarted from Windows PE to the Windows itself
there is a new "setupinfo" file in "%systemroot%\Panther"
folder, but there is also the original WinPE-phase "setupinfo" file
which has been renamed to "setupinfo.bak". It is fully accessible and
still contains username, domain and password information.
We know that MS cleans things like Unattend.xml to say *SENSITIVE*DATA*DELETED* so why don't they just do this all the way and clear these out as well... :(
There's a fix for this: just add a deletion of that file in the setupcomplete.cmd for example and for previously installed machines you could just add a GPP like Mkko shows here:
This was for WDS but many use MDT instead and just the WDS engine to PXE boot. Mikko also asked to remind about something that I've used as well. The fact that also MDT saves the credentials in the C:\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT. although not in clear text but Base64-encoded. Well that's sadly easy to decode so the if you lose that file the password is then bye-bye-captured-by-enemy.
These were all reported to Microsoft but as they require physical access Microsoft doesn't really bother to fix them as these anyway break the immutable laws of security. The truth in the end of the day still is that in many networks these allow an easy to achieve privilege elevation attack so I would strongly encourage you to make sure you are not affected and that that the user accounts used in installation don't have more than bare minimum privileges.
Cheers,
Sami
1122
ReplyDeletewierd!
ReplyDeleteAnyone really seen this, I been looking through several recently installed machines here, and none of them have had this information in clear text on the /panther folder.. The file is there, but no username, domain or password (none of the search strings above).
ReplyDeleteI checked both a Windows 2008R2 and Windows 2012R2 WDS servers.
I meant, I checked machines installed from both 2012R2 and 2008R2 WDS servers (so, not on the WDS servers, but the actually installed machines : )
DeleteMaybe they have fixed it. It's one year old post, and we only tested then.
ReplyDelete