„A nyilvános kulcsú infrastruktúra (PKI) a lehetők legjobbika, ha valaki egy üzenetet rejtjelezni, vagy annak hitelességét bizonygatni szeretné. Szimmetrikus kulcsoknál legalább két fél (küldő és fogadó) rendszeréről kell elhinni, hogy a titkos kulcs őrzésével nincsen gond, aszimmetrikus esetben már elég csak egyvalakiben bízni. Ez az egyvalaki lehet egy hitelesítés-szolgáltató (trusted root CA), de lehet egy PGP-s, GnuPG-s kapcsolat is, a lényeg, hogy a titkos kulcs valóban titokban maradjon. Onnantól kezdve, hogy a titkos kulcs kitudódik, hirtelen nagy hatalomra tesz szert a támadó. Ez igaz akkor is, ha a „trusted third party” alapján működő CA-kat nézzük, és akkor is, ha a „web of trust” szerint szerveződő PGP kliensek az érintettek.
A DigiNotar CA kapcsán 2011. augusztus 29-én zajlott le a holland „mohácsi vész”: kitudódott, hogy 2011. július 10-e óta illetéktelenek is használták a tanúsítványkiadó rendszert (az F-Secure elemzése szerint deface támadások már korábban is történtek), legalábbis ekkori dátummal jelent meg az első „rouge certificate”. A feltehetően iráni támadó (aki a ComodoHacker nick alatt írt a pastebin.com oldalra) a Fox-IT elemzése szerint 531 tanúsítványt adott ki – köztük a *.google.com, login.yahoo.com, twitter.com, *.microsoft.com SSL szerverét is -, amelyekkel man-in-the-middle támadást végrehajtva értékes adatokat (pl. Google accounts) szerzett. Sikerült „code signer” tanúsítványt is kibocsátania (aláírt calc.exe volt rá a bizonyíték), majd állítólag egy Windows update csomaggal is kedveskedett az áldozatainak. A böngészők azonnal frissítettek (törölték az összes DigiNotar tanúsítványt a tárukból), a holland kormány állami felügyelet alá vonta a hitelesítés-szolgáltató e-köziges tanúsítványkibocsátóját (merthogy a közigazgatás számára is rengeteg SSL-szerver tanúsítványt adott ki), a VASCO tulajdonát képező DigiNotar azonban végül az incidens napvilágra kerülését követő 22. napon, 2011. szeptember 20-án csődöt jelentett.
…
Néha azonban még csak hacker sem kell, elég figyelni a hitelesítés-szolgáltatók honlapját is. A Certigna üzemeltetői egy pillanatra hagyták csak ott a www.certigna.fr SSL szerver titkos kulcsát a nyilvános oldalon, ez pont elég volt a bitvadász Google robotoknak, hogy beindexeljék a látottakat, majd felkerüljenek a pastebin.com oldalára. Maga a letöltött titkos kulcs jelszóval védett, azaz rejtjelezett. Az OpenSSL és egy kis script (példa PHP kódot lásd alább) segítségével a jelszótartományt végig lehet pörgetni és vélhetőleg előbb-utóbb meg lehet kapni a nyers titkos kulcsot, de ez már kellően idő- és számításigényes feladat az otthoni erőforrásaimhoz képest, GPU-alapú GRID-et pedig nem kívántam beizzítani az ügy érdekében.
…
Hasonló esetekkel – nyilvános mappában véletlenül vagy szándékosan felejtett titkos kulccsal – lehet találkozni máshol is. A titkos kulcsokra vadászók első körben próbálkozhatnak Google Search eredményeivel is:
rsa private key filetype:key
rsa private key filetype:pemA hitelesítés-szolgáltatóknak valóban megbízható harmadik feleknek kell lenniük, különben borul az egész modell. Nem is annyira a tanúsítványkibocsátó és időbélyegző alkalmazás használata a nehéz feladat, hanem az alapinfrastruktúra hardening-je. Persze, itt szoktak is külső szakértői segítséget igénybe venni, de a jelek azt mutatják, hogy szándékosan, vagy akaratukon kívül, nem veszik elég komolyan a vizsgálatokat és azok eredményeit a felek. A DigiNotar esetében a PKI rendszert 2010. november 1-én a Pricewaterhouse Coopers vizsgálta felül, kérdés azonban, hogy ez mennyire terjedt ki a host szerverek operációs rendszerére, tűzfalszabályokra, IDS/IPS beállításaira és egyéb biztonsági paraméterekre.
A PKI funkcionalitás biztosításához azonban messze nem kellenek több 10 millió forintos alkalmazások, hozzáértők az ingyenes OpenCA-t is tetszőleges módon testre tudják szabni, sőt, maga az OpenSSL mag is biztosítani tudja a legalapvetőbb működést.
…
A PKI funkcionalitás tehát megoldható akár fapadosan is, de a rendszer hardening-je nem lehet fapados! A hálózati topológia jó megtervezése sok gondot levehet az üzemeltetők válláról: maga a tanúsítványkibocsátás ugyanis valóban mehet teljesen elszigetelt környezetben is, a külvilág számára elérendő adatokat lehet akár manuálisan is átvinni a belső rendszerből a külsőbe (gondolok itt CA adatbázis nyilvános adataira, azaz a CRL-ekre és tanúsítványokra, ezekből táplálkozhat az OCSP Daemon, illetve az időbélyegző is használhat egy – a belső hálótól teljesen elkülönülő – másik, külső HSM-et). Egy ilyen rendszernél a legrosszabb esetben az időbélyegből, CRL-ből, OCSP válaszból tudnak hamisat kiadni, de a tanúsítványkiállításhoz – ami a DigiNotar esetében a világméretű felfordulást okozta – nem férnek hozzá. ”
Forrás:
DigiNotar… Comodo… Certigna…, Szabó Áron, kormanyablak.org-blog, 2011. október 1.
