Критична уязвимост в PHP – технология, използвана от до 70% от уебсайтовете в света – беше открита от изследователи с помощта на изкуствен интелект. Нареченият PHP2Shell проблем може да позволи изпълнение на неоторизиран код върху сървъри, които не са актуализирани. Случаят повдигна и въпроса дали изкуственият интелект може да ускори не само откриването на слабости, но и разработването на инструменти за кибератаки.

Какво означава подобна уязвимост на практика, колко уязвими са сайтовете, които не получават редовна поддръжка, и кой трябва да реагира при проблем?

По тези въпроси Moreto.net разговаря с Александър Минчев, който поддържа интернет сървъри от края на 90-те години и управлява „Абиликс Софт“.

- Изненада ли ви сривът в Google Cloud?

Не. Изненада ме колко хора се изненадаха. Всяка система може да спре - въпросът е дали сме помислили какво става тогава. Голямото име на доставчика не отменя математиката. Ако всеки час има шанс едно на десет хиляди нещо да се обърка, средно на 14 месеца нещо ще се обърква. Облакът е отличен инструмент. Но е чужд компютър в чужда сграда, а удобството ви кара да забравите, че зависите от нея. Не съветвам никого да бяга от облака. Съветвам да не се слагат всички яйца в една кошница - независимо чия е кошницата. Ако има два дейта центъра, двата ще отпадат едновременно средно веднъж на 1 400 години.

- PHP уязвимостта сериозна ли е за фирмените сайтове?

Сериозна е, защото PHP стои зад огромна част от сайтовете, а те обичайно са публични. Освен това информацията изтече преди кръпката. Но истинската опасност не беше в новината. Тя се крие при приципния проблем - сайтовете, които никой не поддържа: направени преди години от фирма, която вече я няма, с парола за хостинга у бивш служител.

Бих искал на първо място да предупредя всички, които са решили проблема по спешност - вероятно ще има и други проблеми, включително в PHP. Защитата не е еднократно действие, а процес.

- Кой трябва да реагира при такава уязвимост?

- Ако не сте сигурни кой отговаря за поддръжката на вашия сайт, вероятно отговаряте лично. Ако не сте подготвен - вземете мерки! Особено ако става дума за важна система, която може да блокира работата ви.

Принципно отговаря този, който управлява съответната система, и това трябва да е ясно предварително, не в деня на атаката. Дейта центърът пази тока, мрежата и вратата. Хостингът или администраторът - сървъра. Собственикът - своето приложение. Най-опасната фраза в областта е „Мислех си, че вие го правите“.

- Какво бихте посъветвали варненския бизнес?

- Три неща.

Проверете кой за какво отговаря! Проверете кой отговаря за всяка дейност, осигурете си списък с контакти по отговорности - с име, имейл и телефон; Добавете номерата в указателя на телефона си (може да нямате достъп до файла в случай на инцидент). Ако за нещо отговаря служител, а не организация, изяснете какво става, докато отсъства.

Проверете си архивите! Още тази седмица поискайте да възстановите нещо от архива си, просто за да видите, че се получава. Ако нямате надежден архив, незабавно вземете мерки! Прекъсвания за час или за ден носят щети. Пълната загуба на информация може да е катастрофална.

Пресметнете цената! Изчислете колко ви струва един ден престой. Ако имате магазин - вижте средната сума на поръчките за един ден. Ако имате вътрешна система - вижте колко души биха били блокирани, колко сериозно биха били блокирани и колко са заплатите им за ден. На база цената на престой преценете има ли смисъл от допълнителни действия.

- Откъде може да се почерпи oфициална информация за уязвимостите и корекциите, които следва да се извършат?

- Зависи от това откъде е инсталиран PHP. Ако е от самия проект PHP, кръпката идва от тях. Ако е от дистрибуцията (Debian, Red Hat и др.), тя пуска собствена кръпка според своите срокове и версии – някои я издават веднага, други по-късно, а за по-стари версии понякога няма.

Препоръчвам абонамент за бюлетините за сигурност не само на дистрибуцията, а и на основните използвани проекти. Официални източници за този случай:

- PHP: https://www.php.net/ChangeLog-8.php

- Debian: https://www.debian.org/security/

- Red Hat: https://access.redhat.com/security/

- CERT-EU: https://cert.europa.eu/publications/security-advisories

Темата е изключително техническа, затова най-добре попитайте служителите или доставчика си дали са абонирани за основните бюлетини за сигурност.