20:00
23/2/2010

Pomimo tego, że zarówno WP jak i O2 pozwalają zalogować się na pocztę przy użyciu bezpiecznego protokołu (SSL), szyfrowanie transmisji nie zostało zastosowane w formularzu zmiany hasła. Dlatego atakujący znajdujący się w tej samej sieci co ofiara lub mający kontrolę nad którymkolwiek z urządzeń sieciowych pomiędzy ofiarą a serwerami WP albo O2 może podsłuchać zarówno stare jak i nowe hasło użytkownika.

Hasło użytkownika o2, podsłuchane podczas jego zmiany

“Dziura” nie taka straszna jak ją malują

W naszej ocenie błąd w poczcie WP czy O2 nie jest taki groźny, jak przedstawiają go inne serwisy (kaman, jak często zmieniacie hasło do e-maila?). Twierdzimy wręcz, że tak jak przed wykryciem tego błędu tak i po jego załataniu dalej będzie można podejrzeć czyjąś pocztę. Słowa klucze: session hijacking i cookie stealing.

Mogą naprawić formularz zmiany hasła, ale niewiele to da

Zauważcie, że przytłaczająca większość portali, aby zwiększyć “wydajność” połączenia (transfer, cpu) nie zapewnia szyfrowania przez cały czas trwania połączenia z web-pocztą. Transmisja jest szyfrowana tylko podczas logowania do poczty (hasło leci po SSL-u).

Poprawne zalogowanie się w poczcie oznacza przydzielenie klientowi-przeglądarce unikalnego identyfikatora sesji (Session ID), który jest ustawiany poprzez ciasteczko (HTTP cookie). Ciasteczko to jest następnie przesyłane pomiędzy przeglądarką a serwerem przy każdym “kliknięciu” (żądaniu) BEZ SZYFROWANIA. Wystarczy je podsłuchać (Wiresharkiem), zaimportować do swojej przeglądarki i już jesteśmy na poczcie danej osoby, bez znajomości jej hasła.

WP, podobnie jak O2 i Onet nie przesyłają ciasteczek z ID sesji po SSL-u

Część portali może się ratować powiązaniem Session ID z adresem IP klienta lub User-Agentem przeglądarki. Ale nie wszyscy się na to decydują, gdyż w niektórych sytuacjach rodzi to problemy z utrzymaniem “oryginalnej” sesji. Zresztą jeśli ktoś jest w stanie podsnifować ciastko, to znaczy, że jest też w stanie podsnifować całe połączenie, a zatem i treść czytanych e-maili (wyłączając oczywiście przypadki z ciastkami HTTP-Only).

Na co najmniej jednym z popularnych w Polsce portali świadczących usługi internetowe “kradzież ciastka” jest możliwa — przez grzeczność nie zdradzimy, o którym serwisie mowa, sugerujemy sprawdzić, jak jest w przypadku waszego dostawcy web-poczty. GMail np. szyfruje całe połączenie z pocztą, a nawet jeśli wyłączy się szyfrowanie, to i tak SSL zostanie użyty na czas logowania, a ciasteczko zawsze zostanie wysłane po HTTPS:

Google ustawia dla swojego ciasteczka flagę secure.

Trzymaj się z dala od poczty po WWW

Nie sądziliśmy, że kiedyś to napiszemy, ale do czasu puszczenia formularzy zmiany haseł w O2 i WP po SSL-u, powstrzymajcie się od zmiany haseł …a najlepiej w ogóle nie korzystajcie z e-maila po WWW na polskich portalach, dopóki nie zaczną one przesyłać ciasteczek tylko po SSL-u i z HTTP-only.

Za podesłanie informacji o błędzie w WP dziękujemy Maćkowi Z.

P.S. Sprawdzenie czy “kradzież ciastka” powiedzie się również w przypadku Allegro lub Naszej-Klasy pozostawiam czytelnikom jako pracę domową ;-> Oczywiście pamiętajcie o art. 267 i pracę domową odrabiajcie wyłącznie na własnej sesji.

[Aktualizacja, 23.02.2010, 11:33]
1. Wirtualna Polska już wczoraj poprawiła błąd, przerzucając formularz do zmiany hasła na HTTPS. O2 od dziś również oferuję “bezpieczną zmianę hasła”. Jest to na pewno krok naprzód, ale wciąż czytanie poczty przez WWW w polskich portalach nie jest 100% bezpieczne. Dalej nierozwiązany pozostaje problem przechwycenia sesji (flagi “secure” i “httponly” w ciasteczkach).
2. Paweł Goleń w komentarzu poniżej słusznie zauważył jeszcze jeden problem w polskich serwisach świadczących dostęp do poczty elektronicznej za pomocą WWW — formularz logowania do poczty pobierany jest po HTTP. Cytując Pawła: “Atakujący znajdujący się “na kablu” (w sieci lokalnej lub “po drodze”) może dowolnie zmodyfikować formularz logowania i cały ten SSL (dumne komunikaty “bezpieczne logowanie SSL”) można sobie w buty wsadzić”.

