9:27
28/2/2012

Chyba mamy do czynienia z jakimś tygodniem wycieków… Internauta o dźwięcznym pseudonimie Abu_Nazir właśnie opublikował w internecie zrzut bazy danych serwisu Vista.pl, w którym znajdziemy dane 12740 użytkowników.

Baza Vista.pl

Opublikowane dane zawierają nick, hash hasła oraz adres e-mail wykorzystany do rejestracji.

Vista.pl DataBase

Vista.pl DataBase

Zrzuty zostały także opatrzone opisem oraz kontaktem e-mail do Abu Nazira:

Vista.pl -> DataBase -> LAST_REGISTER => 2011-05-20 22:03:10
DUMP => 2012.02.08 PUBLIC => 2012.02.27
NEXT DUMP => GRAM24.pl

Na podstawie powyższego opisu można zauważyć, że snapshot pochodzi z maja 2011, zrzucono go w 8 lutego tego roku, a opublikowano wczoraj. Skąd takie rozbieżności? Nasza hipoteza: włamywacz uzyskał dostęp do serwera backupowego, a nie produkcyjnego. A na serwerze backupowym najświeższa kopia danych pochodziła właśnie z 20 maja 2011r…

I to prawda. Naszą hipotezę ostatecznie potwierdziła rozmowa z przedstawicielami Vista.pl, których poinformowaliśmy o odnalezionym w internecie pliku. Przedstawiciel Vista.pl przyznał, że doszło do włamania na serwer backupu, na którym znajdowały się kopie baz nie tylko serwisu Vista.pl ale także Gram24.pl (release tej bazy zapowiadał Abu Nazir, teraz już wiemy dlaczego).

Na marginesie, w podobny sposób zhackowano 2 lata temu serwis JoeMonster. Najpierw natknięto się na serwery backupu bazy, z których odczytano hasła i za ich pomocą uzyskano dostęp do strony, podmieniając ją. Administratorzy, szyfrujcie swoje backupy!

Przedstawiciele Vista.pl wystosowali poniższe oświadczenie w sprawie wycieku danych:

Chcielibyśmy zapewnić, iż obecni użytkownicy są bezpieczni. Baza, o której mowa, zawierała nieaktualne dane stanowiące kopie bezpieczeństwa przechowywaną na zewnętrznym serwerze. Dane te powinne były zostać usunięte przez poprzedniego Właściciela serwisu, który pozwolił sobie na niedopatrzenie w tej kwestii. Jednocześnie informujemy, iż aktualna baza danych użytkowników serwisu Vista.pl jest przetwarzana i utrzymywana w odpowiednich do tego warunkach, co gwarantuje jej maksymalne bezpieczeństwo.

Niestety, z powyższego oświadczenia nie wyczytamy, jakie kroki podjęli właściciele Vista.pl, aby chronić użytkowników, których dane pojawiły się w internecie. Nie wiemy nawet, czy zostali oni poinformowani o włamaniu ani czy wymuszono reset hasła — jeśli ktoś z Was jest użytkownikiem tego serwisu (rejestracja przed majem 2011), prosimy o kontakt.

Czy zmieniłeś już swoje hasła na unikalne?

To co dzieje się na przestrzeni ostatnich kilku dni wspaniale pokazuje, dlaczego warto jest mieć osobne hasła do każdego serwisu.

Hasła są jak majtki. Zmieniaj je często, nie zostawiaj na widoku i nie pożyczaj obcym.

Jeśli stosujecie takie same hasła w kilku serwisach, wyciek z najgłupszego forum może dać atakującym dostęp np. do waszej skrzynki pocztowej czy też Facebooka. Aby sprytnie zarządzać unikalnymi hasłami polecamy darmowy program KeePas.

Aktualizacja 16:00
Abu Nazir opublikował 17MB bazę danych z serwisu Gram24.pl. Znajdują się w niej dane 236 351 kont (login, hash hasła, salt).

Przeczytaj także:



81 komentarzy

