Od wczoraj po serwisach informacyjnych krążą informacje o wysłanym w imieniu posłanki Beaty Kempy liście elektronicznym do Polskiej Agencji Prasowej, zawiadamiającym o rezygnacji pani poseł z udziału w kampanii wyborczej. Posłanka Kempa (słusznie) zgłosiła sprawę podszycia się na prokuraturze, obwiniając jednocześnie (niekoniecznie słusznie) i oskarżając o zaniedbania administratorów serwisów sejmowych. Odkładając na bok kwestie tego, czy zatrudnianie administratora serwera pocztowego jest decyzją podejmowaną przez konkretne ugrupowanie polityczne, warto zauważyć, że w dyskusjach pomijany jest zwykle jeden bardzo ważny aspekt. Poczta elektroniczna nie jest narzędziem zapewniającym jakiekolwiek mechanizmy służące weryfikacji tożsamości nadawcy. Tak została zaprojektowana i już. Wiarygodność adresu nadawcy jest mniej więcej taka sama jak wiarygodność napisanego długopisem adresu nadawcy na kopercie zwykłego listu – żadna. Żeby nie szukać przykładu daleko – w przypadku opisanego przez nas niedawno spamu nikt nie oskarżał nadawcy o włamanie na skrzynkę szefa HSBC.

Możliwości podszycia się pod kogoś innego w liście elektronicznym jest wiele. Poniżej przedstawiamy kilka możliwych scenariuszy. Podkreślmy jednak, że nie będąc w posiadaniu kopii kompletnego listu wraz z nagłówkami, nie jesteśmy w stanie spekulować na temat prawdopodobieństwa któregokolwiek z nich. Jednocześnie będziemy wdzięczni za kontakt, gdyby którykolwiek z czytelników był w posiadaniu takiej kopii.
(więcej…)

Przedwczoraj w sieci pojawił się exploit wykorzystujący błędy w DNS, o których pisaliśmy 9-tego lipca (Błędy w DNS dotyczące większości producentów).
Exploit pojawił się kilka dni po “wycieku” szczegółów błędów odkrytych przez Dana Kaminsky’ego. Większość producentów serwerów DNS udostępniła już poprawki (należy sprawdzić na stronie dostawcy). Dodatkowo (w miarę możliwości) warto ograniczyć dostęp do DNSu tylko do zaufanych klas adresów, wprowadzić zabezpieczenia przed spoofingiem na granicy sieci, oraz wyłączyć rekursywne odpowiedzi na pytania pochodzące z niezaufanych źródeł.

Jeżeli podjęcie powyższych kroków nie jest w tej chwili możliwe, administratorzy powinni co najmniej tymczasowo przekierować zapytania do DNSu, o którym wiadomo, że nie jest podatny (na przykład serwery OpenDNS).

Ostatnio w Internecie pojawiły się informacje o wykryciu bardzo groźnego błędu w DNS. W rzeczywistości są to pewne niedociągnięcia w protokole DNS, a także w popularnych jego implementacjach, które potencjalnie mogą zostać wykorzystane do ataku na serwery DNS. Atak ten może polegać na tzw. zatruwaniu pamięci serwera DNS (ang. DNS cache poisoning). W rezultacie serwer DNS odpytujący rekursywnie inny serwer DNS może zostać oszukany przez atakującego (który podszywa się pod serwer odpytywany), przez co klientowi zwracany jest fałszywy adres IP. Dzięki temu na przykład chcąc wejść na jakąś stronę internetową, zostaniemy skierowani na zupełnie inny serwer WWW. Może to być wykorzystywane np. do infekowania złośliwym oprogramowaniem ludzi surfujących po Internecie, lub wyłudzania od nich loginów i haseł do ich kont bankowych.

Pierwszym problemem jest sam protokół DNS, który wykorzystuje w komunikacji protokół UDP. Ponieważ taka komunikacja odbywa się bez połączenia, trudniej jest zweryfikować autentyczność serwera, z którego odbierane są dane (atakujący może się pod niego podszyć).

Ponadto, każde zapytanie zawiera potencjalnie unikalny losowo generowany 16-bitowy numer ID, który musi znaleźć się w odpowiedzi. Atakujący, chcąc podszyć się pod pytany serwer i sfałszować odpowiedź, musi zgadnąć ten numer. Niestety niektóre implementacje mogą używać słabych pod względem unikalności/losowości numerów ID, przez co atakujący może łatwiej i szybciej go zgadnąć.

Kolejnym problemem może być numer portu, z którego wysyłane jest zapytanie. Aby wymiana informacji przebiegła pomyślnie, odpowiedź musi zostać przesłana serwerowi zapytującemu na ten sam port, z którego wyszło zapytanie. Teoretycznie, serwer zapytujący ma do dyspozycji ponad 64 tysiące portów (porty o numerach powyżej 1024), lecz praktycznie rzadko zdarza się, aby serwery DNS wykorzystywały całą tę pulę za każdym zapytaniem zmieniając port źródłowy. Często do tego celu wykorzystywany jest tylko jeden port, który zmieniany jest w chwili restartu serwera, albo nawet w ogóle.

Zatem w najgorszym wypadku atak na serwer zapytujący („zatrucie” jego pamięci fałszywymi rekordami), sprowadza się tylko do odgadnięcia „na ślepo” ID transakcji. Przy założeniu, że zaatakowany serwer obsługuje dużą liczbę klientów (np. jest to serwer dużego dostawcy Internetu), zagrożenie może być poważne. Jednak nie zaobserwowano do tej pory takich ataków na skalę masową, mimo że podobne problemy pojawiają się od wielu lat. Choć teoretycznie konsekwencje udanych ataków tego typu mogą być niezwykle groźne dla użytkowników Internetu, wygląda jednak na to, że często nie jest łatwo wykorzystać powyższe błędy.

Producenci poszczególnych serwerów DNS już zajęli się opisanym problemem, wprowadzając losowe wykorzystywanie portów źródłowych. Większość najpoważniejszych dostawców udostępniło poprawki do swojego oprogramowania, inni są w trakcie ich opracowywania. Zainteresowani administratorzy serwerów DNS powinni dalszych informacji szukać na stronach producenta.

Info:

www.us-cert.gov,

isc.sans.org

Urządzenia sieciowe korzystające z protokołu UPnP narażone są na atak, który może zmienić ich ustawienia lub doprowadzić do przejęcia całkowitej kontroli przez atakującego.
UPnP (Universal Plug and Play) to w rzeczywistości zestaw protokołów pozwalający maksymalnie uprościć konfigurację i komunikację między różnymi urządzeniami.

W urządzeniach sieciowych, takich jak rutery, przesłanie spreparowanego polecenia UPnP może posłużyć do ich rekonfiguracji i zmiany ustawień. Jest to bardzo groźne, ponieważ możliwa jest np. zmiana hasła administratora, otwieranie portów lub podmiana adresów IP serwerów DNS, przez co użytkownik rutera może stać się ofiarą bardziej wyrafinowanego phishingu. Ponadto urządzenie wraz z lokalną siecią, której ruch kontroluje, może stać się częścią botnetu. Cyberprzestępcy mogą go także wykorzystać jako pośrednika (tzw. next hop) w komunikacji między nimi a celami dalszego ataku, przez co trudniej ustalić ich tożsamość.

Najbardziej niepokojący jest fakt, że polecenie może zostać dostarczone urządzeniu w stosunkowo łatwy sposób: może zostać wygenerowane poprze złośliwą animację Flash (plik o rozszerzeniu swf) zawartą na stronie WWW, a dokładnie przy pomocy poleceń Flash ActionScript. W tym przypadku wystarczy tylko, by nieświadomy użytkownik wszedł na taką stronę, a podczas wykonywania kodu animacji do urządzenia zostanie wysłany rozkaz UPnP.

Dodatkowo w większości urządzeń, które wspierają UPnP, funkcjonalność ta jest domyślnie włączona. O ile to możliwe i nie spowoduje destabilizacji sieci, zalecamy jej wyłączenie.

Atak tego typu posiada pewne ograniczenia, m.in. musi być znany atakującemu adres IP rutera (choć w większości przypadków można zgadnąć, że jest to adres z końcówką .1 lub .254).

Problem oczywiście dotyczy także innych urządzeń sieciowych wspierających UPnP, np. telefonów komórkowych czy drukarek. Na razie jednak wymagane jest, by urządzenie używało komunikacji UPnP po HTTP.

Źródła:
www.gnucitizen.org (opis problemu)
isc.sans.org
www.gnu citixen.org (FAQ)