Újabb komoly SSL hiba - DROWN támadás

Titkosítás, biztonság, privát szféra

DROWN logó

Az OpenSSL projekt egy újabb komoly sebezhetőség részleteit tette közzé a minap. Ahogy az a legújabb divat szerint lenni szokott, komoly sebezhetőséghez név, dedikált weboldal és logó is jár. Szóval a CVE-2016-800 azonosító alá besorolt "Cross-protocol attack on TLS using SSLv2" a DROWN nevet kapta. Saját tájékoztató weboldala pedig a drownattack.com címen érhető el. A weboldalon megtalálható egy teszt, amellyel a weboldalaink érintettségét tesztelhetjük, a sebezhetőség technikai részleteinek leírása, valamint egy kérdés-felelet szekció.

A LibreSSL-t nem érinti a DROWN sebezhetőség.

( manfreed (nem ellenőrzött) | 2016. 03. 02., sze – 09:52 )

"Ahogy az a legújabb divat szerint lenni szokott, komoly sebezhetőséghez név, dedikált weboldal és logó is jár."

Kicsit komolytalanná is teszi az egészet.

Szerintem nem. Ez így van jól.
Inkább egy kis színezetet ad neki, és könnyedebbé tesz mondjuk egy előadást, amit félig laikusaknak (pl. menedzsereknek) kell megtartanod.
A nagy fizikusok is képeket, történeteket alkottak sokszor a legabsztraktabb elméletekről.

( Sanya v | 2016. 03. 02., sze – 11:25 )

Jáj, engem érint :)

Le kell tiltsam a 443-at a NAS-on.

( gemnon v | 2016. 03. 02., sze – 12:50 )

Mi nem vagyunk érintve, de a NISZ-nél ma se fognak unatkozni. (nem is tudtam, hogy van mil.hu "TLD" :))

Én nem aggódnék értük nagyon. Ha _megvan/meglesz_rá_az_akarat_, akkor egy hozzáértő ottani kolléga pár óra alatt megoldja.
Bár valóban jogos kérdés, hogy azok akiknek ez lenne a dolguk (CVE böngészés, belső vuln tesztelés), ezt miért nem jelezték a megfelelő üzemeltető csoportok felé, hogy ASAP fixálják.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.1 | 3.10.96-janos

> Ha _megvan/meglesz_rá_az_akarat_, akkor egy hozzáértő ottani kolléga pár óra alatt megoldja.

Hat nem volt.

> akiknek ez lenne a dolguk (CVE böngészés, belső vuln tesztelés), ezt miért nem jelezték a megfelelő üzemeltető csoportok felé, hogy ASAP fixálják.

Hogymi?:)
Ezeknek a rendszereknek a kozelebe nem engednem azt, aki ssl2-t bekapcsolva hagyja rajtuk.
Gillotin meg daralo kene.

Szia,

A linked gázos...
Minket a palyazat.gov.hu rész konkrétan érdekel, csak az egyik IP cím sem valid a listáról.
nslookup/host/dig mást mond. Ezek nagyon régi IP-k, a nyáron átvettük a volt szolgáltatótól. Az viszont gáz, hogy még mindig be van konfigurálva náluk :( emiatt kompromittálódhat a tanúsítvány.
Azt ne kérdezzétek, hogy miért nem kértünk újat azonnal, amikor átvettük... Jeleztük, hogy kell :)

--
PtY - www.myonline.hu, www.westeros.hu

( bithalver | 2016. 03. 02., sze – 12:43 )

Oszinten szolva valamit nem ertek.

NAgy cegek alltak a Linux moge (ami reszemrol is nagyon pozitiv), de nem hallom, hogy barki tokeerosebb az SSL moge allna; megiscsak ez felel a az egesz NET biztonsagaert, nem ?

SSL != OpenSSL.
Az SSL egy protokoll, az OpenSSL csak egy implementáció.
Az SSL protokoll mögött állnak tőkeerős cégek - akik az IETF tagjai.
Az OpenSSL és egyéb más SSL implementációk meg más kérdés.
És nem csak az OpenSSL felel az egész net biztonságáért, legfeljebb UNIX-like platformokon.

A kliens oldali scannerüket próbáltad?

Bár valamiért az NGINX-et nem csipázza, ha az online scannerük is hasonló akkor valószínűleg nem is hoz egy rakás affected siteot. 


root@sandbox:~/public_drown_scanner-master# ./scanner.py example.com 443

Testing example.com on port 443
example.com: Case 3b; Connection reset by peer when waiting for server hello 
example.com: Server is NOT vulnerable with cipher RC2_128_CBC_EXPORT40_WITH_MD5, Message: 3b: no tls

example.com: Case 3b; Connection reset by peer when waiting for server hello
example.com: Server is NOT vulnerable with cipher RC4_128_EXPORT40_WITH_MD5, Message: 3b: no tls

example.com: Case 3b; Connection reset by peer when waiting for server hello
example.com: Server is NOT vulnerable with cipher RC4_128_WITH_MD5, Message: 3b: no tls

example.com: Case 3b; Connection reset by peer when waiting for server hello
example.com: Server is NOT vulnerable with cipher DES_64_CBC_WITH_MD5, Message: 3b: no tls

Asztakurva... Ránéztem a cli-s teszterre. 

--> Testing protocols (via sockets except TLS 1.2 and SPDY/NPN)

 SSLv2      offered (NOT ok) -- 6 ciphers
 SSLv3      offered (NOT ok)
 TLS 1      offered
 TLS 1.1    not offered
 TLS 1.2    not offered (NOT ok)
 SPDY/NPN   not offered

--> Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK) (timed out)
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Secure Renegotiation (CVE-2009-3555)      not vulnerable (OK)
 Secure Client-Initiated Renegotiation     not vulnerable (OK)
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK)
 BREACH (CVE-2013-3587)                    no HTTP compression (OK) (only "/" tested)
 POODLE, SSL (CVE-2014-3566)               VULNERABLE (NOT ok), uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)
 TLS_FALLBACK_SCSV (RFC 7507), experim.    Downgrade attack prevention NOT supported
 FREAK (CVE-2015-0204)                     VULNERABLE (NOT ok), uses EXPORT RSA ciphers
 LOGJAM (CVE-2015-4000), experimental      VULNERABLE (NOT ok), uses DHE EXPORT ciphers, common primes not checked.
 BEAST (CVE-2011-3389)                     SSL3: EDH-RSA-DES-CBC3-SHA DES-CBC3-SHA
                                                 EDH-RSA-DES-CBC-SHA DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA
                                                 EXP-DES-CBC-SHA EXP-RC2-CBC-MD5 EXP-RC2-CBC-MD5
                                           TLS1: EDH-RSA-DES-CBC3-SHA DES-CBC3-SHA
                                                 EDH-RSA-DES-CBC-SHA DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA
                                                 EXP-DES-CBC-SHA EXP-RC2-CBC-MD5 EXP-RC2-CBC-MD5
 RC4 (CVE-2013-2566, CVE-2015-2808)        VULNERABLE (NOT ok): RC4-SHA RC4-MD5 RC4-MD5 EXP-RC4-MD5 EXP-RC4-MD5

Szerintem most baszom ezt siteot ki...

Szerk: kibasztam... Amiért fizettek is, az legalább rendben volt :)

--
openSUSE 13.1 x86_64