Paweł Goleń, blog

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óż...

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):

• Volume Creation Date and Time,
• Volume Modification Date and Time,
• Volume Expiration Date and Time,
• Volume Effective Date and Time,

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.