Dodaj komentarz
  1. Czy nie lepiej trzymać backupy na urządzeniach niepodłączonych do sieci?

    • Szczególnie praktyczne jak backup robisz przez sieć :)

    • @Marcin Maziarz:
      Powiedz, że miałeś na myśli nośniki (taśmy), nie urządzenia (np. tape-loader)?
      Nie wyobrażam sobie efektywnego systemu kopii do nawet średniej wielkości systemu bez wykorzystania sieci, chociaż faktycznie serwer backupu nie musi być cały czas online.

    • Dokładnie. Dostęp on-line do bazy tylko w chwili tworzenia kopii a potem urządzenie z backupem jest FIZYCZNIE odłączane od systemu produkcyjnego. Oczywiście może to być nośnik, typu taśma ze streamera.

    • +1

    • Prawie cały rok to trochę za duża przerwa jak na robienie backupu, nie chodzi tu czasem o serwer testowy?

  2. ani info na maila, ani wymuszenia zmiany hasła. zero reakcji serwisu na to włamanie.

  3. Ufff… dobrze, że zahashowane :D

  4. przynajmniej powstanie jakiś ciekawy słownik BF z polską listą, no! nareszcie ;]

  5. Powiedzcie mi prosze jak oceniacie bezpieczenstwo stosowanego przeze mnie rozwiazania: Glowna czesc hasla jest stala + na koniec “sole” je sama dodajac nazwe serwisu co czyni hash roznym dla kazdego serwisu. Czy to rozwiazanie uodparnia mnie na takie wycieki hasel?

    • Nie. Zakładasz, że hashe nie zostaną “złamane”, a to błędne założenie. Po “rozszyfrowaniu” hasha za serwisu A, atakujący będzie znał algorytm tworzenia hasła i z powodzeniem domyśli się jak wygląda hasło dla innego serwisu (HASLOFACEBOOK, HASLOALLEGRO, …)

    • @Piotr a ile zajmuje rozszyfrowanie hasha zakladajac ze nie jest w rainbow tables?

    • To zależy. Od informacji na temat długości i użytych znaków w haśle jakie ma atakujący (mógł np. widzieć Cię jak wpisujesz hasło) i od mocy obliczeniowej jaką dysponuje.

    • @Piotr ale mowimy tutaj o bruteforce czy raczej ulomnosciach MD5(bo rozumiem ze o takie hashe chodzi)?

    • Mówimy o atakach słownikowych/bf.

    • @Solniczka – jeżeli mnie pamięć nie myli, to na filmie z Defconu 19 jeden z prelegentów podawał przykład 10 dni na własnym komputerze albo 10h przykładowo w chmurze Amazonu, zakładając 8-znakowe losowe hasło.

    • Zakładasz, że włamanie nie ujawni haseł jako plain text i przez to algorytmu haseł…;)

  6. A po co informować użytkowników? Przecież te dane są stare, pewno z 15% już nieaktualne bo ludzie zmienili hasła do skrzynek. W ogóle nie ma się czym przejmować. Przecież tylko ktoś kompletnie nieodpowiedzialny używa tego samego hasła do skrzynki mailowej i do rejestracji, prawda? PRAWDA? Tylko nie mówicie, że jest inaczej, bo nie uwierzę.

    Administratorzy są kompetentni i przede wszystkim zachowują spokój. NIe ma co się wychylać. Ktoś dmuchnął bazę danych z userami? Trzeba siedzieć cicho i się nie wychylać. Jak w sieci “wypłynie” to się wystosuje “komunikat w którym się oświadczy” i będzie wszystko w porządku. Cycuś będzie. Hapy days back again.

  7. W pliku KeePass-a (brak jednego “s” w nazwie) mam wygenerowane długie i mam nadzieję (bo ich nawet nie oglądam) unikalne hasło do każdej strony www wymagającej zarejestrowania się.
    Ten sam plik z hasłami można użyć z wielu różnych systemów – polecam

  8. Ta baza to fake. Na liście znajduje się mój mail, ale hash który jest przy nim zamieszczony na pewno nie kryje hasła które ja podałem przy rejestracji. Sprawdziłem w googlach i hasło składa się z czterech cyfr i czterech liter a nigdy czegoś takiego nie stosowałem i nie stosuję.

    Ale to nie wszystko. Hasła nie są nawet wymieszane, ponieważ po wygenerowaniu hasha mojego hasła, nie znajduje się ono w ogóle w udostępnionych danych. Tak więc to jedna wielka lipa. Tylko loginy i maile są prawdziwe.

    • kawa, chrzanisz głupoty. Przed chwilą sprawdziłem kilka hashy złamanych przez rainbow tables. Pierwsze z brzegu hasło pasuje do konta pocztowego. Więc nie pitol, że fake.

      Jak moderator ma ochotę puścić poniższy fragment, to proszę (konto wygląda na nieużywane od lat, więc szkoda niewielka):
      3821166b2bdf98a28b4e127e8ae52e1f MD5 : scream27

    • ale przecież hasła mogą być solone

  9. @herbata,

    Nie sprawdzałem innych kont tylko swoje! Co mnie obchodzą inne adresy. W każdym razie w przypadku mojego konta hash hasła nie pasuje do skrzynki i jest wzięty z “d”.

    • Na pewno patrzysz na swoje konto z serwisu Vista.pl? (do Gram24.pl nie opublikowano bazy). Na pewno poprawnie “złamałeś” hash? Wklej go tu (skoro i tak nie jest “poprawny”).

    • @Piotr konieczny
      Nie wkleję, ponieważ używam tego adresu mail. Chronię login w powiązaniu z kontem mailowym a te się zgadzają o czym napisałem powyżej. Hasha nie łamałem softem ale po wpisaniu w google które podaje kilka wyników dla tego hasha i w każdym wyniku wyszukiwania jest to samo hasło.

      Jeszcze chciałem dodać, bo w poprzednim komentarzu popełniłem frojdowski błąd. Oczywiście chodziło o to, że hasła są wymieszane a nie jak napisałem, że nie są.

    • kawa, a co mnie obchodzi twoje konto, twój hash czy twoja umiejętność weryfikowania hashy? Mnie obchodzi to, że napisałeś bzdurę, że baza jest lipna i tylko loginy i maile są prawdziwe.

      Napisałeś oczywistą brednię, wykazałem, że hashe/hasła są prawdziwe. I tyle. Na drugi raz nie wyciągaj pochopnych wniosków.

    • @herbata
      Bądźmy szczerzy. Nic tu sobie nie udowodnimy, bo równie dobrze na poparcie swojej tezy mogłeś podać hash i login do swojego konta na którym zmieniłeś hasło na to z hasha aby udowodnić prawdziwość udostępnionej bazy.

      To dobrze, że ciebie nie obchodzi moje konto. Jeżeli natomiast to co napisałeś jest prawdą to powinno cię obchodzić to, że de facto podałeś na talerzu dane do zalogowania się na czyjąś skrzynkę mailową. To co zrobiłeś jest nieetyczne o ile nie karalne. I nie ma znaczenia, że konto jest nieużywane, jak to określiłeś “konto wygląda na nieużywane od lat”.

      Powtarzam. W przeciwieństwie do ciebie ja nie sprawdzałem innych kont z tej bazy. Tutaj zweryfikować mogą tylko wpisy innych użytkowników którzy potwierdzą lub zaprzeczą, że hashe nie są ich hasłami.

      Jeszcze jedna sprawa. Mój mail i login który się znajduje w tej bazie jest moim adresem prywatnym którego używam oficjalnie (składa się z imienia i nazwiska). Nie robię już tego błędu, żeby używać prywatnego adresu do zakładania kont na portalach od ponad 2 lat, więc, jeżeli o moje dane chodzi, to baza jest dość stara. Ale to też nie musi być dowód.

  10. Ktoś tutaj pytał o bezpieczeństwo swoich haseł, ja natomiast dopytam czy bezpieczne jest taki sposób hashowania:
    hash = md5(login+haslo+salt)+sha1(haslo+salt)

    Salt jest stałym (generowany podczas instalacji CMSu) ciągiem binarnym (po za standardowymi A-Za-z0-9). Używam 2 hashy aby uniknąć znalezienia kolizji.

    Czy taki sposób jest bezpieczny?

    • @kiler: nie. Jest dużo materiałów na ten temat w sieci, polecam np.:
      http://www.openwall.com/articles/PHP-Users-Passwords
      tl;dr: sklejanie dwóch hashy tylko ułatwia zadanie włamywaczowi, używanie md5/sha1 jest niewskazane (bo są to szybkie algorytmy, co ułatwia atak brute-force)

    • Stała sól jest szybsza, ale mniej bezpieczna, bo wystarczy, że będziesz miał jednego usera z lipnym hasłem np popularne 123456(a pewnie będziesz miał) i wtedy sprawdza się tylko różne sole różnie doklejane do “123456”.
      Jeżeli którykolwiek hash z bazy dla danej soli będzie się zgadzał, to sól do wszystkich haseł już mamy, więc tak jakby jej nie było.

      Lepiej każdemu userowi wygenerować oddzielną sól(każde trzeba złamać oddzielnie), a jak coś jest bardzo bardzo ważne, to drugą(stałą) sól trzymać jako stałą w jakimś pliku konfiguracyjnym bez dostępu z zewnątz.

    • Jezu, ludzie, zapisać 100 razy na tablicy, unikalny, długi salt per user.

    • @Piotr Konieczny
      Kłóci się to jakoś z tym co napisałem?

  11. Dwa słowa: karty kodowe.

  12. a nie można podlinkować tej bazy żeby laicy mogli sobie sprawdzić czy tam są ?
    czy to za bardzo niebezpieczne piotrku

    • Sprawdzenie czy “laicy” tam są i ich poinformowanie, to zadanie dla właściciela bazy. Albo tych kolegów-informatyków, co z Google potrafią korzystać.

    • no tak szukajka na pastebin załatwia sprawę

    • 5 minut w google panie laik :P

      Btw. Właśnie przed chwilą wypłynęło gram24.pl

    • @raf: 12sek. z zegarkiem w ręku na Google, panie laik ;p

    • @Mistiqe

      To tylko przenośnia :)

  13. BACKUPY BAZ TRZYMA SIĘ ZASZYFROWANE!

  14. swój hash złamałem online ,hasło się zgadza

    • Ja czekam na potwierdzenie stałego bywalca z Niebezpiecznik.pl a nie świeżynki która zakłada konto specjalnie pod komentarz w tym wątku.

    • erm…. u nas nie ma kont…

    • @kawa: dobra, skoro ci na tym zalezy, to tez potwierdzam
      ;-)

  15. Baza do Gram24.pl już jest trochę dużo tego

  16. zerknąłem na te hasełka z vista.pl.
    Oczywiście na podium 123456 i qwerty. Ludzie jak widać mają za nic swoje bezpieczeństwo.
    Pociesza fakt, że “dupy” są tylko dwie, ale za to polska jest kilkanaście razy.

    • Ja bym stwierdził że ludzie są po prostu głupi. Kiedy zwracam im uwagę na idiotyczne hasło, stwierdzają: “Ale mnie jest łatwiej zapamiętać”. Coraz rzadziej się wtrącam. ;-))

  17. admini z g24 jeszcze rano zapewniali że nic od nich nie wyciekło, zaufałem do momentu kiedy nie znalazłem swoich danych w jednej z paczek od Abu_Nazir-a

  18. Poszły konie po betonie, dane 236 tys. userów z gram24.pl są już na pastebin:

    Gram24.pl -> DataBase -> LAST_REGISTER => 2012-02-09 10:24:17
    DUMP => 2012.02.09 PUBLIC => 2012.02.28
    NEXT DUMP => steamkeys.pl
    CONTACT => abu.nazir@interia.pl

    • Ktoś może ma to w jednej partii, bo mi się nie chce każdej strony przelatywać?

    • Nvmnd, też się znalazło.

  19. I ja osobiście nie mogę się zalogować na vista.pl cudnie :/

    • Resetuj hasło, no chyba, że już Ci przejęli konto.

  20. @Ola: Skorzystaj z odzyskiwania hasła, ponieważ wszystkie zostały zresetowane.

  21. NEXT DUMP => steamkeys.pl

  22. Ciekawe kiedy zobaczymy złamany hash, który powie nam: “chcebycnaniebezpieczniku”.

    • Żeszty moje hasło

  23. Jakiego softu typu KeePass poleca Niebezpiecznik na OS X?

  24. kaman poczta na @interia.pl ?? :PP

    • Dobre jako alias ;)

    • coś nie tak z pocztą na interii?

  25. Co do joemonstera to tutaj był sql injection a nie serwer backupowy z tego co mi było dane usłyszeć.

  26. Zastanawiam się co też powoduje ludźmi, że publikują takie dane? Czy nie mogliby tego robić w jakiś sensowniejszy sposób? Można przecież udowodnić publicznie, że ma się do nich dostęp, jednocześnie nie upubliczniając ich (np. pokazać próbkę, użyć wiarygodnej strony potwierdzającej, albo w jakiś sposób uniemożliwić skorzystanie z danych przed ich publikacją). A tak, to właściciel strony powie “sorry, głupio wyszło” i tyle, a za to użytkownicy mogą dostać nieźle po tyłku, bo np. ustawili sobie hasło takie jak w poczcie (albo użyli hasła typu mojetajnehaslo+vistapl, a w innych serwisach użyli podobnego algorytmu generowania hasła).

    • No życie. Niektórzy muszą dostać po tyłku – inaczej się nigdy nie nauczą.

  27. Kiedy w bazie przechowywany jest hash i sól, żeby spróbować brute force’a trzeba jeszcze odgadnąć, w jaki sposób sól jest składana z hasłem.
    Czy nie jest jednak trywialnym zabezpieczeniem dodanie drugiej (stałej) soli na poziomie aplikacji? hash=f(r.password, r.salt, const.salt)

    • Warto kombinować na 100 różnych sposobów, gorzej, jak ktoś i do plików się dobierze ;-)

    • Taka stała może nawet nie być przechowywana w kodzie aplikacji – może być pobierana z jakiejś usługi w sieci wewnętrznej. Każdy sposób dobry – zależy od prawdopodobieństwa potencjalnych zagrożeń :)

    • @btn: No tak, ale jeśli ktoś dorwie się do bazy, to z dużym prawdopodobieństwem i tak uzyska sól z kodu czy zewnętrznego serwisu. A same z takiego rozwiązania kłopoty przy przenoszeniu na nową architekturę czy przywracaniu kopii zapasowej. Chyba dużo łatwiej stosować bardziej czasochłonną procedurę hashowania z różnymi solami dla różnych użytkowników przechowywanymi w bazie.

  28. uważam, że stała sól jest bezpieczna, o ile jest dłuższa od hasha.
    hasło min 6 znaków+ 200znaków soli i mamy pewność, że istnieje przynajmniej jedna kolizja.
    wtedy nawet jak ktoś znajdzie kolizje do hasha z hasłem 123456, to wejdzie tylko na to jedno konto (i wszystkie z takim hasłem), ale nie odczyta soli i reszty haseł.

    • Jak ktos ma hasha, to raczej nie musi sie meczyc z kolizjami zeby *wejsc* na to konto, po prostu odczyta to co chce prost o z bazy. Z kolei kolizje w niczym nie “przeszkadzaja” – string z kolizji to nie bedzie oryginalne haslo, ktore bedzie pasowalo do fb/allegro/etc.

    • @darekry: Ej, przecież sól z definicji jest jawna. Sól nie służy temu, by przy ewentualnym wycieku atakujący nie wiedział, jaki jest algorytm hashujący — z dużym prawdopodobieństwem osoba, która uzyskała dostęp do bazy, uzyska też dostęp do kodu. A nawet jeśli nie, to sztywne kodowanie soli to jednak security by obscurity, które dodatkowo czyni system mniej przenośnym. Sól ma utrudnić korzystanie z tablic tęczowych oraz ataki słownikowe na wiele hashy haseł jednocześnie.

      Już wyżej raz polecałem, polecę jeszcze raz:
      http://www.openwall.com/articles/PHP-Users-Passwords

  29. co do porównania haseł do majtek, to jeszcze jedno mi przychodzi do głowy: dłuższe lepiej chronią ;)

  30. Tak samo było z Wykopem

    • bzdura

    • Dokładnie rzecz biorąc “włamano” się na serwer “testowy” Wykopu (brak hasła roota), który zawierał kopię produkcyjnej bazy danych. Dziwne, że temu zaprzeczasz, ale rzeczywiście tak było.
      Warto się zapoznać np. z tym AMA:
      http://www.wykop.pl/link/842227/wlamalem-sie-na-serwer-wykopu-w-2009-r-ama/

    • Ja wiem jak było, gdyż byłem jednym z pierwszych, który tę sprawę nagłośnił. Natomiast Ty najwyraźniej nie widzisz różnicy pomiędzy korzystaniem z produkcyjnej bazy na serwerze developerskim a zewnętrznym sewerem z backupami…

    • No to przepraszam.

  31. Moj e-mail jest aktualny i działa po dziś dzień to ciekawe co mówi właściciele serwisu ze to stara baza danych była. lol

  32. […] jest abu nazir, który znany jest Czytelnikom Niebezpiecznika z włamań do serwisu gram24.pl oraz streamkeys.pl. g4g.pl hacked by abu nazir (fot. […]

Twój komentarz

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

RSS dla komentarzy: