8.3
Załóżmy, że w wyniku błędu w aplikacji mamy możliwość odczytu dowolnego pliku z serwera, pod warunkiem, że znamy jego nazwę (i oczywiście ścieżkę). Załóżmy, że serwer pracuje pod kontrolą systemu Windows, a aplikacja jest napisana w PHP. Załóżmy dodatkowo, że ciekawe dane znajdują się w sesji użytkownika i bardzo chcemy się do nich dostać.
Czym te “bardzo ciekawe dane” mogą być? Zależy. Jednym z ciekawszych przypadków, które widziałem w ciągu ostatnich 12 miesięcy, była sytuacja, w której w sesji użytkownika był zapisywany jego login i hasło. Działo się tak, ponieważ aplikacja webowa pełniła właściwie tylko rolę GUI do WS, który to WS z kolei wymagał podania danych uwierzytelniających przy wywołaniu każdej metody. Możliwość masowego odczytywania danych zapisanych w sesji niewątpliwie w tym przypadku byłaby bardzo “owocna” dla atakującego.
To jak, damy radę się dostać do tych konfitur?
Dane sesji w aplikacji PHP w standardowym przypadku są przechowywane w plikach, zwykle w katalogu tymczasowym. Nazwa pliku zwykle wygląda następująco:
sess0d15521a02bf0819c109bda0e8e0bcb6 sess5b0a612ada3a04fa9b23139411240ce2 sessa81f5dddda7ea905c5228f808bc81854 sesse04f0445bb9b0e23a8728578b587966a sess_fa5923d6de032f7d7f48c6c9d350d9ef
Jak widać w nazwie pliku zawarty jest identyfikator sesji. Identyfikator sesji to (w tym przypadku) 128 bitów. Możemy zakładać, że po 2**64 próbach trafimy w coś. Możemy też próbować sposób generowania identyfikatora sesji i mamy pewne szanse powodzenia: Advisory: Weak RNG in PHP session ID generation leads to session hijacking.
Tu mała przerwa na poglądowy rysunek (po raz kolejny ten sam, ale pasuje wyjątkowo dobrze):
Teraz cofnijmy się w czasie do zamierzchłej(?) przeszłości, gdzie nazwa pliku składała się z ośmiu znaków nazwy i trzech znaków rozszerzenia. Rolę naszego wehikułu czasu pełni dir z parametrem /X:
2012-12-21 22:17 44 SESS0~1 sess0d15521a02bf0819c109bda0e8e0bcb6 2012-12-21 22:17 44 SESS5~1 sess5b0a612ada3a04fa9b23139411240ce2 2012-12-21 22:17 44 SESSA~1 sessa81f5dddda7ea905c5228f808bc81854 2012-12-21 22:17 44 SESSE~1 sesse04f0445bb9b0e23a8728578b587966a 2012-12-21 22:17 44 SESSF~1 sessfa5923d6de032f7d7f48c6c9d350d9ef
Nagle świat stał się prostszy. Przestrzeń możliwych nazw pliku została drastycznie zawężona. Oczywiście sprawa nie jest aż tak prosta, jak się może wydawać. Jeśli na serwerze jest dużo sesji, pojawiają się kolizje w nazwach pliku, wówczas krótka nazwa pliku jest trochę bardziej złożona, ale nie zmienia to faktu, że dużo łatwiejsza do przewidzenia.
Ten przykład trochę kojarzy mi się z głębokim ukryciem, które przez ten zapomniany już trochę mechanizm (krótkie nazwy plików) może się nagle okazać dużo mniej głębokie, niż w założeniu. Na przykład z GUID dzieje się coś takiego:
2012-12-21 22:31 042FD6~1 042fd6f8-064e-4c72-be2c-ccbdfd1965e6 2012-12-21 22:31 203373~1 20337392-47f8-443d-9938-3b563a7b87d3 2012-12-21 22:31 2F5EE6~1 2f5ee6e0-dc58-47f1-89f9-185678c2b433 2012-12-21 22:31 3DAA39~1 3daa3916-b1fa-4a07-9ecf-554fd19c7433 2012-12-21 22:31 531003~1 5310036d-a355-4103-bf6d-18f1f460f426 2012-12-21 22:31 881E82~1 881e82d0-898c-47b1-95df-0d6f807c5102 2012-12-21 22:31 92AE86~1 92ae861d-9a9d-495b-97d4-b8845b24b041 2012-12-21 22:31 962531~1 96253106-c31c-4f8f-825d-cd50662972f6 2012-12-21 22:31 C0B968~1 c0b96879-515e-4afe-a2d4-51116366e6b8 2012-12-21 22:31 C0EED5~1 c0eed5c4-449f-4a24-92e2-27d5d6d560bc
Tu warto wspomnieć, że za dawnych czasów jednym z zaleceń odnośnie hardeningu systemu Windows było wyłączanie automatycznego generowania krótkich nazw plików (np. ten dokument: Microsoft Windows NT 4.0 and Windows 98 Threat Mitigation Guide):
Attackers could use short file names to access data files and applications with long file names that would normally be difficult to locate. An attacker who has gained access to the file system could access data or execute applications.
Pasuje jak ulał do opisywanej sytuacji, prawda?
Łapki w górę, kto jeszcze pamiętał o krótkich nazwach plików w Windows?
Oryginał tego wpisu dostępny jest pod adresem 8.3
Autor: Paweł Goleń