Od lat wciąż jesteśmy krok za atakującymi

CRN Już od dwóch dekad cyberprzestępcy dokonują ataków wyłącznie dla zysku. Metody poszukiwania ofiar dobierają więc na bieżąco i kierują się głównie tym, ile pieniędzy mogą zdobyć. Wasz zespół także poszukuje luk dla pieniędzy, ale znajduje się po „jasnej stronie mocy”. Według jakich kryteriów zatem wyznaczacie obszar poszukiwań i na czym one polegają?

Grzegorz Wypych Naszym celem jest odkrycie sposobu, który mógłby zastosować cyberprzestępca do uzyskania nieautoryzowanego dostępu do zasobów IT. Ma on swobodę w wyborze technik i narzędzi, więc taką swobodę musimy też mieć my. Wykorzystujemy szeroko pojętą wiedzę dotyczącą elektroniki, programowania, inżynierii wstecznej czy teorii sygnałów. Wspomagamy się nabytymi i własnymi narzędziami do prowadzenia analiz, na których tworzenie poświęcam dość dużo czasu. Działalność ta nie jest schematycznym procesem, nieustannie musimy sięgać po różne niekonwencjonalne metody i szukać tam, gdzie inni nie szukają, trochę jak przysłowiowej igły w stogu siana. To wyzwanie szczególnie ciekawe w przypadku rozwiązań Internetu rzeczy, którymi się zajmuję, bo – ze względu na ich charakter – możliwości przeprowadzenia ataku na nie są znacznie szersze.

Czego konkretnie szukacie?

Tak jak wspomniałem, zaczynamy nie wiedząc, gdzie skończymy, więc na początku działamy stopniowo i zaczynamy od poznania urządzenia. Ale generalnie szukamy błędu konstrukcyjnego, który mógłby wpłynąć na bezpieczeństwo – chociażby przejęcie sesji użytkownika lub jego danych do logowania – albo spowodować straty, finansowe czy wizerunkowe, u producenta danego rozwiązania. Bywało, że mogłem przełamać zabezpieczenie odczytu pamięci w procesorze i uzyskać dostęp do firmware’u, a następnie za pomocą inżynierii wstecznej przeanalizować, jak zostały wykonane różne funkcje lub jakie są w nich luki. Zdarzało się nawet, że wstrzymywana była produkcja, bo znaleźliśmy błąd w architekturze procesora, a jego nie da się naprawić za pomocą oprogramowania. 

A często bywa, że nic nie możecie znaleźć?

Bardzo rzadko. Oczywiście, ważne, ile mamy czasu. W przypadku testów penetracyjnych wygląda to trochę inaczej niż przy wykonywanym przez nas badaniu bezpieczeństwa – jest lista działań do wykonania, więc można je zaplanować i ocenić czas, po którym znane będą rezultaty. Zdarzało się, że nasze poszukiwania trwały miesiącami. Ale dzisiejszy poziom skomplikowania rozwiązań IT sprawia, że niemożliwe jest uniknięcie błędów przez producentów, więc czasem działamy do skutku.

Co po przeprowadzonym badaniu otrzymuje od was producent? Tylko informację o znalezionej luce? Czy podpowiadacie sposób na jej usunięcie?

W raporcie obszernie informujemy o luce,  sposobie weryfikacji, że ona rzeczywiście istnieje, oraz ryzyku, które stwarza. Rozwiązanie problemu należy jednak do producenta. My tylko czasami pokazujemy, co mogłoby zabezpieczyć przed takim atakiem, ale na pewno nie przygotowujemy łatki. Ważne jest też, w jakim trybie informujemy o badaniu opinię publiczną. Jeżeli prowadzone jest na zlecenie konkretnego klienta, raport trafia tylko do niego. Jeśli zostało zainicjowane przez nas, informujemy producenta, że przeprowadziliśmy badanie i znaleźliśmy błędy, a także dostarczamy sprawozdanie i dajemy 90 dni na załatanie luki. Później umieszczamy informację w publicznej bazie CVE. Jednak czasami, na prośbę producenta, wstrzymywaliśmy się na kilka miesięcy z publikacją raportu, ponieważ luka była trudna do usunięcia, więc nie chcieliśmy ujawniać jej zbyt wcześnie.

Jakiego typu wiedzą trzeba dysponować, aby prowadzić tak zaawansowane badania? I czy konieczna jest wąska specjalizacja, czy trzeba mieć doświadczenie z bardzo wielu dziedzin?

