20:41
20/9/2011

BEAST to narzędzie pozwalające atakującemu na rozszyfrowanie danych przesyłanych protokołem TLS w wersji 1.0 (i SSL 3.0). Protokoły te są między innymi składową HTTPS i chronią transmisję danych pomiędzy webserwerem a przeglądarką.

Na wstępie przypomnijmy, że TLS (Trasport Layer Security) to następca SSL (Secure Socket Layer). Głównym zadaniem TLS jest zapewnienie poufności i integralności transmisji danych oraz możliwość uwierzytelnienia serwera a czasem klienta.

BEAST atakuje, SSL 3.0 i TLS 1.0 rozszyfruje

Lada dzień, Thai Duong i Juliano Rizzo planują zademonstrować narzędzie o nazwie BEAST (Browser Exploit Against SSL/TLS) składające się z kodu JavaScript, który musi uruchomić ofiara oraz sniffera, który przechwytuje i rozszfrowuje zaszyfrowane ciasteczka, dając tym samym atakującemu nieautoryzowany dostęp do konta ofiary w danym serwisie internetowym korzystającym z HTTPS. Według twórców, atak zadziała także na serwery wykorzystujące HSTS (HTTP Strict Transport Security).

BEAST potrzebuje ok. 2 sekund, aby korzystając z ataku plaintext-recovery rozszyfrować każdy bajt zaszyfrowanego ciastka (co daje ok. 10 min. dla przeciętnej wielkości ciasteczka). Ten czas można jednak znacznie skrócić — twierdzą autorzy. Warto też wspomnieć, że BEAST wykorzystuje błąd znany od wczesnych wersji SSL — do tej pory jednak zagrożenie z nim związane uważano jedynie za “teoretyczne”.

Atak jest bardzo medialny, bo pozwala stwierdzić, że “źli hackerzy” są w stanie podsłuchiwać transakcje wykonywane za pomocą PayPala, albo przejąć czyjeś konto na GMailu (atak dotyczy tylko tych implementacji TSL, które wykorzystują szyfr blokowy AES). Zauważmy, że TLS 1.0 wykorzystywany jest także jako składowa takich usług jak VPN czy komunikatory internetowe. Robi wrażenie, prawda? Ale warto pamiętać, że aby atak doszedł do skutku, atakujący musi najpierw zmusić ofiarę do uruchomienia złośliwego JavaScriptu, a więc warunkiem koniecznym jest atak MitM i znalezienie XSS-a (niestety, wygląda na to, że da radę również bez XSS).

TLS 1.1/1.2 na ratunek?

Niestety, pomimo tego, że bezpieczniejsza wersja TLS, czyli 1.1 jest dostępna od 2006 roku, praktycznie wszystkie webserwery ciągle korzystają z podatnego na atak TLS 1.0:

TLS wykorzystanie na świecie

Wykorzystanie TLS w internecie (źródło: Qualys)

The Register brak szerszego przyjęcia TLS 1.1 upatruje w przestarzałych implementacjach SSL w Firefoksie i Chromie oraz OpenSSL-u. Bezpieczniejsze wersje TLS są za to dostępne w serwerze IIS (nie domyślnie) oraz Operze (domyślnie). Autorzy BEAST twierdzą, że większość właścicieli serwisów internetowych nie wdroży bezpiecznych protokołów TLS 1.1 lub 1.2, ponieważ nie są one wspierane przez znaczną liczbę klientów i upgrade do bezpieczniejszej wersji TLS oznaczałby spadek dochodów. Być może opublikowanie exploita coś zmieni w tej kwestii — Duong i Rizzo zdradzili, że już od maja współpracują w tej kwestii z producentami przeglądarek, którzy mają wprowadzić obejścia problemu.

Warto też zauważyć, że Doung i Rizza wspominają jak na razie tylko o ataku na szyfr blokowy jakim jest AES. SSL-a można używać z szyframi strumieniowymi (RC4) — być może to pozwoli na bezbolesną ochronę przed tym atakiem?

