Новые кейсы за последние два года от Александра Дмитриева, независимого эксперта по ИБ:

SQL- инъекция. С помощью sqlmap вытащили хеш пароля администратора из формы поиска товара (в БД хранился не в открытом виде, а в виде хеша). С помощью фермы подобрали по хешу пароль администратора.

Ошибки разработчиков и администраторов, которые привели к возможности такой атаки:

• Очень простой пароль администратора;

• Использование классического хеша, просто md5, без «соли» – пароль было легко подобрать. Если бы использовался какой-нибудь более совершенный алгоритм, сделать это в разумные сроки не получилось бы.

• В административной консоли магазина имелся функционал загрузки картинок для карточки товара. При изменении расширения картинки на php, система не выдавала ошибку. С помощью burp suite загрузили туда php скрипт, который потом выполнился с правами system. Это ошибка в настройке сайта.

Далее получили shell, дамп lsass и т. д., в результате чего – администратора системы.

Простой пароль. Целевой системой был Сonfluence, который «смотрел» наружу, и имел (как оказалось) очень простой пароль администратора, который подобрали за 2 дня (и то потому что делали это очень осторожно). Затем зашли в Сonfluence и обнаружили много интересной информации, в том числе описание подключения по RDP к песочнице. Зашли в песочницу, поломали ее (потому что там стояли очень старые версии ОС) с помощью pass-the-hash получили ntlm hash, дальше пытались подключиться ко всем подряд машинам пока не попали на локального на локального администратора и далее администратора домена через lsass. Эта атака стала возможной, потому что пароль администратора был очень простой.

Забыли закрыть доступ пользователям к публикации блогов в ИС банка. Пользователь мог зарегистрироваться у них на сайте и делать записи в блог. Имелась также функция загрузки файла. Нажали кнопку загрузки, пропустили трафик через Burp Suite, залили html файл. В ответ получили путь до загруженного файла, т. е. ссылку на отдельную html страницу, которая никак не связана с блогом, но располагается на сайте банка.

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

Забытый swagger. Swagger – это платформа, которая позволяет создавать и анализировать rest API к своим сервисам. Компания установила себе сервис и на этом же сервере разработчики поставили swagger для своих нужд. В итоге сервис остался, а swagger забыли на prod-системе. Если просто подключаться к сервису, который работает в продакшене, то нужно знать логины, пароли, токены аутентификации и проч., а если с локального хоста – то ничего этого не нужно. С помощью браузера смогли создать в этом сервисе пользователя с правами администратора, затем зашли под ним на этот сервис. Дальше можно смотреть какая информация в сервисе находится, какие уязвимости имеет этот сервис и пр.

Классические CVE. Сервис управления SSO OpenAM, с двумя свежими (2021 года) уязвимостями. Одна из них позволяла с помощью браузера загрузить payload и получить туннель на хост, т. е. в сеть заказчика через консоль, и далее повышать привилегии, компрометировать сеть и проч. Другая – давала доступ напрямую к хранилищу ldap со списком логинов, хешами паролей, создавать учетные записи пользователей.

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

Почему это происходит? Потому что для поддержания всех сервисов в актуальном и безопасном состоянии требуется много людей и усилий. Есть и базовые вещи, которые надо делать, например, проверить сложность паролей в домене (например, с помощью сервиса на wikisec.ru). Это существенно повысит защиту, но не гарантирует ее.

Взлом внешнего web-сервиса, не связанного с инфраструктурой, хорошо подходит для фишинга и последующих атак на сеть.

Server-Side Request Forgery – актуально даже в больших компаниях. Позволяет делать запросы со стороны сервера, т. е. например web-приложение загружает аватар по ссылке, предоставленной пользователем. Вместо картинки можно подставить какую угодно ссылку и сервер приложения ее вызовет. Фактически это позволяет украсть доступ внутрь серверной сети. Встречается регулярно. Защита – SRF-прокси, который осуществляет запросы по ссылкам и находится в изолированном сегменте сети, не имеющем доступ к prod-среде.

Ошибки конфигурации. Есть довольно популярный стек Django или flask и nginx. Часто в конфигурации nginx в директиве location в конце нужной директории забывают ставить «/». Это позволяет на данном стеке технологий в обход балансировщика добавлять в пути конкретные файлы и получать их содержимое или исходный код. Например, если есть директория со статическими файлами /static, если добавить «:/settings.py» – то можно получить исходный код этого файла, а в нем хранится секретный ключ для сериализации при помощи pickle, могут встречаться учетные записи администратора и какие-нибудь учетные данные к БД. Данную уязвимость можно отразить при помощи WAF, но специалист должен быть квалифицированным, чтобы настроить его правильно.

Небезопасная десериализация в WEB-приложениях – можно получить shell.

Учетные записи по умолчанию, которые забывают менять.

Небезопасные прямые обращения к объектам (IDOR) – позволяют передвигаться вертикально и получать учетные данные администратора (hash, пароли)

Небезопасная загрузка файлов, открытые директории и логи, которые администраторы забыли «спрятать».

Насколько надежными будут доказательства, полученные с помощью инструментов форензики?

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