CAn eMudhra har fått ett antal utfärdande CA komprometterade. Det innebär att vem som helst kan skapa falska certifikat som ser ut att komma från eMudhra. Problemet är väldigt allvarligt och kräver mycket kraftfulla åtgärder. Det som vi dock kan se är att infrastrukturen kring PKI och certifikat har fungerat väl vid denna incident. CA-certifikaten har blockerats av de stora webbläsarleverantörerna. Därmed kommer certifikat utfärdade under dessa CA:er att underkännas av webbläsare som omfattas av blockeringen. Certificate Transparency bidrar dessutom till att upptäcka obehörig certifikatutfärdning, men bara för de applikationer som faktiskt tittar i loggarna. CT är alltså ingen garanti för att alla förfalskade certifikat upptäcks. Detta gäller om man använder någon av de större webläsarna. Om man istället har byggt en egen applikation, eller använder curl eller andra verktyg kan man fortfarande vara utsatt för en stor risk.
Två av de komprometterade CA:erna var avsedda för kodsignering, vilket innebär en risk att skadlig programvara kan förses med signaturer som accepteras av system som fortfarande litar på dem. Webbläsarnas krav på Certificate Transparency skyddar inte normal kodsignering, så skyddet är beroende av att systemen får och tillämpar uppdaterade spärrar. Dessutom saknar många produktionssystem kontakt med internet och därmed möjlighet att automatiskt uppdatera spärrinfo, och kanske till och med har spärrkontroll avslaget av den anledningen.
Det som är spektakulärt i detta fall är att de har skapat privata nycklar som är helt galna. De har använt en krypteringsalgoritm som heter ECC-P384, det innebär att den privata nyckeln bör vara ett helt slumpmässig tal som är ca 116 siffror stort (decimalt), eller 384 bitar som man säger på ”kryptografiska”. De har skapat privata nycklar med värdena, håll i er nu… 4, 56, 66, 115, 155, 156, 230 samt 237. Det är alltså åtta nycklar där minst de första 376 bitarna av 384, är nollor… Till och med de 381 första bitarna i fallet där nyckeln är 4. Det här är så spektakulärt att man inte ens kunde förställa sig att något sådant skulle kunna hända, men nu har det hänt, och det väcker en massa frågor om hur de skapar sina nycklar. Policys, rutiner och ceremonier ÄR bra att ha i sin PKI…
Vad vi kan se i Certificate Transparency Log, är att inga legitima certifikat är utfärdade från dessa CA’s, dock är det naturligtvis så att den som eventuellt utfärdat falska certifikat INTE har publicerat dem på CT-loggarna. Till exempel de testcertifikat som finns på en av länkarna nedan. De testsidorna har förfalskade certifikat.
Vad behöver ni göra?
- Kontrollera era webläsare på https://emudhra.we-have-a-problem.com/, där finns testsidor att gå in på. De har förfalskade certifikat och din browser bör vägra.
- Se till att OS och browsers är uppdaterade.
- Kontrollera om just ert OS har kommit med en uppdatering, vissa linuxdistributioner halkar lite efter.
- Kontrollera era övriga applikationer som eventuellt har egna trust stores. Ta bort tilliten till de aktuella certifikaten.
- Kontakta era leverantörer och be dem verifiera att de har kontroll på problemet.
- Kontrollera att alla ”offline” system, som inte kan hämta spärrinfo automatiskt, blir uppdaterade.
- Det finns mer info av med teknisk natur på en av länkarna nedan.
Det mest häpnadsväckande är att nycklarna över huvud taget kunde skapas, godkännas och tas in i den globala tillitsinfrastrukturen. Nycklarna var matematiskt korrekta, certifikaten var korrekta och signaturerna var korrekta. Ändå var säkerheten i praktiken obefintlig.
Det säger något väsentligt om digital tillit. Vi kan ha världens bästa kryptografiska algoritmer, men de hjälper föga om vi inte hanterar de mjuka frågorna. Och kanske ännu viktigare: att någon faktiskt följer upp.
Mer information finns på dessa länkar, informationen på länkarna uppdateras över tid:
https://emudhra.we-have-a-problem.com
https://ctlogs.dev/blog/emudhra-ca-compromisea
För att citera artikeln på arstechnica – Bonkers!
Författare: Martin Juhlin