Windows

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ć?

Tym razem kontynuacja wpisu (Prawie) każde szyfrowanie można złamać, która dotyczy śladów, jakie pozostawiają w systemie Windows narzędzia do szyfrowania. Konkretnie dwa: TrueCrypt oraz FreeOTFE, przy czym w przypadku FreeOTFE skupię się na FreeOTFE Explorer. W obu przypadkach skupię się na kontenerach, a nie szyfrowaniu dysków.

Analiza plików zawartych w katalogu Prefetch pozwala na ustalenie jakie programy były uruchamiane w systemie, kiedy były uruchomione pierwszy, a kiedy ostatni raz. Pojawiło się ostatnio ciekawe narzędzie wspomagające analizę zawartości katalogu Prefetch: WinPrefetchView. Pozwala ono uzyskać nieco więcej informacji, niż jest to możliwe przy pomocy Windows File Analyzer. To tak w ramach ciekawostki :)

Na blogu Security Research & Defense pojawił się ciekawy wpis: Reports of DEP being bypassed. Informacja, że jest możliwe stworzenie exploita, który zadziała pomimo włączenia DEP jest ciekawa, choć nie zaskakująca. Nie jest zaskakująca w tym sensie, że DEP jest kolejną linią obrony, ale nie 100% skuteczną. Dlatego jest uzupełniany choćby przez ASLR w Windows Vista i Windows 7.

We wspomnianym wpisie najciekawsza jest tabela, która pokazuje skutki podatności w zależności od wykorzystanej wersji przeglądarki i wykorzystanego systemu operacyjnego. Zwracam uwagę na skuteczność ASLR oraz ograniczenia skutków exploita poprzez protected mode.

Mądrości ludowe mają to do siebie, że często rozmijają się z rzeczywistością. Jedna z takich mądrości, która wraca przy każdym błędzie w Internet Explorer jest "zalecenie", by nie używać tej przeglądarki. Ja do korzystania z Internet Explorer nikogo zachęcać nie zamierzam, sam korzystam z Firefox. Nie podoba mi się natomiast przeświadczenie, że używanie innej niż Internet Explorer przeglądarki zapewnia bezpieczeństwo.

Nie będę się rozpisywał na temat tego, jak Google zostało skutecznie zaatakowane przy pomocy nowego błędu w Internet Explorer (CVE-2010-0249). Jeśli ktoś ma ochotę poczytać na ten temat, może zrobić to na przykład tu: Techniczne szczegóły ataku na Google. Ja tylko jeszcze raz chciałem podkreślić, że napisanie absolutnie bezpiecznej przeglądarki jest praktycznie niemożliwe. Dlatego należy stosować tak wiele środków zaradczych, jak to jest tylko możliwe. Wówczas jest szansa, że skutki wykorzystania podatności będą ograniczone.

Irytują mnie różne rzeczy. Między innymi występujący od czasu do czasu błąd 0x80072efd. Tym razem Microsoft Security Essentials nie jest w stanie pobrać aktualizacji z powodu tego właśnie błędu, ale czasami również Windows Update nie jest w stanie pobrać aktualizacji. Cóż, trzeba się przyjrzeć co właściwie się dzieje... Szybki rzut okiem na to, co się dzieje na kablu (Wireshark) i już wszystko jasne. Przepełnił mi się /var na obszczymurku, przez co squid się złożył (brak miejsca na logi), komputer nie może nawiązać połączenia z proxy, stąd błąd 0x80072efd. Głupie jest natomiast to, że nie korzysta z drugiej w kolejności opcji (konfiguracja proxy przez WPAD), czyli nie wykorzystuje połączeń bezpośrednich. Ech...

W ostatnim czasie pojawiły się dwie informacje dotyczące ataków mechanizm BitLocker. Pierwsza z nich to to w zasadzie informacja prasowa Passware Software Cracks BitLocker Encryption Open. Metoda ta opiera się na odzyskaniu klucza wykorzystywanego do szyfrowania danych z pamięci systemu. Jak do pamięci uzyskać dostęp, to zupełnie oddzielna (i ciekawa) kwestia. Nie jest to bynajmniej technika nowatorska, wystarczy wspomnieć o pracy/badaniu Lest We Remember: Cold Boot Attacks on Encryption Keys.

Druga wiadomość to praca Attacking the BitLocker Boot Process, która doczekała się na przykład takiego "streszczenia": Złamano szyfrowanie w Windows, albo: BitLocker złamany. Szkoda tylko, że w samym dokumencie znajduje się następujący fragment:

(...) We show that, under certain assumptions, a dedicated attacker can circumvent the protection and break confidentiality with limited effort. Our attacks neither exploit vulnerabilities in the encryption itself nor do they directly attack the TPM. They rather exploit sequences of actions that Trusted Computing fails to prevent, demonstrating limitations of the technology.

Na zakończenie odeślę do wpisu Windows BitLocker Claims poświęconemu obu przypadkom/scenariuszom ataków na mechanizm BitLocker. Po prostu są scenariusze, w których (nie tylko) BitLocker sobie nie radzi. Wątpliwości? Evil Maid goes after TrueCrypt!

Taka już to rola człowieka znającego się na komputerach, że świadczyć musi wsparcie dla krewnych i znajomych. Mnie udało się krąg wspieranych osób zawęzić a postępując według zasady "dać wędkę zamiast ryby" kilku rzeczy owych ludzi również nauczyć. Mam jednak głęboką awersję do problemów niepowtarzalnych. Albo inaczej - powtarzalnych (bo się powtarzają), ale ciężkich do odtworzenia.

Postanowiłem nieco rozwinąć temat sandboxa i sensowności tego typu rozwiązania w przypadku przeglądarek internetowych. Bezpośrednią inspiracją jest ten komentarz.