Widzę, że moja zagadka nie spotkała się z wielkim zainteresowaniem. No ale cóż, to mój blog i mogę na nim pisać o tak nudnych tematach, na jakie mam tylko ochotę. Zwłaszcza, że temat jest ciekawy i ma praktyczne zastosowanie dla ludzi z obu stron barykady.
Kilka pytań naprowadzających:
jakie są oczekiwania odnośnie generowanych identyfikatorów,
czy wymagania są spełnione,
Pytania pomocnicze:
jak długi (w bitach) jest identyfikator,
czy wykonalne jest sprawdzenie wszystkich wartości,
ile wartości trzeba sprawdzić, by trafić w użyty identyfikator,
Założenie jest takie, że przyznawane identyfikatory nie powinny być sekwencyjne, tak by enumeracja obiektów z użyciem bezpośredniego użycia identyfikatora była nieefektywna. Przewiduje się generowanie nie więcej niż jednego identyfikatora na sekundę. Identyfikatory muszą pozostać unikalne przez okres 10 lat.
Okazało się, że w czasie ostatniej ślizgawicy ucierpiała nie tylko moja dup^wduma, ale również taki mój jeden gadżet:
Nie widać tego dokładnie na zdjęciu, ale elektronika jest uszkodzona, w szczególności kość pamięci pokryła się ładną siatką pęknięć.
Nie był to najbardziej pojemny pendrive, szybkością również nie grzeszył. Miał natomiast jedną cechę, którą bardzo lubiłem – po podłączeniu do komputera przedstawiał się jako dysk, a nie jako nośnik wymienny. Co z tego? To, że wówczas można było na nim zrobić partycje (specyfika Windows), jedną zostawić nieszyfrowaną i trzymać na niej niezbędny toolbox, a drugą zaszyfrować w całości TrueCryptem i trzymać na niej notatki z testów.
Zna ktoś może jakieś powszechnie dostępne gadżety, które mają taką samą cechę?
Oryginał tego wpisu dostępny jest pod adresem Buuuu :(
w synchronizowanym folderze utwórz kontener TrueCrypt, zaczekaj aż się zsynchronizuje,
zamontuj kontener, utwórz w nim plik,
odmontuj kontener,
pobierze kontener z Google Drive,
zamontuj pobrany kontener,
...gdzie jest mój plik?!
Właściwie do ostatniego punktu może się nie uda dojść, bo samo zamontowanie kontenera może okazać się niemożliwe (właściwie – otwarcie zamontowanego kontenera).
Załóżmy, że mamy aplikację mobilną, która korzysta z chmury. Aplikacja przechowuje pewne ustawienia/dane specyficzne dla użytkownika, ale nie są to dane, których ujawnienie lub modyfikacja spowodowałyby koniec świata. W takim scenariuszu wymaganie uwierzytelnienia użytkownika może być nadmiarowe, wystarczająca będzie jego identyfikacja. Identyfikacja ta może odbywać się w sposób kompletnie dla użytkownika niezauważalny. Identyfikowana może być instancja aplikacji (konkretna instalacja) lub urządzenie, na którym ta aplikacja jest zainstalowana.
Jeśli ktoś zaoferuje wam wykonanie projektu (najczęściej jakiegoś serwisu) w oparciu o “autorski, profesjonalny CMS”, to uciekajcie tak szybko i tak daleko, jak tylko się da. Może i w jednym przypadku na dziesięć popełnicie błąd. W pozostałych dziewięciu właśnie uniknęliście poważnych kłopotów.
Co do zasady wykorzystanie pewnej dodatkowej “warstwy abstrakcji” ogranicza ryzyko związane z błędami typu SQL Injection. Ogranicza, ale nie eliminuje, bo:
wiedzieć co się użyło (a wybierać rzeczy do użycia też trzeba z głową!),
śledzić informacje na temat użytych elementów,
A co, kiedy ktoś mówi “nie mogę zagwarantować, że po aktualizacji nasz system będzie nadal działał”? Cóż, z tym też można sobie poradzić: Test-driven development.
Oryginał tego wpisu dostępny jest pod adresem SQLi w RoR
Na początek odsyłacz do “materiału poglądowego”: Hacking an Android Banking Application. Chodzi mi szczególnie o sekcję “Memory dump analysis”, choć nie tylko. Na potrzeby tego krótkiego wpisu jednak ograniczmy się do tego scenariusza.
A teraz fragment zdania, które w stosunkowo często pojawia się w książkach Schneiera:
If (...), you already have much bigger problems.
A teraz temat do przemyśleń – jeśli atakujący dysponuje takim dostępem do urządzenia ofiary, że jest w stanie pozyskać i analizować zrzut pamięci, to czy przypadkiem nie znaczy to, że mamy już większy problem, niż to, co atakujący w tej pamięci znajdzie?
Załóżmy, że w wyniku błędu w aplikacji mamy możliwość odczytu dowolnego pliku z serwera, pod warunkiem, że znamy jego nazwę (i oczywiście ścieżkę). Załóżmy, że serwer pracuje pod kontrolą systemu Windows, a aplikacja jest napisana w PHP. Załóżmy dodatkowo, że ciekawe dane znajdują się w sesji użytkownika i bardzo chcemy się do nich dostać.
Czym te “bardzo ciekawe dane” mogą być? Zależy. Jednym z ciekawszych przypadków, które widziałem w ciągu ostatnich 12 miesięcy, była sytuacja, w której w sesji użytkownika był zapisywany jego login i hasło. Działo się tak, ponieważ aplikacja webowa pełniła właściwie tylko rolę GUI do WS, który to WS z kolei wymagał podania danych uwierzytelniających przy wywołaniu każdej metody. Możliwość masowego odczytywania danych zapisanych w sesji niewątpliwie w tym przypadku byłaby bardzo “owocna” dla atakującego.
