Schemat wycieku danych przez Web Proxy Auto-Discovery (WPAD) w przypadku kolizji nazw (w tym przypadku kolizji wewnętrznej domeny z nazwą jednej z nowych gTLD, ale istota pozostaje ta sama). Źródło: , 2016
Mike O’Connor, jeden z najstarszych inwestorów w domeny, najbardziej niebezpieczny i kontrowersyjny element swojej kolekcji: domenę corp.com za 1,7 mln USD. W 1994 roku O’Connor kupił wiele prostych nazw domen, takich jak grill.com, place.com, pub.com i inne. Wśród nich była też corp.com, którą Mike przechowywał przez 26 lat. Inwestor ma już 70 lat i postanowił zmonetyzować swoje długoterminowe inwestycje.
Cały problem polega na tym, że corp.com — potencjalnie niebezpieczny przynajmniej dla 375 000 korporacyjnych komputerów z powodu niechlujnej konfiguracji Active Directory w czasach budowy korporacyjnych intranetów na początku lat 2000 na bazie Windows Server 2000, kiedy wewnętrzny rdzeń wskazywano po prostu jako „corp”. Do początku lat 2010-tych nie było z tym problemu, ale wraz z rosnącą liczbą laptopów w środowisku biznesowym, coraz więcej pracowników zaczęło wynosić swoje służbowe komputery poza sieć korporacyjną. Cechy implementacji Active Directory sprawiają, że nawet bez bezpośredniego żądania użytkownika do \/\/corp, wiele aplikacji (np. poczta) samoistnie łączy się ze znajomym adresem. Lecz w przypadku zewnętrznego połączenia z siecią w umownej kawiarni za rogiem prowadzi to do tego, że strumień danych i żądań spływa na corp.com.
Obecnie O’Connor ma nadzieję, że domenę kupi sama Microsoft i w najlepszych tradycjach Google schowa ją gdzieś w ciemnym, niedostępnym dla postronnych miejscu, a problem z tak fundamentalną podatnością sieci Windows zostanie rozwiązany.
Active Directory i kolizja nazw
W korporacyjnych sieciach działających na systemie Windows wykorzystywana jest usługa katalogowa Active Directory. Pozwala ona administratorom korzystać z polityk grupowych do zapewnienia jednolitości konfiguracji środowiska roboczego użytkowników, wdrażać oprogramowanie na wielu komputerach poprzez polityki grupowe, realizować uwierzytelnianie itd.
Usługa Active Directory jest zintegrowana z DNS i działa na protokole TCP\/IP. Do lokalizowania węzłów w sieci wykorzystywany jest protokół automatycznego wykrywania proxy Web Proxy Auto-Discovery (WAPD) oraz funkcja (wbudowana w Windows DNS Client). Ta funkcja ułatwia wyszukiwanie innych komputerów lub serwerów bez potrzeby podawania pełnej nazwy domeny.
Na przykład, jeśli firma zarządza wewnętrzną siecią o nazwie internalnetwork.example.com, a pracownik chce uzyskać dostęp do wspólnego dysku o nazwie drive1, nie ma potrzeby wpisywania drive1.internalnetwork.example.com w Eksploratorze, wystarczy wpisać \drive1 — a klient Windows DNS sam uzupełni nazwę.
W wcześniejszych wersjach Active Directory — na przykład w Windows 2000 Server — jako domyślna wartość dla drugiego poziomu domeny korporacyjnej ustawiono corp. I wiele firm zachowało domyślną wartość dla swojej wewnętrznej domeny. Co gorsza, wiele zaczęło budować rozległe sieci na bazie tego błędnego ustawienia.
W czasach komputerów stacjonarnych nie stanowiło to większego problemu z bezpieczeństwem, ponieważ nikt nie wyciągał tych komputerów poza sieć korporacyjną. Ale co się dzieje, gdy pracownik, który pracuje w firmie z ścieżką sieciową corp w usłudze Active Directory zabiera firmowego laptopa — i wchodzi do lokalnego Starbucks? Wtedy wchodzi w życie protokół automatycznej konfiguracji proxy Web Proxy Auto-Discovery (WPAD) oraz funkcja dewolucji nazw DNS.
Istnieje duże prawdopodobieństwo, że niektóre usługi na laptopie będą nadal próbować łączyć się z wewnętrzną domeną, corpale jej nie znajdą, a zamiast tego zapytania będą rozwiązywane do domeny corp.com z otwartego internetu.
W praktyce oznacza to, że właściciel corp.com może pasywnie przechwytywać prywatne zapytania z setek tysięcy komputerów, które przypadkowo wyszły poza korporacyjne środowisko, używając oznaczenia corp dla swojej domeny w Active Directory.
Wycieki zapytań WPAD w amerykańskim ruchu. Z badania Uniwersytetu Michigan w 2016 roku,
Dlaczego domena jeszcze nie została sprzedana
W 2014 roku specjaliści ICANN opublikowali kolizji nazw w DNS. Badanie częściowo sfinansowane przez Ministerstwo Bezpieczeństwa Krajowego USA, ponieważ wycieki informacji z sieci wewnętrznych zagrażają nie tylko firmom komercyjnym, ale także organizacjom rządowym, w tym służbom wywiadu, agencjom wywiadowczym i jednostkom wojskowym.
Mike chciał sprzedać corp.com już w zeszłym roku, ale badacz Jeff Schmidt przekonał go, aby wstrzymał sprzedaż na podstawie wspomnianego wcześniej raportu. W ramach badania ustalono również, że każdego dnia 375 000 komputerów próbuje nawiązać kontakt z corp.com bez wiedzy właścicieli. W zapytaniach znajdowały się próby dostępu do korporacyjnych intranetów, sieci lub zasobów plikowych.
W ramach własnego eksperymentu Schmidt wspólnie z JAS Global zasymulował na corp.com sposób przetwarzania plików i zapytań, który wykorzystuje lokalna sieć Windows. W ten sposób otworzyli właściwie portal do piekła dla każdego specjalisty ds. bezpieczeństwa informacji:
To było straszne. Zatrzymaliśmy eksperyment po 15 minutach i zniszczyliśmy [wszystkie zebrane] dane. Dobrze znany tester, który doradzał JAS w tej kwestii, zauważył, że eksperyment przypominał "deszcz poufnych informacji" i że nigdy nie widział nic podobnego.
[Ustawiliśmy odbiór poczty na corp.com] i mniej więcej po godzinie otrzymaliśmy ponad 12 milionów wiadomości e-mail, po czym zakończyliśmy eksperyment. Chociaż przytłaczająca większość wiadomości była automatyzowana, odkryliśmy, że niektóre z nich były wrażliwe [z punktu widzenia bezpieczeństwa], w związku z czym zniszczyliśmy cały zbiór danych bez dalszej analizy.
Schmidt uważa, że administratorzy na całym świecie przez dziesięciolecia, nie zdając sobie z tego sprawy, przygotowywali najniebezpieczniejszy botnet w historii. Setki tysięcy pełnowartościowych komputerów na całym świecie są gotowe nie tylko stać się częścią botnetu, ale także dostarczyć poufne dane dotyczące swoich właścicieli i firm. Wszystko, co jest potrzebne, aby z tego skorzystać, to kontrolować corp.com. Przy tym częścią botnetu staje się każda maszyna, która kiedykolwiek została podłączona do korporacyjnej sieci, której Active Directory było skonfigurowane przez //corp.
Microsoft "zignorował" problem już 25 lat temu
Jeśli myślisz, że MS nie miał pojęcia o tej całej chaotycznej sytuacji wokół corp.com, to poważnie się mylisz. z taką stroną, na którą trafiali użytkownicy beta wersji FrontPage '97, w której corp.com był podany jako domyślny URL:
Gdy Mike miał tego już serdecznie dość, corp.com zaczął przekierowywać użytkowników na stronę sex-shopu. W odpowiedzi otrzymał tysiące wściekłych wiadomości od użytkowników, których przekierował przez kopię na Billa Gatesa.
Tak przy okazji, Mike również sam, z ciekawości, postawił serwer pocztowy i odbierał poufne wiadomości na corp.com. Próbował rozwiązać te problemy, kontaktując się z firmami, ale one po prostu nie wiedziały, jak to naprawić:
Natychmiast zacząłem otrzymywać poufne e-maile, w tym wstępne wersje raportów finansowych korporacji do Komisji Papierów Wartościowych i Giełd USA, raporty dotyczące zasobów ludzkich i inne przerażające rzeczy. Przez jakiś czas próbowałem korespondować z korporacjami, ale większość z nich nie wiedziała, co z tym zrobić. Ostatecznie po prostu wyłączyłem swój [serwer pocztowy].
Z strony MS aktywne działania nie zostały podjęte, a firma odmawia komentarzy w tej sprawie. Tak, Microsoft przez te lata wydawał kilka aktualizacji Active Directory, które częściowo rozwiązują problem kolizji nazw domen, jednak mają one swoje problemy. Firma wypuściła również zaleceń instrukcje dotyczące konfigurowania wewnętrznych nazw domen, zalecenia dotyczące posiadania domeny drugiego poziomu w celu uniknięcia kolizji i inne samouczki, które zazwyczaj nie są czytane.
Jednak najważniejsze kryje się w aktualizacjach. Po pierwsze: aby je zastosować, trzeba całkowicie wyłączyć intranet firmy. Po drugie: niektóre aplikacje po takich aktualizacjach mogą zacząć działać wolniej, niepoprawnie, lub mogą całkowicie przestać działać. Oczywiste jest, że większość firm z dobrze zorganizowaną siecią korporacyjną na krótką metę nie zdecyduje się na takie ryzyko. Ponadto wiele z nich nawet nie zdaje sobie sprawy z całego zakresu zagrożenia, jakie wiąże się z przekierowaniem wszystkiego na corp.com, gdy urządzenie zostanie wyjęte poza wewnętrzną sieć.
Maximum ironii osiąga się, gdy przeglądasz . Tak, według jego danych, niektóre zapytania do corp.com pochodzą z intranetu samego Microsoftu.
A co będzie dalej?
Wydawałoby się, że rozwiązanie tej sytuacji leży na powierzchni i zostało opisane już na początku artykułu: niech Microsoft wykupi od Mike'a jego domenę i zabroni gdziekolwiek w odosobnionym kącie na zawsze.
Ale nie wszystko jest takie proste. Microsoft oferował O'Connorowi wykupienie jego toksycznej domeny dla firm na całym świecie już kilka lat temu. Tylko, że gigant zaoferował zaledwie 20 tys. dolarów za zamknięcie takiej luki w swoich sieciach.
Teraz domena wystawiona jest za 1,7 mln dolarów. A nawet jeśli Microsoft w ostatniej chwili zdecyduje się ją wykupić — czy zdąży?
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
A co byście zrobili na miejscu O'Connora?
59,6%Niech Microsoft kupi domenę za 1,7 mln dolarów, albo niech kupi ją ktoś inny.501
3,4%Sprzedałbym ją za 20 tysięcy, nie chcę wejść do historii jako człowiek, który sprzedał taką domenę nie wiadomo komu.29
3,3%Pogrzebałbym ją sam i na zawsze, jeśli Microsoft nie może podjąć właściwej decyzji.28
21,2%Specjalnie sprzedałbym domenę hakerom z warunkiem, że zniszczą reputację Microsoftu w środowisku korporacyjnym. Wiedzieli o problemie od 1997 roku!178
12,4%Zbudowałbym botnet + serwer pocztowy sam i zacząłbym wpływać na losy świata.104
Zagłosowało 840 użytkowników. 131 użytkownik wstrzymał się od głosu.
Źródło: habr.com
