10:38
31/7/2011

Drżyjcie piraci ;) Z popularnego polskiego serwisu do wymiany plików TorrentLeech.pl wykradziono całą bazę danych (w tym hasła i adresy IP użytkowników). Jak twierdzi włamywacz, opublikowania tych informacji w internecie można było uniknąć, wystarczyło z nim współpracować. A że właściciele serwisu kompletnie zignorowali atakującego, to w ramach ostrzeżenia dane użytkowników (niektóre już ze złamanymi hasłami) zostały opublikowane.

Jak doszło do włamania na TorrentLeech.pl?

Włamywacz (BTW: już włamywacz, czy ciągle jeszcze osoba, która wykonała “niezamówiony pentest”?), podpisujący się jako White Hacker, przejął wczoraj konta administratorów serwisu i umieścił oraz rozesłał do użytkowników serwisu torrentleech.pl następującą wiadomość:

Ponad tydzien temu znalazlem luke na TorrentLeech.pl, luka zostala zgloszona. I w tym momencie zostalem kompletnie olany, ale przywyklem do tego, luka zostala naprawiona a do mnie nie raczono nawet odpisac. Ostatecznie z niewiadomego mi powodu moje konto kontaktowe z administracja zostalo usuniete, i tutaj zaczyna sie wasza historia:

Do tego wycieku publicznego NIGDY nie mialo dojsc, jednakze poczulem sie urazony, i jest to powiedzmy mala przestroga na przyszlosc dla wszystkich. Jezeli ktos zglasza krytyczna luke, nalezy nawet sztucznie utrzymywac z nim kontakt (dac mu na browara i po krzyku), jezeli dobrze to rozegracie to gwarantuje ze wyciagniecie z tego mnostwo korzysci.

Gwarancja chyba trochę na wyrost, ale będąc właścicielem serwisu zdecydowanie warto wykazać się ludzkim podejściem do osoby, która zgłasza nam problem z bezpieczeństwem. Kiedy tego zabraknie to… tak jak w przypadku torrentleech.pl w internecie pojawić się mogą fragmenty bazy.

torrentleech.pl hasla

torrentleech.pl hasla -- fragment opublikowanej bazy

Pamiętajcie, że nawet jeśli uda się Wam wypracować kompromis ze zgłaszającym błąd (nie wyobrażam sobie braku udziału prawnika w tym procesie, choćby do sformalizowania “układu”), to mimo wszystko nie należy naiwnie zakładać, że włamywacz nigdy nie ujawni wykradzionych danych — warto “prewencyjnie” wymusić zmianę haseł użytkowników. Niestety, jak widać w tej sytuacji najwięcej tracą poważnie podchodzący do bezpieczeństwa — ciężko będzie im ukryć nieautoryzowany dostęp do danych przed użytkownikami, globalny reset haseł prawie zawsze świadczy o jakimś problemie :>

Co wyciekło?

Wyciekły nie tylko dane użytkowników (loginy, e-maile i hashe haseł), ale również historia adresów IP — to z kolei może być łakomy kąsek dla wszystkich organizacji “antypirackich”.

Niektóre z hashy zostały już złamane. Kolejny raz kłaniają się dwa klasyczne błędy:

  • administratorów torrentleech.pl,
    którzy nie przechowują haseł w formie bezpiecznej (bcrypt lub wielokrotny hash z unikalnym per user saltem)
  • użytkowników torrentleech.pl,
    którzy używają tego samego hasła do więcej niż jednego serwisu

Czy torrentleech.pl zgłosi sprawę na policję?

Swoją drogą, zastanawiam się, czy serwis torrentleech.pl zgłosi sprawę włamania na policję? Ich działalność w końcu, delikatnie mówiąc, balansuje na krawędzi prawa.

Przypomnę, że zgodnie z polskim prawem można pobierać z internetu multimedia (np. muzykę), ale tylko na własny użytek (ich udostępnianie jest karane, a nie posiadanie) — nie można natomiast pobierać “pirackiego” oprogramowania (karalne jest już samo posiadanie).

Cała sprawa przypomina mi stare powiedzonko:

“najkorzystniej jest okraść przestępcę, on nie pójdzie na policję”

Dziękujemy Miłoszowi, Adamowi i Mirkowi za informacje i czekamy na wyjaśnienia właścicieli serwisu TorrentLeech.pl. Kiedy tylko je otrzymamy zaktualizujemy ten tekst. Do tego czasu, wszyscy z Was, którzy mieli tam konto powinni obowiązkowo zmienić hasła w innych serwisach, w których użyli hasła takiego samego jak na torrentleech.pl

P.S. Rejestrować się na stronie torrentowej przy pomocy e-maila w stylu imie.nazwisko@costam.tld — niektórzy naprawdę nie mają wyobraźni…

Aktualizacja 12:35
Administracja serwisu torrentleech.pl w odpowiedzi na nasze pytania podesłała następujące oświadczenie:

