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.