Pewien rodzaj specjalizacji jest konieczny, bo nie można znać się na wszystkim. Dlatego często pracujemy w grupach i uzupełniamy się. Natomiast trzeba mieć szerokie doświadczenie w obsłudze różnych narzędzi, które ułatwią osiągnięcie celu. To szczególnie duże wyzwanie w przypadku urządzeń Internetu rzeczy, ponieważ dostajemy tylko pudełko i musimy sami wydobyć zaimplementowane w nim oprogramowanie, a jego producent robi wszystko, aby to uniemożliwić. Potrzebna jest więc także wiedza z zakresu elektroniki. Czasami wylutowujemy procesor z płyty głównej, budujemy własny układ, w którym go instalujemy, i dopiero w takich warunkach przeprowadzamy testy. Musimy mieć doświadczenie w lutowaniu precyzyjnym, obsłudze oscyloskopu, mikroskopu i wielu innych narzędzi. Z reguły konieczne jest zastosowanie inżynierii wstecznej, więc wiele czasu spędzamy na złamaniu zabezpieczeń procesora. Gdy już zdobędziemy oprogramowanie zarządzające sprzętem, niezbędna jest jego analiza. A bez znajomości programowania niskopoziomowego, przede wszystkim w assemblerze, jej przeprowadzenie jest niemożliwe. 

W przypadku analizy pracy samego oprogramowania powinno być zatem znacznie łatwiej…

Z jednej strony tak, bo odpada długotrwała „zabawa” ze sprzętem, a pliki do analizy dostajemy niemalże na tacy. Ale z drugiej strony trzeba systematycznie aktualizować swoją wiedzę. Zmiany w sposobie konstruowania urządzeń nie są aż tak częste, a raz stworzone protokoły transmisji stosuje się latami. W aplikacjach webowych zaś sposoby zabezpieczeń, przechowywania i przesyłania danych nieustannie ewoluują, zmieniają się też języki programowania. Do tego dochodzi konieczność posiadania wiedzy na pograniczu psychologii, bo trzeba umieć odtworzyć tok myślenia autora kodu. A to jest możliwe tylko wtedy, gdy samemu wcześniej było się programistą – na podstawie analizy własnych błędów można z większym prawdopodobieństwem oszacować, gdzie podobne błędy mogła popełnić inna osoba. Dla mnie ogromne ułatwienie stanowi fakt, że kiedyś byłem programistą aplikacji webowych.

Eksperci branży IT mogą uzyskać certyfikaty potwierdzające ich wiedzę w bardzo wielu obszarach. Czy podobnie jest w kwestiach związanych z badaniami nad bezpieczeństwem?

Mam dość ambiwalentne odczucia dotyczące certyfikatów. Zleceniodawcy często ich wymagają, traktując je jak formę ubezpieczenia przed odpowiedzialnością za nieprawidłowe wykonanie pracy przez zleceniobiorców. Nie zawsze odzwierciedlają one rzeczywisty wysoki poziom wiedzy i doświadczenia, więc usługodawcy zdobywają certyfikaty, ale trochę na siłę. W tej branży chodzi przede wszystkim o posiadanie otwartego umysłu. Żadnych certyfikatów nie mają najlepsi na świecie eksperci ds. badań nad bezpieczeństwem rozwiązań IT. Ja także ich nie mam i nie zamierzam się o nie starać. Zresztą nie ma żadnych certyfikatów dotyczących działań, którymi się zajmuję.

Czy wspomniane analizy zawsze prowadzone są ręcznie, czy korzystacie z narzędzi automatyzujących lub wręcz ze sztucznej inteligencji?

Podczas badania sprzętu na początku jest  dużo pracy ręcznej – lutowanie, budowanie alternatywnego układu, podłączanie i analiza poprawności jego pracy. Dopiero w tak stworzonym środowisku testowym można wprowadzać procesy automatyzujące badanie z wykorzystaniem skryptów. To konieczne, gdyż samodzielna analiza wyników prób znalezienia szczególnie podatnych na ataki miejsc jest bardzo nużąca i łatwo coś przeoczyć. Czasami korzystamy z prostych narzędzi sztucznej inteligencji, ale na pełne rozwinięcie skrzydeł raczej nie ma tu szans. Uczenie maszynowe jest najbardziej skuteczne wtedy, gdy ma się bardzo dużo danych i cały czas dostarczane są nowe. A tutaj mamy układ zamknięty, pewną część danych jesteśmy w stanie uzyskać, ale nowych nie przybędzie.

Czy w procesie analizy uwzględniane są tak chętnie wykorzystywane przez cyberprzestępców mechanizmy inżynierii społecznej?

W pewnym stopniu tak. Jak już wspomniałem, jako programista muszę podążać za tokiem myślenia autora oprogramowania. W podobny sposób musimy ustalać, jak postępuje użytkownik urządzenia lub aplikacji. Atak może być dokonany w każdym obszarze, w którym dochodzi do interakcji z użytkownikiem. Ta dziedzina jest zresztą bardzo niedoceniana przez działy badania jakości i testów oprogramowania. Skupiają się one na poprawności działania poszczególnych funkcji, rzadko badają sytuacje, kiedy, dajmy na to, użytkownik wprowadza nietypowe dane. Tymczasem to znana od lat metoda ataku.