Atakujący wykorzystał lukę kodu która znajdowała się w pliku details.php. Użył do tego programu o nazwie sqlmap. Atak typu SQL Injection. Przez co uzyskał dostęp do bazy danych co miało miejsce tydzień temu i już w następny dzień od tego faktu luka została załatana. Jak można zauważyć atakujący opublikował tylko część bazy z przed tygodnia nie bieżącą! Co świadczy o tym co napisałem wcześniej, że luka została zabezpieczona już tydzień temu. Jak już wspomniałem wyżej atakujący zgłosił się do jednego z naszych administratorów z informacją o luce w kodzie. Nie wskazał gdzie i w jakim pliku jest błąd. Chciał byśmy złożyli mu propozycję w zamian za informacje o błędzie. Po znalezieniu luki, wyszliśmy z propozycją nadania mu rangi Vip lecz nie był nią zainteresowany można było przypuszczać, że chodzi mu o cele zarobkowe. Tak więc zostało jego konto skasowane. Być może dlatego poczuł się obrażony ale dlaczego zignorowany to nie mamy pojęcia. Stosowna informacja znajdzie się niebawem na naszej stronie w dziale wiadomości. Na dzień dzisiejszy możemy zalecić by userzy zmienili hasła na naszej stronie. Dodatkowo zostanie zmieniony w bazie naszego serwisu system kodowania haseł na bardziej zaawansowany.

W świetle powyższego oświadczenia ciężko więc mówić o “zignorowaniu” włamywacza przez administrację serwis (o bezinteresowności tez możemy zapomnieć). Z drugiej strony na jaw wychodzi podatność typu SQL injection — jeden z podstawowych błędów w webaplikacjach, który łatwo można wykryć przy pomocy ogólnie dostępnych narzędzi do weryfikacji bezpieczeństwa serwisów internetowych (obsługi kilku z nich uczymy na naszych szkoleniach) — trzeba tylko pamiętać o wykonywaniu regularnych testów bezpieczeństwa.

Aktualizacja 1.08.2011, 00:57
atom podesłał zestawienie najpopularniejszych haseł:

creative, torrentleech, lol123, zaq12wsx, 1qazxsw2, qwerty1, 111111, qazwsx, agnieszka, michal, master, widzew, marcin, qwerty, qaz123, barcelona, 1qaz2wsx, 123456, polska, samsung

Przeczytaj także:

93 komentarzy

Dodaj komentarz
  1. Wypuscil baze bo go administracja nie przytulila? how pathetic… powinien sobie maskotke przytulanke kupic. Swoja droga elementarna kultura przydala by sie i pijawka…

  2. omg…następny co się poczuł “urażony” wykonał najzwyklejsze w świecie przestępstwo i powinni go ścigać z urzędu…koleś chyba ma kompleksy.
    Ja mam jedną zasadę jak wykonuje nie zamówione pentesty…nie pcham się na siłę aby mi za to zapłacili albo chociaż o tym wiedzieli…po co mi prokuratura na drzwiach…

  3. Nie TorrentLeach.pl tylko TorrentLeech.pl a to mała różnica Panowie :P

  4. włamywacz użyj sqlmap. Na większej stronie dostał bana za próbę użycia tej dziury. Unikalnych haseł jest 10257 zostało mi do załamania ~2050. 123456 jak zwykle rządzi.

  5. Koleś urażony, czy nie, wniosek z tego zdarzenia – jak zwykle – jest taki, że niechcący zauważona luka lepiej niech pozostanie niezauważona w dalszym ciągu lub służy do prywatnych celów tylko odkrywcy tej luki. W naszym dziwnym kraju wszyscy jesteśmy statystycznie potencjalnymi przestępcami z założenia.

    BTW: ciekawe ilu policajców jest w tej wyciekniętej bazie.

    • No ale widzisz, jeśli ktoś ma otwarte drzwi od samochodu i kluczyki w stacyjce to znaczy że masz zapier*lić samochód ?
      Na takim przykładzie tata programista, mi wytłumaczył że lepiej jak napisałeś dla siebie to zostawić.

    • A propos kluczyków w stacyjce. Dziadek widział jak gówniarze bawi się takim samochodem, przegonił ich, zadzwonił na policję poczekał 30 minut i poszedł dalej – policji jak nie było tak nie ma. Samochód parę dni później tez tak stał.

    • Kauczu, ale przecież on jest zwyczajnym przestępcą, który powinien być teraz ścigany. Jak widać nie tylko wykrył lukę, ale zawczasu ściągnął bazę dany – to jeden paragraf. Drugi, to próba wyłudzenia korzyści majątkowych (do czego sam się przyznaje), bo konto vip mu się nie podobało. Paragraf trzeci, to upublicznienie tych danych. Pewnie liczył, że jak to serwis torrentowy, to admini zatrzęsą portkami przed takim dzieciakiem.

  6. Mnie raczej dziwią ludzie rejestrujący się na takich serwisach. To zaprzeczenie idei p2p jeszcze w erze DHT.

    • A mnie np dziwi, że ludzie pobierają torrenty z publicznych trackerów udostępniający każdemu przypadkowemu policjantowi swoje IP.

    • @Sławek: IP nie jest dowodem w sprawach procesowych, więc nie pociskaj już tej pseudoideologii. wiadomo, że chodzi o piramidki finansowe.

  7. Ha, zaloga tej strony pewnie wyciszy sprawe, zadnych przeprosin ani nic niestetty tacy oni sa…

  8. Czemu mieliby nie zglaszac na policje? Przeciez hostowanie torrentow nie jest nielegalne.

    • Pewnie temu, że kiedy ktoś zainteresuje się na co pozwala ten serwis, to zacznie go prosić o dane użytkowników — bo zaszło uzasadnione podejrzenie popełnienia przestępstwa (dystrybucja nielegalnego oprogramowania np.) — a jak myślisz, jak dłużo pożyje serwis, który “doniesie” na wszystkich swoich użytkowników?

  9. Daniel – cóż oni mogą sobie “wyciszyć”, ale czy Polskie serwisy informacyjne tak zrobią, powątpiewam :D

  10. Przypominają mi się słowa policjantki co robiła wykład (moralności?) w mojej szkole. “Możecie ściągać ale nie możecie udostępniać”. Czyli upload do innych na 0kB/s. Pytanie brzmi czy tak faktycznie jest bo trzeba chyba informować o naszym postępie ściągania czyli jednak jest wysyłanie do innych pakietów ale nie udostępnianie? Żeby było śmieszniej to mówią to Ci co kilka lat temu na komendzie większość oprogramowania mieli pirackiego :)

    PS
    @Piotr Konieczny
    Ciekawi mnie dlaczego nie zainteresowaliście się informacją, którą przesłał Wam znajomy odnośnie dziury na zlecenia.przez.net?

    • CapaciousCore: podeślij przez formularz kontaktowy dane tego znajomego, postaram się dowiedzieć na jakim etapie jest ta sprawa.

  11. torrentleech.pl zawsze stwarzało i stwarza zagrożenie dla użytkowników. Nieodpowiedzialni właściciele strony byli posądzani o włamania na konta użytkowników na innych stronach posługując się dostępem do swojej bazy. Oni działają na szkodę polskiego P2P. Użytkowników traktują jak zera. (Dziwie się, że w ogóle ktoś tam się rejestruje).
    Zbyt duże ego dwóch młodych cwaniaków z osiedla.
    Myślę, że jakby osoba która dokonała włamania wiedziała co tam się dzieje poszłaby o krok dalej.

    • Jakieś dowody na poparcie twoich słów ?.

  12. Popularny serwis do hostingu plikow oron.com takze przechowuje hasla w plaintext, kiedy skorzystalem z przypomnienia hasla dziwnym trafem haslo do mnie przyszlo w formie jawnej..

    • A o pojęciu szyfr słyszałeś?

    • @tmq: a wiesz, że maile można przechwytywać?

  13. a co to jest torrentleech.pl ? Jedyny prawdziwy jest torrentleech.org

  14. Ciekawe, czy fragmenty bazy udostępnił… przez torrenta ;)

  15. Ale z ortografią to admini zaatakowanego serwisu to są trochę na bakier :)

  16. Troche mnie przeraza to podejscie bo stara zasada dziennikarska mowi ‘audiatur et altera pars’ a komentarze dowodza, ze bractwo administratorow slucha wyjasnien torrentleech.org a ignoruje naszego wlamywacza.
    Nie jestem zwolennikiem lamania prawa ale sprawa nie jest prosta.
    Dlaczego przyjmujemy wersje ignorantow – administratorow strony torrentleech.org – z aprobata?
    Obie wersje troche sie roznia? Dla mnie nie jest jasne czy rzeczywiscie PANY ADMINISTRATORY przeslali jakas oferte bo nasz wlamywacz pisze …I w tym momencie zostalem kompletnie olany, ale przywyklem do tego, luka zostala naprawiona a do mnie nie raczono nawet odpisac…
    Gdzie jest prawda? Widze, ze to nie jest wazne!
    Wyrok juz wydano!
    A fe!

    pr0of

    • Niebezpiecznik podał obydwie wersje, więc są raczej obiektywni. A do anonimowych komentarzy w necie stosować zasady dziennikarstwa, o których przestrzeganie trudno w praktycznie każdych mediach, to trochę dziwne ;)
      Moje zdanie jest takie, że jeśli włamywacz zrobił sobie zrzut bazy, której nie miał zamiaru upubliczniać ‘NIGDY’ to coś tu jest nie tak. Wiem, potwierdzam tym samym stwierdzenie, że wyrok został już wydany :P

  17. @progeo torrentleech.pl nie torrentleech.org ta druga to jedna z lepszych zagranicznych stron, a mowa o naszym polskim średniaku.
    Ja powiem tak, prawdy się nie dowiemy. A w żadne słowo zarządu tl.pl nie uwierzę.
    Powód? W kłamstwach i oszczerstwach są wybitni i dobrze im to idzie. Mydlą oczy użytkownikom od 4 lat już…

  18. torrentleech.pl to jedna z największych i najlepszych stron torrentowych w polsce a komentarze uzytkownika adi śmierdzą konkurencja na 3 kilometry. Mam nadzieję, że strona wróci niedługo.

    • Aż tak bardzo w nich zakochany?
      Nie są ani najwięksi, ani najlepsi, jest przynajmniej kilka innych polskich trackerów, które stoją wyżej niż oni.

    • spam alert

  19. wielokrotny hash z unikalnym per user saltem

    Piotrze, z tego co mi wiadomo, wielokrotne hashowanie hasła nic nie daje, a tylko zwiększa prawdopodobieństwo znalezienia kolizji. Wielokrotne hashowanie w najlepszym przypadku da nam taki sam efekt, jak pojedyncze hashowanie, a w najgorszym zwiększa nam prawdopodobieństwo znalezienia kolizji:

    Powiedzmy, że dla md5($haslo) mamy:
    x = md5(zyx) i x = md5(qwe)
    Jeżeli wynikowy hash przepuścimy przez md5 (czy jakąkolwiek inną funkcję skrótu), to uzyskujemy to samo co wyżej:
    y = md5(hash1) y = md5(hash2).
    Przy tym założeniu mamy 4 różne hasła dające nam hash, który wygenerował user.

    • Trochę źle to tam zobrazowałem, pokażę inaczej:
      Kodujemy np. w taki sposób (użyte funkcje nie mają znaczenia):
      y = md5(sha1(a))
      Dla kodu powyżej mamy np. takie możliwości:
      y = md5(a) i y = md5(b)
      A potem mamy jeszcze takie możliwości:
      a = sha1(c) i a = sha1(d) oraz b = sha1(e) i b = sha1(f)

    • Nie do konca. Przede wszystkim nkrotne hashowanie (n=500) *spowalnia* operacje łamania hasha. Atakujący, nawet jeśli pozna wartość n, bedzie musiał spędzić nad wyliczeniem nkrotnego hasha T+x (gdzie T jest wyliczeniem jednokrotnego hasha). Funkcje skrótu są zoptymalizowane pod katem szybkości ich wyliczania, a dla nas w tym przypadku szybkość jest wrogiem. Poza tym ew. kolizja to nie oryginalne hasło użytkownika, które ma takie samo jak to do banku, czy innych serwisów — a to własnie poznanie tego hasła chcemy utrudnić atakujacemu, dostęp do serwisu z którego hasła wyciekly i tak przecież już ma ;)

    • Przy założeniu, że atakujący ma dostęp tylko i wyłącznie do bazy danych i nie wie jaka jest sól, to wystarczy hash w postaci $haslo.$sol.$haslo

      Przy każdym kolejnym hashowaniu zwiększamy prawdopodobieństwo znalezienia kolizji, co dla mnie jest bez sensu, bo ułatwiamy mu robotę. W tym przypadku wydłużenie czasu łamania hasha nie jest oczywiste, bo przy n=500 mamy naprawdę duże prawdopodobieństwo na kolizję a to z tego względu, że md5 ma tylko 3.40282367 × 1038 możliwych hashy. Jak wiemy, specjaliści odradzają używanie sha1, które ma o wiele więcej możliwych hashy, a co taki md5, o którym piszemy.

      O wiele szybszym i prostszym zabezpieczeniem jest zwykłe hash(‘sha512’, $haslo.$salt); a sama sól może być jednakowa, dla wszystkich userów i trzymana w pliku… Niech taki atakujący się z tym męczy, szybciej wymuszę zmianę haseł użytkowników…

    • Przy założeniu, że dla jednego hasha mamy dwa hasła mu odpowiadające i mamy 500-krotne hashowanie to mamy 3.27339061 × 10^150 możliwych haseł. md5 ma 3.40282367 × 10^38 możliwych kombinacji hashy… Trochę się Pan zagalopował.

    • Nie wspominam już o tym, że jeśli nie mamy zabezpieczenia przed bf, to atak na stronę jest X razy skuteczniejszy (dla naszego usera z hasłem “test” istnieje jeszcze np. 10 innych haseł dających ten sam hash). Dlatego wielokrotne hashowanie nie jest wcale dobre.

    • @nolias:
      “Przy założeniu, że dla jednego hasha mamy dwa hasła mu odpowiadające” — niezly z ciebie matematyk. Dla dla kazdego hasha mamy nieskonczenie wiele kolizji, bo nasza dziedzina sa ciagi bitow dowolnej dlugosci, a wynik ma bitow 128.

      Rozklad hashy musialby by bardzo “nielosowy”, zeby zachodzilo to o czym mowisz. Nie twierdze ze sie mylisz, ale powinienes podac zrodla, bo te twoje wywody to machanie rekami. Jesli hashe maja dobry rozrzut po calej przeciwdziedzinie (a pewnie tak jest), to wielokrotne hashowanie w niczym nie przeszkadza.

    • To było optymalne założenie, które jest realne, nie potrzebuję więcej kolizji, żeby udowodnić twierdzenie, które przedstawiam. A źródła? Wystarczy poszukać w googlach i poczytać wypowiedzi. Ale to jest proste do przedstawienia na chłopski rozum. Jeżeli jedno hashowanie tworzy Ci możliwość podania dwóch różnych haseł, to kolejne hashowanie zrobi to samo. Jest to nieuniknione. Dlatego przy każdym kolejnym hashowaniu zwiększasz prawdopodobieństwo znalezienia kolizji. Przy najlepszym rozwiązaniu uzyskasz to samo, co przy jednym hashowaniu. Nie da się lepiej zahashować czegoś, co już jest zahashowane. Poza tym, jeżeli to rozwiązanie działałoby tak faktycznie, to kolejne wersje (np. z md4 na md5) powinny mieć już w sobie zaimplementowane wielokrotne wykonanie samego siebie… To tak samo jakbyś chciał coś wydrukować 2x na tej samej kartce. W najlepszym przypadku, uzyskasz ten sam efekt, ale większe prawdopodobieństwo jest na to, że będziesz miał to ciemniejsze, lub kartka źle się ułoży i ten drugi wydruk może być przesunięty… A inny przypadek? Enigma. Niemcy myśleli, że stosując podwójne kodowanie zwiększą dwukrotnie bezpieczeństwo, w efekcie ułatwili pracę polskim kryptografom, bo okazało to się słabym punktem całego systemu…

    • @nolias:
      mylisz sie.
      Wyobraz sobie graf, ktorego wierzcholkami sa 128bitowe ciagi. Miedzy wierzcholkami u,v istnieje krawedz wtw. gdy md5(u)=v.
      Zalozmy, ze ten graf jest jednym wielkim cyklem. W tym przypadku wielokrotne hashowanie w niczym nie przeszkadza, ani w niczym nie pomaga.
      Zalozmy teraz, ze wszystkie wierzcholki oprocz jednego, hashuja sie do jednej wartosci, a ta wartosc hashuje sie do samej siebie. Wtedy hashowanie rzeczywiscie oslabia.

      Jak widzisz, bez znajomosci wlasciwosci przeciwdziedziny nie mozna na temat wielokrotnego hashowania nic wywynioskowac — twoj chlopski rozum cie zawiodl.

      Skoro tak latwo wygoglowac zrodla, to zapodaj pare linkow, wtedy kazdy bedzie mogl sam ocenic czy masz racje, bez uzywania swojego chlopskiego rozumu.

    • Ehh, możesz poszukać na googlach, to nie jest wbrew pozorom trudne. Ale podpowiem, że temat był długo też wałkowany na forum php.pl, więc i tam możesz poszukać takich samych wypowiedzi różnych osób.

    • @Nolias: skupiłeś się na kolizjach, podczas gdy problem leży w zupełnie innym miejscu. Zauważ z jaką sytuacją mamy do czynienia. Wyciekła baza hashy z serwisu. Zwiększenie bezpieczeństwa użytkowników to w tym przypadku albo
      a) natychmiastowy reset haseł wszystkim użytkownikom — ale serwis tego nie robi
      b) ***opóźnienie*** atakującego w łamaniu haseł offline (także możesz zapomnieć o swojej ochronie przed atakami online brute-force). Podkreślam “opóźnienie” a nie uniemożliwienie, bo to drugie nie jest wykonalne — mając dostatecznie dużo czasu i odpowiednio duży słownik, atakujący znajdzie hasło. Nam jednak nie chodzi o to, żeby nie znalazł, a o to, żeby znalazł za rok, a nie za tydzień. Przez rok jest bowiem większa szansa, że użytkownicy serwisu dowiedzą się, iż baza wyciekła i ci z nich, którzy mieli to samo hasło ustawione w innym miejscu zdążą je zmienić zanim atakujący uzyska do niego dostęp.

      To teraz na chłopski rozum, skoro taką metodę dowodu preferujesz, skoro mój komputer liczy hash(“dupa.8”) w 1 sekundę, a hash[n](hash[n-1](hash[n-2]…hash(“dupa.8”)…)) w n sekund, to czy nkotne hashowanie nie spełnia założonego przez nas celu opóźnienia działań atakującego zmierzających do poznania ***prawdziwego*** hasła użytkownika (podkreślam prawdziwego, bo co mu po kolizji?)

      Wygodnie też dobrałeś sobie funkcje, sha1, md5, podczas gdy ja celowo nie wymieniałem konkretnego algorytmu hashowania. Dodatkowo, zwróć uwagę na alternatywę w mojej wypowiedzi “(bcrypt _lub_ wielokrotny hash z unikalnym per user saltem)” i zastanów się, dlaczego bcrypt podałem na pierwszym miejscu? Z naszego, niebezpiecznikowego doświadczenia w testach bezpieczeństwa wynika, że niekiedy ciężko jest programistów przekonać do stosowania bcrypta do przechowywania haseł (wymagana zmiana funkcji/biblioteki). Ale już podpowiedź w stylu “to może n-krotne hashowanie będzie dla Państwa bardziej akceptowalne?” (czyli wprowadzenie pętli, np. dodatkowo z dodaniem salta w każdej iteracji) często jest łatwiejsze — no cóż, życie czasem wymaga kompromisu.

      Tak więc proszę mi tu z Niemcami nie wyskakiwać ;) tylko postarać się zrozumieć, o czym dyskutujemy i przed czym chronimy użytkownika. Bo to że funkcje hashujące mają problem z kolizjami wiedzą chyba wszyscy czytelnicy Niebezpiecznika.

    • @nolias:
      mysle, ze wiem jak wyjasnic o co ci chodzi.

      Zalozmy, ze hashujemy 2 razy i md5^2(x) = y. Jesli istnieja dwa hashe h1 i h2, t.ze md5(h1)=md5(h2)=y, to rzeczywiscie podwojne hashowanie oslabia, bo zwiekszylismy pdp. trafienia przez przypadek na dobre haslo z 1/2^128 do 2/2^128. Im wiecej iteracji, tym wiecej moze pojawic sie kolizji (nawet wykladniczo od glebokosci). Problem w tym, ze o f-cjach hashujacych zaklada sie, ze maja dobre wlasciwosci (radnom oracle model) — to po pierwsze, a po drugie to co powiedzial Piotr — lag moze unieszkodliwic tę *potencjalna* slabosc.

    • Tak, tylko musisz jeszcze pamiętać o tym, że te funkcje zostały stworzone z myślą o jednokrotnym zastosowaniu. Każde kolejne, tak jak pisałem, może osłabić taką funkcję.

    • @up:
      rozchodzi sie o to, ze moze ale nie musi!

    • No i spójrz co napisałem w pierwszym komentarzu ;)

      “Wielokrotne hashowanie w najlepszym przypadku da nam taki sam efekt, jak pojedyncze hashowanie, a w najgorszym zwiększa nam prawdopodobieństwo znalezienia kolizji”

    • Nolias, przecież Ci tu tłumaczymy, że wielokrotne hashowanie ma zaletę – opóźnienie ataku słownikowego offline, więc błędne jest Twoje stwierdzenie, że “Wielokrotne hashowanie w najlepszym przypadku da nam taki sam efekt, jak pojedyncze hashowanie”. Przeczytaj mój poprzedni komentarz, bo mam wrażenie, że go nie zauważyłeś.

    • w najlepszym przypadku znacznie poprawi bezpieczenstwo, a w najgroszym moze zwiekszyc pdp. kolizji, ale niewiadomo o ile — to troche co innego, nie uwazasz? :P

    • No może i tak, ale tak czy siak, to o czym pisałem, to słuszna teoria… Żeby sprawdzić kto miał więcej racji, trzeba byłoby przerobić trochę testów…

    • Trochę dziwnie komentarze są wyświetlone… Najpierw Twój z 00:28, potem Jurka z 00:18 i mój z 00:27…

      Piotrze, ja rozumiem, że moje i jest jakaś zaleta zwolnienia łamania, ale ciągle też pamiętam o tym, że przy wielokrotnym hashowaniu jesteśmy podatni na zwiększenie prawdopodobieństwa kolizji. Nie chcę się kłócić, kto będzie miał więcej racji, tylko (tak jak przy początku pisałem) chciałem zauważyć, że nie jest to najlepsze rozwiązanie…

    • Nolias: ale właśnie w tej sytuacji o której tu rozmawiamy jest to najlepsze rozwiązanie (poza użyciem bcrypt :). Kolizje nie wpływają istotnie na bezpieczeństwo n-kotnego hashowania wykorzystywanego do przechowywania haseł (co z tego, że atakujący znajdzie kolizję “xyz” dla hasła “abc” — nic mu to nie da), z kolei n-krotność hashowania wpływa — podnosi bezpieczeństwo przez opóźnienie procesu łamania. Co innego wykorzystanie hashy do zapewnienia integralności, ale i tu kolizje nawet jeśli się zdarzą, to rzadko wynikają z takich danych wejściowych, jakich sobie życzymy.

    • Poprawcie mnie jeśli się mylę ale wielokrotne hashowanie dzięi ryzyku wystąpienia kolizji ma też jedną pozytywną cechę: hacker po napotkaniu pierwszego konfliktu staje przed wyborem, które z wynikowych haseł powinien dalej łamać (czy hasło które w ten sposób otrzymał jest właściwym, czy powinien szukać następnego konfliktu, by je też złamać w nadziei na odzyskanie oryginalnego). W takim przypadku hacker aby odkryć oryginalne hasło (w nadziei, że wykorzysta je np na innym serwisie, na którym konto posiada ofiara ataku) musi nie tylko zmierzyć się z opóźnieniami związanymi z samym wyszukiwaniem konfliktów, lecz także z różnymi ich kombinacjami

    • Mam wrażenie, że mówicie tylko o utrudnieniu znalezienia hasła do wykorzystania w innym serwisie (mówiąc o n-krotnym hashowaniu, ignorując potencjalne zwiększenie ryzyka kolizji), gdyż zakładacie że atakujący – mając już bazę hashy – ma pełny dostęp do aplikacji.
      Jak rozumiem, znalezienie kolizji (nie oryginalnego hasła) pozwoli dostać się do (tej konkretnej) aplikacji w normalny sposób – w logach itp. pozostawiając normalne ślady sugerujące, że zalogował się (i np. napisał bzdurne komentarze, oczerniające konkurencję) faktycznie dany użytkownik.

      Fakt – jeśli rund hasha będzie 500, a to samo hasło w innym serwisie będzie hashowane 499 razy, to już kolizja najprawdopodobniej nie wystarczy. Czyli jeśli zabezpieczamy usera przed nim samym (wielokrotne użycie tego samego hasła) przez n-krotne hashowanie, to n powinno być losowe, bardziej losowe niż n=6. ;-)

  20. @luxemburg niestetey nie jesteś świadom tego co piszesz. Wynika to z niewiedzy.
    I nie konkurencją a wieloletnią wnikliwą obserwacją ;)

  21. LoL!

  22. To nie była baza piratów. To była baza BANDZIORÓW !

  23. Gdzie można znaleźć tą bazę?

  24. Bije sie w piersi za bledny adres. Dziekuje za sprostowanie. Oczywiscie komentarze sa subiektywne ale ja nie ocenialem Niebezpiecznika.pl a to co pisali inni a mysle, ze jest to serwis dla ludzi ktorzy powinni troche inaczej podejsc do oceny wydarzenia. W koncu kazdego moga troche poniesc emocje, dodam, ze dziekuje powinno byc na porzadku dziennym a sprawa nie jest blacha!

  25. @Sergi
    Nieco dziwne jest to stwierdzenie, zasady dobrego wychowania I obiektywnego oceniania sa bezuzyteczne bo inni tego nie stosuja lub … A gdzie kultura rozmowy?
    Zreszta takze potepienie owego wlamywacza bo skopiowal pliki jest smieszne – toz to podstawa, jak inaczej pokazac ze tam bylem!

    • z bazy mozesz wyciagnac 2, 3 rekordy, jesli chcesz czegos dowieść, a nie kilka tysiecy.

    • Chłopie, najpierw spojrzyj na swoje stwierdzenia:
      “… komentarze dowodza, ze bractwo administratorow slucha wyjasnien torrentleech.org a ignoruje naszego wlamywacza.”
      Komentarze anonimowych czytelników wpływają post factum na to, kogo słuchają dmini niebezpiecznika?
      Z bazy możesz wyciągnąć kilka rekordów, możesz je upublicznić, pokazać adminom. Jak się chce dowieść czegoś, a nie nachapać, to są na to metody.

  26. Ale niektórzy z Was są zawistni. Za niedługo będziecie jeszcze bronić gościa który to zrobił i bić mu brawa. Żałośni hejterzy :)

  27. Sfrustrowany hacker :) Sam kiedyś znalazłem lukę na http://komixxy.pl/, i też admini nawet nie powiedzieli “dzięki”, no ale nie ma co płakać :)

  28. Z tego co widzę ten “hakier” jest zwykłym niedowartościowanym idiotą. Tyle ode mnie.

  29. Aż normalnie się przestraszyłem bo myślałem że to jest tl.org:P. Mam nadzieje że są tutaj ludziska z tej ciemnej strony Polskiego Internetu i wiedzą doskonale że w tych najstarszych Polskich stronach naprawdę pracują ogarnięci ludzie. Fajnie jak widzę takie dysputy zaawansowane na temat kryptografii widać że są tutaj mądrusie ;)

  30. Po co rejestrować się w jakichś serwisach od torrentów, skoro wszystko można znaleźć na piratebayu, btdigg i eztv, a ściąganie leci pełnym łączem?

    Kretynizm.

    “Jak twierdzi włamywacz, opublikowania tych informacji w internecie można było uniknąć, wystarczyło z nim współpracować.”

    Buahaha. Za szantaż to się chyba idzie do paki. ;)

  31. Ciekawe kto tak zna się bo ja siedzę w tym i znam tylko 2 ludzi którzy naprawdę znają w tym temacie z sieci.

  32. Oświadczenie http://www.torrentleech.pl które umieścili na głównej ;)

    Wyrażamy ubolewanie z powodu zaistaniałej sytuacji, którą teraz wnikliwie analizujemy. Znane już są przyczyny wycieku danych. Hasła użytkowników były zakodowane, co utrudnia ich odczytanie. Atakujący wykorzystał lukę kodu która znajdowała się w pliku details.php. Użył do tego programu o nazwie sqlmap. Atak typu SQL Injection. Przez co uzyskał dostęp do bazy danych co miało miejsce tydzień temu i już w następny dzień od tego faktu luka została załatana. Jak można zauważyć atakujący opublikował tylko część bazy z przed tygodnia nie bieżącą. Co świadczy o tym co napisaliśmy wcześniej, że luka została zabezpieczona już tydzień temu. Jak już wspomnieliśmy wyżej atakujący zgłosił się do jednego z naszych administratorów z informacją o luce w kodzie. Nie wskazał gdzie i w jakim pliku jest błąd. Chciał byśmy złożyli mu propozycję w zamian za informacje o błędzie. Po znalezieniu luki, wyszliśmy z propozycją nadania mu rangi Vip lecz nie był nią zainteresowany. Można było przypuszczać, że chodzi mu o cele zarobkowe. Tak więc zostało jego konto skasowane. Być może dlatego poczuł się obrażony.

  33. Przestańcie się ośmieszać bo jesteście żałośni, praktycznie nikt z “inteligencji” wypowiadającej się na ten temat nie zna sprawy od środka, nikt nie wie jak było, jak zachowywali się administratorzy, kiedy zareagowali i w jaki sposób, więc jakim prawem się wypowiadacie? …

    • Twój emocjonalny ton wypowiedzi sugerowałby, że znasz tych administratorów i to dosyć blisko. Mylę się?

  34. Nie ma znaczenia czy znam czy nie znam, hejterskie komentarze ludzi nie mających pojęcia nie tylko o tej sprawie bo nie o to chodzi, tylko o całym temacie są śmieszne, tyle ;]

  35. “Haker” chcial zarobi…nie udalo sie, troche smutno, administratorzy nie chcieli stracic…czy sie udalo…sie zobaczy

    Co do “sposobow” na to jak przechowywac hasla w bazie danych to powiem jedno, ze nadrzednym celem (MOIM zdaniem) jest ukrycie hasla orginalnego, a znalezienie “wzorca” ktrorego suma zgadza sie z suma hasla umozliwi dostep do danego serwisu (z ktorego pochodzi haslo) wiec dobrze by bylo zeby uzyty sposob “przetwarzania” hasla byl w miare możliwosci osobliwy (skrypt dokleja do hasla ciag znakow?, wielokrotne hashowanie? inne metody…ja sie nie znam, ale “biore to na chlopski rozum”;))

    Pozdrawiam

  36. Wielki hakier dziura w kodzie i opublikowanie haseł i ip ludzi. To głupek

  37. Archiwizuje ktoś może takie wycieki? Dostępna jest tylko druga część;

  38. darwin a po co Ci to ?

    • A po co pytasz? A serio- zastanawiałem się, czy nie znajdę kogoś znajomego na fb z tej listy maili:P W końcu nie do każdego starego znajomego ma się czasem adres, nawet pisząc przez komunikator..

  39. niedawno zgłosiłem błąd SQLI na http://www.emilcin.com/ i http://www.nautilus.org.pl/

    i jakoś mi nie podziękowano :( już udostępniam hasła w sieci XD(Aż tak chamski nie jestem).

  40. Dokładnie frajer bo tylko tak mozna nazwac tego nie hakera tylko crackera , myslal ze zarobi jak postraszy . Ale takich osob ktore moga znalezc dziury w aplikacjach jest wiele a tylko zalosni kretyni robia szkody . Wnioskując z zachowania , wystawil bd do publikacji chcial pokazac ze to on wygrał , powinni zglosic sprawe na policje i po zabawie .

    Co do tego :

    ”’balansuje na krawędzi prawa”’

    To przeciez na dole strony jest info ze oni tych plików nie udostepniają a sami userzy , tl tylko te torrenty kataloguje etc. wiec nie powinni miec problemów .

  41. Siema WH ;] Koleś jesteś wielki:D

  42. jak dla mnie White dobra robota po raz 2 TL nie zadbal o to zeby poprawic zabezpieczenia GodJob “my programisci wiemy cos o czym nie wiedza inni xD” Pozdro

  43. White Hacker mam tu konto niepotrzebnie wyjawniłeś dane zwykłych użytkowników oni ci przecież nic nie zawinili, osobiście hasła do konta nie zmieniałem bo wiedziałem, że to i tak bez sensu bo jeszcze coś będziesz kombinował, zmieniłem tylko hasło do maila i do jednego ważnego dla mnie trackera na 11 cyfrowe składające się w większości ze znaków specjalnych, myślę, że jestem bezpieczny a po moim koncie na TL.PL nic nie będziesz miał bo i tak jestem zaledwie PowerUserem i nie zależy mi tak bardzo na tej stronie. Załoga jest chamska o czym się przekonałem już i mam to gdzieś.
    Pozdrawiam.

  44. http://paste2.org/p/1565417

    Hoho, gosciu chyba odpuscil.

  45. buehehe…
    Kolejny fail zalosnej zalogi xD
    A na SB “pan” sysop probowal zataic to i pisal jakies bzdury haha zalosna strona

  46. skurw!@!@ je!@##! wystarczy cos napisac w SB odnosnie wycieku danych to odrazu usuwaja konto!!! WEZCCIE ROZWALCIE TA STRONE W KOSMOS!! co za matoly tam pracuja

    • To i tak milo z ich strony, ze usuwaja a nie blokuja :D

  47. Dane z przed tygodnia ? za tydzień znów da inna cześć bazy i napisze ze się włamał haha
    Staff pojechał po ambicji pryszczatemu white i są efekty. Jak on szukał luki to staff pewnie piwo pil haha :)

    • To, że załoga mówi, że sprzed tygodnia to nie znaczy, że to prawda ;]

  48. gowno a nie kasuja jak wyzywacie na sb i non stop dajecie linki to nic dziwnego

  49. Pokazałem wam gdzie raki zimują jestem najlepszy

    • w czym najlepszy? w używaniu gotowego narzędzia którego gotową opcją jest pobieranie bazy danych? lepiej cineq (bo taki jest twój nick) powiedz na ilu stronach dali ci bana za próbę włamu.

    • @zaraza

      Słaby trop, szukaj dalej …

    • twoje dane zostały udostępnione pomiędzy załogi stron.

Twój komentarz

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