Google, DNS i XSS – historia ciekawego bug huntingu

Na blogu jednego z bug hunterów pojawił się bardzo ciekawy wpis o błędzie znalezionym w Google w październiku zeszłego roku. Czy błąd w usłudze DNS może doprowadzić do XSS-a? Okazuje się, że tak.

Zacznijmy od samych nazw DNS. Zgodnie ze standardem, nazwa hosta nie może być całkowicie dowolna; nie może się zaczynać ani kończyć znakiem myślnika. Zatem takie nazwy domen jak www-.google.com, -www.google.com, czy www2-.drive.google.com nie są poprawne w myśl standardu. Pomimo tego, okazuje się, że implementacja protokołów sieciowych m.in. w Windowsie rozwiązuje nazwy DNS tego typu i nie są one w żaden sposób blokowane.

Za w00tsec

Bernardo Rodrigues, autor wspomnianego posta, pisze na swoim blogu, że to samo działa też na Linuksach, ale u mnie to się nie udało. Błąd został znaleziony pół roku temu, być może w międzyczasie został załatany w stosie sieciowym Linuksa?

Oczywiście, aby sprawdzanie tych myślników miało w ogóle sens, należy znaleźć domenę z rekordem wildcard. Bernardo znalazł kilka tego typu subdomen w ramach domeny google.com, m.in. drive.google.com (spróbujcie np. rozwiązać nazwę domeny sekurak.drive.google.com).

Okazało się, że googlowy serwer DNS zachowuje się dość specyficznie w zależności od tego, ile myślników zostanie dodanych na końcu poszczególnych części składowych nazwy hosta.

Kluczowe jest ostatnie sprawdzenie ze zrzutu ekranowego wyżej. Otóż nazwa domeny vpn.bmaia.com——.drive.google.com  (która bez dwóch zdań jest subdomeną google.com) zostaje rozwiązana jako alias do vpn.bmaia.com. Innymi słowy, serwer DNS usuwa sześć kolejnych myślników i zupełnie ignoruje nazwę domeny, sprawiając, że ruch z vpn.bmaia.com——.drive.google.com jest przekierowany na domenę kontrolowaną przez atakującego. Można było więc w ten sposób pozyskać zawartość ciasteczek http bądź też przeprowadzić atak phishingowy.

W praktyce atak mógłby więc wyglądać następująco:

•  Użytkownik klika w hiperłącze prowadzące do domena.atakujacego.pl——.drive.google.com.

•  Przeglądarka rozwiązuje nazwę domeny jako alias do domena.atakujacego.pl, załóżmy adres IP 1.2.3.4.

• Przeglądarka nawiązuje połączenie z adresem 1.2.3.4, zachowując jednak nazwę domeny domena.atakujacego.pl——.drive.google.com. W efekcie pod IP 1.2.3.4 wysyłane są ciasteczka powiązane z domenami .google.com – atakujący może je przeczytać na swoim webserwerze.

Po więcej informacji, w tym jak udało się wykorzystać owe myślniki w atakach na Facebooka oraz o problemach ze Strict Transport Security, odsyłam do oryginalnego posta: http://w00tsec.blogspot.com/2014/03/wilcard-dns-content-poisoning-xss-and.html.

—Michał Bentkowski