Od wielu lat analizujemy wszelkie dostępne opisy ciekawych incydentów bezpieczeństwa i rzadko coś nas zaskakuje pomysłowością po stronie atakujących. Tak jest jednak tym razem – ich pomysł naprawdę jest ciekawy.
Firmy zajmujące się zawodowo bezpieczeństwem z zawodowego obowiązku musza być bardziej wyczulone na różnego rodzaju ataki – bo i na nie są częściej narażone. Nie wszyscy przyznają się do bycia ofiarami – czasem dowiadujemy się o tym z relacji włamywaczy (jak np. w przypadku Hacking Teamu), czasem poszkodowani stają na wysokości zadania, jak chociażby Kaspersky. Tym razem swoją historią postanowiła podzielić się firma Fox-IT, świadcząca wiele profesjonalnych usług z obszaru bezpieczeństwa – w tym także analiz powłamaniowych. Opis tego, co się im przydarzyło, jest ciekawą lekturą.
Mistrzowski MiTM
19 września 2017 tajemniczy atakujący przeprowadził bardzo sprytny atak na firmowy portal przeznaczony dla klientów Fox-IT. Atakującemu udało się przejąć kontrolę nad serwisem dla klientów firmy i to w taki sposób, że mógł podsłuchiwać hasła klientów i wykradać ich dokumenty – a to wszystko mimo dość rozwiniętego systemu firmowych zabezpieczeń. Wszystko zaczęło się od trzy dni wcześniej, kiedy to firma zaobserwowała serię skanów swojej infrastruktury. Nie uznała jednak tego wydarzenia za krytyczne – ot, kolejny dzień jak co dzień. Trzy dni później, krótko po północy, atakujący uzyskał dostęp do wpisów DNS głównej domeny Fox-IT.com, utrzymywanych przez firmę trzecią. Fox-IT przyznaje, że nie wie, w jaki sposób uzyskano dostęp do jego konta – hasło było skomplikowane, choć nie było zmieniane od roku 2013 a samo logowanie nie wymagało dwuskładnikowego uwierzytelnienia.
Atakujący zaczął od bardzo krótkiego przekierowania serwera obsługującego firmową pocztę elektroniczną. Ta faza ataku trwała zaledwie 10 minut, po których przywrócono oryginalne wpisy. W tym czasie jednak atakujący przechwycił korespondencję od firmy wystawiającej certyfikaty SSL, która pozwoliła mu podszyć się pod Fox-IT i uzyskać prawidłowy certyfikat dla jej portalu klienckiego. Kilka minut później portal dla klientów (clientportal.fox-it.com) został przejęty, także przez zmiany we wpisach serwera DNS, przekierowując ruch na zupełnie inny serwer. Maszyna przygotowana przez przestępców działała jako serwer proxy – wszystkie zapytania klientów podsłuchiwała i przesyłała do serwera właściwego. Atak zaczął się o 2:21, a o 7:25 został wykryty przez pracowników firmy. Prawidłowe rekordy DNS zostały przywrócone, jednak ze względu na ich propagację problem nie został natychmiastowo usunięty. By ograniczyć skalę naruszenia, o 12:25 firma wyłączyła mechanizmy dwuskładnikowego uwierzytelnienia klientów, by uniemożliwić im logowanie do serwisu przestępców.
Dzięki licznym sensorom w sieci firmowej i nagrywaniu sporych porcji ruchu Fox-IT mógł szybko określić skalę problemu. Przestępcy wykradli jedynie hasła kilku klientów (i na dokładkę bez dostępu do kodów jednorazowych nie mogli ich użyć). Weszli także w posiadanie trzech poufnych dokumentów, do których nie powinni mieć dostępu. Wykradli także nazwy uzytkowników portalu klienckiego oraz część ich adresów email.
Rekomendacje
Fox-IT podzielił się także swoimi wnioskami i zaleceniami po analizie incydentu. Obejmują one:
- Korzystanie z usług dostawcy DNS, który albo wymaga manualnego procesu zmiany wpisów (jeśli nie są te zmiany zbyt częste) abo obsługuje 2FA (jeśli zmiany są regularne)
- Monitoring logów certificate transparency by zauważyć, gdy komuś uda się uzyskać certyfikat do jednej z naszych domen
- Wymuszenie okresowej zmiany haseł systemowych (choć trudno tutaj wskazać dlaczego ma ona poprawić bezpieczeństwo i nie do końca się z tym zgadzamy)
- Prowadzenie pełnego nagrywania ruchu w kluczowych punktach infrastruktury (np. DMZ i punkty styku)
- Przygotowanie kierownictwa na podjęcie decyzji o świadomym utrzymywaniu zagrożonych systemów w trakcie ataku, by lepiej móc zrozumieć działanie atakujących (natychmiastowe wyłączenie systemów ogranicza straty, ale często uniemożliwia pełne zrozumienie skali ataku i sposobu działania napastników)
- Współprace z organami ścigania od samego początku incydentu (tu nasza uwaga – o ile organy są na taką współpracę gotowe)
Podsumowanie
Fox-IT należy pogratulować ujawnienia szczegółów incydentu i przyznania się do popełnionych błędów. Dzięki takim publikacjom cała branża może nauczyć się czegoś nowego. Pozostaje nam mieć nadzieję, że inne ofiary podobnych incydentów pójdą w ich ślady. Firmom, które martwią się o bezpieczeństwo swoich rekordów DNS, polecamy ten wpis omawiający możliwe rozwiązania poprawiające komfort snu obrońców.
Komentarze
Rzeczywiście część rekomendacji dziwna – „Prowadzenie pełnego nagrywania ruchu w kluczowych punktach infrastruktury (np. DMZ i punkty styku)”
Życzę powodzenia FOX-IT w nagrywaniu *pełnego* ruchu – np. w punkcie styku (LAN-u z Internetem). Chyba że na loterii wygrali jakieś ekstremalnie duże storage, albo logują bardzo ograniczony czas.
Michał pewnie chodziło o zapisywanie nagłówków bez payloada. A to juz jakiś ekstremalnie duży storage nie jest potrzebny na netflowa.
Full packet capture. Da się. Jak się chce to się wszystko da. Są firmy które nagrywają cały ruch np z miesięcznym buforem.
To ciekawe. Cały ruch? Dlaczego nie wystarczą same nagłówki (nie tylko mniej miejsca ale chyba i lepiej się kompresuje…)? I aż przez miesiąc?? Można prosić o więcej szczegółów, np. z jakiej branży to firmy?
Cały ruch bo inaczej nie dowiesz się co ukradziono, jakie wydawano polecenia itd. Branża finansowa.
Mnie to bardziej „śmieszy”, że już nikt nawet nie łudzi się, że (nawet pomimo takich technicznych rozwiązań) kogokolwiek złapią.
Takie uroki anonimowości i zarządzania zdalnego. Rabunki zdalne stały się wręcz komfortowo bezkarne w porównaniu do rabunków zwykłych.
A odnośnie samego ataku, to takie full logi ruchu sieciowego oraz własnych kluczy na miesiąc wstecz byłyby przydatne niemalże każdemu w dzisiejszym świecie jako analiza po incydencie. Niestety koszty i względy praktyczne wciąż to negują.
„Cały ruch bo inaczej nie dowiesz się co ukradziono, jakie wydawano polecenia itd. Branża finansowa.”
A co z ruchem szyfrowanym, którego, jak się spodziewam, musi być sporo? Jest robiony dump przesyłanych danych zanim nastąpi szyfrowanie TLS-em (keyloggery na komputerach służbowych? dodatek do przeglądarki?) czy jest on rozpruwany przez dołożenie dodatkowych certyfikatów?
Tak, jest MiTM na SSL
Jak światło dzienne ujrzał błąd Heartbleed, to pewien administrator był w stanie stwierdzić kiedy pierwszy raz wykorzystano na jego systemie ten atak, dzięki temu że logował cały ruch. I było to dużo wcześniej niż internet się o tym błędzie dowiedział.
Dać się da – w firmie 1 osobowej to można spróbować i przez rok nagrywać. W firmie 100 osobowej robi się gorzej a w firmie 100 000 osobowej to nieco słabiej.
To znaczy oczywiście wszystko jest kwestią kosztów i pytanie czy z analizy ryzyka wyszło, że trzeba nagrywać full capture. Właśnie z chęcią bym zobaczył ich analizę ryzyka z takim wnioskiem.
Czy ogólnie dawał bym wszystkim zewnętrznym firmom rekomendację nagrywania full capture i to w jeszcze w wielu miejscach? Raczej nie.
Tzn. można dać – na zasadzie pal licho koszty, bezpieczeństwo jest najważniejsze ;-) ale raczej chodzi żeby $ wydawać z głową i może ta sama kasa puszczona w inny obszar ITsec będzie sensowniej wydana.
Jako mały bonus mogę dodać wymagania RODO i prawo do zapomnienia – ktoś teraz będzie przeglądał bajt po bajcie te full kapczery (co jest do zautomatyzowania zapewne) i usuwał selektywnie moje dane z kapczerów jeśli taki request wyślę? :-)
Nie będzie kasował bo nazwiemy to kopią i nie będzie trzeba kasować z kopi. Problem będzie z analizą bo my sobie ie będziemy mogli (wtedy by trzeb usnąć te dane jeśli by uznać że to przywracanie kopi)
Za to o wiele trudniej będzie udowodnić że takie nagrywanie uchu będzie zasadne i nie wypełni znamion nadmiarowości. Szczególnie że zapewne dojdzie do ryzyka gromadzenia danych prywatnych co zupełnie rozwali system. Z tym że RODO kompletnie jest oderwane od realiów i będzie spory problem.
@Michał Sajdak,
1) co RODO na elementy FPC realizowane przez systemy bezpieczeństwa nagrywające pakiety dopasowane do sygnatur/reguł?
2) co RODO generalnie na zdarzenia bezpieczeństwa (logi w różnej postaci) mogące zawierać dane, o których w RODO mowa?
3) czy RODO nakaże je (1), 2)) usuwać i modyfikować zabezpieczone ślady, na Twój wniosek?
Dostęp do danych z 1), 2) oraz FPC powinien być rozliczalny, a także dodatkowo chroniony, co jest zazwyczaj poruszane przy systemach typu FPC oraz infrastruktury bezpieczeństwa organizacji. Podział ról (jedni zarządzaja, inni przeglądają), rejestracja dostępu, etc.
Czy uważasz, że RODO utrudni używanie FPC lub infrastruktury bezpieczeństwa opisanej powyżej?
Mówicie, że RODO przedstawi nową jakość ataków typu DDoS? :)
Michal, full packet capture to ostatnio normalna sprawa i mogę podać wiele przykładów z Pl gdzie jest zaimplementowany. Powodów jest kilka ale najważniejszy to potrzeba narzędzia do IR. FPC daje niesamowite możliwości Threat Huntingu i analizy powlamaniowej. Zdarzenia sieciowe sa efemeryczne wiec posiadanie payloadu daje Ci jedyna możliwość dojścia skąd i dlaczego – poznać łańcuch wieloetapowego ataku. Koszt infrastruktury może być znaczący ale z praktyki powiem, że znacznie zmniejsza koszt porządnie wykonanego IR. Security Analitics (bo tak to sie ostatnio nazywa) razem z EDR w dzisiejszych czasach wydaje sie koniecznością.
Nie sądzę aby FPC mógł w czymkolwiek pomóc (z reguły). Nawet jeśli będziecie radzić sobie SSL a pomocą MITM, to pozostaje jeszcze HSTS i pining.
Nagle okazuje się że dla rzekomego bezpieczeństwa trzeba wyłączyć lub ominąć kilka istotnych mechanizmów bezpieczeństwa, żeby na końcu się okazało że atakujący użył kryptografii klucza publicznego ale nie SSL-a i w dumpach ruchu sieciowego jest pełno informacji – zaszyfrowanych.
Chyba lepiej uznać że w przypadku skompromitowanego systemu wszystkie dane jakie były na nim dostępne są skradzione, czy istotne jest to czy np kradziono tylko pliki Doc i Pdf a xls już nie ?
> o wiele trudniej będzie udowodnić że takie nagrywanie
> uchu będzie zasadne i nie wypełni znamion nadmiarowości.
> Szczególnie że zapewne dojdzie do ryzyka gromadzenia
> danych prywatnych co zupełnie rozwali system.
No właśnie – a jak jest ze zgodami?
Czy wystarczy, że pracownik wyrazi uprzednią zgodę na przechwytywanie i zapisywanie całego ruchu, jaki generuje na firmowym komputerze? A może jest tak, ze taka zgoda pracownika jest pracodawcy niepotrzebna? A może jest jeszcze inaczej, że pracodawca żadnej zgody pracownika nie potrzebuje? Ktoś wie?
To jeszcze musicie sobie SSL zacząć rozszywać :)
a wtedy wam captcha z google się zepsuje co znacznie osłabi morale pracowników i przełoży się na masowe odejścia, w tym momencie to już nie kwestia przekierowania DNS ale wojny informacyjnej i działania służb, żeby temu przeciwdziałać na każdej stacji roboczej należy zainstalować program monitorujący i dodatkowego pracownika do monitorowania pracownika który monitoruje za pomocą programu monitorującego.
To nie jest jakiś niespotykany pomysł, mamy kilku klientów, którzy coś takiego praktykują. Są gotowe rozwiązania, pierwsze linki z Googla: https://www.viavisolutions.com/en-us/products/observer-gigastor albo http://www.ipcopper.com/product_itr1000.htm.
@Michał Sajdak. FPC to już nie mokry sen tylko wymaganie – nie aby osiągnąć zgodność ze standardem tylko zdrowym rozsądkiem.
Szczególnie w większych firmach.
Jak ktoś nie ma pieniedzy na najdroższe rozwiązania (pudełka) lub nie czuje uzasadnienia to ma inne opcje:
– do FPC od tcpdumpa po molocha
– może skracać okres retencji dla FPC
– moze dłużej trzymać kopie ruchu wychodzącego, a krócej wychodzącego
– może trzymać metadane z FPC, takie jak daje Bro-IDS, nie takie jak daje netflow 10k stacji z wyjściem do Internetu.
Połącz wszysztkie powyższe i uzupełnij analizą ryzyka = yes, you can!
Analiza ryzyka może i powinna (jak liczymy każdą złotówkę i jesteśmy pragmatyczni) wskazać w których punktach należy monitorować i nagrywać FPC, bo będą bardziej wrażliwe i mniej wrażliwe miejsca.
Rekomendacje odnośnie FPC traktuję jako rekomendację kierunkową, a do niej trzeba dorobić szczegóły pasujące do organizacji.
Od > 5 lat przekonuję ludzi na szkoleniach i kolegów z branży by przestali się bać FPC reagując alergiczno-binarnie, zazwyczaj na „0” – nie będziemy robić, bo skala nas przeraża.
A tu nie ma czego się bać tylko z głową używać analizy ryzyka i korzystać z doświadczeń ludzi, którzy już to zrobili.
„Wymuszenie okresowej zmiany haseł systemowych (choć trudno tutaj wskazać dlaczego ma ona poprawić bezpieczeństwo i nie do końca się z tym zgadzamy)”
Mam trzy typy dlaczego okresowa zmiana haseł jest wskazana:
– przyrost mocy wzrasta wykładniczo, a co za tym idzie jest możliwe poznania starych haseł metodą siłową
– nowe luki w sofcie zostają ujawnione codziennie i to może prowadzić do poznania haseł przez osoby nieuprawnione (nawet gdy system już został załatany)
– obecne systemy są coraz bardziej zintegrowane z usługami chmurowymi i aplikacjami webowymi, a przy skompromitowaniu jednego – drugie też może paść łupem przestępców
Jeżeli hasło jest silne i unikatowe…
Nawet w dobie rewolucji kwantowych technologii? Chińczycy już działają mocno na polu kwantowego szyfrowania. Obecne mocne hasła takimi mogą przestać być i będzie trzeba je zmieniać co jakiś czas, tak jak to robimy ze słabymi. Lepiej od razu uczyć dobrych (przyszłościowych) praktyk ;)
Czyli jak chinole wprowadza szyfrowanie kwantowe to jak zmienie haslo w tym czasie z admin123 na admin321 to stanie sie ono milion razy silniejsze i odporniejsze na ataki silowe?
Do tego wystarczy zwykły superkomputer xD
A serio pisząc to kryptografia kwantowa ponoć jest odporna na jakiekolwiek ataki. Stan splątania kwantowego uniemożliwia odczytanie wiadomości, bo klucz który byś posiadał – nikt inny nie mógłby posiadać. A ten klucz byłby nierozerwalnie związany z informacją nim zaszyfrowaną. W chwili jakichkolwiek manipulacji, informacja byłaby bezpowrotnie niszczona.
> Chińczycy już działają mocno na polu kwantowego
> szyfrowania. Obecne mocne hasła takimi mogą przestać
> być i będzie trzeba je zmieniać co jakiś czas, tak
> jak to robimy ze słabymi. Lepiej od razu uczyć
> dobrych (przyszłościowych) praktyk ;)
Zawsze warto uczyć przyszłościowych praktyk, ale w jaki sposób rozwój szyfrowania kwantowego wpłynie na łamanie haseł? Kryptografia kwantowa i komputery kwantowe trochę się różnią, z tego co wiem.
No skoro pracują nad szyfrowaniem kwantowym to raczej pewne, że trwają równoległe prace nad algorytmami deszyfrującymi, które będą w przyszłości wykorzystywały maszyny kwantowe do łamania zwykłych haseł. Na początek technologie kwantowe będą niedostępne dla zwykłych ludzi, ale rządowe centra takie komputery będą miały i na pewno zdobędą nad nami olbrzymią przewagę. Bo my nadal będziemy wykorzystywać obecne technologie, np. szyfrowanie symetryczne lub asymetryczne. A to drugie podobno będzie banalnie proste do złamania dla kwantowych komputerów. I błędnie myślisz, że te dziedziny są nieprzenikalne. Otóż powstały już nawet dedykowane algorytmy i języki programowania do komputerów kwantowych, które potrafią symulować takowe środowisko.
https://pl.wikipedia.org/wiki/Algorytm_kwantowy
https://www.microsoft.com/en-us/quantum/development-kit
Czyli jeśli taki kod da się uruchomić na obecnych maszynach, nic nie stoi na przeszkodzie, aby wykonywały obliczenia pod klasyczne szyfrowania.
Warto poczytać też o pracach Chińczyków w tym temacie. Wyprzedzają oni inne czołowe ośrodki naukowe i poczynili olbrzymie postępy i rozwiązali kilka fundamentalnych problemów, które napotykali inni przy pracach nad kwantowymi technologiami.
https://en.wikipedia.org/wiki/Quantum_Experiments_at_Space_Scale
@Adam: Przypomniał mi się przypadek Bruce Schneiera.
„Tak, aktualny klucz Schneiera ma długość 4096 bitów. Co sprawiło, że zdecydował się zmienić klucz używany od 15 lat? Może to zbieg okoliczności, ale Bruce Schneier tego samego dnia, kiedy zmienił klucz, przyznał, że od dwóch tygodni pracował z dziennikiem The Guardian nad materiałami wyniesionymi przez Edwarda Snowdena…”
https://zaufanatrzeciastrona.pl/post/bruce-schneier-zmienil-dlugosc-klucza-pgp-my-tez-powinnismy/
A wniosek z tego prosty: mimo niezłamanego poprzedniego klucza, zmienił na o wiele mocniejszy, bo woli dmuchać na zimne. Tak naprawdę nikt nie wie, jakie obecnie hasła są odporne na złamanie…
Jeśli komputer kwantowy kiedyś powstanie to nasze klucze będą łamane w minuty a nie lata(mowa o super komputerach).
Mozliwe, że rząd USA czy USA posiada taki komputer- niedawno usłyszałem o projekcie IBM-Q – jeszcze w tym roku IBM zacznie udostępniać zasoby takiego komputera przez internet.
https://www.research.ibm.com/ibm-q/
Ponieważ kwanty sa niestabilne w wyższych temperaturach komputer będzie chłodzony azotem. Taki koimputer nigdy nie trafi na nasze biurko. Teoretycznie.
@Czesław: Może nie będzie tak źle. Tęgie głowy już główkują nad tym, żeby nie ziścił się ten czarny scenariusz.
„Na szczęście powstają już rozwiązania, które mają być odporne na ataki z użyciem komputerów kwantowych. Jednym z takich rozwiązań jest algorytm McElice’a oparty na kodach liniowych. Inne to algorytmy wielomianowe, system szyfrowania NTRU, a także wykorzystujące drzewo skrótu Merkle’a. Co ciekawe, większość z pomysłów była już znana nawet 40 lat temu. Jednak dopiero teraz, kiedy na horyzoncie pojawiają się komputery kwantowe zagrażające systemom bezpieczeństwa naukowcy postanowili się im przyjrzeć. Miejmy nadzieję, że pomogą one przygotować się na kolejny wielki skok technologiczny, któremu jak się okazuje towarzyszą również zagrożenia.” Źródło: CHIP.PL
A ja mam czwarty powód, chociaż na liście Djabola umieścliłbym go na pozycji 0 (zero).
Jak zagwarantujesz że jakkolwiek długie i skomplikowane hasło nie zostanie gdzieś zapisane? – w pliku tymczasowym na przykład, żeby je skopiować do sesji PuTTY? Albo w czacie między adminami, którego log będzie później leżał gdzieś niezauważony? Albo nawet niech ktoś mniej świadomy wyśle hash hasła w środku „show run” do wendora bo routery nie mogą się dogadać? Wiesz co stanie się z tym show-run’em później i kto będzie miał do niego dostęp. TO są wzystko przypadki z życia wzięte.
Jak komuś zajmie złamanie teho hash’a 3 lata a Ty nie zmieniałeś haseł od 4 lat, to masz problem.
Po co się narażać? Hasło 32 znaki z 4 grup, czy nie – zmiana raz na rok najrzadziej! Lepiej być trochę bardziej przewrażliwionym niż trochę bardziej zdziwionym, zastanawiając się „jak oni to zrobili? …”
A co w tym sprytnego? Atakujący krok po kroku realizował swój plan. Ciekawe by było tylko to w jaki sposób uzyskał dostęp do ich konta – to jest kluczowe i sprytne. Cała reszta właściwie nic specjalnego.
To bardzo sprytne, nikt by na to nie wpadł że dysponując kontrolą nad wpisami DNS przez panel zarządzania i nie mając nic innego można przekierować ruch !
Jakieś 10 lat temu masowo robili to hakjerzy z pod znaku półksiężyca, chyba nawet fejsa wam przkierowali na hacked by …
No ale jak na polskie warunki to wysoko wyspecjalizowany atak godny tylko dobrego XSS-a
Ale postulat by utrudnić zmiany DNS jest akurat sensowny. Choć widać, że atakujący był przygotowany nieźle do swojego działania.
Nie od dzisiaj wiadomo, że jak ktoś się chce włamać to się włamie. Brawa za szybkie wykrycie.
hm… zmiana wpisów MX dot. przekierowania poczty bo tak rozumiem to zostało zrobione aby przechwycić korespondencję z certyfikatem to nie takie 10minut. Propagacja MX tak samo długo trwa jak innych.
„Atak zaczął się o 2:21, a o 7:25 został wykryty przez pracowników firmy” – a w firmie się drą jak drukarka sieciowa nie chodzi 10 minut… ech monitoring
Jakim cudem WYLACZENIE 2FA uniemozliwia logowanie do podszywajacego sie serwera???
Tak że wyłączyli usługę 2FA a nie wyłączyli wymuszanie 2FA