Atak na podpis elektroniczny przez zmianę formatu

2008-05-28 00:00:00 +0100

Rozszerzenie pliku determinuje sposób jego interpretacji przez odbiorcę, powinno być więc chronione wewnątrz podpisanej elektronicznie struktury - taka lekcja płynie z nowego ataku opublikowanego przez badaczy z włoskiego uniwersytetu Reggio Calabria. Informacja krąży w zainteresowanych kręgach od kilku tygodni, ale jako pierwsi napisali o niej Czesi w magazynie CryptoWorld.

Demonstracją ataku jest plik graficzny w formacie BMP, który zawiera jakiś tekst. Jednak wystarczy tylko zmienić rozszerzenie na HTML by plik wyświetlił tekst o zupełnie odmiennej treści. Jak to jest zrobione?

Tak się akurat składa, że w formacie BMP początek pliku stanowią dwa znaki ASCII (“BM”). Zaraz po nich w pliku występuje ciąg “<!–” mające różne znaczenie w zależności od tego, czy interpretujemy go jako HTML czy jako BMP. W tym pierwszym przypadku chroni on przed interptetacją bitmapę, która wyświetliłaby się jako śmieci w przeglądarce. Dla programu graficznego jest on ciągiem bajtów szesnastkowych, określających m.in. rozmiar nagłówka i tak dalej.

00000000 42 4d 3c 21 2d 2d ae 6c 07 00 3e 00 00 00 28 00 |BM<!--.l..>...(.| 00000010 00 00 76 06 00 00 23 09 00 00 01 00 01 00 00 00 |..v...#.........| ... 00076ca0 ff ff ff ff ff ff ff ff ff ff ff ff fc 01 2d 2d |..............--| 00076cb0 3e 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64 |><html>....<head|

W sensie technicznym Włosi nie odkryli nic nowego, bo już w latach 90-tych programiści urządzali konkursy polegające np. na napisaniu programu wykonywalnego zawierającego tylko drukowalne znaki ASCII - i wtedy taki plik z rozszerzeniem TXT można było np. wydrukować, a po zmianie na COM - uruchomić. Nowe jest odniesienie tego do podpisu elektronicznego jako metody manipulacji.

Ryzyko dla podpisującego zależy od formatu podpisu, a w szczególności czy nazwa podpisanej treści jest atrybutem chronionym czy nie. I to jest tutaj kluczowe, bo warunkiem powodzenia ataku jest możliwość późniejszej zmiany nazwy pliku zachowanej w podpisanym kontenerze. Standard PKCS#7 na który tutaj się powołują autorzy dokumentu o ile wiem nie przechowuje nazwy pliku w środku (chyba że za pomocą prywatnych rozszerzeń jakiejś implementacji). Przyjęta praktyka jest taka, że jak plik nazywa się TEST.BMP.P7M to po weryfikacji zapisujemy go do TEST.BMP. Ponieważ nazwa pliku nie jest chroniona, więc taki atak jest możliwy.

W każdym przypadku jest to natomiast dobry argument przeciwko podpisywaniu danych w formie ciągu bitowego niezrozumiałego dla SCA, w odróżnieniu od podpisu struktury danych zrozumiałej dla SCA. Jeśli już, to należy albo zastosować jeszcze jeden wewnętrzny kontener, który będzie zawsze tak samo interpretowany przez obie strony, niezależnie od nazwy, albo skorzystać z formatu, który przechowuje typ pliku.

Pierwsze rozwiązanie zastosowało Certum w swoim Delivery Authority - zrobili to w ten sposób, że plik oryginalny - dowolnego typu i rozszerzenia - jest zawsze pakowany w archiwum ZIP. Przy weryfikacji plik jest zawsze zapisywany z rozszerzeniem ZIP, niezależnie od rozszerzenia kontenera. A z ZIPa każdy sobie wypakowuje to co tam było oryginalnie. I nazwa oryginalnego pliku jest chroniona, i wynikowe rozszerzenie jest przewidywalne. Podobne rozwiązanie zostało zastosowane w Słowacji i to na poziomie rozporządzenia.

Formatem, który może chronić typ pliku jest natomiast XAdES - służy do tego atrybut DataObjectFormat. Podobne atrybuty definiuje również CMS. Warto zauważyć, że problem nie dotyczy tylko formatów podpisu - nieprzypadkowo atrybut SignatureAlgorithm w certyfikacie X.509 jest zdublowany na zewnątrz struktury tbsCertificate, jak i wewnątrz niej.

Niezależnie od profilaktyki przypuszczam, że taki podpis można łatwo obalić przed sądem. Każdy kompetentny biegły powinien z łatwością wykazać, że plik był skonstruowany w celu oszukania podpisującego. Cały materiał dowodowy jest na miejscu, wystarczy go podejrzeć hexedytorem.

Bibliografia