Хабрахабр

Как потерять доступ в лайв систему, просто пошарив исходный код

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

У него было достаточно много причин для беспокойства, среди прочих прозвучала и такая: “Несколько месяцев назад к нам пришел новый разработчик, получил доступы к исходному коду, документации, тестовому серверу, через два дня пропал и до сих пор не отвечает. Один раз пришел клиент с запросом на тестирование на проникновение. Доступы в лайв систему ему не давали.” Чем мне это может грозить?

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

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

Source code на предмет чувствительной информации мы обычно прогоняем, используя gittyleaks. Система 1.
Клонированный код из гита это не только последняя версия, но и история всех изменений.

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

Output: gittyleaks --find-anything
image
Картинка 1.

В данной системе мы нашли deployer.pem файл, который лежал когда-то в руте проекта и использовался для автоматического разворачивания проекта на серверах через SSH канал. Система 2.
Можно воспользоваться git утилитой и попросить ее показать все когда-либо удаленные файлы. Почему открыт? SSH порт в лайв системе был открыт. Гы-гы… Разработчики ответили, что билд машина у них сидела за динамическим IP адресом, и они решили не закрывать порт — “все равно SSH ключ никто не подберет”.

Output: git log --diff-filter=D --summary image
Картинка 2.

Возможно, стоит залезть в скрипты базы и посмотреть, как создаются пользователи по-умолчанию. Система 3.
С этой системой все было ещё проще. В скриптах мы нашли код, который из реальных паролей генерировал хэш и записывал его в базу. Обычно первым пользователем создается админ с самыми высокими полномочиями. А этому коду не первый год, между прочим, и не один человек работал с ним. Что удивительно — создавалось 5 пользователей, но пароль для самого главного админа к нашему изумлению прошел в лайв системе.

Как в скриптах базы можно найти реальные пароли image
Картинка 3.

Посыл.

Если ваш проект на гите, откройте его и запустите пару команд из рут папки: 1.

pip install gittyleaks
gittyleaks --find-anything

git log --diff-filter=D --summary

Одно золотое правило. 2. Лайв система всегда должна иметь уникальные ключи, уникальные пароли пользователей, и в ней все по-максимуму должно быть закрыто.

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

Денис К.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть