“Oh no, not again.”

By | April 20, 2016

I got what I paid for: those Windows laptops were cheap, but then that’s because they were…cheap.

It isn’t just the crapware that has to be removed, some OEMs leave behind a nasty “birth defect” in the security of the Windows machine. ┬áTL;DR: if you’re going to lockdown that laptop you bought, do that first — it’s likely going to require a clean reinstall.

Duo Labs recently published a paper on current OEM practices in other areas of system security that nicely sums up the problem: “Bring Your Own Dilemma”

I bought two Acer laptops 3-4 years ago with Windows 7 preinstalled. One was branded Acer, the other was a refurbished Gateway brand that nonetheless was an Acer machine. They are for travel mostly and I’ve been thinking about adding a Software Restriction Policy (SRP) whitelist to one or both. I was reading Proofpoint’s blog about that Crypto-Reveton hybrid, seeing that rundll32 reference for the umpteenth time and it reminded me that if I wanted to set up a whitelist, I’d need to also enforce restrictions on DLLs. (And now overnight I see @mesa_matt Tweeting about Dridex starting to hook up a DLL with a Scheduled Task.)

A nice SRP whitelist overview that’s been online for most of Windows 7’s public life is here:
http://mechbgon.com/srp/

(It even predates Cryptolocker.)

There’s a nice step in there to audit whitelisted directories for write access with one of SysInternals’ Swiss-Army-knife utilities, accesschk. I got to the check on the “Authenticated Users” SID for the Windows directory when a long list of entries showed up:

[$p$g]accesschk -w -s -q -u "Authenticated Users" "C:\Windows"
RW C:\Windows\ChangeLang_Done.tag
RW C:\Windows\ClearFi.tag
RW C:\Windows\CSUP.TXT
RW C:\Windows\DeployWinRE2
RW C:\Windows\DPINST.LOG
RW C:\Windows\Driver_install.log
RW C:\Windows\en
RW C:\Windows\IE10_main.log
RW C:\Windows\IE11_main.log
RW C:\Windows\Migration
(snip)
RW C:\Windows\NAPP_Dism_Log
RW C:\Windows\NewDeployWinRE.cmd
RW C:\Windows\Panther
RW C:\Windows\PCHEALTH
RW C:\Windows\RtlExUpd.dll
RW C:\Windows\SoftwareDistribution
RW C:\Windows\symbols
RW C:\Windows\System32
RW C:\Windows\Tasks
RW C:\Windows\WindowsUpdate.log
RW C:\Windows\WLXPGSS.SCR
RW C:\Windows\debug\WIA
RW C:\Windows\debug\WIA\wiatrace.log
RW C:\Windows\DeployWinRE2\DeployWinRE_x64.exe
RW C:\Windows\DeployWinRE2\Lang.xml
RW C:\Windows\en\WLXPGSS.SCR.mui
RW C:\Windows\Migration\WTR
RW C:\Windows\Migration\WTR\netfx45_upgradecleanup.inf
RW C:\Windows\NAPP_Dism_Log\en-us
RW C:\Windows\NAPP_Dism_Log\en-us\Inject_LP1.log
RW C:\Windows\Panther\OLD-unattend.xml
RW C:\Windows\Panther\unattend.xml
RW C:\Windows\Panther\x64.xml
RW C:\Windows\Panther\x86.xml
RW C:\Windows\PCHEALTH\ERRORREP
RW C:\Windows\SoftwareDistribution\AuthCabs
RW C:\Windows\SoftwareDistribution\DataStore
RW C:\Windows\SoftwareDistribution\Download
RW C:\Windows\SoftwareDistribution\EventCache
RW C:\Windows\SoftwareDistribution\PostRebootEventCache
RW C:\Windows\SoftwareDistribution\ReportingEvents.log
RW C:\Windows\SoftwareDistribution\ScanFile
RW C:\Windows\SoftwareDistribution\SelfUpdate
RW C:\Windows\SoftwareDistribution\WuRedir
(and so on)

My first reaction was the same as Douglas Adams wrote about that bowl of petunias: “Oh no, not again.”

I’d done this audit a couple of years back when I was working, had more machines to risk, and so on. It’s just as ugly as whenever I last saw it, but now I have a lot of free time and a small maintenance budget that approaches zero as much as possible. I can spend as much time as I want, though, and I’m long familiar with Jesper Johansson’s “How to Shoot Yourself in the Foot” blogs when he was with Microsoft and the related Microsoft KB885409 article. (Those are over 10 years old.)

Here’s the problem: you can’t put this genie back in the proverbial bottle — the only way to return to original conditions is to reinstall (and leave out Acer’s crappy machine staging routine). It was pretty much just as bad with XP, as Steve Riley wrote 10 years ago:
http://blogs.technet.com/b/steriley/archive/2005/11/08/when-security-breaks-things.aspx

The TL;DR of KB885409 was italicized right in his blog: “don’t change the default ACLs on the operating system’s files and registry entries.”

I couldn’t remember the links without Googling for them, but I long remembered the part of KB885409 he highlighted; here’s a smaller excerpt:

Extensive permission changes that are propagated throughout the registry and file system cannot be undone. New folders, such as user profile folders that were not present at the original installation of the operating system, may be affected. Therefore, if you remove a Group Policy setting that performs ACL changes, or you apply the system defaults, you cannot roll back the original ACLs….

To help you remove the worst results of such file and registry permissions, Microsoft will provide commercially reasonable efforts in line with your support contract. However, currently, you cannot roll back these changes. We can guarantee only that you can return to the recommended out-of-the-box settings by reformatting your hard disk drive and by reinstalling the operating system.

(My emphasis.)

Microsoft was a hall-of-fame enabler of mediocre software, though, so this isn’t enforced or anything — and seeing that KB885409 was written for Windows XP, it’s not surprising that some OEM vendors have ignored this “guidance” since it was first published in 2004. Screwing with the default ACLs was institutionalized years ago; the problem now is that malware is a much more formidable threat than in 2004 or 2006 (which is approximately when I started whining about it).

So that explains culturally why Acer decided this (D)ACL for %windir% would be OK:

[$p$g]icacls C:\Windows
C:\Windows BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)

And this one for the System(32) directory:

[$p$g]icacls C:\Windows\System32
C:\Windows\System32 BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)

TL;DR again: “Authenticated Users” can drop new files into the Windows and System32 directories…so there’s really no point in restricting non-admins from loading DLLs dropped in their user profile. I have no doubt this was highly productive for Acer…for me, not so much.

Looking more closely at the full security descriptor, we see the fingerprints of a poorly executed SysPrep/”Panther” job — I’ll bet they didn’t think Windows 7 was any different than XP. The owner (!) of the directories is the SysPrep account (RID = 8401):

Owner SDDL: "O:S-1-5-21-X-Y-Z-8401"
Primary Group SDDL: "G:S-1-5-21-X-Y-Z-513"
DACL SDDL (reformatted):
D:AI
(A;ID;FA;;;BA)
(A;OICIIOID;GA;;;BA)
(A;ID;FA;;;SY)
(A;OICIIOID;GA;;;SY)
(A;OICIID;0x1200a9;;;BU)
(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)"

Sigh — well, it did make the decision pretty easy: a whitelist would be a maintenance nightmare on this system and resetting the (D)ACLs is close enough to impossible to be a never-ending waste of time. As time-consuming as a rebuild from scratch is, it’s easily the fastest choice and the more secure choice.

I’m partly writing this blog as a reminder to my future self to just archive the installation from the next cheap OEM Windows machine I buy and start from scratch.