Adam Haertle: Incydenty duże i bardzo duże, czyli administrator też człowiek

 

Omówione zostanie kilka mniejszych i większych incydentów bezpieczeństwa, których przyczyną była wrodzona niedoskonałość rodzaju ludzkiego. Wraz z prelegentem uczestnicy przejdą wspólnie przez historie wielu firm, w których doszło (lub mogło dojść) do nieprzyjemnych wydarzeń na skutek ludzkich błędów i zaniedbań. Będzie śmiesznie, będzie strasznie, będzie ciekawie. Adam Haertle, redaktor naczelny zaufanatrzeciastrona.pl

Incydenty duże i bardzo duże, czyli administrator też człowiek

— Adam Haertle —

Chciałem opowiedzieć dzisiaj o wpadkach, bo o tym lubię opowiadać najbardziej. W różnych firmach dzieją się różne ciekawe rzeczy i postaram się dzisiaj odpowiedzieć przede wszystkim na pytanie: „Kto to popsuł?” Bo wiemy czasem że coś się stało, ale nie do końca wiemy dlaczego i w jaki sposób. Na szczęście czasami ktoś przerobi raport z takiego wydarzenia i na podstawie tego raportu możemy opowiedzieć co miało miejsce tak naprawdę. Nie tylko to, co pokazano w mediach.

Może pamiętacie Państwo 21 czerwca 2015 roku. 11 samolotów nie wyleciało wtedy z Okęcia przez cyberatak. Był to bardzo poważny incydent, który do tej pory jest cytowany w światowej prasie jako jeden z przykładów ataków na infrastrukturę krytyczną. Mamy do czynienia z lotniskiem w dużym, poważnym kraju z którego samoloty nie startują ze względu na cyberatak, wszyscy więc pochylają się nad tym atakiem, żeby sprawdzić co tak naprawdę się stało. Jaki jest pierwszy, gorący komunikat? Gorący komunikat mówi, że systemy stały się przedmiotem ataku. Mamy do czynienia z jakimś atakiem na systemy naziemne. Nie wygląda to dobrze. Słyszymy potem rzecznika, który mówi, że byliśmy obiektem zmasowanego ataku.
Zmasowany atak kojarzy się z DDoS i na dokładkę sugeruje, że nie jest to jedyna linia lotnicza, która korzysta z podobnych rozwiązań, w związku z czym jest ryzyko, że ten atak może dotknąć także innych. Sytuacja robi się jeszcze poważniejsza, ponieważ mamy do czynienia z tak naprawdę globalnym zagrożeniem. Mamy więc jakiś potencjalny scenariusz, że był to atak DDoS, ale przyglądamy się dalej tym komunikatom, które pojawiają się w prasie i w pewnym momencie pojawia się informacja, że to nie był atak hakerów, ale ludzkie błędy, również często bywające przyczyną różnych incydentów bezpieczeństwa. Ale co ma wspólnego atak DDoS z ludzkimi błędami? Robi się ciekawie, tym bardziej że w sierpniu pojawia się winny, ponieważ z pracy rezygnuje dyrektor IT i spółka szuka włamywaczy. Czyli mamy atak, włamywaczy i ludzkie błędy. Gdzie leży prawda? My na te ujawnienie prawdy musimy chwileczkę poczekać, ponieważ we wrześniu do prasy wycieka informacja, że systemy LOT nie były celem ataku hakera, lecz jego narzędziem i odwraca nam się trochę sytuacja. Czyli to nie LOT był DDoS-owany tylko LOT DDoS-ował? Jak to możliwe?

W grudniu 2015 roku prokuratura umarza postępowanie w tej sprawie i okazuje się, że faktycznie był problem takiej natury, że to LOT DDoS-ował pewne chińskie kasyno. Jak takie rzeczy się dzieją? To są cuda. Do tej pory w raportach międzynarodowych, w prezentacjach na poważnych konferencjach, pojawia się informacja, że systemy LOT-u zostały zhakowane, albo że LOT był ofiarą ataku DDoS z wewnętrznej sieci, co podnosi dodatkowo rangę wydarzenia. Natomiast odpowiedź jest proszę Państwa dosyć prosta. Kto to popsuł? LOT wymieniał firewalla i do jego wymiany wynajął firmę, która wygrała w przetargu, w którym jednym z głównych kryteriów była cena. Firma ta jednak nie do końca przepisała wszystkie regułki tak jak trzeba, bo to była wymiana sprzętu wymagająca przepisania konfiguracji. Jeżeli ktoś kiedyś odpowiadał za taki projekt, to wie że jest to trudne, kłopotliwe i pracochłonne, a żeby zmniejszyć pracochłonność, trzeba po prostu przepisać mniej tych regułek. I tak się składa, że regułka która odcinała serwer DNS od zapytań ze świata, nie trafiła do nowej konfiguracji, a ten serwer DNS był tak zwanym open-resolverem i mógł zostać użyty w ataku DDoS.
Hakerom, którzy skanują cały Internet pod kątem takich serwerów zajęło to około doby by zidentyfikować, że teraz ten serwer jest dostępny dla całego świata i użyli go do ataku DDoS. Więc to że samoloty nie wystartowały, było wynikiem tego że serwer DNS LOT-u DDoSował chińskie kasyno. Można? Można. Nie było to więc włamanie, nie był to DDoS, a tak naprawdę był to błąd w konfiguracji. Ktoś po prostu nie skonczył w sposób prawidłowy konfiguracji jednego urządzenia i w związku z tym nastąpił atak na infrastrukturę krytyczną dużego kraju. Dbajcie więc o konfigurację firewalli, a szczególnie o dostęp do serwerów DNS.

