https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:14:36 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#c2880 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=919 nospam@example.com (Tadek Wójcik) "...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? " Dla .NET w wersjach 1.0 do 3.5, również można użyć dynamicznej strony błędów (.aspx'a) jednakże nic nie możemy poradzić na timing attack, ponieważ w sytuacji zaistnienia błędu na serwerze (np. wyjątku CryptographicException ) zawsze następuje przekierowanie(redirect 302) na stronę błędu więc atakujący jest w stanie zmierzyć czas wykonania pierwotnego requestu przed redirectem i nic z tym nie możemy zrobić. Jednakże od .NET 3.5 sp1 istnieje możliwość pokazania dowolnej strony błędu (dynamicznej czy statycznej) bez redirect'a .Dodając do takiej strony błędu skrypt generujący losowe opóźnienia skutecznie minimalizujemy szansę na skuteczny timing attack. Najważniejsze jednak jest to, żeby zawsze zwracać jedną, tą samą stronę błędu, niezależnie od rodzaju (kodu) tego błędu . Tue, 21 Sep 2010 19:04:32 +0200 https://archive.mroczna-zaloga.org/archives/919-guid.html#c2880 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#c2875 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=919 nospam@example.com (Paweł Goleń) Ja to wszystko rozumiem. Mam jednak taką naturę, że tego typu rzeczy wolę namacalnie sprawdzić. I chyba niestety będę musiał w przyszłości trochę bardziej zaawansowanych narzędzi statystycznych zapoznać. Bo z takich danych (średnia z 1000000 próbek) wiele się nie wyciągnie: 44, 45, 44, 44, 44, 44, 45, 45, 45, 45. Mon, 20 Sep 2010 08:49:05 +0200 https://archive.mroczna-zaloga.org/archives/919-guid.html#c2875 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#c2874 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=919 nospam@example.com (Krzysztof Kotowicz) Moim zdaniem na pewno. Skoro udało się wykrywać przez Internet różnice w porównywaniu tekstów (czy różnice są na początku, czy trochę dalej) - http://groups.google.com/group/keyczar-discuss/browse_thread/thread/5571eca0948b2a13 - to tym bardziej można wykryć czasochłonny proces walidacji danych dokonywany przez aplikację (coś w rodzaju - mam ciastko, ale nie powodzi mi się jego deserializacja). Jeśli ktoś uważa, że za dużo opóźnień wprowadza sam Internet - polecam http://rdist.root.org/2010/01/07/timing-independent-array-comparison/ Mon, 20 Sep 2010 02:58:10 +0200 https://archive.mroczna-zaloga.org/archives/919-guid.html#c2874 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#c2871 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=919 nospam@example.com (Paweł Goleń) Rozumiem to w ten sam sposób. Zresztą dodałem update do treści. Zastanawiam się jednak, czy różnica w czasie jest na tyle istotna, by móc się na niej w wiarygodny sposób oprzeć, uwzględniając przy tym opóźnienia wprowadzane na przykład w trakcie transmisji. Przykład z OpenID i OAuth pokazał, że taka możliwość istnieje. Ciekawe, czy również w tym przypadku. Sun, 19 Sep 2010 15:21:11 +0200 https://archive.mroczna-zaloga.org/archives/919-guid.html#c2871 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#c2870 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=919 nospam@example.com (Krzysztof Kotowicz) Wracając do timingu - ja rozumiem to tak, że nawet gdyby aplikacja zwracała taki sam rezultat (response code, treść) w obydwu przypadkach, to zostaje problem z timingiem, bo framework w przypadku niezgadzającego się paddingu rzuci exception wcześniej (kontrola paddingu odbywa się przy deszyfracji a przed walidacją, która należy już do logiki samej aplikacji). Sun, 19 Sep 2010 15:15:13 +0200 https://archive.mroczna-zaloga.org/archives/919-guid.html#c2870 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#c2869 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=919 nospam@example.com (Paweł Goleń) Szczerze mówiąc zamiast czasu patrzyłbym po pierwsze na zwracany kod HTTP (200 lub 500), a w przypadku kodu 200 - na zawartość strony. Nie pamiętam jaki kod HTTP jest zwracany, gdy ASP.NET ma skonfigurowane customErrors. Inna sprawa, że ja dziś coś ciężko kontaktuję, więc mogę nie dostrzegać czegoś istotnego... Druga sprawa - teoretycznie żądanie do ASP.NET może trafić na inny serwer (load balancing) i ten inny serwer musi być w stanie rozszyfrować otrzymane dane. Z tego co pamiętam w takim przypadku na wszystkich serwerach konfiguruje się te same klucze. A co do IV to jest szansa, że jest doklejany plaintextem na początku. Tak wynika z przykładu w tekście, który podałeś w linku. Sun, 19 Sep 2010 00:28:29 +0200 https://archive.mroczna-zaloga.org/archives/919-guid.html#c2869 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#c2868 https://archive.mroczna-zaloga.org/archives/919-wyrocznia-w-aspnet.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=919 nospam@example.com (Krzysztof Kotowicz) > Czy to oznacza, że w nowszych wersjach .NET Framework > poza wskazówką w komunikacie błędu jest również > potencjał na timing attack? Opierając się na informacjach z http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/ jest możliwość ataku timingowego - w przypadku, kiedy po deszyfracji (tryb CBC) framework nie wykryje odpowiedniego bajtu/bajtów z paddingiem w ostatnim bloku, rzuca wyjątek. Gdy bajt ma odpowiednią wartość, do danych dostaje się aplikacja (i po walidacji odrzuca śmieciowe dane), co dodaje swój narzut czasowy. Natomiast interesuje mnie co innego - w przytoczonym artykule jest informacja, że do zaszyfrowanych danych jest na początku doklejany plaintextem IV (co jest słabością wykorzystaną przez omawiane narzędzie). Czy tak rzeczywiście jest w ASP.NET? Czy w praktyce IV jest zmienny (jednorazowy) i przekazywany jawnie razem z ciphertextem, czy to tylko jakiś przykład konkretnej aplikacji? Ktoś zna mechanizm ASP.NETa pod tym kątem? Sat, 18 Sep 2010 23:24:53 +0200 https://archive.mroczna-zaloga.org/archives/919-guid.html#c2868