Den 19 september 2011 begärdes den holländska certifikatutfärdaren DigiNotar i konkurs, dagen efter förklaras de bankrutt. Två månader tidigare hade man loggat in på en av sina maskiner för att undersöka varför en daglig kontrollrutin hade slutat fungera. Rutinen jämförde utfärdade certifikat på CA-servrarna med beställda certifikat i sitt affärssystem. Tänk dubbel bokföring: debet och kredit ska vara lika stora. När rutinen startades igen visade det sig att antalet utfärdade certifikat vida översteg antalet beställda. Hundratals certifikat hade utfärdats av en okänd inkräktare.

Black Tulip DigiNotar Intrusion Investigation

Så slutade och började historien om intrånget hos DigiNotar. Idag visar deras hemsida bara ett kort meddelande om att Ministry of the Interior and Kingdom Relations kommer att tillse att CRL och OCSP-tjänsten är tillgänglig till 2015 så att de certifikat som utfärdades av inkräktaren inte kan missbrukas.

En stor del av intrånget utreddes av det holländska säkerhetskonsultföretaget Fox-IT med början den 30 augusti 2011. Den 5 september släppte de en preliminär rapport (pdf) till allmänheten. I fjol, den 13 augusti 2012, släpptes slutrapporten (pdf) på 101 sidor. Jag är med andra ord nästan ett år efter men jag har å andra sidan aldrig utgett mig för att vara snabb.

Vid intrång i stil med det här är jag intresserad av:

  1. Hur kom de in från första början?
  2. Vad gjorde de när de väl var inne?
  3. Hur fick de ut stöldgodset?
  4. Hur upptäcktes de?
  5. Hur agerade företaget?
  6. Vad var konsekvenserna för företaget?
  7. Vem var inkräktaren?

Sammanfattning

En ensam, ung, politiskt motiverad, iransk hacker bröt sig in via ett känt säkerhetshål i en webbfrontad CMS. Arbetade sig vidare in i nätverket med hjälp av svaga lösenord, otillräckliga brandväggsregler och dåligt härdade servrar; totalt hade 20 servrar hackats. Väl inne i det inre nätet där CA-programvara och hårdvarusäkerhetsmoduler med rotnycklar hölls utfärdades hundratals bedrägliga certifikat som sedan slussades ut till ett script på en webbserver i DMZ. Intrånget upptäcktes när ett kontrollscript (som hade varit avstängt en period) startades och visade att flera okända certifikat hade utfärdats. DigiNotar försökte först mörka intrånget trots att de visste att åtminstone ett bedrägligt certifikat hade använts i en attack. Efter att nyheten briserade tog man in konsultfirma som avtäckte ett omfattande intrång, trots varierande tillgång till loggar. Loggarna i den centrala brandväggen var instrumentala i utredningen. Historien slutar med att DigiNotar begärs i konkurs sedan samtliga stora webbläsare har tagit bort deras rotcertifikat.

Analys

I stället för att bara avsluta analysen med föreslagna rekommendationer har jag valt att ha dem insprängda i texten. Får se efter hur det känns.

Hur kom de in från första början?

En portscan som Fox-IT genomförde i mitten av september visade att DigiNotar hade nästan 90 webbservrar tillgängliga från internet (s. 20). En ganska fet attackyta med andra ord och därför är det inte överraskande att en webbserver i DMZ (dmz-ext-net) utgjorde det första brohuvudet. Minst två av webbservrarna körde sårbara versioner av DotNetNuke (s. 23) och sannolikt var det ett remote file upload-exploit från januari 2010 som användes. Notera att det upptäcktes nästan ett år tidigare… DotNetNuke har ingen fantastisk säkerhetshistorik.

Här är en skiss över DigiNotars nätverk från rapporten, den är baserad på intervjuer med personalen, inte genom att verifiera brandväggsreglerna (s. 70). Angriparens väg in till CA-servrarna är utmärkt med röd pil. Intrånget var dock inte riktigt så kirurgiskt, totalt hade åtminstone 20 servrar hackats (s. 56).

DigiNotar network by Fox-IT

