9:44
11/11/2010

Szybkie łamanie haseł do Windowsa

Naprawdę szybkie. Czternastoznakowce w 5 sekund. Jak to możliwe? A tak:

Tablice tęczowe na dyskach SSD

Oto klucz do szybkiego “łamania” haseł, chociaż żeby być technicznie proprawnym, należałoby napisać wyszukiwania hashy w slowniku. Przy pomocy tablic tęczowych na SSD, hasła można łamać z prędkością 300 miliardów na sekundę.

Mowa oczywiście o LM Hashach, czyli należy pamiętać, że hasła dłuższe niż 7 znaków są dzielone na 2 części i hashowane osobno.

Hash Cracker

Online'owy łamacz hashy, wykorzystujący dyski SSD do przechowywania tablic tęczowych.

Firma Objectif Securite udostępnia online’owego crackera hashy, dzięki któremu można samemu przetestować kilka przykładowych hashy. Cyberarms zrobił następujący test:

aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
hasło: (puste)
czas: 2 sec.

747747dc6e245f78d18aebeb7cabe1d6:43c6cc2170b7a4ef851a622ff15c6055
hasło: T&p/E$v-O6,1@}
czas: 11 sec.

Robi wrażenie! Ale jest dobra informacja, LM Hashe można wyłączyć. Pozostaje pytanie, co w takim razie z hashami NTLM?

NTLM hash – łamanie

Można pobawić się Ophcrackiem (autorstwa tej samej firmy) …albo skorzystać z techniki ataku zwanej “pass the hash“, której implementacje znajdziemy np. w nieśmiertelnym BackTracku… Przy okazji, warto wiedzieć, że z protokołu NTLM także można zrezygnować na rzecz NTLMv2, a jeszcze lepiej na rzecz Kerberosa z certyfikatami, biometrię albo OTP. Hashe NTLM, jak celnie zauważa Paweł Goleń, mimo to dalej będą przez Windowsa przechowywane — czy to jest problem? Patrz ramka niżej:

Warto podkreślić, że jeśli atakujący jest w stanie pobrać hashe z komputera ofiary, to ataki typu pass-the-hash, czy samo złamanie hasła jest tylko jednym z wielu zmartwień właściciela pwniętej maszynki…

Jeśli ktoś z was miał przyjemność korzystać z tablic tęczowych na dyskach SSD, dajcie znać, o ile szybciej udało się “połamać” hasła…

Przeczytaj także:

21 komentarzy

