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...
Eksperyment: łamanie hashy haseł w Windows
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% 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:
- hasło ma długość większą niż 14 znaków,
- wyłączy się hashe LM: How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases,
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 :)
