Взлом двухфакторной аутентификации.
Хакерский форумы изобилуют предложениями о взломе аккаунтов. В большинстве случаев атаки устраивают при помощи фишинга с подделкой страницы авторизации. Однако такой метод неэффективен, если пользователю приходит SMS с проверочным кодом. Я покажу, как хакеры обходят двухфакторную аутентификацию, на примере взлома аккаунта Google
Экскурс в двухфакторную аутентификацию
Раньше, когда сайты работали по HTTP и о защите толком никто и не думал, перехват трафика с учетными данными был совсем простой задачей. Потом трафик стали шифровать, и злоумышлиникам пришлось придумывать более изощренные способы подмены и перенаправления маршрутов. Казалось бы, двухфакторная аутентификация окончательно решила проблему, но все дело в деталях ее реализации.
Метод двухфакторной аутентификации (Two-Factor authentication) был придуман как дополнительный способ подтверждения владельца аккаунта. Он основан на нескольких способах аутентификации:
Самый популярный метод 2FA — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код приходит каждый раз разный, поэтому угадать его практически невозможно.
Однако чем сложнее преодолеть защиту техническими методами, тем легче бывает это сделать социальной инженерией. Все настолько уверены в надежности двухфакторной аутентификации, что используют ее для самых ответственных операций — от авторизации в Google (а это сразу доступ к почте, диску, контактам и всей хранимой в облаке истории) до систем клиент-банк.
При этом возможность обхода такой системы уже показывал австралийский исследователь Шабхэм Шах (Shubham Shah). Правда, его метод был довольно сложен в практической реализации. В нем использовалась авторизация по звонку, а не SMS, а предварительно нужно было узнать номер телефона жертвы и часть учетных данных. PoC был не особо убедительным, но наметил вектор атаки.
Взлом двухфакторной аутентификации с помощью Modlishka
В начале 2019 года польский исследователь Пётр Душиньский (Piotr Duszyński) выложил в открытом доступе реверс-прокси Modlishka. По его словам, этот инструмент может обойти двухфакторную аутентификацию, что мы сейчас и проверим.
Если сравнить его с тем же SEToolkit (он встроен практически во все популярные дистрибутивы для пентеста), то разница вот в чем: SET клонирует и размещает на локальном сервере страницу авторизации. Там все основано на работе скриптов, которые перехватывают вводимые учетные данные жертвы. Можно, конечно, настроить редирект на оригинальный сайт, но трафик от жертвы до твоего сервера будет незашифрованным. По сути, такого рода программы выступают в роли web-серверов с поддельным (фишинговым) сайтом.
Статья написана в образовательных целях. Цель статьи указать на недостатки двухфакторной аутентификации.
Modlishka действует иначе. Генерируется свой сертификат, которым шифруется соединение от жертвы до нашего сервера (чтобы не палиться). Затем эта машина выступает в роли обратного прокси.
Другими словами, весь трафик идет на оригинальный сайт с инстанцией на нашем сервере. У хакера остаются учетные данные, и захватывается авторизованная сессия жертвы. Классическая MITM-атака, которую предваряет фишинг (нужно как-то заставить жертву установить поддельный сертификат и направить ее на фейковый сайт).
Стенд для обхода двухфакторной аутентификации
Давай поднимем сервер с Modlishka внутри локальной машины. Я сделаю это на примере Kali Linux, но принципиальной разницы для других дистрибутивов не будет — разве что слегка изменится путь к исходникам Go.
Вначале ставим Go— на этом языке написан реверс-прокси, и без Go он не скомпилируется.
$ apt-get install golang
Следом указываем путь к директории исходников:
$ export GOPATH='/root/go'
Проверить все можно командой
$ go env
В выводе должен быть указан 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 и заменить значение двух переменных:
Файл autocert.go после замены сертификата
Теперь собираем все это дело:
$ make
Занимает компиляция от трех до десяти минут в зависимости от количества вычислительных ресурсов.
Сам запускаемый файл находится в директории dist/ под названием proxy. Для проверки можно запустить с ключом -h — вывод справки.
$ ./dist/proxy -h
Вывод справки программы Modlishka
Отлов учетных данных и сессий жертвы
Как я писал выше, чтобы создать прозрачный для жертвы шифрованный канал до нашего реверс-прокси, необходимо сперва экспортировать в браузер сертификат. Дальнейшие действия разбираются на примере Mozilla Firefox x64 v. 67.0.
Перед запуском взглянем внимательно на содержимое еще одного файла в директории templates. Нам интересен google.com_gsuite.json. Подробное описание каждого пункта можно найти в гайде по этому конфигу.
Содержимое файла google.com_gsuite.json
Есть два варианта запуска Modlishka: вручную и с помощью конфигурационного файла. Для запуска вручную минимальная команда выглядит так:
$ ./dist/proxy -target https://google.com -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 выглядел следующим образом:
https://loopback.modlishka.io/?ident=1
Именно на такой (или дополнительно обфусцированный) URL необходимо направить жертву.
На этот раз, после перехода и авторизации по такой ссылке, в панели управления (loopback.modlishka.io/SayHello2Modlishka) будет доступна сессия с заполненным UUID. Как именно это выглядит, я покажу чуть позже на реальном примере.
Теперь при нажатии на большую желтую кнопку мы увидим красивую синюю анимацию и через пять-десять секунд попадем в авторизованную сессию жертвы, невзирая на трудности двухфакторной авторизации. Жертва, как обычно, получит и введет подтверждающий код, видя зашифрованное соединение и настоящую панель авторизации Google, но не замечая вклинившегося посередине реверс-прокси Modlishka.
Хоть я и привел Wiki по всем параметрам конфигурационного файла, есть еще один момент. После того как жертва ввела учетные данные, желательно предотвратить выход из аккаунта и сохранить авторизованную сессию. Это делает параметр terminateTriggers. Если в этом параметре указать URL, на который попадет пользователь после успешной авторизации, то при появлении такого адреса весь трафик начнет перенаправляться на оригинальный URL, а авторизованная сессия не будет тронута даже после выхода из аккаунта.
Хакерский форумы изобилуют предложениями о взломе аккаунтов. В большинстве случаев атаки устраивают при помощи фишинга с подделкой страницы авторизации. Однако такой метод неэффективен, если пользователю приходит SMS с проверочным кодом. Я покажу, как хакеры обходят двухфакторную аутентификацию, на примере взлома аккаунта Google
Экскурс в двухфакторную аутентификацию
Раньше, когда сайты работали по HTTP и о защите толком никто и не думал, перехват трафика с учетными данными был совсем простой задачей. Потом трафик стали шифровать, и злоумышлиникам пришлось придумывать более изощренные способы подмены и перенаправления маршрутов. Казалось бы, двухфакторная аутентификация окончательно решила проблему, но все дело в деталях ее реализации.
Метод двухфакторной аутентификации (Two-Factor authentication) был придуман как дополнительный способ подтверждения владельца аккаунта. Он основан на нескольких способах аутентификации:
- пользователь что-то знает (например, может ответить, какая была девичья фамилия его матери или кличка первого домашнего питомца);
- пользователь обладает уникальными чертами, которые можно оцифровать и сравнить (биометрическая аутентификация);
- пользователь имеет девайс с уникальным идентификатором (например, номер мобильного, флешку с ключевым файлом).
Самый популярный метод 2FA — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код приходит каждый раз разный, поэтому угадать его практически невозможно.
Однако чем сложнее преодолеть защиту техническими методами, тем легче бывает это сделать социальной инженерией. Все настолько уверены в надежности двухфакторной аутентификации, что используют ее для самых ответственных операций — от авторизации в Google (а это сразу доступ к почте, диску, контактам и всей хранимой в облаке истории) до систем клиент-банк.
При этом возможность обхода такой системы уже показывал австралийский исследователь Шабхэм Шах (Shubham Shah). Правда, его метод был довольно сложен в практической реализации. В нем использовалась авторизация по звонку, а не SMS, а предварительно нужно было узнать номер телефона жертвы и часть учетных данных. PoC был не особо убедительным, но наметил вектор атаки.
Взлом двухфакторной аутентификации с помощью Modlishka
В начале 2019 года польский исследователь Пётр Душиньский (Piotr Duszyński) выложил в открытом доступе реверс-прокси Modlishka. По его словам, этот инструмент может обойти двухфакторную аутентификацию, что мы сейчас и проверим.
Если сравнить его с тем же SEToolkit (он встроен практически во все популярные дистрибутивы для пентеста), то разница вот в чем: SET клонирует и размещает на локальном сервере страницу авторизации. Там все основано на работе скриптов, которые перехватывают вводимые учетные данные жертвы. Можно, конечно, настроить редирект на оригинальный сайт, но трафик от жертвы до твоего сервера будет незашифрованным. По сути, такого рода программы выступают в роли web-серверов с поддельным (фишинговым) сайтом.
Статья написана в образовательных целях. Цель статьи указать на недостатки двухфакторной аутентификации.
Modlishka действует иначе. Генерируется свой сертификат, которым шифруется соединение от жертвы до нашего сервера (чтобы не палиться). Затем эта машина выступает в роли обратного прокси.
Другими словами, весь трафик идет на оригинальный сайт с инстанцией на нашем сервере. У хакера остаются учетные данные, и захватывается авторизованная сессия жертвы. Классическая MITM-атака, которую предваряет фишинг (нужно как-то заставить жертву установить поддельный сертификат и направить ее на фейковый сайт).
Стенд для обхода двухфакторной аутентификации
Давай поднимем сервер с Modlishka внутри локальной машины. Я сделаю это на примере Kali Linux, но принципиальной разницы для других дистрибутивов не будет — разве что слегка изменится путь к исходникам Go.
Вначале ставим Go— на этом языке написан реверс-прокси, и без Go он не скомпилируется.
$ apt-get install golang
Следом указываем путь к директории исходников:
$ export GOPATH='/root/go'
Проверить все можно командой
$ go env
В выводе должен быть указан 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 после замены сертификата
Теперь собираем все это дело:
$ make
Занимает компиляция от трех до десяти минут в зависимости от количества вычислительных ресурсов.
Сам запускаемый файл находится в директории dist/ под названием proxy. Для проверки можно запустить с ключом -h — вывод справки.
$ ./dist/proxy -h
Вывод справки программы Modlishka
Отлов учетных данных и сессий жертвы
Как я писал выше, чтобы создать прозрачный для жертвы шифрованный канал до нашего реверс-прокси, необходимо сперва экспортировать в браузер сертификат. Дальнейшие действия разбираются на примере Mozilla Firefox x64 v. 67.0.
Перед запуском взглянем внимательно на содержимое еще одного файла в директории templates. Нам интересен google.com_gsuite.json. Подробное описание каждого пункта можно найти в гайде по этому конфигу.
Содержимое файла google.com_gsuite.json
Есть два варианта запуска Modlishka: вручную и с помощью конфигурационного файла. Для запуска вручную минимальная команда выглядит так:
$ ./dist/proxy -target https://google.com -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 выглядел следующим образом:
https://loopback.modlishka.io/?ident=1
Именно на такой (или дополнительно обфусцированный) URL необходимо направить жертву.
На этот раз, после перехода и авторизации по такой ссылке, в панели управления (loopback.modlishka.io/SayHello2Modlishka) будет доступна сессия с заполненным UUID. Как именно это выглядит, я покажу чуть позже на реальном примере.
Теперь при нажатии на большую желтую кнопку мы увидим красивую синюю анимацию и через пять-десять секунд попадем в авторизованную сессию жертвы, невзирая на трудности двухфакторной авторизации. Жертва, как обычно, получит и введет подтверждающий код, видя зашифрованное соединение и настоящую панель авторизации Google, но не замечая вклинившегося посередине реверс-прокси Modlishka.
Хоть я и привел Wiki по всем параметрам конфигурационного файла, есть еще один момент. После того как жертва ввела учетные данные, желательно предотвратить выход из аккаунта и сохранить авторизованную сессию. Это делает параметр terminateTriggers. Если в этом параметре указать URL, на который попадет пользователь после успешной авторизации, то при появлении такого адреса весь трафик начнет перенаправляться на оригинальный URL, а авторизованная сессия не будет тронута даже после выхода из аккаунта.
