Главные враги безопасности облаков — сложные схемы и теневые ИТ-ресурсы

Главные враги безопасности облаков — сложные схемы и теневые ИТ-ресурсы

Главные враги безопасности облаков — сложные схемы и теневые ИТ-ресурсы

Специалисты подразделения IBM Security представили данные исследования киберугроз, влияющих на безопасность облачных сред. По мнению экспертов, часто облака страдают из-за чрезмерно сложных схем и теневых ресурсов.

Проведя опросы и проанализировав инциденты, команда IBM Security пришла к выводу, что главную опасность для облачных сред представляет недостаток бдительности. Например, полное или выборочное игнорирование уязвимостей, ошибки в конфигурациях и общая небрежность в управлении.

Исследователи считают, что именно с этим в первую очередь стоит бороться руководителям организаций, которые хотят обеспечить безопасность облачных операций.

За последний год набралось достаточное число инцидентов информационной безопасности, что позволяет проанализировать их и понять, как именно киберпреступники проводят атаки на облачные среды. Можно также выяснить, какие кастомизированные вредоносные программы, шифровальщики и другие средства используют злоумышленники.

В IBM Security подчеркнули, что со стремительным переходом на облачные технологии и при большом разнообразии различных сервисов становится непонятно, кто именно отвечает за безопасность в облаке. Из-за этого возникают своеобразные «слепые зоны» в политиках безопасности.

В связи с этим возрастает опасность появления новых уязвимостей или некорректных конфигураций. Специалисты IBM Institute for Business Value (IBV) и IBM X-Force Incident Response and Intelligence Services (IRIS) выделили основные тенденции обеспечения безопасности облачных сред.

Во-первых, по словам экспертов, 66% респондентов заявили, что они полагаются на провайдеров в вопросах обеспечения базовой безопасности. При этом зачастую у опрошенных были совсем разные представления о том, кто должен нести ответственность за безопасность.

Во-вторых, облачные приложения открывают возможность для кибератак. На долю облаков приходится 45% от всех инцидентов, в ходе которых атакующие пользуются уязвимостями или ошибками в конфигурации.

В-третьих, кибератаки становятся более масштабными. Основной целью этих действий стала кража данных, за ней идут установка майнера и программы-вымогателя.

Подпишитесь на новости

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru