Безопасность на реальных примерах всегда более интересна.
Один раз пришел клиент с запросом на тестирование на проникновение. У него было достаточно много причин для беспокойства, среди прочих прозвучала и такая: “Несколько месяцев назад к нам пришел новый разработчик, получил доступы к исходному коду, документации, тестовому серверу, через два дня пропал и до сих пор не отвечает. Чем мне это может грозить? Доступы в лайв систему ему не давали.”
Мы сейчас не будем говорить про ошибки разработчиков, которые могут стать серьезными дырами в лайв системе. Все гораздо проще — сам исходный код может содержать прямые инструкции и доступы.
Из разных проектов, которые мы тестировали на безопасность, приведу реальные примеры, когда имея лишь исходный код, мы могли проникнуть в саму систему. Все эти проблемные места были устранены, а любая лишняя информация на скриншотах скрыта.
Система 1.
Клонированный код из гита это не только последняя версия, но и история всех изменений. Source code на предмет чувствительной информации мы обычно прогоняем, используя gittyleaks.
В данном проекте мы нашли приватный ключ шифрования, который когда-то удалили из кода, но в лайв системе он продолжал использоваться. Этот ключ использовался для аутентификации, и зная механизм мы могли генерировать себе любой аутентификационный кук любого пользователя, включая администратора.
Картинка 1. Output: gittyleaks --find-anything
Система 2.
Можно воспользоваться git утилитой и попросить ее показать все когда-либо удаленные файлы. В данной системе мы нашли deployer.pem файл, который лежал когда-то в руте проекта и использовался для автоматического разворачивания проекта на серверах через SSH канал. SSH порт в лайв системе был открыт. Почему открыт? Разработчики ответили, что билд машина у них сидела за динамическим IP адресом, и они решили не закрывать порт — “все равно SSH ключ никто не подберет”. Гы-гы…
Картинка 2. Output: git log --diff-filter=D --summary
Система 3.
С этой системой все было ещё проще. Возможно, стоит залезть в скрипты базы и посмотреть, как создаются пользователи по умолчанию. Обычно первым пользователем создается админ с самыми высокими полномочиями. В скриптах мы нашли код, который из реальных паролей генерировал хэш и записывал его в базу. Что удивительно — создавалось 5 пользователей, но пароль для самого главного админа к нашему изумлению прошел в лайв системе. А этому коду не первый год, между прочим, и не один человек работал с ним.
Картинка 3. Как в скриптах базы можно найти реальные пароли
Посыл.
1. Если ваш проект на гите, откройте его и запустите пару команд из рут папки:
pip install gittyleaks
gittyleaks --find-anything
git log --diff-filter=D --summary
2. Одно золотое правило. Лайв система всегда должна иметь уникальные ключи, уникальные пароли пользователей, и в ней все по максимуму должно быть закрыто.
Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.
Денис Колошко
Один раз пришел клиент с запросом на тестирование на проникновение. У него было достаточно много причин для беспокойства, среди прочих прозвучала и такая: “Несколько месяцев назад к нам пришел новый разработчик, получил доступы к исходному коду, документации, тестовому серверу, через два дня пропал и до сих пор не отвечает. Чем мне это может грозить? Доступы в лайв систему ему не давали.”
Мы сейчас не будем говорить про ошибки разработчиков, которые могут стать серьезными дырами в лайв системе. Все гораздо проще — сам исходный код может содержать прямые инструкции и доступы.
Из разных проектов, которые мы тестировали на безопасность, приведу реальные примеры, когда имея лишь исходный код, мы могли проникнуть в саму систему. Все эти проблемные места были устранены, а любая лишняя информация на скриншотах скрыта.
Система 1.
Клонированный код из гита это не только последняя версия, но и история всех изменений. Source code на предмет чувствительной информации мы обычно прогоняем, используя gittyleaks.
В данном проекте мы нашли приватный ключ шифрования, который когда-то удалили из кода, но в лайв системе он продолжал использоваться. Этот ключ использовался для аутентификации, и зная механизм мы могли генерировать себе любой аутентификационный кук любого пользователя, включая администратора.
Картинка 1. Output: gittyleaks --find-anything
Система 2.
Можно воспользоваться git утилитой и попросить ее показать все когда-либо удаленные файлы. В данной системе мы нашли deployer.pem файл, который лежал когда-то в руте проекта и использовался для автоматического разворачивания проекта на серверах через SSH канал. SSH порт в лайв системе был открыт. Почему открыт? Разработчики ответили, что билд машина у них сидела за динамическим IP адресом, и они решили не закрывать порт — “все равно SSH ключ никто не подберет”. Гы-гы…
Картинка 2. Output: git log --diff-filter=D --summary
Система 3.
С этой системой все было ещё проще. Возможно, стоит залезть в скрипты базы и посмотреть, как создаются пользователи по умолчанию. Обычно первым пользователем создается админ с самыми высокими полномочиями. В скриптах мы нашли код, который из реальных паролей генерировал хэш и записывал его в базу. Что удивительно — создавалось 5 пользователей, но пароль для самого главного админа к нашему изумлению прошел в лайв системе. А этому коду не первый год, между прочим, и не один человек работал с ним.
Картинка 3. Как в скриптах базы можно найти реальные пароли
Посыл.
1. Если ваш проект на гите, откройте его и запустите пару команд из рут папки:
pip install gittyleaks
gittyleaks --find-anything
git log --diff-filter=D --summary
2. Одно золотое правило. Лайв система всегда должна иметь уникальные ключи, уникальные пароли пользователей, и в ней все по максимуму должно быть закрыто.
Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.
Денис Колошко
