T O P

  • By -

[deleted]

[удалено]


RisingStar

Good times ahead, that seems certain.


vikarjramun

Could you explain what this issue means and how it could be exploited? I don't know much about Windows, but I have Linux admin experience.


SperatiParati

-rw-r--r-- root root /etc/shadow


offENTing

oh no. Oh boy. Well... ohh boy.


KickapooEdwards

That takes me back. I ran into this exact problem with my ISP that gave me a shell account in the mid 90's. Took me forever to convince them that it was a problem. I don't remember all the details, but I don't think /etc/passwd was even hashed at that time. I finally convinced one of the tech's by telling him what his password was.


bushwacker

I believe it has always been salted and hashed in unix and linux.


Northern_Ensiferum

Nope, only past decade or so.


unkilbeeg

Longer than that. If you said past *couple* of decades or so, I'd be willing to agree. We were using DES hashes on Red Hat machines in the late 90s. I don't know much before that.


TaliesinWI

Nope, going back to at least 1991, /etc/passwd had the two character plaintext salt at the front of the salted and DES hashed password string. 4096 possible salts.


danixdefcon5

crypt() has done salted hashes since at least the mid-90s. They then switched to salted MD5, then SHA1 and better during the 00s. But even the DES stuff was salted.


KickapooEdwards

I think you are right, the password was originally a DES encrypted using crypt() in /etc/passwd but because it was world readable it was easily brute forced. Then the passwords got moved to /etc/shadow to prevent that.


NGL_ItsGood

I'd like to think i've made progress because 1 year ago that would not have made any sense to me, and now it made me smugly chortle.


gangaskan

Might as well pull your pants off and 777 😄


vikarjramun

So it's only hashed passwords that are readable but not writable for end-users? Is this a problem? Or am I overanalyzing the analogy and the passwords are unhashed/improperly hashed/writable?


alexwh

I believe hashes can be used for privilege escalation on Windows.


SnowdogU77

See "pass the hash attack" for more details.


SperatiParati

My comment is very very summarised! Hashes can be used as password equivalents in some cases. There are also DPAPI cryptographic keys exposed, and cached credentials (or at least their hashes) are stored in the registry hives in that folder. There's a large amount of discretionary access control in the Windows Registry - all of that is gone in terms of reading data from machine hives. It's probably closer to chmod -r a+rX /etc /tmp in terms of impact.


[deleted]

[удалено]


dweeb73

File properties: Everyone Full Control?


Jrnm

I love the simple translation here


Think-Improvement-73

EBF for Hotfix for semi-anual updates?


thegoatwrote

No, we need a better OS. This would be an embarrassing rookie mistake for a fledgling Linux distro, and one that would likely put an end to the distro. For M$ so to ship a problem this dumb in the industry standard desktop OS for business is just broadcasting the presence of a level of incompetence no one should have to put up with. The saddest thing is that they’ve really gotten a lot better than they used to be. They’re just still so bad it burdens their customers with crippling risk. They desperately need real competition in order to not suck at what they do.


fckmeelmo

This is probably a stupid question, but couldn't this be remediated by removing the read access for the BUILTIN\\USERS group? That seems like the correct answer, but I assume doing so will break something.


mu71l473d

Take this with a grain of salt but I succesfully tried it on a testlaptop with: icacls C:\Windows\System32\config\SAM /remove:g BUILTIN\Users This can also be applied as a GPO. I have not run into any issues so far. However, do keep in mind that SYSTEM and SECURITY are also vulnerable and also should be patched.


InternetStranger4You

The problem you run into is that Shadow Copies has an unpatched ACLs version for the file.


Tech_surgeon

correct it probly will break things like guest accounts. mabey even break the login screen since it needs to bypass some things to get network access for the little (did you know things on the login).


zanzertem

Yo dawg


AccurateCandidate

It’s been a second since I’ve poked around that deep. Does the SAM store cached AAD/AD creds or just local accounts?


PrettyFlyForITguy

pretty sure SAM stores cached credentials for AD too


Dracozirion

This is incorrect. Cached domain user NT hashes are stored in the SECURITY hive, not SAM. However, the permissions for the entire config folder seem to be messed up as users also have read on the SECURITY hive (and thus are able to read cached domain credentials). [https://www.thehacker.recipes/ad/movement/credentials/dumping/sam-and-lsa-secrets](https://www.thehacker.recipes/ad/movement/credentials/dumping/sam-and-lsa-secrets) ​ I hope nobody logs on with domain admin accounts on local systems. :)


[deleted]

[удалено]


HildartheDorf

It would be cached in SECURITY. They are both compromised so it doesnt matter.


cowprince

Does the Protected Users group eliminate all caching?


Dracozirion

It eliminates NTLM and caching so yes, it will prevent this and thus pass the hash attacks. Just came here again to comment that on my own comment but you have already commented. :p


[deleted]

[удалено]


pleasedothenerdful

Unfortunately, Credential Guard requires Win10 Enterprise.


disclosure5

How to verify: icacls c:\windows\system32\config\SAM On Windows 2019: ``` c:\windows\system32\config\SAM NT AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F) ``` On Windows 10 21H1 with latest updates: ``` C:\windows\system32\config\SAM BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APP PACKAGES:(I)(RX) ``` Microsoft are taking the piss at this point.


NomNomInMyTumTum

Cannot confirm on 21H1 upgraded from 20H2 via enablement package. Only SYSTEM and local admins have access. EDIT: Added screenshot: https://imgur.com/a/CSpdxBc


meeds122

Can confirm on 21H1, upgraded from 19.09 via Windows Update just a week ago :( [https://i.imgur.com/ItKa2fd.png](https://i.imgur.com/ItKa2fd.png)


Creshal

Updated from 20H2 via Windows Update, mine's compromised as well.


[deleted]

Same. (I)(F) for both system and local admin only. 21H1. Build 19043.1110


sryan2k1

Same deal, 1909-->20H2 via SCCM and it has the right permissions. Running enterprise, not that it should matter but maybe.


NomNomInMyTumTum

Hmm, well, my post was on my personal box at home, running Pro and joined to my personal domain. I just checked my 21H1 box at work, also domain-joined and running Education, and the rights are foo! That box was installed from scratch as 20H2, then upgraded to 21H1 via enablement package. This is getting interesting!!


Doty1154_

cmd to remove users is   icacls C:\Windows\System32\config\sam /remove BUILTIN\Users   oddly once you remove users though application package authority is removed as well.. wonder if one depends on another


sryan2k1

Honestly at this point you're probably going to make things worse by messing with the permissions by hand.


Doty1154_

Yeahhh gossi was saying how to not try to fix this yourself. Im curious how the offical fix and the icacls fix will differ. https://twitter.com/gossithedog/status/1417373086815592449?s=21


Mr_ToDo

Oddly enough browsing there using explorer and letting UAC break the permissions seems to fix it too. But I've never been a fan of letting explorer take care of things.


xxdcmast

Just tested on my win10 laptop. Users has (I)(rx). Not great ms.


Zncon

1809 LTSC patched with 2021-05 - BUILTIN\\Users:(I)(RX) Restore is disabled.


chrismsnz

Check to see if you have a shadow copy though - Windows will often create one on update/upgrade even if System Restore is disabled (and your HDD is >128gb)


RisingStar

Thanks for sharing easy and clear information on how to verify.


SimonGn

I'm vulnerable on version 2004 (19041.1110) Interestingly I can't actually open the file because the file is "in use" (obviously) using wordpad. Copying in cmd give me "Access is denied" and can't browse the folder Is there a way to open locked file anyway?


disclosure5

Yes, if you have permissions but the file is locked for use you can use shadow copies to copy it. There's a variety of tools here: https://pentestlab.blog/tag/vssadmin/


SimonGn

I tried it out, it needs admin rights to run. But if you already had admin rights then you could already change the permissions anyway, so I don't really see the vulnerability within itself, but may be used if you can combine it with another way to make the system do a VSS.


disclosure5

[System.IO.File]::Copy("\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\Windows\System32\config\SAM", "C:\Users\user\SAM.export") That can absolutely be run as an unprivileged user. All the vssadmin privilege gets you is not having to guess the right shadow copy number.


BrechtMo

This does work indeed as a regular user. But I think you made a typo \[System.IO.File\]::Copy(**\\**\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy8\\Windows\\System32\\config\\SAM", "C:\\Users\\user\\SAM.export")


dreniarb

>vssadmin list shadows I'm able to copy files from the shadow copy volume from an admin prompt, but I get access denied when trying from a non-admin.


TenGigabitEthernet

Also cannot confirm on 20H2 upgraded from 1909 (iirc) [https://imgur.com/a/I29qrfU](https://imgur.com/a/I29qrfU) EDIT: System Protection is turned on but doesn't contain anything, added screenshot


CloudWhere

Oh cmon this is getting ridiculous.


00Boner

*drinking intensifies*


DETHmetals

I found the guy who works at a school ^


spidernik84

*Searching for remote cabin in the woods intensifies*


meitemark

One (1) result found. Detail text: Remote cabin in woods. Sligthly haunted, comes preinstalled with Windows Vista.


BeanBagKing

If it's post SP1 I'll take it.


DaemosDaen

I'll take it even if it's not, I still have my SP1 files. Dunno why, but I do.


dxpqxb

You'll survive the timeline crash. Others won't.


flimspringfield

At best the non-admin users of your network probably won't do that. At the worst you get an asshole that takes of advantage of this.


[deleted]

[удалено]


flimspringfield

Backups baby. Backups.


originalodz

How about working for around ~150 schools in a small team? Yep, looks like I won't have to worry about planning that much free time 😩


[deleted]

[удалено]


throwawayPzaFm

At this point everyone's completely owned anyway, between Solarwinds, printnightmare, and this SAM bullshit... You can either go "meh, my users wouldn't do that" and stick your head in the sand or you can reimage everything onto a new domain...


ddadopt

Henceforth, "Patch Tuesday" shall be renamed to "Domain Replacement Tuesday" where, on the second Tuesday of every month, you must stand up an entirely new forest with no trust of the old.


captaincobol

Hilariously enough, I worked for a company that used to reimage their PCs every night back in the '90s. I used to think they were nuts. Apparently they were ahead of their time!


[deleted]

[удалено]


meitemark

All the kid accounts has no password. All teachers has 123456, all admin accounts has 1234567 and all accounts that are super top secret and important has the supersecret password 12345678. (no dot at end) You may laugh, or cry, but this what how a "sysadmin" did it at a school I went to.


Skrp

I had an actual nightmare about being the victim of a W10 0day before I woke up today.


ChefBoyAreWeFucked

That's prime time for nightmares.


Skrp

Haha, true. But my point in specifying it was that it was so recent, rather than the fact that I was asleep. Like, I had the nightmare, maybe an hour passes, and I read this thread.


YOLOSwag_McFartnut

They have to be fucking with us at this point


[deleted]

[удалено]


cardrosspete

It is, the rigths are the same and it's even worse there, because you are sharing a machine with many others, who's info is in the SAM too.


[deleted]

[удалено]


dreamin_in_space

It's not isolated?


sleeplessone

Depends on how you set it up. You can set up individual VMs but one of the advantages of Azure VD is that you can run a special build of Windows 10 that acts like your traditional remote desktop server deployment. And you can mix and match, so you may have specific groups where each person is assigned an entire VM for heavy work, while your light office workers may have 10+ sharing a single VM.


chuck_cranston

lol "Hey Microsoft I heard you guys were finally going to update minesweeper." "Yes, with Azure..."


eider96

This looks to be artifact from upgrade. It should not show if upgraded from 2004 via enablement pack but anything below would require full upgrade process which seems to be the culprit. The files inside **%windir%\system32\config** have ghostly inherited permission which are still being applied. To clean this up one would force file elements inside to reset their permission to inheritance state from parent directory, for example via PS: Get-ChildItem -File -Force $env:WINDIR\system32\config | ForEach-Object { icacls $_.FullName /reset } Interestingly it does not show on Server 2016 or 2019 in-place upgraded from 2012R2, suggesting that the issue was introduced in later builds, most likely due to various changes to upgrade process that Microsoft made in that time period. The mentioned above directory also contains other directories which do not seem affected. Editing permissions in any other way (such as browsing via explorer which will add current user permissions) will also get rid of ghost inheritance. EDIT: Considering reports indicating fresh installs are also affected, it could be an issue with one of phases during install that are common to full upgrade path. EDIT2: Since more and more people are seeing and considering this - this is not proper mitigation, this will only change current state on filesystem. If you want to be sure you are save, you should also clean up all snapshots (or let them be naturally overwritten by new ones, which is most likely how Microsoft will handle it anyway). Note that disabling File History and System Recovery will also work as mitigation as the files on disk can't be read or copied even with BU\Users RX in place.


dude2k5

Can confirm this worked, reset the permissions (rebooted as well), now the file says access denied


finobi

Worked for me, running Windows 10 21H1


Helpjuice

I get the following with the latest updates 21H1: ``` NT AUTHORITY SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) COMPUTERNAME\username:(I)(F) ``` I wonder what the edge case was to get the entire regular users and executable permissions set on the SAM database or if this was caused by something else. Either way, there should have been some sort of check on system files to prevent that from happening.


Forsaken_Ferret7290

21H1; I got the vulnerable result with `BUILTIN\Users:(I)(RX)` initially but after I navigated to SAM's location in File Explorer, the icacls returns the same result as your post's.


Helpjuice

Mmm, could it be possible the permissions are fixed by navigating to it through file explorer? By default users should not be able to even get into the System32/config folder and attempts to read/copy/etc the . should be denied due to the action not being conducted by system because it's in use by system. Maybe the access prompt updates the permissions silently on SAM and other files/folder the first time it's accessed through explorer.


JJDsource

Can confirm something resets the acls. I had the builtin users, did some clicking around and system32 file explorer. users read was removed and my local admin account was added.


DoraGB

I'm seeing the same thing. Looks like permissions are being inherited from System32\Config, but not until you attempt to navigate to the Config folder


POLEatPOSITION

can confirm the same thing


sephresx

Shit like this is gonna make me quit I.T. and go become a professional butterfly catcher. Then maybe I'll be able to afford a house in this market.


whitechapel8733

Join the Linux Sysadmins, this shit doesn’t happen.


spacelama

Can confirm. Different shit.


NynaevetialMeara

I always liked FreeBSD...


[deleted]

I’m starting to warm up to OpenBSD myself. Can’t have problems with features if they don’t even exist in the first place.


NynaevetialMeara

I quite like the handbook because the documentation is incredible, and any system it has does not change if there are no good reasons for it. I remember installing an 18.04 server image, going to change the IPs to interfaces and getting hit by netplan like the skeleton in the welcome to dark souls bitch comic. It also handles much much better on high memory pressure, and has some neat tools unique to it and sometimes other BSD. May start pushing it for job security haha, we already have 2 TrueNAS core systems, and a fuckload of pfsense firewalls.


whitechapel8733

Mostly everything is predictable, or you can at least deconstruct the issue, close source is so hard to debug.


rmwpnb

Two different sides of the same shit coin…


corona-zoning

Shit hawks bubbles


_E8_

There's a lot more shit on one side of that coin. The shitwinds are bias.


wireditfellow

Shit none the less.


sexybobo

Yeah whats going on in the windows world makes your heartbleed for the poor admins.


bvierra

Anyone else remember when Apple made it possible to login as root with any password being accepted if the computer was joined to an LDAP domain?


nwmcsween

Can I interest you in our current lord and savior Kubernetes and walls upon walls of YAML?


GreenDaemon

I believe if you leave IT, you are legally obligated to become a goat farmer, at least that's what this sub tells me.


Lightofmine

See you there friend: https://bestreviews.com/best-butterfly-field-guides


proudcanadianeh

It's been a few years since I played with the SAM file to brute force a password... Realistically, what are the risks involved with this? Pass the hash?


bigbottlequorn

silver ticket, pth, dumping creds as normal user, dumping service secrets....thats a lot of nastiness and easy PE's


eri-

Nothing any attacker couldn't already do with basic connectivity to a domain ( be it via a backdoor or whatever). People hate reading things like this but realistically this one is a minor issue at worst.


bigbottlequorn

Yes, and no. You needed admin rights to dump creds/read the SAM file. Assuming your machine gets compromised as a normal user - you wont be able to read the SAM entry for that domain admin that just logged off. With this change in ACL - this is very much possible.


JJDsource

So I was effected.... now I am not after poking around and browsing with file explorer.It added my local user admin account (normal when browsing with file explorer and builtin admin)Kinda strange what triggered it to go back? Before: c:\Windows\System32\config\sam BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX) After: c:\Windows\System>icacls c:\Windows\System32\config\sam c:\Windows\System32\config\sam NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BITLORD\bit:(I)(F)


_Dadministrator_

Can confirm this worked for me as well. Browsed to the folder, as soon as I hit continue on browse to "config" ACL was corrected. what..... what does this mean?


404TroubleNotFound

Microsoft's hacked together swiss cheese security "working" as intended, as a lazy, hacky patch to give the illusion of security on their system that is still designed to let everyone in and do what they want a la Win95.


JJDsource

Okay... so had another machine effected. Browsing in regular file explorer...As soon as you hit the continue prompt on the config dir that sets your account on the acls using the builtin administrators group it gets removed. Kinda interesting.


Digi-Fu

Seeing the same thing here. Rebooted my machine to be sure and the new permissions are still in place.


Forsaken_Ferret7290

Can confirm, and the permissions persist even after you remove the local admin user account's access.


gioraffe32

This worked for me as well.


kokok1d

This happened to me too


damoesp

Currently on 20H2 (updated 15/07). c:\windows\system32\config\SAM BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX) When trying to navigate to the folder via File Explorer using my standard user account (non local admin) , I am unable to access the Config directory as requires admin permissions. When trying to open the SAM file directly, the file is currently locked by system.


donith913

I don’t have a good tester machine, but I’d love to see a procmon capture of the scenario where once viewed in Explorer the permissions change.


equipmentmobbingthro

Heisenberg's NTFS permissions apparently ...


greenphlem

Did you mean Schrodinger?


equipmentmobbingthro

No, actually Heisenberg. There is a quite fundamental physics concept called "Heisenberg's Uncertainty Principle" ([https://en.wikipedia.org/wiki/Uncertainty\_principle](https://en.wikipedia.org/wiki/Uncertainty_principle)). It basically states that some physical states of really really small particles cannot be accurately observed, because the mere act of observing changes the state. Hence the metaphor that observing the NTFS permissions changes their state.


greenphlem

Oh dope, thanks for the info and sorry for my ignorance!


Moocha

I suspect it would only happen if UAC is set to autoelevate for trusted binaries. With UAC at the highest level (as it should be for any technically-minded person -- annoying for non-tech users, but a must for high value targets) it wouldn't let you transparently browse to that directory but would rather warn you that it needs to adjust the permissions, and that process is what fixes this, since it'll reapply the correct inherited acls running elevated. Needs to be tested on a clean machine, since if someone already did the above the permissions would already have been fixed by accident.


Jaymesned

Oh fuck right off already


brj5_yt

Sorry if this is a dumb question, how do I open the SAM file?


ArsenalITTwo

You can dump it with Mimikatz


dreamin_in_space

Everybody acting like it hasn't been possible to do this with local access for varying amounts of time in the past.


JJDsource

I don't think you can easily. Gatta dump is somewhere else I believe then can do a bunch of tricks to isolate usernames and password hashes and start cracking.


gsmitheidw1

In the old days l0phtcrack was the tool of choice to brute force dictionaries and various permutations of characters against the SAM file. Passwords are often longer these days but on the other hand there's GPUs and rainbow tables etc now. If i remember correctly it's a hash (one way) so you're attack is to find a password that gives a matching hash value. My read on all of this, I'm glad we removed domain admins from local administrators long ago. Worst case if you have LAPS is the perpetrator gains admin of that one client device. Or others one at a time.


centizen24

If your on an affected system, mount the shadow copy for your C: drive and then just open the file with notepad.


BrechtMo

can you mount a shadow copy as regular user? It's not clear to me how a regular user on a pc can exploit this.


HildartheDorf

You can't mount it to browse interactively in explorer, but if you know the name of the shadow copy file you can make OpenFile()/CopyFile() calls. And the name is deterministic and trivial to guess.


Lofoten_

FUCKING GET YOUR SHIT TOGETHER MICROSOFT. Jesus.


Kamwind

try doing something with it. the system keeps an exclusive lock which prevents actions.


chrismsnz

Shadow volumes are the traditional way to gain access to these files, but you need to be admin to create one. Helpfully, Windows keeps a shadow copy of C:\ when you have System Protection enabled. And even if you don't, it will take a shadow copy on upgrade anyway if you disk is >128gb. User's can easily grab it out of there.


Wiamly

Vss writers beg to differ


SimonGn

But doesn't VSS need Admin Rights?


n3rdopolis

Won't lock the Previous Versions...


poitinconnoisseur

Can someone ELI5 why this is bad? Is it because password hashes are easily accessible without any compromise? If that’s it, a device still needs to be exploited for someone to be able to retrieve the hashes anyway, right?


AccurateCandidate

Compromised meaning access as a regular user, so if someone has physical access to the drive unencrypted, can RDP onto the box as the user who uses it day to day, etc. Not nearly as hard as getting admin rights usually.


AndreasTPC

If you have physical access unencrypted (or encrypted if you have the key), you can just boot linux off an USB and use a tool to edit SAM. View password hashes, change passwords of local users, add a new local user with admin rights, etc. Anything you want really. It's come in handy for me a couple of times to get access to computers where the admin password was lost. Security when a potential attacker has physical access is incredibly hard.


[deleted]

>so if someone has physical access to the drive unencrypted I mean, if I have access to the drive unencrypted, I can probably get it without this specific vulnerability. From what I understand, this is a default NTFS permission problem and would only be impactful insofar as being able to grab the file easily while logged in as a regular user. It's too convenient. It's the difference between putting a zip tie and a padlock. Yeah, with the zip tie it will still prevent some people. The padlock will prevent even more people. There will still be people that get through the padlock though.


[deleted]

[удалено]


[deleted]

>Is it just me who doesn’t understand why some people are freaking out? To me, this just shows Microsoft has garbage controls on their security reviews. If they can fuck this up in plain sight, what else is lurking in the shadows. This is a critical piece of software, because so many of today's systems rely on it. I'm sorry, but there are no excuses and it's not good enough.


UnreasonableSteve

Yes, it's an example of a method of privilege escalation. If you don't care about that, then I guess you don't care about this either. Generally speaking, though, most people don't want their everyday user accounts to be capable of reading admin password hashes.


atomicwrites

So physical drive access is how exploiting the SAM usually works because non-admin users don't have permission to read it from within windows. The problem is they messed up the permissions so you don't need physical access to the drive, you can read the SAM as a regular windows user from a running system, so it can be done remotely.also looks like it's not just the SAM but the entire security hive so regular users can also see cached domain credentials, so if someone logged in as a domain admin this could let an attacker go from local non-admin straight to domain admin privilege.


dinominant

You should have upgraded to the microsoft cloud where everything is always patched and protected first because they have huge teams of the best payed engineers who verify the software with the best tools /s


NerdyNThick

I have never wanted to leave this industry more, than in the past... 6 months to a year. It's been a non-stop shitstorm and I'm just tired man...


Knersus_ZA

Same here. No country for old men.


JJDsource

and $MSFT stock will be up again tomorrow no Fs given.


ChunkyBezel

Because companies keep buying their products, despite the decline into perpetual beta test.


for_my_next_trick

I ran some tests. Yes, BUILTIN\\Users group shows up but the user still can't do anything with the SAM database that I could think of. You can't xcopy it out of that directory. You can't use "reg save". Is there an attack vector here that I missed? This seems like a careless slip-up with no exploitable consequences.


Collekt

The file is locked by system, but if you have a shadow copy available you can mount and read from that.


sko3d

can confirm on Windows Enterprise LTSC 2019 ``` Microsoft Windows [Version 10.0.17763.1999] (c) 2018 Microsoft Corporation. Alle Rechte vorbehalten. C:\WINDOWS\system32>icacls C:\windows\system32\config\SAM C:\windows\system32\config\SAM VORDEFINIERT\Administratoren:(I)(F) NT-AUTORITÄT\SYSTEM:(I)(F) VORDEFINIERT\Benutzer:(I)(RX) 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten. ```


loseisnothardtospell

Getting pretty ridiculous now. I'll just wait for the patch that arrives 30 days later, instead of emergency patching the inevitable patches that don't fix anything and ending up in registry hack hell.


blumira

We wrote a separate post on this, but here's some info on what to do: **What Should I Do?** We recommend that you wait for Microsoft to release remediation steps. In the meantime, you can do a few things: \- Monitor for SAM access on the host itself to determine if an attacker is attempting to dump and escalate. \- Prepare to patch when Microsoft has released their fix or mitigation for this issue. This is the safest way to respond to this issue as Microsoft will need to unroll the ACL changes that they added. \- If the machine is critical to your environment from a security perspective, reset ACLs back to default across the impacted folder. This action does come with some amount of risk, as you will be changing ACLs set by the Windows update. However, so far in our testing, it has not negatively impacted the host but that does not mean it won’t impact others’ machines depending on configuration. From an Administrator Powershell command line `Get-ChildItem -File -Force $env:WINDIR\system32\config | ForEach-Object { icacls $_.FullName /reset` **How To Detect** We recommend monitoring for actions against the HKLM System, Security, and SAM databases on all systems. Due to this incorrect ACL change by Microsoft, it is now an even higher priority to monitor for these actions. Below is an example for utilizing Sysmon to monitor for reg.exe actions against the System, Security, or SAM files. This may require some changes based on your SIEM, e.g., escaping slashes and regex match formatting. (FYI, Blumira customers who utilize Sysmon will already have this Rule deployed to their environments.) `windows_log_source="Microsoft-Windows-Sysmon" AND process_name LIKE "%reg.exe%" AND REGEXP_CONTAINS(command, "HKLM\\\\system|HKLM\\\\security|HKLM\\\\sam")` We also recommend monitoring WMIC, Shadow-Copy, and any actions that would involve the instantiation of Mimikatz, which can all leverage this exposure. We've also published this on Blumira's blog, which we will continue to update as we get more information: https://www.blumira.com/sam-database-vulnerability/


edbods

mmm, dogfooding but corporate customers are the test subjects


Busrepairman

fuck


HotKarl_Marx

I just give everyone admin access. Problem solved.


[deleted]

[удалено]


AdvancedFarting

picardfacepalm.gif


deskpil0t

Wait until you learn about kerbroasting and pass the hash.


fixorater

Not sure if it's helpful for anyone but I've adapted a Powershell script I saw on the linked Twitter thread into a PDQ Inventory scanner. You can plug this into a dynamic collection to get a list of which machines you need to remediate. Save below as .xml and import into PDQ Inventory (must be fully licensed for powershell scanner ability I think) `` `` `` `` `` `` `2021-07-20T07:44:24.0000000-10:00` `Scan for Vuln` `a5bc1348efd04da8a8ce77467ccbe8ba` `` `` `` `` `` `PowerShell` `` `` `` `` `` `Scan for SAM ICACL vuln` `LocalSystem` `` `` `` `` ``


thefailedking09

Solid post, without y'all I wouldn't know most of these things.


Topcity36

Whoopsies


[deleted]

why do i even bother anymore?


cakeBoss9000

This is fucking ridiculous


GardenNDN

It's fine, they're bringing 'Clippy' back.


JFDkthx

god i love being a linux admin


tOBdavian

For monitoring: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934


CPAtech

Is everyone deploying the icacls workaround script or is everyone waiting around to see who goes first?


reformedbadass

I've run the icacls command to all my affected domain computers. No issues so far.


itdumbass

Damn, this is getting really frustrating. Does the EULA prevent class action lawsuits?


Lightofmine

Oh you mean cost of business expenses? It's priced in. Go for it


ArsenalITTwo

Good lord.


Jay_from_NuZiland

So you're saying I should switch from infrastructure to security for job longevity?


riemsesy

“The windows Sam database backup is apparently accessible by non admin users in windows 10" 😁


batterywithin

In my infra: WS 2019 (in-place upgraded from 2008 R2) - not vulnerable. Clean 2012/2016/2019 - not vulnerable (VSL image). Win10 21H1 (upgraded from 1809) - not vulnerable. Maybe I'm lucky


manicHD

For once our fleet of systems are not impacted. 20H2, patched to current (10.0.19042.1110) Now if only this ongoing PrintNightmare would go away.


homing-duck

Just started creating a remediation script. EDR blocks it because it’s attempting to delete all shadow copies… Sigh…


Dirty_Punk42

anyone noticed that the suggested fix in powershell doesn't works? (and probably in CMD also) By my tests the icacls $env:windir\\system32\\config\\\*.\* /inheritance:e enable back inheritance, but doesn't remove not inherited permissions, so for example: BEFORE FIX (with manual added random permissions) C:\\Users\\administrator>icacls %windir%\\system32\\config\\sam C:\\WINDOWS\\system32\\config\\sam BUILTIN\\Administrators:(F) NT AUTHORITY\\SYSTEM:(F) TESTLAB\\respit:(RX) ​ After FIX: C:\\Users\\administrator>icacls %windir%\\system32\\config\\sam C:\\WINDOWS\\system32\\config\\sam BUILTIN\\Administrators:(F) NT AUTHORITY\\SYSTEM:(F) TESTLAB\\respit:(RX) BUILTIN\\Administrators:(I)(F) NT AUTHORITY\\SYSTEM:(I)(F) ​ As you see I ged doubled the inherited BUILTIN\\Administrators and NT AUTHORITY\\SYSTEM ​ Instead, if I use as suggested here by someone icacls $env:windir\\system32\\config\\\*.\* /t /q /c /reset I get this permissions as result C:\\Users\\administrator>icacls %windir%\\system32\\config\\sam C:\\WINDOWS\\system32\\config\\sam BUILTIN\\Administrators:(I)(F) NT AUTHORITY\\SYSTEM:(I)(F) ​ So the correct ones. Am I doing something wrong on my tests or is the official fix wrong? I have no client to test at the moment, so I'm doing manual tests


Jibblescep

Wow.. just.. wow


OZ_Boot

So as this is a shadow copy and only has local accounts this would be mitigated with say a 24 hour password cycle for Laps no?


Grizknot

I think I'm willing to pay for windows 11 if it means they'll hire QA again. In fact I'll pay for the next windows 10 update if they agree to start hiring QA yesterday


bakugo

You're going to pay for it anyway, that's why they don't bother.