[Aktualizacja, 23.02.2010, 15:06]
Napisał do nas Pan Bartosz Wojciechowski z działu prawnego Grupy Allegro, który zwrócił uwagę, że treść P.S. w tym poście “wydaje się wypełniać znamiona przestępstwa określone w art. 267 w zw. z art. 18 § 2 k.k. a zagrożony karą pozbawienia wolności do lat 2. W związku z powyższym oczekuję stosownej edycji wzmiankowanego tekstu oraz unikanie w przyszłości podobnych przypadków naruszenia prawa.

Aby P.S. nie “wydawał się wypełniać” jak pisze Pan Bartosz i żeby było jasne, że stoimy po jasnej stronie mocy, dopisaliśmy do P.S.-a zdanie “Oczywiście pamiętajcie o art. 267 i pracę domową odrabiajcie wyłącznie na własnej sesji”. Przy okazji serdecznie pozdrawiamy zawsze czujny dział prawny Allegro i oczywiście resztę pracowników Allegro, z których wielu jest naszymi stałymi czytelnikami :-)

Przeczytaj także:

35 komentarzy

Dodaj komentarz
  1. Szczęściem, jak stary, uparty osioł, od zawsze korzystam z desktopowego klienta. Bo – jak rozumiem – tu nie ma żadnych luk?

  2. Uff na szczęście korzystam z GMaila (ale on pewnie tez ma swoje słabości, o których nie wiem). Mam natomiast pytanie: jak jest w przypadku aol.pl?
    Co oni szyfrują, a co nie?

  3. Rzeczywiście udało Ci się zaimportować ciasteczko sesyjne WP do innej przeglądarki i zalogować się na konto, czy tylko sugerujesz, że tak da się zrobić?

  4. Np. poczta.neostrada.pl nie SSL-uje ani SMTP, ani POP3! Od tego tym bardziej trzymajcie się z daleka. Lepiej nawet niż SSL – TLS (ale bez jakichś haczyków “TLS, jeśli dostępne” – bo to groźne – http://www.heise-online.pl/security/features/Diagnozowanie-komunikacji-POP3-IMAP-i-SMTP-zabezpieczonej-przez-SSL-813575.html)

  5. Po zbadaniu allegro wiresharkiem uznaje, że do allegro też trzeba wysłać cały sessid. Wysyła go tak jak przy wp. Nasza-klasa nie robi tego tak, a bynajmniej nie widać po zapytaniach, ale za to przy logowaniu wszystko jest plain textem.

  6. W mojej ocenie błąd jednak jest groźny. Zauważ Piotrze, że podejrzenie czyjegoś hasła jest zdecydowanie groźniejsze niż przytoczone przez Ciebie przejęcie sesji! Po pierwsze, przejęcie sesji nie pozwala intruzowi na całkowite przejęcie kontroli nad kontem (czyli np. zmianę hasła dostępowego). Po drugie, podejrzenie hasła do poczty, w przypadku większości internautów, oznacza poznanie ich haseł stosowanych również w innych serwisach…
    Błąd jest więc poważny. Tym bardziej, że serwisy te chwalą się wszędzie, że hasła ich użytkowników są bezpieczne dzięki przesyłaniu ich wyłącznie w postaci szyfrowanej… duża wpadka i tyle.

    • Wojtku, oczywiście, tego błędu nie można zignorować. W naszej ocenie nie jest on jednak straszny. Zapytam jeszcze raz — ile razy zmienia się hasło do e-maila? Chciałbym poznać statystyki portali, odnośnie wykorzystania tej opcji wśród użytkowników — strzelam w okolice 1%?

      Poznanie hasła oczywiście pozwala na sprawdzenie czy w innych serwisach ofiara też stosuje takie samo hasło. Z tym tylko wyjątkiem, że szyfrowanie może do formularza zostać dodane i ten wektor ataku szlag trafi. A tymczasem, w tych samych warunkach atakujący może dalej sniffnąć ciastko, przejąć sesje i skorzystać z procesu resetowania hasła na kolejnych serwisach/kontach do których chce się włamać (bo przecież restet-mail spłynie w większości przypadków na podsłuchiwaną, session-hijackniętą skrzynkę ;-) W mojej opinii to jest pewniejsza metoda. Zauważ, że nawet jeśli znasz czyjeś hasło do skrzynki pocztowej, to nie masz pewności, czy ta osoba wykorzysta(ła) dokładnie to hasło w innym serwisie (chociażby ze względu na różne wymogi co do długości, znaków specjalnych, etc.

      Tak więc wpadka — OK, ale nie zgodzę się, że duża.

  7. Pozwolę sobie wspomnieć jeszcze jedną ciekawą rzecz, gazeta.pl która od jakiegoś czasu hostuje swoją pocztę na serwerach googla, jako stronę logowania używa http://www.poczta.gazeta.pl , bez https i innych bajerów, trudno coś z tym zrobić? ;)

  8. A mamusia mówiła:”Zmieniaj synuś hasła co miesiąc,bo tak bezpieczniej” :D

  9. To ja chciałem zwrócić uwagę na coś innego. Sprawdźcie sobie jak wygląda URL do poczty ze stron głównych np. na Onet.pl, wp.pl albo o2.pl. Podpowiem – zaczyna się od http://. Oznacza to tyle, że formularz logowania pobierany jest po HTTP a nie HTTPS. Efekt? Atakujący znajdujący się “na kablu” (w sieci lokalnej lub “po drodze”) może dowolnie zmodyfikować formularz logowania i cały ten SSL (dumne komunikaty “bezpieczne logowanie SSL”) można sobie w buty wsadzić.

    By było bezpiecznie(j), powinno wyglądać to tak:
    - brak dostępu po HTTP,
    - formularz logowania pobierany po SSL,
    - cała komunikacja po SSL (co oczywiste, HTTP przecież nie ma),
    - losowy identyfikator sesji zmieniany po uwierzytelnieniu,
    - jeśli identyfikator przekazywany jest w cookie – dodatkowe zabezpieczenia, w szczególności flagi httpOnly oraz Secure, poprawnie ustawione path,
    - odpowiednia domena(!),

    Jest jeszcze parę innych detali, ale wiele razy pisałem na ten temat u siebie na blogu, więc powtarzać się nie będę.

  10. Poczta o2 MA włączoną funkcję httpOnly dla ciasteczek sesji.

    • firem: zakładam, że odnosisz się do fragmentu: “dopóki nie zaczną one przesyłać ciasteczek tylko po SSL-u i z HTTP-only” i zakładam, że rozumiesz co znaczy koniunkcja. Czekamy zatem na koniunkcje w o2 ;-) Http-only niestety łata połowe sita, a połowy mają to do siebie, że to tylko 50% :-)

  11. @firem: Jakoś nie widzę, żeby o2 ustawiło HTTPonly:

    http://img193.imageshack.us/img193/1285/o2irzekomehttponly.png

    Set-Cookie: ssid=eu1PHWQGOGJSkMSUS6hK2RsaHz5hnJIvMKcjnJIwrz5cnmL2AtN0l; domain=poczta10.o2.pl

    Wyjaśnisz?

  12. @Paweł Goleń
    Dobra uwaga. Szczerze mówiąc bank z którego korzystam pozwala na połączenie po HTTP. Zaraz następuje przekierowanie na HTTPS, no ale sslstrip jest wśród nas :)

  13. @igH: masz rację, kiedyś było, teraz gdzieś przepadło.
    BTW już jest szyfrowana zmiana hasła na o2.

  14. @firem: ja na Twoim miejscu nie przyznawałbym się publicznie, że funkcje bezpieczeństwa w o2 “gdzieś przepadają”…

    Zaraz się upewnimy czy to szyfrowanie faktycznie jest i jesli nie będzie tak jak z httpOnly to zaktualizujemy tekst ;-]

  15. @Paweł Goleń

    Były dokumenty na ten temat, czy lepiej jest mieć formularz logowania ‘jeszcze’ po http czy ‘już’ po https. Zdania były podzielone.

    Co do httpOnly HTTP Only itp. chyba nie wszyscy wiedzą z czym to sie je na co po co i dlaczego

    • wheelq: Żeby wszyscy zatem wiedzieli “z czym sie je” httpOnly “na co po co i dlaczego”, pozwolę sobie wyjaśnić jednym zdaniem: ustawienie tej flagi w ciastku ukrywa je przed skryptami, co w konsekwencji pozwala zmniejszyć ryzyko XSS-a, zwłaszcza w kontekście kradzieży ciastek przez document.cookie.

  16. Bardzo obrazowe przedstawienie zagadnienia. Po raz pierwszy mogłem się przekonać, że cała ta sprawa z SSLami i szyfrowaniem połączeń nie jest tylko teoretyzowaniem.

  17. ” Żeby wszyscy zatem wiedzili “z czym sie je” httpOnly “na co po co i dlaczego”, pozwolę sobie wyjaśnić jednym zdaniem: ustawienie tej flagi w ciastku ukrywa je przed skryptami, co w konsekwencji pozwala zmniejszyć ryzyko XSS-a, zwłaszcza w kontekście kradzieży ciestek przez document.cookie.”

    Bardzo ładnie :)

    Zapisać, Zapamiętać, jeżeli trzeba to Zastosować

  18. @wheelq

    A możesz przedstawić argumenty za tym, że przesłanie formularza logowania po HTTP jest bezpieczne? W szczególności jaką użytkownik ma gwarancję, że formularz logowania, który dociera do jego przeglądarki jest tym samym formularzem, który został wysłany przez serwer? A skoro formularz może zostać podmieniony “w locie” to dane wpisane przez użytkownika mogą zostać wysłane gdziekolwiek. W skrócie – w tym zakresie mam wiele wspólnego z elektoratem PiS, nikt mnie nie przekona, że czarne jest czarne.

  19. Dlatego zdania były podzielone. Postaram się wygooglować dokument. Pamiętam ze chodziło o analizę pakietów z SSL przed logowaniem/ po logowaniu. Sam nie pochwalam takiego rozwiązania, tylko mowię że było takie coś argumentowane

  20. mam wrazenie z każdym dodanym komentarzem pogrążasz sie w swojej niewiedzy ;)
    to ze ustawisz httponly nie sprawi, że znikna xss’y :) owszem ustawienie httponly zmniejsza impact ataków XSS, ale nie sprawią że twoj kod się naprawi.
    W Twoim przykladzie zakladasz, że napastnik sniffuje ruch – czyli i tak HttpOnly nie ukryje ciasteczka przed wscibskim wiresharkiem. Tak z ciekawości po co tobie dostep do hasla użytkownika, skoro ten nieszczęśnik korzysta z polaczenia umożliwiającego zastosowanie ataku MITM (podrzucić pdf’a w odpowiedzi – teraz to takie modne :)

    • @slodka.jola — doprecyzuj prosze do czyjej wypowiedzi odnosi sie Twoj komentarz.

  21. Parę innych detali – szyfrowanie GPG, PGP albo X.509 (wystawione przez uznany autorytet) samej wiadomości, a nie tylko połączenia z serwerem, bo chińscy hakerzy będą ci czytali wiadomości. IDS/IPS na serwerze poczty. Sensownie zabezpieczony system operacyjny (firewall, antywirus, wyłączenie Flasha, JavaScriptu, QuickTime i innych pluginów), na którym uruchamiasz klienta poczty… Mnożyć można bez końca, jak zabezpieczyć naszą wiadomość email do Józia, że “Kocham Pet Shop Boys”.

  22. @różni ludzie – http-only-sronly – w 2010 tak się kradnie ciastka http://www.blackhat.com/html/bh-dc-10/bh-dc-10-archives.html#AlvarezMedina – poza tym po co wysyłać sobie na serwer document.cookie – jak można będąc “JavaScriptem” u zalogowanego użytkownika można zrobić mnóstwo inych rzeczy mu ze stroną i zawartymi danymi – choćby nawet pophishować, po której chodzi (zdaje się data: dobrze obchodzi same-origin policy) – formularze, iframki, może zaciągnąć jakąś Javę, ActiveX, może normalnie-legalnie trojana w exec-u, że niby wymagany plugin… To alert(‘document.cookie’) to taka zretardziała demostracja podatności na XSS – jest mnóstwo dokumentów jak użyteczniej zastosować XSS w zależności od waszych potrzeb. Nie chcę już czytać setny raz, że groźne XSS to wysłanie document.cookie na swój serwer GET-em.

  23. Idąc dalej tropem komentarzy Pawła: nawet jeśli serwis jest w całości dostępny przez SSL i ma ustawione httpOnly i secure w ciasteczkach, to atakiem MITM można nadal:
    - narzucić id sesji – przy requeście http do dowolnego serwisu doklejamy w odpowiedzi jakikolwiek element http z domeny serwisu atakowanego, nawet nieistniejący, po czym sami na niego odpowiadamy ustawiając odpowiednie ciastko
    - “zSSLstripować” cały serwis, jeśli użytkownik trafia do niego linkiem z dowolnej strony HTTP, a nie z zakładki/ręcznie wpisanego “https://…”
    - zgodnie z sugestią Joli – podrzucić w dowolnym połączeniu http exploita, co skutecznie eliminuje problem SSLa
    itd.

    Czekam na pierwszą przeglądarkę, która będzie wpisane adresy domyślnie interpretować jako https ;)

  24. A w allegro to inaczej?

    http://allegro.pl/myaccount/mysettings.php

    Formularz zmiany hasła także jest nie szyfrowany, a znaczenie tego hasła jest dużo większe niż w przypadku jakichś tam darmowych skrzyneczek pocztowych.

  25. Rzut pomysłem: Tabelka z popularniejszymi (polskimi) serwisami (pogrupowanymi wg kategorii), podatnościami i zaznaczeniem, czy dany serwis jest podatny. Z możliwością dopisywania kolejnych serwisów i podatności, oczywiście (wiki?). Mogłoby ułatwić userom wybór bezpieczniejszego (niekoniecznie bardziej popularnego) serwisu. Dla serwisów też mogłaby to być motywacja do poprawienia serwisów.

  26. [...] transmisję danych, może łatwo odczytać wszystkie przesyłane w niej informacje (por. błąd w formularzach zmiany haseł w polskich [...]

  27. [...] Kradzież Googlowych ciastek a prywatność Kilku śmiałków zwędziło nielatające SSL-em ciasteczka użytkownikom serwisów Google’a i pogrzebało im w historii wyszukiwania. Podobny atak na sesję, do pewnego stopnia wyjdzie większości polskich portali. [...]

  28. Mimo, że zmiana hasła jest rzadka to jednak może stać się niebezpieczna o ile napastnik uzyska dostęp do większego punktu przez który lecą pakiety. Potem odpowiednie filtrowanie i mamy zwycięzców “straconego” konta.

  29. Dzięki tej akcji poprawiono również możliwość bezpiecznego zakładania kont (o2), chociaż wcześniej tego nie planowano….

    https://poczta.kontakt.o2.pl/index.php?help_o2=0&dzial=answer&x=304218&y=983110&auth=4ae76a094766149959882cd0b153ff31

  30. “Napisał do nas Pan Bartosz Wojciechowski z działu prawnego Grupy Allegro, który zwrócił uwagę, że treść P.S. w tym poście “wydaje się wypełniać znamiona przestępstwa określone w art. 267 w zw. z art. 18 § 2 k.k. a zagrożony karą pozbawienia wolności do lat 2. W związku z powyższym oczekuję stosownej edycji wzmiankowanego tekstu oraz unikanie w przyszłości podobnych przypadków naruszenia prawa.””

    Szkoda, że Bartuś nie zwrócił uwagi, że:

    “Administrator danych jest obowiązany zastosować środki techniczne i organizacyjne zapewniające ochronę przetwarzanych danych osobowych odpowiednią do zagrożeń oraz kategorii danych objętych ochroną, a w szczególności powinien zabezpieczyć dane przed ich udostępnieniem osobom nieupoważnionym, zabraniem przez osobę nieuprawnioną, przetwarzaniem z naruszeniem ustawy oraz zmianą, utratą, uszkodzeniem lub zniszczeniem (art. 36 ust. 1 ustawy). ”

    Jak zwykle kij ma dwa końce i aż dziwię się, że nie poszedł jakiś pozew od zdenerwowanego użytkownika.

  31. “Napisał do nas Pan Bartosz Wojciechowski z działu prawnego Grupy Allegro, który zwrócił uwagę, że treść P.S. w tym poście “wydaje się wypełniać znamiona przestępstwa określone w art. 267 w zw. z art. 18 § 2 k.k. a zagrożony karą pozbawienia wolności do lat 2. W związku z powyższym oczekuję stosownej edycji wzmiankowanego tekstu oraz unikanie w przyszłości podobnych przypadków naruszenia prawa.””

    Treść wysłana przez “pana” Bartosza wydaje się wypełniać znamiona grubiaństwa i bezczelności określone zasadami savoire – vivre zagrożona pokazaniem międzynarodowego znaku fuck. Kim ty w ogóle jesteś panie wojciechowski?! Kimś lepszym, bo pan nie prosi o edycję tylko jej oczekuje i jeszcze poucza ludzi z niebezpiecznika, kiedy oni są od pana 100 razy mądrzejsi. Współczuję pańskim rodzicom że pana lepiej nie wychowali.

Twój komentarz

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

RSS dla komentarzy: