Przewodnik po zabezpieczeniach elementu BinaryFormatter

Ten artykuł dotyczy następujących implementacji .NET:

  • .NET Framework wszystkich wersji
  • .NET Core 2.1–3.1
  • .NET 5.0 i nowsze

Tło

Ostrzeżenie

Typ BinaryFormatter jest niebezpieczny i nie jest zalecany do przetwarzania danych. Aplikacje powinny przestać korzystać tak szybko, jak to możliwe, nawet jeśli uważa, że przetwarzane przez nie dane BinaryFormatter są wiarygodne. BinaryFormatter jest niezabezpieczony i nie można go zabezpieczyć.

Ten artykuł dotyczy również następujących typów:

Luki w zabezpieczeniach deserializacji są kategorią zagrożeń, w której ładunki żądań są przetwarzane w sposób niezabezpieczone. Osoba atakująca, która pomyślnie wykorzystuje te luki w zabezpieczeniach aplikacji, może spowodować odmowę usługi (DoS), ujawnienie informacji lub zdalne wykonywanie kodu w aplikacji docelowej. Ta kategoria ryzyka stale sprawia, że OWASP Top 10. Cele obejmują aplikacje napisane w różnych językach,w tym C/C++, Java i C#.

Na .NET największym celem ryzyka są aplikacje, które używają BinaryFormatter typu do deserializować dane. BinaryFormatter Jest powszechnie używany w całym ekosystemie .NET ze względu na jego możliwości i łatwość użycia. Jednak ta sama moc daje atakującemu możliwość wywierania wpływu na przepływ sterowania w aplikacji docelowej. Pomyślne ataki mogą spowodować, że osoba atakująca będzie mogła uruchomić kod w kontekście procesu docelowego.

Jako prostszą analogię załóżmy, że wywoływanie ładunku jest odpowiednikiem interpretacji tego ładunku jako autonomicznego pliku BinaryFormatter.Deserialize wykonywalnego i jego uruchomienia.

Luki w zabezpieczeniach programu BinaryFormatter

Ostrzeżenie

Metoda BinaryFormatter.Deserialize nigdy nie jest bezpieczna w przypadku korzystania z niezaufanych danych wejściowych. Zdecydowanie zalecamy, aby zamiast tego konsumenci rozważyli skorzystanie z jednej z alternatyw opisanych w dalszej części tego artykułu.

BinaryFormatter Przed wdrożeniem luk w zabezpieczeniach deserializacji były dobrze zrozumiałą kategorią zagrożeń. W związku z tym kod nie jest zgodne z nowoczesnymi najlepszymi rozwiązaniami. Metoda może służyć jako wektor dla osób atakujących do przeprowadzania ataków Deserialize DoS na korzystanie z aplikacji. Te ataki mogą spowodować brak reakcji aplikacji lub spowodować nieoczekiwane zakończenie procesu. Tej kategorii ataku nie można ograniczyć za pomocą przełącznika konfiguracji ani SerializationBinder żadnego innego BinaryFormatter przełącznika konfiguracji. Program .NET uznaje to zachowanie za zachowanie projektowe i nie będzie wydawać aktualizacji kodu w celu zmodyfikowania tego zachowania.

BinaryFormatter.Deserialize może być narażony na inne kategorie ataków, takie jak ujawnienie informacji lub zdalne wykonywanie kodu. Korzystanie z funkcji, takich jak niestandardowe, może SerializationBinder być niewystarczające do prawidłowego ograniczenia ryzyka. Istnieje możliwość, że zostanie wykryta nowa luka w zabezpieczeniach, dla której program .NET nie może praktycznie opublikować aktualizacji zabezpieczeń. Konsumenci powinni ocenić swoje indywidualne scenariusze i rozważyć ich potencjalne narażenie na te zagrożenia.

Zalecamy, aby BinaryFormatter konsumenci przeprowadzali indywidualne oceny ryzyka w swoich aplikacjach. To użytkownik ponosi wyłączną odpowiedzialność za określenie, czy korzystać z tej BinaryFormatter funkcji. Konsumenci powinni ryzykować ocenę wymagań dotyczących zabezpieczeń, technicznych, reputacji, prawnych i prawnych dotyczących korzystania z usługi BinaryFormatter .

