Wally jest moim idolem
Ja wiem, że to tylko komiks. Mimo wszystko osoby takie jak Wally istnieją w Prawdziwym Świecie i doskonale radzą sobie w Korporacjach. Wykorzystują specyfikę Korporacji do własnych celów. Choćby dzisiejszy (polski) przykład...
Ja wiem, że to tylko komiks. Mimo wszystko osoby takie jak Wally istnieją w Prawdziwym Świecie i doskonale radzą sobie w Korporacjach. Wykorzystują specyfikę Korporacji do własnych celów. Choćby dzisiejszy (polski) przykład...
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.