Czy luk powinno się szukać także w rozwiązaniach ochronnych? Czy można zakładać, że ich producenci znają się na bezpieczeństwie i błędów nie popełniają?

Nie można zakładać, że rozwiązanie nie ma błędu, wręcz odwrotnie – zawsze trzeba zakładać, że błąd jest i go szukać. Nie wolno nadmiernie ufać żadnemu producentowi tylko ze względu na jego wielkość, markę czy sektor, w którym działa. Dla dużych firm, także działających w branży bezpieczeństwa IT, znaczący problem stanowi fakt, że nie tworzą wszystkiego same, że wiele komponentów i związanych z nimi usług pozyskują w ramach outsourcingu. Prawie wszystkie kupują gotowe procesory, a nawet jeśli zaprojektują je same, to ich produkcję zlecają innym. Bardzo często też współpracują z zewnętrznymi podmiotami w produkcji oprogramowania. Im więcej rozwiązanie ma funkcji, tym większa szansa, że współtworzyło je wiele firm, a tylko sprzedawane jest pod określoną marką. Oczywiście, każde liczące się przedsiębiorstwo ma własne zespoły poszukujące błędów w tworzonych rozwiązaniach. Często jednak brakuje im świeżego spojrzenia, nieszablonowego podejścia, dzięki któremu udaje się znaleźć coś tam, gdzie nikt by nie pomyślał, że należy szukać.

W ostatnich latach co pewien czas padają publicznie poważne oskarżenia wobec niektórych producentów, że ich urządzenia mają „tylne furtki” ułatwiające szpiegostwo na dużą skalę. Czy dzięki stosowanym przez was narzędziom można po pierwsze wykryć backdoory, a po drugie – prowadzoną za ich pomocą transmisję?

Teoretycznie odpowiedź na oba pytania brzmi „tak”. Czasami jest to banalnie proste. Pewien czas temu przeprowadzono badanie, w którym sprawdzono, czy jakieś dane do centrali wysyłają telewizory Smart TV. Okazało się, że z tej możliwości korzystali wszyscy producenci, czasami wręcz transmisja była niezaszyfrowana. W przypadku bardziej zaawansowanych rozwiązań, w których wykrycie backdoora mogłoby mieć kontekst polityczny, oczywiście nie jest to takie łatwe. Tylne wejścia są w nich z reguły sprytnie chowane, a prowadzona za ich pomocą transmisja „zaszumiona” i naturalnie zaszyfrowana, aby trudniej było sprawdzić, jakie dane są wysyłane. Ale interpretacja wyników analizy obecności backdoorów nie zawsze jest jednoznaczna. Rok temu podjąłem się badania routerów Wi-Fi popularnego chińskiego producenta. Zrobiliśmy to za jego zgodą i otrzymaliśmy wiele urządzeń do testów. We wszystkich znalazłem poważne błędy, które umożliwiały bezpośredni nieautoryzowany dostęp do nich. Luki były w takich miejscach, że wyglądały na backdoory. Powstały z powodu zastosowania niewystarczająco zabezpieczonych funkcji, których od lat nie powinno się używać, o czym wszyscy zaznajomieni z tematem wiedzą. Tymczasem ja znalazłem te funkcje w 70–80 miejscach, a w paru przypadkach umożliwiały one nieautoryzowany dostęp. Natomiast firma stwierdziła, że to błąd programisty i naprawiła je w kolejnym wydaniu firmware’u. Czy istnienie luk miało jakiś cel, nie dowiemy się nigdy.

Czy można zatem wskazać, jakie rozwiązania są najlepiej zabezpieczone?

Bardzo dokładnie chronione, bo o stuprocentowym bezpieczeństwie nigdy nie można mówić, są praktycznie tylko rozwiązania dla wojskowości, bo armie mają raczej nieograniczone fundusze. Trudniej jest zaatakować urządzenia do ochrony sieci, ale niektóre z nich, np. firewalle aplikacji web, są podatne na ataki typu bypass. Wiadomo też, że w urządzeniach do przechowywania haseł lub kryptowalut stosowane są procesory, do których można „wstrzyknąć” błędy i w ten sposób wydobyć klucz prywatny użytkownika. 

Jakie kryteria powinno się stosować do oceny, czy rozwiązanie jest wystarczająco bezpieczne? Do jakiego stopnia można ufać producentom?