Druga historia, świeża, z tego roku, dotyczy Norsk Hydro. Firma ta została bardzo boleśnie zaatakowana przez ransomware, a jeżeli interesujecie się historią szczególnie II wojny światowej, to możecie kojarzyć Norsk Hydro z czegoś zupełnie innego. Firma ta bowiem była jednym z największych światowych producentów ciężkiej wody i kiedy Niemcy zajęli Norwegię, to postanowili kontynuować tę produkcję. Wyprodukowali jej sporo, a Alianci starali się za wszelką cenę uszkodzić tę fabrykę. Niemcy przykrywali ją bardzo grubą warstwą betonu, bombowce bombardowały, ale nie mogły się przebić. W końcu przylecieli komandosi i wysadzili wszystko w powietrze. Bardzo spektakularna historia. Okazuje się natomiast, że Norsk Hydro wraca w kolejnej odsłonie, tym razem w 2019 roku. 18 marca 2019 roku, Norsk Hydro ogłasza, że mają nową panią prezes i trzeba przyznać, że jest to otwarcie roku, ponieważ już następnego dnia ogłasza, że mają również ransomware w sieci, które wyłączyło wszystkie ich systemy. Nikomu nie życzę takiego pierwszego dnia w pracy. Gorszy pierwszy dzień w pracy miała tylko osoba odpowiadająca za kontrolę ruchu lotniczego w Stanach Zjednoczonych, która 11 września musiała posadzić wszystkie samoloty znajdujące się aktualnie w amerykańskiej przestrzeni powietrznej. Na drugim miejscu jest pani prezes Norsk Hydro.

Tak więc 19 marca okazuje się, że komputery nie działają w całej firmie, a firma ta polega na procesach przemysłowych sterowanych przez komputery i te procesy też nie działają. Na drzwiach pojawiają się ostrzeżenia: „Proszę nie podłączać swoich komputerów do Internetu i w ogóle do sieci firmowej, ponieważ mamy atak ransomware”. Co ciekawe w tym ataku jest notatka, z której wynika, że włamywacze prócz ProtonMaila używali polskiej poczty o2. Jeżeli ktoś z was wie dlaczego przestępcy oprócz ProtonMaila używali Poczty o2, to bardzo proszę o informację dlaczego akurat o2 jest tak atrakcyjną skrzynką dla międzynarodowych włamywaczy. Ja nie mam pojęcia, ale mamy taki nasz mały akcent narodowy. Jak wygląda skutek takiego ataku ransomware? Oczywiście pliki są zaszyfrowane i nie do odczytania. Norsk Hydro – drugi największy producent aluminium na świecie, firma działająca w kilkudziesięciu krajach, zatrudniająca tysiące osób. Jak to możliwe że zaatakował ich ransomware, który zaszyfrował wszystko? Czy nie mieli jakichś rozwiązań Next-Generation Anti-Ransomware? Oczywiście, że mieli i przestępcy świetnie o tym wiedzieli, ponieważ pierwsze co uruchomili na zainfekowanych komputerach, to pewien skrypt.

Skrypt ten ma jakieś 30 stron i każda z nich odpowiada za wyłączenie wszystkich możliwych rozwiązań bezpieczeństwa. Nie sprawdzali nawet co akurat było zainstalowane u ofiary, po prostu puścili 30 kilobajtowy skrypt, w którym znajdowały się po kolei polecenia wyłączające wszystkie usługi jakie mogą zabezpieczać te komputery przed infekcją. W związku z czym po puszczeniu skryptu z prawami administratora domeny, można już było sobie spokojnie taką stację zaszyfrować, zainfekować, zrobić z nią absolutnie co tylko się zamarzy.

