Главная » Песочница » Как хакеры взламывают двухфакторную аутентификацию с помощью Modlishka

Как хакеры взламывают двухфакторную аутентификацию с помощью Modlishka

Обход двухфакторной аутентификации с Modlishka

Хакерский форумы изобилуют предложениями о взломе аккаунтов. В большинстве случаев атаки устраивают при помощи фишинга с подделкой страницы авторизации. Однако такой метод неэффективен, если пользователю приходит SMS с проверочным кодом. Я покажу, как хакеры обходят двухфакторную аутентификацию, на примере взлома аккаунта Google редактора сайта «www.spy-soft.net».

Еще по теме: Извлечение паролей из iCloud Keychain

Экскурс в двухфакторную аутентификацию

Раньше, когда сайты работали по HTTP и о защите толком никто и не думал, перехват трафика с учетными данными был совсем простой задачей. Потом трафик стали шифровать, и злоумышлиникам пришлось придумывать более изощренные способы подмены и перенаправления маршрутов. Казалось бы, двухфакторная аутентификация окончательно решила проблему, но все дело в деталях ее реализации.

Метод двухфакторной аутентификации (Two-Factor authentication) был придуман как дополнительный способ подтверждения владельца аккаунта. Он основан на нескольких способах аутентификации:

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

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

Самый популярный метод 2FA — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код приходит каждый раз разный, поэтому угадать его практически невозможно.

Однако чем сложнее преодолеть защиту техническими методами, тем легче бывает это сделать социальной инженерией. Все настолько уверены в надежности двухфакторной аутентификации, что используют ее для самых ответственных операций — от авторизации в Google (а это сразу доступ к почте, диску, контактам и всей хранимой в облаке истории) до систем клиент-банк.

При этом возможность обхода такой системы уже показывал австралийский исследователь Шабхэм Шах (Shubham Shah). Правда, его метод был довольно сложен в практической реализации. В нем использовалась авторизация по звонку, а не SMS, а предварительно нужно было узнать номер телефона жертвы и часть учетных данных. PoC был не особо убедительным, но наметил вектор атаки.

Взлом двухфакторной аутентификации с помощью Modlishka

В начале 2019 года польский исследователь Пётр Душиньский (Piotr Duszyński) выложил в открытом доступе реверс-прокси Modlishka. По его словам, этот инструмент может обойти двухфакторную аутентификацию, что мы сейчас и проверим.

Если сравнить его с тем же SEToolkit (он встроен практически во все популярные дистрибутивы для пентеста), то разница вот в чем: SET клонирует и размещает на локальном сервере страницу авторизации. Там все основано на работе скриптов, которые перехватывают вводимые учетные данные жертвы. Можно, конечно, настроить редирект на оригинальный сайт, но трафик от жертвы до твоего сервера будет незашифрованным. По сути, такого рода программы выступают в роли web-серверов с поддельным (фишинговым) сайтом.

Статья написана в образовательных целях. Цель статьи указать на недостатки двухфакторной аутентификации. Ни автор, ни редакция сайта «www.spy-soft.net» не несут ответственности за любой возможный вред, причиненный материалами данной статье.

Modlishka действует иначе. Генерируется свой сертификат, которым шифруется соединение от жертвы до нашего сервера (чтобы не палиться). Затем эта машина выступает в роли обратного прокси.

Другими словами, весь трафик идет на оригинальный сайт с инстанцией на нашем сервере. У хакера остаются учетные данные, и захватывается авторизованная сессия жертвы. Классическая MITM-атака, которую предваряет фишинг (нужно как-то заставить жертву установить поддельный сертификат и направить ее на фейковый сайт).

Стенд для обхода двухфакторной аутентификации

Давай поднимем сервер с Modlishka внутри локальной машины. Я сделаю это на примере Kali Linux, но принципиальной разницы для других дистрибутивов не будет — разве что слегка изменится путь к исходникам Go.

Вначале ставим Go — на этом языке написан реверс-прокси, и без Go он не скомпилируется.

Следом указываем путь к директории исходников:

Проверить все можно командой

В выводе должен быть указан GOPATH.

Обход двухфакторной аутентификации с помощью Modlishka
Вывод команды

Затем клонируем ветку с инструментом.

Создаем сертификат:

Теперь необходимо перенести содержимое ключа и сертификата в файл plugin/autocert.go и заменить значение двух переменных:

  • const CA_CERT — значение сертификата (файл pem);
  • const CA_CERT_KEY — значение ключа (файл key).
