Как Взломать Систему Через Тестовую Среду

Безопасность на реальных примерах всегда интересна.

Разговор пойдет о взломе систем через тестовые среды.

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

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

Итак о причинах:

1. Весь акцент делается на построении защиты производственной среды, при этом среды тестирования, промежуточной или производственной среды «забываются»;
2. Принцип снижения поверхностной атаки нарушается, когда специалисты просто не учитывают все возможные точки входа;
3. Нарушается принцип наименьших привилегий, и учетной записи службы предоставляются разрешения, которые ей не нужны;
4. В тестовых средах используются единые и простые пароли для повышения эффективности тестировщиков;
5. Панели отладки добавляются в тестовую среду, чтобы можно было оптимизировать производительность, но такие панели часто включают в себя много дополнительной информации о системе (переменные среды, полный стек ошибок, SQL-запросы и т. д.).

Ниже мы попытаемся проанализировать этот реальный случай.

Итак, было проведено тестирование мобильного приложения непосредственно из магазинов Google и Apple и серверного API, который это приложение использует. Стоит отметить, что разработчики и разработчики проделали очень хорошую работу; В работающей системе обнаружено лишь несколько уязвимостей низкого уровня, которые рекомендуется закрыть.

Мы очень расстраивались (мы обычно расстраиваемся, если безопасность системы на высоте), пока не дошли до тестирования на проникновение через альтернативные точки входа.

Первым делом мы выяснили, какие еще поддомены известны для этого домена.

Возможные способы: посмотреть альтернативные имена в SSL-сертификате или изучить архивы DNS-записей в сторонних сервисах.

Так мы нашли местоположение тестовой среды, указанное как в SSL-сертификате, так и во внешнем сервисе.

Небольшое отступление: доменные сервисы могут хранить историю изменения IP-адреса для доменного имени, а иногда можно обойти WAF, подставив вместо адреса брандмауэра адрес предыдущего IP-адреса.

Таким образом, нам удалось узнать адрес административной панели тестовой среды, которая была доступна в Интернете.

Тогда мне даже не пришлось брутфорсить админку; мне удалось войти в систему с первого раза администратор / администратор .

Скриншота здесь не будет. Помимо раскрытия подробностей того, как устроена административная панель и с какими данными она работает, нас интересовала панель PHP Debug, которая показывала ошибки с полной трассировкой стека, SQL-запросами и путями к файловой системе сервера.

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



Дальше дело техники: с помощью AWS Explorer для Visual Studio подставили ключи AWS и подключились к облаку.

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

В облаке были обнаружены еще три бизнес-системы с полными оперативными данными.

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

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

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

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

Что вы можете сделать, чтобы защитить свою тестовую среду прямо сейчас:

1. Закрытый доступ к различным тестовым средам на уровне VPN или межсетевого экрана;
2. Дважды проверьте, что во всех средах используются уникальные системные настройки (ключи шифрования, доступ к облакам, к другим средам);
3. Дважды проверьте, что каждая среда имеет строгий безопасный цикл;
4. Все разрешения для сервисных учетных записей выдаются в соответствии с принципом наименьших привилегий;
5. Убедитесь, что для работающей системы изменены логин и пароли «по умолчанию»;
6. Разработайте процедуру анонимизации данных, если актуальные данные необходимы для анализа в других средах.

Денис Колошко

• Онлайн-Хранение Данных Предотвращает Саботаж И Кражу Информации

  19 Oct, 24

• Время И Деньги По Всему Миру

  19 Oct, 24

• Докланд — Сервис По Организации Лечения За Рубежом

  19 Oct, 24

• Почему Junior Web-Разработчиков Не Приглашают На Собеседование В Москву?

  19 Oct, 24

• Как Написать Статью На Английском Языке Без Опыта Перевода

  19 Oct, 24

• В Продолжение Темы «Рак. Что С Ним Делать..."

  19 Oct, 24

• Наш Опыт: Аутсорсинг Ит-Услуг Для Сети Розничных Магазинов

  19 Oct, 24

• Яркие Проекторы Для Школ: Бросайте Вызов Световому Загрязнению И Подключайтесь Ко Всем Устройствам Одновременно, Проводным Или Беспроводным.

  19 Oct, 24

• Как Я Поверил В Web3

  19 Oct, 24

• Создание Чистого Css-Шаблона Для Joomla 1.5 — Часть 2.3

  19 Oct, 24