Jak już się taką stację zaszyfruje, to teraz trzeba zadbać o to, żeby się nikt nie mógł do niej zbyt szybko dostać, w związku z czym zmieniamy hasła administratora – oczywiście robi to ransomware – następnie wylogowujemy wszystkie sesje i wyłączamy wszystkie interfejsy sieciowe. I już. Do takiej stacji nikt się ani zdalnie, ani lokalnie nie dostanie, trzeba faktycznie podać hasło, które umożliwi jej odblokowanie. Przestępcy zmieniają hasło na taki ciąg znaków – przynajmniej w tym wariancie – żeby nikt go nie odgadł i czekają aż ktoś zapłaci okup. Norsk Hydro postanowiła nie płacić okupu, co jest bardzo dzielną decyzją i rekomenduje to wszystkim firmom, które mają backupy. W jaki sposób Norsk Hydro sobie poradziło z tym atakiem? Firma podkreśla, że jednym z elementów, który pomógł im w ogóle jakoś zacząć reagować na ten atak, było to, że odważnie przenieśli swoją pocztę wraz z uwierzytelnieniem Microsoftowym do chmury. Nie jest to decyzja, która przychodzi łatwo, natomiast to, że mieli pocztę wraz z uwierzytelnieniem, wraz z AD w chmurze, sprawiło że mimo takiego ataku, mogli powiedzieć: „Dobra, nie włączajcie komputerów, ale macie swoje telefony, tablety i macie komunikację wewnątrz organizacji”, a komunikacja w obliczu takiego ataku jest kluczowa. Nie musicie potem sprawdzać i rozdawać ludziom prywatnych skrzynek. Niedawno jedno z miast w Stanach Zjednoczonych zostało zaszyfrowane po całości i powiedziało pracownikom „Pozakładajcie skrzynki na Gmailu”, a Gmail zobaczył, że naraz pojawiło się 500 kont z jednego IP i je wszystkie zablokował, ponieważ uznał to za działalność jakiegoś botnetu. Dobrze jest więc mieć pocztę, która działa w obliczu ataku ransomware’owego.

Inne firmy także zostały zaatakowane, to nie była jedyna ofiara, co jest jednak charakterystyczne, to że Norsk Hydro bardzo ładnie komunikuje o swojej awarii. Jeżeli szykujecie jakieś plany reakcji na wypadek jakiegoś masowego ataku złośliwego oprogramowania, czy w ogóle unieruchomienia firmy, to polecam przejrzenie profili w mediach społecznościowych Norsk Hydro, ponieważ oni nawet nagrywają filmy ze swoimi pracownikami, którzy opowiadają jak odbudowują infrastrukturę firmy. To jest dosyć niecodzienne i zaskakująco dojrzałe podejście, że faktycznie dzielą się tym z rynkiem, mówią od pierwszego dnia co się stało, jak się stało, jak z tym walczą. I to działa, ponieważ rynek faktycznie to docenia. Jest bardzo przejrzysta komunikacja i regularne aktualizacje. Rynek to docenia, ponieważ moment ataku to jest ta przerywana kreska na wykresie, która pokazuje że ten atak nie wpłynął w zasadzie na wycenę akcji. Wyceny akcji zależą głównie od kursów aluminium na rynkach międzynarodowych, bo to główny produkt Norsk Hydro, natomiast sam atak nie spowodował załamania kursu akcji bo firma podeszła do tego dojrzale i pokazała że potrafi swoją działalność szybko odbudować.
Wracając do pytania: kto to popsuł? Okazuje się więc, że ktoś dostał się na serwery Norsk Hydro i zdobył uprawnienia administratora domeny i z tymi uprawnieniami wysyłał ten ransomware na stację. Faktycznie, jest to scenariusz przed którym można się obronić na zasadzie ogólnej – staramy się bronić naszej infrastruktury i identyfikować poważne ataki-natomiast jeżeli przestępca już jest na tym etapie, to już w zasadzie przegraliśmy i możemy tylko czekać na moment, kiedy uruchomi oprogramowanie szyfrujące. Do tej pory nikt definitywnie nie atrybuował tego ataku, natomiast firma FireEye zasugerowała, że grupa która wcześniej zajmowała się atakami na karty płatnicze i terminale płatnicze dużych sieci handlowych, prawdopodobnie posługuje się tym samym narzędziem, które zostało użyte w Norsk Hydro. Jest to więc taka drobna sugestia, że być może po prostu ktoś dywersyfikuje swój biznes i zamiast kraść tylko dane kart płatniczych, bierze się również w tej chwili za wymuszenie ransomware.

