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

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

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

1. Весь акцент делается на построении защиты для продакшн среды, а про тестовую, стэйджинг или дев среду «забывают»;

2. Нарушается принцип Surface Attack Reduction, когда специалисты просто не учитывают все возможные точки входа;

3. Нарушается принцип минимальных привилегий, и сервисному аккаунту дают разрешения, которые ему не нужны;

4. В тестовых средах используются однотипные и несложные пароли для повышения эффективности работы тестировщиков;

5. В тестовую среду добавляют дебаг панели, чтобы можно было оптимизировать производительность, но такие панели часто включают в себя много дополнительной информации о системе (переменные среды, полный стэк ошибок, sql запросы и т.д.)

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

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

Первым делом выяснили, какие еще поддомены известны для данного домена. Возможные пути: посмотреть альтернативные имена в SSL сертификате либо исследовать архивы DNS записей в сторонних сервисах. Так мы нашли расположение тестовой среды, указанной и в SSL сертификате, и во внешнем сервисе. Небольшое отступление: доменные сервисы могут хранить историю изменения IP адресов для какого-нибудь доменного имени, и иногда получается обходить WAF, подставляя вместо адреса файервола адрес предыдущего IP адреса.

Таким образом, нам удалось выяснить адрес административной панели тестовой среды, которая была доступна в Интернете. Далее даже не пришлось брутфорсить админовскую панель, с первого раза удалось зайти под admin/admin. Тут скриншота не будет.

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

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

Далее - дело техники: через AWS Explorer для Visual Studio мы подставили AWS ключи и подключились к облаку. В итоге оказалось, что те же ключи использует и продакшн окружение, и в целом для сервисного аккаунта были предоставлены полные привилегии. В облаке обнаружили еще три бизнес системы с полными лайв данными. Часть лайв данных была доступна для прямого скачивания.

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

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

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

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

1. Закрыть доступы к различным тестовым средам на уровне VPN или Firewall;

2. Перепроверить, что все среды используют уникальные системные настройки (ключи шифрования, доступы в облака, в другие среды);

3. Перепроверить, что каждая среда имеет строгий защищенный контур;

4. Все разрешения для сервисных аккаунтов выданы в соответствии с принципом минимальных привилегий (Principle of least privilege);

5. Удостовериться, что логины-пароли «по умолчанию» изменены для лайв системы;

6. Разработать процедуру по анонимизации данных, если данные с лайва необходимы для анализа в других средах.

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

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

CISSP, OSWE, Penetration Tester