Двухфакторная аутентификация и возможные способы её обойти
Подробно рассматриваем достоинства и недостатки самого популярного способа защиты учётных записей в Интернете.
Передовые методы обеспечения безопасности учётных записей включают двухфакторную аутентификацию (2FA). Она используется повсеместно как для корпоративных, так и для личных аккаунтов пользователей по всему миру. В классическом понимании этот способ аутентификации подразумевает доставку на телефон или электронную почту специального кода, который необходимо ввести уже после ввода пароля от учётной записи. Однако существуют и другие формы 2FA, которые мы обсудим в этой статье.
Двухфакторная аутентификация обеспечивает дополнительный уровень защиты аккаунта от киберпреступников, но при большом желании злоумышленники всё равно найдут способ её обойти. Именно понимание того, каким образом хакеры обычно обходят 2FA, позволит не попасться на их возможные уловки и обезопасить свою учётную запись.
Что такое двухфакторная аутентификация?
2FA — это второй уровень аутентификации, который используется в дополнении к классической комбинации имени и пароля пользователя при входе в учётную запись. Двухфакторная аутентификация может быть настроена на абсолютно разные способы подтверждения владения аккаунтом. Всё зависит от конкретных потребностей самой системы или пользовательских предпочтений.
Иногда для определённого аккаунта необходим наивысший уровень защиты. Тогда на помощь приходит так называемая «многофакторная аутентификация» (MFA), включающая несколько факторов проверки. Например, пароль + физический токен + биометрия. Такой способ защиты учётной записи гораздо надёжнее классической двухфакторной аутентификации.
Какие типы двухфакторной аутентификации существуют?
Некоторые сервисы и приложения позволяют выбирать, какой тип проверки в дополнении к паролю использовать, а некоторые — нет. Рассмотрим же все возможные варианты 2FA.
2FA по СМС
Этот метод аутентификации требует, чтобы пользователь указал свой номер телефона при первой настройке профиля. Затем при каждом входе в систему (или первом для нового устройства), пользователь должен будет вводить одноразовый код подтверждения (One-Time Password, OTP), состоящий чаще всего из шести цифр. Такой код приходит в виде текстового сообщения на телефон.
Поскольку у большинства людей есть мобильные телефоны с поддержкой SMS, а дополнительных приложений устанавливать не требуется, этот метод проверки является сейчас, вероятно, самым популярным.
Проблемы с 2FA по СМС возникают только при потере сигнала сети или при наличии проблем с работоспособностью телефона.
2FA через голосовой вызов
Этот метод аутентификации подразумевает дозвон на телефон пользователя. При входе в какое-либо мобильное приложение самого факта звонка, как правило, уже достаточно для авторизации, и приложение автоматически подтверждает вход. Но в некоторых сервисах 2FA через телефонный звонок настроен таким образом, что на входящий вызов нужно обязательно ответить, прослушать шестизначный код, озвученный роботом, и затем указать его в форме.
2FA по электронной почте
2FA по электронной почте работает так же, как 2FA по СМС, но одноразовый код подтверждения приходит уже в виде электронного письма на почту пользователя. Одним из вариантов аутентификации по электронной почте является не ввод кода, а переход по уникальной ссылке, который и предоставляет доступ к учётной записи.
2FA по электронной почте требует обязательного подключения к Интернету для получения письма, хотя в современных реалиях можно и не считать это за недостаток. Однако, что точно не является достоинством данного метода, так это частое определение подобных писем как спама. Соответственно, на процесс авторизации из-за поиска письма может уходить больше времени.
К тому же, злоумышленникам элементарно взломать учётную запись с аутентификацией по электронной почте, если у них уже есть доступ к этой самой почте. Когда как аутентификация по СМС вынуждает злоумышленника находиться физически рядом с жертвой; украсть его телефон, чтобы подсмотреть код или прибегнуть к сложной атаке методом SIM-jacking.
2FA через TOTP-приложения для аутентификации
Алгоритм временных одноразовых паролей (Time-based One-time Password Algorithm, TOTP) — это форма проверки, которая требует от пользователя установки на смартфон специального приложения, такого как Microsoft Authenticator, Google Authenticator, Яндекс Ключ и т.п.
Когда пользователь заходит в определённый онлайн-сервис с нового или неизвестного устройства, ему предлагается открыть приложение для проверки подлинности на своём мобильном телефоне. Приложение генерирует временный одноразовый код, длиной от шести до восьми цифр, который обновляется каждые 30 секунд. После ввода этого кода в соответствующую форму, пользователь получает доступ к аккаунту.
Одним из преимуществ приложений-аутентификаторов является то, что их легко внедрить и использовать. Пользователь сразу получает пароль для подтверждения, и ему не нужно ждать письма или СМС. Этот способ также надёжнее, чем 2FA по СМС, потому что код нельзя подсмотреть на экране блокировки или связанном по Bluetooth фитнес-браслете. Смартфон необходимо как минимум разблокировать, а может даже и ввести отдельный пароль для доступа к TOTP-приложению.
Если пользователь не настроил один PIN-код на все случаи жизни, то и взломать его при использовании TOTP-аутентификатора будет крайне непросто.
2FA через аппаратный ключ
Данный метод использует для авторизации физические устройства. Это может быть, например, USB-флешка, вставленная в компьютер, NFC-карта или TOTP-брелок, который генерирует код для авторизации каждые 30/60 секунд.
Аппаратные ключи не требуют подключения к интернету. Это один из самых простых и безопасных методов 2FA. Однако выпуск и обслуживание подобных устройств для каждого пользователя может быть дорогостоящим для бизнеса. А если критически важно, чтобы пользователь носил такой ключ с собой, добавляется ещё и риск потерять его.
6 способов обойти двухфакторную аутентификацию
Несмотря на все достоинства двухфакторной аутентификации, каждый из вышеописанных методов имеет и свои уязвимости. Ниже опишем способы, как именно хакеры могут обойти двухфакторную аутентификацию.
1. Обход 2FA с помощью социальной инженерии
Социальная инженерия — это нетехническая атака, с помощью которой злоумышленник обманом заставляет жертву неосознанно предоставить важную информацию о секретном коде. Уже имея на руках логин и пароль для входа, злоумышленник звонит или отправляет жертве сообщение с убедительным повествованием, призывая передать 2FA-код.
В других случаях злоумышленник уже обладает достаточной базовой информацией о жертве, чтобы позвонить от её имени в службу поддержки целевого сервиса. Преступник может выдать себя за пользователя и сказать, что его учётная запись заблокирована, или есть какие-то неполадки с приложением-аутентификатором. В случае успеха хакер как минимум получит одноразовый доступ к учётной записи жертвы, а если повезёт, то вообще сбросит и поменяет пользовательский пароль.
2. Обход 2FA с помощью открытой авторизации (OAuth)
OAuth — это открытый протокол авторизации, предоставляющий приложениям и сервисам ограниченный доступ к данным пользователя без разглашения пароля. Например, для входа в приложение нужно дать разрешение на частичный доступ к учётной записи VK или Facebook. Таким образом выбранное приложение получает часть полномочий аккаунта, но не хранит в своих базах данные, связанные с паролей пользователя.
При так называемом «фишинге согласия» злоумышленник притворяется законным приложением с авторизацией OAuth и отправляет жертве сообщение с просьбой предоставить доступ. Если жертва даст такой доступ, злоумышленник сможет делать всё, что ему заблагорассудится, в пределах запрошенного доступа. Фишинг согласия позволяет злоумышленнику игнорировать учётные данные и обходить любую настроенную двухфакторную аутентификацию.
3. Обход 2FA с помощью Brute-Force
Иногда злоумышленники выбирают грубый метод «полного перебора», особенно если используется устаревшее или слабозащищённое оборудование. Например, некоторые старые TOTP-брелоки имеют длину кода всего в четыре цифры. Следовательно, их гораздо легче взломать.
Препятствием для хакеров является то, что одноразовые коды, генерируемые такими брелоками, действительны только в течение короткого времени (30/60 секунд). Таким образом, у злоумышленников есть ограниченное количество кодов, которые можно успеть перебрать, прежде чем они изменятся. А если двухфакторная аутентификация настроена корректно, то реализовать атаку такого типа будет в принципе невозможно — пользователя заблокирует после нескольких неверно введённых OTP-кодов.
4. Обход 2FA сгенерированными ранее токенами
Некоторые платформы позволяют пользователям заранее генерировать 2FA-коды. Например, в настройках безопасности Google-аккаунта можно скачать документ с определенным числом резервных кодов, которые можно использовать в будущем для обхода 2FA. Это нужно, как правило, на случай потери устройства, используемого для аутентификации. Но вот если подобный документ или хотя бы один из резервных кодов попадёт в руки злоумышленнику, он легко получит доступ к учётной записи, не взирая на настроенную двухфакторную аутентификацию.
5. Обход 2FA с помощью Cookie-файлов сеанса
Кража cookie-файлов, также известная как захват сеанса, позволяет злоумышленникам получить доступ к аккаунту, не зная вообще никаких паролей или 2FA-кодов.
Когда пользователи входят на сайт, им не нужно каждый раз вводить пароль, потому что браузер хранит специальный cookie-файл сессии. Он содержит информацию о пользователе, поддерживает его аутентификацию в системе и отслеживает активность сеанса. Cookie-файлы сеанса остаются в браузере до тех пор, пока пользователь не выйдет из системы вручную. Таким образом, злоумышленник может использовать cookie в своих интересах для доступа к аккаунту пользователя.
Киберпреступникам известно множество методов захвата аккаунта, таких как перехват и фиксация сеанса, межсайтовый скриптинг и использование вредоносных программ. Кроме того, злоумышленники часто используют фреймворк Evilginx для атак типа «человек посередине». С помощью Evilginx хакер отправляет пользователю фишинговую ссылку, которая перенаправляет его на страницу входа настоящего легитимного сайта, но через специальный вредоносный прокси. Когда пользователь входит в свою учётную запись с помощью 2FA, Evilginx фиксирует его учётные данные для входа, а также код аутентификации.
Поскольку срок действия одноразовых кодов ограничен, а один код нельзя использовать дважды, — хакерам гораздо проще воспользоваться именно методом захвата cookie для входа в систему и обхода двухфакторной аутентификации.
6. Обход 2FA с SIM-jacking
Атака SIM-jacking подразумевает получение злоумышленником полного контроля над телефонным номером жертвы. Преступники, например, могут заблаговременно получить ряд базовых данных о пользователе, а затем «прикинуться» этим самым пользователем в салоне оператора мобильной связи с целью выпуска новой SIM-карты. Также SIM-jacking возможен через вредоносные приложения, установленные на смартфон жертвы.
Контроль над номером телефона пользователя означает, что хакер может перехватывать одноразовые коды, отправленные через 2FA по СМС. А так как это самый популярный способ двухфакторной аутентификации, злоумышленник может взломать один за одним все ключевые учётные записи жертвы и заполучить полный доступ над необходимыми данными.
Как можно сделать 2FA ещё безопаснее?
Несмотря на уязвимости, обнаруженные хакерами, двухфакторная аутентификация по-прежнему является рекомендуемым способом защиты учётных записей в Интернете. Вот несколько советов по эффективному использованию 2FA:
- по возможности используйте приложения-аутентификаторы вместо простой аутентификации по СМС, так как приложения гораздо безопаснее, и одноразовый код нельзя подсмотреть без полного доступа к смартфону;
- никогда и никому не сообщайте одноразовые или резервные коды безопасности;
- используйте длинные коды безопасности, содержащие более шести символов (если сервис допускает такие настройки);
- не используйте для защиты аккаунта простые пароли, лучше сгенерировать пароль в генераторе и использовать его в связке с менеджером паролей;
- не используйте один и тот же пароль в критически важных учётных записях;
- используйте физические ключи безопасности в качестве альтернативной формы аутентификации;
- ознакомьтесь с популярными тактиками социальной инженерии, чтобы не стать жертвой обмана;
- если речь идёт о компании с определённым штатом сотрудников, не лишним будет воспользоваться услугами частного консультанта по безопасности.
Заключение
Несмотря на перечисленные в статье недостатки и методы обхода, двухфакторная аутентификация всё ещё остается одним из лучших способов защиты учётных записей. Достаточно следовать рекомендациям выше, чтобы не оставить злоумышленникам ни малейшего шанса на компрометацию аккаунта. Надеемся, что ваши учётные записи никогда не попадут в лапы мошенникам, а любые конфиденциальные данные останутся в полной безопасности.
Как обезопасить свой смартфон от СЛЕДЯЩИХ ПРИЛОЖЕНИЙ ?
Присоединяйтесь к нашему ТГ каналу и ваш смартфон станет вашим оружием.
Обход двухфакторной аутентификации Google
Злоумышленник может обойти двухфакторную аутентификацию (2ФА) на сервисах Google, сбросить пользовательский пароль и получить полный контроль над аккаунтом, просто заполучив т.н. пароль приложения — ПП (ASP — Application-Specific Passwords).
(При всём уважении к рекламной компании Google «Good to Know»)
Злоупотребление паролями приложений Google
2ФА Google предоставляет материал для исследования различных проблем, непременно возникающих в настолько масштабных системах надежной аутентификации.
Чтобы сделать подобную аутентификацию возможной для всех пользователей (и безболезненно интегрировать её в уже существующую экосистему), инженерам Google пришлось пойти на некоторые компромиссы. Такие, например, как пароли приложений.
Несколько месяцев назад мы нашли способ использовать ПП для получения полного контроля над google аккаунтом, полностью обойдя 2ФА. Мы рассказали о нашей находке службе безопасности Google и недавно получили от них ответ, что они предприняли некоторые шаги для нейтрализации наиболее серьезных угроз из тех, что мы обнаружили. И так, вот что мы нашли:
Пароли приложений
Как только вы включите 2ФА, Google попросит вас создать отдельный пароль для каждого приложения, что вы используете (отсюда и название «пароль приложения»), который не поддерживает 2ФА. Этот пароль Вы используете вместо своего основного. Выражаясь конкретнее, вы создаёте ПП для большинства приложений, которые не используют логин из web-формы: e-mail клиенты, использующие IMAP и SMTP (Apple Mail, Thunderbird, и т.п.); XMPP чат-клиенты (Adium, Pidgin и т.п.), а так же различные календари, синхронизирующиеся с помощью CalDAV (iCal, etc.).
Даже некоторые софт от Google вынуждает вас использовать ПП — например, чтобы включить синхронизацию в Chrome или настроить свой аккаунт на Android устройстве. Совсем недавно эти клиенты в большинстве своём перешли на авторизацию через OAuth. В такой модели, когда вы впервые логинитесь на своём новом устройстве или в приложении, вы получаете запрос на авторизацию в web-форме, которая использует 2ФА. После успешной авторизации, сервер возвращает токен с ограниченным доступом, который в дальнейшем используется для аутентификации вашего устройства/приложения.
На самом деле, OAuth токены и ПП очень сильно похожи — в конечном итоге всё заканчивается созданием уникального авторизационного токена для каждого устройства/приложения, которое вы привязываете к вашему google аккаунту. Кроме того, каждый отдельный токен может быть отозван, без ущерба для остальных: если вы потеряли ваш смартфон, вы можете быть уверены, что никто не сможет получить доступ к вашему почтовому ящику, не имея пароля.
И так, основные отличия между OAuth токенами и ПП следующие:
- OAuth токены создаются автоматически, в то время как ПП нужно создавать вручную. Вам нужно пойти в настройки google аккаунта чтобы его создать, а затем скопировать в приложение.
- OAuth токены предоставляют более гибкую модель авторизации и могут быть использованы для ограничения доступа только к определенным данным или сервисам в вашем аккаунте. С другой стороны, пароли приложений, если уж быть совсем точным, не совсем ТОЛЬКО для приложений!
Authentication at Scale из «IEEE S&P Magazine» vol. 11, no. 1
Получается, ПП могут гораздо, гораздо больше, чем простое получение доступа к вашей почте. На самом деле, они могут быть использованы для аутентификации на большинстве сервисах Google в обход 2ФА!
Авто-логин в Chrome
В последних версиях Android и ChromeOs Google включил в свои браузеры механизм авто-логина в google аккаунты. После того, как вы свяжите ваше устройство с аккаунтом, браузер будет использовать уже существующую авторизацию и перестанет запрашивать её через web-форму. (Есть даже экспериментальная поддержка этой функциональности в десктопной версии Chrome, вы может включить её, открыв «chrome://flags/.»). 
До недавнего времени, этот механизм работал даже для самой важной части google аккаунта — странице настроек. Она включает в себя страницу восстановления пароля, на которой возможно добавление и редактирование e-mail адреса и телефонных номеров, на которые вам будет отослана информация, необходимая для сброса пароля. Короче говоря, если вы сможете получить доступ к этой странице — вы сможете отобрать аккаунт у его законного владельца.
Технические детали
В своём отличном блоге Android Explorations Николай Еленков опубликовал обширное исследование механизма авто-логина в Android. Оно стало отличной отправной точкой, но всё не содержала всю необходимую нам информацию. Мы захотели узнать, как можно использовать этот механизм, не имея Android устройства или Хромбука.
Чтобы сделать это, мы установили перехватывающий прокси, чтобы следить за траффиком между эмулятором Android и серверами Google. Во время добавления google аккаунта, мы увидели следующий запрос:
POST /auth HTTP/1.1
Host: android.clients.google.com
…
accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&add_account=1&EncryptedPasswd=AFcb4. \
&service=ac2dm&source=android&androidId=3281f33679ccc6c6&device_country=us&operatorCountry=us&lang=en&sdk_version=17
Ответ, помимо всего прочего, содержал следующее:
Несмотря на то, что урл и некоторые параметры не документированы, это очень напоминает Google ClientLogin API. Чтобы воссоздать такой запрос самим, нам нужно было понять, что за значения нужно передавать в параметрах «EncryptedPasswd» и «androidId». Со вторым всё оказалось просто — это тот самый параметр «ANDROID_ID», упоминаемый в Android API Docs — случайно сгенерированный 64-битное значение, которое предназначено для однозначной идентификации устройства Android.
Другой пост Еленкова вселил нас надежду, что «EncryptedPasswd» может быть нашем ПП, зашифрованным публичным 1024-битным RSA ключём, который включён в Android платформу. «EncryptedPasswd» являлся бинарными данными(закодированными base64) длинной 130 байт, так что вполне возможно, что так оно и есть. Однако, прежде чем двигаться дальше, мы решили попробовать заменить этот параметр параметром «Passwd» (не зашифрованный пароль) из документации и установить ему значение — наш ПП:
POST /auth HTTP/1.1
Host: android.clients.google.com
…
accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&add_account=1&Passwd=xxxxxxxxxxxxxxxx\
&service=ac2dm&source=android&androidId=3281f33679ccc6c6&device_country=us&operatorCountry=us&lang=en&sdk_version=17
И это сработало! Мы получили ответ, в котором содержалось что-то очень похожее на валидный токен. Этот токен, созданный сервером android.clients.google.com, стал видим в разделе «Connected Sites, Apps, and Services» нашего аккаунта и, похоже, предоставляет нам полный доступ к аккаунту:
Продолжая наблюдать за трафиком, мы заметили 2 различных процесса, относящихся к авто-логину в браузере. Тот, что попроще, был очередным клиентским запросом на логин, но использовал наш токен:
POST /auth HTTP/1.1
Host: android.clients.google.com
…
accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&Token=1%2Ff1Hu. &\
service=weblogin%3Acontinue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount\
&source=android&androidId=3281f33679ccc6c6&app=com.android.browser&client_sig=61ed377e85d386a8dfee6b864bd85b0bfaa5af81&\
device_country=us&operatorCountry=us&lang=en&sdk_version=17
Этот запрос возвращал тело ответа, а так же следующую строчку:
Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP. &source=AndroidWebLogin
Expiry=0
Из этого запроса мы установили, что форматом для параметра «service» является weblogin:continue=url_encode(destination_url). Мы решили попытаться указать этот параметр для нашего изначального запроса с ПП вместо токена (вместо того, чтобы пытаться понять происхождение непонятного параметра «client_sig»):
POST /auth HTTP/1.1
Host: android.clients.google.com
…
device_country=us&accountType=HOSTED_OR_GOOGLE&androidId=3281f33679ccc6c6Email=user%40domain.com&lang=en&\
service=weblogin%3Acontinue%3Dhttps%253A%2F%2Faccounts.google.com%2FManageAccount&\
source=android&Passwd=xxxxxxxxxxxxxxxx&operatorCountry=us&sdk_version=17&has_permission=1
И получили ответ, полностью повторяющий предыдущий:
Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP. &source=AndroidWebLogin
Expiry0
Ключевым параметром здесь является «MergeSession». Если вы откроете этот урл в неавторизованном браузере после того, как выполните запрос (это нужно сделать очень быстро), вы будете немедленно залогинены в аккаунт!
Таким образом, имея только имя пользователя, ПП и выполнив запрос к android.clients.google.com/auth, возможно залогиниться на страницу настроек аккаунта, в обход двухступенчатой верификации!
Фикс Google
Как было замечено ранее, этот способ работает даже для самой критичного раздела google аккаунта — настроек. Атакующий может предпринять рад действий, используя ПП жертвы:
- Он может передать «accounts.google.com/b/0/UpdateAccountRecoveryOptions?hl=en&service=oz» в качестве урла в API запросе. MergeSession URL, полученный в ответе, приведёт его прямо на страницу восстановления пароля, где он сможет сбросить основной пароль.
- Аналогично, атакающий может передать в запрос урл «accounts.google.com/b/0/SmsAuthConfig?hl=en», что приведет его на страницу с настройками 2ФА, где он сможет добавлять и удалять ПП или же отключить 2ФА совсем.
Насколько всё было плохо?
Мы считаем, что это большая дыра в системе аутентификации, если пользователь имеет некую форму для ввода пароля, которая позволит получить доступ к полному контролю над аккаунтом. Но несмотря на это, мы всё же согласны, что даже до того, как Google выкатил свой фикс, включить 2ФА на своём аккаунте гораздо лучше, чем не делать этого.
В наши дни, злоумышленник всё ещё имеет в своём арсенале набор методов для получения контроля над аккаунтом. Например:
- Создание фишингового сайта, с целью заставить пользователя отдать свой пароль.
- Использование того факта, что пользователи часто используют один и тот же пароль на различных сайтах. Взломав базу с паролями одного слабозащищенного сайта, злоумышленник может попытаться получить доступ к аккаунтам на других сайтах.
Несмотря на это, даже с ПП, 2ФА Google может сгладить оба этих типа атак, даже если пользователи продолжают делать глупые вещи. ПП генерируются Google и не предполагают запоминание пользователем, т.о. маловероятно, что он использует точно такой же пароль на другом сайте. Если даже злоумышленник создаст фишинговый сайт и выманит ПП, его шансы на успех будут значительно (возможно, на порядки) ниже, чем с обычным паролем.
Тем не менее, повсеместное использование ПП всё же несёт в себе потенциальную опасность. Если злоумышленник сможет заставить установить вредоносное ПО, оно сможет найти и извлечь ПП где-нибудь в пользовательской системе (например, популярный чат-клиент Pidgin хранит пароли в открытом виде в XML файле). Кроме того, «толстоклиентские» приложения, основной пользователь ПП, частенько подвержены довольно известной проблеме слабой проверки SSL сертификата, что потенциально позволяет украсть ПП с помощью MiM-атаки.
Фикс Google значительно помогает в данной ситуации. Несмотря на то, что ПП всё ещё могут нанести значительный вред пользователю, он сможет сохранить контроль над своим аккаунтом и возможность отозвать ПП, если вдруг что-то пойдет не так. Тем не менее, мы твердо верим в принцип минимальных привилегий и хотели бы видеть дальнейшие шаги Google, направленные на ограничение привилегий отдельных ПП.
Апдейт #1
Google обновил своё предупреждение при создании ПП, в котором предупреждается о потенциальном риске: 
Апдейт #2
Craig Young из nCircle выступил с докладом об аналогичной проблеме на конференции BSides, проводимой совместно с RSA!
Как хакеры взламывают двухфакторную аутентификацию в Google-аккаунтах
Доступ к учетной записи по одноразовому, короткоживущему паролю в SMS-сообщении до недавнего времени считался простой и надежной преградой для киберзлодеев. Однако хакеры научились обходить и двухфакторную аутентификацию интернет-аккаунтов.
Как это работает
Хакеры любыми удобными путями получают логин и пароль от аккаунта некоего пользователя в сервисе Google. В основном это производится при помощи «фишинга». Пользователю приходит поддельное письмо якобы от администрации Google, в тексте которого говорится о необходимости срочно перейти на сайт для осуществления каких-либо действий, связанных с обеспечением безопасности аккаунта. Ничего не подозревающий пользователь переходит по ссылке в письме и попадает на мошеннический сайт, который выглядит точь-в-точь, как официальный; вводит свои логин и пароль, которые мгновенно получают хакеры.
Узнать номер телефона, к которому привязан аккаунт, тоже труда не составляет. Но с дальнейшим взломом никто не торопится, вместо этого сначала формируется SMS-послание в стиле официальных сообщений сервиса с фальшивым уведомлением. Дескать, была предпринята попытка несанкционированного входа в вашу учетную запись, но мы поймали хулиганов за руку.
Чтобы избежать блокировки аккаунта и доказать, что вы – его истинный владелец, пришлите нам проверочный код из следующего SMS.
Сообщение содержит достоверные данные – IP-адрес и логин, его стиль копирует реальные послания техподдержки Google, так что жертва обеспокоена, но подвоха не ощущает, мысли скользят в ином направлении.
Далее все разыгрывается по минутам, так как срок жизни кода невелик:
- хакеры инициируют вход в аккаунт и получают требование ввода кода
- SMS с ним приходит на номер телефона жертвы в штатном порядке
- код доверчиво пересылается хакерам
- происходит верификация и вуаля
Фактически, вместо факта взлома системы безопасности имеет место обман, выманивание у доверчивого пользователя конфиденциального ключа. Претензии к Google? За что – двухфакторная аутентификация сработала так, как и описано в стандарте и пользовательском соглашении. Другое дело, что когда ее создавали, не подумали о «защите от дурака», как бы обидно это не звучало для миллионов людей.
Что можно сделать?
Ключевой информацией для взлома является связка логин-пароль – если хакерам есть, за что зацепиться, появляется смысл начать атаку. Эти данные они могут выудить тысячей и одним способов, но зачастую страдают самые беспечные пользователи. Например, Марк Цукерберг, оконфузившийся своим супер-паролем «dadada» в нескольких аккаунтах. Гигантские базы данных регулярно воруются и утекают в Сеть – возьмите за привычку использовать разные, красивые и сложные пароли, а также менять их хотя бы раз в квартал, а не когда станет поздно и обидно.
Специалисты по безопасности рекомендует вчитываться в тексты сообщений от роботов сервисов, пусть вы и получаете их десятками на дню. А вдруг вовремя обратите внимание, что адресатом указан Facebook, а вы пользуетесь аккаунтом на Яндексе или в Gmail? Злоумышленники постоянно меняют личины, но из-за мелких нестыковок в схеме работы их можно вывести на чистую воду. Если просят перейти по ссылке – вглядитесь в символы, это может быть фишинговая страничка. А если есть сомнения хоть в чем-то, лучше лишний раз оповестить службу безопасности. Это проще, чем отвоевывать свой аккаунт назад.
Учимся обходить двухфакторную аутентификацию (Google Authenticator, SMS)
UnderPrivate
Бывают случаи, когда тебе нужно кого-то зафишить. Бывает, когда у целевой организации настроен второй фактор для аутентификации — sms, Google authenticator, Duo. Что делать в таких случаях? Нанимать гопников? Подрезать телефоны у сотрудников? Нет! Оказывается, хитрые хакеры написали софт, способный помочь в этой непростой ситуации.
Evilginx2 — фреймворк для фишинга, работающий как прокси между жертвой и сайтом, учетки от которого мы хотим получить. Раньше он использовал кастомный nginx, теперь же полностью переписан на Go, включает в себя мини HTTP и DNS серверы, что сильно облегчает установку и развертывание.
Как это работает? Автор софта подробно описал на своем сайте, детали по установке и настройке можно найти на github странице проекта. Почему же удается обойти второй фактор? Фишка в том, что мы не вмешиваемся в процесс ввода кода из смс / временного пароля / пуша от DUO. Мы тихо ждем, пока пользователь успешно пройдет все шаги аутентификации, ловим его куку, и уже ее используем для входа. Попутно на всякий случай собираем его логин и пароль.
В этой же заметке я расскажу о своем опыте и подводных камнях, с которыми столкнулся.
Задача
Итак, нам нужно зафишить контору, которая активно использует Okta как Single Sign-on. В качестве второго фактора используется Duo — решение, фишка которого в мобильном клиенте, позволяющем подтверждать второй фактор через обычные пуш-нотификации вместо ввода 35-значных кодов (привет Google Authenticator). Приступим.
Шаг первый — регистрируем фишинговый домен
В панели нашего провайдера указываем адрес сервера, на котором будет расположен фишинг. Также регистрируем поддомен вида okta.<фишинговый домен>.com
Шаг второй — настраиваем Evilginx
Запускаем Evilginx и через команду config
вводим необходимые настройки. Указываем основной домен (не поддомен) и его IP.
В итоге конфиг выглядит так:
Интересен тут параметр redirect_url
— он указывает куда перенаправлять запрос, когда клиент пришел в корень нашего домена. Зачем это сделано? Если отдавать фишинговую страницу из корня, домен очень быстро вычислят и внесут в списки опасных сайтов, браузеры будут грозно ругаться, и пользователи никогда к нам не попадут. Поэтому мы ее будем отдавать по уникальной ссылке, а корень будет перенаправлять на песню Never Gonna Give You Up.
Шаг третий — настраиваем фишинговую страницу
Тут начинается самое интересное. Так как по-факту на нашем сервере мы вообще не хостим никакого контента, а только проксируем запросы, нам нужно "рассказать" Evilginx, какие именно данные мы хотим получить. Этот "рассказ" мы пишем в специальном формате. Документация по нему доступна на wiki странице проекта. Называются эти описания phishlets. Для некоторых популярных сервисов — facebook, linkedin, amazon они уже написаны и включены в дистрибутив. Нам повезло меньше, из коробки Okta не поддерживается, но добрые люди написали phishlet для старой версии. Берем напильник и начинаем паять.
Заполняем описание, указываем имя phishlet, авторов, и требуемую версию Evilginx.
Указываем, какой именно домен собираемся фишить. В нашем случае используется домен вида <имя целевой компании>.okta.com
указывает на то, что именно этот домен отдает нужные нам куки и туда передаются учетные данные, is_landing
значит что этот хост будет использоваться для генерации фишинговых URL.
Следующий важный этап — определить все запросы к целевому домену, для того чтобы прокси успешно их переписала на фишинговый домен. Если этого не сделать, пользователь будет отправлять данные не нам, а сразу на оригинальный домен, и никаких учеток мы не поймаем. Переписывать нужно только те запросы, которые непосредственно участвуют в процессе входа пользователя на сайт.
Чтобы четко понимать, что именно требуется для успешной аутентификации, нужно внимательно этот самый процесс изучить. Вооружившись Burp и тестовой учеткой начинаем искать как передается пароль и по каким кукам приложение определяет авторизованного пользователя. Также ищем ответы от сервера, в которых есть ссылки на оригинальный домен.
Находим запрос, в котором передается логин и пароль. Видим что он шлется на оригинальный домен, а нужно чтобы уходил нам.
Вот здесь видно, как оригинальный домен отдает ссылки внутри javascript, их нужно переписать.
Собрав это и еще пару запросов получаем следующие настройки:
как раз используется для замены оригинального домена на фишинговый. Подробнее о синтаксисе этой секции написано тут.
Помните, нам нужны куки, с которыми мы будем авторизоваться на сайте. Путем проб и ошибок выясняем имя куки — sid
, и дописываем его в настройки:
Также нам пригодится логин и пароль пользователя, мы уже нашли запрос, в котором они передаются. Как видно в запросе, нужные нам параметры username
передаются в json, дописываем:
Так Evilginx сможет вычленять их из запросов и корректно сохранять.
Осталось немного. Укажем URL страницы логина на целевом домене.
Укажем URL, по которому мы поймем, что пользователь успешно авторизован.
Вот и все! Конфиг целиком:
Сохраняем его как okta.yaml
Шаг четвертый — включаем наш новый фишинг
Запускаем evilginx и пишем команду
Под него автоматически создается сертификат от LetsEncrypt.
Указываем, куда будем редиректить пользователя после успешной авторизации
Приложение выдаст ссылку, которую нужно рассылать пользователям, вида https://<фишинговый домен>.com/login/login.htm?rb=9ffe&ec=<уникальный хеш>
Шаг 4 — ждем улов
Рассылаем письма (технологии рассылки — материал для отдельной статьи) и ждем.
Неокрепший доверчивый пользователь идет по ссылке и авторизуется. Видим мы это так:
Все пойманные учетки складываются в sessions. Выбираем нужную и копируем из нее куки:
Открываем бразуер, подставляем куки и вуаля — мы внутри:
Послесловие
Evilginx сильно упрощает создание фишинговых страниц, особенно для 2FA. Также эти страницы удобно хранить и делиться ими с друзьями. Способы защиты — использование девайсов стандарта U2F, переход на новые методы аутентификации.