| | | | | Mottó:
Pangloss megmagyarázta neki,
hogy minden a legjobban van
ezen a legeslegjobb világon.
/Voltaire: Candide
vagy az optimizmus/ | | 2011. október 1. | | | | | DigiNotar... Comodo... Certigna... | | | | | | 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.
A ComodoHacker korábban a Comodo CA elleni sikeres támadásról vált ismertté. Bizonyítékként feltöltötte az addons.mozilla.org SSL szerver tanúsítványának titkos kulcsát a pastebin.com oldalra (ezt később már csak a erratasec.blogspot.com oldalon lehetett elérni). A titkos kulcs és a tanúsítvány birtokában otthon már össze lehetett rakni egy PKCS#12 formátumot, amit aztán a Windows is meg tudott emészteni. A telepített tanúsítványra kattintva lehet is látni, hogy "Van egy személyes kulcsa, amelyik ehhez a tanúsítványhoz tartozik.", azaz létrehozhatunk aláírásokat, lezongorázhatunk egy SSL-handshake kapcsolatfelépítést az addons.mozilla.org nevében.
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:pem
A 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. Merthogy mi is kell egy CA-nak? Tudjon kulcsokat generálni és azok alapján tanúsítványokat kiadni különböző profilok (pl. aláíró, SSL web server) szabályai szerint, illetve tudjon visszavonási adatokat (pl. CRL) kibocsátani bizonyos időközönként. Az ezekhez szükséges szolgáltatói kulcsokat pedig biztonságos módon kell tárolni (pl. drága HSM helyett akár egy Aladdin eToken PRO is jó lehet). Azért ha van valakinek egy jó netHSM-je, ne dobja el, inkább fogja be elé az OpenSSL-t (az alábbi konfig egy Thales nShield Connect 500 - Code: NH2033 - netHSM eszközhöz jó volt)!
Az OpenSSL tudja nyújtani az alábbi feltételeket:
- legyen Unicode-támogatás pl. a commonName névelemben (a 4 byte-on tárolt vietnámi karakterek ugyan ritkák, általában az UTF-8 is elég)
- támogassa az erősebb algoritmusokat (SHA-256 lenyomatképzés ma már elvárás, de tud többet is)
- támogassa a nagyobb kulcsméreteket (2048 vagy 4096 bites RSA kulcs ma már elvárás, de tud többet is)
- támogassa a különböző profilokat (a keyUsage és extKeyUsage kiterjesztések értékeit könnyen meg lehet adni)
- szerepeljen a tanúsítványban a CRL helye (a cRLDistributionPoints kiterjesztésben a CRL URL-t könnyen meg lehet adni)
- szerepeljen a tanúsítványban az OCSP helye (az authorityInfoAccess kiterjesztésben az OCSP URL-t könnyen meg lehet adni)
- támogassa a hosszabb tanúsítványláncokat (1.. 2.. 3.. 4.. N-mély lánc kialakítható)
- tudjon CRL visszavonási adatokat kiadni (van ilyen funkciója az alapcsomagban)
- tudjon OCSP visszavonási adatokat kiadni (van ilyen funkciója az OCSP Daemon kiegészítővel az OpenCA révén)
- tudjon időbélyeg adatokat kiadni (van ilyen funkciója a v1.0.0 változattól az OpenTSA révén)
- tudjon HSM-ben tárolt kulcsokat kezelni (van ilyen funkciója, ami az "engine" paramétereként és az "openssl.conf" állományban adható meg)
- legyen független fél által is bevizsgálva (FIPS 140-2 Level 1 plecsnije van bizonyos változatoknak).
Az UTF-8 karakterek megadása picit ugyan körülményes, mert a stdin nem veszi be őket jól, ezért érdemes azokat default értékként beírni az "openssl.conf" állományba, amit utána úgy kell elmenteni, hogy a BOM (Byte Order Mark UTF-8 esetében: EF BB BF) ne maradjon benne.
A kis trükközés után már minden megy szépen, a paramétereket kell csak megfelelően kitölteni.
Az eredmény pedig egy szép tanúsítványlánc...
... és a hozzájuk tartozó CRL visszavonási adatok.
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á.
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
