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

Az SSL nehéz

2012.10.28. 10:08 | buherator | 4 komment

A Stanfordi és Texasi egyetemek kutatói közzétettek egy érdekes tanulmányt a különböző SSL/TLS-t alkalmazó könyvtárak, middleware-ek és SDK-k minőségéről. Ezeket a komponenseket számos érzékeny adatot kezelő alkalmazásban megtaláljuk, találkozhatunk velük például banki mobilalkalmazásokban e-kereskedelmi site-ok fizetési moduljaiban, de a különböző cloud szolgáltatások eléréséhez is érdemes ezeket a kulcsrakész szoftvereket használni. 

A probléma az, hogy úgy tűnik, a szóban forgó szoftverek fejlesztői nem fordítottak kellő figyelmet az általuk használt alacsonyabb szintű API-k dokumentációjára, vagy egyenesen kiiktattak bizonyos ellenőrzéseket a kellemetlen felhasználói hibajelzések vagy éppen a könnyebb tesztelhetőség érdekében. 

Az egyik tipikus hiba a cURL könyvtár tanúsítványellenőrzést beállító opcióinak helytelen paraméterezése: a tanúsítványok "Common Name" attributumának vizsgálatához először is be kell állítani a CURLOPT_SSL_VERIFYPEER opciót igazra, ezen kívül a CURL_SSL_VERIFYHOST értékét 2-re kell állítani. A baj az, hogy a fejlesztők gyakran azt hiszik, hogy a második opció is egy boolean, így true-t adnak értékül neki, ami a legtöbb nyelvben az 1-es értékre fordítódik. Ilyen beállítás mellett azonban a könyvtár csak azt ellenőrzi, hogy létezik-e CN attributum a tanúsítványban, azt már nem, hogy az megegyezik-e az aktuális hosztnévvel. Ettől a problémától szenvedett a PayPal Payments Standard SDK korábbi verziója, valamint az Amazon Flexible Payments Service SDK-ja is. A ZenCart-tal szállított PayPal IPN modul simány False-ra állította a VERIFYPEER értéket, így gyakorlatilag semmilyen névellenőrzés nem történt. 

Egy másik érdekes példa az Apache HttpClient 3-as főverziója, ami a JSSE SSLSocketFactory-ját használja a kapcsolatok kialakítására, ez az alacsony szintű API (ahogy a dokumentációban is olvasható) nem végez hosztnév ellenőrzést, az Apache HttpClient pedig szintén megfeledhezik erről. Bár a legfrissebb 4-es főverzióban már orvosolták ezt a problémát (így a csomag esetenként érvényes tanúsítványokat is visszadob...), számtalan helyen (pl. az Axis 2-ben) még mindig a 3-as változatot használják, az újabb verzió ugyanis nem visszafele kompatibilis.  

Sajnos olyan is előfordul, hogy a hivatalos dokumentáció egy szót sem ír az SSL/TLS kapcsolatok ellenőrzéséről. Ilyen például a PHP fsockopen() függvénye, mely ugyan képes titkosított kapcsolatokat kezelni, a távoli hoszt tanúsítványán azonban nem hajt végre semmilyen ellenőrzést. Ezt az eljárást a már emlegetett ZenCart és PrestaShop rendszerek is használják, ha a cURL nem elérhető.

Végül, ahogy már említettem, előfordul, hogy a fejlesztők szándékosan kapcsolják ki a távoli hoszt hitelességének ellenőrzését. Ez történik többek között az Apache Libcloud 0.11.1-nél korábbi verzióiban, az Amazon Elastic Cloud Balancing API Toolsban, az osCommerce, a ZenCart, az Ubercart és a PrestaShop szinte összes fizetési szolgáltatást integráló moduljában, az AIM-ben és számos Andorid alkalmazásban. 

Népszerű tévhit, hogy ha a kapcsolatom titkosított, minden meg van oldva. Pedig a titkosítás hitelesítés nélkül általában nem sokat ér, az esetek többségében passzívan hallgatózó támadó könnyen aktív man-in-the-middle-é tudja varázsolni magát. Gyakori védekezés, hogy a hálózat alapvetően megbízható, ami internetes alkalmazásoknál eleve abszurd kijelentés, egyébként érdemes átgondolni, hogy ha tényleg sérthetetlenek az összeköttetések (általában nem azok), akkor miért is használunk SSL/TLS-t?

Az érintett szoftverek listájáért érdemes átolvasni a teljes dokumentumot, ökölszabályként pedig elmondható, hogy ha már elfogadunk kódot idegenektől, legyen gondunk rá, hogy teszteljük is azt.

Címkék: ssl java php programozás amazon apache aim tls oscommerce ubercart curl andorid zencart prestashop jsse

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.

noss 2012.10.28. 15:36:59

"Validating SSL Certificates in Non-Browser Software" --- valszeg buta, de leginkább hozzá nem eléggé értő kérdésem: a böngészők ezek szerint rendesen/tisztességesen hitelesítenek?

buherator · http://buhera.blog.hu 2012.10.28. 20:46:32

@noss: Ez az állítás a tanulmány címéből logikailag nem következik ugyebár. A böngészők nyilván nagyobb hangsúlyt fektetnek a titkosított kapcsolatok kezelésére, de ott is akadnak problémák, lásd pl. a visszavonási listák kezelését.

nossvagyok 2012.10.30. 00:16:14

@buherator: pontosan erre voltam kiváncsi :)

hrgy 2012.12.29. 23:44:14

Fejlesztokent en is sokszor szembesulok azzal, hogy bizonyos szolgaltatasok hasznalatahoz egyszeruen kenytelen vagyok letiltani a tanusitvany ellenorzest, mert egyszeruen maga a szolgaltatas nem fordit elegendo figyelmet arra, hogy megfelelo tanusitvanyt hasznaljon. Peldaul ismeretlen az alairo CA, lejart, vagy a hostnev nem ellenorizheto, mert a tanusitvany rossz nevre szol.

Aztan az is elofordul, hogy az SSL konyvtarak nem mindegyike tamogatja a wildcard tanusitvanyt, igy hiaba tudnam a hostnevet ellenorizni, ha a wildcardhoz nem lehet ellenorizni, mert nem a *.valami.com -hoz csatlakozok, hanem a server542.valami.com -hoz.

Szoval ez egy sok komponensu kerdes, nem lehet csak azzal elintezni, hogy a kliens eszokozok vackok, mindig meg kell nezni a szerver oldalt is...