Kilka wyzwań na świąteczną nudę
Jeśli komuś znudzi się “świąteczna atmosfera” albo świąteczne obżarstwo, może zająć się kilkoma wyzwaniami. O większości z nich już wspominałem, ale postanowiłem wspomnieć jeszcze raz.
Jeśli komuś znudzi się “świąteczna atmosfera” albo świąteczne obżarstwo, może zająć się kilkoma wyzwaniami. O większości z nich już wspominałem, ale postanowiłem wspomnieć jeszcze raz.
Temat jest w pewnym stopniu związany z wyzwaniem, o którym pisałem wczoraj. Dostępny jest zrzut pamięci, a zadanie polega na odzyskaniu określonego pliku. Czy jest to możliwe? Tak, o ile plik ten znajduje się w pamięci. Pewna szansa na to istnieje, a to z uwagi na coś, co nazywa się file system cache. Poniżej prosty przykład jak można w pamięci znaleźć zawartość pliku.
Pojawił się kolejny odcinek w ramach Forensic Challenge 2010, tym razem nosi tytuł Banking Troubles. Dostępny jest zrzut pamięci operacyjnej systemu w chwili prawdopodobnej infekcji. Jak ONI dostali się do środka? Cóż, poniższy fragment daje sporo do myślenia:
(...) One of their employees had received an email from a fellow co-worker that pointed to a PDF file. (...)
Oryginał tego wpisu dostępny jest pod adresem Challenge 3 of the Forensic Challenge 2010 – Banking Troubles
Autor: Paweł Goleń
Mechanizm sandbox stosowany w Internet Explorer (pod nazwą protected mode) i Chrome różni się sposobem realizacji, ale prawdopodobnie również samymi założeniami odnośnie tego, przed czym ma on chronić. W moim odczuciu pomysł wykorzystany w Chrome jest nieco lepszy. Paradoksalnie lepiej wykorzystuje mechanizmy dostępne w systemie Windows, niż Internet Explorer tworzony przez producenta tego systemu.
Dostępny jest opis sposobu, w jaki został pokonany IE8 na Windows7: Pwn2Own 2010 Windows 7 Internet Explorer 8 exploit. Muszę przyznać, że koncepcja jest ciekawa, szczególnie podoba mi się użycie VirtualProtect do obejścia DEP.
Mam jednak pewną wątpliwość, w dostępnych materiałach nie znalazłem wprost informacji który proces został skutecznie zaatakowany i z jakimi prawami udało uruchomić się kod. Chodzi mi o to, że zabezpieczenie jest warstwowe, w szczególności:
Zadaniem pierwszej warstwy jest utrudnienie wykorzystania ewentualnej podatności, druga warstwa natomiast ma ograniczyć skutki sytuacji, w której istnieje podatność i jest ona możliwa do wykorzystania pomimo istnienia funkcji DEP i ASLR. Zastanawiam się, czy udało się również wyjść w piaskownicy, czy też uruchomiony kod był objęty ograniczeniami wynikającymi z protected mode.
Oryginał tego wpisu dostępny jest pod adresem Pwn2Own 2010 – jak bardzo padł IE8?
Autor: Paweł Goleń
Wymyśliłem właśnie nowy atak z użyciem serwisów społecznościowych. Jest genialny w swojej prostocie, a skutki mogą być dla ofiary wyjątkowo uciążliwe. Na czym polega? Na początek drobne wprowadzenie, za wpisem A jak to jest w Polsce?:
(...) Wiadomo, że sprawdza się czasem, czy obywatele płacą podatki, a wytypować takich można w internecie. W internecie można sprawdzić, czy komuś przysługuje jakieś świadczenie społeczne... (...)
Zasada działania ataku jest prosta. Należy wykreować “wirtualną rzeczywistość” dotyczącą wybranej ofiary. Wirtualną, czyli taką, w której prezentowany w serwisach społecznościowych (ogólnie: w Internecie) stan posiadania wyraźnie odbiega od danych (prawdopodobnie) deklarowanych przez ofiarę w zeznaniach podatkowych. Pozostaje tylko czekać na efekty. Skuteczność ataku może być zwiększona przez mały donosik.
Technika ta może być wykorzystana również do dobrych celów, tak jak w kawale o prezencie bacy dla bacy czyli rąbaniu drewna przez CBŚ.
Oryginał tego wpisu dostępny jest pod adresem Właśnie wymyśliłem nowy atak :)
Autor: Paweł Goleń
Weryfikacja poprawności kontroli dostępu do danych oraz do funkcji jest jednym z bardziej istotnych elementów testów bezpieczeństwa aplikacji. Tematowi temu były poświęcone między innymi dwa przykłady w przewodniku po bezpieczeństwie aplikacji internetowych (Lekcja 2: Nieprawidłowa kontrola dostępu do danych oraz Lekcja 3: Nieprawidłowa kontrola dostępu do funkcji). Dziś spojrzenie na temat z nieco innej strony.
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ć?