12:50
20/9/2010

Kilka dni temu ostrzegaliśmy przed atakiem na webaplikacje pisane w ASP.NET. Dziś znamy już szczegóły błędu, a Microsoft potwierdził zagrożenie. Poniżej prezentujemy jak zabezpieczyć się przed atakiem.

Atak na ASP.NET (demonstracja)

Błąd, tak jak pisaliśmy kilka dni temu, korzysta z tzw. wyroczni, czyli polega na wysyłaniu zaszyfrowanych zapytań do serwera i wyłapywaniu różnic w jego odpowiedziach — różne kody błędów świadczą o tym, czy serwer poprawnie rozszyfrował wiadomość. Na tej podstawie można wyciągnąć wnioski pozwalające odtworzyć poprawny klucz, używany przez ASP.NET do szyfrowania danych w trakcie sesji — ale nie tylko, atak pozwala także na dostęp do pliku web.config (który często zawiera interesujące z punktu widzenia atakującego dane).

Poniżej film obrazujący atak Padding Oracle:

Warto zauważyć, że aby atak się udał należy wykraść ciastka (co jest w większości przypadków nietrywialne). Dodatkowo, jeśli w ciastkach nie ma krytycznych z punktu widzenia bezpieczeństwa danych, to atak spali na panewce (a dobrego programistę poznasz po tym, że nie pcha do ciastek numerów kart kredytowych ;).

Przy okazji, trzymanie w ciasteczkach “superwrażliwych” danych, tylko dlatego, że “i tak je szyfrujemy”, to nie jest dobry pomysł — podstawowa zasada: nie ufaj danym pochodzącym od użytkownika. Nigdy.

Ochrona przed atakiem na ASP.NET

Aby uniemożliwić atak należy:

  • Włączyć <customErrors>
  • Skonfigurować serwer tak, aby w każdym przypadku, niezależnie od kodu błędu, zawsze zwracał (dokładnie) taką samą stronę błędu.

Poniżej przykład konfiguracji dla serwera ASP.NET V3.5 SP1 i 4.0

<configuration>
<system.web>
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
</system.web>
</configuration>

Plik error.aspx zawiera (stały) komunikat wyświetlany po napotkaniu dowolnego błędu — można do tego skryptu dodać element wprowadzający losowe opóźnienie wyświetlenia jego zawartości, gdyż w niektórych przypadkach, pewne błędy serwera mogą szybciej zwracać stronę błędu (a zatem mechanizm wyroczni dalej działa, por. Ataki czasowe na serwisy internetowe).

Jak jednak słusznie przypomina Paweł Goleń, powyższy skrypt może się na niewiele zdać. Z kolei Krzysiek Kotowicz w dyskusji z Pawłem wskazuje na ciekawe opracowanie dot. ataków czasowych.

ASP.NET

ASP.NET: clikc & hack?

Oficjalny komunikat Microsoftu dot. tej luki jest dostępny tutaj. Administratorzy mogą też pobrać skrypt vbs, który odpalony lokalnie na webserwerze wylistuje wszystkie webaplikacje podatne na ten atak. Idźcie i łatajcie się.


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

5 komentarzy

Dodaj komentarz
  1. ciekawe dlaczego wszyscy trabia o tym bugu, a CVE-2010-3301 nikogo nie interesuje? IMO priv. escalation w linuxie jest powazniejsze, niz umiejetnosc deszyfrowania juz przechwyconych ciasteczek :P

    • jurek: spoko, ten 12-letni bug ;p też mamy w draftach, poleci pewnie jeszcze dziś (poważny to on jest przede wszystkim na shared hostingach, ale tam pewnie się już połatali, no i w .edu).

  2. Dobra, mały offtopic: Co to za muzyka w tle, wie ktoś? Bardzo mi się spodobała. Z góry dzięki za odpowiedź.

  3. @Jurek: Bo to nie chodzi o umiejętność deszyfrowania już przechwyconych ciasteczek. Część frameworków korzysta z przechowywania stanu sesji lub innych danych związanych ze stanem aplikacji po stronie klienta. W części przypadków dane te są zabezpieczone przed tamperingiem, na przykład przy pomocy HMAC i opcjonalnie szyfrowania. Jeśli atakujący ma możliwość modyfikacji tych danych, to potencjalnie może taką aplikację rozjechać. Wiele tu zależy oczywiście od konstrukcji samej aplikacji.

    Jeszcze raz odwołam się do przykładu, który kiedyś udostępniłem:

    http://threats.pl/bezpieczenstwo-aplikacji-internetowych/wyzwanie-ii

    Jest w nim pokazanych kilka podatności, między innymi “śmieszny” sposób zarządzania sesją. Załóżmy teraz, że nauczony tym prostym przykładem dodaję do sesji sumę kontrolną, wspomniany HMAC. Jestem bezpieczny? Teoretycznie. Jeśli w kodzie umieszczę coś na zasadzie hmac1 == hmac2 gdzie hmac1 to ten otrzymany od klienta a hmac2 to “prawidłowy” wyliczony na podstawie otrzymanych od klienta danych i znanego przez serwer klucza, to mam potencjał na timing attack. W ten sposób znak po znaku MOGĘ ustalić to, JAK powinien wyglądać prawidłowy HMAC dla tych konkretnych danych, zmodyfikować dane sesji i stać się dla aplikacji kimś zupełnie innym.

    I szczerze mówiąc takich timing attack będzie pewnie więcej w przyszłości. Różnych. Bo operator porównania nie jest operacją atomową, zajmującą zawsze tyle samo czasu. Różnice w czasie wykonania operacji są niewielkie, ale są. Przykłady udanych ataków pokazują, że nawet stosunkowo niewielkie różnice są jednak wystarczające, a różne zaburzenia wprowadzane choćby przez losowe opóźnienie na poziomie sieci nie uniemożliwiają poprawnej ich identyfikacji i wykorzystania.

  4. @OkropNick: Naprawdę nie chce Ci się wejść na YouTube i zobaczyć, czy ktoś już o to nie spytał? 15 sekund pracy i masz: “Hey There Delilah by Plain White T’s”. Pozdrowienia!

Odpowiadasz na komentarz OkropNick

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: