В этом проекте нет сложных или изящных атак — напротив, многие из них просты, даже примитивны. Эта история про то, как неплохо защищенная в техническом плане компания может пострадать из-за человеческого фактора: простой ошибки веб-разработчиков или неаккуратных сотрудников. Такие случаи напоминают о том, что невозможно предусмотреть все заранее и доказывают важность проведения тестов на проникновение.

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

Пробиваем периметр: анализируем защищенность веб-приложений

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

Self-XSS (межсайтовый скриптинг)

На одном из сайтов заказчика предусмотрена возможность отправлять сообщения администрации. Там нашлась возможность внедрения произвольного JavaScript-кода в POST-запрос.

Внедрение произвольного JavaScript-кода в POST-запрос

В принципе, при помощи социальной инженерии злоумышленник мог бы заставить администратора выполнить модифицированный запрос на своей стороне и таким образом, например, украсть Cookie, но на практике этот баг практически невозможно эксплуатировать, так что в отчете он попал в раздел с дополнительной информацией.

Результат выполнения запроса

Как это пофиксить: В подобных случаях рекомендуется экранировать и фильтровать входные данные: использовать флаг HttpOnly для сессионных Cookie, чтобы запретить JavaScript читать и передавать их, а также заменять спецсимволы HTML-сущностями.

Небезопасное управление сессией

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

Большинство сайтов компании создал один подрядчик. Для авторизации и разграничения доступа пользователей разработчики использовали сессионный идентификатор сервиса Gatekeeper Oauth в заголовке Authorization: Bearer. При этом возможно передавать токен в GET-параметре. А передача сессионных идентификаторов в GET-параметре открывает возможность для фишинга и дальнейшего переиспользования полученных сессионных идентификаторов. Кроме того, URL, содержащий сессионные идентификаторы, может утечь через логи приложений или прокси-серверов.

https://домен.ru/api/dealers/unload_all?token=gFWF9MRXXXXXXfQYAAAL6f2b

Как это пофиксить: Мораль проста — для авторизации пользователей нужно использовать только заголовок Authorization.

Небезопасное хранение файлов

Нашлись недостатки и в функции загрузки файлов на сайт. Так, оказалось, что при создании ссылки объект используются параметры temp_url_sig, temp_url_expires. Получается ссылка типа:

https://домен.ru:443/v1/AUTH_098febeXXXXX3902c29/documents_st2/uploads/alfa_pa/request_532/attachment_8039/image.jpg?temp_url_sig=17400e30XXXXXXXXXX7d79bab&temp_url_expires=1639845372&inline

Однако, в то же время возможен неавторизованный доступ ко всей директории с документами и отдельным объектам в хранилище по прямой ссылке без учета этих параметров.

Неавторизованный доступ к объектам глазами злоумышленника

Как это пофиксить: Закрыть неавторизованный доступ к объектам в хранилищах.

Незакрытые уязвимости

К средней категории опасности мы отнесли дыры, связанные с устаревшим ПО, например, OpenSSH с CVE-2018-15473. Для этой уязвимости давно можно загрузить готовый эксплойт из Metasploit. Он позволяет получить имена пользователей SSH для дальнейших атак.

Слепая SSRF-уязвимость в Keycloak CVE-2020-10770 позволила нам получить информацию о доступности хостов, времени отклика и различных типах ошибок. Все это также можно использовать для других атак.

Как это пофиксить: Не забывать и не лениться устанавливать обновления.

Одна реально серьезная проблема

Перечисленные уязвимости представляют для хакеров некоторый интерес, но сами по себе сравнительно безобидны. Конечно, мы пытались найти нечто более эффектное, зарывались в тонкости логических уязвимостей и искали новые точки входа — и ничего не нашли. А потом вернулись к еще незакрытым пунктам в стандартной методике OWASP Top 10 и проверили ресурсы заказчика на Broken Access Control…

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

Успешная авторизация с использованием произвольного пароля

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

Как это пофиксить: Очевидно, мы посоветовали переделать механизм авторизации и ввести двухфакторную аутентификацию хотя бы для тех ресурсов, которые дают доступ к внутренним документам компании.

Возможные последствия найденных уязвимостей

Итого за две недели исследований мы обнаружили:

• недостаточную фильтрацию входных данных;
• хранение чувствительной информации в открытом доступе;
• устаревшее уязвимое ПО;
• некорректную реализацию авторизационных механизмов
• нарушение контроля доступа.

И если бы не последний пункт, то периметр организации можно было бы назвать довольно надежным. Большинство уязвимостей не складывается в прямой и эффективный вектор атаки на компанию, однако одно нарушение контроля доступа могло доставить заказчику море неприятностей. По условиям договора мы не имели права развивать атаку — все-таки это пентест, а не редтиминг. Поэтому сложно сказать, как далеко могли бы зайти хакеры в конкретном случае, но мало бы не показалось. Доступ к информации о сделках, контрагентах и бизнес-процессах компании открывает широчайшие возможности: от хищения и перепродажи базы клиентов компании до кражи денег при помощи социальной инженерии.

Кстати, о ней.

Выпускаем социальных инженеров: проверяем сотрудников

Атаки, основанные на психологии и обмане, разнообразны, но чаще всего как дополнение к классическому пентесту наши клиенты выбирают фишинг. Так что мы всегда радуемся, когда просят сделать что-то еще. Прикольно творить всякое шпионское «злодейство», но во благо. В этот раз это был выезд и проникновение в офис. По договоренности с заказчиком основной целью нашего агента было распространение по помещениям флешек с активным содержимым.

Проникновение в офис

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

Нашего агента встретил полупустой опенспейс. Время заранее было выбрано так, что большинство сотрудников ушло на обед. Агент разбросал флешки — никто и не заметил. Ни препятствий или вопросов, даже как-то скучно.

К сожалению для нас, уговорить секретаря распечатать пару листочков из зараженного файла не получилось. На этот раз флешки вообще не сработали. В службу безопасности компании ни один накопитель не сдали, но похоже сотрудники тихо забрали «подарки» и отформатировали их дома, даже не изучив содержимое. Собеседование на должность безопасника тоже как-то не задалось. Оффер агенту потом прислали, но никакой конфиденциальной информации о СЗИ в процессе разговора вытянуть не удалось.

Токен и пропуск, оставленные без присмотра

Впрочем, в обычном рабочем бардаке на столах сотрудников нашлись и незаблокированные ноутбуки, конфиденциальные документы, пропуска и даже токен ЭЦП бухгалтерии. Так что, будь на месте нашего сотрудника злоумышленник, с пустыми руками он бы не ушел.

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

Фишинговая рассылка

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

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

Фишинговое письмо для первого сценария

Второй сценарий мы заготовили для специалистов техподдержки разного уровня. Им направили письмо от эйчара о возможности оформить ДМС. В аттаче был файл .docx якобы с программой страхования.

Фишинговое письмо для второго сценария

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

Выхлоп от рассылки также оказался небольшим — всего два хеша из полусотни писем.

Перехваченный хеш от доменных учетных записей

В целом сотрудники заказчика показали себя на удивление хорошо. Обычно на удочку попадаются 25–30% получателей наших писем. На этот раз — всего 3%. Для крупной компании это на редкость маленький показатель. Однако даже одной скомпрометированной учетной записи хватило, чтобы добраться до бухгалтерии.

Мы восстановили пароли из тех самых NTLMv2-хешей и получили доступ к корпоративной почте двух сотрудников техподдержки. Запрос по ключевому слову «пароль» в одном из ящиков выдал письма с учетными данными от различных сервисов, в том числе и с логинами других пользователей. Там нашлись валидные пары логин/пароль от облачной версии 1С-Бухгалтерия и даже пароль от одной из баз данных 1С.

Проверка валидности обнаруженных учетных данных на примере базы данных

Судя по контексту сообщений, наш заказчик нанял для администрирования 1С внешнего подрядчика. С администратором в основном контактировал конкретный сотрудник компании, назовем его Владимир. Его почту мы и взломали.

Когда в компании появлялся новый сотрудник, Владимир просил администратора 1С создать еще одну учетную запись. В ответ администратор присылал логин и пароль, а Владимир пересылал их владельцу нового аккаунта. Такая схема работала годами, и никто заботился об удалении истории переписки или смене паролей.

Как это пофиксить: Порой опытных специалистов это раздражает, но, похоже, даже технических сотрудников необходимо тестировать на знание принципов информационной гигиены. Такое вот необходимое занудство — время от времени напоминать, что хранить пароли в почтовых ящиках и мессенджерах — это не комильфо.

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

• Практикуют ли разработчики ваших сайтов и приложений методики безопасной разработки?
• Звали тестировщиков перед сдачей проекта? А пентестеров?
• Какие пробелы допущены в обучающих материалах по ИБ, которые используют в компании?
• Зачем сотрудники передают друг другу пароли?

Защита компании — это не только установка СЗИ и отлов багов. Эти меры не так уж эффективны без системного подхода к информационной безопасности, вдумчивого менеджмента и работы с персоналом.