Serdecznie zapraszam na spotkanie Koła Naukowego Informatyków KUL “Ataki na intranet z sieci WWW: skanery portów w JavaScripcie/HTML i łamanie reguły same-domain“.
Termin i miejsce: 10 stycznia, godzina 18.15, sala 104 Wydziału Matematyczno-Przyrodniczego KUL
Uwaga! Zmiana terminu na: 10 stycznia, godzina 16.30.
Bieżące informacje o spotkaniach KNI KUL mozna znaleźć na stronie: kni.kul.lublin.pl
Po ogromnej popularności artykułu Łukasza Lacha na hacking.pl można spodziewać się, że wbrew temu co napisałem w poprzedniej notce, luki w Allegro zaczną być wkrótce wykorzystywane w praktyce. Warto zatem wiedzieć, jak bronić się przed wspomnianymi tam atakami.
Na początek, dla osób nie znających mechanizmów XSS i CSRF, krótkie wyjaśnienie: luki opisane przez Łukasza Lacha nie umożliwiają zaatakowania konta dowolnego użytkownika. Atak następuje w momencie, kiedy ofiara otworzy stronę zawierającą złośliwy kod. Link do tej strony może być przesłany mailem, wstawiony w opis aukcji lub na stronie “o mnie”. W najgorszym przypadku złośliwy kod znajduje się bezpośrednio we wstawionym przez nieuczciwego użytkownika opisie aukcji.
Dodano 22 grudnia 2006: zgłoszona luka nie dotyczyła opisów aukcji (http://anakin.us/blog/allegro-pelne-dziur-jak-to-bylo/)
Jak zatem się bronić?
Niestety żadna z tych metod (poza pierwszą, oczywiście nie polecaną, ale skuteczną ;)) nie broni przed atakiem CSRF przy pomocy obrazków w opisach aukcji - zaś wyłączenie wyświetlania grafiki nie ma większego sensu w serwisie aukcyjnym. Na szczęście tego typu ataki mają bardzo ograniczone możliwości, można się też spodziewać że ekipa Allegro szybko zlikwidowałaby źródło w razie pojawienia się złośliwego kodu wykorzystującego tą lukę.
Poniższy tekst mojego autorstwa ukazał się pierwotnie w serwisie aukcje.org, za co bardzo dziękuję panu Jackowi Strzembkowskiemu.
Poniższe zestawienie jest trochę nierówne - przy testach Allegro spędziłem dobrych kilkanaście wieczorów, podczas gdy na stronach ebay.pl i swistak.pl ledwie po kilka godzin. Przepraszam właścicieli wszystkich pominiętych w tym tekście polskojęzycznych serwisów aukcyjnych.
Oczywiście wszystkie trzy serwisy stosują SSL dla formularzy logowania użytkownika. Zapobiega to podsłuchaniu hasła - niestety tylko podczas logowania. Na http://www.swistak.pl/konto_nowe.html przesyłamy hasło w postaci nieszyfrowanej (możemy wymusić szyfrowanie, wpisując ręcznie adres https://ssl.swistak.pl/konto_nowe.html), podobnie jest podczas zmiany dotychczasowego hasła w ustawieniach użytkownika serwisu Allegro.
Zastanawia “złamana kłódka” na szyfrowanych stronach Świstaka - okazuje się, że serwis korzysta ze skryptu statystyk gemius.pl, importując go przez nieszyfrowane połączenie HTTP. Nie powoduje to bezpośrednio możliwości ujawnienia hasła, ale:
Połączenie z gemius.pl lepiej realizuje Allegro - wykorzystuje w celu zapisywania danych bezpieczny skrypt z własnej domeny, a w przypadku połączenia SSL w ogóle ze statystyk na stronie logowania rezygnuje.
[Problem “złamanej kłódki” został przez serwis Świstak bardzo szybko zlikwidowany.]
Skrypty podobne do https://ssl.allegro.pl/direct_login.php?request_server=lukasz.pilorz.net&request=/index.php to świetne narzędzie dla phisherów (powyższy przykład jest dodatkowo podatny na XSS). Niestety podobne luki ma również eBay, mimo że są one od dłuższego czasu aktywnie wykorzystywane.
Jak zauważył pan Strzembkowski, Allegro (Świstak również) w wielu miejscach nie rozróżnia danych przychodzących metodami GET i POST. Samo w sobie nie jest to luką, natomiast ułatwia ataki CSRF (niektóre z nich można dzięki temu wykonać bez użycia aktywnych skryptów w przeglądarce ofiary). O ile wysłanie spreparowanego żądania POST ze strony opisu aukcji jest praktycznie niemożliwe (dzięki skutecznemu filtrowi treści), o tyle żądanie GET jest banalne do uzyskania, na przykład przy pomocy znacznika img.
Większość istotnych formularzy broni się przed takim atakiem przy pomocy dodatkowych, nieprzewidywalnych dla atakującego parametrów. eBay zrobił to konsekwentnie, natomiast w Allegro atakujący nadal może na przykład wysłać w naszym imieniu email lub zalicytować w aukcji. Ponadto tego typu obrona jest nieskuteczna między innymi:
Tutaj również plus dla eBay, ponieważ najistotniejsze elementy są chronione mechanizmem CAPTCHA, z dużym prawdopodobieństwem eliminującym obie powyższe metody. Niezależnie od serwisu aukcyjnego, użytkownik może się dodatkowo bronić, zamykając wszystkie inne okna/zakładki przeglądarki przed zalogowaniem, wpisując adres serwisu ręcznie, oraz nie wchodząc wewnątrz serwisu na odnośniki prowadzące do zewnętrznych stron (na przykład w opisach aukcji).
Luki tego typu są tak powszechne, że nie dziwi specjalnie fakt, iż wszystkie trzy testowane platformy aukcyjne są podatne na XSS. W przypadku eBay skutki są mniej poważne ze względu na podział serwisu na wiele subdomen oraz wykorzystanie CAPTCHA do weryfikacji istotniejszych formularzy. W Allegro i Świstaku możliwe jest przy pomocy XSS na przykład wykradnięcie hasła następującymi metodami:
Druga z tych metod, tak jak większość ataków CSRF, jest możliwa do wykorzystania również bez żadnej luki XSS, jeżeli przeglądarka ofiary jest podatna na luki naruszające zasadę same-domain (obecnie znana i niezałatana luka tego typu, mhtml-redirect, dotyczy Internet Explorera w przypadku gdy w systemie obecne są biblioteki dll Outlook Expressa - czyli praktycznie we wszystkich Windowsach poza Vistą).
Ostatnią linią obrony przed atakami XSS i CSRF jest system powiadomień o istotnych wydarzeniach dotyczących konta użytkownika: rozpoczęciu aukcji, udziale w licytacji, zmianie ustawień itp. W Allegro ten system jest bardzo dobry, jednak eBay poszedł jeszcze dalej - poza powiadomieniem mailowym, tworzone są dodatkowo tzw. alerty, widoczne w serwisie i nieusuwalne przez pewien czas, informujące o najistotniejszych zdarzeniach. Nawet jeśli użytkownik padnie ofiarą ataku CSRF, najprawdopodobniej dowie się o tym natychmiast, nawet jeśli nie sprawdza często skrzynki pocztowej.
Świstak po raz kolejny wypada w porównaniu najsłabiej - chociażby z powodu braku powiadomienia na stary adres e-mail przy jego zmianie.
Wspomniane przeze mnie problemy najprawdopodobniej nie dotkną zbyt wielu użytkowników serwisów aukcyjnych. Myślę jednak, że stopniowo coraz większy odsetek oszustw na aukcjach będzie wykorzystywać technologiczne możliwości wprowadzenia w błąd lub zwyczajnej kradzieży. Ponadto takie luki mogą być wykorzystywane nie tylko w celu uzyskania konkretnych korzyści finansowych, lecz czasem po to, by zaszkodzić serwisowi i obniżyć jego wiarygodność.
W tym krótkim zestawieniu widać, że eBay przyłożył największą wagę do jakości zabezpieczeń. Miał on największe ku temu powody - wraz z ilością użytkowników rośnie stopień zagrożenia, a polska odsłona serwisu jest przecież kopią platformy aukcyjnej znanej na całym świecie. Działania phisherów są co prawda powiązane zazwyczaj z jedną wersją językową, ale ataki XSS i CSRF działają w każdej tak samo. Można więc założyć, że “małe” Allegro, choć bardziej podatne na ataki, jest w praktyce niemal tak samo bezpieczne - przynajmniej jeszcze przez jakiś czas.
Luka “mhtml:” Redirection Information Disclosure znana jest od kwietnia tego roku. Dotyczy przeglądarki Internet Explorer w wersjach 6 i 7, ale spowodowana jest błędem jednej z bibliotek programu Outlook Express, wykorzystywanej przez IE. Nie jest znany planowany termin wypuszczenia przez Microsoft łatki.
Użytkownicy Internet Explorera mogą się przed nią teoretycznie bronić odinstalowując Outlook Express (jest to dość skomplikowane zadanie).
Możliwe jest również zabezpieczenie danego serwisu po stronie serwera. Jak wynika z moich testów, zwykłe usunięcie wszystkich pustych linii z kodu HTML strony uodparnia ją na ataki z wykorzystaniem mhtml-redirect. Kanatoko na forum sla.ckers.org zaproponował inne rozwiązanie - wstawienie na początek kodu strony następującego fragmentu:
<!-- Content-type: multipart/related; boundary="==stopmhtml"; type="text/html" --==stopmhtml -->
Proste przykłady można znaleźć pod adresami:
Podatność powyższych stron testowych na mhtml-redirect można sprawdzić na przykład przy pomocy tej demonstracji.
Polecam wszystkim, którzy przespali ostatni rok nowości w tematyce bezpieczeństwa WWW:
Jeremiah Grossman: Top 10 Web Hacks of 2006
Komentarze RSnake’a z ha.ckers.org
