Blog: Historien om en feature der aldrig skulle have været der

I min digitale “bunke” over ufærdige blogindlæg har der længe ligget et, som hermed er opprioriteret grundet en aktuel sikkerhedsartikel og -opdatering fra Microsoft.

Min oprindelige tanke var at advare mod en meget uheldig funktion (læs: noget man også kunne opfatte som en sårbarhed) i Windows og samtidig demonstrere, hvor nem den er at udnytte for en hacker. I værste fald fører den nemlig til en fuldstændig kompromittering af Active Directory – og det ta’r kun 5 minutter for en almindelig bruger.

Der har oven i købet – i mere end 2 år (!) – eksisteret offentligt tilgængelige Python og PowerShell scripts, samt et Metasploit Modul til formålet.

Men nu dukkede (KB2962486) op for et par dage siden – og endelig ser det ud til, at vi får fred for denne tvivlsomme funktion.

Så lad os sammen se at få den udryddet!

Et tilkøb af præferencer

Den omtalte funktion tillader IT-administratorer nemt og bekvemt at sætte brugernavne og adgangskoder for bruger konti (f.eks. Administrator), planlagte opgaver, servicekonti, delte mapper og datakilder – på alle Windows servere og klienter over netværket. Smart, ik’!?

Funktionen stammer fra Group Policy Preferences (GPP) teknologien, som oprindeligt blev solgt som et selvstændigt produkt, “PolicyMaker”. Dette produkt blev gradvist “importeret” i Windows efter Microsoft købte firmaet DesktopStandard tilbage i ultimo 2006. Det er altså her, den sårbare – og nu bedagede – funktion egentlig stammer fra.

Vi har vidst det noget tid

Selvom mange kyndige IT-administratorer nok har vidst, at sikkerheden i denne funktion var “tvivlsom”, så er den blevet godt brugt rundt omkring – for det var pludselig så nemt at administrere klienterne. Bekvemmelighed vinder som bekendt alt for ofte over sikkerhed.

Technet-indlægget “How to change the password for the local administrator account on multiple machines (the easy way without scripting)” fra 27. marts 2009 viser meget godt hvordan det foregår i praksis. Man bruger en masse linjer (og billeder) til at fortælle hvor cool en funktion er og hvor meget tid man kan spare ved at benytte den. I en lille note i bunden fortæller man derefter, at det ikke er en sikker metode. Skaden er sket – alverdens IT-administratorer er solgt og allerede videre med implementeringen…

Også Microsoft Group Policy Teamet advarede om sårbarheden på deres egen blog helt tilbage i august 2008 (Reposted and updated on 22 April 2009). I artiklen “Passwords in Group Policy Preferences” står der således: »However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it… but because the password is merely obscured rather than secured, you should carefully evaluate the security ramifications for your situation to determine whether it is appropriate to use this feature.«

Skrev du ikke selv om den funktion engang? Ups…

Personligt har jeg lidt dårlig samvittighed, idet jeg tilbage i december 2007 og februar 2008 skrev om de nye funktioner, som kom med Group Policy Preferences (GPP) i Windows Server 2008.

Til mit forsvar bemærkede jeg dog dengang, at det på daværende tidspunkt var uklart hvilken krypteringsalgoritme, der var tale anvendt. Under afsnittet “Encryption” skrev jeg således:

If you are worried about how passwords for user accounts, service accounts, scheduled task logon accounts, etc, are stored (knowing that simple XML files are used for preferences), I can tell you that they are encrypted. I do not know the algorithm used (yet), but I can tell you that “password” translates to “wWHIrHyXsbFpBhpQ/fMKbwEEg3Ko0Es+RskCj/W6F8I” and “Password” translates to “VPe/o9YRyz2cksnYRbNeQmFQgz60no44B/3YywYtmYU” – who would have guessed that?

I’ll try to get the detailed information and post it later – so far all I can say is that it is a good sign that a small change in the clear text string (lower case “p” changed to upper case “P”) gives a huge change in the encryption string.

Jeg havde ikke lige forestillet mig, hvor ringe det var implementeret i praksis.

Nøglen ligger under måtten

DesktopStandards implementering af AES-algoritmen var for simpelthen svag (banal obfuscation-teknik). Krypteringsnøglen blev hurtigt fundet og senere gjort offentligt tilgængelig på MSDN.

Nøglen på 256-bit viste sig at være: »4e 99 06 e8 fc b6 6c c9 fa f4 93 10 62 0f fe e8 f4 96 e8 06 cc 05 79 90 20 9b 09 a4 33 b6 6c 1b« og derfra er det relativt trivielt at dekryptere de anvendte adgangskoder til klartekst.

