Krytyczna luka RCE w SharePoint wykorzystywana do kradzieży machine keys - Security Bez Tabu

Krytyczna luka RCE w SharePoint wykorzystywana do kradzieży machine keys

Cybersecurity news

Wprowadzenie do problemu / definicja

W lokalnych wdrożeniach Microsoft SharePoint wykryto krytyczną podatność oznaczoną jako CVE-2026-50522, która umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Zagrożenie ma szczególnie wysoki priorytet, ponieważ w obserwowanych atakach celem nie jest wyłącznie jednorazowe przejęcie serwera, ale także kradzież kluczy machine keys wykorzystywanych w procesach kryptograficznych i uwierzytelniających.

To sprawia, że incydent może wykraczać poza klasyczny scenariusz RCE. Po przejęciu takich sekretów napastnik może próbować generować wiarygodnie wyglądające tokeny i utrzymywać dostęp nawet po wdrożeniu poprawek bezpieczeństwa.

W skrócie

  • CVE-2026-50522 dotyczy lokalnych instalacji SharePoint.
  • Luka wynika z niebezpiecznej deserializacji niezaufanych danych.
  • Atak pozwala na zdalne wykonanie kodu bez logowania.
  • Po uzyskaniu dostępu napastnicy kradną machine keys.
  • Samo załatanie systemu może nie wystarczyć, jeśli środowisko zostało wcześniej naruszone.

Kontekst / historia

Podatność została opisana jako problem typu deserialization-of-untrusted-data prowadzący do zdalnego wykonania kodu przez sieć. Luka została usunięta w ramach lipcowych aktualizacji bezpieczeństwa Microsoftu, jednak jej znaczenie szybko wzrosło po publikacji publicznego proof-of-concept.

Badacze bezpieczeństwa niemal natychmiast zaobserwowali próby wykorzystania podatnych serwerów SharePoint. Z perspektywy operacyjnej potwierdza to znany schemat, w którym ujawnienie technicznych szczegółów i kodu demonstracyjnego znacząco skraca czas między publikacją podatności a realnymi atakami.

Dodatkowe sygnały telemetryczne sugerowały również, że podejrzana aktywność związana z wektorem deserializacji mogła pojawić się wcześniej, zanim luka została jednoznacznie powiązana z konkretnym numerem CVE. To oznacza, że część organizacji mogła zostać zaatakowana jeszcze przed wdrożeniem działań obronnych.

Analiza techniczna

Techniczny przebieg ataku koncentruje się na obsłudze tokenów federacyjnych w SharePoint. Publicznie opisany wariant wykorzystania obejmuje spreparowaną odpowiedź logowania WS-Federation kierowaną do endpointu /_trust/default.aspx. W takiej odpowiedzi przesyłany jest sfałszowany SecurityContextToken, zawierający złośliwy ładunek .NET oparty na mechanizmie BinaryFormatter.

Jeżeli podatny komponent przetworzy taki obiekt bez właściwej walidacji, dochodzi do wykonania dowolnego kodu na serwerze. To klasyczny przykład niebezpiecznej deserializacji, w której aplikacja traktuje dane dostarczone przez atakującego jako zaufaną strukturę możliwą do odtworzenia w pamięci procesu.

Najbardziej niebezpieczny etap następuje jednak po skutecznym RCE. Napastnicy koncentrują się na pozyskaniu machine keys, czyli kluczy wykorzystywanych przez ASP.NET i powiązane komponenty do podpisywania, walidacji i ochrony artefaktów uwierzytelniających. Ich przejęcie może umożliwić tworzenie poprawnie wyglądających tokenów tożsamości oraz podszywanie się pod legalnych użytkowników.

Z punktu widzenia obrony oznacza to przejście od incydentu podatności aplikacyjnej do naruszenia zaufania kryptograficznego. W takim scenariuszu nawet skuteczny patch management nie rozwiązuje problemu, jeśli wcześniej doszło do eksfiltracji sekretów.

Konsekwencje / ryzyko

Skutki udanego ataku mogą być bardzo poważne. Obejmują one pełną kompromitację serwera SharePoint, dostęp do dokumentów i zasobów organizacji, nadużycie uprawnień, a także możliwość dalszego ruchu bocznego w infrastrukturze.

Szczególnie istotne jest ryzyko trwałego utrzymania dostępu po stronie napastnika. W przeciwieństwie do klasycznych mechanizmów trwałości, takich jak webshelle czy zadania harmonogramu, nadużycie machine keys może być mniej widoczne i trudniejsze do wykrycia podczas rutynowej analizy.

Dla środowisk on-premises oznacza to również możliwość utraty zaufania do lokalnych mechanizmów tożsamości i federacji. W praktyce organizacja może zostać zmuszona do rotacji sekretów, przeglądu sesji i tokenów, wykonania analizy forensic oraz czasowego ograniczenia działania części usług.

Rekomendacje

Organizacje korzystające z lokalnych wdrożeń SharePoint powinny niezwłocznie wdrożyć najnowsze poprawki bezpieczeństwa. Należy jednak założyć, że sama aktualizacja może nie wystarczyć, jeśli podatny serwer był dostępny dla atakującego przed załataniem.

  • Zidentyfikować wszystkie instancje SharePoint on-premises narażone na CVE-2026-50522.
  • Natychmiast wdrożyć poprawki w środowiskach produkcyjnych, testowych i zapasowych.
  • Przeanalizować logi aplikacyjne, IIS i systemowe pod kątem nietypowych żądań do /_trust/default.aspx.
  • Zweryfikować nietypowe użycie WS-Federation i anomalii związanych z tokenami.
  • Sprawdzić, czy nie doszło do odczytu, eksportu lub użycia machine keys oraz innych sekretów aplikacyjnych.
  • Przeprowadzić rotację kluczy, poświadczeń i powiązanych sekretów w potencjalnie naruszonych systemach.
  • Przejrzeć aktywne sesje, konta uprzywilejowane i tokeny pod kątem nadużyć.
  • Skontrolować mechanizmy trwałości, w tym usługi, zadania harmonogramu oraz modyfikacje plików aplikacyjnych.
  • Włączyć rozszerzony monitoring EDR/XDR dla serwerów obsługujących SharePoint.
  • W razie podejrzenia wcześniejszej kompromitacji przeprowadzić pełną ocenę wpływu incydentu.

Dodatkowo warto ograniczyć ekspozycję systemów SharePoint do zaufanych segmentów sieci, wzmocnić segmentację administracyjną oraz monitorować wszystkie odstępstwa związane z uwierzytelnianiem federacyjnym. W środowiskach o podwyższonym ryzyku uzasadnione może być tymczasowe ograniczenie dostępu do wybranych usług do czasu zakończenia weryfikacji bezpieczeństwa.

Podsumowanie

CVE-2026-50522 pokazuje, że krytyczne luki RCE coraz częściej stanowią jedynie pierwszy etap bardziej złożonego łańcucha ataku. W tym przypadku kluczowym celem jest przejęcie machine keys, co może umożliwić długotrwałe nadużywanie zaufania kryptograficznego i podszywanie się pod użytkowników.

Dla zespołów bezpieczeństwa oznacza to konieczność potraktowania problemu nie tylko jako zadania z obszaru patch management, ale jako potencjalnego incydentu naruszenia tożsamości. Skuteczna reakcja wymaga równoczesnego załatania systemów, analizy śladów kompromitacji oraz rotacji sekretów tam, gdzie istnieje choćby podejrzenie wcześniejszego przejęcia.

Źródła