Eksperyment: łamanie hashy haseł w Windows

Zwykle nie chce mi się sprawdzać rzeczy oczywistych, postanowiłem jednak sprawdzić skuteczność użycia rainbow tables w łamaniu haseł w Windows. W zasadzie to nawet nie tyle skuteczność tej metody, co skuteczność tablic dostępnych wraz z ophcrack (choć użytych w Cain). Różne rzeczy przychodzą do głowy, gdy wszędzie można usłyszeć jakieś dzwoneczki, oraz złowrogie słowo christmas...

Postanowiłem sprawdzić skuteczność tablic dla hashy LM. Dla szybkiego przypomnienia – hash jest generowany w taki sposób, że hasło o długości (maksymalnie) 14 znaków dzielone jest na dwie połowy (po 7 znaków), które dalej traktowane są jednakowo. Nie jest uwzględniana wielkość znaków (uppercase), generowany jest klucz DES i szyfrowany stały ciąg znaków. Rezultat tej operacji to hash hasła. Efektywnie więc wystarczy wygenerować tablice dla wybranego zbioru znaków dla ciągów o długości od 1 do 7 znaków. Wykorzystałem tablice, które zawierają litery i liczby (te dostępne z ophcrack, konkretnie XP free small). W testowym systemie stworzyłem 1000 użytkowników, dla każdego ustawiłem losowe hasło o długości dokładnie 14 znaków. Następnie hashe zrzuciłem do Cain (ophcrack odmówił współpracy). Skutek – złamane hasła dla 100%25 kont w niecałe 5 godzin (15876 sekund). Nie, dodanie znaku specjalnego do hasła nie rozwiązuje problemu, są pełniejsze tablice, choćby: Hak5 produces 120GB LM hash rainbow table – complete charset!!!. Zresztą proponuję zajrzeć również na torrenty...

Niestety, sposób przechowywania hasła w Windows (hashe) nie są “zwinne”, co oznacza, że nie ma prostej metody zastąpienia wykorzystanych algorytmów innymi. Hashe LM zostały (domyślnie) wyeliminowane dopiero w Vista. Hashe NTLM są dużo lepsze, ale przed tego typu kryptoanalizą również się nie są w stanie oprzeć. Przestrzeń w NTLM jest jednak dużo większa, niż dla LM (do 127 znaków, rozróżniane duże i małe litery), dlatego przygotowanie “kompletnych” tablic będzie dość... pracochłonne.

Dla przypomnienia, system nie stworzy hasha LM jeśli:

Przy okazji warto pamiętać, że w przypadku użycia EFS klucz prywatny potrzebny do odszyfrowania plików jest chroniony przy pomocy (w uproszczeniu, ponownie odsyłam do opisu DPAPI, polecam też ten opis: Windows Data Protection) hasła użytkownika. Jeśli zostanie ono złamane, atakujący uzyska dostęp do plików zaszyfrowanych EFS. Właśnie uzyskanie/utrata dostępu do plików zaszyfrowanych EFS może przemawiać za złamaniem hasła w stosunku do jego ponownego ustawienia.

Oczywiście atak na hashe haseł wymaga dostępu do nich. Standardowo są one przechowywane w pliku SAM w formie zaszyfrowanej (patrz: How to use the SysKey utility to secure the Windows Security Accounts Manager database), jednak o ile hasło nie znajduje się na zewnętrznym nośniku (dyskietka lub pamięć użytkownika), wartość tego szyfrowania jest iluzoryczna.

...i (między innymi) właśnie dlatego szyfruję cały dysk :)

Oryginał tego wpisu dostępny jest pod adresem Eksperyment: łamanie hashy haseł w Windows

Autor: Paweł Goleń