Задача об утечках паролей
Будет полезна начинающим и опытным специалистам по информационной безопасности, а также всем, кто хочет защитить свои данные.
Текст подготовил Артём Шумейко — внештатный райтер, амбассадор Selectel и автор YouTube-канала о разработке.
Условие
В компании «ТехноБезопасность» недавно всплыла неприятная ситуация: один из сотрудников каким-то образом заходит под аккаунтами других пользователей.
Специалист по безопасности Дин Завров начал расследование. Изначально он предполагал, что утечка вызвана атаками XSS или CSRF, но лид фронтенд-разработки заверил: подобные уязвимости исключены. Тогда Дин пошел к бэкенд-разработчикам и девопсам, но и они не смогли помочь. Пришлось ему самостоятельно перебирать все популярные варианты утечки паролей.
Задача
Определите, какими способами внутри компании мог произойти несанкционированный доступ к чужим аккаунтам. Предположения о фронтенд-уязвимостях (XSS/CSRF) исключены.
Важно учесть все варианты, связанные с неправильным хранением паролей, секретов, бэкапов и логов.
Решение
Ниже — самые распространенные причины, по которым сотрудник внутри компании мог получить пароли коллег или зайти под чужой учетной записью.
Админский доступ к базе и слабое хеширование (или отсутствие хеширования). При нестрогом распределении ролей любой «администратор» может подключиться к базе и посмотреть таблицу пользователей. Если пароли там хранятся без надежного хеширования (например, plain text или устаревший MD5), их легко прочитать или расшифровать. Даже использование SHA1 без соли может позволить быстро восстановить пароль с помощью радужных таблиц. Если в компании не принята политика надежного хеширования (bcrypt, Argon2), то это слабое место в безопасности.
Доступ к приватным ключам или секретам для подписи токенов. В системах, где используются JWT или аналогичные механизмы, знать сам пароль не нужно, если имеется секрет для подписи токенов. С полученным ключом можно выпускать токены от лица любого пользователя. Часто такие секреты случайно хранятся в открытых репозиториях или лежат на общем диске без надлежащих прав. Это позволяет злоумышленнику заходить под любым аккаунтом, обходя даже сложные пароли.
Доступ к бэкапам базы. Разработчики порой защищают бэкапы хуже, чем «живую» базу. Их могут хранить без шифрования на общих сетевых ресурсах или в облаке без жесткого контроля. Если там лежат логины с несильными хэшами паролей или вовсе в открытом виде, любой человек, получивший архив, сможет развернуть бэкап локально и увидеть все данные. Кроме того, иногда в бэкапах содержатся токены или конфигурационные файлы, что усугубляет проблему.
Доступ к паролю через внутренние API. Некоторые внутренние сервисы отдают слишком подробную информацию. Разработчики могли оставить служебные эндпоинты с полным набором данных о пользователях, включая оригинальный пароль или хеш. Если доступ к таким эндпоинтам не ограничен ролями или вообще не документирован, то достаточно иметь технические навыки, чтобы найти и вызвать его. Зачастую подобные роуты создаются для тестовых целей, но случайно оказываются доступными на продакшене.
Логирование паролей в чистом виде. Частый и весьма нелепый случай — когда пароли попадают прямо в логи приложения или системы мониторинга. Такое происходило даже у крупных компаний вроде GitHub. Достаточно включить детальный дебаг HTTP-запросов с записью поля password, и все учетные данные окажутся в логах, которые нередко доступны многим сотрудникам или выгружаются во внешние сервисы (Elasticsearch, Splunk).
В итоге становится ясно: даже в крупных организациях бывают подобные оплошности. Иногда дело в человеческом факторе или временных решениях, которые забыли вовремя исправить.
Важно регулярно проверять, как именно хранятся и обрабатываются пароли, бэкапы, токены и логи. Это поможет предотвратить подобные инциденты.