Istnieje wiele niezależnych organizacji, które poddają rozwiązania ochronne drobiazgowym testom, więc raporty z ich przebiegu mogą stanowić punkt wyjścia do decyzji o zakupie. Warto także sprawdzić, czy w bazie CVE znajdują się informacje o lukach w rozwiązaniach producenta i czy błędy zostały zlikwidowane. Ich duża liczba paradoksalnie nie musi świadczyć o tym, że dostawca ma słabej jakości rozwiązania. Wręcz przeciwnie, wskazuje na jego otwartość w komunikacji i odpowiedzialność, bo – jak już wspomniałem – w branży IT nie ma produktów bez błędów. Dowodem profesjonalnego podejścia są też ogłaszane przez producentów programy bug bounty. Z otwartą przyłbicą mówią oni, że dopuszczają najbardziej drobiazgowe testy, a za znalezienie poważnych błędów wypłacają niemałe wynagrodzenie. W pewnym stopniu można też zminimalizować ryzyko, korzystając z oprogramowania bazującego na otwartym kodzie źródłowym. W przypadku kodu powszechnie dostępnego jest większa szansa, że obejrzy go kilku specjalistów, niż gdy kod jest zamknięty. W jego przypadku cyberprzestępcy mogą wykorzystywać lukę latami, a użytkownik nawet o niej nie wie. To naturalne, że producenci skupiają się przede wszystkim na funkcjach, bo one przynoszą zyski, a bezpieczeństwo jest kosztem. Na szczęście coraz częściej zdają sobie sprawę, że na jednej dziurze można stracić więcej, niż zarobić na sprzedaży miliona urządzeń. 

Czy twórcy rozwiązań IT zawsze muszą być zmuszani do kompromisu między ich bezpieczeństwem, a funkcjonalnością oraz łatwością obsługi?

To zależy od miejsca, w którym zastosowane są zabezpieczenia. W sprzęcie można ukryć je tak, że użytkownik w ogóle nie będzie świadom ich istnienia. Ale w oprogramowaniu i usługach internetowych to bardzo złożone zagadnienie, bo rzeczywiście użytkownicy powszechnie narzekają na niedogodności. Co jest przyczyną problemów? Pierwsze przeglądarki oraz stosowane w nich protokół HTTP i język HTML były przystosowane do pobierania i wyświetlania statycznych stron, na których w ogóle nie było możliwości interakcji z użytkownikiem, więc ataki były ograniczone do interakcji z serwerem. Po pojawieniu się i późniejszym rozwoju różnego typu usług internetowych wykorzystujących protokół HTTP zaczęto dostosowywać go do nowych wymagań. Takie podejście było błędne, ponieważ powinno się poszukiwać bezpieczniejszej formy interakcji, bez korzystania z przeglądarki. Tymczasem przez lata wprowadzono do tego protokołu wiele funkcji, w których były luki umożliwiające ataki typu Man In The Middle, śledzenie komunikacji, kradzieże haseł itd. Dlatego od lat trzeba łatać dziury i dodawać nowe zabezpieczenia, które na pewno nie ułatwiają obsługi, więc budzą frustrację użytkowników. Co więcej, przeglądarki pojawiają się w kolejnych urządzeniach, jak smartfony czy telewizory – jest to wygodne, ale nie bezpieczne. Jeśli nie nastąpi rewolucja w tym zakresie, a na razie na to się nie zanosi, nic nie zmieni się na lepsze.

Jakich zagrożeń powinniśmy się obawiać w najbliższej przyszłości?

Od lat trwa gonienie króliczka, a osoby zabezpieczające wciąż są krok za atakującymi. Oni nie działają schematycznie, szukają błędów wszędzie tam, gdzie ma miejsce interakcja z użytkownikiem. Oczywistym utrudnieniem jest rosnąca popularność sprzętu podłączanego do internetu, bo to niemal wykładniczo zwiększa liczbę miejsc, na które może być przypuszczony atak. Mikrokomputer wbudowany w lodówkę łączy się z internetem, więc automatycznie narażony jest na próbę przejęcia kontroli nad nim przez cyberprzestępców – czasami tylko w celu wykorzystania jego mocy obliczeniowej do kopania kryptowalut, czasami dla przeprowadzania ataków typu DDoS na różne cele w internecie, ale czasami do użycia go jako bramy wejściowej do innych podłączonych do lokalnej sieci urządzeń. 

Czy widać na czyją stronę przechylona jest szala w cyberwojnie? Czy mamy szansę wygrać z cyberprzestępcami?

Na szczęście wiele błędów jest wykrywanych proaktywnie, dzięki czemu zabezpieczane są systemy IT na całym świecie. Dlatego bardzo ważne jest, aby nie wprowadzać żadnych ograniczeń i dawać wolną rękę specjalistom od testowania. Są niestety kraje, w których zabroniono stosowania inżynierii wstecznej, tymczasem w wielu przypadkach jest to jedyna metoda znajdowania błędów.