W trakcie spotkania SPIN pojawiło się pytanie w jaki sposób można określić czas trwania/pracochłonność penetracyjnego testu bezpieczeństwa. Nie istnieje prosta formuła, która na wejściu dostaje “opis aplikacji” (cokolwiek to oznacza), a na wyjściu podaje ilość osobodni potrzebnych na wykonanie testu. W znacznym stopniu określenie pracochłonności (co wprost przekłada się na czas trwania testu) opiera się na doświadczeniu i wcześniej realizowanych projektach. Po rekonesansie w aplikacji (no niestety, bez tego każda “wycena pracochłonności” jest w zasadzie zgadywaniem) można porównać aplikację z wcześniej wykonywanymi testami – w szczególności istotną informacją jest jak długo w rzeczywistości trwał taki test. Warto zauważyć, że ten sposób określania harmonogramów “występuje w przyrodzie”: Evidence Based Scheduling (wielkie dzięki dla Tomka za to, że polecił mi kiedyś stronę Joel on Software).
Na konferencji Hack In The Box zaprezentowany został VBootkit2 (materiały konferencyjne), w rezultacie czego można przeczytać tego typu informacje: Researchers show how to take control of Windows 7, albo Windows 7 z nieusuwalnym exploitem (autor artykułu chyba nie do końca rozumie pojęcie “exploit”). Ja powiem tak – proponuję zapoznać się z pracami Joanny Rutkowskiej (Invisible Things Lab, blog), gdzie tego typu koncepcje przewijają się od kilku lat. Ot, choćby taki przykład: Attacking SMM Memory via Intel® CPU Cache Poisoning. Zresztą in the wild występuje już od pewnego czasu malware “przejmujący system przed jego uruchomieniem”, mowa oczywiście o Mebroot. To chyba pozwala popatrzeć na temat VBootkit2 z szerszej perspektywy. Przy okazji warto zauważyć, że ten problem nie dotyczy tylko Windows. W 2007 roku, po prezentacji pierwszej wersji VBootkit pojawił się artykuł VBootkit vs. Bitlocker in TPM mode, ciekawe, czy i tym razem pojawi się taka analiza.
Zgodnie z zapowiedzią udostępniam materiały dotyczące spotkania SPIN. Znajduje się tam prezentacja (cała, wyciętych tylko kilka nieistotnych slajdów z obrazkami), oraz tekst (tylko do tej części slajdów, które zdążyłem pokazać).
Z przygotowanych 83 slajdów udało mi się dojść do slajdu 23. I bardzo mnie to cieszy, bo chyba dyskusje, które “wyszły w trakcie” również były ciekawe. Dziękuję wszystkim za tak liczne przybycie i udział w dyskusji. Jeśli nie zanudziłem Was, to się cieszę. Materiały wkrótce umieszczę (podam tutaj informację), być może wraz z prezentacją udostępnię również tekst do (części) slajdów. Mam taki zwyczaj, że do prezentacji piszę również tekst właśnie po to, by później można go było ze slajdami wystawić, choć tym razem jakość tego tekstu jest niska, za duży temat za mało czasu.
Przykłady, które demonstrowałem pod koniec prezentacji pochodzą z mojego bootcamp.
Tomek podesłał mi link do ciekawego artykułu: The Great Brazilian Sat-Hack Crackdown. Interesujący przykład, gdy dostępna funkcjonalność zostaje (nad)użyta przez osoby do tego nieuprawnione. Co więcej, obciążenie generowane przez “obcych” może spowodować niedostępność systemu dla “swoich” (klasyczny przykład DoS). Być może w czasach, gdy powstawał system FLTSATCOM, technologia potrzebna do zbudowania “klienta” nie była powszechnie dostępna, teraz, blisko 30 lat później, świat się trochę zmienił.
Kilka razy wspominałem o narzędziu F-Response. Kilka dni temu pojawiła się trzecia generacja tego narzędzia. Myślę, że w najbliższym czasie uda mi się rzucić okiem na zmiany. Oczywiście podzielę się wrażeniami, choć podejrzewam, że będę musiał napisać dokładnie to, co pisałem do tej pory: małe narzędzie, które po prostu robi to, co ma robić i robi to dobrze.
Dziś dostałem informację/potwierdzenie o nominacji mojego blogu w konkursie CONFidence Security Evangelist w kategorii Blog o bezpieczeństwie IT w języku polskim. Chciałem podziękować osobie, która zgłosiła mój blog do konkursu, jak również tym, którzy oddali już na niego głosy. Cieszę się, że widzicie w nim jakąś wartość.
Podobno złodzieje kradnący pieniądze z kont bankowych zaczęli celować również w te systemy, w których autoryzacja transakcji odbywa się przy pomocy kodów SMS. Rozwinę trochę ten temat.
Na blogu F-Secure pojawił się wpis: €25,000 Bank Robbing Mobile Phones? Podobno telefon Nokia 1100 może zostać wykorzystany do przejmowania SMS przesyłanych przez bank do klientów. Na chwilę obecną brak jest bliższych szczegółów i potwierdzenia tej informacji, ale warto śledzić ten wątek. Jeśli okaże się, że rzeczywiście możliwe jest łatwe przechwytywanie wiadomości SMS, może zrobić się ciekawie. Swoją drogą, czy ktoś zna się na GSM na tyle dobrze, by móc spekulować na jakiej zasadzie mogłoby to działać?