Взлом 2FA: Как хакеры обходят двухфакторную аутентификацию
С ростом киберпреступности использование пароля, как основного способа защиты, уже не является панацей. Брутфорс, фишинговые атаки и утечки данных еще раз доказывают, что для защиты учетных записей необходим более надежный подход. В качестве решения этих проблем появилась многофакторная аутентификация. Однако, хакеры и тут нашли лазейку. Сегодня мы расскажем, как именно злоумышленники обходят двухфакторную аутентификацию.
Ликбез по 2FA
Еще совсем недавно никто и не думал о защите информации, и перехват трафика с учетными данными был легкой задачей. Позже, когда трафик стали шифровать, хакеры были вынуждены искать более изощренные способы подмены и перенаправления маршрутов.
Двухфакторная аутентификация ввела дополнительный уровень безопасности. В добавок к паролю появился второй фактор для подтверждения своей личности, который обычно включает в себя одну из трех категорий:
Самый популярный метод двухфакторной аутентификации среди всех пользователей — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код доступа меняется каждый раз, поэтому угадать его практически невозможно.
Казалось бы, двухфакторная аутентификация обеспечила высокий уровень безопасности, но не тут то было. В начале 2019 года в открытом доступе появился реверс-прокси Modlishka, который, по словам создателя, может обойти двухфакторную аутентификацию.
Работает этот инструмент следующим образом: Modlishka размещается между жертвой и целевым сайтом, и когда пользователь подключается к серверу Modlishka на фишинговом домене, обратный прокси обращается к настоящему сайту, за который пытается себя выдать. В итоге жертва видит контент с настоящего сайта, однако весь ее трафик при этом проходит через сервер Modlishka. Также, иинструмент помогает перехватывать введенные пользователем одноразовые коды двухфакторной аутентификации.
Взлом 2FA
Мы продемонстрируем вам, как работает инструмент Modlishka на примере Kali Linux.
Прежде всего вам нужно установить 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 и заменить значение двух переменных:
Файл autocert.go после замены сертификатаТеперь собираем все это дело:
Занимает компиляция от трех до десяти минут в зависимости от количества вычислительных ресурсов.
Сам запускаемый файл находится в директории 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.
Есть еще один момент, о котором нигде не сказано: после того как жертва ввела учетные данные, желательно предотвратить выход из аккаунта и сохранить авторизованную сессию. Это делает параметр terminateTriggers. Если в этом параметре указать URL, на который попадет пользователь после успешной авторизации, то при появлении такого адреса весь трафик начнет перенаправляться на оригинальный URL, а авторизованная сессия не будет тронута даже после выхода из аккаунта.
Сессия в панели управления Modlishka не закрывается до тех пор, пока из нее самой не выйдет пользователь (либо хакер). То есть, если жертва закроет вкладку, авторизованная сессия останется активной. Если заново авторизоваться напрямую на google.com, а потом выйти из аккаунта, то сессия все равно будет активной. Даже если закрыть сервер Modlishka и запустить его заново — сессия все равно еще останется. Есть только одна гарантированная возможность деавторизации — выйти в тот момент, когда только «редиректишься» на прокси.
Заключение
Таким образом, мы убедились, что двухфакторная аутентификация не является 100% надежным способом защиты. Для обеспечения безопасности необходимо комбинировать несколько уровней проверки, прибегая к трехфакторной аутентификации.
Читайте также: Эволюция MFA: все, что вам нужно знать о многофакторной аутентификации
С ростом киберпреступности использование пароля, как основного способа защиты, уже не является панацей. Брутфорс, фишинговые атаки и утечки данных еще раз доказывают, что для защиты учетных записей необходим более надежный подход. В качестве решения этих проблем появилась многофакторная аутентификация. Однако, хакеры и тут нашли лазейку. Сегодня мы расскажем, как именно злоумышленники обходят двухфакторную аутентификацию.

Еще совсем недавно никто и не думал о защите информации, и перехват трафика с учетными данными был легкой задачей. Позже, когда трафик стали шифровать, хакеры были вынуждены искать более изощренные способы подмены и перенаправления маршрутов.
Двухфакторная аутентификация ввела дополнительный уровень безопасности. В добавок к паролю появился второй фактор для подтверждения своей личности, который обычно включает в себя одну из трех категорий:
- Что-то, что знает пользователь: это может быть любой секретный вопрос: кличка питомца или девичья фамилия матери.
- Что-то, чем является пользователь: сюда входят биометрические данные, такие как отпечатки пальцев, сканирование радужной оболочки или распознавание лиц.
- Что-то, чем владеет пользователь: например, номер телефона, на который приходят СМС.
Самый популярный метод двухфакторной аутентификации среди всех пользователей — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код доступа меняется каждый раз, поэтому угадать его практически невозможно.
Казалось бы, двухфакторная аутентификация обеспечила высокий уровень безопасности, но не тут то было. В начале 2019 года в открытом доступе появился реверс-прокси Modlishka, который, по словам создателя, может обойти двухфакторную аутентификацию.
Работает этот инструмент следующим образом: Modlishka размещается между жертвой и целевым сайтом, и когда пользователь подключается к серверу Modlishka на фишинговом домене, обратный прокси обращается к настоящему сайту, за который пытается себя выдать. В итоге жертва видит контент с настоящего сайта, однако весь ее трафик при этом проходит через сервер Modlishka. Также, иинструмент помогает перехватывать введенные пользователем одноразовые коды двухфакторной аутентификации.
Взлом 2FA
Мы продемонстрируем вам, как работает инструмент Modlishka на примере Kali Linux.
Прежде всего вам нужно установить 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).

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

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

Для запуска вручную минимальная команда выглядит так:
$ ./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.
Входим в аккаунт и видим, как в выводе терминала появляются учетные данные жертвы.

Что же теперь делать с двухфакторной аутентификацией?
А вот что: в панели управления есть незаполненное поле 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.
Есть еще один момент, о котором нигде не сказано: после того как жертва ввела учетные данные, желательно предотвратить выход из аккаунта и сохранить авторизованную сессию. Это делает параметр terminateTriggers. Если в этом параметре указать URL, на который попадет пользователь после успешной авторизации, то при появлении такого адреса весь трафик начнет перенаправляться на оригинальный URL, а авторизованная сессия не будет тронута даже после выхода из аккаунта.
Сессия в панели управления Modlishka не закрывается до тех пор, пока из нее самой не выйдет пользователь (либо хакер). То есть, если жертва закроет вкладку, авторизованная сессия останется активной. Если заново авторизоваться напрямую на google.com, а потом выйти из аккаунта, то сессия все равно будет активной. Даже если закрыть сервер Modlishka и запустить его заново — сессия все равно еще останется. Есть только одна гарантированная возможность деавторизации — выйти в тот момент, когда только «редиректишься» на прокси.
Заключение
Таким образом, мы убедились, что двухфакторная аутентификация не является 100% надежным способом защиты. Для обеспечения безопасности необходимо комбинировать несколько уровней проверки, прибегая к трехфакторной аутентификации.
Читайте также: Эволюция MFA: все, что вам нужно знать о многофакторной аутентификации
Комментарий