Wyrocznia w ASP.NET

W mechanizmach kryptograficznych wykorzystywanych w ASP.NET wykryty został błąd. Microsoft opublikował stosowny dokument: Vulnerability in ASP.NET Could Allow Information Disclosure. Informacje na temat tej podatności są nieco chaotyczne, ale z kontekstu można przypuszczać, że pozwala ona nie tylko na rozszyfrowanie danych i ustalenie klucza, którym zostały zaszyfrowane.

Brzmi groźnie, bo jest to duży problem. W ASP.NET wykorzystywany jest między innymi __VIEWSTATE (patrz: Understanding ASP.NET View State), który jest ciekawym celem ataku. Nie chodzi nawet o ujawnienie danych, ale o możliwość ich modyfikacji.

Sposób zabezpieczenia __VIEWSTATE definiują parametry (patrz: pages Element (ASP.NET Settings Schema)):

Domyślnie __VIEWSTATE nie musi być szyfrowany, natomiast jest zabezpieczony przez HMAC. Z tego powodu dane, choć mogą być podglądnięte, nie mogą być modyfikowane. Z samym __VIEWSTATE było trochę problemów wcześniej. Warto wspomnieć o:

Tym razem atak pozwala na więcej. Po odzyskaniu klucza atakujący jest w stanie nie tylko odczytać dane, ale również je zmodyfikować. Dobrze opisuje to ten fragment z agendy (Padding oracles everywhere):

Finally we demonstrate the attacks against real world applications. We use the Padding Oracle attack to decrypt data and use CBC-R to encrypt our modifications. Then we abuse components present in every ASP.NET installation to forge authentication tickets and access applications with administration rights. (...)

A tu przykładowy atak:

Zastanawiam się jeszcze nad proponowanymi w dokumencie Microsoftu obejściami problemu. Dla .NET Framework 3.5 RTM i starszych zalecane jest ustawienie statycznej strony błędów, dla nowszych natomiast strony dynamicznej, która zawiera kod generujący losowe opóźnienie. Czy to oznacza, że w nowszych wersjach .NET Framework poza wskazówką w komunikacie błędu jest również potencjał na timing attack? Jest to dość istotna kwestia, bo wykorzystanie “standardowych” stron błędów, nie tylko w ASP.NET, jest zwyczajowo raportowane jako podatność. Przy okazji warto odgrzebać temat timing attacks na OpenID i OAuth: Ataki czasowe na OpenID i OAuth (Twitter, Digg i Wikipedia podatne na atak), oraz komentarz Gynvaela.

Jeśli ktoś nie bardzo jest w stanie sobie wyobrazić do czego może prowadzić możliwość modyfikacji danych, zapraszam do mojego starego przykładu: Lekcja 17: Wyzwanie II, a w szczególności do wyjaśnienia sposobu obsługi sesji.

UPDATE: Dobrze mi się wydawało, że jest potencjał na timing attack , świadczy o tym ten wpis:

error message setting is irrelevant. no error? there's always HTTP status. always the same HTTP status? there's always big timing different

ScotGu uważa jednak, że różnica w czasie przetwarzania żądania we wszystkich trzech przypadkach jest na tyle mała, że timing attack jest mało prawdopodobny. Zwłaszcza po dodaniu niewielkiego losowego opóźnienia. Dalej nie rozumiem, dlaczego w przykładach losowe opóźnienie zalecane jest w nowszych wersjach .NET Framework, a w starszych “wystarczy” statyczna strona błędu.

Oryginał tego wpisu dostępny jest pod adresem Wyrocznia w ASP.NET

Autor: Paweł Goleń