[a.....r]

#programowanie #zagadkihakerskie #ssl

Ostatnio wrzucałem zagadki hakerskie, które polegały na wykorzystaniu błędów w implementacji strony. Tym razem skupimy się na pewnym problemie (w sumie dość powszechnym) od strony koncepcyjnej.

Mamy stronę, która działa zarówno w protokole HTTP jak i HTTPS. HTTPS jest postawiony na stronie tylko do realizacji procesu logowania, cała reszta jest wysyłana przez HTTP.

Na stronie głównej (tej w HTTP), w prawym górnym rogu znajduje się formularz do logowania wyglądający mniej więcej tak:

Jak widać, formularz odnosi się do strony logowania po HTTPS. Wszystko wygląda więc w porządku:

1. Użytkownik wchodzi na stronę w HTTP.

2. Wpisuje swoje dane do formularza logowania.

3. Dane logowania są przesyłane przez HTTPS (a więc nie ma możliwości by je podsłuchać w sieci).

4. Serwer zweryfikował poprawność danych, ustawia ciastka i przekierowuje użytkownika z powrotem do HTTP.

No... więc wszystko niby wygląda w porządku ale nie byłoby tej zagadki, gdyby faktycznie wszystko było ok :) Jaki jest problem w takim rozwiązaniu? W jaki sposób można tutaj przeprowadzić atak?

Albo sformułuję problem inaczej, żeby był bardziej obrazowy: dlaczego nie powinniście się logować na Wykop z niezaufanej sieci Wifi? ;)

Od razu powiem, że nie chodzi tutaj o keyloggery czy jakieś inne złośliwe oprogramowanie. Komputer ofiary nie jest niczym zainfekowany.

[MichaS_LwK]

@almafater: Taka mała prośba , mógłbyś przy okazji swoich zagadek wrzucać małą ciekawostkę jak się bronić ?

[J.....w]

XSS i zmiana atrybutu action w formularzu?

[a.....r]

@MichaS_LwK: Hmm, racja, trochę mi to umknęło. Dorzucę późniejszym wieczorem do moich postów jeszcze jeden komentarz, z krótką informacją na ten temat w każdym z nich. Zawołam jak będzie zrobione :)

[a.....r]

@Jon_Shannow: Tak, to mógłby być pomysł pod warunkiem, że istniałaby na stronie taka podatność.

A co byłoby gdyby na stronie nie dało się zrobić XSS?

[MichaS_LwK]

@almafater: Dziękuje.

[J.....w]

@almafater: problem polega na tym, że można logować się z formularza na innej domenie?

[Wozyack]

@almafater: Może po prostu chodzi o to, że lecą hasło i użytkownik w formie zaszyfrowanej i łatwo te zaszyfrowane dane wyciągnąć z całego dokumentu, a potem przeprowadzić np. brute force? W sensie że kiedy cała strona leci po SSLu, wszystko jest zaszyfrowane i nie wiadomo, co jest czym. A tutaj wiadomo, który ciąg znaków to zaszyfrowane hasło, a które to zaszyfrowany użytkownik.

[staa]

@almafater: mylę się, czy wystarczy przechwycić całe zapytanie (to co wysyła formularz) i wysłać je ponownie w późniejszym czasie logując siebie? Jeśli w ogóle da się zrozumieć co napisałem

[Wozyack]

@almafater: Kontynuując - bo te zaszyfrowane dane lecą jako zmienne o konkretnych nazwach z tabeli asocjacyjnej POST.

[a.....r]

@Jon_Shannow: generalnie problem polega na tym jak rozwiązano kwestię trzymania strony zarówno na HTTP i HTTPS.

@Wozyack: Zaszyfrowanych danych nie wyciągniesz z dokumentu, bo nie masz jak :)

@staa: Nie jestem do końca pewien, o którym zapytaniu mówisz, więc wolałbym większą precyzję.

Mała podpowiedź:

[AltumVidetur]

Skoro całe połączenie nie jest zaszyfrowane to pierwszy request do strony głównej zawierającej formularz logowania można zmodyfikować w złośliwej sieci. Np atakujący stawia proxy które podmienia wszystkie action we wszystkich przesyłanych dokumentach na http://zly-serwer/zbierakdanych.php i wymusza cały ruch http w sieci przez nie.

[J.....w]

@almafater: przeglądarka nie prześle chyba tego zakodowanego bo nie dostała od serwera klucza - aktualny url leci przez https

[AltumVidetur]

@almafater: I jeszcze rozwiązanie nr 2 - można po prostu buchnąć ciastko.

[a.....r]

@AltumVidetur: Tak, właśnie o to chodzi.

Wyjaśnienie:

Pierwsze żądanie idzie w HTTP, ale zawiera formularz z odniesieniem do HTTPS. Ponieważ jednak jest w HTTP - złośliwy użytkownik może w nim podmienić atrybut

action

na taki, który nie będzie zawierał odniesienia do HTTPS tylko HTTP.

Istnieją gotowe skrypty, które coś takiego robią, jak np. sslstrip - on zamienia "https" na "http", dodatkowo może zmienić favikonę na taką samą, tylko zawierającą w sobie

[K.....a]

@almafater: dlaczego zgasiłeś Jon_Shannow ? Dobrze powiedział - wstrzyknięcie w sieci kodu XSS. Żaden problem z metasploitem.

[a.....r]

@Klopsztanga: Poprzez XSS rozumie się atak polegający na wstrzyknięciu skryptu wykorzystując niewłaściwe filtrowanie danych na stronie. Zrobienie czegoś takiego poprzez sieć to już zwykły man-in-the-middle.