Wampiryczny blog

Dawno, dawno temu, jak jeszcze Firefox nazywał się Phoenix, praktycznie codziennie korzystałem z nowego nightly build, teraz nie mam już na to czasu. Dzisiaj pojawił się Firefox 3.5, zainstalowałem i... szczerze mówiąc w odbiorze "prawie zwykłego użytkownika" nie widzę żadnych różnic w stosunku do wersji 3.0, pomijając tradycyjny problem z niekompatybilnością niektórych z add-ons, między innymi słownik języka polskiego (przynajmniej w tej chwili).

W komentarzach do wpisu Protecting Against the Snatched Laptop Data Theft (Schneier on Security) jest kilka pomysłów na automatyczne blokowanie laptopa w sytuacji, gdy z pewną pomocą osób trzecich oddali się od właściciela w stanie włączonym. Poza metodami opartymi na wykrywaniu bezczynności użytkownika, są też inne pomysły, na przykład automatyczne blokowanie laptopa, gdy telefon komórkowy użytkownika zniknie z zasięgu Bluetooth albo wykorzystanie wbudowanej w większość modeli kamerki do wykrycia sytuacji, gdy (prawowity) użytkownik znika z "pola widzenia". Wszystko po to, by bronić się przed scenariuszem, w którym ktoś kradnie aktywnego laptopa i odzyskuje z niego dane pomimo wykorzystania mechanizmu szyfrowania całego dysku. Może to zrobić, ponieważ klucze kryptograficzne w trakcie działania systemu muszą być dostępne (co zwykle oznacza, że są w pamięci). Tu trzeba zauważyć, że proste zablokowanie konsoli nie będzie wystarczającym rozwiązaniem (system wciąż działa, klucze są dostępne), należałoby system wyłączyć lub przynajmniej posłać do "głębokiego snu".

Jakiś czas temu udostępniłem wyzwanie (http://bootcamp.threats.pl/lesson08/), które do tej pory przeszły chyba dwie osoby, a przynajmniej tylko te dwie osoby się tym chwalą. Tym razem udostępniam zmodyfikowaną wersję tego samego wyzwania (http://bootcamp.threats.pl/lesson11/), która implementuje (ale nie dokładnie, bardziej na zasadzie PoC) koncepcję opóźnienia przy kolejnych nieudanych próbach uwierzytelnienia, (patrz: O implementowaniu haseł).

Znów o hasłach, tym razem bardziej pod kątem implementacji mechanizmów uwierzytelniania w aplikacji (głównie w aplikacji internetowej).

Łamanie haseł staje się coraz bardziej wydajne. Co można zrobić, by upewnić się, że używane hasła są "dobre"?

Pojawiła się wersja beta Microsoft Security Essentials dostępna, jak na razie, dla ograniczonej liczby użytkowników. Choć z zasady nie używam antywirusa (rezydentnego), planuję przyjrzeć się temu produktowi, ale raczej dopiero wówczas, gdy wyjdzie z fazy beta. Nie ukrywam, że wiążę pewne nadzieje z twierdzeniem It is a lightweight (...), bo ociężałość "tradycyjnych" antywirusów mocno mnie do nich zniechęca. Swoją drogą ciekawe czy w dobie mody na green IT ktoś policzył koszty wynikające z używania antywirusa (dodatkowe obciążenie systemu, które przekłada się choćby na pobór prądu i wydzielanie ciepła), choć koszty dla środowiska wynikające z nieużywania antywirusów również mogą być wysokie - komputery będące częścią botnetów też raczej się nie nudzą...

Kilka dni temu pojawił się BackTrack 4 Pre Release, który można pobrać z remote-exploit.org. Szczerze mówiąc, choć zastąpiłem BT3 przez BT4 na moim pendrive, to nie miałem wiele okazji, by dokładniej przyglądnąć się zmianom, zresztą co do użyteczności LiveCD mam dość mieszane uczucia. Z tego, co udało mi się sprawdzić, wspieranych jest więcej kart sieciowych (między innymi karty w moich laptopach). Być może po dwóch latach odświeżę przewodnik o łamaniu WEP, choć w zasadzie tamten wpis wciąż spełnia swoją rolę - pokazuje, jak łatwe jest złamanie sieci wykorzystującej WEP. Muszę przyznać, że sytuacja trochę poprawiła się w tym czasie. Obecnie tylko dwie z ośmiu sieci, w których jestem zasięgu, korzystają z WEP, pozostałe z WPA (z wyjątkiem jednej gołej, wesołej i otwartej na nowe kontakty).

Od dłuższego czasu na mojej liście narzędzi znajduje się Mandiant Highlighter (patrz wpisy na blogu M-unition: Mandiant Highlighter v1.0, Highlighter v1.0.1 Released, Highlighter v1.1.1 Released). Narzędzie to, w dużym uproszczeniu, służy do wspomagania analizy plików tekstowych, na przykład wszelkiego rodzaju logów. W związku z przeprowadzką bloga i zmianami, które w nim wprowadzam, kilka rzeczy w logach sprawdzam i muszę przyznać, że Highlighter okazał się całkiem sympatycznym narzędziem, choć początkowo miałem pewne wątpliwości co do jego przydatności. Jednocześnie polecam forum Highlighter: Bug Reports, bo kilka uciążliwych błędów jednak jest.

Wczoraj pisałem o narzędziu Slowloris. Zastanawiam się, czy tej samej koncepcji nie da się zastosować w drugą stronę - do ataku na przeglądarkę klienta. Prawdopodobnie ilość równoległych połączeń, jakie przeglądarka może nawiązać, jest ograniczona (i nie chodzi mi tu o ograniczenia zapisane w RFC 2616), tak więc teoretycznie można skonstruować stronę, która wyczerpie całą pulę dostępnych dla przeglądarki połączeń, a to w rezultacie spowoduje, że żadna nowa strona nie będzie mogła zostać otwarta. Sens takiego scenariusza jest raczej dyskusyjny, choć w niektórych przypadkach atak taki mógłby być uciążliwy (np. fora pozwalające na wstawienie zewnętrznych obrazków).

Jak być może pamiętacie pisałem o problemie związanym z memory leak (Miałem memory leak). Poprzez blog Network Monitor przesłałem zapytanie, czy problem jest znany. Okazało się, że nie. Rozpoczął się proces diagnostyki błędu, przesłanie informacji o konfiguracji, sposobu odtworzenia błędu, (...). W końcu pojawiła się pytanie o możliwość wykonania memory dump i przesłania go do analizy. Niestety, musiałem odmówić.