Oznacza to zdalne wykonanie kodu bez uwierzytelnienia, z atakami obserwowanymi jeszcze przed wydaniem poprawek.
Nie czekaliśmy na patch. Pierwszą analizę ryzyka przygotowaliśmy w niecałe 10 minut od ogłoszenia, a czas do pojawienia się poprawionych wersji PHP w repozytoriach wykorzystaliśmy na przeglądy infrastruktur naszych Klientów. Działamy według procedur, które dopracowujemy od wielu lat i stosujemy na co dzień. Dzięki nim w takiej sytuacji zawsze wiemy, co robić.
Zweryfikowaliśmy około 1200 serwerów stanowych oraz około 800 zasobów bezstanowych, czyli klastry Kubernetes, grupy autoskalujące i inne, na ponad 300 kontach w Amazon Web Services (AWS), Microsoft Azure i Google Cloud Platform. Do weryfikacji i części aktualizacji użyliśmy naszych autorskich narzędzi automatyzujących.
Gdy poprawki były dostępne, około 350 serwerów załataliśmy automatycznie. Kolejnych 50 zaktualizowaliśmy ręcznie, zgodnie z procesem Klienta: najpierw środowisko dev, a po akceptacji produkcja.
Dla około 30 systemów, których producent już nie wspiera (End of Life), zastosowaliśmy obejścia ograniczające ryzyko mimo braku oficjalnej poprawki. Na tym właśnie polega utrzymanie: bierzemy odpowiedzialność za środowisko także wtedy, gdy problem dotyczy technologii sprzed piętnastu lat, a nie tylko tej, o której wszyscy dziś mówią.
W tym czasie obsłużyliśmy około 60% więcej zgłoszeń niż w analogicznym okresie przed podatnością.
Niezależnie od tego, czy Twoja aplikacja działa na PHP, Kubernetesie czy Bedrock, ktoś powinien za nią odpowiadać przez całą dobę. Jeśli nie masz pewności, czy Twoje środowisko jest bezpieczne, odezwij się, sprawdzimy to.
