Smartkort i en Microsoft Windows labbmiljö

0 kommentarer
Hej kära läsare, Peter Swedin här igen. En ”fellow geek” noterade häromsistens att jag använde ett .NET smartkort när jag skulle logga in på HTPC:n. Efter de vanliga kommentarerna om paranoida säkerhetsnördar ville kompisen veta hur man bygger en smartkortsimplementation i labbmiljö. Jag svarade att jag skulle posta ett blogginlägg om saken. Eftersom det rör säkerhet, PKI, labbande och annat som jag brinner för passar det här på SÄK-bloggen, så här kommer en allmän snabböversikt. Mycket nöje och labba på där ute!
OBS! Detta är som sagt i en labbmiljö! Skall man införa det här i en enterprise-miljö kommer helt andra drift- och säkerhetshänsynstaganden med i bilden!
Utrustning:
1.       Minst en domänkontrollant (Windows 2008 R2 är min favorit)
2.       En  Active Directory Certificate Services maskin. (Vill man snåla i labbmiljön, kan man köra den på DCn. OBS! det är strängeligen förbjudet att snåla på det sättet i en skarp produktionsmiljö av uppenbara skäl….)
3.       En klient. (Windows 7 eller Vista är enklast. Det funkar ypperligt på Mac OS X också, men i så fall behöver man börja betala mig konsultarvode… J)
4.       Minst en smartkortsläsare. (Den billigaste jag har hittat är PC Twin)
5.       Minst ett smartkort (.NET smartkort är busenkla eftersom de följer PKCS#11 standarden, Smart Card Minidriver specifikationen och CSP:n följer med i Win7/Vista)

Gör så här

Efter att man har installerat ovanstående utrustning, alltså byggt domäninstallerat CA och så vidare är det dags att utfärda certifikat.
Först och främst skall man ge ut ett Kerberos Authentication certifikat till DCn (se mitt tidigare inlägg om Kerberos och dess sårbarheter. Se till att slå på de GPO:er som rekommenderas där också).
Sen är det dags att utfärda ett smartkortscertifikat till en användare.  I en enterprise-miljö använder man givetvis en enterprise-lösning, exempelvisForefront Identity manager 2010vSEC:CMSNet ID Card Portal eller motsvarande men i labbmiljön kan vi snåla genom att använda webbapplikationen som följer med i CA-rollen i Windowscertifikatservern (med andra ord, installera IIS och Certsrv på CA:n). För att göra det så enkelt som möjligt, konfigurera smartkortscertifikat-template:ts ACL  så att användare i domänen har rätt att begära smartkortscertifikaten (enroll rättigheter till Domain Users). Glöm inte att lägga till det template:t som ett ”new certificate to issue”, annars dyker det inte upp som ett valbart alternativ iwebbapplikationen (https://CA-hostnamn.domännamn.toppdomän/certsrv). Därefter surfar man till webbapplikationen, begär ut ett smartkortscertifikat och sen kan man använda det till att logga in på domänen. 

Häpp! Svårare an så var det inte!  För en fullständig installationsguide med skärmdumpar och handhållning, tveka inte att höra av er! Undertecknad står mer än gärna till tjänst.

/Peter Swedin

Osäkra laddningar av dynamiska bibliotek

0 kommentarer
De senaste dagarna har Internet surrat om att ett stort antal program är sårbara för en så kallad 0-day sårbarhet (zero-day eller oh-day [:deɪ]), dvs. en sårbarhet som hittills varit okänd och saknar uppdatering (patch).  Bland annat har HD Moore (mest känd som skapare av Metasploit attack-ramverk) noterat ett 40-tal applikationer är sårbara. Acros Security meddelade att dom kände till åtminstone 200 sårbara applikationer.

Den senaste informationen från Microsoft är att dom inte tänker lösa problemet (!), i alla fall inte just nu. Istället det är upp till varje leverantör att uppdatera och skydda sina program. Microsoft kommer kanske att fixa denna bugg i ett framtida servicepack, men har inte gett några garantier för detta.

Jag har undersökt grunderna till problemet och har kommit fram till att det är inte något nytt problem i sig, utan problemet har varit känt i sak ganska länge (Georgi Guninski rapporterade om det 18 September 2000) och säkerhetsimplikationerna har rapporterats in till Microsoft för 6 månader sedan av Taeho Kwon. Kwon och hans handledare Zhendong Su har skrivit ett papper [Automatic Detection of Vulnerable Dynamic Component Loadings] som presenterades på en internationell konferens i februari i år.



Hur det går till
Både Windows och Linux letar efter dynamiska bibliotek (.DLL respektive .SO) i en speciell ordning, beroende på hur man har konfigurerat systemet. Om en attackerare kan få programmet att ladda sitt skadliga bibliotek (DLL) istället för det riktiga biblioteket så körs attackerarens kod istället för den ligitima applikationens kod (och om attackeraren är "snäll" så kan han skicka funktions-anropen vidare till det riktiga biblioteket för att bibehålla funktionaliteten i programmet som attackeras).

Vissa program letar efter sina bibliotek i samma katalog som den filen man försöker öppna finns i, så ett attack-scenario kan se ut på det här sättet:

  1. Alice (användaren) får en .zip-fil av Mallory (angriparen) innehållandes ett MS Word dokument och en .dll-fil
  2. Alice packar upp zip-filen till en katalog
  3. Alice dubbel-klickar på Word-filen för att öppna den
  4. MS Word startar, letar efter sina .DLL filer
  5. MS Word hittar en av sina .DLL-filer i samma katalog som dokumentet dvs. den .DLL-fil som Mallory skickade med i .ZIP-filen. Detta bibliotek innehåller den skadlig koden.
  6. MS Word kör nu kod från Mallory

Vad du kan göra
Som jag har nämnt ovan så kommer Microsoft inte att lösa grundproblemet i närtid. Vad du som användare och/eller system-administratör kan göra är att hålla ett öga på framtida patchar.

Sitter du i en organisation som har egenutvecklad mjukvara kan du undersöka ifall något av de egenutvecklade programen är sårbara för denna attack och i så fall se till att dom blir fixade. HD Moore har släppt ett verktyg (här kan man läsa ett blogg-inlägg om detta samt bakgrunden till problemet) för att detektera program som laddar dynamiska bibliotek på ett osäkert sätt. Man kan även använda Microsoft Sysinternals Procmon och Filemon för att detektera osäkra laddningar av DLL-filer.

/Michael Boman

Anonymitet på nätet med Google Sharing och Off The Record Messaging

0 kommentarer

Moxie Marlinspike - känd från sina SSL-hack - hade en intressant föreläsning på årets Black Hat-konferens. Under titeln "Changing Threats To Privacy: From TIA To Google" summerade han historien bakom kryptering och anonymitet på internet.

Moxie berättade att i början av webbens historia pågick det ett krig mellan kryptografi-förespråkare och USA:s regering. Kryptofgraferna ville att vem som helst skulle kunna skicka krypterade meddelanden, något som USA:s regering starkt avvisade. Om fri kryptografi skulle finnas tillgänglig skulle hela samhållet helt enkelt kollapsa, menade regeringen, och målade upp en rejäl hotbild som byggde ungefär på följande resonemang:

1.Anonyma digitala betalningar skulle florera

2.Det skulle bli omöjligt med övervakning

3.Vilket skulle leda till att det blev omöjligt att beskatta något

4.och tillslut skulle samhället kollapsa

Man gick så långt att man likställde export av krypteringsalgoritmer med vapenexport. Det var, ur en straffrättslig synvinkel, lika illa att sälja bomber till Kina som att skicka Zimmermanns PGP-algoritm för att kryptera e-post till sin kusin i Tyskland.

Denna kamp höll på ända fram till år 2000, då den dåvarande Clintonadminsitrationen gjorde det lagligt att exportera kryptoalgoritmer igen. Det verkade som att kryptograferna hade vunnit!

Men vad har då hänt med kryptering på webben i praktiken nu 10 år senare? Kryptering möjliggör att vanliga användare kan handla säkert med sitt kontokort över nätet, eller logga in på facebook utan att någon kan sniffa reda på ens lösenord. Men för övrigt är anonymitet på nätet i stort sett obefintligt. Visserligen finns möjligheten att skicka krypterade mail, även i Tyskland, men digital övervakning är vanligare nu än någonsin.

Vad var det egentligen som hände?

Säkerhetsfolk och kryptografer förberedde sig på en fascistisk framtid á la "1984", något som aldrig inträffade. Vad vi istället fick var mycket mer subtilt, en värld där vi själva väljer att delge vår information till stat och företag - helt frivilligt - för att inte stå utanför samhället!

Ta följande exempel: Om det skulle bli lagstadgat att alla medborgare var tvungna att bära en apparat som gör det möjligt att både spåra och avlyssna dom, oavsett var de befann sig, skulle gissningsvis få tycka det var en bra idé. Men trots detta har nästan alla en mobiltelefon idag, något vi själva har valt!

Vi har den för att det är smidigt, men också - som alla som glömt sin mobil hemma en dag vet - för att man känner sig lite utanför om man inte har en. Vi planerar inte längre "vi ses där då" utan det heter "vi ringer efter jobbet".

Google's roll

Googles affärsmodell är övervakning, och det är något som de är fenomenalt duktiga på! Idag övervakar och lagrar Google nästan allt om dig. Din IP, dina sökningar, data du skickar och tar emot, vilka GPS-koordinater du befann dig på när du gjorde det, vem du jobbar för, vilka du umgås med, och snart även din sjukjournal. Problemet är att det börjar bli svårt att undvika Google.

Ett exempel på detta som Moxie tog upp är adblock plus, en tilläggsmodul till firefox som med hjälp av filter gör det möjligt att spärra innehåll från vissa domäner i syfte att slippa reklam. Eftersom det är ett hästjobb att sammanställa dessa listor, erbjuds även möjlighet att "prenumerera" på uppdaterade spärrlistor. En av dessa prenumerationslistor som cirkulerar är gjord för att slippa trackers och webbugs. I den listan står bland annat Google analytics, den idag största webb-trackern.

En dag var plötsligt Google analytics-filtret borta ur prenumerationslistan, och sidor med Google analytics laddades igen. Vad var det som hade hänt? Den som är konspiratoriskt lagd hade gissat att det skett någon form av övertalning där Google åkt ut till han som sköter prenumerationslistan med en portfölj pengar. Det var naturligtvis inte så det gick till, men det som hade hänt var att Google hade börjat lägga in lite ytterligare JavaScript-funktioner i sin tracker, funktioner som hemsidemakaren kunde använda. Eftersom i stort sätt alla redan inkluderar Google analytics-koden, kunde de ju lika gärna använda de utökade funktionerna som ingick. Resultatet blev att om man som besökare till hemsidan inte ville ladda Google analytics kod, kunde man heller inte ta del av hemsidan!

Valet om att använda Google eller inte har plötsligt fått helt nya dimensioner. Från att välja om man vill söka på nätet med dem eller altavista, eller om man vill använda hotmail eller gmail, står man idag inför valet att ta del av webben eller ej.

Hur kan man då ta tillbaka valmöjligheten, utan att riskera att stå utanför?

Svaret är GoogleSharing, en anonymiseringsproxy för alla Googles tjänster som inte kräver inloggning. Det funkar såhär:

Man installerar en plugin till firefox som analyserar trafiken som skickas från din browser. Ser pluginen att ett anrop görs till Google, strippas google-cookien i requesten, och skickas till en proxy. Proxyn innehåller flera olika identiter, och skapar en ny cookie som skickas till Google. Svaret retuneras till proxyn och skickas tillbaka till användaren. Dessutom sker all kommunikation med proxyn över SSL, för att ytterligare stärka anonymiteten.

Men mail då?

Här har vi som bekant redan möjlighet att kryptera korrespondens om vi vill, men om alla våra mail (eller i varje fall alla mail från eller till en gmail-adress) lagras hos Google uppstår problem även om de är krypterade. Om vår privata nyckel någon gång i framtiden skulle komma i orätta händer, blir plötsligt alla mail, från det allra första vi skickade, läsbara. Dessutom blir det väldigt svårt att förneka att man skrivit något om man skulle behöva det. Mailet är ju signerat med din privata nyckel!

Off The Record Messaging

OTR-Messaging löser problemet genom följande modell:

Istället för att använda varandras publika nycklar för att kryptera ett mail, använder man dem för att signera ett nyckelutbyte. Den gemensamma nyckeln används sedan för att kryptera mailet. Med i varje mail skickar man även en halv ny nyckel. Efter ett mailutbyte har båda parter en helt ny nyckel, och denna används istället för den gamla. Detta innebär att om en nyckel kommer på vift, kan den bara användas för att läsa ett meddelande, och inte samtliga som skickats.

Istället för att använda digitala signaturer för att signera meddelandet använder man något som kallas för Message Authentication Code (MAC), en signatur som är baserad på den gemensamt utbytta sessionsnyckeln. Eftersom båda parter har tillgång till signaturen, kan ingen hävda för en tredje part att den andra skrev meddelandet.

MAC:en ändras allteftersom kommunikationen fortsätter eftersom den hänger ihop med sessionsnyckeln. När en MAC blivit förbrukad, publicerar man den dessutom öppet för omvärlden, för att ytterligare göra det svårare att bevisa vem som skrivit ett meddelande i efterhand.

Dessa lösningar kan tyckas vara marginella, men det är ändå steg i rätt riktning mot att återta anonymiteten på ett alltmer övervakat internet.

Marcus Hartwig

Omegapoint Stockholm



Länkar:

Moxie Marlinspike - http://www.thoughtcrime.org/

GoogleSharing - http://www.googlesharing.net/

OTR - http://www.cypherpunks.ca/otr/


 

-”Hjälp! Nätet är trasigt!”

0 kommentarer
Så öppnar kompisen telefonsamtalet. Ja visst är det trasigt tänker jag i mitt stilla sinne med avsmak, dels över att få ett oviktigt icke-problem på halsen, dels över att min vän har mer rätt än vad han inser. (Kompisens problem visar sig vara en ethernet-kabel som hade halkat ur den trådlösa hemma-routern.)
Orden biter sig fast. ”Hjälp, nätet är trasigt”.  Vad är egentligen det här nätet egentligen? Beroende på vem man frågar kan det vara WAN, LAN eller kanske åtkomst till Facebook. Ja visst är ”nätet” trasigt men var sjutton skall man börja? För att bara ta ett fåtal exempel:
Vad sägs om WPA2. Förutom att man givetvis kan brute-force knäcka Pre Shared Keys (PSK) med hjälp av rainbow tables har vi hål 196 som möjliggör man-in-the-middle attacker. Eller vad sägs om de allt för många och opålitliga rotcertifikatsutgivare som kommer förinstallerade i operativsystem och webbläsare. Det gör att man i princip bör ha PKI som huvudsyssla om man skall kunna surfa på HTTPS sidor med någorlunda trygghet. Surfa ja, det är ju något som de flesta av oss gör dagligdags, men eftersom så få domäner använder DNSSEC utgör DNS cache poisoning ett hot mot alla oss som rör sig på nätet.
Där kom det där ordet igen. Nätet. Ett av de viktigaste protokollen på det stora nätet, alltså Internet, är Border Gateway Protocol. I korthet är det ett sätt för routrar på internet att utbyta routingtabeller. Det gör att paketen kommer fram dit de skall. Utan BGP inget Internet helt enkelt. Men BGP togs fram långt innan säkerhet var i fokus och många ISPer och Autonoma System (AS) implementerar inte BGP Security. Visst vore det tråkigt om halva Internet plötsligt skulle försvinna? Det torde ha en viss påverkan på världsekonomin….  
Det finns så många exempel på varför  ”nätet” är trasigt att det går att skriva hyllmeter om det. Det kanske jag skall göra men först tänkte jag surfa lite på nätet.
Surfa lugnt där ute men ta det inte för givet.
/Peter Swedin

Skräck och varnagel: Kerberos är sårbart för man-in-the-middle attacker!

0 kommentarer

På säkerhetskonferensen Black Hat i Las Vegas i förra veckan hölls en mängd intressanta föreläsningar. Många säkerhetsforskare visade upp sina senaste resultat och det var massvis av intressanta, skrämmande, roliga, och kittlande nyheter som spreds. Ett par föreläsningar fick nackhåren att resa sig och känslan av uppgiven skräck och förstämning spred sig bland de åhörande säkerhetsexperterna.

Här följer en sammanfattning av en av de föreläsningarna som jag gillade (och skrämdes av) allra mest.

Rachel Engel, Brad Hill and Scott Stender från iSEC Partners presenterade attacker mot Kerberos 5, ni vet det som gör att man kan logga in i Windowsdomänen, Open Directoryt, få Single Sign On mot SAP systemet, ja allt det där som gör att man får en och samma användaridentitet med rätt rättigheter, spårbarhet o.s.v.

Kerberos 5 kan som bekant växla kryptering och av bakåtkompatibilitetsskäl klarar protokollet av de gamla osäkra algoritmerna såsom DES och Microsofts exporterbara RC4.

Problemet kan konkretiseras med att det inte sker någon egentlig validering av domänkontrollanten (KDC Kerberos Key Distribution Center) eftersom klienten saknar en lista över sina domänkontrollanter, istället broadcastar klienten ut förfrågan och hoppas att det är rätt DC som svarar.

Vid vanlig lösenordsbaserad inloggning kan en angripare "i mitten" helt enkelt förfalska handskakningen och hävda att klienten bara klarar av en äldre och osäkrare krypteringsteknik, exempelvis DES. Specialiserade hårdvaruknäckare knäcker det kryptot inom några timmar och vips har angriparen offrets lösenord. Angriparen tar kontroll över offrets identitet.

Realistisk angreppsvektor mot smartkortsautentisering

Eftersom det inte sker någon egentlig servervalidering i standardkonfigurationen av Windowsdomäner uppstår det även problem vid smartkortsautentisering. Smarta kort är en stark form av 2-faktorautentisering med PKI i botten och vanliga x509 certifikat. Starkt och säkert, de privata nycklarna är skyddade i hårdvara på smartkortschippen. Men... sker ingen servervalidering av KDCn, ja då är den säkra (och säkert dyra) lösningen sårbar för "man-in-the-middle" attacker. Detta beror på att alla Windows XP, och defaultkonfigurerade Vista och Windows 7 klienter bara kontrollerar Server Authentication EKU:n i DCns domänkontrollantcertifikat. Problemet är att den EKUn följer med i både webserver-certifikat och i datorcertifikat. Det gör varje domänmedlem med ett sådant cert (alla datorkonton får automatiskt rätt att auto-enroll:a datorcertet) till en potentiell man-in-the-middle angreppsstation genom möjligheten att spoofa KDCns svar och signera det med sitt eget certifikat så att de verkar komma från en riktig DC.

Ungefär här hördes tunga suckar och kvävda stön bland den samlade åhörarskaran. Själv fick jag en molande huvudvärk. Det här är inte bra.

Attacken beskrivs utförligt i detta white paper. Den går i korthet ut på följande: Användaren loggar in, tror hon. Istället spoofar angriparen en KDC och med hjälp av ett användarkonto angriparen redan har kontroll över loggas användaren istället in som det hackade/knäckta/stulna/lurade kontot. Trojaner maskerade som vanliga uppdateringar installeras på den angripna klienten, PIN koden till kortet stjäls, användaridentiteten tas helt över och den ovetande användaren upplever bara att "det tog lång tid att logga in idag med både uppdateringar och omstart". Angriparen behöver bara iterera detta tills en identitet med tillräckliga rättigheter (tänk: Domain admin) har hittats och tagits över.

Hur skyddar man sig?

Det finns inga enkla genvägar, men här är de viktigaste:

- Uppgradera åtminstone en av domänkontrollanter till 2008R2.

- Uppgradera samtliga klienter till Windows Vista eller Windows 7.

- Uppgradera Issuing CAn till 2008R2
- utfärda nya DC certifikat av typen Kerberos Authentication till samtliga DCs.

- Har man kvar gamla 2003 DCs måste de gamla DC certifikaten tas bort..

Slå på följande grupppolicys

Computer Configuration\Administrative Templates\System\Kerberos
Policy: Require strict KDC validation = ON

Computer Configuration\ Policies \Windows Set-tings\Security Settings\Local Policies\Security Options

Network security: LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLM

Network security: Minimum session security for NTLM SSP based (including secure RPC) clients: and

Network security: Minimum session security for NTLM SSP based (including secure RPC) servers:

Require NTLMv2 session security

Require 128-bit encryption
Network security: Allow Local System to use computer identity for NTLM: Enabled

Network security: Allow LocalSystem NULL session fallback: Disabled

I en ren Server 2008R2 och Windows 7 miljö är det även en bra idé att försöka göra sig av med NTLM helt och hållet (OBS! Detta kan visa sig svårt rent praktiskt om man har gamla system i nätverket som använder sig av NTLM):

NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7


Introducing the Restriction of NTLM Authentication


Peter Swedin
Omegapoint Stockholm