Kopia bezpieczeństwa a odzyskiwanie danych w środowisku VMware

Dokument obejmuje zagadnienia związane z praktyczną realizacją kopii bezpieczeństwa środowisk wirtualizowanych o dużej skali wdrożenia. W takich...
pobierz »

Biometria głosowa: efektywność, bezpieczeństwo, łatwość korzystania

Zwiększenie liczby oszustw i kradzieży tożsamości wzbudza coraz większe zaniepokojenie klientów możliwością utraty danych osobowych i poufnych danych....
pobierz »

IBM BladeCenter - IT w pudełku

Rozwiązanie IBM BladeCenter integruje serwery blade, pamięć masową i przełączniki sieciowe w jednej obudowie. Zapewnia przy tym redukcję kosztów...
pobierz »

Hakerzy: Polska nie ma się czego wstydzić

21 sierpnia 2006

PC World — PC World: Zasłynąłeś na Bugtraqu z aktywnych poszukiwań dziur w komunikatorach. Powiedz nam, czy celowo rozglądałeś się za błędami w Gadu-Gadu, czy może same ci się napatoczyły?

Jarosław Sajko: Dziur było wiele. W zasadzie okazało się, że Gadu-Gadu jest dziurawe na tyle, na ile się spodziewaliśmy, czyli jak budżet naszego kraju. Nie mogę powiedzieć, że były to błędy znalezione przypadkowo. GG "niefrasobliwym zachowaniem" po prostu przyciągnęło naszą uwagę.
To co się okazało (w przeciągu roku znaleźliśmy co najmniej 13 błędów), nie jest moim zdaniem wielką sensacją - jest to raczej logiczna konsekwencja tego, co wiemy o błędach bezpieczeństwa w oprogramowaniu w ogóle i tego co wiemy o Gadu-Gadu. Da się to wyrazić bardzo krótko: jeśli aplikacja powstaje w ciągu nocy i zajmuje się nią jedna osoba, nie ma nawet mowy o porannym przeprowadzeniu audytu bezpieczeństwa.

Jak dotarłeś do dziur? Czy było to trudne?

W oparciu o standardowe metodyki przeprowadzania audytu kodu binarnego czyli: deassemblację i śledzenie wykonania kodu. Cała operacja z pewnością wiele zawdzięcza wykorzystaniu długopisu, kartki papieru, mojej podstawowej znajomości assemblera x86 oraz ogólnych pojęć dotyczących przetwarzania informacji w sposób elektroniczny.

Jarosław Sajko

Jarosław Sajko to absolwent Politechniki Poznańskiej na kierunku informatyka. Od kilku lat związany z bezpieczeństwem ICT. Pracownik Zespołu Bezpieczeństwa PCSS (Poznańskie Centrum Superkomputerowo - Sieciowe), gdzie zajmuje analizą kodów źródłowych oraz binarnych pod kątem błędów problematycznych z punktu widzenia bezpieczeństwa aplikacji/systemu oraz audytami systemów teleinformatycznych.

Podsumowując: jest to raczej kwestia chęci niż mitologicznych mocy czy umiejętności.

Czego dotyczyły ujawnione błędy i czy zostały naprawione?

Ujawnione błędy można posortować na kilka kategorii. Były to bugi łatwiejsze do poprawienia, czyli proste błędy w implementacji takie jak brak kontroli nad ilością danych zapisywanych w pamięci lub przesadne zaufanie do danych wejściowych.

Było też kilka błędów, których naprawienie musiało kosztować sporo czasu. Wśród nich znalazł się protokół jakim posługuje się komunikator (został on zaprojektowany bez przykładania wagi do bezpieczeństwa) czy problemy z mechanizmami renderowania komunikatów. Tutaj nie ma żadnej natychmiastowej procedury tworzenia łaty polegającej na modyfikacji kilku linijek kodu - pewnie dlatego część z tych problemów istnieje do dzisiaj.

Wydaje się jednak, że te najbardziej krytyczne zostały usunięte bądź ryzyko ich wystąpienia zostało zredukowane do minimum.

Niezależnie od aktualnego statusu (załatany lub nie) - byłbyś skłonny szczegółowo opowiedzieć o jednym z błędów?

Jeden z błędów bezpieczeństwa był o tyle ciekawy, że wykorzystywał jedynie błędy w logice aplikacji i przez to był niezależny od platformy systemowej, a ponadto wykorzystywał ukrytą funkcjonalność aplikacji GG. Był to bug związany z połączeniami bezpośrednimi, a umożliwiający kradzież poufnych danych.

Mianowicie: jedną z funkcji GG jest możliwość przesyłania plików pomiędzy znajomymi użytkownikami. Usługa realizowana jest za pomocą połączeń bezpośrednich i działa również przez NAT-y i firewalle. W takim przypadku strona inicjująca operację wysyła specjalny pakiet do swojego rozmówcy, który oznacza mniej więcej tyle: Chcę wysłać Tobie plik, ale jesteś za NAT-em/zaporą, więc to ty musisz się ze mną połączyć, żeby go odebrać. Na co program rozmówcy automatycznie odpowiada łącząc się na podany przez stronę inicjalizującą adres i port. Już samo to jest potencjalnym źródłem zagrożenia, ale to nie koniec opowiastki. Od tego momentu stronę, która połączyła się z podanym adresem po otrzymaniu takiej prośby będziemy nazywać dla uproszczenia ofiarą.