Med säkerhetshålet laddades ett webshell (ASPXSpy av allt att döma) upp som settings.aspx för att få fotfäste i DigiNotars dmz-ext-net. (s. 23, 48) Titta på Ryan Kazanciyan från Mandiant när han pratar om webshells på OWASP AppSec DC 2012 om du inte är bekant med dem. Ett webshell är en programfil med server-sidekod (PHP, ASP, Java, etc) som ger åtkomst till filsystemet, möjlighet att starta program, ladda upp filer och liknande funktioner på webbservern.

DigiNotar hade tagit bort en mängd loggfiler från webbservern strax innan intrånget eftersom diskutrymmet på servern började lida. (s. 24) Rotera alltid loggar, även på IIS, om det inte är möjligt att skicka dem vidare, självklart även på Apache HTTP Server.

F-Secure konstaterade i ett blogginlägg den 30 augusti 2011 att DigiNotar hade råkat ut för ett par defacements redan 2009(!) som fortfarande inte hade hanterats (läs: upptäckts). Av utseendet att döma är det dock automatiserade attacker och de hade sannolikt inget med de bedrägliga certifikaten att göra.

Något som hade drivit mig till vansinne om jag jobbade på DigiNotar är…

Så, inkräktaren har kontroll över en webbserver i ett yttre DMZ genom att ladda upp ett webshell via en publik remote file include i DotNetNuke.

Vad det verkar så använde DotNetNuke en databasserver som stod i office-net och därför var åtkomlig från webbservern i dmz-ext-net över SQL Servers standardport 1433/tcp. (s. 29) Inloggningsuppgifter till databasservern togs möjligen från DotNetNukes connection string i web.config. (s. 29, 49, 70) Det är oklart hur det gick till men ett program för att tunnla Remote Desktop från databasservern i office-net till webbservern i dmz-ext-net och därifrån till internet laddades upp och kördes (s. 29). Möjligen användes xp_cmdshell på databasservern för att köra programmet.

Användaren på databasservern var med i operativsystemets lokala administratörsgrupp (s. 49), så nu var inkräktaren inloggad som administratör med Remote Desktop på en databasserver i office-net.

Grundregeln är att servrar i DMZ inte ska ha någon åtkomst alls till de interna näten. Ett intrång i DMZ ska innebära begränsad skada, det är något man ska klara av. Det är nästan alltid möjligt att designa system så att grundregeln inte behöver brytas men tyvärr är det vanligt med webbservrar som behöver ansluta till servrar i de inre nätverkssegmenten. Det är inte alltid man får bestämma själv. Om så är fallet måste åtkomsten vara väl avgränsad. Alla åtta principer från Saltzer & Schroeder ska övervägas. I onödigt komplicerade… förlåt, moderna, system är det tyvärr svårt vilket jag har klagat över tidigare.

Nästa steg är in i det säkra nätet där CA-servrarna finns, det är inte klart hur det gick till. (s.70) Första tecknet på att secure-net hade ägts var att brandväggens gränssnitt mot det nätet började droppa packets på vanliga portar (80, 139, 443, 445) från en av servrarna där. (s. 31) Förmodligen scannades hela subnätet och brandväggen med det. Av okänd anledning så har inte denna server undersökts vidare av Fox-IT så det är oklart hur intrånget i den först skedde. Oavsett, scan av subnät gjordes klockan ett på morgonen den 1 juli. (s. 31) Tio timmar senare gjordes den första lyckade autentiseringen som domänadministratör på en annan server i secure-net. (s. 52)

I övrigt hittar jag inget om hur angriparen tog steget från office-net till secure-net. Utifrån de verktyg som hittats på servrarna rör det sig dock om de vanliga metoderna: dumpa hashar, cached credentials och lsass; knäck lösenord om du behöver (mimikatz plockar ut dem i klartext, pass-the-hash nöjer sig utan att de knäcks). (s. 96-101) De hittade t o m tecken på att Cain & Abel hade använts för att stjäla kerberosbiljetter och NTLM-hashar i en MITM-attack. (s. 50) Sannolikt fanns flera öppningar i brandväggen mellan office-net och secure-net.

Vad gjorde de när de väl var inne?

Utfärdade certifikat som om deras liv hängde på det. Det var dock något som krävde en del arbete och otaliga misslyckanden. Sen gick det som på räls.

DigiNotar använde RSA Certificate Manager (RSA CM) för att hantera sina CA (s. 38) och Thales nCipher netHSM 500s (s. 52, 54) för att lagra de privata rotnycklarna. För att kunna signera ett certifikat krävdes åtkomst till en aktiverad, privat nyckel i HSM:en. För att aktivera nycklar krävs (1) fysisk access, (2) ett smartkort och (3) en pinkod. (s. 19) Vår inkräktare hade förstås inget av detta.

Som ”tur” var så behöver nycklar vara aktiva över tiden för att kunna skapa och signera CRL:er samt svar från OCSP-tjänsten; uppgifter om vilka certifikat som är revokerade måste förstås signeras av utfärdaren. Vad det verkar så tolkar Fox-IT detta som att smartkort ”satt i” över tiden (s. 45) men enligt uppgift från en person med viss insyn i netHSM 500s (tack Jesper) behövs bara smartkortet för att aktivera nyckeln, det behöver inte sitta i.

Av någon anledning misslyckades inkräktaren med att utfärda certifikat via webbgränssnittet till RSA CM. Vederbörande valde i stället att falla tillbaka på ett annat gränssnitt, XUDA eller XCert Universal Database API. XUDA är ett scriptspråk/API för att kommunicera med PKI-programvara (s. 51), exempelvis RSA CM.

Dagen efter upptäcks meddelandet från inkräktaren och fler certifikat upptäcks.

Ett par XUDA-script som använts för att utfärda certifikat återfanns på CA-servrarna. Det verkar som att experimenten med XUDA började den 2 juli, dagen efter angriparen verkade ha fått åtkomst till nätverket i fråga. (s. 51) Det är förstås ett tecken på rätt påtaglig flexibilitet hos inkräktaren, något som samme person är medveten om. Se längre ned.

Det framgår tyvärr inte av rapporten huruvida åtkomst till RSA CM krävde inloggningsuppgifter av något slag.

När man läser mellan raderna verkar inte RSA ha varit särskilt hjälpsamma i utredningen, exempelvis rörande XUDA-scripten. Jag gissar att det är en anledning till att processen som användes för att utfärda certifikat är något luddigt beskriven. Kanske anses säkerhetsbrister vara affärshemligheter.

Under ett par dagar utfärdades hundratals certifikat i flera omgångar.

Hur fick de ut stöldgodset?

Brandväggen tillät trafik från secure-net ut till 80/tcp i dmz-ext-net.

Samma webshell användes för att slussa ut filer, helt enkelt genom att man hade grafiskt gränssnitt på de inre CA-servrarna (Remote Desktop) och använde Internet Explorer för att ansluta tillbaka ut mot webbserverns webshell ute i dmz-ext-net. (s. 48)

Att låta trafik lämna ett högsäkerhetsnät så lättvindigt är nästan lika illa som att låta trafik komma in.

För några år sedan körde ASSA en kampanj om att gardera sig mot vad de kallade utbrott. Med en funktion i deras senaste låsmekanism ASSA 2000 Evo (som hade vissa säkerhetsproblem) kunde man koppla ur låsvredet på insidan så att en nyckel behövdes för att ta sig ut. Tanken var att en tjuv bröt sig in i huset genom att panga en ruta på balkongen, tog den tunga teven i famnen, låste upp en dörr och promenerade ut.

Intrång hos en CA av den här magnituden är faktiskt märkvärdigt, det måste man erkänna.

Med skydd mot utbrott skulle tjuven i stället vara tvungen att lirka sig ut med teven via det krossade fönstret vilket inte alls är lika attraktivt. Jag är lite skeptisk till hur effektivt detta är i den fysiska världen men samma princip gäller tveklöst i den digitala. Rich på Securosis illustrerar detta föredömligt med sin Data Breach Triangle som är lite av en light-variant av Lockheed Martins mer kända, och underskattade, Cyber Kill Chain.

Sammantaget var det en barnlek att smuggla ut de bedrägliga certifikaten. Det hade till och med automatiserats. (s. 52)

Hur upptäcktes de?

För sent.

Det första tecknet inne på DigiNotar var som sagt när man åtgärdade problemet med det schemalagda kontrollscriptet den 19 juli och upptäckte att mängden utfärdade certifikat och mängden beställda certifikat var helt ur balans. (s. 37) Notera att förmågan att upptäcka sådana här problem fanns men att den var out of order när den väl behövdes. När den slutligen reparerades hade skadan redan skett. Huvuddelen av certifikaten hade slussats ut den 10 juli.

