jekob heidelberg bloghoved

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.

Illustration: Privatfoto

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

*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.

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Mogensen

Jeg erindrer hvordan jeg tilbage omkring år 2000 med vantro så de "features", der gjorde ILOVEYOU virusen mulig.

Men jeg kunne forstå at mange Windows administratore dengang havde fundet det utrolig smart at de sådan kunne fjernstyre en masse klienter ved at sende VBscript til dem i email.

  • 5
  • 0
Jakob H. Heidelberg

Hej Peter,

Nu lægger du vel ikke op til en Windows vs *nix krig her, vel? Hehe ;-)

Til den del må jeg bare sige "for the record", at alle OS'er har - og har haft - deres "features". Begge har ligeledes deres fordele og ulemper. Jeg er ikke religiøs, heller i forhold til operativsystemer, og anvender selv et bredt udsnit, privat og professionelt, fra Tails, Ubuntu, MintLinux og Kali over MacOS og FreeBSD til alle moderne Windows afarter, klient og server.

ILOVEYOU-virussen var ganske rigtigt et kreativt udformet VBScript, men alene at bebrejde VB Scripting Engine den konkrete virale effekt - og f.eks. ikke f.eks. brugerne som klikkede på disse scripts, øh "kærlighedsbreve" eller Outlooks (Express) måde at håndtere vedhæftninger - det synes jeg ikke umiddelbart, at man kan. Det er i hvert fald lidt den med "i bagklogskabens klare lys" - men jeg vil bestemt ikke udelukke, at du allerede havde lugtet lunten tilbage i 2000'ish.

Selv var jeg dengang fuldstændig forelsket og forgabt i VBS. Så jeg må indrømme, at jeg læste koden med stor iver og blev yderligere inspireret. Jeg havde ikke tænkt tanken, at folk bare ville eksekvere den (klartekst) kode, som man sendte til dem. Sikke muuuuuuligheder ;-) Og ja, her er vi tilbage til snakken om funktionalitet kontra sikkerhed!

Det er nok sådan, at systemer, services og applikationer (generelt) har tendens til med nye features at tilbyde funktionalitet, som man ikke helt kan gennemskue konsekvensen - eller alle mulige konsekvenser - af. Men forhåbentlig har "vi" løbende lært af "vores" fejl.

Konkret i forhold til GPP og kode-opbevaring i SYSVOL, så burde man nok have stoppet den tilbage da man købte DesktopStandard - hvis man var klar over problemet. For havde funktion været korrekt implementeret, så havde vi ikke stået her i dag :)

God dag.

mvh
/Jakob

  • 0
  • 4
Peter Mogensen

men alene at bebrejde VB Scripting Engine den konkrete virale effekt - og f.eks. ikke f.eks. brugerne som klikkede på disse scripts, øh "kærlighedsbreve" eller Outlooks (Express) måde at håndtere vedhæftninger - det synes jeg ikke umiddelbart, at man kan. Det er i hvert fald lidt den med "i bagklogskabens klare lys" - men jeg vil bestemt ikke udelukke, at du allerede havde lugtet lunten tilbage i 2000'ish.

Jeg havde faktisk (som en opgave) tilbage i min studietid i starten af '90'erne da MIME kom frem skrevet en MIME-reader, der kunne spawne eksterne viewere til at vise diverse mime-typer.
Jeg kan huske vi jokede lidt om vi ikke skulle mappe "application/x-shell-script" eller lignende til en shell som "viewer" ... Det var kun sjovt fordi vi alle tænkte "Hvem pokker kunne da finde på det?".
... det fandt jeg så ud af 7-8 år senere.

Og nu var problemet jo heller ikke "bare" at VB-script kunne eksekveres direkte fra email-klienten.
Man havde jo også gået gennem store anstrengelser for at skjule den mekanisme der afgjorde hvilken viewer der blev startet fra brugerene. I Outlook var det jo ikke MIME-typen, men filens "extension"... som man jo havde valgt at skjule for brugerne. Så alm. brugere havde faktisk ikke rigtig den store chance for at regne ud hvad der var på vej til at ske.
Det at skjule extensions var jo heller ikke komplet. Brugerene så dem jo engang imellem og var godt klar over at .TXT var en harmløs tekst-fil.
Men når Outlook skjulte den egentlige extension på en fil ved navn "ILOVEYOU.TXT.VBS" ... så var brugerne prisgivet.

... og så var der så vidt jeg husker mindst en version af Outlook, der fik eksekveret VB-scriptet blot man markerede mail'en i folder-oversigten. Man skulle ikke eksplicit åben den og læse den.

Jeg mener ikke rigtig at jeg er "bagklog" her ... det var et relativt utilgiveligt design.

  • 6
  • 0
Jakob H. Heidelberg

Hej Peter

Jeg må indrømme 2 ting. For det første husker jeg ikke detaljerne omkring ILOVEYOUs funktioner. Jeg tror nu ikke, at lige den udnyttede Outlook Preview bug'en. Det kan undersøges, men "why bother", det var vist bare et eksempel :)

For det andet, så var jeg dengang mere i mindset'et "Windows administrator" end "sikkerhedsspecialist". Det er 2 forskellige måder at se tingene på, som dog med tiden er gledet tættere på hinanden.

Du har nok haft de briller på før mig. Way to go!

mvh
/Jakob

  • 0
  • 0
Peter Mogensen

For det første husker jeg ikke detaljerne omkring ILOVEYOUs funktioner.

Det gør jeg heller ikke... jeg kan se at jeg fik fil-navnet lidt forkert.

Men jeg husker også at der faktisk var en sekretær, der blev ramt af den, hvor jeg arbejdede, hvorefter en af medarbejderne satte sig for at finde den "inficerende" email ved at greppe hele mail-serveren igennem efter strengen "ILOVEYOU".
Lidt senere kom han triumferende tilbage og pegede på den mail hvori det stod ... blot for at opdage at det var 8 tegn midt i en kæmpe base64-klump, der tilfældigvis matchede. :)
Sådan er sandsynlighedsregning så pudsigt.

  • 1
  • 1
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize