W dzisiejszym artykule opiszemy, na czym polega podatność XXE oraz jak można było ją wykorzystać w przypadku niedawno odkrytego błędu w Microsoft SharePoint (instancje w chmurze i on-prem).
Co to jest XXE injection?
XXE injection, inaczej wstrzyknięcie zewnętrznej jednostki XML (XXE), to luka w zabezpieczeniach, która umożliwia ugrupowaniu zagrażającemu wstrzyknięcie niebezpiecznych jednostek XML do aplikacji internetowej przetwarzającej dane XML. Podmioty zagrażające, którym uda się wykorzystać luki XXE, mogą wchodzić w interakcję z systemami, do których aplikacja może uzyskać dostęp, przeglądać pliki na serwerze, a w niektórych przypadkach zdalnie wykonywać kod (RCE).
Luki XXE spowodowane są przez nieaktualne lub niepoprawnie skonfigurowane parsery XML. Teoretycznie można temu łatwo zapobiec, ustawiając konfigurację analizatora składni XML tak, aby nie zezwalała na niestandardowe definicje typów dokumentów (DTD).
Jednak w praktyce aplikacje internetowe mogą mieć dużą liczbę komponentów, z których każdy może zawierać parser XML. Trudno jest określić, które części aplikacji przetwarzają XML, a w niektórych przypadkach właściciele aplikacji nie mają dostępu do konfiguracji parsera XML używanego przez określone komponenty.
Jakie konsekwencje dla firm niosą podatności XXE?
Typowe konsekwencje ataków XXE:
- Ujawnianie plików lokalnych — ugrupowania zagrażające mogą ujawniać pliki zawierające wrażliwe dane, takie jak hasła, korzystając ze schematów plików lub ścieżek względnych w identyfikatorze systemu.
- Rozszerzanie ataku – ataki XXE opierają się na aplikacji przetwarzającej dokument XML. Podmioty zagrażające mogą używać tej zaufanej aplikacji do przenoszenia się do różnych systemów wewnętrznych.
- Zdalne wykonanie kodu — jeżeli biblioteka procesora XML jest podatna na uszkodzenie pamięci po stronie klienta, osoba zagrażająca może wyłuskać złośliwy identyfikator URI, aby umożliwić wykonanie dowolnego kodu z poziomu konta aplikacji.
- Wpływ na dostępność aplikacji — niektóre ataki XML mogą umożliwić aktorom dostęp do zasobów lokalnych, które nie powstrzymują zwracania danych. jeżeli nie zostanie zwolnionych zbyt wiele procesów lub wątków, może to negatywnie wpłynąć na dostępność aplikacji.
Jeśli powyższy opis jest dla Ciebie trochę zawiły, zaraz pokażemy wykorzystanie podatności na przykładzie załatanej niedawno podatności w Microsoft SharePoint.
Przykład ataku XXE na podstawie podatności CVE-2024-30043 w MS SharePoint
14 maja br. Microsoft ogłosił, iż załatał nową podatność – CVE-2024-30043 XXE (XML eXternal Entity) która miała wpływać na SharePoint zarówno w instancjach lokalnych, jak i chmurowych. Odkrył ją i dokładnie opisał badacz Zero Day Initiative. Stopień ważności luki określono na 6,3 (średni).
Ponieważ luka ta jest bezpośrednio związania z XXE i może ją wykorzystać użytkownik o niskich uprawnieniach, można było narobić wiele złego u klientów.
Szczegóły CVE-2024-30043
W przypadku tej podatności powodem były błędy w pobieraniu i analizowaniu XML w elemencie BaseXmlDataSource, który jest klasą bazową dziedziczącą z DataSource.
Metoda Execute klasy BaseXmlDataSource akceptuje ciąg znaków o nazwie „żądanie”, który użytkownik może w pełni kontrolować. To żądanie wymaga adresu URL lub ścieżki prowadzącej do pliku XML, nazywanego przez badaczy „DataFile”.
Pomyślne wykorzystanie tej luki umożliwia ugrupowaniu zagrażającemu:
- odczytywanie plików za zgodą konta usługi SharePoint Farm,
- przeprowadzanie ataków SSRF,
- przekazywanie NTLM
i wykonywanie wszelkich innych dodatkowych ataków, które może prowadzić XXE, w tym zdalne wykonanie kodu.
W momencie pobierania pliku XML parametr this.FetchData akceptuje adres URL, który jest przesłany przez użytkownika jako argument wejściowy.
FetchData jest zaimplementowany w trzech klasach: SoapDataSource (wykonuje żądanie HTTP SOAP), XmlUrlDatasource (wykonuje dostosowywalne żądanie HTTP) i SPXmlDataSource (pobiera istniejący określony plik w witrynie SharePoint).
Cała analiza XML odbywa się natomiast za pośrednictwem xmlReaderSettings.DtdProcessing, dla którego ustawiono wartość DtdProcessing.Prohibit, aby wyłączyć przetwarzanie DTD (definicje typów dokumentów).
Ponadto xmlTextReader.XmlResolver jest ustawiony na świeżo utworzony XmlSecureResolver.
Podczas tworzenia XmlSecureResolver ciąg żądania jest przekazywany przez parametr securityUrl. Treść żądania odczytywana jest dzięki pętli while-do.
Chociaż konfiguracja ta wydawała się bezpieczna, później odkryto, iż nie wykonano żadnego żądania HTTP i zgłoszony został wyjątek przetwarzania DTD.
Zaskakującym faktem jest to, iż ładunek zostaje wykonany poprzez żądanie HTTP, które zostało najpierw odczytane przez XmlReader, gdy XmlReaderSettings.DtdProcessing jest ustawione na Prohibit, a także jest aktywne An XmlTextReader.XmlResolve.
Źródło: ZDIDemo z POC
Cały atak możesz zobaczyć na poniższym nagraniu.
Powód wykonania ładunku
Funkcja rozpoznawania nazw zawsze będzie najpierw próbowała obsłużyć jednostki parametrów, a dopiero potem przeprowadzana będzie kontrola zakazu DTD, dzięki czemu na końcu zostaje zgłoszony wyjątek. Jednak umożliwia przez cały czas wykorzystanie Out-of-Band XXE i potencjalną ekstrakcję danych ze złośliwie spreparowanym ładunkiem.
Microsoft załatał tę lukę w aktualizacjach Patch Tuesday w maju 2024 r.
Zgodnie z łatką wydaną przez Microsoft zaimplementowano większą kontrolę analizowania adresów URL dla SpXmlDataSource, a obiekt XmlTextReader zabrania również używania DTD.
