Poprawka na tę lukę wyszła 14 lipca, razem z lipcowym zestawem aktualizacji Microsoftu. Prawie miesiąc później, 11 sierpnia, firma która lukę znalazła opublikowała szczegółową analizę wraz z działającym kodem. Dwa dni po tej publikacji firma prowadząca pułapki sieciowe zaraportowała, że napastnicy zaczęli tego kodu używać. Nie zmieniło się zagrożenie, tylko wysiłek potrzebny, żeby z niego skorzystać. Luka siedzi w SharePoincie instalowanym na własnych serwerach. Pozwala obcej osobie podać się za użytkownika, w tym za administratora, bez znajomości jakiegokolwiek hasła. Warto od razu dodać rzecz, którą gubi większość relacji: sam Microsoft do dziś nie potwierdził, że ktokolwiek tę lukę wykorzystał.
Na czym polega obejście logowania w SharePoincie
Producent nazywa to obejściem zabezpieczenia i tłumaczy skutek w jednym zdaniu. Obchodzone zabezpieczenie to uwierzytelnianie, ponieważ luka pozwala na podszycie się pod inną osobę. W opisie technicznym Microsoft dodaje, że w ataku prowadzonym przez sieć napastnik bez konta może ominąć logowanie i nawiązać anonimowe połączenie.
Sedno problemu leży w sprawdzaniu tokenów, czyli podpisanych elektronicznie przepustek, którymi serwer potwierdza tożsamość użytkownika. Rapid7 opisuje token z nagłówkiem alg: none, czyli z deklaracją, że podpisu nie ma. Samo pole podpisu nie jest przy tym puste, tylko SharePoint nigdy go nie weryfikuje. Do wskazania klucza wystarcza natomiast odcisk certyfikatu samego serwera.
Jedno ograniczenie warto znać, bo bez niego obraz wychodzi groźniejszy niż w rzeczywistości. Napastnik musi wcześniej znać identyfikator atakowanego użytkownika w firmowej usłudze katalogowej. Nie jest to bariera nie do pokonania, ale odróżnia ten atak od zwykłego pukania do drzwi.
Ocena luki wynosi 9,1 w dziesięciostopniowej skali, a Microsoft opatrzył ją etykietą krytyczna. Rozbicie noty tłumaczy producent sam i robi to precyzyjnie: skuteczny atak pozwala ujawnić pliki i zmienić dane, natomiast nie pozwala wpłynąć na dostępność systemu. Innymi słowy, chodzi o wykradzenie i podmianę zawartości, a nie o wyłączenie usługi.
Skąd wzięła się ta luka i dlaczego wybuchła dopiero teraz
Historia tej podatności jest podręcznikowym przykładem tego, jak proces zgłaszania błędów ma działać. Znalazł ją Stephen Fewer z firmy Rapid7, podczas zawodów hakerskich Pwn2Own w Berlinie. Firma zgłosiła rzecz Microsoftowi 18 maja. Poprawka wyszła 14 lipca, razem z comiesięcznym zestawem aktualizacji. Szczegółową analizę techniczną wraz z działającym kodem Rapid7 opublikował dopiero 11 sierpnia, czyli prawie miesiąc po udostępnieniu łatki.
Ten odstęp jest sednem sprawy i warto się przy nim zatrzymać. Między wydaniem poprawki a upublicznieniem gotowego kodu firmy miały cztery tygodnie na spokojne zaktualizowanie serwerów. Od 14 lipca publicznie znane były istnienie luki i opis producenta. Szczegółowa analiza techniczna z działającym kodem doszła dopiero 11 sierpnia. Zabrakło więc nie wiedzy, tylko presji, a presja pojawia się wtedy, gdy do wykorzystania luki nie trzeba już własnej pracy.
Widać w tym niewygodną prawidłowość, którą trudno zrzucić na badaczy. Instalacje niezałatane po 11 sierpnia miały tę samą podatność co 15 lipca. Publikacja kodu nie stworzyła luki, tylko obniżyła próg jej wykorzystania.
Kto mówi o atakach, a kto ich nie potwierdza
Tutaj zaczyna się część, którą warto rozłożyć na czynniki, bo trzy instytucje mówią trzema różnymi głosami. Nagłówki brzmią jednoznacznie, a dokumenty już nie.
O atakach informuje firma Defused, która prowadzi pułapki sieciowe, czyli serwery udające prawdziwe cele. Podała ona, że napastnicy używają opublikowanego kodu przeciwko jej pułapkom SharePointa. Jest to obserwacja pojedynczej firmy z jej własnej infrastruktury. Tak też należy ją traktować: jako wiarygodny sygnał, nie jako urzędowe potwierdzenie.
Microsoft mówi co innego, a raczej nie mówi nic nowego. W jego wpisie pole informujące o wykorzystaniu luki w atakach ma wartość “nie”, tak samo jak pole o ujawnieniu publicznym. Producent szacuje jedynie, że wykorzystanie jest bardziej prawdopodobne. Sprawdziliśmy to 15 sierpnia bezpośrednio w rejestrze Microsoftu i przy okazji wyszła rzecz istotna. Wpis nie był zmieniany od dnia publikacji, czyli od 14 lipca. Wartość “nie” nie jest więc przeoczeniem w świeżej aktualizacji, tylko stanem dokumentu, którego nikt od miesiąca nie ruszał.
Trzeci głos należy do amerykańskiej agencji CISA i jest najciekawszy. Luki nie było wtedy w katalogu podatności wykorzystywanych w atakach. Sprawdziliśmy to we własnoręcznie pobranym pliku z 14 sierpnia, liczącym 1665 pozycji. Cztery dni później to się zmieniło, o czym piszemy w aktualizacji niżej. W osobnej ocenie z 13 sierpnia agencja zapisała, że istnieje kod dowodzący, a nie że trwają ataki. Zaznaczyła przy tym, że atak da się zautomatyzować, a jego skutki techniczne są całkowite.
Dlaczego brak wpisu w katalogu też jest informacją
Różnicę widać najlepiej w zestawieniu. Przy innej luce z tego samego miesiąca, w narzędziu Langflow, ta sama agencja wpisała “aktywne wykorzystanie” i dołożyła pozycję do katalogu. Tutaj nie zrobiła ani jednego, ani drugiego. Katalog CISA bywa traktowany jako lista zadań na dziś i słusznie. Działa to jednak również w drugą stronę: skoro katalog rozróżnia te sytuacje, to brak wpisu też coś znaczy.
Praktyczny wniosek z tego rozjazdu wymaga jednego zastrzeżenia, bo łatwo go przekręcić. Brak wpisu w katalogu CISA i obecny status u Microsoftu nie potwierdzają aktywnego wykorzystania, ale też go nie wykluczają. To jest brak urzędowego potwierdzenia, a nie potwierdzenie braku ataków. Praktyczne zadanie wychodzi z tego jedno: pilnie sprawdzić numer kompilacji, zainstalować poprawkę i przejrzeć dzienniki serwerów dostępnych z internetu.
Warto przy tym pamiętać, że opisany stan jest stanem na 15 sierpnia i może się zmienić. Gdyby CISA dopisała tę lukę do katalogu, a Microsoft zmienił wartość pola o wykorzystaniu w atakach, byłby to sygnał innego kalibru niż relacja o ruchu na pułapkach jednej firmy. Oba dokumenty są publiczne i darmowe, więc sprawdzenie ich zajmuje minutę. To zresztą tańszy nawyk niż śledzenie nagłówków, bo pokazuje nie tylko, że coś się dzieje, ale też jak mocno instytucje są tego pewne.
Aktualizacja z 25 sierpnia. Warunek opisany wyżej spełnił się dokładnie w połowie. 18 sierpnia CISA dopisała tę lukę do katalogu podatności wykorzystywanych w atakach i wyznaczyła termin na 21 sierpnia, czyli trzy dni. To najkrótszy próg, jaki ten katalog stosuje wobec systemów wystawionych do internetu. Microsoft natomiast do dziś ma we wpisie wartość „nie” przy pytaniu o wykorzystanie w atakach, a sam dokument pozostaje nietknięty od 14 lipca. Rozjazd między obiema instytucjami nie zniknął, tylko się pogłębił. Co z niego wynika dla firm i dlaczego trzydniowy termin nie jest sygnałem wyjątkowej paniki, rozpisaliśmy w tekście o czterech lukach z terminem 21 sierpnia.
Pierwsza Misja AI · Kodożercy
Używasz AI codziennie, ale czy robisz to dobrze?
Kurs Pierwsza Misja AI pokaże Ci techniki promptowania, które naprawdę działają. Praktyczne ćwiczenia z prawdziwym modelem, gamifikacja i certyfikat.
Sprawdź program kursu →
Jak sprawdzić, czy wasza instalacja jest już załatana
Pierwsze pytanie brzmi, czy sprawa w ogóle was dotyczy, i tu odpowiedź jest krótka. Lista podatnych produktów obejmuje wyłącznie SharePointa instalowanego na własnych serwerach: edycję abonamentową, wersję 2019 oraz Enterprise Server 2016. SharePointa w Microsoft 365 na tej liście nie ma.
Dalej wystarczy porównać numer kompilacji z wersją zawierającą poprawkę:
- edycja abonamentowa:
16.0.19725.20434, aktualizacja KB5002882 - SharePoint Server 2019:
16.0.10417.20175, aktualizacja KB5002883 - SharePoint Enterprise Server 2016:
16.0.5561.1001, aktualizacja KB5002891
Wszystko starsze od tych numerów jest podatne. Producent odpowiada przy tym na pytanie, które co roku wraca przy wersji z 2016 roku. Ta sama poprawka obsługuje SharePoint Server 2016 i Enterprise Server 2016, więc obie instalacje trzeba zaktualizować tak samo.
Została jeszcze jedna sprawa, o której łatwo zapomnieć przy załatanym serwerze. Poprawka zamyka wejście, natomiast nie cofa tego, co ktoś mógł zrobić wcześniej. Serwer wystawiony do internetu i zaktualizowany dopiero teraz zasługuje na przejrzenie dzienników pod kątem nietypowych połączeń bez logowania. Ten sam nawyk opisywaliśmy przy wydaniu rsync zamykającym trzydzieści trzy błędy i wniosek jest identyczny w obu przypadkach.
Najczęstsze pytania
Czy luka dotyczy SharePointa w Microsoft 365?
Nie. Producent wymienia wyłącznie trzy produkty instalowane na własnych serwerach: edycję abonamentową, wersję 2019 i Enterprise Server 2016. Usługa w chmurze nie znalazła się na liście podatnych produktów. Nie zwalnia to nikogo z aktualizowania własnych instalacji, bo w wielu firmach obie rzeczy działają równolegle.
Czy publikacja kodu dowodzącego przez badaczy była błędem?
To spór starszy niż ta luka i nie ma w nim jednej odpowiedzi. Kod pojawił się prawie miesiąc po wydaniu poprawki, więc obrońcy mieli czas zareagować, a zespoły bezpieczeństwa dostały narzędzie do sprawdzenia własnych serwerów. Relacje o wykorzystywaniu tego kodu przeciwko pułapkom sieciowym pojawiły się dwa dni po publikacji. Wniosek dla firm jest praktyczny: okno między łatką a publicznym kodem to realny czas na działanie i szkoda go marnować.
Podsumowanie
Krytyczna luka w SharePoincie instalowanym na własnych serwerach pozwala obejść logowanie i podszyć się pod użytkownika, w tym administratora, bez znajomości hasła. Microsoft wydał poprawkę 14 lipca, a ocenił ją na 9,1 z etykietą krytyczna i wyjaśnił, że skuteczny atak prowadzi do ujawnienia plików i zmiany danych, ale nie do wyłączenia usługi. Hałas wokół sprawy zaczął się dopiero 11 sierpnia, po opublikowaniu przez odkrywcę analizy z działającym kodem. Warto przy tym trzymać się dokumentów zamiast nagłówków. O atakach mówi firma prowadząca pułapki sieciowe, producent ma we wpisie “nie” przy pytaniu o wykorzystanie, a agencja CISA zapisała istnienie kodu dowodzącego i nie dodała luki do swojego katalogu. Zadanie dla zespołu jest niezależne od tego sporu. Sprowadza się do porównania numeru kompilacji z wersją zawierającą poprawkę, a przy serwerze widocznym z internetu także do przejrzenia dzienników.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