Dodaj komentarz
  1. Składowania hasha NTLM nie można wyłączyć. Można natomiast wyłączyć protokół uwierzytelniania NTLM.

    • Paweł: racja z tym hashem, przeedytowałem tekst tak, żeby było to bardziej czytelne.

  2. Dobrze, ze wspomnieliscie o specyfice LM, bo na wykopie bylo info o tablicach Objectifu bez tego znaczacego szczegolu:

    Hasla powyzej 7 znakow sa dzielone na dwie czesci, obkladane uppercasem i osobno haszowane DESem, co sprawia ze zlamanie takiego hasza to nie problem dla komputera sprzed 5 lat.

    Wydaje mi sie, ze Objectif troche naciaga – ich cracker lamie tylko hashe LM a samo NTLM jest dla sciemy. Co wiecej – zyczy sobie 99$ za tablice ktore ktora lamia 7znakowe hasla a nie 14…

    Jedyna innowacja moze byc trzymanie czesci tablic w RAMie i uzycie dyskow SSD, ale watpie zeby to bylo tak skalowalne jak uzycie GPU.

  3. A jak odzyskać ;-) hasło w HP-UX (trusted system) mając zapis w pliku z hasłem np. /tcb/files/auth/k/ktos ?

  4. kolejny wpis bedzie o zlamaniu enigmy – zawsze najswiezsze informacje.
    czas lamania mozna skrocic (jednoczesnie zwiekszajac zajmowana przestrzen dyskowa), to tez dziala w druga strone.
    taniej chyba wyjdzie kupic jakies dobre gpu, niz wydajny dysk ssd (o odpowiedniej przestrzeni).

  5. A skąd się biorą te hashe? Bo rozumiem że na ich podstawie łamiemy hasło.

  6. Ciekawe jak jest z bezpieczeństwem solonego MD5… a najlepiej to mieć >20znakowe hasło (o ile system informatyczny pozwala ;) https://niebezpiecznik.pl/post/security-fail-krotsze-hasla-sa-lepsze/ ).

  7. Zalezy jak solone.

    Rainbowtables to doskonala technologia utrzymujaca rownowage pomiedzy przestrzenia lamanych hasel, prawdopodobienstwa ich zlamania, czasu potrzebnego na wygenerowanie tablic, objetosci tablic i czasu ich przetwarzania (czyli lamania hasza).
    To taka hybryda pomiedzy brutem (sktuczenosc np. pow. 99.5%) a slownikiem (w rainbowtables nie jest trzymana kazda para haslo-hasz).

    Takze juz kilkuznakowa sol skutecznie uniemozliwia atak poprzez tablice,
    nie zmienia to faktu ze sa jeszcze inne metody lamania haszy (np. znalezienie kolizji – czyli inny plaintext dla ktorego hasz jest identyczny).
    Ja preferuje podwojne haszowanie w taki sposob: trzymamy w bazie np. md5(sol1+haslo) i sha1(sol2+haslo) do tego warto pomyslec nad algorytmem wyznaczania soli jako funkcji od loginu (albo jakiejkolwiego innego i zapisanie soli w bazie – ale to juz gorsze rozwiazanie) – zeby sie ustrzec przed “zlamaniem” soli majac do dyspozycji krotkie haslo. Takie “podwojne” haszowanie uchrania przed kolizja, bo znalezienie takiego plaina, zeby dal w dwoch algorytmach haszujacych kolizje jest juz prawie niemozliwe.

  8. Ciekawe rozwiazanie mial (na szczescie juz zmienili :) ) bodajze Kredytbank albo Alior – modul kryptograficzny w Javie (i wlasnie to byl problem – nie bylo latwo automatycznie zemulowac srodowisko dla robota) obliczajacy w jakis sposob hasze (reverse-engineering zlozenia funkcji haszujacych nie jest trywialny). Haszowanie po stronie klienta – wiec MITM na duzo sie nie zda, do zlamania trzeba by miec juz jakis exploit/wirus na komputerze.

    Ah, zapomnialem dodac ze MD5 jest juz dosyc przestarzale, sa efektywne metody znajdowania kolizji (nie dowolnych, a dla konkretnego hasla/hasza)

  9. A ktoś wie jak odtworzyć hasło w HP-UX (trusted system) mając plik z za-hash-ownaym hasłem ?

  10. @gadulix: szczerze mówiąc uważam, że z tymi dwoma hashami rozwiązujesz zupełnie nie ten problem. Funkcje hashujące muszą dawać kolizje, bo tak po prostu musi być w przypadku funkcji, której dziedzina jest (praktycznie) nieskończona, natomiast przeciwdziedzina zawiera skończoną ilość elementów.

    W tym konkretnym wypadku mamy jednak zbiór danych na wejściu jest ograniczony, w związku z tym prawdopodobieństwo kolizji nawet dla funkcji md5 jest niewielkie. W rezultacie jeśli ktoś znajdzie jakiś plaintext, który w połączeniu z saltem daje hash, to prawie na pewno nie znalazł kolizji, tylko trafił w hasło użytkownika. W rezultacie oba hashe będą prawidłowe.

    Lepszym kierunkiem jest wykorzystanie bardzo kosztownego sposobu liczenia hashy, przez co atak bruteforce jest nieefektywny. Przykładem może być blowfish crypt.

  11. Wiem, że to nie na temat, ale czekałem kilka dni, aż taki news się tu pojawi:

    http://www.dobreprogramy.pl/Microsoft-wprowadza-pelna-obsluge-SSL-do-Hotmaila,Aktualnosc,21421.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+dobreprogramy%2FAktualnosci+%28dobreprogramy+-+Aktualno%C5%9Bci%29&utm_content=FeedBurner

    Nie rozumiem, czy to w praktyce oznacza, że gdy obie strony będą korzystały z Hotmaila, to całość korespondencji będzie zaszyfrowana, czyli bezpieczeństwo będzie tylko mnimalnie mniejsze w stosunku, do tego, gdyby 2 strony używały PGP?

    Jeszcze raz przepraszam za off top i proszę o niekasowanie lub dodanie newsa o tym.

  12. @gadulix
    Kredyt Bank miał (może jeszcze ma – już nie używam) coś takiego – aczkolwiek zupełnie nie rozumiem, dlaczego nie zrobili tego w javascripcie tylko jako aplet Javy (przez co nie dało się zalogować z bardziej prymitywnych urządzeń). W każdym razie faktycznie przesyłana wartość była jednorazowa.

    cały kod sprowadza się do:
    $password = sha1_hex(substr($pin,0,4));
    $signature = sha1_hex(sha1_hex($id.$pin).$ticket);
    gdzie $ticket jest jednorazowy dostarczany przez aplikację

  13. @adiblol – na średniej jakości grafie (hd 5770) łamanie bruteforcem md5 daje radę ok. 1,2G haszy/s – więc 7 literowe hasło składające się z małych i dużych liter i cyfr to ok. 1h; przy dodaniu znaków specjalnych ten czas mocno się wydłuża :)

    BTW.: ja stosuję sha512 + 50 losowych znaków salta wplecionych w wygenerowanego hasza na określonych pozycjach. Krótko mówiąc złamanie hasła bez configa jest praktycznie niemożliwe* :) Nawet nie wiadomo jak wygląda hasz bez soli, więc trudno to porównać… Poza tym sha512 jest strasznie wolne w porównaniu do np. md5.

    ps. tak, wiem, że ten sposób haszowania jest trochę paranoiczny, ale nikt mi nie zarzuci, że słabo chronię hasła :D

    * jeśli to jest do złamania to prośba o wytłumaczenie jak/linka do wytłumaczenia.

  14. Wystarczy użyć jednego niestandardowego znaku w haśle i automatycznie tylko hash NTLM będzie przechowywany (np. polskie znaki diakrytyczne, €). Jednak ja mam zawsze wyłączone przechowywanie hashy LM.

    @Paweł Goleń – też uważam, że najlepszym wyjściem jest kosztowny sposób obliczania hashy. I wcale nie musi to być skomplikowane, np. WinRAR oblicza 0x40000 razy kolejne hashe (nawet AES chyba jest wykorzystywany przy obliczeniach, jak dobrze pamiętam). Dzięki temu, bruteforce nawet na najnowszych komputerach jest strasznie powolny, a wygenerowanie tęczowych tablic dla sensownej długości hasła, zajęłoby ogrom czasu.

  15. Po zastanowieniu mała korekta – oczywiście w przypadku WinRARa wygenerowanie tęczowych tablic byłoby niemożliwe, a nie czasochłonne (bo przecież nie jest przechowywany hash hasła w archiwum).

  16. @hydralisk: analogicznie jest w przypadku TrueCrypt. Tylko tu mamy do czynienia z generowaniem klucza na podstawie hasła a nie przechowywaniem hasha hasła. W obu przypadkach jednak wydłużenie czasu na sprawdzenie danego hasła jest pożądane.

  17. Mnie ciekawi jak fizycznie się odbywa weryfikacja haseł w całej informatyce. Jak porównuje się wpisane hasło z tym zapisanym w pamięci. Procesor w czasie swojej pracy wytwarza zmienne pole magnetyczne w zależności od częstotliwości pracy, przerabianych “słów”, obliczeń, adresowania innych elementów i wielu innych czynników. Czy nie dałoby się przy pomocy jakiejś pluskwy elektromagnetycznej wychwycić te zmienne pola magnetyczne ? Jej “anteną” może być bezpośrednio radiator. Byłyby problemy z częstotliwością próbkowania gdyż musi być znacznie większa od częst. wychwytywanych.

  18. @joker – wątpię, jednak idąc tym tropem można dużo prościej – każda klawiatura działa trochę jak antena, jej nieekranowany kabelek sieje dookoła nawet nieźle. Przy pomocy odpowiedniego sprzętu można odczytać na odległość co ktoś pisze :) (niektórzy mają bezprzewodową, więc pewnie jest jeszcze prościej)

    Co do haseł, to zazwyczaj hasło nie jest nigdzie zapisane w takiej postaci jak je wpisujesz, tylko obliczane są różnego rodzaju sumy kontrolne (hash) – np. MD5, SHA itp. Dopiero ewentualnie ta suma jest porównywana z tą prawidłową (gdzieś zapisaną), albo w ogóle nigdzie nie jest zapisywana, tylko np. służy jako klucz szyfrujący (wtedy weryfikacja hasła polega na próbie odszyfrowania kluczem, powstałym z hasła podanego przez użytkownika i sprawdzenie, czy to co zostało odszyfrowane jest poprawne). Tak więc, nikt nie pozna bezpośrednio hasła, może co najwyżej łamać tą sumę kontrolną (lub też czasami może ją podmienić, tak żeby ustawić swoje, znane hasło)

  19. Kurcze w pierwszej chwili miałem wrażenie, że coś nowego. A tu dajecie linka do “XP Special Demo”. Kurcze trochę stare, tak samo jak całe zagadnienie hashów LM i NTLM. Takie rzeczy to się kilka lat temu ogarniało… Ale news dobrze opisany :) No fakt, może kilka lat temu to bez SSD, ale na zwykłym HDD też hasła równo padają ;p

  20. “Jedyna innowacja moze byc trzymanie czesci tablic w RAMie i uzycie dyskow SSD, ale watpie zeby to bylo tak skalowalne jak uzycie GPU” – dyski ssd nie przyspieszają kryptoanalizy – chodzi o to żeby jak najmniej ją spowalniały – jeżeli wczytywanie tablicy do ramu będzie szybsze niż analiza tablicy przez procesor i/lub gpu to dalszy wzrost prędkości dysku nie przyniesie korzyści. Przynajmniej ja tak to rozumiem.

Twój komentarz

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

RSS dla komentarzy: