Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

A webmail és a CA-k

2010.04.18. 19:03 | buherator | 5 komment

Ez tényleg fáj:

Kurt Seifried rájött, hogy a RapidSSL (és minden bizonnyal még néhány "jónevű" CA) pusztán egy (tipikusan ssladmin@ kezdetű) e-mail cím meglétéhez köti az SSL tanúsítványok kibocsátását, ami ingyenes webmail szolgáltatók esetében nem túl szigorú feltétel... 

A probléma első sorban nyilván man-in-the-middle támadásra ad lehetőséget: Pl. egy megfelelően beállított vezetéknélküli AP segítségével a rapid tanúsítványt használva gyakorlatilag bárkit meggyőzhetünk, hogy a valódi levelezőrendszerrel beszélget, miközben a kommunikációt a saját magunk által üzemeltetett, preparált szájton vezetjük át. 

Mindez persze valójában nem a webmailek hibája, hanem CA-ké (akiknek néha elég egy céges fejléccel ellátott, aláírt papírt átfaxolni a hitelesítéshez), de azért nem árt, ha a hasonló szolgáltatásban utazók letiltják az ilyen, félreértésekre okot adó címek regisztrációját.

Itt olvashatók C Keigher tapasztalatai, aki a húsvétra való tekintettel Jézus Krisztus néven regisztrált néhány nagyobb szolgáltatóhoz - sikerrel.

Gondoltam teszek én is egy próbát, és beregisztráltam a nagyobb hazai szolgáltatóknál (freemail, indamail, citromail, mailbox) az ssladmin fiókot. Különösebb problémába nem ütköztem, innentől kezdve én is is szaladhatnék a RapidSSL-hez tanúsítvány igényelni... de minek?

A mélyen tisztelt hazai szolgáltatók ugyanis az esélyét sem adják meg annak, hogy biztonságosan férjünk hozzá a leveleinkhez, az említett oldalak HTTPS-en nem elérhetők...

Címkék: ssl freemail webmail citromail indamail mailbox

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Aron bacsi 2010.04.18. 22:58:51

Huh, ez egy újabb buta dolog, ami azért fordulhat elő, mert nem (annyira) hozzáértő emberek szagolnak hozzá egy éles PKI szolgáltatáshoz. Anno a 0 byte-os hiba és most ez is azt jelzi, hogy egy tanúsítvány-regisztrációs folyamatot azért legalább egy picit át kellene gondolni, különben érhetik az embert ilyen jellegű meglepetések...

Buhera! Az ssladmin@-os fiókok jó ötletek! :D Hasonló érdekességet csinált az egyik ismerősöm is: ahol tudta, regisztrálta a MAILER-DAEMON@-os címeket is... Ott is voltak már ebből vicces helyzetek...

EQ · http://rycon.hu 2010.04.19. 19:13:23

@Aron bacsi: hát azért a 0byteos hiba olyan szinten teljesen más téma, hogy említeni sem kellett volna. Ember legyen a talpán aki feltudja szakszerűen fejből sorolni azt a 2x db stringábrázolást amiből ott a hiba eredt.

Aron bacsi 2010.04.19. 20:33:37

@EQ: Izé... Igen, mint konkrét dolog, más a hiba, ebben igazad van! Én csak arra akartam inkább utalni, hogy a folyamat szempontjából viszont ugyanott, a regisztrációnál van a banánhéj.

Tehát nem a fizikai környezettel (pl. törhető HSM?), nem a kulcsokat használó kripto alkalmazásokkal (pl. rossz PRNG OpenSSL-nél?), nem a kripto algoritmussal (pl. AES 128 vagy 256 erősebb?), még csak nem is az egyszerű júzerrel (pl. PIN kód a kártyán?) van a baj, hanem a CA folyamataival. Értem én, hogy nehéz "fejből sorolni azt a 2x db stringábrázolást", de úgy gondolom, hogy ha egy CA ennyire felügyelet nélkül bocsát ki tanúsítványokat, akkor azért komolyabb szűréseket, néhány jól megírt regexp-et elviselne a rendszer input-validálásnál. Ha jól tudom, az itthoni CA-knál is van valamennyi automatizmus, de azért van a folyamatban olyan pont, ami ember által felügyelt. Az is igaz, hogy itthon valszeg nincs annyi SSL tanúsítványigénylés, ami miatt teljesen automatizálni kelljen a folyamatokat...

synapse · http://www.synsecblog.com 2010.04.20. 10:12:24

"Én csak arra akartam inkább utalni, hogy a folyamat szempontjából viszont ugyanott, a regisztrációnál van a banánhéj"

Nem, arra utaltal hogy az openssl fejlesztok inkompetensidiotak: "nem (annyira) hozzáértő emberek szagolnak hozzá egy éles PKI szolgáltatáshoz"

"pl. rossz PRNG OpenSSL-nél?" PRNG jovolt, nem volt megfeleloen beseedelve.

Az hogy faxra kapsz certet meg megarofl.

Aron bacsi 2010.04.20. 21:00:52

@synapse: Hmm, na, várj csak! Az OpenSSL fejlesztőknek köze nincs egy CA által használt regisztrációs folyamathoz és az azt vezérlő apphoz! Még akkor sem, ha a RapidSSL mögött OpenSSL magot használnak, hiszen maga az OpenSSL nem fogja megelemezni, hogy az ssladmin@ e-mail cím jó-e vagy sem, egyszerűen nem az ő feladata, hanem egy előtét alkalmazásé! Az OpenCA-nál, mint előtét alkalmazásnál is amikor felhúztam, volt néhány
hiba, amit a Perl script-ekben kellett javítanom anno, de az OpenSSL forrásához, a kripto-maghoz nem nyúltam hozzá.

Az OpenSSL-t már csak azért sem szólnám le, mert én is ezt használom referenciaként, amikor a saját Windows-os appjainkat tesztelem a cégnél. :D A pid-es seed mondjuk valóban hiba volt, de ezzel együtt is az OpenSSL-t nagyon jó kis cuccnak tartom...
süti beállítások módosítása