Прежде чем приступить, скажу что ниже изложенная информация дана исключительно в образовательных целях и не является призывом к действию.Хакерские форумы изобилуют предложениями о взломе аккаунтов. В большинстве случаев атаки устраивают при помощи фишинга с подделкой страницы авторизации. Однако, такой метод неэффективен, если пользователю приходит SMS с проверочным кодом. Прямо сейчас мы покажем, как хакеры обходят двухфакторную аутентификацию.
Погнали!
Экскурс в двухфакторную аутентификацию
Раньше, когда сайты работали по HTTP и о защите толком никто и не думал, перехват трафика с учетными данными был совсем простой задачей. Потом трафик стали шифровать, и нам (хакерам) пришлось придумывать более изощренные способы подмены и перенаправления маршрутов. Казалось бы, двухфакторная аутентификация окончательно решила проблему, но все дело в деталях ее реализации.Метод двухфакторной аутентификации (Two-Factor authentication) был придуман как дополнительный способ подтверждения владельца аккаунта. Он основан на нескольких способах аутентификации:
- Пользователь что-то знает (например, может ответить, какая была девичья фамилия его матери или кличка первого домашнего питомца);
- Пользователь обладает уникальными чертами, которые можно оцифровать и сравнить (биометрическая аутентификация);
- Пользователь имеет девайс с уникальным идентификатором (например, номер мобильного, флешку с ключевым файлом).
Самый популярный метод 2FA — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код приходит каждый раз разный, поэтому угадать его практически невозможно.
Однако, чем сложнее преодолеть защиту техническими методами, тем легче бывает это сделать социальной инженерией.
Все настолько уверены в надежности двухфакторной аутентификации, что используют ее для самых ответственных операций — от авторизации в Google (а это сразу доступ к почте, диску, контактам и всей хранимой в облаке истории) до систем клиент-банк.
Взлом двухфакторной аутентификации с помощью Modlishka
В начале 2019 года в открытом доступе появился реверс-прокси .Если сравнить его с тем же (он встроен практически во все популярные дистрибутивы для пентеста), то разница вот в чем: SET клонирует и размещает на локальном сервере страницу авторизации. Там все основано на работе скриптов, которые перехватывают вводимые учетные данные жертвы. Можно, конечно, настроить редирект на оригинальный сайт, но трафик от жертвы до вашего сервера будет незашифрованным. По сути, такого рода программы выступают в роли web-серверов с поддельным (фишинговым) сайтом.
Modlishka действует иначе. Генерируется свой сертификат, которым шифруется соединение от жертвы до нашего сервера (чтобы не палиться). Затем эта машина выступает в роли обратного прокси.
Другими словами, весь трафик идет на оригинальный сайт с инстанцией на нашем сервере. У хакера остаются учетные данные, и захватывается авторизованная сессия жертвы. Классическая MITM-атака, которую предваряет фишинг (нужно как-то заставить жертву установить поддельный сертификат и направить ее на фейковый сайт).
К оружию!
Давайте поднимем сервер с Modlishka внутри локальной машины. Мы сделаем это на примере Kali Linux, но принципиальной разницы для других дистрибутивов не будет — разве что слегка изменится путь к исходникам Go.Вначале ставим — на этом языке написан реверс-прокси, и без Go он не скомпилируется.
Следом указываем путь к директории исходников:
$ export GOPATH='/root/go'
Проверить все можно командой.
В выводе должен быть указан GOPATH.
Вывод команды.
Затем клонируем ветку с инструментом:
$ go get -u github.com/drk1wi/Modlishka
$ cd /root/go/src/github.com/drk1wi/Modlishka/
Создаем сертификат:
$ openssl genrsa -out secret.key 2048
$ openssl req -x509 -new -nodes -key secret.key -sha256 -days 1024 -out cert.pem
Теперь необходимо перенести содержимое ключа и сертификата в файл plugin/autocert.go и заменить значение двух переменных:
- const CA_CERT — значение сертификата (файл pem);
- const CA_CERT_KEY — значение ключа (файл key).
Файл autocert.go после замены сертификата.
Теперь собираем все это дело:
Занимает компиляция от трех до десяти минут в зависимости от количества вычислительных ресурсов.
Сам запускаемый файл находится в директории dist/ под названием proxy. Для проверки можно запустить с ключом -h — вывод справки.
Вывод справки программы Modlishka.
Как мы писали выше, чтобы создать прозрачный для жертвы шифрованный канал до нашего реверс-прокси, необходимо сперва экспортировать в браузер сертификат. Дальнейшие действия разбираются на примере Mozilla Firefox x64 v. 67.0.
Перед запуском взглянем внимательно на содержимое еще одного файла в директории templates. Нам интересен . Подробное описание каждого пункта можно найти в по этому конфигу.
Содержимое файла google.com_gsuite.json.
Есть два варианта запуска Modlishka: вручную и с помощью конфигурационного файла.
Для запуска вручную минимальная команда выглядит так:
$ ./dist/proxy -target -phishingDomain loopback.modlishka.io -listeningPort 443 -tls
Запуск с использованием конфигурационного файла:
$ ./dist/proxy -config /templates/google.com_gsuite.json
Запустим из конфига и перейдем в браузере по адресу loopback.modlishka.io. Нам откроется страница google.com.
Входим в аккаунт и видим, как в выводе терминала появляются учетные данные жертвы.
Логин и пароль в выводе Modlishka.
Если перейти по адресу loopback.modlishka.io/SayHello2Modlishka (очень символично), то получим консоль управления перехваченной сессией (в данный момент это бета-функция). На данном этапе мы перехватили логин и пароль жертвы безо всяких ошибок с шифрованием и в «защищенном» соединении. Насколько мне известно, другие инструменты аналогичного назначения такого не умеют.
Что же теперь делать с двухфакторной аутентификацией?
А вот что: в панели управления есть незаполненное поле UUID, и эта цифра — ключ ко всему.
Если сразу нажать на кнопку Impersonate user (beta), то откроется пустая вкладка, и в консоли Modlishka нам подскажет, что нет UID пользователя. Его необходимо задать, а задается он в самом начале — указывается в ссылке на наш злой URL. Для этого вернемся к конфигурационному файлу.
Нам интересна строка «trackingParam»: «ident». В ней необходимо задать значение ident, чтобы наш URL выглядел следующим образом:
Именно на такой (или дополнительно обфусцированный) URL необходимо направить жертву.
На этот раз, после перехода и авторизации по такой ссылке, в панели управления (loopback.modlishka.io/SayHello2Modlishka) будет доступна сессия с заполненным UUID. Как именно это выглядит, мы покажем чуть позже на реальном примере.
Теперь при нажатии на большую желтую кнопку мы увидим красивую синюю анимацию и через пять-десять секунд попадем в авторизованную сессию жертвы, невзирая на трудности двухфакторной авторизации. Жертва, как обычно, получит и введет подтверждающий код, видя зашифрованное соединение и настоящую панель авторизации Google, но не замечая вклинившегося посередине реверс-прокси Modlishka.
Есть еще один момент, о котором нигде не сказано: после того как жертва ввела учетные данные, желательно предотвратить выход из аккаунта и сохранить авторизованную сессию. Это делает параметр terminateTriggers. Если в этом параметре указать URL, на который попадет пользователь после успешной авторизации, то при появлении такого адреса весь трафик начнет перенаправляться на оригинальный URL, а авторизованная сессия не будет тронута даже после выхода из аккаунта.
Итого
Сессия в панели управления Modlishka очень живучая. Она не умирает до тех пор, пока из нее самой не выйдет пользователь (либо хакер). То есть, если жертва закроет вкладку, авторизованная сессия останется активной. Если заново авторизоваться напрямую на google.com, а потом выйти из аккаунта, то сессия все равно останется живой. Даже если остановить сервер Modlishka и запустить его заново — сессия все равно остается. Есть только одна гарантированная возможность деавторизации — выйти в тот момент, когда только «редиректишься» на прокси.Хоть в статье и были описаны технические детали, обход двухфакторной аутентификации не сработает без социальной инженерии. Нужно замаскировать сайт и как-то установить сертификат на компьютер жертвы. Впрочем, это может оказаться не так уж сложно. Большинство пользователей охотно выполняют инструкции, начинающиеся со слов «отключите антивирус и файрвол», а уж в установке сертификата мало кто из обывателей увидит потенциальную опасность.
