Zatruwanie pliku hosts
Ostatnio, gdy “triumfy” święci phishing pojawiło się kilka technik, jakie mogą pomóc złodziejom w kradzieży danych dostępowych do kont internetowych. Jedną z nich jest atak na serwery DNS bądź na pliki hosts. Serwery DNS zamieniają komputerom adresy URL na numery IP serwerów. Więc teoretycznie gdyby się włamano na serwery na przykład Telekomunikacji Polskiej, zatruwając je, to każdy klient Neostrady zamiast adresu swojego banku dostawałby to, co złodzieje by zechcieli. Na przykład postawioną stronę rejestrującą hasła. Ale przeglądarka internetowa wyświetlałaby w pasku adresu jak najbardziej prawidłowy URL.
Jednak oczywiście atak na infrastrukturę sieciową nie jest tak prosty, jak na źle zabezpieczone kompuetry użytkowników. A trzeba wiedzieć, że praktycznie każdy system operacyjny dysponuje specjalnym plikiem, który spełnia rolę lokalnego “serwera” DNS. Tak zwany plik hosts, umieszczony w katalogach /etc/hosts (w Linuksie) czy %SYSTEMROOT%system32driversetchosts (w Windows) jest małym plikiem tekstowym, w którym znajdują się po dwie rzeczy - adres IP serwera oraz adres domenowy serwera - w każdej linijce. Ma różne zastosowania, ja na przykład wykorzystuję go do tego, by adres lucy.local prowadził do komputera w mojej sieci domowej o adresie 192.168.0.4.
Jednak, można go wykorzystać do zaatakowania konta bankowego użytkownika. Należy się zabezpieczyć. Użytkownicy Linuksa mogą już przestać czytać, bo ich ten problem w większości nie dotyczy. Jedna sprawa z powodu takiego, że wirusów na Linuksy to się raczej nie spotyka, po drugie - bo i tak zapisać do tego pliku cokolwiek może tylko root. A nikt zwykle pod rootem nie pracuje.
Właśnie - zapis. Atak na plik hosts może się powieść tylko w przypadku, gdy użytkownik ma prawa zapisu do tego pliku. A zatem jeżeli używa Windows z obsługą praw zapisu na partycji NTFS - na przykład najpopularniejszego Windows XP, to zapisać do tego pliku domyślnie może cokolwiek tylko Administrator bądź konto o takich uprawnieniach. I dochodzimy do faktu, że wiele osób na koncie administracyjnym pracuje normalnie. Z wygody, niewiedzy, czy czego tam jeszcze. Zalecam się przesiąść na konto o ograniczonych uprawnieniach - żaden wirus nie zapisze się nam w katalogu Windows bo nie będzie mógł. W pliku hosts też nie nabrudzi, bo zwykli użytkownicy mają tylko prawa “Odczyt”, “Odczyt i wykonanie” (w polskiej wersji systemu jest “Zapis i wykonanie” ale to błąd w tłumaczeniu). A “Zapis” czy “Modyfikacja” - nie.
Sprawa wygląda znacznie gorzej na sytemach Windows 98 czy ME. Oraz gdy stosuje się w tych nowszych system plików FAT, a nie NTFS. Jedyne co można zrobić to ustawić plikowi hosts atrybut “Tylko do odczytu”. Rozwiązanie banalne, ale większość wirusów atakujących go powinno się na nie nabrać. Gorzej jeśli ich autorzy czytają ten artykuł :-)
Jest jeszcze jedna zasada. Podejrzliwość. Nawet jak adres banku jest prawidłowy niby to raczej o kilka naszych haseł jednorazowych nikt nie zapyta. Ani e-mailem o nie nie poprosi. Musimy być czujni.
Technorati Tags: phishing, hosts, security, DNS, cache poisoning, Windows, administrative account
Liczba komentarzy: 12
»Wątek RSS dla komentarzy tego wpisu · Adres trackback
wrzesień 3, 2006 godzina 15:45
Twój bank nie używa SSL?
wrzesień 3, 2006 godzina 17:03
A jak ja proponowałem komuś, to zostałem poinformowany, że nadmiernie komplikuje jemu życie. Zresztą Nero wymagał praw administratora i nic nie chciało pomóc.
Co do SSL, to część wirusów pyta się, czy się zainstalować. Ludzie mechanicznie klikają tak. Zresztą, ile % populacji zwróci uwagę, czy kłudka jest otwarta, czy zamknieta i czy jest literka s, czy nie (i ile wie co to jest)? Nie będzie to szło z podmienionym serwerem przez SSL i spokoj ;)
W FF (nie wiem jak w innych alternatywnych) mamy większą różnice - żółty pasek adresu, ale nadal nie sądze, żeby dużo osób zwróciło na to uwagę.
wrzesień 3, 2006 godzina 17:12
Użytkownik: Nero? Use NeroBurnRights i można nadawać użytkownikom prawa do nagrywarki. Używam konta ograniczonego od blisko dwóch lat i dzięki na szybko stworzonemu skryptowi który uruchamia cmd.exe z prawami administratora (i dzięki znajomości poleceń konsoli) pulpitu konta administatora nie widziałem od dawna.
Patrys: Mój akurat używa. Ale obawiam się że większość użytkowników na kłódkę i szczegóły certyfikatu uwagi nie zwraca, mimo iż stale się o tym przypomina. A atak na plik hosts powoduje atak na ten pasek adresu, na który jednak zaczęto zwracać uwagę.
wrzesień 3, 2006 godzina 18:47
Spotkałem się z programami antywirusowymi/antyspyware, które czyściły plik hosts. Więc ten problem jednak jest zauważany przez twórców (i wirusów i wszelkich lekarstw).
wrzesień 3, 2006 godzina 20:49
@Patrys - “bank” podstawiony przez phisherów też może używać SSL. A to, że użytkownik dostanie komunikat o tym, że certyfikat nie jest podpisany (albo nie dostanie, bo ustawił sobie, by przeglądarka to ignorowała), najczęściej nie wywoła odpowiedniej reakcji.
@Olorin: No to pogratulować twórcom tego antywirusa. Wszak wiele osób (no dobra, może nie tak wiele, ale dość sporo) używa pliku hosts do swoich potrzeb i jego nagłe opróżnienie nie wyjdzie takim osobom na dobre. Chyba, że opatrznie zrozumiałem słowo “czyścić”.
@Ktos: E… Jacy znowu użytkownicy Neostrady? Od kiedy to użytkownik ma narzucone, z jakich serwerów DNS ma korzystać? Ja używam jedynego słusznego 192.168.1.111 :P. A ten z kolei bynajmniej nie uważa DNSów TPSA za najważniejsze, używa je tylko wtedy, gdy pozostałe na liście leżą :).
P.S. A użytkownikiem Neozdrady jestem. Niestety.
wrzesień 3, 2006 godzina 22:34
Podpowiadają mi, że mając dostęp do komputera, można oprócz pliku hosts, zmienić ustawienia przeglądarki (konkretnie, proxy - na własne).
wrzesień 4, 2006 godzina 05:49
parę przydatnych narzędzi do zarządzania plikiem HOSTS - http://www.searchengines.pl/phpbb203/index.php?showtopic=11529
wrzesień 4, 2006 godzina 07:01
Tak, ten świetny program wyczyścił mi hosts, którego używam ;) Dobrze zrozumiałeś. Co do użytkowania Neostrady to ja polecam DNS 127.0.0.1 ;)
wrzesień 4, 2006 godzina 17:17
Krótko:
Jak jakikolwiek wirus ma dostęp do uprawnień admina, to może ci podmienić bibliotekę odpowiedzialną za resolvowanie nazw.
Użytkowników linuxa problem zapisu do pliku hosts również dotyczy.
Całym problemem jest jak zwykle nie technologia, tylko człowiek, któremu się nie chce myśleć.
wrzesień 4, 2006 godzina 20:49
@olorin: 127.0.0.1 nie jest taki idealny. Wszak jak ma się sieć domową, to jest aktualny tylko dla komputera, przy którym siedzisz. A jakiekolwiek zmiany ustawień są tylko na nim zauważalne. A ja korzystam z serwera stojącego dwie ściany dalej (dwa pokoje dalej, w moim mieszkaniu :) ), który jest użyteczny dla całej sieci domowej, dzięki czemu jak wpiszę na przykład cvs.smok.cicha.lublin.pl, to niezależnie, czy wpiszę to na swoim Smoku, czy na którymś innym gadzie, będzie działało :).
@carstein: Oczywiście, że problem dotyczy użytkowników Linuksa w takim samym stopniu, jak użytkowników Windowsa. Problemem po stronie Windowsa jest to, że duży ich odsetek (duuuużo większy, niż po stronie Linuksa, jak i innych *niksów) korzysta przy normalnej pracy z kont o uprawnieniach administratora.
wrzesień 16, 2006 godzina 04:00
->carstein: uzytkownicy, ktorym sie nie chce myslec, to po prostu normalni uzytkownicy. Obracanie sie li tylko w srodowisku geekow prowadzi do wypaczen;) Zadaniem specow od bezpieczenstwa i programistow jest dostarczenie bezpiecznego srodowiska, ktore wymaga jak najmniejszej ingerencji zwyklego uzytkownika (co to z definicji nie mysli).
No i po tej samej stronie barykady jestesmy jeszcze my, admini :(
wrzesień 23, 2006 godzina 02:24
@zen: Ale przecież tylko Macintoshe spełniają tą rolę: “Wszystko działa, ale nie pytaj jak”. Każdy system, w którym użytkownik ma prawa administratora jest niebezpieczny. Problemem Windowsów do M$ WinXP jest to, że domyślny użytkownik jest administratorem. Zaletą *nixów jest to, że domyślny użytkownik nim nie jest.
Tak zwani “my, admini” to grupa, która pod każdym systemem może temu problemowi w banalny sposób zapobiec - zabrać użytkownikom - i sobie podczas zwykłej pracy też! - uprawnienia administratora. Ktoś, kto pracuje na koncie, które może wszystko, musi się liczyć z tym, że jak coś odpali (nieraz jakąś aplikację nieznanego pochodzenia albo coś), to to, co odpali, też może wszystko. Dlatego też pracuję pod każdym systemem na koncie, które ma spore uprawnienia (windowsowy “użytkownik ograniczony” utrudnia robienie czegokolwiek), ale nie może grzebać w systemie. Jak chcę jakąś akcję wykonać z uprawnieniami admina, to jedno polecenie i mogę śmigać. Ale w konsoli su (”runas /user:Administrator cmd”) biorę pod uwagę konsekwencje poleceń, które wykonuję.