Lista procesów aktywnych w systemie jest jednym z podstawowych źródeł informacji o tym, czy przypadkiem nie działa jakiś “wrogi kod”. Problem w tym, że ów wrogi kod wcale na liście procesów pojawić się nie musi, co jednak wcale nie musi być równoznaczne z wykorzystaniem rootkita.
Podobnież szaleje epidemia Downadup, o ogromnym rozmiarze... Postanowiłem wystawić sobie “ofiarę”, czyli Windows XP SP3 (bez łatek). Niestety – wciąż nie udało mi się nic złapać. Kilka ataków miałem, ale kończyły się one błędem procesu svchost.exe , w kontekście którego pracuje atakowana usługa. W opcjach recovery ustawiłem restart po awarii usługi i wciąż czekam, aż jakaś działająca wersja na mnie trafi... Gdzie można się zgłosić po support dla wirusów? Mam logi z Dr Watson :)
Posiadanie zarejestrowanej działalności gospodarczej wiąże się z kilkoma irytującymi konsekwencjami.
These are some typical sounds we hear in our data recovery lab: Hard drive sounds.
Bardzo ciekawy artykuł w temacie usuwania danych z dysków: Overwriting Hard Drive Data.
Jeśli kogoś zainteresował temat kodowania identyfikatorów, to udostępniam trochę dokładniejszy opis mojego PoC, wraz z kodem. Przypominam, że traktuję całość bardziej jak eksperyment, niż coś, co może znaleźć praktyczne zastosowanie. Wszelkie uwagi mile widziane. W szczególności przykład, jak atakujący może generować prawidłowe “zakodowane” identyfikatory, które po stronie serwera będą miały wartość pożądaną przez atakującego. Mowa oczywiście o metodzie bardziej efektywnej niż brute force.
Jednym z mechanizmów wykorzystywanych w Windows Vista (choć pojawiły się już w Windows XP SP2 i Windows 2003 SP1) jest tak zwany “pointer encoding” (Protecting against Pointer Subterfuge (Kinda!)). W uproszczeniu chodzi o to, by ewentualna modyfikacja wskaźnika (np. przez buffer overflow) nie była trywialna. Nawet nie tyle sama modyfikacja, ale ustawienie odpowiedniej wartości. Zastanawiałem się, czy tego typu koncepcji nie można wykorzystać w aplikacjach webowych do ochrony identyfikatorów globalnych, które są ZŁE!. Taki prawdopodobnie nikomu nie potrzebny eksperyment.
Każdy ją ma, nie ma ratunku, to już prawdziwy koniec świata. Mowa oczywiście o tej mrocznej luce we wszystkich przeglądarkach: In-session phishing – luka we wszystkich przeglądarkach. Tylko, że tak naprawdę co wiadomo o tej luce, to to, że istnieje nowa metoda stwierdzenia, czy ktoś był na określonej stronie. Podkreślam nowa metoda, bo już tego typu problemy były, choćby wspomniany w In-session phishing sposób: Detecting States of Authentication With Protected Images. Dzięki temu możliwe jest lepsze dostosowanie “produktu do klienta”, czyli ataku (phishingu) do użytkownika. Jeśli chwilę po skorzystaniu z bankowości internetowej pojawia się dialog z niej właśnie (a przynajmniej dialog, który wygląda, że pochodzi z niej), to istnieje szansa, że jakaś grupa użytkowników da się oszukać. Skuteczność takiego ataku może być wyższa, w stosunku do rozsyłanych mailem wiadomości.
A to, co jest w mediach, no cóż...
Oryginał tego wpisu dostępny jest pod adresem Abjn, fgenfman yhxn, oyn oyn oyn...
Autor: Paweł Goleń
Wspomniałem już temat (tajemniczej) płytki i umieszczenia jej powstania w czasie. Trochę jeszcze poszukałem na ten temat i okazuje się, że stosunkowo prosto można uzyskać dodatkowe informacje o dacie powstania płytki. Dokument Volume and File Structure of CDROM for Information Interchange zawiera opis formatu danych na płycie (właściwie jednego z formatów). W opisie struktury Volume Descriptor (konkretnie to Primary Volume Descriptor) znajduje się informacja o czterech znacznikach czasowych (format również wytłumaczony w dokumencie):
W przypadku tego formatu, wystarczy znaleźć odpowiedni deskryptor (zwykle w sektorze 16) i odczytać znaczniki czasu (offset podany w dokumencie). To tak w ramach ciekawostki.
Warto przeczytać: CWE/SANS TOP 25 Most Dangerous Programming Errors.