Обход двухфакторной аутентификации с помощью Modlishka
Файл autocert.go после замены сертификата

Теперь собираем все это дело:

Занимает компиляция от трех до десяти минут в зависимости от количества вычислительных ресурсов.

Сам запускаемый файл находится в директории dist/ под названием proxy. Для проверки можно запустить с ключом -h — вывод справки.

Обход двухфакторной аутентификации с помощью Modlishka
Вывод справки программы Modlishka

Отлов учетных данных и сессий жертвы

Как я писал выше, чтобы создать прозрачный для жертвы шифрованный канал до нашего реверс-прокси, необходимо сперва экспортировать в браузер сертификат. Дальнейшие действия разбираются на примере Mozilla Firefox x64 v. 67.0.

Перед запуском взглянем внимательно на содержимое еще одного файла в директории templates. Нам интересен google.com_gsuite.json. Подробное описание каждого пункта можно найти в гайде по этому конфигу.

взлом двухфакторной аутентификации с помощью Modlishka
Содержимое файла google.com_gsuite.json

Есть два варианта запуска Modlishka: вручную и с помощью конфигурационного файла. Для запуска вручную минимальная команда выглядит так:

Запуск с использованием конфигурационного файла:

Запустим из конфига и перейдем в браузере по адресу loopback.modlishka.io. Нам откроется страница google.com. Входим в аккаунт и видим, как в выводе терминала появляются учетные данные жертвы.

взлом двухфакторной аутентификации с Modlishka
Логин и пароль в выводе Modlishka

Если перейти по адресу loopback.modlishka.io/SayHello2Modlishka (очень символично), то получим консоль управления перехваченной сессией (в данный момент это бета-функция). На данном этапе мы перехватили логин и пароль жертвы безо всяких ошибок с шифрованием и в «защищенном» соединении. Насколько мне известно, другие инструменты аналогичного назначения такого не умеют.

Что же теперь делать с двухфакторной аутентификацией? А вот что: в панели управления есть незаполненное поле UUID, и эта цифра — ключ ко всему.

Если сразу нажать на кнопку Impersonate user (beta), то откроется пустая вкладка, и в консоли Modlishka нам подскажет, что нет UID пользователя. Его необходимо задать, а задается он в самом начале — указывается в ссылке на наш злой URL. Для этого вернемся к конфигурационному файлу.

Нам интересна строка «trackingParam»: «ident». В ней необходимо задать значение ident, чтобы наш URL выглядел следующим образом:

Именно на такой (или дополнительно обфусцированный) URL необходимо направить жертву.

На этот раз, после перехода и авторизации по такой ссылке, в панели управления (loopback.modlishka.io/SayHello2Modlishka) будет доступна сессия с заполненным UUID. Как именно это выглядит, я покажу чуть позже на реальном примере.

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

Хоть я и привел Wiki по всем параметрам конфигурационного файла, есть еще один момент. После того как жертва ввела учетные данные, желательно предотвратить выход из аккаунта и сохранить авторизованную сессию. Это делает параметр terminateTriggers. Если в этом параметре указать URL, на который попадет пользователь после успешной авторизации, то при появлении такого адреса весь трафик начнет перенаправляться на оригинальный URL, а авторизованная сессия не будет тронута даже после выхода из аккаунта.

Готовый комплект за NAT

Атаковать внутри одной машины или ЛВС оказалось не так сложно, а вот с подготовкой в качестве PoC «боевого» стенда в WWW у меня поначалу вышла заминка. Для него понадобится либо перенаправление на белый (внешний) IP-адрес, либо выделенный сервер с таким адресом. Арендовать сервер можно от 300 рублей в месяц.

Когда я поднимал этот сервер на Kali Linux, проблем не было. На VDS стояла Ubuntu Server 16.4, и при установке Golang оказалось, что в указанных по умолчанию репозиториях лежит очень старая версия Go, которая при компиляции выдавала массу ошибок. В таком случае необходимо добавить актуальные репозитории Go и установить свежую версию.

Первая проблема заключается в доменном имени. Если перейти с компьютера жертвы на URL loopback.modlishka.io, то ничего не выйдет, так как внешние и неподконтрольные нам DNS не знают такого адреса. Если же перенаправить на IP-адрес машины с Modlishka, то жертва попадет прямиком на страницу Google, минуя прокси-сервер, а в выводе терминала увидим две строки:

