Do tych rozważań skłonił mnie wpis Nasza-Klasa i atak typu phishing, choć od dawna mam wątpliwości co do wpływu błędów takich jak open redirect na ryzyko. Mówiąc prościej – zastanawiam się o ile skuteczniejszy jest atak phishingowy na serwis, w którym istnieje błąd typu open redirect od ataku na serwis, w którym takiego błędu nie ma. Bo sam fakt, że jakiś błąd znajduje się (wyżej lub niżej) na liście typu 2010 CWE/SANS Top 25 Most Dangerous Programming Errors nie koniecznie przekłada się na to, jak dane wystąpienie podatności określonego typu należy wycenić. Trochę już w tym temacie pisałem we wpisie Scenariusze wykorzystania Cross-Site Scripting.
Drobne uzupełnienie do wpisu Wykrywanie API hooking, a konkretnie do możliwości wykorzystania narzędzia Volatility w tym celu. Wspominałem, że istnieje plugin służący do wykrywania API Hooking, ale nie udało mi się go (jeszcze) użyć. Poświęciłem temu tematowi chwilę czasu i udało mi się przekonać całość do działania.
Rzuciłem okiem ostatnio na pewne narzędzie, które służyło do “zabezpieczania” środowiska pracy użytkownika. Nie wdając się w szczegóły procesy uruchomione w tym środowisku miały pewne dodatkowe ograniczenia, na przykład odnośnie uruchamiania innych procesów (lista dozwolonych), zapisywania danych, kopiowania plików. Gdy widzę takie rozwiązanie zawsze przede wszystkim zastanawiam się nad tym, jak je można obejść. Do tego dobrze jest wiedzieć (przynajmniej w przybliżeniu) jak to coś działa. Nie miałem na to zbyt wiele czasu, ale szybkie zbadanie sprawy przy pomocy Process Monitor pokazało, że “chronione” procesy ładują dodatkowe biblioteki. Moja pierwsza hipoteza zakłada więc API Hooking. Tylko jak łatwo ją potwierdzić?
Tym razem kontynuacja wpisu (Prawie) każde szyfrowanie można złamać, która dotyczy śladów, jakie pozostawiają w systemie Windows narzędzia do szyfrowania. Konkretnie dwa: TrueCrypt oraz FreeOTFE, przy czym w przypadku FreeOTFE skupię się na FreeOTFE Explorer. W obu przypadkach skupię się na kontenerach, a nie szyfrowaniu dysków.
Na początku chciałem wyjaśnić jedną rzecz – nie kwestionuję istotności tematu użyteczności aplikacji, zresztą wspominałem o tym wcześniej. Irytuje mnie natomiast “usability”, czyli banda nawiedzonych, niedouczonych oszołomów, którzy uszczęśliwiają (pośrednio) mnie na siłę. Wszystko oczywiście w ramach rewitalizacji aplikacji i poprawy usability właśnie. W tym swoim ślepym zapatrzeniu we “święte księgi” przypominają mi tolkistów z Kłopotów w Hamdirholm.
Nawiązując do pytania z komentarzy odpowiadam: (prawie) każde szyfrowanie można złamać, TrueCrypt też. Wystarczy “tylko” znaleźć odpowiedni klucz, a jest to “tylko” kwestia czasu, w przypadku dobrego rozwiązania – bardzo długiego czasu. Trzeba przy tym uwzględnić fakt, że czas ten może zostać zredukowany nie tylko przez postęp techniczny, ale również przez kolejne osiągnięcia w kryptoanalizie (np. Nowy atak na AES-256 ).
Przykład szyfrowania, którego się “nie da” złamać to poprawnie użyty one-time pad, ale z dość oczywistych względów do szyfrowania dysków się nadaje umiarkowanie...
Za dawnych czasów podczas zimowych wypraw w góry zawsze szedłem przodem. Podobno nikt głębiej ode mnie się nie zapadnie. Dziś przekonałem się, że nadal jest to prawda.
Ponieważ jakiś czas temu wydana została finalna wersja BackTrack 4 postanowiłem w końcu zaktualizować swoją instalację na USB. Ostatecznie doszedłem do wniosku, że pendrive o rozmiarze 4GiB to trochę za mało (obecnie już zalecane jest 8GiB), ale nie miałem innego wolnego o większej pojemności pod ręką, więc musiałem zadowolić się tym, co miałem. Dodatkowo okazało się, że wersja finalna jest nieco większa i nie mieści się na partycji przygotowanej pod wcześniejszą wersję. Nie chciało mi się bawić w partycjonowanie pendrive na nowo, więc stwierdziłem, że zainstaluję go nieco inaczej.
Wpis ten jest związany z tematem autoryzacji transakcji, który wielokrotnie już poruszałem. Mimo tego temat wciąż nie został wyczerpany, jest ciągle wiele aspektów, o których się mówi. Jeden z nich chcę tu poruszyć, tak trochę w ramach ciekawostki.
Wspominałem już kiedyś o dokumencie Understanding scam victims: seven principles for systems security. Opisany jest tam między innymi scenariusz Jewellery shop scam. Polega on między innymi na “zabezpieczeniu” przez policję “fałszywych” pieniędzy. Skuteczność tego scenariusza opiera się na prostej obserwacji, którą dobrze oddaje poniższy cytat:
Society trains people not to question authority. Hustlers exploit this “suspension of suspiciousness” to make you do what they want.
Dlaczego o tym piszę? Ponieważ ostatnio usłyszałem bardzo podobną historię z naszego polskiego podwórka, prawdopodobnie chodzi o ten przypadek: Uwaga! Przebrani za policjantów okradli sklep!!! W tym przypadku również mamy “fałszywe” pieniądze i “zabezpieczenie” dowodów. Proste i skuteczne.
