Windows Server: niedawno załatana dziura wreszcie zostaje zauważona

Wielu autorów specjalizujących się w bezpieczeństwie opisało sierpniowe aktualizacje jako mało spektakularne i typowe. Również na dobrychprogramach, po przejrzeniu bazy MSRC z dnia 11 sierpnia, doszliśmy do podobnych wniosków. Ot, jedna z aktualizacji dodaje logowanie zdarzeń NETLOGON w większą dokładnością. Zresztą sam Microsoft napisał, że jej wykorzystanie jest "mało prawdopodobne". Po kilku godzinach jednak, podatność CVE-2020-1472 uzyskała na portalu Microsoft Security Response Center swoją ocenę zagrożenia CVSS. Było nią 10, a więc "gorzej być nie może". Dokładnie tyle, ile otrzymał lipcowy DNS.

I tyle. Potem nic. Brak opublikowanych szerszych informacji na temat dziury, mimo wyceny CVSS 10, poskutkował osobliwą "ciszą w eterze". Gdy łatano DNS, gotowy był exploit: w momencie wydania aktualizacji, wydano także artykuł opisujący działanie luki. W przypadku CVE-2020-1472, nie było gotowca, a ocena CVSS pojawiła dopiero po kilku godzinach. Efekty są zabawne: przez cały sierpień pojawiło się tylko kilka wzmianek o owej podatności, a żadna nie opisywała jej jako coś mocnego.

Dopiero po pewnym czasie zaczęło się robić ciekawiej: coraz więcej osób zaczęło raportować, że Dziennika Zdarzeń Windows raportuje rzeczy wcześniej niewidoczne w logach: odmowy i pozwolenia żądań NETLOGON wywoływanych na niższym poziomie zabezpieczeń. Tak szczegółowe logi zaczęły się pojawiać dopiero po zainstalowaniu stosownych aktualizacji.

Milczenie przerwała w końcu Secura, publikując narzędzie umożliwiające zweryfikowanie, czy posiadany kontroler domeny jest "podatny" na zagrożenie CVE-2020-1472. Podatność ta oznacza możliwość nadpisania hasła komputera, a następnie zdobycia uprawnień administratora domeny, co oznacza przejęcie nad nią całkowitej kontroli. Obiecano także wydanie artykułu podsumowującego podatność, odsyłając jednocześnie do notatki Microsoftu.

Ta jednak (a w zasadzie kilka: problem jest na tyle rozległy, że opublikowano aż cztery notatki KB) okazała się być napisana naprawdę kiepsko. W skrócie, opisuje ona, że wraz z sierpniową aktualizacją, komunikacja NETLOGON podatna na nadużycia będzie logowana jako oddzielne zdarzenie "Systemowe" (a nie tylko sukces/niepowodzenie audytu w logu "Zabezpieczenia"). System zostanie też wzbogacony o funkcję zablokowania żądań wykorzystujących dziurawy protokół. Należy jej użyć celem przeprowadzenia testu: zaktualizowanie Windowsów w sieci usunie groźne zapytania, więc blokada nie powinna nic popsuć. A test jest potrzebny, bo od lutego... blokada będzie obowiązkowa.

Mierność notatki przejawia się w tym, że nie wynika z niej bezpośrednio, czy samo załatanie kontrolera domeny rozwiązuje problem. W zależności od akapitu, notatkę można zrozumieć na inny sposób. Nie jest jasne, czy aktualizacja dostarcza blokadę i włącza ją, czy trzeba ją włączyć samodzielnie. Wszystko wskazuje na to, że trzeba ją włączyć, bowiem z automatu włączane jest tylko logowanie.

To prawda, ale w praktyce już sama aktualizacja w dużej mierze rozwiązuje problem. Nie trzeba włączać nowych zabezpieczeń, by podatność została zmniejszona. Dziurawy protokół staje się wtedy "mniej dziurawy": złamanie go nie zajdzie po sekundzie, a po kilku minutach (co zostanie wykryte w porządnie monitorowanych sieciach). Microsoft po prostu nie umiał przyznać wprost, że dziura jest załatana tylko częściowo. Zamiast tego, aktualizację opisano jako element odpowiedzialnego, dwuczęściowego wdrożenia, którego pierwszy etap polega na zbieraniu logów.

Choć technicznie jest to poprawne stwierdzenie, całej prawdy możemy się dowiedzieć dopiero od autorów zgłoszenia. To tam przeczytamy, na czym polega atak nadpisania hasła komputera, jaki szyfr łamie i jak się zabezpieczyć. Na szczęście, nieco uogólniając, można powiedzieć, że "wystarczą aktualizacje".

Często śmiejemy się z obrządku podczas publikowania podatności, gdy w ramach "big reveal" otrzymują własne nazwy, logo oraz domenę. Niektóre z nich są wręcz reklamowane koszulkami i gadżetami. W przypadku CVE-2020-1472 okazało się, że kiepska dokumentacja, brak exploita i częściowe łatanie sprawia, że dużo osób ignoruje zagrożenie, gdy nie ma wokół niego imprezy.

Na koniec warto wspomnieć, że aktualizacja nawet bez włączania zabezpieczeń, chroni przed sierpniową dziurą. Stosowany jednak pod spodem algorytm został uznany za nieposiadający przyszłości. Każe to zakładać, że Microsoft podejrzewa kolejne luki w nim i decyduje się go wyłączyć. Rok po roku, wsteczna zgodność z OS/2 LAN Managerem wychodzi bokiem.