Если жертва в той же локальной сети, то можно задать соответствие IP — URL в местном DNS или в ее файле hosts. В моем случае это было так:

В интернете я сначала попробовал зарегистрировать бесплатный домен 3-го уровня. Предполагал, что этого хватит, но не тут-то было! При переходе оказывалась лишь страница, что сайт недоступен, а при вводе IP-адреса через HTTPS редиректило на Google. По простому HTTP и вовсе открывалась приветственная страница Apache.

Как обычно, дьявол кроется в деталях. При переходе по URL в глобальной сети автоматом добавляется префикс www, а программа ждала чистого обращения к домену. Добавление www в конфиг не помогло, и пришлось добывать в свои владения полный пул поддоменов. Другими словами, если домен выглядит как loopback.modlishka.io, то иметь необходимо *.loopback.modlishka.io.

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

Идем на любой генератор сертификатов, делаем и скачиваем два файла. Их содержимое надо подставить в конфигурационный файл Modlishka соответственно полям «cert»: «» и «certKey»: «». Небольшая ремарка: сертификат и ключ должны указываться в одну строку, а перенос строки, как обычно, задается последовательностью \n.

Выглядеть должно примерно так:

Также в конфигурационном файле нам необходимо изменить пару других параметров:

  • «phishingDomain»: «loopback.modlishka.io» — тут вместо loopback.modlishka.io подставляем свой домен;
  • «listeningAddress»: «127.0.0.1» — нужно заменить на 0.0.0.0, иначе прослушивается лишь lo-интерфейс, а работать все будет только внутри локальной машины.

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

Обход двухфакторной аутентификации

Этот стенд я тестировал с редактором сайта «www.spy-soft.net», который выступал в роли очень наивной жертвы. На google.com адрес моего домена ничуть не похож, но мы решили пропустить обфускацию. Об этом уже была отдельная статья, и не одна.

Результаты совместного эксперимента можно увидеть на скриншотах. Андрей находился в другом городе и поэтому ничего не мог мне сделать подключался через другого провайдера, заходя на мой фишинговый сайт через десктопный Firefox v. 67.0.

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

взлом двухфакторной аутентификации с Modlishka
Жертва ставит сертификат

В адресной строке творится безобразие, но мало кто в нее смотрит (на мобильных браузерах она вообще скрывается для экономии места на экране). Зеленый замочек «защищенного» соединения вселяет уверенность, а панель авторизации Google вообще загружается оригинальная.

взлом двухфакторной аутентификации с Modlishka
Ловушка для невнимательных

Первый этап прошел успешно — Андрей ввел свой логин и пароль, после чего Google отправил ему одноразовый код подтверждения в SMS.

взлом двухфакторной аутентификации с Modlishka
Запрос кода подтверждения

Меньше чем через минуту Андрей вводит его в стандартное поле верификации. Он вошел в свой аккаунт… и я тоже!

обход двухфакторной аутентификации с Modlishka
Полный перехват авторизации

После этого мне открылась полная свобода действий. Почта, диск, контакты, история браузера, история географических перемещений, списки установленных приложений, сохраненные пароли точек доступа Wi-Fi и бэкапы. Просто цифровой Клондайк!

Обход двухфакторной аутентификации с помощью Modlishka
Взломанная почта

Самое главное — удалось перехватить активную сессию.

обход двухфакторной аутентификации с Modlishka
Панель управления Modlishka

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

Итого

Сессия в панели управления Modlishka очень живучая. Она не умирает до тех пор, пока из нее самой не выйдет пользователь (либо хакер). То есть, если жертва закроет вкладку, авторизованная сессия останется активной. Если заново авторизоваться напрямую на google.com, а потом выйти из аккаунта, то сессия все равно останется живой. Даже если остановить сервер Modlishka и запустить его заново — сессия все равно остается. Есть только одна гарантированная возможность деавторизации — выйти в тот момент, когда только «редиректишься» на прокси.

Хоть в статье и были описаны технические детали, обход двухфакторной аутентификации не сработает без социальной инженерии. Нужно замаскировать сайт и как-то установить сертификат на компьютер жертвы. Впрочем, это может оказаться не так уж сложно. Большинство пользователей охотно выполняют инструкции, начинающиеся со слов «отключите антивирус и файрвол», а уж в установке сертификата мало кто из обывателей увидит потенциальную опасность.

Еще по теме: Как хакеры скрывают вирусы в документах Office

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

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