Hakerzy: Polska nie ma się czego wstydzić

Ofiara po przeprowadzeniu nieskomplikowanej procedury autoryzacyjnej polegającej m. in. na wysłaniu swojego identyfikatora i sprawdzeniu czy tajnym kodem dostępu otrzymanym od drugiej strony połączenia jest UDAG (czyli "GADU" w porządku little-endian) rozpoczyna pętlę oczekiwania na komunikaty od drugiej strony, która teraz dla uproszczenia będziemy nazywać atakującym.

Atakujący wysyła komunikat z prośbą o przesłanie pliku z katalogu plików tymczasowych komunikatora ofiary. Trudno mi powiedzieć co autor programu miał na myśli programując taką funkcję, ale teraz to nieistotne. Ten plik, który chcemy z tego katalogu plików tymczasowych pobrać może się nazywać np.: '..\..\..\..\..\..\..\..\..\windows\repair\sam' lub '..\Ja\config.dat' lub '..\Ja\archive.dat'. Możliwości jest wiele, przesłaniu może ulec zawartość pulpitu, skrzynka pocztowa itd. Oczywiście program ofiary posłusznie, automatycznie taki plik odsyła i zamyka połączenie. Koniec opowiastki.

Mamy tutaj generalnie dwie sprawy. Po pierwsze wydobyliśmy na światło dzienne ukrytą funkcjonalność o nieznanym przeznaczeniu. Po drugie dostrzegliśmy, że program zanadto ufa danym wejściowym.

Aby wykryć tę dziurę, musiałem jedynie przeanalizować fragment kodu odpowiadający za nawiązywanie połączeń bezpośrednich. Dowiedziałem się, że poza zwykłym przesyłaniem plików można "poprosić" kogoś o przesłanie pliku z katalogu cache. Okazało się też, że nazwa pliku, o który prosimy nie jest sprawdzana pod kątem zawartości. To znaczy, że można było w jej miejsce podać dowolny ciąg znaków, co stwarza potencjalnie kilka możliwości. Jedną z nich jest możliwość kradzieży danych co udało się empirycznie stwierdzić.

Inną ciekawą opcją jest fakt, że w podobny sposób można było dowolny plik w dowolnym miejscu na komputerze ofiary zapisać.

Jak można było wykorzystać ujawnione dziury?

Kilka z ujawnionych błędów można było wykorzystać do przejęcia całkowitej kontroli nad zdalnym komputerem. Pozostałe były mniej groźne, umożliwiały kradzież poufnych danych z komputera ofiary czy też zwykłe ataki na dostępność powodujące zawieszenie się czy to aplikacji lub systemu.

Jak współpracowało Wam się z Gadu-Gadu?

Błędy zgłaszane były dwukrotnie, w odstępie rocznym. Za każdym razem były inne i dotyczyły odmiennych edycji komunikatora (w tym Gadu-Gadu udostępniło nową wersję aplikacji). Początkowo rozmawialiśmy z panem Łukaszem Foltynem, autorem kodu GG - nasze wymiany zdań przebiegały bez zakłóceń. Wysłaliśmy opis błędów, dostaliśmy informację zwrotną wraz z prośbą o wyjaśnienie (oczywiście odpowiedzieliśmy) itd.

Później po wysłaniu obszernej informacji otrzymaliśmy tylko ticket (bilet) z jakiegoś systemu, na który to ticket mieliśmy się powoływać w przypadku dalszej korespondencji. A po krótkim czasie jeszcze informację, że nasze wnioski zostały przekazane "tam gdzie trzeba". Wkrótce pojawiła się nowa wersja komunikatora...

Czy masz inne doświadczenia związane z bezpieczeństwem? Nad czym teraz pracujesz?

Poza GG publikowaliśmy jeszcze informacje na temat błędów w dwóch innych komunikatorach: Tlen.PL oraz WPkontakt. Jakiś czas temu ujawniliśmy również raport z krótkich, aczkolwiek dających wiele do myślenia badań dotyczących portali bankowości elektronicznej w Polsce (http://security.psnc.pl/reports/e-banking_polska_ssl_report.pdf ).

W bezpieczeństwie informacji chodzi o to, żeby sekret pozostał sekretem, staram się więc dbać o bezpieczeństwo informacji na temat, nad którym aktualnie pracuję :).