Menu dostępności

Maile będą już przychodzić! Błąd naprawiony przez Microsoft

W korporacyjnym świecie wraz ze zmianą daty na 2022 rok w niektórych organizacjach przestały docierać maile do użytkowników. Wszystkiemu winien był błąd w sprawdzaniu sygnatur plików przez silnik anty-malware wbudowany w Exchange. Na szczęście błąd ten został szybko naprawiony przez Microsoft przez poprawkę wydaną w ubiegły weekend.

Microsoft wyjaśnił wszystko na swoim blogu. Czytamy tam między innymi, że problem dotyczy tylko środowisk on-premise w wersji 2016 lub 2019, w których aktywny jest moduł AV. Microsoft zapewnia również, że nie jest to żadna dziura czy bug związany z bezpieczeństwem i nie mamy czego się obawiać. To tylko sprawdzanie wersji sygnatury plików powoduje awarię i crash silnika AV, a to z kolei skutkuje blokowaniem wiadomości w kolejkach transportowych na serwerze.

Problem odbił się dużym echem w Internecie, co możemy zobaczyć poniżej:

Zaczął też zwracać uwagę administratorów, gdy rozpoczął się rok 2022, powodując, że serwery nie dostarczały wiadomości e-mail, a jednocześnie wyświetlały następujący komunikat: „The FIP-FS 'Microsoft’ Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can’t convert '2201010001′ to long.”

W logu aplikacyjnym można było za to znaleźć następujące wpisy:


Naprawa problemu

Microsoft zagregował szybko prezentując rozwiązanie naprawiające problematyczny moduł. Poprawkę można wdrożyć na dwa sposoby: – automatyczny – wykonując dostarczony przez MS skrypt – ręczny – usuwając pliki z silnika AV i instalując nowe


Metoda Automatyczna
  • Pobierz skrypt tutaj: https://aka.ms/ResetScanEngineVersion
  • Przed uruchomieniem skryptu zmień zasady wykonywania skryptów PowerShell, uruchamiając Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
  • Uruchom skrypt na każdym serwerze Exchange z rolą mailbox, który pobiera aktualizacje chroniące przed złośliwym oprogramowaniem w Twojej organizacji 

Skrypt ten można uruchomić równolegle na wielu serwerach. Po zakończeniu skryptu powinniśmy zobaczyć dane wyjściowe podobne do poniższych:


Metoda Manualna

Zamiast używać skryptu, klienci mogą również ręcznie wykonać kroki w celu rozwiązania problemu i przywrócenia usługi. Aby ręcznie rozwiązać ten problem, należy wykonać następujące kroki również na każdym z serwerów Exchange z rolą „Mailbox”. Problem ten nie dotyczy serwerów z rolą „Transport Edge”.

1. Sprawdź, czy wersja, której dotyczy problem, jest zainstalowana: – Uruchom Get-EngineUpdateInformation i sprawdź informacje UpdateVersion. Jeśli zaczyna się od „22…”, kontynuuj. Jeśli zainstalowana wersja zaczyna się od „21…”, nie musisz podejmować żadnych działań.

2. Usuń istniejący silnik i metadane: – Zatrzymaj usługę Microsoft Filtering Management. Po wyświetleniu monitu o zatrzymanie usługi Microsoft Exchange Transport kliknij przycisk Tak. – Użyj Menedżera zadań, aby upewnić się, że updateservice.exe nie jest uruchomiony. – Usuń następujący folder: %ProgramFiles%\Microsoft\Exchange Server\V15\FIP FS\Data\Engines\amd64\Microsoft. – Usuń wszystkie pliki z następującego folderu: %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\metadata.

3. Aktualizacja do najnowszego silnika: – Uruchom usługę Microsoft Filtering Management i usługę Microsoft Exchange Transport. – Otwórz powłokę Exchange Management Shell, przejdź do folderu Scripts (%ProgramFiles%\Microsoft\Exchange Server\V15\Scripts) i uruchom Update-MalwareFilteringServer.ps1 .

4. Sprawdź informacje o aktualizacji silnika: – W powłoce zarządzania Exchange uruchom Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell. – Uruchom Get-EngineUpdateInformation i sprawdź, czy informacja UpdateVersion to 2112330001 (lub nowsza)

Po zaktualizowaniu Microsoft zaleca oczywiście sprawdzenie czy przepływ poczty działa i czy zdarzenia błędów FIPFS nie są obecne w dzienniku zdarzeń w logu aplikacyjnym.

Popularne

7-Zip podatny na NTFS Heap Overflow

7-Zip podatny na NTFS Heap Overflow

Jaroslav Lobačevski z GitHub Security Lab opublikował analizę nowej podatności odnalezionej w 7-Zip, oznaczonej jako GHSL-2026-140. Luka dotyczy parsera NTFS i prowadzi do uszkodzenia pamięci procesu, co w...
19-letnia luka w jądrze Linuksa naraża systemy na dostęp root

19-letnia luka w jądrze Linuksa naraża systemy na dostęp root

Właśnie opublikowano kod exploita Proof-of-Concept (PoC) dla luki CIFSwitch, która umożliwia użytkownikom o niskich uprawnieniach uzyskanie dostępu root w podatnych systemach Linux. Luka w zabezpieczeniach jądra...
Fałszywe ChatGPT i Claude infekują komputery. Cyberprzestępcy wykorzystują boom na AI

Fałszywe ChatGPT i Claude infekują komputery. Cyberprzestępcy wykorzystują boom na AI

Popularność sztucznej inteligencji rośnie w niespotykanym tempie. Narzędzia takie jak ChatGPT czy Claude stały się codziennym wsparciem dla programistów, analityków, studentów i firm. Miliony użytkown...
YellowKey: koniec mitu o bezpieczeństwie BitLockera? Nowy zero-day pozwala ominąć szyfrowanie przy użyciu zwykłego pendrive’a

YellowKey: koniec mitu o bezpieczeństwie BitLockera? Nowy zero-day pozwala ominąć szyfrowanie przy użyciu zwykłego pendrive’a

Jeszcze w piątek opisywaliśmy nowe podatności typu zero-day, o nazwach YellowKey oraz GreenPlasma, uderzające w mechanizmy bezpieczeństwa systemów Windows. Najnowsze informacje pokazują jednak, że spr...
Krytyczna luka w Windows Search ujawnia hashe NTLMv2. Microsoft nie wydał jeszcze poprawki

Krytyczna luka w Windows Search ujawnia hashe NTLMv2. Microsoft nie wydał jeszcze poprawki

Eksperci z Huntress ujawnili nową podatność, umożliwiającą wyciek poświadczeń NTLMv2 za pośrednictwem mechanizmu Windows Search. Problem dotyczy obsługi schematu URI wykorzystywanego przez Eksplorator Windows d...