HARD CORE SECURITY LAB

Microsoft przyznał w końcu, że aplikacje webowe stworzone przy pomocy praktycznie dowolnej wersji środowiska ASP.NET są podatne na atak typu Padding Oracle. Oznacza to, że w zależności od konkretnej aplikacji, intruzowi może udać się przykładowo uzyskanie dostępu  do zawartości zaszyfrowanych ciasteczek i innych danych sesyjnych. Około 25% wszystkich aplikacji webowych bazuje na ASP.NET, w związku z czym skala problemu jest ogromna. Zobaczmy więc, jak w praktyce może wyglądać sam atak i w jaki sposób administratorzy mogą się przed nim na chwilę obecną zabezpieczyć.

Problemem wynika ze sposobu, w jaki popularny framework szyfruje newralgiczne dane. Chodzi o wadliwe zastosowanie algorytmu szyfrowania w trybie CBC (ang. Cipher Block Chaining). Tryb ten jest podatny na ataki Padding Oracle, które bez znajomości klucza pozwalają na odczytanie zaszyfrowanych danych.

Warto nadmienić, że sama nazwa ataku może być nieco myląca, gdyż nie ma on zupełnie nic wspólnego z jakąkolwiek bazą danych Oracle lub systemem zarządzania bazą danych Oracle. Metoda ataku polega w skrócie na wprowadzaniu niewielkich modyfikacji do zaszyfrowanych informacji, wielokrotnym powtarzaniu żądań przesyłanych do serwera i odkrywaniu kolejnych fragmentów tekstu jawnego na podstawie zaobserwowanych reakcji (komunikatów o błędach) serwera. Dwaj badacze (Juliano Rizzo, Thai Duong) już jakiś czas temu zaprezentowali narzędzie (POET, czyli Padding Oracle Exploitation Tool) pozwalające na przeprowadzanie praktycznych ataków. Oto przykładowy atak krok po kroku na webaplikację ASP.NET z wykorzystaniem właśnie narzędzia POET:

W powyższym przykładzie POET umożliwił intruzowi zdalne wydobycie klucza, który następnie posłużył do wygenerowania ciasteczka pozwalającego na uzyskanie uprawnień administratora. Taki scenariusz ataku wymaga jednak pewnej określonej konfiguracji docelowego systemu:

• customErrors mode="Off"

Typowy atak na ASP.NET pozwoli natomiast intruzowi w ciągu kilku lub góra kilkudziesięciu minut odszyfrować dane sesyjne przesyłane do klienta, które mogą przykładowo zawierać hasła użytkowników. Teoretyczne zagrożenie jest poważne, warto jednak podkreślić, że niezbędne jest w takim przypadku przechwycenie samych zaszyfrowanych danych. W niektórych przypadkach intruz będzie również w stanie uzyskać dostęp do plików znajdujących się na serwerze (np. pliku potencjalnie interesującego pliku web.config).

O ile całkowite wyeliminowanie podatności na atak typu Padding Oracle będzie pewnie wymagało wprowadzenia zmian w sposobie szyfrowania danych przez środowisko ASP.NET, o tyle na chwilę obecną możliwe jest już zastosowanie pewnych tymczasowych środków ochronnych. Ponieważ do przeprowadzenia skutecznego ataku niezbędne jest rozróżnienie komunikatów o poszczególnych błędach serwera, skonfigurowanie jednolitej odpowiedzi całkowicie uniemożliwi potencjalnemu intruzowi wykonanie skutecznego ataku. Szczegółowe instrukcje pozwalające na zabezpieczenie ASP.NET w wersjach od 1.0 do 4.0 oraz odnalezienie wszystkich webaplikacji podatnych na tak, można znaleźć pod tym adresem.