Mer om vad DigiNotar gjorde efter att de börjat misstänka ett intrång längre ned.

Nästa upptäckt, att bedrägliga certifikat verkligen hade använts för att angripa användare, spreds av en Gmail-användare den 27 augusti som stött på ett *.google.com-certifikat från DigiNotar. Google gick ut på sin blogg den 29 augusti och informerade om DigiNotar-certifikatet.

Gänget bakom Chrome hade oavsett anledning att vara nöjda sedan de infört certificate pinning i Chrome strax innan. Certificate pinning innebär i det här fallet att Chrome vet vilka CA som har rätt att signera certifikat för google.com. Om ett google.com-certifikat från någon annan, exempelvis DigiNotar, dyker upp så hissas varningsflagg, även fast utfärdaren är betrodd.

Eventuella tvivel kring om det rörde sig om ett äkta intrång eller inte skingrades nog när DigiNotar, dagen efter första upptäckten, hittade ett meddelande från inkräktaren bland kommentarerna i ett av XUDA-scripten. (s. 14) Det började relativt återhållsamt (jag tog mig friheten att lägga in en och annan punkt för läsbarhet, jag lämnar dock stavfel för att behålla känslan):

I know you are shocked of my skills, how I got access to your network. To your internal network from outside. How I got full control on your domain controller. How I got logged in into this computer. How I learned XUDA programming. How I got this idea to write such XUDA code. […]

Viss stolthet får man väl unna honom trots allt. Han känner sig dock manad att strö lite salt i såren och fortsätter:

[…] How I bypassed your expensive firewall, routers, netHSM, unbreakable hardware keys. How I did all XUDA programming without 1 line of resource, got this idea, owned your network accesses your domain controlled, got all your passwords, signed my certificates and received them shortly.

Intrång hos en CA av den här magnituden är faktiskt märkvärdigt, det måste man erkänna. Inkräktaren vill dock understryka sin egen fullkomlighet:

THERE IS NO ANY HARDWARE OR SOFTWARE IN THIS WORLD EXISTS WHICH COULD STOP MY HEAVY ATTACKS, MY BRAIN OR MY SKILLS OR MY WILL OR MY EXPERTISE.

Han avslutar med att visa att han trots allt är en stor person:

I know you’ll see this message when it is too late, sorry for that.

Hur agerade företaget?

Vad som hände innan Fox-IT kallades in beskrivs endast översiktligt så jag följer deras exempel.

Den 19 juli upptäcks att för många certifikat har utfärdats. Man påbörjar incidenthantering och de certifikat som kontrollscriptet hittat revokeras. Dagen efter upptäcks meddelandet från inkräktaren och fler certifikat upptäcks. Dessa revokeras den 21 juli och CA-servrarna stängs av över natten. Ett par dagar senare, den 25, tas konsulter in. Två dagar senare hittar de flera certifikat som revokeras. Då konstaterar även konsulterna att en server i DMZ samt en CA-server har tagits över. Den 28 juli märker man för första gången att en dator i Iran har verifierat ett certifikat (sannolikt via OCSP-anropet). (s. 14)

Den 29 augusti, två dagar efter att information om *.google.com-certifikatet från DigiNotar hade publicerats revokerades även detta. Notera här att DigiNotar vid det här laget i en månad har varit fullt medvetna om att bedrägliga certifikat har utfärdats och använts i minst en attack.

Google, Mozilla och Microsoft agerade snabbt från och med att certifikatet för *.google.com dök upp den 27 augusti och klippte DigiNotars rotcertifikat (plural) från sina webbläsare. Opera yrade först om att revokering av bedrägliga certifikat med hjälp av CRL och OCSP räckte för att hantera situationen. Efter att Fox-IT:s preliminära rapport kommit ut den 5 september ändrade de sig dock och fimpade DigiNotar helt.

Vad var konsekvenserna för företaget?

Företaget finns inte mer. En certifikatutfärdares affär bygger på att de är pålitliga, ett så här omfattande intrång är, och ska vara, ödestigert. Det betyder inte att motsvarande intrång i ”vanliga” företag ska ha samma resultat, det ska de nog inte. För två veckor sedan gav jag några exempel på hur aktieägarna reagerat på intrång. Tanken är att återkomma till temat framöver.