Det nye fix fra Microsoft

Den omtalte funktion giver fortsat anledning til bekymring, men nu gør Microsoft altså noget for at rette op på fortidens synder.

(1) For det første, så er der mange IT-afdelinger, som stadig bruger denne bekvemme funktion – også trods bedrevidende.

(2) For det andet, så er der mange IT-afdelinger, som har brugt funktionen, men som har “glemt” at rydde ordentligt op i SYSVOL.

Microsoft har så nu valgt, at fjerne den uheldige funktion fra Windows med en sikkerhedsopdatering. Se Microsoft Security Bulletin MS14-025: “Vulnerability in Group Policy Preferences Could Allow Elevation of Privilege (2962486)”. Det løser (delvist) punkt 1.

Yderligere tilbyder Microsoft et script, som søger SYSVOL (lokalt fra en Domain Controller) igennem for “glemte” Group Policy objekter (GPO) med de sårbare GPP funktioner (leder efter CPassword i XML filer).

Det er godt tænkt!

Efterfølgende slettes de identificerede sårbare GPO’er – eller de specifikke GPP indstillinger – manuelt vha. Group Policy Management Console (GPMC). Det løser punkt 2.

Er alt så fryd og gammen?

Først og fremmest, så burde det efter min mening* aldrig være kommet så langt. En så usikker funktion burde være fjernet for længst – eller i bedste fald aldrig implementeret. Men der er formentlig mange årsager til dette, eksempelvis, at Microsoft i 2006 også overtog eksisterende PolicyMaker kunder. At tage funktionalitet væk fra brugere er sjældent populært.

Det er svært at undgå at bide mærke i sætningen: »This functionality is being removed because the password was stored insecurely.« Tak, men hvorfor gik der så lang tid? Det har været en “offentlig hemmelighed” i mere end 2 år (se referencer nederst).

Dernæst, så anbefaler Microsoft i KB2962486 en “workaround” til skift af adgangskoder for lokale administrator konto, som jeg ikke umiddelbart vil anbefale. Jeg mener, der findes et bedre alternativ til det ellers fine PowerShell-script.

Hvad gør vi så med de lokale Administrator konti?

Jeg ville undgå de mange script-forslag, som man finder rundt omkring på nettet (og i omtalte KB-artikel) og i stedet begynde her: “Solution for management of built-in Administrator account’s password via GPO“.

I den løsning er der tænkt over mange essentielle ting, såsom kryptering af data-in-transit, rettighedsbeskyttelse af data, unikke adgangskoder, nem administration og integration med Active Directory. Jeg har ikke reviewet koden og kan ikke stå på mål for løsningen som sådan, men den har et godt ry. Evaluer, test og rul ud.

Hvordan skal det gribes det an?

Hermed blot et forslag til handlinger i IT-afdelingen i forbindelse med den aktuelle opdatering:

• undersøg hvad de(n) nye opdatering(er) vil have af betydning i dit miljø
• test opdateringen i et testmiljø
• test og implementer en anden løsning til at styre lokale administrator konti
• test og implementer en anden løsning til at styre øvrige “afskrevne” (deprecated) GPP funktionaliteter (se KB2962486 for forslag)
• kør PowerShell scriptet fra KB2962486 som finder gruppepolitikker i SYSVOL, der indeholder “cpassword” værdier og husk at scanne backup GPO’er
• tag backup af de berørte GPO’er til et offline medie
• rul opdateringen ud i produktion
• slet alle de berørte GPO’er via GPMC

Noter, referencer og relaterede artikler

• Exploit credentials stored in Windows Group Policy Preferences (april 2012)
• GPP Password Retrieval with PowerShell (maj 2012)
• Exploiting Windows 2008 Group Policy Preferences – Expanded (juni 2012)
• Metasploit Meterpreter Modul
• Get-GPPPassword Redux (juli 2013)
• Using Group Policy Preferences for Password Management = Bad Idea (juli 2013)
• Why Passwords in Group Policy Preference are VERY BAD (november 2013)
• MSDN om cPassword og AES kryptering
• MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege
• MS14-025: Description of the security update for Group Policy Preferences for systems that have update 2919355 installed (13. maj 2014)
• MS14-025: Description of the security update for Group Policy Preferences for systems that don’t have update 2919355 installed (13. maj 2014)

*Alt hvad jeg skriver, er for egen regning og mine synspunkter kan selvfølgelig ikke tillægges nogen virksomhed, organisation eller 3. part, som jeg (midlertidigt) måtte være, eller har været, associeret med eller på anden måde engageret hos.