на главную сниппетовНа проектах по пентестам нам часто удается получить доступ к корпоративному компьютеру «жертвы», а затем и добыть из него плохо защищенные пароли. К чему это приводит, все понимают. А как происходит такая компрометация — сегодня попробуем раскрыть.
Внимание! Цель статьи — повышение осведомленности рядового пользователя и специалиста по ИБ в вопросе (без)опасности выбранного метода хранения паролей и рекомендация хороших альтернатив. Методы эксплуатации приведены исключительно в образовательных целях для понимания реальных угроз. Ни в коем случае не пробуйте эксплойты на чужом устройстве и/или чужом парольном менеджере — это неправильно как с точки зрения этики, так и закона. Подобные действия разрешено выполнять либо на своей системе, либо с разрешения владельца системы (лучше — письменного).
По результатам запроса в Google «top internet browsers» я выбрал три браузера для показательного примера:
Простой, но нетехнический случай на пентесте.
Пожалуй, один из наиболее известных способов подглядеть простой автозаполненный пароль — использовать замену типа элемента ввода пароля.
Переходим на страницу с логин-формой, от которой браузер хранит пароль, кликаем по полю с паролем кружочками правой кнопкой мыши, выбираем пункт Проверить/Inspect/Исследовать (названия из выбранных браузеров) и меняем у интересующего input-элемента значение type="password" на type="text".
Есть и простой способ массово выгрузить пароли в исходном виде: если вы храните пароли в Firefox и не установили мастер-пароль, то можете легко выгрузить их все разом без регистрации и смс, зайдя в Настройки/Приватность/Логины и пароли/Сохраненные логины (в MS Edge и Google Chrome на Linux так же).
Графическое подключение можно получить не всегда. Чаще при проведении тестирования на проникновение мы хотим выгрузить данные из браузеров быстро и эффективно. Для этого нужно понимать, как устроено хранение паролей в целевом браузере.
Раньше Google Chrome хранил связанные с логин-формами данные в файле «Web data». В новых же версиях он хранит данные в файле базы данных SQLite «Login Data», находящемся в папке пользователя. Адреса сайтов и имена пользователя хранятся в читаемом виде, а пароли зашифрованы. На Windows-системах Google Chrome шифрует данные с помощью функции CryptProtectData, встроенной в Windows DPAPI (Data Protection API).
DPAPI — это функционал Windows для управления защитой «секретов». Шифрование производится симметрично (чем зашифровали, тем и расшифровываем), ключ шифрования основан на пользовательских аутентификационных данных в системе. С помощью DPAPI защищаются данные в веб-браузерах (Internet Explorer, Microsoft Edge, Google Chrome), в почтовых клиентах (Outlook, Windows Mail), в приложениях Skype, Dropbox и пр. — применений много.
Есть и функция расшифрования «секретов» — CryptUnprotectData. Так как ключ шифрования основан на пользовательских аутентификационных данных в системе, расшифрование от лица пользователя — простейшая задача.
Разберемся на примере Google Chrome.
Берем ключ шифрования «encrypted_key» из файла C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Local State. Он зашифрован с помощью DPAPI, но при доступе от имени пользователя это неважно.
Зашифрованные пароли хранятся в базе данных SQLite по пути C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Login Data.
В шифрованной последовательности из файла Login Data содержатся сразу две величины: с 4-го по 20-й символ — второй секрет, а с 21-го символа по 17-й с конца — сам шифрованный симметричным алгоритмом AES-пароль. Таким образом, у нас есть оба секрета (ключ, второй секрет) и пароль. Это всё, что требуется для получения исходных паролей!
Так как Microsoft Edge создан на том же «движке», что и Google Chrome, для него меняется лишь путь: C:\Users\<User>\AppData\Local\Microsoft\Edge\User Data.
Для ознакомления прилагаю пример Python-скрипта, быстро выгружающего данные из Google Chrome и Microsoft Edge (только для данного пользователя):
Для выгрузки паролей из браузера существуют и специальные Metasploit-модули, к примеру, для Chrome: post/windows/gather/credentials/chrome.
Такой скрипт может быть упакован в обычный EXE-файл без дополнительных зависимостей и может быть написан на других языках.
Бывает ситуация: нашли резервную копию папки AppData интересного пользователя или получили к ней доступ иным образом. Что можно сделать — расскажем по-пентестерски.
По пути C:\Users\<User>\AppData\Roaming\Microsoft\Protect\<SID> лежит мастер-ключ, используемый для шифрования паролей пользователя:
wmic useraccount get name,sid # Перечислить имена аккаунтов в системе и их SID
ls C:\Users\<User>\AppData\Roaming\Microsoft\Protect\<SID> -h # Найти зашифрованный мастер-ключУтилитой DPAPImk2john.py из SID и зашифрованного мастер-ключа пользователя получаем хэш пароля пользователя и подбираем его пароль от операционной системы. При наличии доступа к ПК этого пользователя заходим в его аккаунт и выгружаем пароли ранее описанным способом. Но если есть только папка AppData, то с помощью инструмента Mimikatz (модуль dpapi::masterkey) достаем зашифрованный мастер-ключ, SID, системный пароль и расшифровываем мастер-ключ.
Затем берем зашифрованный encrypted_key из папки браузера, переводим его из кодировки base64 в байтовое представление и расшифровываем с помощью модуля dpapi::blob (понадобится расшифрованный мастер-ключ). Готово, пароли получены!
Что можно сказать о защите паролей Google Chrome, MS Edge на Linux?
На Linux, браузеры Google Chrome и Microsoft Edge не имеют доступа к DPAPI, поэтому шифруют данные самостоятельно. При этом выгрузка паролей из этих браузеров происходит «без вопросов». То есть если на проекте мы получили доступ к системе, то удаленно подключаемся к графическому окружению (к примеру, по vnc) и вручную выгружаем все пароли в несколько кликов средствами самого браузера!
Как вы могли заметить, мы не обсудили Firefox. Дело в том, что он эксплуатируется одинаково на разных платформах. Путь до папки с Firefox-профилями в Windows будет следующим: C:\Users\<User>\AppData\Roaming\Mozilla\Firefox\Profiles. В Linux: ~/.mozilla/firefox/Profiles. В папке профиля пользователя находится файл logins.json, хранящий адреса логин-форм и зашифрованные по стандарту PKCS #11 имя пользователя с паролем. Для шифрования Firefox пользуется собственной библиотекой NSS, которая находится в папке браузера: nss3.dll в Windows, libnss3.so в Linux и libnss3.dylib в Mac.
Для расшифрования с помощью NSS потребуется считать зашифрованные имена и пароли из папки профиля и использовать NSS для получения имен и паролей в исходном виде. Если декодирование проводится на том же устройстве, то больше ничего не требуется. По сути, ключ для шифрования — само устройство.
Хороший инструмент для получения паролей из Firefox на пентесте — firefox_decrypt.
Благодаря тому, что Firefox использует собственную библиотеку для шифрования, на Linux- и Mac-системах ситуация никак не отличается.
В Google Chrome подобные настройки отсутствуют в принципе. В Microsoft Edge есть лишь настройки защиты паролем функции автозаполнения, а не самих паролей. Как можно догадаться, от скрипта выше такие функции не защитят. В отличие от предыдущих браузеров, Firefox позволяет (и даже рекомендует) защищать свои пароли мастер-паролем. Доступна эта возможность по пути Настройки/Приватность и защита/Логины и пароли/Использовать основной пароль. Сразу после установки мастер-пароля все сохраненные пароли защищаются уже с его помощью.
Но если при пентесте обнаруживаем подобный защищенный файл, то не всё потеряно — ведь мы можем провести атаку на перебор мастер-пароля.
Нужно учитывать, что многие парольные менеджеры, включая все три рассмотренных браузера, уязвимы к выгрузке паролей из памяти. Если же парольный менеджер шифрует пароли мастер-ключом (как в Firefox), то уязвимость актуальна, только когда база разблокирована (после ввода мастер-пароля). Для проверки своего браузера можете сохранить в нем данные, затем с помощью Process Hacker раскрыть процесс открытого браузера, на вкладке «Memory» нажать кнопку «Strings...», далее «Ok», в открывшемся окне кликнуть «Filter» и выбрать «Contains», попробовать ввести пароль, и его можно будет найти в памяти процесса.
Как вы могли убедиться, Firefox + мастер-пароль являются более безопасной комбинацией. Но я рекомендую всё же рассмотреть альтернативу в виде менеджеров паролей, не встроенных в браузер: как из-за дополнительного функционала (хранение секретов, не связанных с логин-формами), так и из-за дополнительных настроек безопасности.
Расширения обычно хранят пароли на серверах разработчика. Пароли зашифровываются/расшифровываются на компьютере пользователя его мастер-ключом. Мастер-ключ не покидает компьютер пользователя, поэтому за нешифрованное хранение паролей можно сильно не беспокоиться.
Обычно, если при пентесте попадаются такие менеджеры паролей, то пароли из них удается извлечь, если они уже разблокированы, если получен мастер-пароль и на парольном менеджере не настроена двухфакторная аутентификация, либо при успешной атаке типа «человек посередине».
Для пользователя можно выделить скорее сопутствующие риски у расширений:
Серверы сервиса могут оказаться недоступны, тогда пользователь потеряет доступ к паролям. К примеру, в 2020 году пользователи LastPass временно потеряли доступ к своим паролям. Без подключения к интернету пароли также будут недоступны.
Возможна утечка баз паролей пользователей сервиса. К примеру, в декабре 2022 года LastPass сообщил об утечке зашифрованных баз паролей как последствии атаки, проведенной ранее в этом же году.
Сервис может прекратить свое существование — тогда все пароли могут быть утрачены.
Неизвестно, что происходит со связанными с паролями данными. К примеру, сервис может отслеживать, когда и как пользователь обращается к нему, откуда и какие данные запрашивает, а затем использовать их в своих целях. Или может быть проведена «инсайдерская» атака, при которой недобросовестный сотрудник собирает из системы накопившиеся пользовательские данные.
Риск перехвата зашифрованных паролей «на лету» и их расшифровки ничтожно мал, а атака выполнима только теми, у кого есть власть над такими процессами (администраторы сервера разработчика, персонал центра сертификации, выдавшего сертификат, по которому защищено соединение) и теми, у кого есть возможность провести атаку типа «человек посередине».
Пример популярного онлайн-решения такого типа — Bitwarden, обладающий множеством настроек безопасности, открытым исходным кодом, возможностью локального хранения паролей и установки двухфакторной аутентификации на случай, если кто-то всё же сможет завладеть вашим мастер-паролем.
Локальные парольные менеджеры не несут многих рисков онлайн-менеджеров паролей: данные хранятся на нашем устройстве, а за безопасность базы паролей отвечает сам пользователь.
Если нужно держать свои пароли под контролем и сохранить свои «секреты», рекомендую рассмотреть KeePassXC, хотя на пентестах чаще встречается KeePass. Оба менеджера имеют открытый исходный код, хранят пароли локально (можно записать базу с паролями на компьютер или на съемный носитель), позволяют хранить как пароли, так и заметки, файлы и другие данные в надежно зашифрованном формате. KeePassXC задуман как кроссплатформенный менеджер паролей, это улучшенная версия предыдущего как с точки зрения безопасности, так и возможностей. Но, в отличие от KeePass, KeePassXC не поддерживает плагины.
Для смартфонов тоже есть совместимые приложения:
KeePass2Android для Android;
Strongbox для iPhone.
Базы паролей формата KeePass настолько часто встречаются при тестировании и обладают такой высокой ценностью, что под них даже есть специальный режим атаки в Hashcat, благодаря чему мастер-пароль можно подобрать довольно быстро.
Поэтому, когда парольный менеджер требует ввести будущий мастер-пароль от нового хранилища, помните, что от сложности этого пароля зависит безопасность всех хранимых данных.
Слабый пароль («admin1», «Qwerty1», «iloveyouverymuch», «P2$#s», …) подбирается с помощью специального ПО (к примеру, «hashcat») за минуты, а иногда — и секунды. Часто это происходит из-за того, что подобный пароль часто встречается, из-за его малой длины и из-за того, что пароль состоит из комбинаций слов. Пароль также может оказаться слабым, если оказался в утечках.
Небольшой рецепт хорошего мастер-пароля: добавьте больших и маленьких символов в непредсказуемых местах, разбавьте цифрами и «посыпьте» специальными символами.
Вот вам пример для вдохновения: R0s11@.pA&jkm9'sPT^#!$
Чтобы запомнить подобный пароль, при его построении можно придумать несуществующее, но «звучащее» слово, попеременно писать его с помощью разных раскладок клавиатуры, заменить часть букв на цифры или на символы, находящиеся над соответствующими буквами на клавиатуре. А когда такой пароль станет слишком привычным, его можно заменить на еще более продуманный и сложный.
В настройках KeePass имеется опция ввода мастер-пароля в окружении «Secure Desktop». Рекомендую включить ее, так как это может спасти базу от кейлоггеров. Кроме того, имеются настройки для защиты с помощью Windows DPAPI (помните Google Chrome?), что может сильно усложнить компрометацию паролей от лица другого пользователя.
По нашему опыту тестирований на проникновение, работники заказчика часто держат свою базу паролей в разблокированном виде значительно дольше, чем необходимо. Для компрометации разблокированных баз имеется инструмент KeeFarce, а для более сложных атак — KeeThief. Требуется лишь запустить его на компьютере с разблокированной базой данных KeePass.
Для защиты в обеих версиях KeePass есть настройки автоблокировки. К примеру, в KeePass рекомендую выставить настройки «Lock workspace after KeePass inactivity», «Lock workspace after global user inactivity» и параметры из блока «General».
При этом столь действенные способы компрометации для KeePassXC найти значительно сложнее. Ради утоления интереса читателя прикрепляю блог-пост разработчиков на тему безопасности хранящихся в памяти данных. Вкратце — приложение очень хорошо защищает пароли :)
Несколько советов по «парольной» безопасности:
Из рассмотренных парольных менеджеров лучше всего себя проявили: локальный парольный менеджер KeePassXC, браузерное расширение с возможностями локального хранения Bitwarden и парольный менеджер браузера Firefox при настроенном мастер-пароле.
Сильный мастер-пароль является одним из самых главных факторов защищенности парольного менеджера, но даже при использовании сильного мастер-пароля не стоит разбрасываться парольной базой.
В случае, если злоумышленник получит мастер-пароль, базу защитит второй фактор.
Важно настроить автоблокировку парольного менеджера. Если база разблокирована, то она подвержена большему числу угроз.
У веб-сервисов бывают утечки, поэтому важно проверять, не оказались ли ваши данные в сети (и сменять пароль в случае утечки). Для этого можно воспользоваться сервисом haveibeenpwned.com или LeakCheck.
Среди атак на пользователей широко распространен фишинг (зачастую выражается в виде поддельной страницы с просьбой ввода учетных данных). Так как браузеры и расширения по умолчанию «связывают» пароли с адресами логин-форм и предлагают автозаполнять формы только на сохраненных страницах, такие средства защищают от фишинга, не подставляя данные на поддельный сайт. Если вы пользуетесь локальным менеджером, то советую также настроить автозаполнение: по умолчанию оно может быть отключено.
Браузеры практически не имеют настроек безопасности и удобного функционала. В свою очередь, менеджеры паролей в виде отдельных решений обладают множеством настроек в обеих «областях».
Статья написана в первую очередь о базах паролей, используемых на конкретных системах, но если вы ищете парольный менеджер для корпоративной среды, то можно рассмотреть PasswordState — это довольно мощный инструмент для корпоративных баз паролей.
В заключение хочу еще раз напомнить, что материал написан исключительно для повышения осведомленности в вопросе хранения паролей. Ни в коем случае не пробуйте приведенные выше действия на чужих системах без разрешения их владельца (лучше письменного). Экспериментируйте на своей собственной системе и со своим хранилищем паролей — так вы лучше усвоите материал и сможете понять, подходит ли вам тот или иной способ хранения паролей. Ну или идите работать пентестером — это интересно и законно.
на главную сниппетов