Preferowane alternatywy

.NET oferuje kilka serializatorów skrzynkowych, które mogą bezpiecznie obsługiwać niezaufane dane:

Niebezpieczne alternatywy

Unikaj następujących serializatorów:

Wszystkie poprzednie serializatory wykonują nieograniczoną deserializację polimorficzną i są niebezpieczne, podobnie jak BinaryFormatter .

Ryzyko związane z założeniem, że dane są wiarygodne

Często deweloper aplikacji może uważać, że przetwarza tylko zaufane dane wejściowe. W niektórych rzadkich przypadkach bezpieczny przypadek wejściowy ma wartość true. Jednak znacznie częściej ładunek przekracza granicę zaufania, a deweloper nie zda sobie z tego sprawę.

Rozważ użycie serwera w sytuacji, gdy pracownicy korzystają z klienta stacjonarnego ze swoich stacji roboczych w celu interakcji z usługą. Ten scenariusz może być postrzegany jako "bezpieczna" konfiguracja, w której użycie BinaryFormatter jest dopuszczalne. Jednak ten scenariusz przedstawia wektor dla złośliwego oprogramowania, które uzyskuje dostęp do komputera pojedynczego pracownika, aby można było go rozpowszechniać w całym przedsiębiorstwie. To złośliwe oprogramowanie może wykorzystać użycie usługi przez przedsiębiorstwo do przechodzenia z stacji roboczej pracownika na BinaryFormatter serwer zaplecza. Może on następnie ekspfiltrować poufne dane firmy. Takie dane mogą obejmować tajemnice handlowe lub dane klientów.

Rozważ również aplikację, która używa funkcji BinaryFormatter do utrwalania stanu zapisywania. Na początku może to wydawać się bezpiecznym scenariuszem, ponieważ odczytywanie i zapisywanie danych na własnym dysku twardym stanowi niewielkie zagrożenie. Udostępnianie dokumentów za pośrednictwem poczty e-mail lub Internetu jest jednak powszechne i większość użytkowników końcowych nie postrzega otwierania pobranych plików jako ryzykownych zachowań.

W tym scenariuszu można wykorzystać do niegodziwego efektu. Jeśli aplikacja jest gierą, użytkownicy, którzy współużytkują pliki zapisu, nieświadomie są na niebezpieczeństwo. Celem mogą być również sami deweloperzy. Osoba atakująca może wysłać wiadomość e-mail do pomocy technicznej deweloperów, dołączając złośliwy plik danych i prosząc personel pomocy technicznej o jego otwarcie. Ten rodzaj ataku może dać osobie atakującej przyczółek w przedsiębiorstwie.

Inny scenariusz polega na tym, że plik danych jest przechowywany w magazynie w chmurze i automatycznie synchronizowany między maszynami użytkownika. Osoba atakująca, która jest w stanie uzyskać dostęp do konta magazynu w chmurze, może zatruć plik danych. Ten plik danych zostanie automatycznie zsynchronizowany z maszynami użytkownika. Przy następnym otworze pliku danych zostanie uruchomiony ładunek osoby atakującej. W związku z tym osoba atakująca może wykorzystać naruszenia zabezpieczeń konta magazynu w chmurze w celu uzyskania pełnych uprawnień do wykonywania kodu.

Rozważmy aplikację, która przechodzi z modelu instalacji pulpitu do modelu opartego na chmurze. Ten scenariusz obejmuje aplikacje, które przejdą z aplikacji klasycznej lub rozbudowanych modeli klientów do modelu internetowego. Wszystkie modele zagrożeń rysowane dla aplikacji klasycznej nie muszą mieć zastosowania do usługi opartej na chmurze. Model zagrożeń dla aplikacji klasycznej może odrzucić dane zagrożenie jako "nie jest interesujące, aby klient zaatakował samego siebie". Jednak to samo zagrożenie może stać się interesujące, jeśli uzna, że użytkownik zdalny (klient) zaatakował samą usługę w chmurze.

Uwaga

Ogólnie rzecz biorąc, celem serializacji jest przesyłanie obiektu do lub z aplikacji. Ćwiczenie modelowania zagrożeń prawie zawsze oznacza ten rodzaj transferu danych jako przekroczenie granicy zaufania.

Dodatkowe zasoby