Głęboka sanityzacja dokumentów: Nowe podejście do bezpieczeństwa

CVE-2026-26110 [2] (w skrócie RCE w parserze Microsoft Office) to kolejny sygnał ostrzegawczy: Microsoft załatał własnie lukę typu 'type confusion’ w Microsoft Office, opisaną jako podatność prowadząca do remote code execution. W praktyce to kolejny przykład, że problemem nie są już wyłącznie „makra”, ale znacznie szersza powierzchnia ataku samego formatu dokumentu i parserów Office.

Traktowanie podpisywania makr jako głównej odpowiedzi na ryzyko ze strony dokumentów to dziś juz podejście mocno archaiczne. Podpisy makr i kodu pozostają oczywiście ważnym elementem kontroli bezpieczeństwa. Ale trzeba sie zastanowic czy 'hacker’ nie wyda tych kilku dolarow na codesigning ?

Aktywny lub niebezpieczny content może kryć się także w innych elementach pliku: relacjach zewnętrznych, osadzonych obiektach, polach, szablonach czy nietypowej strukturze OOXML. Dlatego nadchodzi czas głębokiej sanityzacji dokumentów — nie tylko blokowania makr, ale rozbrajania i rekonstrukcji całego pliku. Sam charakter CVE-2026-26110 dobrze pokazuje, że warstwa „document content” i parsery Office pozostają realnym wektorem wykonania kodu.

Juz nie wystarczy nauczyc uzytkownika 'nie klikaj w linki i nieznane zalaczniki’, trzeba tez nauczyc tego Copilota (lub innych asystentów AI).

Z niecierpliwoscia czekam na połaczenie metod z CVE-2026-0866 [1] (Zombie ZIP) z CVE-2026-26110. Tak, DOCX to jest archiwum ZIP, a ZombieZip sprawi ze bedzie nieczytelny dla antywirusa, EDR i innych zabawek.

Dlatego coraz bardziej sensownym podejściem wydaje się głęboka sanityzacja dokumentów (Content Disarm & Reconstruction) – analiza i rekonstrukcja pliku zamiast prostego blokowania makr.

Być może w wielu procesach biznesowych warto wrócić do pytania, czy zawsze potrzebujemy „bogatych” formatów. Czasem prostszy format — a w niektórych scenariuszach nawet stary, dobry RTF lub inne uproszczone formy wymiany treści — może być rozsądniejszy do zbierania danych, CV czy materiałów od klientów niż pełny, złożony ekosystem nowoczesnych dokumentów Office, Wordów, Powerpointow. Nie dlatego, że jest idealnie bezpieczny, ale dlatego, że ograniczanie złożoności bardzo często ogranicza też powierzchnię ataku.

…obawiam się ze jeszcze wrócę do tego wątku..

[1] https://isc.sans.edu/diary/rss/32786

[2] https://nvd.nist.gov/vuln/detail/CVE-2026-26110

No i co z tego, że kamera jest w internecie?

Also available in: English English

Niedawno sekurak opublikował artykuł [1] o tym, że kamery na jednym z dworców PKP były dostępne bezpośrednio z Internetu. Pod postem szybko pojawiły się komentarze w stylu: „no i co z tego?”. Na pierwszy rzut oka rzeczywiście może się wydawać, że niewiele z tego wynika – ot, obraz z jednej kamery.

Problem zaczyna się wtedy, gdy spojrzymy na takie dane przez pryzmat dzisiejszych możliwości analitycznych. W dobie AI, rozpoznawania obrazu i analizy dużych zbiorów danych nawet pojedyncze źródło wideo może dostarczać bardzo cennych informacji: o ruchu osób, schematach zachowań, spotkaniach czy logistyce w danym miejscu.

Warto zestawić tę pozornie błahą sytuację z niedawną informacją opisaną przez The Telegraph, który donosił: „Israel hacked Tehran’s traffic cameras to spy on Khamenei […] Israel hacked nearly all of Tehran’s traffic cameras to spy on Ali Khamenei before launching an attack to kill Iran’s supreme leader.” To pokazuje, że infrastruktura kamer – szczególnie jeśli obejmuje przestrzeń publiczną – może mieć znaczenie znacznie wykraczające poza zwykły monitoring.

Nawet pojedyncza kamera na dworcu, dodatkowo z włączonym audio, może być bardzo wartościowym źródłem informacji. Co więcej, łatwo ulec złudzeniu, że takie urządzenie jest wyłącznie pasywnym sensorem. W praktyce jednak kamera IP to nic innego jak mały komputer podłączony do sieci.

A to oznacza, że często działa na starym, nieaktualizowanym systemie operacyjnym, z podatnym interfejsem webowym i wieloma znanymi lukami bezpieczeństwa. W takim scenariuszu kamera może stać się punktem wejścia do infrastruktury, pełnić rolę jumphosta, umożliwiać rekonesans sieci, a nawet prowadzić do eskalacji uprawnień poprzez podatności w interfejsie zarządzającym (np. XSS lub inne klasyczne błędy aplikacji webowych).

Krótko mówiąc – to nie jest tylko kamera. To element infrastruktury IT działający w bardzo wrażliwym miejscu.

Dodatkowo jestem w stanie się założyć ze 'administrator’ tej kamerki pierwsza rzeczą jaką zrobił po otrzymaniu informacji że jest dostępna z Internetu, w panice, ze swojej stacji roboczej (z milionem otwartych innych zakładek , zcache’owanymi uprawnieniami, a może i kontem administracyjnym). Zalogowal sie do tej nieszczęsnej kamerki by sprawdzić i 'zmienić hasło’. Jeśli redaktorzy Sekuraka mogli sie do niej zalogowac to tysiące innych też. Oni mogli nie byc tak mili i zmodyfikować jej oprogramowanie i wprowadzić złośliwe modyfikacje do jej kodu. Takie urządzenia powinno traktować sie jako skompromitowane i groźne. Dokładnie tak samo jak lekarz potraktowałby pacjenta który przyszedł na wizytę zkrawiącymi łzami i pęcherzami na skórze.

A jeśli do tego zaczniemy rozważać scenariusze, w których kompromitacja takiej infrastruktury może prowadzić do realnych, kinetycznych skutków w świecie fizycznym… to już temat na osobny wpis.

Ciekawi mnie jeszcze czy kamerka wymagała ActiveX…?

Metoda gumowej kaczuszki

Metoda gumowej kaczuszki[1][2] – nieformalny sposób debugowania kodu. Metoda polega na tym, że programista, próbując znaleźć błędy w kodzie (inspekcja kodu), trzyma w pobliżu gumową kaczuszkę lub inny przedmiot nieożywiony. Linia po linii, programista tłumaczy kaczuszce lub innemu obiektowi przewidywane funkcje każdego segmentu kodu – podczas sprawdzania powinny wyjść na jaw błędy stworzonej aplikacji.

Metoda jest wersją metody „myślenia na głos”[3], procedury uznanej za skuteczny sposób na przyspieszenie rozwiązywania problemów.”

https://pl.wikipedia.org/wiki/Metoda_gumowej_kaczuszki