Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Odwołujesz się anonimowo do API. Podajesz login użytkownika i dostajesz jego… hasha hasła :D A to nie koniec tej szalonej historii buga w realnej aplikacji.
Troy Hunt opublikował na swoim blogu ciekawy artykuł opisujący incydent, który przydarzył się Spoutible – portalowi społecznościowemu, który został założony przez osoby związane wcześniej z Twitterem na kanwie sagi przejęcia portalu przez E. Muska.
Wycieki danych z API to nic nowego, często zdarza się, że źle zaprojektowana i wdrożona autoryzacja pozwala na dostęp do danych, do których użytkownik nie powinien mieć nigdy dostępu. To co jednak wyróżnia tę sytuację to bardzo rozbudowane odpowiedzi na zapytania, które nie wymagają uwierzytelnienia – np.:
password: "$2y$10$B0EhY/bQsa5zUYXQ6J.NkunGvUfYeVOH8JM1nZwHyLPBagbVzpEM2",
Wierzymy Troyowi, że gdy zobaczył taką informację zwracaną przez portal, gdy odpytał go o swojego użytkownika, to nie mógł w to uwierzyć.
Mimo, że portal korzysta z algorytmu bcrypt do przechowywania hasła (uznawanego za bezpieczny) to jednak nie jest to rozwiązanie problemu. Bcrypt może znacznie wydłużyć czas łamania hasła nawet przy wykorzystaniu najnowszych układów GPU, ale to nie znaczy, że słabe hasła użytkowników nie mogą zostać w ten sposób odzyskane.
Słabości haseł to jedno, ale dobre praktyki mówią, że użytkownicy powinny korzystać z uwierzytelniania wieloskładnikowego. Na wypadek gdyby jednak ich poświadczenia zostały przejęte. Spoutible oczywiście umożliwia dodanie takiego składnika, więc problemu nie ma, prawda? Siedzicie? Jeśli nie, to usiądźcie. W przypadku odpytania API o konto, dla którego zdefiniowany był drugi czynnik, aplikacja zwracała jeszcze takie informacje:
2fa_secret: "7GIVXLSNKM47AM4R",
2fa_enabled_at: "2024-02-03 02:26:11",
2fa_backup_code: "$2y$10$6vQRDRDHVjyZdndGUEKLM.gmIIZVDq.E5NWTWti18.nZNQcqsEYki"
Tak, 2fa_secret
to seed, wykorzystywany przy generowaniu kodów jednorazowych. Znając tę wartość, atakujący jest w stanie odtworzyć i ten składnik. Gdyby się jednak okazało, że telefon z aplikacją Authenticatora wpadł Wam do wody, a kartkę z kodami zapasowymi zgubiliście, to Spoutible ma na to sposób – hash z kodu zapasowego (2fa_backup_code
), składającego się z sześciu cyfr… Pamiętacie co pisaliśmy dwa paragrafy wyżej o słabych hasłach? Przestrzeń przeszukiwania takiego pinu jest na tyle mała, że średniej klasy karta graficzna znajdzie brakujący kod w kilka minut. Jak na początek lutego to naprawdę silna kandydatura do największej wpadki security w tym roku (chociaż jak zwykle z niecierpliwością czekamy na grudzień).
~fc
Właśnie wielką wadą HOTP/TOTP/YKOTP jest to, że serwer uwierzytelniający ma klucz prywatny użytkownika. Jakikolwiek wyciek kompromituje OTP.
Dlatego: używać U2F/FIDO/FIDO2. Tam serwisy mają jedynie klucze publiczne generowane per-serwis.
Heh, niestety dla byłych pracowników Twittera, wygląda, że akurat co do ich zwolnienia, to Musk się nie mylił :)
Poza tym że mozemy enumerowac username uzytkownika, to coś daje nam sam hash z podanego algorytmu? Nie znamy soli wiec chyba zadne ataki na odkodowanie tego hashu nie mają sensu
Pro tip – w „hashu bcrypt” zawarta jest już sól (i nawet ją widać na screenie). Patrz: https://en.wikipedia.org/wiki/Bcrypt
Jak nie mają sensu? Jak hasło słownikowe, to kilka minut hashcata i po haśle.
Hashcat na mojej maszynie cała entropię dla 8 znakow (maly litery, duze litery i cyfry) przeszukuje w ok. 4 minuty.
@Karol Dobra, dopiero załapałem czego tu nie łapiesz. Sól nie powoduje tego, że hasz jest niełamalny. Sól powoduje, że hasz słowa P@słord jest za każdym razem (a raczej: za każdą solą) inny. Czyli nie możesz mieć gotowej bazy haszy popularnych słownikowych słów (czyli tak zwanych: tęczowych tablic).
Takie solone hashe trzeba po prostu łamać licząc hasze kolejnych kombinacji liter (lub słów), ale używając konkretnej soli.
Czyli w praktyce wystarczy silne hasło i nic nie da się zrobić, jak to jest wpadka roku to to bardzo dobry rok.
„praktyce wystarczy silne hasło” – nie jest to kompatybilne z przyzwyczajeniami ogromnej części użytkowników ;-)
Cześć, A co moglibyście powiedzieć o mechanizmie „scram-sha-256”? Czy wg. Was jest to rozwiązanie bezpieczniejsze od zastosowanego w omawiany tu przypadku?