Kolejna historia – Office of Personnel Management. W Stanach Zjednoczonych postanowiono stworzyć jedną firmę, która zajmowałaby się rekrutacją personelu do instytucji rządowych i weryfikacją dostępu do informacji niejawnych. W Polsce ten system funkcjonuje zupełnie inaczej. W USA to właśnie Office of Personnel Management zajmuje się wydawaniem poświadczeń bezpieczeństwa w naszym rozumieniu. Instytucja ta prócz tego, zajmuje się wszystkimi procesami rekrutacyjnymi do administracji rządowej. I ta instytucja ogłasza: „Ktoś się do nas włamał”. Włamali się i ukradli w sumie 4 miliony CV. Czy to poważny incydent? Przecież te 4 miliony CV (a nawet więcej) leży na LinkedIn, więc nic więcej raczej tam nie można znaleźć. To nic strasznego, 4 miliony CV. Mija parę dni i firma mówi, że w sumie tych CV było 18 milionów. Ale chyba dalej to nic strasznego? Co to jest 18 milionów? Na LinkedIn jest ich pewnie miliard! Mija znowu kilka dni i okazuje się, że niestety wyciekły formularze SF-86. Czym są formularze SF-86? Jeżeli ktokolwiek z was wypełniał kiedyś ankietę o dostęp do informacji niejawnych, to jest to właśnie ten dokument. Czyli jest to dokument w którym odpowiadamy na czasem proste pytania typu jak się nazywamy, gdzie mieszkamy, gdzie i kiedy się urodziliśmy, a czasem na trochę bardziej skomplikowane: jak często używamy narkotyków, jakie mieliśmy problemy z alkoholem, z rozwodami, jakie mamy kredyty, jakie mamy inne potencjalnie wrażliwe punkty. I okazuje się, że wycieka treść nie tylko pytań, ale i odpowiedzi tych kilkunastu milionów osób, które kiedykolwiek aplikowały o prace dla rządu Stanów Zjednoczonych. Jak popatrzymy na to, to pytanie brzmi: czy może być gorzej? Jak pracujemy w IT to wiemy, że zawsze może być gorzej. Zawsze, ponieważ kilka dni później okazuje się, że wyciekły również odciski palców kandydatów. O ile nałogi i kochanki można sobie zmienić, to odciski palców już trochę trudniej, choć podobno też się ta, lecz jest z tym dużo więcej zachodu. Tak więc okazuje się, że ktoś wykradł naprawdę poufne dane pracowników administracji rządowej Stanów Zjednoczonych. Mówimy tu więc o bardzo poważnym przypadku.
Od czego to się wszystko zaczęło? Okazuje się, że rok wcześniej, w listopadzie 2013 roku, firma odnotowała pewien niecodzienny incydent, mianowicie ktoś włamał się do infrastruktury i ukradł dokumentację sieciową. Tylko to, i więcej się nie pojawił. Zaskakujące – kto przyszedł po samą dokumentację? Co komu z czytania dokumentacji sieciowej? Tutaj taka profesjonalna porada – nie ukradną wam dokumentacji, jeżeli jej nie będziecie mieli. Gdybyście chcieli kiedyś uzasadnić pewne luki w dokumentacjach firmowych, możecie się powołać na ten przykład. Okazuje się natomiast, że przestępcy przeczytali tę dokumentację sieciową, przestudiowali ją i doszli do wniosku, że nie ma sensu włamywać się do tej firmy bezpośrednio i włamali się do jej dwóch dostawców. Można? Można. Z wykradzionej dokumentacji wynikało, że firma była dobrze zabezpieczona i przestępcy zorientowali się, że gdyby próbowali dostać się innymi drogami to zostaliby szybko wykryci. Skorzystali więc z dostępów, które już były – włamali się po prostu do podwykonawców i z ich infrastruktury, dostali się do infrastruktury firmowej.
20 marca 2014 roku wybucha bomba, ponieważ OPM odkrywa tych intruzów w swojej sieci i postanawia podejść do tego bardzo dojrzale. Mało jest instytucji, które w momencie wykrycia intruza, nie odcinają go od sieci, tylko go obserwują. Trzeba mieć faktycznie dużą wiarę we własne możliwości i dużą wolę akceptacji ryzyka, żeby obserwować intruza w swojej sieci, ale daje to też bardzo duże korzyści, bo jeżeli mamy takie umiejętności że wierzymy w to że zatrzymany go w razie gdyby sięgał za daleko, to możemy obserwować np. czego szuka, co często pozwala nam zobaczyć również kim jest i kogo reprezentuje. Tak więc przez dwa miesiące obserwują tego intruza w swojej sieci, a potem postanawiają go usunąć. Przez te dwa miesiące intruz nie robi nic co zmusiłoby ich do wyrzucenia go natychmiast, więc to usunięcie jest planowane. Natomiast nie wiem czy pamiętacie, że była taka gra „Szpieg konta szpieg”, bardzo fajna, ja ją uwielbiałem. W grze tej mamy dwóch szpiegów na dwóch różnych poziomach domu i dokładnie tak samo było w przypadku Office of Personnel Management, ponieważ oni widzieli tylko tego szpiega u góry, a nie widzieli, że równocześnie mają w swojej sieci drugą grupę szpiegowską, która robiła dokładnie to samo co ta pierwsza, ale obserwowali tą pierwszą i byli święcie przekonani, że mają sytuację pod kontrolą, bo widzą tych włamywaczy i ich każdy ruch, a potem wyrzucamy ich z sieci. I ci pierwsi rzeczywiście dali się wyrzucić z sieci, a ci drudzy kontynuowali prace przez nikogo już nie niepokojeni, bo firma spoczęła już trochę na laurach. Jaki był tego efekt?