Z niecierpliwością czekamy na premierę narzędzia — panowie mają zaprezentować jego działanie “hackując” płatności PayPala. Jedno jest pewne, najbliższe tygodnie dla tzw. e-commerce będą pełne wrażeń — myślę, że to dobra pora, żeby zaproponować wszystkim sklepom internetowym zniżkę na nasze pentesty, w końcu warto ustrzelić wszystkie XSS-y :-)


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

60 komentarzy

Dodaj komentarz
  1. Wow!

  2. no to pieknie. xss stanie sie teraz najbardziej wartościowym i najgroźniejszym atakiem…

    • Może tak, a może nie. Zwróć uwagę, że aby przeprowadzić atak musimy “podsłuchać” ofiarę, a samym XSS’em tego nie zrobimy. W tedy z pomocą przychodzi MiT. I trzeba te dwie rzeczy “zgrać”. W sumie to można bardzo łatwo zrobić, iść na lotnisko z laptopem postawić fake AP tak aby do każdej otwieranej strony dodawał złośliwy JS, a ruch i tak idzie przez nasz komputer więc wszystko ;)

      No to po prezentacji tego ataku czekamy na nową wersję firesheep, która zrobi wszystko za nas :E żartuje oczywiście ;-)

      Jest drobna literówka: “dostępnya”

    • @kasper93
      A u ciebie jest poważniejszy błąd – “w tedy”.

    • @Kasper93:

      Pomyśl, jak chcesz wstrzyknąć kod javascript do zaszyfrowanej wiadomości …

      Bez ataku XSS się nie obejdzie

  3. Życzę wszystkim adminom szybkiego update’a do TLS 1.1 v 1.2 ; )))))

  4. Czyli co? Koniec bezpiecznych transakcji? Lepiej żeby banki wzieły się ostro do roboty…

    • Przeczytaj artykuł :) Nikt nie złamał szyfrowania, to tylko tytuł rodem z Faktu. Po prostu stworzyli narzędzie do obchodzenia szyfrowania poprzez atak za pomocą JS, np. XSS.

    • o_O Hm… nie wprowadzaj ludzi w błąd. To nie jest “obejście szyfrowania”, a “rozszyfrowanie transmisji” przy pomocy ataku plaintext-recovery.

    • Taki atak nazywasz złamaniem algorytmu? Wymuszenie bejsbolem hasła do banku też nazwiesz złamaniem zabezpieczeń systemu bankowego? Plaintext recovery nie narusza w żaden sposób integralności czy skuteczności samego szyfrowania. Mając po prostu zrzut zaszyfrowanej transmisji nie zrobisz NIC. Czyli samo szyfrowanie złamanym nie jest, i nie wprowadzajmy ludzi w błąd mówiąc, że jest.

    • człeniu kropkowy, złamaniem nie jest? to jak twoim zdaniem mialoby wygladac zlamanie ssla? IMO twoje podejscie z nazywaniem tego ,,obejsciem” jest mniej poprawne. Ale nie bawmy sie w przpychanki na jezyk polski. Jest atak. Dziala ponoc bo chyba goscie nie odwalą ściemy na konferencji. Jest problem jednym slowem. Ty go nie dostrzegasz, wiec gratuluje ci pewnosci, ze nie masz na swoim servie xssa, hehe ;] podaj url, sprawdzimy czy masz racje ;];]

    • Złamanie SSL działałoby tak, że mając zapisany zrzut zaszyfrowanych danych, mógłbyś go odszyfrować. Tak proste, a tak trudne do zrozumienia.

    • Ehh no niestety się zgodzę, że to tytuł rodem z faktu… niebezpiecznik coś sie psuć zaczyna :P Albo poprostu czegoś nie rozumiem… Jeśli SSL został złamany to powinno się dać odczytać zaszyfrowaną wiadomość SZYBKO bez jakichkolwiek dodatkowych informacji. Jeśli się nie da to rozumiem, że polega to na kompromitacji klucza przez wadliwe oprogramowanie lub inny błąd w implementacji.

      Jeżeli SSL został złamany (jeszcze raz – SSL – nie konkretna implementacja tylko SSL) to chętnie zobacze jak poradzi sobie ten sposób z wyciągnięciem hasła np szyfrowanego logowania do SMTP.

      A i złamanie tego nie znaczy przypadkiem udowodnienia NP-niezupełności jakiegoś dręczącego matematyków problemu?

    • @ble: czy tablice tęczowe to złamanie funkcji skrótu, np. sha1? Nie? To dlaczego proces porówywania skróty ze słownikiem skrótów nazywa się łamaniem haseł? Zaraz zaczniemy się zastanawiać, kim jest hacker… i co gorsza, czym różni się od crackera ;)

      Przekaz z szumu wokół BEAST-a myślę jest dość jasny — używanie SSL*/TSL 1.0 nie zawsze jest bezpieczne. Nie wierzę, że ktoś może mieć problem z jego zrozumieniem.

    • Piotr Konieczny: tak to nazywa się łamaniem, tęczowe tablice to tylko sposób przyspieszenia ataku brute-force. I SSL też łamano już wielokrotnie (google ssl ps3). Przykładowo pisze aplikację, używam socketa i na nim SSL’a – a mimo że piszecie o złamaniu SSL’a tak naprawde te rewelacje nijak sie mają do bezpieczeństwa mojej aplikacji. Tym samym tytuł wprowadza w błąd – nie złamano SSL tylko znaleziono luki w konkretnej(ych) implementacji. I nie są to żadne nieścisłości językowe tylko nierzetelność.

      Przy tym jestem troche hiporytą, że to komuś wytykam ale naprawde widze ten tytuł jako rażące wprowadzanie w błąd. I wcale nie twierdze też że “Przekaz z szumu wokół BEAST-a” nie jest jasny – tak to jest poważne zagrożenie, ale innej natury.

    • ble: odśwież cache, tytuł od wczoraj to “Atak na” :-)

  5. A czy SSLv3 jest pod tym względem bezpieczniejsze? Jeśli tak, to prędzej niż masowe wprowadzenie TLS 1.2 możemy się spodziewać wyłączania TLS tam gdzie jest…

  6. Ciekawe jak szybko będą się wszyscy updatować na 1.1 /1.2 :D

    • Nie będą. Wciąż spotykane jest wsparcie dla SSLv2, który ma poważniejsze słabości niż to, co wykryto w tym przypadku. Wystarczy tylko spojrzeć na wykres dołączony do artykułu. To duże czerwone pole to lista serwerów wspierających SSLv2.

    • Problem jest taki, że nie ma tu mowy o podrzędnym sklepiku internetowym tylko firmach, które nie mogą sobie pozwolić na “nie updatowanie się”. Wyobrażasz sobie, że wszyscy będą trąbić o możliwym ataku na PayPal, a oni stwierdzą:

      “a łeee musicie zrobić zdobyć ciastko, przejść 5 firewalli, zjeść babeczkę, odwiedzić kolegę i zainstalować mu keylogger’a (…) Na pewno się wam to nie uda, więc nie będziemy się łatać!”

      Banki, allegra, droboxy itd. jeśli mają takie zgłoszenie, to MUSZĄ taki problem rozwiązać, bo inaczej wypadną z gry.

    • Nie wypadną. Według tej teorii żaden bank nie powinien już istnieć. Weźmy chociażby takie zagrożenia jak phishing lub skimming.
      Dopóki nie zaczną im wyciekać grube tysiące, to nawet tym się nie przejmą szczególnie. Było tak w przypadku SSLv2, będzie i teraz. Odsyłam do dość starego raportu http://security.psnc.pl/reports/e-banking_polska_ssl_report.pdf. Nie wierzę, ze teraz będzie inaczej.

  7. Haha, wiedziałem, że jest w tym jakiś haczyk! ;D
    “atakujący musi najpierw zmusić ofiarę do uruchomienia złośliwego JavaScriptu”
    To prawie tak jak:
    “Złamaliśmy najlepszejsiejsze zabezpieczenie XXX! Ofiara musi tylko uruchomić nasz program i już wszystko mamy!”…

    • no ale w czym widzisz problem? dla Ciebie xss to tak samo wirtualny byt jak latający holender?

  8. No tak, znów na piechotę trzeba będzie chodzić do spożywczaka…

  9. “aby atak doszedł do skutku, atakujący musi najpierw zmusić ofiarę do uruchomienia złośliwego JavaScriptu, a więc warunkiem koniecznym jest np. znalezienie XSS-a lub atak MitM” – oznacza to, że ten JS musi zawierać się w szyfrowanej zawartości wysłanej przez dany serwis? Podsłuchiwanie połączenia z nieszyfrowanym WiFi na nic się nie zda?

    • Z tego co zrozumiałem, to ten JS ma robić requesty w imieniu użytkownika do serwisu, z którego chce się wykraść ciastko. A zatem samego JSa można zaserwować z dowolnego miejsca, autorzy w jednej z wypowiedzi sugerują np. iframe’a z reklamami.

  10. @Bartosz Kolasiński
    Nie, wiadomość musi być przesłana przez serwer i zaszyfrowana. MitM w tym wypadku raczej odpada.

    Warto wspomnieć, że w Apache-u też jest możliwość używania nowszych wersji TLS przez GnuTLS, a o teoretycznym ataku na CBC IV (bo to rozpracowali autorzy BEAST-a) było wiadomo od dobrych kilku lat http://www.openssl.org/~bodo/tls-cbc.txt

    • Szkoda, że GnuTLS nie obługuje list CRL dla certyfikatów klienta

  11. Z punktu widzenia laika: czy serwery nie mogą serwować wszystkich wersji TLSa? a przeglądarka wybierać ten najwyższy dostępny? Jeśli informacja okaże się prawdziwa to chyba największa wtopa naszych “czasów” Zanim “uzgodnimy” wersje wizja mad-maxa stanie się bardzo prawdopodobna :)

    • Eustachy: mogą i robią tak (mniej więcej). Ale problem w tym, że przeglądarki na razie nie mają obsługi TLS 1.0+ (oprócz Opery). Pewnie z powoli zaczną, bo przejście na nowy protokół to jedyne rozwiązanie (jeśli wierzyć autorom BEAST-a)

    • @Piotrek Nadzieją jest jeszcze wymuszenie RC4, które nie zawiera podatności, którą najprawdopodobniej wykorzystali Rizzo & Duong. Ale po szczegóły najlepiej zaczekać do piątku.

    • @PK … chwila moment, to znaczy ze ja jestem slepy i glychy a microsoft wali scieme od wersji chyba 6 IE [ napewno 7.0 ] i ma ta opcje tak dla zabawy ? fakt jest wylaczona no ale jesli ktos nie umie sobie skonfigurowac softu to niech nie placze ze cos nie tak dziala, w IE8 jest nawet TLS 1.2, fakt faktem sa one nie wlaczone, ale to jest standard jak na microsoft i ich software, ze trzeba najpierwsz wszystko skonfigurowac zeby dzialalo.

    • @angel no to chyba jesteś ślepy tu masz to co ma IE8: http://imageshack.us/photo/my-images/9/ie8xg.jpg/
      TSL 1.0 i nic więcej.

    • Chrome już ponoć wprowadził fix. Rozbija requesty na fragmenty. Dodatkowo warto zapoznać się z tym tekstem: http://practicalcrypto.blogspot.com/2011/09/brief-diversion-beast-attack-on-tlsssl.html

  12. Czy wszelkiego rodzaju NoScripty pozwalają choć trochę się zabezpieczyć?
    Tak troszkę, troszeczkę, troszunio. ;)

    • Tak wg mnie tak. NoScript blokuje wykonanie skryptow domyslnie na stronie. Jesli skrypt zostanie zablokowany / nie uruchomiony to atak sie nie powiedzie… Przynajmniej ja tak to widze.

      Pozdrawiam.

      Andrzej

    • O ile atak nie będzie dotyczył np. youtube, a na youtube masz wyjątek w NoScript, bo inaczej nie zagra ci video ;)

    • @Piotr: na YouTube obejrzeć film to akurat można, do tego JS nie jest wymagany :) Ale np. komentarza już się nie doda, a miniaturki proponowanych filmów nie będą się wczytywać.

    • Prawda to niestety… Tak samo w bankowosci internetowej wymagane sa skrypty… wiec zeby strona zostala poprawnie wyswietlona… bedziesz musial zezwolic na skrypty w przegladarce.

      Mam racje Piotrze?

      Btw. Podeslalem Wam cos na maila.

      Andrzej

  13. Drobna, acz kluczowa korekta – potrzebny jest atakujący Javascript (przemycony np. XSSem albo malwaretisingiem) _i_ pasywny MitM. Działa to tak, że Javascript wysyła requesty do atakowanego serwera (chosen plaintext), które sniffer podsłuchuje (a więc MitM) i kawałek po kawałku deszyfruje. Man-In-The-Middle musi być, bo konieczny jest dostęp do ciphertextu przecież.

    Więcej można poczytać np. tu:
    http://www.ietf.org/mail-archive/web/tls/current/msg08032.html

    • przebrnąłem przez tę listę, gdzie masz info o wymogu sniffera, nie neguje ze potrzeba, ale nie moglem sie doszukac?

      tak sie zastanawiam czy nie mozna ciphertxt wyciagnac jakos za pomoca js zeby pominac mitm no bo mitm wymaga bycia w lanie ofiary. ktos ma pomysl, czy sam js styknie?

      [A atak z tego co widze polega na generowaniu przez ten js requestow do serwera ze swoimi danymi i badanie odpowiedzi a na tej podstawie wnioskowanie co jest kluczem.]

    • @grizly

      “The stealthy piece of JavaScript works with a network sniffer to decrypt encrypted cookies a targeted website uses to grant access to restricted user accounts. ” z http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

      Jeśli miałbyś tylko część Javascriptową, miałbyś dostęp tylko do plaintextu requestu/odpowiedzi, więc nie miałbyś danych do wnioskowania o kluczu. Atak skonstruowany jest tak, że JS wysyła plaintext, a sniffer słucha ciphertextu (i np. uzgadniają coś między sobą poprzez pakiety HTTP na dowolną domenę).

      Javascriptem nie uzyskasz ciphertextu, bo szyfrowanie odbywa się na niższym poziomie.

      Czy atak polega na badaniu odpowiedzi – nie wiem, możliwe, ale raczej wydaje mi się, że badany jest sam request (szyfrowany). Poleganie na odpowiedzi wymuszałoby znajomość samej aplikacji (skąd wiesz, jaki response dostaniesz, jaka będzie kolejność nagłówków, jaka ich treść, kiedy WAF zablokuje itp.) – a tak jest prościej, bo wysyłasz x requestów i nie interesuje Cię, co z nimi zrobiła aplikacja, tylko jakie cookie przesyłasz.

  14. Cytując artykuł: “Niestety, pomimo tego, że bezpieczniejsza wersja TLS, czyli 1.1 jest dostępnya od 2006 roku, praktycznie wszystkie webserwery ciągle korzystają z podatnego na atak TLS 1.0” więc zdaje się że nie do końca winne są same przeglądarki.

    • No nie do końca: to, że korzystają z TLS 1.0 nie znaczy, że nie udostępniają także nowszych wersji…

  15. Tytuł taki że się przestraszyłem że RSA złamali ;)

    • RSA juz dawno padlo, chyba przespales atack sprzed paru miesiecy
      i zeby sie nikt nie czepial – jest zlamane, stare klucze sa zlamane [ czyli jak w starych protokolach tutaj ], jesli nie masz nowego klucza RSA bo “oszczedziles” to sie martw

    • Ale nie znaleźli sposobu na szybką faktoryzację, o.

  16. Ahem.
    Dobry link do opisu, jak działa atak:
    http://news.ycombinator.com/item?id=3015498

    W szczególności, pragnę zwrócić uwagę, że jeśli już ktoś ma dostęp wystarczający do wykonania MITM na HTTP, to nie potrzebuje w żaden sposób żadnego XSS, wystarczy tylko przejąć jakąś losową stronę HTTP i wstawić do niej iframe z JavaScriptem i podmienioną stroną domeny-ofiary (banku, PayPal, etc – domena jest po to, żeby zapewnić sobie dostęp na same-origin policy), która zajmie się atakiem known-plaintext.

    • ale mitm chyba nie jest potrzebny, potrzebny jest sniffing, a to mozna na sieciach typu wifi/wep zrobbic bez mitm.

      na marginesie, czy jak podrzuce skrypt po http to bedzie on mogl odwolywac sie do https [i na odwrot]? ktos sie orientuje? jakis resource na ten temat ktos poleci?

    • @grizli
      Powołując się na wiki, wymagany jest ten sam protokół, nazwa domeny serwera i numer portu.

    • Alan ma rację, tylko tutaj, z tego, co rozumiem, nie jest wykorzystywany XMLHttpRequest, a zwykły formularz, który można wysłać przez submit(), więc same-origin policy niekoniecznie musi mieć zastosowanie…

  17. W Operze są dostępne TLS 1.1 i 1.2, ale nie są domyślnie włączone.
    Po ich ręcznym włączeniu (i wyłączeniu SSL 3 i TLS 1.o) nie mogłem się połączyć z moimi bankami (m.in. mB…). Czy to oznacza, że systemy bankowe nie pozwalają na połączenia > TSL 1.0 ? Czy może to trzeba inaczej w przeglądarce skonfigurować?

  18. Jak to ja mówię “wszystko jest kwestią czasu”. I do tego musieli się kiedyś dobrać :)

  19. Czyli jak mamy stronke po https to umieszczony na nim exploit javascript nie potrafi po prostu przesłac ciacha z kompa ofiary na dowolny adres??

  20. “rozszfrowuje”

  21. Nie ma zadnych dowodow na to, ze to w ogole atak na TLS/SSL i ze doszlo do zlamania protokolu czy nawet implementacji. Lubicie ganic “komentatorow” ktorzy wytykaja wam odswiezanie newsow – ok. ale jesli juz skupiacie sie na “przedrukach” robcie to rzetelnie…

    • Nie, krwa, skądże znowu :> Poguglaj sobie za nazwiskami obydwu gości co stoją za tym toolem. Popatrz ma icj przeszłość ,wątpie żeby ściemiali z tym Beast’em. Oczywiście możecie się spierać co znaczy złamać i co dokłądnie zostało złamane. Czy AES czy SSL czy TLS, czy może security model przeglądarki. Ja to mam w dupie. Jest realny atak, można sporo zyskać. Wy się spierajcie o terminologie, ja ide kroić użytkowników :>

      A tak BTW to zarzucasz brak rzetelnosci niebezpiecznikowi i oskarzasz vi’currego o jakies przedruki a ja widze ze to JEDYNY serwis ktory uspokaja ze do ataku wymagany jest MITM i w dodatku niebezpiecznik jako JEDYNY serwis wspomnial o tym, ze atak dotyczy CBC/AES’a i ze przejscie na szyfr strumieniowy moze rozwiazac sprawe. Tylko ze czytac to trzeba umić :]

  22. Muszę niestety się zgodzić z przedmówcami, że co innego „szyfrowanie SSL/TLS 1.0 złamane”, a co innego współpraca kilku ataków, żeby odszyfrować wiadomość w konkretnym przypadku. Fakt.

    A osobę chcącą się doczepić, że niemniej jednak atak na przeglądarki wciąż jest poważny informuję, że wcale nie neguję tego faktu.

  23. IE8 ma TLS 1.1 i 1.2 na mojej maszynie….

    http://imageshack.us/photo/my-images/16/tls12.png/

Odpowiadasz na komentarz mcv

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: