Kilka dni temu w sieci pojawił się plik ze 153 milionami kont użytkowników Adobe. Jest to efekt ujawnionego przed miesiącem włamania do tej firmy. Prawie milion spośród wykradzionych kont posiada adres email w domenie .pl.
Wśród prawie miliona polskich kont znajdziemy ponad tysiąc kont w domenie gov.pl, ponad 5 tysięcy w domenie .edu.pl i setki kont największych polskich firm. Jak te informacje trafiły do sieci? Miesiąc temu pisaliśmy o poważnym włamaniu na serwery Adobe, w trakcie którego skradziono dane użytkowników oraz kod źródłowy kilku programów. Włamanie zostało odkryte przez dziennikarza Briana Krebsa, który trafił na dane z niego pochodzące w trakcie pisania jednego ze swoich artykułów. Zaraz po ujawnieniu włamania Adobe przyznało się, że wyciekły dane ok. 3 mln kart kredytowych oraz kod źródłowy Acrobat Readera oraz ColdFusion. Okazuje się, że wyciek był jeszcze poważniejszy – objął również dane ok. 153 milionów klientów firmy (i przy okazji także kod źródłowy Photoshopa).
Ponad 9 GB danych klientów
Tydzień temu w serwisie AnonNews.org pojawiły się linki prowadzące do dwóch plików: users.tar.gz oraz ldap.tar.gz. Pierwszy z nich zawierał dane klientów Adobe, drugi spis kont firmowego serwera LDAP. Pliki były umieszczone na zhakowanym serwerze, skąd jednak bardzo szybko zniknęły. Również wątki na forum AnonNews nie przetrwały długo, usunięto je nawet z pamięci Google’a. Jak jednak pewnie wiecie, w przyrodzie nic nie ginie i na rosyjskich forach pojawiły się kopie danych. W sieci znalazły się już pierwsze analizy bazy użytkowników Adobe. Dzięki życzliwemu czytelnikowi możemy podzielić się z Wami niektórymi statystykami danych, zawartych w plikach.
Fragment ujawnionego pliku
Bez wątpienia mamy do czynienia z największym do tej pory opublikowanym wyciekiem listy kont, adresów email i zabezpieczonych haseł, pochodzących z jednego serwisu. Po rozpakowaniu archiwum users.tar.gz trafiamy na plik o rozmiarze ponad 9 GB, w którym znajduje się ponad 153 milionów wierszy z danymi użytkowników. Dane mają format:
ID-|--|-adres email-|-zaszyfrowane hasło-|-podpowiedź do hasła|--
Ponad 130 milionów wierszy zawiera wartość w polu hasła, z czego ponad 56 milionów haseł jest unikatowych. Co najciekawsze, hasła nie są haszowane, a szyfrowane. Adobe użyło do zabezpieczenia haseł algorytmu symetrycznego Triple DES w trybie ECB. Co to oznacza?
Dobra i zła wiadomość
Fakt, że hasła zostały zaszyfrowane algorytmem symetrycznym, może być zarówno dobrą, jak i złą wiadomością zarówno dla użytkowników jak i dla włamywaczy. Jeśli klucz szyfrujący jest trudny do odgadnięcia (a w przypadku Triple DES, w zależności od rodzaju użytych kluczy, może mieć złożoność od 2^56 do 2^168), to zaszyfrowane hasła są raczej bezpieczne. Jeśli jednak komukolwiek uda się odgadnąć klucz lub włamywacze go zdobyli i kiedyś ujawnią, to wszystkie, nawet najbardziej skomplikowane i losowe hasła z pliku natychmiast zostaną odszyfrowane.
Fakt, że mamy do czynienia z dużą ilością pojedynczych haseł, potencjalnie może ułatwić próby złamania klucza użytego do ich zaszyfrowania. Atakujący mogą powiem przeprowadzić ataki w oparciu o znany tekst jawny – nie będzie trudno odgadnąć, jakie hasła mogą występować w pliku najczęściej. 3DEs uznawany jest jednak za dość bezpieczny algorytm i mimo, że znane są teoretyczne ataki, obniżające poziom złożoności zgadywania klucza, to nie spotkaliśmy się z ich praktyczną implementacją (może Czytelnicy będą w stanie podać nam w komentarzach więcej informacji na ten temat).
Zastosowanie trybu ECB w szyfrowaniu 3DES powoduje, że możemy dowiedzieć się trochę więcej o hasłach użytych przez użytkowników Adobe. Jako że w tym trybie szyfrowane są bloki po 64 bity, po długości zaszyfrowanego hasła możemy wywnioskować przedział, w jakim mieści się długość hasła. Wykorzystaliśmy tę właściwość w statystykach „polskich” haseł poniżej.
Polska część wycieku
Z uwagi na fakt, że wiele osób korzysta z kont pocztowych w domenach innych niż .pl, trudno oszacować pełną skalę wycieku danych Polaków. Bez wątpienia jest ona większa, niż 968,742 konta w naszej narodowej domenie. Jakie polskie domeny są najliczniej reprezentowane w wycieku?
282,896 wp.pl 165,182 o2.pl 86,085 interia.pl 71,551 op.pl 45,377 poczta.onet.pl 37,507 tlen.pl 29,674 vp.pl 19,555 onet.pl 14,918 gazeta.pl 10,848 buziaczek.pl 8,109 go2.pl 5,864 autograf.pl 5,325 neostrada.pl 4,464 amorki.pl 4,273 yahoo.pl 1,946 tenbit.pl 1,927 post.pl 1,814 orange.pl 1,726 spoko.pl 1,610 plusnet.pl
Powyższa lista wyraźnie wskazuje, że w bazie Adobe znajdowały się zarówno dane bieżące, jak i mocno historyczne (jak np. kiedyś popularny tenbit.pl). Jak wygląda reprezentacja niektórych co ciekawszych domen?
5042 edu.pl 1184 gov.pl 29 policja.gov.pl 10 sejm.gov.pl 7 mon.gov.pl 4 prezydent.pl 3 abw.gov.pl 3 skw.gov.pl 2 niebezpiecznik.pl ;) (ok. 23 milionów najnowszych wpisów nie zawiera haseł i niebezpiecznikowe adresy stworzone na potrzeby rejestracji produktów Adobe znalazły się w tej puli)
Jak wyglądają statystyki haseł użytych dla kont z domeny .pl? Z 968,742 haseł prawie dokładnie połowa, bo 479,159 to hasła unikalne. Jeśli chodzi o długość użytych haseł, to:
1 - 7 znaków: 523,548 8 - 15 znaków: 444,720 16 - 23 znaków: 417 24 - 31 znaków: 50 32 - 39 znaków: 3 40 - 47 znaków: 3
Niestety dla posiadaczy długich haseł – jeśli zostanie ujawniony klucz szyfrujący, to długość tutaj nic nie pomoże…
Jakie będą skutki
Firma już miesiąc temu poinformowała swoich klientów o możliwym wycieku i zresetowała ich hasła. Nie wiemy, czy informacja dotarła na wszystkie 153 miliony adresów poczty elektronicznej, ponieważ Adobe sprytnie informuje, że wyciekły dane „zaledwie” 38 milionów klientów (w domyśle mowa jedynie o klientach aktywnych). Reset hasła to dobry krok, jednak choć indywidualne konta użytkowników w innych serwisach mogą być zagrożone, to najważniejszym skutkiem tego wycieku może być niespotykana poprawa jakości słowników osób, zajmujących się łamaniem cudzych haseł.
Skuteczność łamania haszowanych haseł zależy nie tylko od mocy obliczeniowej, którą dysponuje osoba łamiąca, ale przede wszystkim od skuteczności (niekoniecznie idącej w parze z rozmiarem) użytego słownika. Słownik, zawierający prawdziwe, kiedyś użyte hasła, może być wielokrotnie skuteczniejszy od nawet tysiąc razy większego słownika, zawierającego np. wszystkie słowa z Wikipedii. Mały słownik z dużą ilością potencjalnych „trafień” pozwala na szybkie zastosowanie wielu skomplikowanych reguł budowy haseł i odsianie haseł prostych lub znanych, by móc skoncentrować się na łamaniu pozostałych. Do tej pory najcenniejszym zbiorem prawdziwych haseł był słownik pochodzący z włamania do serwisu RockYou.com, który przechowywał hasła swoich 32 milionów klientów otwartym tekstem. 14 milionów unikalnych haseł zasiliło słowniki na całym świecie, walnie przyczyniając się do poprawy jakości łamania. Gdyby pojawił się klucz, pozwalający odszyfrować 56 milionów unikatowych haseł, pochodzących z włamania do Adobe, byłby to niezwykły prezent dla osób zajmujących się bezpieczeństwem haseł.
Komentarze
A czy to nie jest tak, że wystarczy zestawić liczebności unikalnych haseł z tego wycieku z najczęściej powtarzającymi się (znanymi) hasłami z jakichś badań i spróbować odczytać klucze na podstawie, powiedzmy, top 10 haseł?
Jestem laikiem, wybaczcie…
Wybaczamy ;) To, co proponujesz, nazywa się w kryptografii „atak ze znanym tekstem jawnym” (http://pl.wikipedia.org/wiki/Atak_ze_znanym_tekstem_jawnym) i świetnie działa w przypadku niektórych szyfrów, szczególnie tych o prostej konstrukcji. W przypadku 3DES nie jest znany skuteczny atak tego typu. Przekształcenie w czasie szyfrowania jest tak skonstruowane, by jego odwrócenie bez znajomości klucza było bardzo trudne.
Owszem, bardzo trudne. O ile przy okazji tak gigantycznego „plonu” z włamania klucz nie został wykradziony (co by było dziwne), to na pewno bardzo duża moc obliczeniowa obecnie jest zaangażowana w złamanie tego jednego, konkretnego klucza. O ile oczywiście to był jeden klucz a nie np. pula 666 kluczy i używanie klucza numer (user_id % 666).
Tak więc jedynie kwestią czasu jest wyciek tych haseł i rozsądnym jest założenie, że hasło już jest publiczne tylko niekoniecznie (jeszcze) wykorzystane.
Adobe ma ostatnio mocno pod górkę…
Oprócz powyższego – dostępne dla wszystkich przez dłuższy czas flagowe produkty wraz z kluczami aktywacyjnymi, tradycyjne już wycieki źródeł…
Gdzie można dokopać sie do pliku zeby sprawdzić czy moje konto też wyciekło?
lezy sobie na botnecie
[usunięte przez redakcję – bez linków proszę]
post napisany 30.10.2013, 09:57
http://www.reddit.com/r/netsec/comments/1pg439/adobe_breach_impacted_at_least_38_million_users/
Prawdopodobnie dlatego moja karta kredytowa została przez Vise uznana za potencjalnie zagrozoną i zabklokowana. Nie infolini nie podaja konkretnej przyczyny lecz informuja o 'zwiazku z przechwyceniem danych Pana karty’.
Adobe fail. Odbije im sie to na wynikach finansowych.
Najzabawniejsze jest to, że takie wycieki są groźne chyba tylko dla legalnych kopii softu zaś wersje spiracone były pewnie bezpieczne ;)
Bo ludzie jak te barany zgodzili się na creativecloud. Oprogramowanie w wersji box za który płacisz przelewem, gotówką czy kartą w sklepie który nie trzyma Twoich danych było dobre. Ale oczywiście Adobe musi zarobić więcej, a głupi ludzie brną w to bagno i teraz mają z tego same problemy, a w perspektywie kilku lat chmura jest droższa od wersji boxowych… ludzie są po prostu głupcami i historia wiele razy to pokazała.
Większość danych jest bardzo stara i nie ma związku z oferta cloud. Samo głupie pobranie triala wymagało założenia tam konta.
Pytanie techniczne dlaczego w 1/3 zaszyfrowanych haseł widnieje na końcu ciąg „CatHBw” ? :)
Taka cecha szyfrowania 3DES w trybie ECB – jeśli klucz jest stały a hasło ma 8 znaków, to zaszyfrowana forma zawsze będzie kończyć się tak samo (prawdziwe również bodajże dla 16 znaków. Oczywiście forma tej stałej „końcówki” zależy od klucza – tu wyszło ioxG6CatHBw==.
To nieprawda, że szyfrowanie blokowe w trybie ECB daje takie same zakończenia szyfrogramów przy tej samej długości szyfrowanego tekstu jawnego. Dla 3DES w trybie ECB każdy blok o długości 64 bitów jest szyfrowany OSOBNO, niezależnie czy jest to jeden blok, dwa bloki czy dziesięć. Szyfrując ostatni blok tekstu algorytm nie ma żadnej wiedzy o długości całego tekstu jawnego.
Jeśli szyfrogramy kończą się znakami „CatHBw==” (czyli ostatni blok jest taki sam) i do szyfrowania został wykorzystany ten sam klucz, to oznacza, że osiem ostatnich znaków odpowiadających tym szyfrogramom teksów jawnych również jest takich samych.
Nie wiem, jakiej długości są te szyfrogramy kończące się na „CatHBw==”, ale ja bym obstawiał, że mamy do czynienia z paddingiem, który uzupełnia krótsze hasła takim samym ciągiem znaków lub dodaje „dummy block”. Natomiast różnice w długości szyfrogramów mogą wówczas wynikać z różnych okresów zapisania haseł w bazie.
O ile oczywiście mamy do czynienia z trybem ECB…
Maciek, dla sprecyzowania: dla szczególnych przypadków, gdzie długość tekstu jawnego wynosi 8 lub wielokrotność 8 znaków, algorytm generuje ostatni (n+1) blok, w całości wypełniony „paddingiem” (zapewne bitowo 08), które zawsze szyfruje się tak samo.
Dla tekstów jawnych o określonej długości opisanej w artykule (przedziały) szyfrogram też jest o określonej długości, co pozwala na ustalenie orientacyjnej długości hasła jawnego.
Śmieszne jest, że kiedyś miałem tam konto (które jak przypuszczam usunąłem), a niedawno dostałem maila by zresetować hasło. Spróbowałem je zresetować, ale wyskakiwał błąd, że nie ma takiego maila w bazie.
Czyli pewno usunięcie konta, to tylko zmiana jego stanu na nieaktywne…
Na pewno jest tak jak piszesz. Nieporównywalnie trudniejsze jest stworzenie mechanizmu trwałego usuwania konta. Trzeba by usunąć wszystkie powiązane wpisy a wystarczy, że jedną by została i po integralności bazy danych. Do tego kod musiałby dodatkowo sprawdzać czy powiązane z innymi obiektami konta istnieją no i straciliby wiele cennych danych. Po prostu zwyczajnie nie opłaca się robić trwałego usuwania i jako programista ich w pełni rozumiem.
Pobierajcie i zachowajcie.
users.tar.gz – http://filecom.net/xDpje
ph1.tar.gz -http://filecom.net/F6T6PzEA
all_users_list.rar -http://filecom.net/yewUs