Od 1 lipca 2014 roku do 30 marca 2015, włamywacze wyciągali dokument po dokumencie, bazę danych po bazie danych przez nikogo nie niepokojeni. Dlaczego 30 marca zostali wykryci? To też jest fajna historia, ponieważ bywa tak, że mamy jakieś licencje, przychodzi do nas jakiś sprzedawca i proponuje jakąś licencję, opowiada o produkcie i mówi: „Tu macie taką demonstracyjną licencję, zainstalujcie sobie kiedy chcecie i przetestujcie”. I do Office of Personnel Management oczywiście też takie firmy przychodzą i m.in. przyszła tam firma Cylance, która dała jakimś pracownikom licencje trialowe. I trzymali oni te licencje w szufladzie (bo po co im one jak oni mają co robić), aż któregoś dnia jeden z tych pracowników powiedział: „Dzisiaj mam taki wolny dzień, robiłem porządki w szufladach, mam tu taką licencję to ją sobie przetestuję”. Uruchomił ją i zobaczył że jakaś biblioteka McAfee łączy się z jakimś serwerem opmsecurity.org. Okej, czemu nie, przecież może, tylko zaraz… my nie używamy McAfee?! Zobaczmy na kogo jest zarejestrowana domena opmsecurity.org. Okazuje się, że jest zarejestrowana na Steve’a Rogersa, czyli komiksowego Kapitana Amerykę. Łączy się też z drugą domeną: opmlearning.org. Na kogo ta domena jest zarejestrowana? Na Tony’ego Starka, komiksowego Iron Mana. Więc jeżeli nie używamy McAfee, ktoś zarejestrował domeny na takie śmieszne dane, to może faktycznie warto się temu przyjrzeć? I zaczęli się temu przyglądać. Jak już się temu przyjrzeli i odpalili już pełną licencję, to jeden z pracowników stwierdził, że konsola zaświeciła się jak choinka u jego babci na Boże Narodzenie, ponieważ znaleźli dwa tysiące próbek złośliwego oprogramowania w swojej sieci w ciągu dwóch miesięcy. Warto więc czasem te trialowe licencje faktycznie uruchomić.

Natomiast jest też taka smutna historia, ponieważ pięć dni po tym jak firma dowiedziała się, że ma tę infekcję w swojej sieci, mieli już umówione spotkanie z innym vendorem, innym dostawcą podobnego oprogramowania, które również miało pomóc w reagowaniu na incydenty i temu dostawcy nie powiedzieli że już wiedzą o infekcji. Dostawca przyjechał, myślał że firma nic nie wie i został poproszony o uruchomienie wersji demonstracyjnej. I te demo oczywiście wykryło infekcję, bo to również nie był zły program i dostawca cały podekscytowany, że wykrył infekcję w tak ważnej organizacji rządowej (ale będzie wpis do portfolio!), natychmiast wystartował że dostarczy wszystko co się da, licencje, pracowników, serwery i w sumie koszty obsługi tego incydentu (nie wiedząc że firma wie o tym incydencie), dostawca podsumował na 800 tys. dolarów. Tylko jak wystawili fakturę, to niestety nikt jej nie zapłacił, bo nie było zamówienia. Także zanim coś sprzedacie komuś, upewnijcie się, że jest zamówienie i że ten ktoś ma faktycznie intencje opłacenia tej faktury, bo ta firma była na krawędzi bankructwa po tak wspaniałym incydencie. A ile to kosztowało OPM? Do tej pory jakieś pół miliarda dolarów, bo musieli zapewnić pewne usługi poszkodowanym, monitorowanie chociażby ich stanu rachunków i tego czy ktoś nie bierze na nich pożyczek. Drogi incydent, a wystarczyło włączyć tę trialową licencję parę miesięcy wcześniej.

Ponieważ był to poważny incydent, tematem zainteresowała się Komisja Senacka, która w Stanach Zjednoczonych ma pewne uprawnienia i możliwości techniczne przeprowadzania m.in. analiz takich incydentów. Raport komisji można mniej więcej streścić tak, jak sytuację większości polskich firm:

1. Brak wykwalifikowanych pracowników i brak jasno określonych zasad odpowiedzialności (czyli problemy HR-owe),

2. Brak podstawowych reguł konfiguracji systemów,

Nawet jak ktoś przeprowadzał audyt jakiejś stacji czy serwera, nie wiedział czy ta konfiguracja jest dobra czy nie, ponieważ nie było powiedziane która konfiguracja będzie dobra.

3. Brak dowodów na skanowanie podatności,

To takie ładnie sformułowanie, czyli pracownicy twierdzili że skanują, tylko nigdzie nie znaleziono dowodów że to robią więc prawdopodobnie tego nie robi.

4. Brak inwentaryzacji.

Jeżeli zarządzacie IT to weźcie sobie teraz kierownika od antywirusa, od Active Directory, od Helpdesku i od jakiegoś kluczowego systemu z którego wszyscy korzystają i każcie każdemu z nich napisać na karteczce ile ma stacji roboczych pod swoją kontrolą i wsadzić tę karteczkę do koperty, a potem porównajcie te liczby i zobaczcie jaka jest rozpiętość między najniższą a najwyższą. To bardzo fajne ćwiczenie.

Było zarządzanie aktualizacjami, ale nieskuteczne. Sporo serwerów było niezaktualizowanych. Był też wdrożony SIEM, tylko że 20% systemów było niepodłączonych, a te które były podłączone, generowały głównie false positivy. Także nie wystarczy podłączyć, trzeba jeszcze prawidłowo skonfigurować. Było wdrożone dwuskładnikowe uwierzytelnienie, ale tylko do stacji roboczych. Były karty chipowe do stacji roboczych, natomiast nie wymagane było posiadanie karty żeby zalogować się do aplikacji, ponieważ wszyscy wychodzili z założenia że do stacji wystarczy. Tylko że jeżeli stacje były przejęte przez włamywaczy, to oni już bez dodatkowej potrzeby logowali się do systemów. Wdrożono także dwuskładnikowe uwierzytelnienie przy zdalnym dostępie, ale wdrożono je w trakcie kiedy włamywacze już byli w sieci, o parę miesięcy za późno i na dodatek po wdrożeniu tego dwuskładnikowego uwierzytelnienia, nie zrestartowano wszystkich połączeń sieciowych. Więc 2FA już było, a sesje włamywaczy sobie dalej wisiały bez 2FA. Bardzo fajny case. I na koniec pytanie: kto za tym stał? Dane nigdy nie wypłynęły, nie zostały użyte, nigdy nie zostały sprzedane, nie ma żadnego dowodu że ktoś gdziekolwiek próbował z nich skorzystać.

I jest kilka takich incydentów w których dane nigdy nie wypłynęły. Ten o którym właśnie mówiliśmy (OPM), sieć hoteli Marriott (która przejęła sieć hoteli Starwood i tam były dane 500 milionów ich klientów, czasami również ze skanami paszportów), największe w Stanach linie lotnicze, United i taki nasz odpowiednik PZU, czyli jedna z największych firm ubezpieczeniowych w Stanach – Anthem. Jakie dane łącznie posiadają te cztery instytucje do których w ciągu dwóch lat ktoś się włamał i wykradł wszystkie bazy danych ich klientów? Jakie szanse ma teraz agent CIA lądujący w Chinach, że nie zostanie rozpoznany zanim jeszcze wyjdzie z terminalu lotniska? Są to ciekawe incydenty. Te dane nigdy się nie pojawiły na rynku – ktoś je ma i z nich korzysta.

I na deser mam incydent z firmy Equifax, jednego z największych biur informacji kredytowej w Stanach Zjednoczonych. Equifax, który gromadzi informacje o wszystkich klientach w USA, któregoś dnia ogłasza mieli incydent dotyczący informacji ich klientów i tak naprawdę starają się ukryć liczbę danych klientów, która wyciekła. Jak się okazuje się, wynosi ona około 150 milionów osób, czyli tak naprawdę dane co drugiego Amerykanina, nie tylko dorosłego, były w tej bazie i zostały wykradzione. Jak doszło do tego incydentu? Musimy zacząć 14 lutego 2017 roku, kiedy ktoś odkrywa podatność w module Apache Struts. Jest to moduł wykorzystywany przez wiele aplikacji i często są w nim odkrywane dosyć trywialne błędy i jest z nim problem z aktualizacją, ponieważ jest on wkompilowywany w aplikację, więc nie wystarczy po prostu puścić aktualizacji, trzeba przeprowadzić jeszcze dosyć rozbudowane testy. Ten kto odkrywa ten błąd, zgłasza go do Apache po cichu, nie ogłaszając tego w Internecie.

Apache naprawia ten błąd w kolejnej aktualizacji, ale najwyraźniej ktoś studiuje aktualizacje i zauważa że pojawił się błąd, który był bardzo ciekawy, a teraz jest naprawiony, ponieważ 6 marca w Internecie pojawia się exploit na ten błąd i ten exploit jest dosyć trywialny – po prostu w nagłówku requestu http trzeba ten payload wpisać, więc jakby mamy wykonywanie poleceń przez wpisanie polecenia w żądaniu WWW w odpowiednim miejscu pola i te polecenie się wykonuje z uprawnieniami serwera po drugiej stronie. 8 marca Talos, część firmy Cisco zajmująca się analizą zagrożeń, mówi że widzą już ataki. Niektóre ataki są proste (włamywacz pyta czy atak działa), niektóre są trochę bardziej rozbudowane (od razu włamywacz instaluje swoje oprogramowanie na stacji gdzie ten atak funkcjonuje). 8 marca, gdy ataki faktycznie są na żywo, Departament Bezpieczeństwa Wewnętrznego wydaje komunikat: „mamy zagrożenie i ataki na żywo – proszę się tym zająć” i wysyłają to do wszystkich najważniejszych instytucji w kraju.

9 marca atak opisany jest w wewnętrznej komunikacji firmy Equifax, która ma dział zarządzania podatnościami i ten dział rozsyła maila do 400 osób w organizacji (co pokazuje skalę zespołów bezpieczeństwa i administracji): „jest taka podatność, macie 48 godzin na jej załatanie bo jest aktywnie wykorzystywana przez włamywaczy”. Również 9 marca firma uruchamia skaner podatności i ów skaner nie wykrywa podatności na serwerach Equifax. Nie wykrywa podatności mimo iż jest w sumie dobrym skanerem, tylko że okazuje się, że skanuje tylko główny folder serwera WWW, nie skanuje podfolderów, a podatne aplikacje były właśnie w podfolderach. Nie wystarczy więc puścić skaner, trzeba go jeszcze odpowiednio skonfigurować żeby zrobił swoją robotę. Stwierdzają więc, że nie mają podatnych stacji i mogą spać spokojnie. Analiza śledcza wykazała potem, że 10 marca były już pierwsze próby przestępców, którzy mieli lepsze skanery, znaleźli te podatne aplikacje i próbowali czy działają.

