Ezúttal mélyebb vizekre evezünk. A PKI-témával, SSL-protokollal sokat foglalkozó Moxie Marlinspike is vizsgálgatta már a tanúsítványok ellenőrzéséhez kapcsolódó OCSP (Online Certificate Status Protocol) protokollt, amelyet az IETF RFC 2560 ír le, de ő alapvetően az elektronikus aláírással nem védett tartalmak módosításával tudott anomáliákat okozni ("OCSPResponseStatus" értékeként a "tryLater (3)" megadása). Én azt mutatom be, hogy mit lehet művelni akkor, ha az aláírt tartalomba ("ResponseData") piszkálunk bele. Igyekszem úgy leírni a dolgokat, hogy ne csak az OSCP (Offensive Security Certified Professional) vizsgával rendelkező szakemberek értsék meg... ;-)
A tanúsítványkibocsátók vagy hitelesítés-szolgáltatók rendszerében a CA (Certificate Authority) modul által kiadott (aláírt) tanúsítvány állapotáról a szintén CA modul által bizonyos időközönként (pl. 24 óránként) kiadott, web server-re vagy X.500/LDAP adatbázisba feltöltött (aláírt) CRL (Certificate Revocation List) közöl adatokat. Ha vissza lett vonva a kérdéses tanúsítvány, akkor a visszavonás pontos dátuma és időpontja, illetve a visszavonás oka kerül feltüntetésre ebben. Az OCSP protokoll segítségével ugyanúgy a tanúsítvány visszavonási adatait lehet lekérdezni, de ilyenkor közvetlenül a CA modul adatbázisában tárolt állapotról kapunk visszajelzést. Előnye a CRL-lel szemben, hogy azonnal kapunk választ, nem kell megvárni a következő (aláírás létrehozása utáni első) frissítést.
Az OCSP-vel kapcsolatban ott lehet érdekességeket találni, ahol az OCSP modul aláíró tanúsítványa nem ugyanarra a CA tanúsítványra vezethető vissza, mint a kérdéses végtanúsítvány, amelyről a visszavonási adatokat szeretnénk megtudni. A CRL-eknél nincs hasonló probléma, ott mindig visszavezethetők ugyanarra a CA tanúsítványra a CRL-t aláíró tanúsítványok.
A "CA X" adja ki a felhasználói tanúsítványt, illetve az OCSP válaszokat, mint visszavonási adatokat (tiltólistákat):
A "CA X" adja ki a felhasználói tanúsítványt, de az OCSP válaszokat, mint visszavonási adatokat (tiltólistákat) a "CA Y" alá tartozó entitás adja ki:
Miért okoz ez problémát? Elképzelhető olyan helyzet, amikor a "CA X" által kibocsátott tanúsítványról a "CA Y" alá tartozó OCSP kiszolgáló nyilatkozik, ahol mindkét CA ugyanannak a szolgáltatónak, szervezetnek két különböző modulja, de közös adatbázisból dolgoznak. Felhasználóként még el is lehet fogadni ezt, de amikor egy elektronikus aláírás-ellenőrző alkalmazásnak kell "bután" elemeznie a CA tanúsítványláncokat, akkor az csak annyit lát, hogy az egyik CA által kiadott tanúsítványról egy teljesen más CA alá tartozó OCSP kiszolgáló mond véleményt (pl. mintha a VeriSign tanúsítványunkról a Thawte nyilatkozna). Látszik, hogy a hitelesítés-szolgáltatói oldalon bizonyos esetekben ilyen még akár elő is fordulhat, ezért az elektronikus aláírás-ellenőrző alkalmazásoknak kell jó ítéletet mondania. Kérdés, hogy mi lehet ilyenkor a jó ítélet? Mivel az alkalmazás nem tudhat a valós életben a háttérben megbúvó esetleges összefonódásokról, ezért ilyenkor el kell dobnia az OCSP választ, hibásnak kell tekintenie azt. A probléma azonban ott van, hogy ezen ellenőrzés nem alapértelmezett az elektronikus aláírás-ellenőrző alkalmazásoknál! Készítsünk egy Proof-of-Concept (PoC) adathalmazt annak bemutatására, hogy ezzel milyen könnyen lehet visszaélni! Ne feledjük: legjobb barátaink továbbra is az OpenSSL és az ASN.1 Editor!
Szerezzünk egy valós OCSP választ (pl. az otthon felhúzott OpenCA projekt OCSP Daemon moduljából):
Módosítsuk a kérdéses, ellenőrzendő végtanúsítvány sorozatszámát az OCSP válaszban (azaz, az OCSP szolgáltatónk így kiad egy "good" választ egy teljesen más tanúsítványra):
A módosított OCSP választ írjuk alá az OCSP kiszolgálónk kulcsával, majd gyúrjuk össze az elektronikusan aláírt tartalmat az OCSP válasz keretével (az ellenőrzendő tanúsítvány sorszáma - "008C.." helyett "6666.." - és az OCSP válasz aláírása - "8EB2.." helyett "37A0.." - változott):
Ellenőrizzük a teljes OCSP válasz hitelességét (az OpenSSL szerint "Response verify OK"):
Az elkészült OCSP választ ezután már be lehet ágyazni pl. egy XML elektronikus aláírás állományba, amit oda lehet adni egy elektronikus aláírás-ellenőrző alkalmazásnak. A jelen példa tehát bemutatja, hogy tetszőleges tanúsítványhoz tudunk gyártani olyan OCSP választ, amely kimondja, hogy az adott tanúsítvány nem volt visszavonva ("good"), és van olyan "csillagegyüttállás", amelyek mellett az elektronikus aláírás-ellenőrző alkalmazások ezt el is tudják hinni. Persze, ehhez szükséges az is, hogy az általunk (a támadó által) üzemeltett OCSP kiszolgáló CA-jában is megbízzon az alkalmazás, de néhány self-signed trusted root tanúsítvány felpakolása a háttérben (interakció nélkül) a felhasználó rendszerébe azért megoldható, úgyhogy ez nem jelent gondot.
A trükközés ellen megfelelő védelmet nyújt az, ha az elektronikus aláírás-ellenőrző alkalmazás megvizsgálja azt is, hogy a kérdéses tanúsítványhoz tartozó és az OCSP választ aláíró CA tanúsítványlánc összeér-e.
Kapcsolódó anyagok:
|