Intressant nog hänvisar förövaren själv (se nästa rubrik) till Vascos börskurs (DigiNotar var helägt av Vasco). Om intrånget hade någon effekt är det svårt att se, det hade varit en tydlig nedgång redan innan intrånget blev känt och viss återhämtning skedde efteråt.

Vasco stock price at intrusion being made public

Vem var inkräktaren?

Mindre än en vecka innan DigiNotar begärdes i konkurs lade den förmodade angriparen upp bekännelser på Pastebin. Det framgår att det ska vara samma förövare som vid hacket mot Comodo i mars samma år, ”Comodohacker”. Enligt utsago ska det röra sig om en 21-åring från Iran som sympatiserar med regimen. Attacken mot DigiNotar ska ha varit en attack mot Holländska staten för dess inblandning i folkmordet på bosniska muslimer i Srebrenica 1995.

En ensam, politiskt motiverad hacker med begränsade resurser, hög kompetens och ingen särskild relation eller åtkomst till företaget.

Lärdomar

Med facit i hand är det de ”vanliga” problemen som gäckar: svaga lösenord, programvara utan säkerhetspatchar, bristande loggning, bristande härdning, etc. Det är också sådana, tråkiga lessons learned som Fox-IT presenterar i rapporten (s. 68-69). En av dem står dock ut:

Use data that can be accumulated by the OCSP responder to check if unknown serials are being validated.

Det kanske är standardförfarande på en CA men jag kan inte påminna mig att jag har hört om det förut.

Omfattande intrång i den här stilen bygger nästan alltid på att en serie av ”vanliga” sårbarheter utnyttjas. Det är ovanligt att sådana här serier dissekeras publikt och eftersom det är ett så tydligt fall är det värt att poängtera. Naturligtvis hade inte angriparen en utstakad väg till målet ”signerat wildcard-certifikat” när intrånget började. Det började med en gammal version av DotNetNuke med publikt exploit tillgängligt, därifrån visade det sig att det var möjligt att nå en databasserver, inloggningsuppgifter fanns läsbart i en fil. Databasanvändaren var lokal administratör, detta ledde till … och så vidare.

Det är möjligt, nästan sannolikt, att det hade funnits någon annan väg framåt för vår inkräktare om det t ex inte gick att nå just den databasen eller att filen inte var läsbar. Kanske hade det gått att dumpa lösenord med mimikatz, kanske hade det gått att nå en mailserver i stället. Vem vet. Det är det här som avses med defender’s dilemma: det är betydligt svårare att se till att alla säkerhetshål är stängda än att hitta ett som inte är det. Den totala attackytan i ett nätverk, i synnerhet från insidan, är enorm.

Är det ens ekonomiskt försvarbart att försöka försvara hela nätverket? Borde man kraftsamla till vissa delar bara?

Även det här finns det anledning att återkomma till i mer detalj. Det får dock bli i ett separat inlägg.

Något som hade drivit mig till vansinne om jag jobbade på DigiNotar är: hur hade det gått om jag hade fått arslet ur och fixat det där schemalagda kontrollscriptet för två veckor sedan?

Tidslinje

Översiktlig tidslinje som beskriver vad som hände.

  • 17 juni, intrång i det yttre DMZ
  • 17-29 juni, intrång i kontorsnätet
  • 1 juli, intrång i det inre nätet
  • 2 juli, första försöket att skapa certifikat
  • 10 juli, lyckas skapa certifikat
  • 19 juli, daglig(?) kontrollrutin upptäcker falska certifikat
  • 22 juli, sista koppling från inre nät mot internet
  • 24 juli, sista spåret i yttre DMZ
  • 25 juli, it-säkerhetskonsulter tas in
  • 27 augusti, nytt certifikat (*.google.com) används för MITM-attack i Iran
  • 29 augusti, browserleverantörer börjar klippa DigiNotars rotcertifikat
  • 30 augusti, Fox-IT tas in
  • 2 september, interimrapport klar
  • 5 september, interimrapport publiceras, DigiNotar polisanmäler
  • 14 september, motsvarigheten till PTS drar in DigiNotars rätt att signera e-legitimationer
  • 19 september, DigiNotar begär konkurs
  • 20 september, DigiNotar förklaras bankrutt