Natomiast 13 marca były już webshelle założone na serwerach, już było skuteczne włamanie i przestępcy dostali się do infrastruktury firmy – weszli z resztą przez system który powstał w latach 70. To jest nasz luksus w Polsce, że większość systemów mamy jednak dużo nowszych. W Stanach te systemy często ruszały zanim jeszcze Polska była skomputeryzowana i to był system, który od lat 70. był regularnie aktualizowany, choć najwyraźniej niezbyt skutecznie. 14 marca zespół bezpieczeństwa pisze regułki do Snorta i wdraża te regułki, ale 13 marca mieli już zhakowane serwery, więc spóźnili się o jeden dzień. 15 marca puszczają jeszcze dwa skanery, które też nie wykrywają żadnej podatności (jeden był dostarczony przez zewnętrznego dostawcę). Tak więc jeżeli skaner podatności mówi że nie ma podatności, to wcale nie znaczy że skaner przestępców tej podatności nie wykryje. Przestępcy dostają się na serwer WWW i na tym serwerze odkrywane jest potem 30 różnych narzędzi przestępczych i okazuje się, że mając dostęp do tego serwera są w stanie przeczytać pliki konfiguracyjne aplikacji. W plikach konfiguracyjnych aplikacji jest login i hasło do bazy danych. Przestępcy bez wątpienia dziwią się dlaczego jest tylko jeden login i jedno hasło do wszystkich baz danych, ale tak niestety jest, a tak jest często wygodniej administrować systemami. Korzystają więc z tego i uzyskują dostęp do 48 baz. Śledczy, którzy przyjechali potem sprawdzić co się działo, mówią że przestępcy musieli wysłać prawie 10 tysięcy zapytań do tych baz danych, a potem zrobili 265 zrzutów.

Dlaczego taka ogromna dysproporcja? Ponieważ w tych bazach danych był straszny bałagan. Jest to też jakaś technika zabezpieczeń, bo nawet administratorzy nie wiedzieli jakie dane tam są więc ci biedni złodzieje musieli naprawdę wykonywać tysiące zapytań, żeby w ogóle znaleźć dane które chcieli ukraść. Tablice nie były opisane ani poindeksowane, nie było żadnej dokumentacji więc musieli baza po bazie przeglądać ręcznie co tam jest, czy to ich interesuje i to zrzucać. I tak dwa miesiące sobie w tej sieci siedzieli. W jaki sposób wykrywamy takich przestępców? 29 lipca o 9 wieczorem ktoś zwrócił uwagę że ta firma miała też narzędzia do monitoringu sieci. Oczywiście że miała. Większość dużych firm ma. I miała m.in. narzędzie do monitorowania ruchu SSL. Taki atak man-in-the-middle, czyli podstawione certyfikaty, zamiast oryginalnych żeby rozszywać ten ruch SSL i go analizować, patrzeć czy tam nie dzieje się coś złego. Tylko okazuje się, że niestety, ale od 31 stycznia 2016 roku to urządzenie nie działało. Dlaczego? Bo wygasły na nim jego certyfikaty SSL i nikt przez półtora roku nie zwrócił na to uwagi. Możecie więc mieć pudełko za setki tysięcy dolarów, które pełni świetną rolę na narzędzia bezpieczeństwa, tylko znowu zapomnieliście zaktualizować na nim certyfikaty, nikt nie zwrócił uwagi na komunikaty o wygasłym certyfikacie, które pewnie codziennie przychodziły na jakąś nieobsługiwaną skrzynkę, aż w końcu ktoś przeczytał tę wiadomość i stwierdził: „Ojej, od półtora roku nie działa nam rozszywanie sesji SSL w naszym monitoringu. Weź John skocz i podmień ten certyfikat na działający”. John podmienił i po minucie zobaczył ruch do Chin, którego nie powinno być. Można? Można. Więc jak już zobaczyli ten ruch do Chin, to oczywiście wielka afera, włamanie i wzywają największą firmę reagowania na incydenty na świecie – Mandiant.
Mandiant przyjeżdża i musi niestety wykonać bardzo ciężką pracę, ponieważ musi zidentyfikować dane, które wyciekły. Pamiętacie jak wygląda status tych baz danych? Więc teraz Mandiant musi przeszukać wszystkie bazy danych i sprawdzić co złodzieje mogli ukraść, bo w firmie nikt nie potrafił powiedzieć co w tych bazach było. One działają, ale człowiek który je konfigurował już nie żyje. Częsty scenariusz w firmach o długiej tradycji. W końcu Mandiant dochodzi do tego co się stało i można ogłosić incydent. I faktycznie, 15 września pojawia się informacja o incydencie. Zwróćcie Państwo uwagę na domenę jaką serwowany jest ten komunikat o incydencie – equifaxsecurity2017.com. Jest to zaproszenie dla phisherów i dla innych przestępców aby z tego skorzystali. Jeżeli macie incydent, to zróbcie subdomenę głównej domeny żeby dodać jej trochę wiarygodności, ponieważ jeżeli zrobicie stronę tak jak Equifax (equifaxsecurity2017.com), to parę godzin później pojawi się jakiś żartowniś, który zamieni te dwa słowa miejscami i zrobi domenę securityequifax2017.com, dopisze jakieś obraźliwe zdania na temat waszych kompetencji w tytule tej strony, a potem wasza obsługa klienta odpowiadając klientom na Twitterze, sama się będzie mylić i podawać błędny adres strony. Taki klient przekierowany na błędną stronę, który ma sprawdzić czy jego dane wyciekły, poda tam swoje dane (bo trzeba podać by sprawdzić czy wyciekły) i dostanie komunikat „teraz to już na pewno wyciekły”. I to jest firma, która nie tylko prowadzi biuro informacji kredytowej, ale profesjonalnie świadczy usługi zarządzania incydentami. Najwyraźniej nie tak do końca profesjonalnie. Reagowanie na incydenty też jest trudną umiejętnością. Jeżeli chcecie pokazać swojemu zarządowi jakiś wykres akcji gdzie poważny incydent spowodował spadek kursu akcji, to jest to najlepszy przykład. Nie znajdziecie lepszego bo ten pierwszy duży ząbek (na wykresie) to jest właśnie incydent bezpieczeństwa, gdzie jedna trzecia rynkowej wartości firmy poszła w kanał.

