Email, który zmieni DNSy w Twoim domowym ruterze

dodał 28 listopada 2012 o 16:02 w kategorii Błędy  z tagami:
Email, który zmieni DNSy w Twoim domowym ruterze

Kiedyś popularne były błędy w klientach poczty elektronicznej, umożliwiające wykonanie kodu poprzez samo przeczytanie nadesłanie wiadomości. Dzisiaj to rzadkość, niemniej przeczytanie emaila może w pewnych okolicznościach mieć nieciekawe skutki.

Ciekawą koncepcję wykorzystania wiadomości poczty elektronicznej do zdalnej zmiany konfiguracji serwerów DNS domowego rutera przedstawił Bogdan Calin z firmy Acunetix. Nie jest to ani nowy wektor ataku, ani rewolucyjne odkrycie, a jedynie kreatywne połączenie dwóch rodzajów problemów związanych z bezpieczeństwem – podatności domowych ruterów na błędy typu CSRF oraz niebezpiecznej domyślnej konfiguracji niektórych klientów poczty elektronicznej.

Bogdanowi udało się tak spreparować wiadomość, by jej otwarcie spowodowało zmianę konfiguracji serwerów DNS jego domowego rutera. Jak możecie się już pewnie domyśleć, nie było to trudne – przykład poniżej.

Przykład złośliwego emaila (źródło: Acunetix)

Kod, odpowiedzialny za modyfikacje ustawień rutera ma postać

<iframe width="0" height="0" src='http://admin:admin@192.168.1.1/start_apply.htm?wan_dns1_x=66.66.66.66&wan_dns_x=66.66.66.66">

Jak to działa?

Po pierwsze, nasz klient poczty musi domyślnie wczytywać zewnętrzne obiekty. Tak się składa, że na przykład domyślny klient poczty w urządzeniach firmy Apple jest tak skonfigurowany, by bez pytania użytkownika wczytać zewnętrzną zawartość. Pozycja w menu, która umożliwia edycję tej opcji, nazywa się „Load remote images”, ale jej wyłączenie blokuje nie tylko obrazki z innych serwerów, ale także zewnętrzne ramki. Kiedy jednak użytkownik nie zmienił domyślnej konfiguracji, otwarcie tego emaila w domowej sieci powoduje automatyczne wykonanie zapytania do serwera www pod adresem 192.1.68.1.1 – gdzie najczęściej znajduje się domowy ruter.

Po drugie, nasz ruter musi mieć ustawione domyślne (lub łatwe do odgadnięcia) hasło. Część użytkowników może być przekonana, że skoro interfejs rutera nie jest domyślnie dostępny z zewnątrz, to nie ma potrzeby ustawiać silnego hasła. Niestety, ten atak pokazuje, że to błędne założenie. Umieszczenie loginu i hasła w adresie URL pozwala automatycznie zalogować się do rutera i wysłać do niego odpowiednie żądanie. Oczywiście oprócz domyślnego hasła, można także dodać kilkadziesiąt innych kombinacji login:hasło w kolejnych ramkach, by zwiększyć prawdopodobieństwo trafienia.

Po trzecie, nasz ruter musi być podatny na atak typu cross-site request forgery. Oznacza to, że musi przyjmować i wykonywać żądania wysłane przez nieświadomego użytkownika z innej aplikacji lub strony. Niestety spora część obecnie używanych ruterów korzysta jedynie z prostego uwierzytelnienia użytkownika, umożliwiającego przesłanie loginu i hasła w odnośniku oraz przyjmuje polecenia przesłane za pomocą żądania GET. W opisywanym przykładzie podatne na tak okazały się rutery ASUS RT-N16 oraz ASUS RT-N56U, jedna całkiem prawdopodobne, że podobny atak można przeprowadzić także na inne modele innych producentów.

Poniżej demonstracja wideo przeprowadzanego ataku.



Jakie mogą być skutki takiego ataku?

W tym przykładzie podmieniono adresy serwerów DNS. Kilka tygodni temu opisywaliśmy podobny atak na domowe rutery, przeprowadzony na masową skalę w Brazylii. Gdy cały ruch DNS użytkownika zostanie przekazany na serwery znajdujące się pod kontrolą atakujących, wtedy mogą oni podmieniać użytkownikowi np. witryny banków czy serwisów społecznościowych na fałszywe i przejmować dane użytkownika. Przed tym zagrożeniem chronią nas na co dzień certyfikaty SSL, jednak część użytkowników nie zwraca uwagi na ostrzeżenia, wyświetlane przez przeglądarki.

Jak się zabezpieczyć?

Najprostszym zabezpieczeniem przed tego typu atakiem jest zmienienie domyślnego hasła rutera na coś znacznie bardziej skomplikowanego. Zabezpieczeniem, przynajmniej częściowym (bo dla stron przesyłanych przez HTTPS) są automatyczne ostrzeżenia o nieważności certyfikatu wbudowane w przeglądarki. Poza tym użytkownikom urządzeń Apple polecamy wyłączenie opcji „Load remote images”, które nie tylko uchroni przed opisanym powyżej atakiem, ale także podniesie poziom prywatności użytkownika.