Kolejny ząbek to przykład, że jeszcze nie do końca odzyskali swoje wszystkie zasoby i dalej mają problemy. Natomiast jeżeli wasz zarząd jest wnikliwy, to powie pokażcie inne przykłady dużych incydentów i tu macie sześć przykładów po których nie dostaniecie budżetu na security, ponieważ za każdym razem przy tej czerwonej strzałce miał miejsce kompromitujący incydent (taki naprawdę gruby, który trafił do światowych mediów) i kursy akcji zupełnie nic sobie z tego nie zrobiły, bo rynku nie interesuje cyberbezpieczeństwo. Nie wiem w ogóle po co my pracujemy w ogóle w tej branży. Rynek nie reaguje na tego typu incydenty – przynajmniej nie długofalowo – albo mają świetne działy PR (też jest taka możliwość).

Jakie jeszcze były skutki tego incydentu? Jeżeli wiecie o jakimś wycieku danych w jakiejś firmie giełdowej, to naprawdę nie handlujcie akcjami, nawet przez teściową lub jej sąsiadkę, bo przychodzi wtedy Komisja Nadzoru Finansowego i bije linijką po rękach. Wszyscy, którzy faktycznie skorzystali na wiedzy o tym incydencie, zostali zatrzymani i muszą oddać pieniądze, które w ten sposób zarobili i niektórzy jeszcze poszli do więzienia. I odpowiadając ostatni raz dzisiaj na pytanie kto to zepsuł? Mamy tu konkretne osoby, które to zepsuły: Davida Weba, szefa IT, który zrezygnował przez przypadek z pracy dzień po ujawnieniu incydentu, Susan Molding, szefową security, która przez przypadek zrezygnowała z pracy tego samego dnia co szef IT, mamy prezesa który tego dnia nie zrezygnował z pracy i mamy wiceszefa IT. I ten wiceszef IT został wystawiony na strzał, ponieważ kiedy prezes jechał zeznawać w senacie, tego samego dnia zwolniono z pracy wiceszefa IT. A wiecie pod jakim pretekstem?

Pamiętacie, że na początku mówiłem, że organizacja zajmująca się bezpieczeństwem wewnętrznym wysłała maila do 400 osób o tym, że trzeba zaktualizować podatny moduł? Wiceszef IT był jedną z tych 400 osób i nie przekazał tego maila dalej, za co właśnie został zwolniony z pracy. Jakaś ofiara musiała być, choć tu też taka wskazówka, ponieważ jeżeli zwolnią was po jakimś dużym incydencie to nie wszystko stracone. Sprawdziłem jego profil na LinkedInie i co on teraz robi. Okazało się, że doradza firmom jak zarządzać dużymi incydentami. Więc jeszcze mówi że ma super doświadczenie, bo w końcu przeżył jeden z największych incydentów w historii. Natomiast jeżeli mam wam w ogóle dać jakąś poradę zawodową, to proponuję żeby zostać prezesem, ponieważ prezes w momencie kiedy odchodził pół roku później w glorii (nie)chwały, dostał jedyne 90 milionów dolarów na pożegnanie, żeby nie było mu smutno że takim incydentem kończy karierę. To go pocieszyli. Tak więc taka oficjalna porada – lepiej być zdrowym i bogatym niż biednym i chorym. Mam nadzieję, że będziecie zdrowi i bogaci, a wasze systemy bezpieczne.

Adam Haertle