Как мошенники обходят двухфакторную аутентификацию

Злоумышленники научились обходить двухфакторную аутентификацию Yahoo Mail и Gmail

На днях специалисты по информационной безопасности из компании Cerfta Lab опубликовали результаты изучения ряда взломов аккаунтов пользователей Yahoo Mail и Gmail. Как оказалось, у технологии двухфакторной аутентификации, используемой этими сервисами, есть ряд недостатков, которые и позволяют действовать злоумышленникам.

Авторы расследования считают, что взломы осуществлялись по заказу иранского правительства. Целью всей кампании была информация взломанных аккаунтов. Атака осуществлялась при помощи e-mail со скрытым изображением и скриптом.

Само письмо представляло собой сообщение о якобы обнаруженной подозрительной активности в аккаунте пользователя упомянутых почтовых сервисов. Отправлялись эти e-mail с адресов вроде mailservices@gmail[.]com, noreply.customermails@gmail[.]com, customer]email-delivery[.]info. Поэтому у не слишком продвинутых пользователей эти сообщения не вызывали подозрения.

Наоборот, многие стремились кликнуть по кнопке «защитить аккаунт», которая перебрасывала пользователя на фейковую страницу входа почтового сервиса. Когда пользователь вводил свои данные, их практически в режиме реального времени использовали злоумышленники уже для доступа к реальному аккаунту. Пользователь, у которого включена двухфакторная аутентификация, получал на телефон SMS с одноразовым паролем, злоумышленники каким-то образом получали возможность войти в аккаунт. Они научились обходить защиту Google Authenticator.

Исследователи составили схему использовавшихся доменов и серверов, которые с ними связаны.

Злоумышленники использовали систему VPN и прокси для того, чтобы скрыть свое местонахождение. Но исследователям удалось восстановить оригинальный диапазон IP, с которых осуществлялась атака. Это были иранские адреса. Кроме того, схожие методы работы использовались и используются группой взломщиков Charming Kitten, которая связана с правительством Ирана.

Жертвами, на которых охотились злоумышленники, стали, в первую очередь, журналисты, политики, разного рода общественные активисты со многих стран мира.

Понятно, что основной способ, позволяющий защититься от атак подобного рода — просто не открывать подозрительные e-mail. К сожалению, этот способ не всегда действует, поскольку многие люди не видят ничего подозрительного в письме, составленным якобы Google или Yahoo. Ситуации может помочь использование хардварных ключей (например, YubiKey), которые позволяют провести аутентификацию при подключении USB-устройства к порту.

Компания Google провела исследование, результаты которого однозначно говорят о том, что USB-ключи гораздо надежнее смартфонов или других систем, которые могут использоваться для двухфакторной аутентификации.

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

Источник

Как мошенники обходят двухфакторную аутентификацию Apple ID

Продолжаем знакомить вас с новыми способами мошенничества, чтобы обезопасить от потери дорогостоящего гаджета.

Уже давно злоумышленники банально крадут смартфоны Apple, а после пытаются всеми возможными способами выудить у владельца Apple ID и пароль для отвязки от iCloud.

В противном случае смартфон можно лишь пустить «на органы».

Раньше, чтобы узнать логин и пароль, массово использовали схему с фейковыми СМС и письмами, а сейчас мошенники вышли на новый уровень.

Как происходит новый развод

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

В этот момент на указанный резервный номер телефона поступает звонок.

Собеседник представляется сотрудником «ООО ЭППЛ РУС» (официального представительства Apple в России) и говорит примерно следующее:

Сегодня в наш офис пришли мошенники с Вашим iPhone и поддельными документами о его приобретении. Они пытались подать заявление на отвязку смартфона от Apple ID. Мы их разоблачили и изъяли iPhone.

Готовы вернуть Вам iPhone X 256 Гб в цвете «серый космос» с серийным номером: XXXXXXXXXXXXX.

Владелец потерянного смартфона с радостью проверяет iCloud и обнаруживает, что смартфон действительно включился и обнаружен по адресу Москва, Петровка 5, который является фактическим адресом «ООО ЭППЛ РУС».

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

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

Надеюсь, дальше все понятно…

Что жертва делает неправильно

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

Разумеется, это полный бред, но так специально пытаются ввести в заблуждение тех, кто усомнится в необходимости вводить давно сохраненный пароль. Сотрудники Apple никак не смогут сбросить кэш и сохраненные пароли в вашем браузере.

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

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

На самом деле этот код система запросит в момент, когда мошенники попытаются войти в iCloud жертвы со своего компьютера. Для еще большей достоверности пользователь увидит запрос на попытку авторизации с уже знакомого адреса Москва, Петровка 5.

После подтверждения и ввода кода по фейковой ссылке можно навсегда распрощаться со своим iPhone, а если мошенники параллельно сменят пароль от Apple ID, то еще и получим блокировку остальных привязанных к учетке гаджетов.

Как такое возможно

Для начала мошенники обзаводятся фейковым сайтом iCloud для кражи логина и пароля. Даже не самый опытный разработчик может запросто создать подобный сайт. В сети множество уже готовых предложений с подобными поделками.

Далее остается лишь приехать к офису Apple на Петровке и включить украденный iPhone, параллельно звоня жертве по появившемуся на экране номеру.

Когда владелец украденного смартфона клюнет и введет данные, мошенники попытаются авторизоваться и запрос на двухфакторную аутентификацию снова придет с нужного адреса, ведь они находятся рядом.

Многие ничего при этом не заподозрят, слив мошенникам логин и пароль, а после собственноручно пропустив их через двухфакторную авторизацию.

Как не попасться

Как всегда, все очень просто: ни при каких обстоятельствах не сообщайте никому свои учетные данные от Apple ID.

Как бы ловко не пытались их выудить мошенники, будьте предельно бдительны и никогда не переходите по предоставленным сылкам. Всегда самостоятельно вбивайте в адресной строке адрес нужного сайта или сервиса.

Если кто-то будет настаивать на необходимости перехода по особенной ссылке – знайте, что это обман.

Желаем вам не терять свои гаджеты и не попадаться на уловки мошенников.

Источник

Обход двухфакторной аутентификации 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 токенами и ПП следующие:

«Другая слабость ПП в обманчивом впечатлении, что они предоставляют доступ к конкретному приложению, а не полномасштабный доступ к аккаунту»

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 аккаунта — настроек. Атакующий может предпринять рад действий, используя ПП жертвы:

Насколько всё было плохо?

Мы считаем, что это большая дыра в системе аутентификации, если пользователь имеет некую форму для ввода пароля, которая позволит получить доступ к полному контролю над аккаунтом. Но несмотря на это, мы всё же согласны, что даже до того, как Google выкатил свой фикс, включить 2ФА на своём аккаунте гораздо лучше, чем не делать этого.

В наши дни, злоумышленник всё ещё имеет в своём арсенале набор методов для получения контроля над аккаунтом. Например:

Несмотря на это, даже с ПП, 2ФА Google может сгладить оба этих типа атак, даже если пользователи продолжают делать глупые вещи. ПП генерируются Google и не предполагают запоминание пользователем, т.о. маловероятно, что он использует точно такой же пароль на другом сайте. Если даже злоумышленник создаст фишинговый сайт и выманит ПП, его шансы на успех будут значительно (возможно, на порядки) ниже, чем с обычным паролем.

Тем не менее, повсеместное использование ПП всё же несёт в себе потенциальную опасность. Если злоумышленник сможет заставить установить вредоносное ПО, оно сможет найти и извлечь ПП где-нибудь в пользовательской системе (например, популярный чат-клиент Pidgin хранит пароли в открытом виде в XML файле). Кроме того, «толстоклиентские» приложения, основной пользователь ПП, частенько подвержены довольно известной проблеме слабой проверки SSL сертификата, что потенциально позволяет украсть ПП с помощью MiM-атаки.

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

Апдейт #1
Google обновил своё предупреждение при создании ПП, в котором предупреждается о потенциальном риске:

Апдейт #2
Craig Young из nCircle выступил с докладом об аналогичной проблеме на конференции BSides, проводимой совместно с RSA!

Источник

Как хакеры обходят 2FA — двухфакторною аутентификацию?

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

Конечно, 2FA намного лучше примитивного логина, но это еще не все. Всем известно, что пароли в корне небезопасны и до тех пор, пока они остаются в тренде, защита учетных записей остается под угрозой. Но 2FA не панацея, она пока что не справляется с нагрузкой всех прорывов — паролей и людей, которые их создают. Этим успешно пользуются злоумышленники и обходят 2FA, чем доказывают, что путь к хорошей безопасности и истинному спокойствию лежит не здесь.

Как хакеры обходят 2FA?

Хакеры могут использовать несколько потоков эксплойтов для целевых учетных записей 2FA на основе паролей. Рассмотрим несколько распространенных техник обхода 2FA в действии:

1. Браузер Necro

Все гениальные решения просты — и это одно из них. Два инструмента — Muraena и NecroBrowser автоматизируют фишинговые атаки, которые могут обойти 2FA. Большинство средств защиты не остановят их по простой причине — эти атаки идут непосредственно к первопричине всех нарушений — пользователям.

Принцип работы такой же, как и у любой фишинговой схемы, за исключением одного момента. Вместо того, чтобы просто создать поддельный сайт, который выглядит как реальный для того, чтобы обманом заставить пользователей ввести свои пароли, новый способ действует еще и как прокси между жертвой и реальным сайтом. Как только пользователь войдет в систему — запрос посылается от его имени в службу. Пользователь, ошибочно считая, что находится на легальной странице входа в систему, передает и пароль, и PIN-код 2FA непосредственно в руки злоумышленника.

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

2. Атака «человек в браузере»

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

На видео: Обход двухфакторной аутентификации. Новый фишинг

3. Социальная инженерия и фишинг

Хакеры могут нацелиться на аутентификацию 2FA огромным количеством способов:

2FA без пароля

Выход из этой неразберихи прост — отказаться от паролей, также как и от менеджеров паролей и сложных паролей — они практически никогда не работали в прошлом, и точно не будут работать в будущем.
Беспарольная аутентификация — это 100% защита. Это означает, что у нас наконец-то появился метод аутентификации, который не полагается на самое слабое звено в безопасности. Пришло время оставить позади всю парадигму безопасности, которая основывалась только на паролях — технология наконец-то наверстала упущенное.

Беспарольная аутентификация работает так:

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Кража паролей и обход двухфакторной аутентификации с evilginx2

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

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

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

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

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

Крепкость цепи, как известно, определяется крепкостью самого слабого звена. Чтобы понять, где в двухфакторной аутентификации самое слабое звено, рассмотрим технические аспекты её работы.

Всё начинается с того, что пользователь переходит на сайт и вводит свой пароль. Затем по другому каналу он получает второй пароль/код для входа на сайт. Всё современно и безопасно.

В случае удачного входа, как удалённый сервис «запомнит» этого пользователя, как будет отличать его запросы от других? А здесь всё по старинке — с помощью токена (маркера) сохранённого в кукиз. В принципе, это единственный вариант, который предусмотрен в самом протоколе HTTP.

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

Как реализовать обход двухфакторной аутентификации

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

evilginx2 для взлома аккаунтов

Чтобы фишинговая атака прошла успешно, нужно учесть ряд тонкостей. Доменное имя не должно вызывать подозрений у пользователя, должно использоваться безопасное HTTPS соединение, сайт для входа должен полностью повторять оригинал, должна использоваться убедительная история, после ввода учётных данных пользователь не должно происходить ничего такого, что вызывает подозрение пользователя и так далее.

Для автоматизации технической части была создана программа evilginx2. Её цель (а также цель этой инструкции, кстати), это показать пользователям пример обхода двухфакторной аутентификации и усилить её безопасность благодаря повышению бдительность пользователей и уменьшению возможности взлома через «человеческий фактор», поскольку с технической точки зрения двухфакторная аутентификация является весьма надёжной.

Инструмент evilginx2 является преемником программы evilginx. Данный инструмент автоматизирует многие технические аспекты, в том числе выступает в роли прозрачного прокси для получения токена, автоматически получает валидный (действительный) SSL сертификат для субдомена, используемого в фишинговой атаке, сохраняет введённые учётные данные, а также перехваченные маркеры.

Фишинг 2.0

Типичная фишинговая атака заключалась в том, что создавалась (клонировалась) страница входа на которую заманивался пользователь. Эта страница входа при вводе имени пользователя и пароля сохраняла их или отправляла злоумышленнику. Такую фишинговую атаку двухфакторная аутентификация нивелирует полностью.

Новый вариант фишинговой атаки заключается в том, что пользователь заманивается на сайт злоумышленника, но вместо показа ему заранее подготовленной HTML страницы, для него проксируется оригинальная страница входа (например, сайта Facebook). Задача атакующего в этой ситуации выполнять роль прозрачного прокси — всё, что вводит пользователь, отправляется легитимному сайту, чтобы легитимный сайт в конечном счёте прислал нам валидный токен.

Может возникнуть вопрос, как обстоят дела с HTTPS, ведь безопасные соединения свели практически на нет атаки человек-посередине. В данной фишинговой атаке HTTPS не является препятствием — между настоящим сайтом и прокси атакующего используется HTTPS соединение, отправляя данные «жертве», атакующий также использует HTTPS соединение, для чего он получает валидный SSL сертификат для своего домена/субдомена.

HTTPS является не единственной проблемой — часто страница входа содержит ссылки на скрипты, файлы стилей и изображений, которые могут размещаться на субдоменах и даже других сайтах. Здесь необходимо решить сразу две проблемы: во-первых, на лету подменять ссылки на наши собственный «злой» сайт, а, во-вторых, обеспечить действительные DNS ответы для наших «злых» субдоменов.

Собственно, именно все эти (а также другие технические задачи) и решает программа evilginx2.

Что такое evilginx2

evilginx2 — это атакующая платформа для настройки фишинговых страниц. Вместо хранения шаблонов страниц входа, она выступает посредником между жертвой и настоящим сайтом, при этом сохраняя все введённые учётные данные и полученные токены и кукиз.

Захват токенов аутентификации позволяет атакующему обойти любую форму 2FA (двухфакторной аутентификации).

Посмотрите на видео демонстрацию, показывающую, как атакующий может удалённо взломать аккаунт Outlook для которого включена 2FA.

Кстати, в отличие от своего предшественника, evilginx2 больше не использует веб-сервер nginx. Программа имеет свой собственный встроенный веб-сервер и свой DNS сервер.

Дисклэймер: проект evilginx2 выпущен только для образовательных целей и должен использоваться только в демонстрациях или легитимных тестированиях на проникновение с письменным разрешением от стороны, в отношении которой выполняется фишинговая атака. Цель заключается в том, чтобы показать, что 2FA не является «серебряной пулей» против попыток фишинга и люди должны быть предупреждены, что их аккаунты могут быть скомпрометированы, если они не будут осторожными.

Настройка сервера для evilginx2

Для фишинговой атаки с evilginx2 нужно много всего:

Кстати, evilginx2 работает даже на Windows, но в этом примере я буду показывать исключительно на Linux.

На сервере, который будет использоваться для фишинговой атаки, не должны быть заняты порты 80, 443 и 53. То есть если на сервере запущен apache или nginx и какая-либо служба для обработки DNS запросов, то их нужно остановить. При запуске evilginx2 скажет вам, если ему не удалось открыть сокет для прослушивания на каком-либо из этих портов.

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

Итак, регистрируемся у хостера (этой Айхор, там я уже зарегистрирован, поскольку на VPS у меня там работает SuIP.biz). Это отечественный хостер, если вы предпочитаете иностранных, то могу посоветовать DigitalOcean.

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

Как я сказал, я арендую VPS только для тестов, поэтому выбираю период 1 день. Кстати, если вы не знаете, выбрать на HDD (обычные жёсткие диски) или на SSD (быстрые диски), то настоятельно рекомендую выбирать именно SSD.

Сама операционная система Linux без графического рабочего стола потребляет где-то 200 мегабайт, поэтому варианта с 1 гигабайтом оперативной памяти нам будет достаточно (нажимаем кнопку Заказать).

На следующей вкладке обратите внимание на операционную систему — по умолчанию там выбрана CentOS — это действительно популярный дистрибутив Linux у хостеров, но я в ней чувствую себя не очень уверенно, поэтому выбираю более привычную мне Debian самой последней версии, причём в конфигурации minimal — никакие панели управления я не признаю:

Меня не смущает, что там alpha версия, поскольку этот сервер будет жить 1 день, для реального веб-сайта или сервиса я бы выбрал последнюю стабильную версию, а не альфу (да и вообще бы установил Arch Linux, конечно).

Публичный IPv4-адрес уже входит в комплект, поэтому больше никаких расходов. Нажимаем кнопку «В корзину».

Оплачиваем и немного ждём, пока для нас развернуть виртуальный выделенный сервер по нашим параметрам.

Через некоторое время приходят данные для входа на сервер. Самое главное, что нам нужно, это IP адрес нашего нового сервера, имя пользователя (root) и пароль.

Теперь нам нужно подключиться по SSH к нашему серверу командой вида:

Если у вас Windows, то вам поможет Cygwin.

У моего сервера IP адрес 185.238.139.203, поэтому подключаюсь к нему следующей командой:

Делаем на сервере полное обновление и перезагружаемся:

Теперь нам нужен домен. Домен можно приобрести здесь же, в панели управления хостингом Айхор. Если ваш домен куплен здесь, то в этом случае нужно перейди во вкладку Домены. Затем выбрать домен и нажать кнопку NS:

Здесь нужно будет установить NS записи — ниже показано, какие именно. (А также будут присланы учётные данные для входа на https://dns-manager.marosnet.net/dnsmgr, где нужно будет установить IP домена — это нужно для обычных сайтов, для наших целей здесь не нужно ничего менять).

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

Переходим к доменам и нажимаем кнопку NS.

Нам нужно добавить две записи вида:

В качестве yourdomain.com должно быть ваше доменное имя. То есть если я делаю записи для домена softocracy.ru, то они должны быть такими:

Вполне вероятно вы делаете настройку на другом хостинге и там вкладка может называться по-другому, например, сервера имён.

Чтобы понимать, что именно это за настройка, нужно примерно представлять работу DNS серверов. Те, кто уже знает, что это такое, часто представляют себе работу DNS как «запрос-ответ». На самом деле, существуют разные DNS серверы:

Сервер имён который мы сейчас будем настраивать, — это тот DNS сервер, который непосредственно и содержит DNS записи для вашего домена. Причём указывать этот сервер можно только как имя хоста, то есть как субдомены ns1.* и ns2.*, IP адрес не будет принят в качестве сервера имён.

Может возникнуть вопрос, если сервер, который хранит DNS записи, в том числе запись вида A (содержит IP адрес сайта) указывается с помощью имени хоста, например, ns1.softocracy.ru, то как будет найден IP этого самого хоста ns1.softocracy.ru? Ведь все DNS записи о хостах *.softocracy.ru содержит ns1.softocracy.ru…

Специально для разрешения такой закольцованной проблемы используются так называемые glue records. С практической точки зрения это означает, что кроме имени хоста нам нужно ещё указать и IP этого хоста. В Айхор это делается записями вида:

То есть после слэша нужно указать один или более IP адресов.

В нашем случае функции сервера имён будет выполнять программа evilginx2, то есть в качестве IP адреса сервера имён нужно указать адрес VDS. У меня это адрес 185.238.139.203. Но IP адреса для каждого сервера имён должны быть уникальными, а у меня только один IP… В общем, один IP я указал правильный, а в качестве второго выбрал случайный в надежде, что всё равно будет работать (забегая вперёд скажу, да, так работает). Поэтому записи следующие:

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

На других хостингах IP адреса NS серверов могут указываться по-другому. Например, на Хостлэнд также можно изменить NS сервера на любые другие, но в качестве серверов имён принимаются только имена хостов, без IP. Там нужно заранее создать A записи для субдоменов ns1 и ns2 и только после этого указать желаемые NS сервера. В этом случае IP адреса подхватятся автоматически.

Связанная статья: Что такое glue record в DNS

Как установить evilginx2

Установка evilginx2 на все дистрибутивы Linux выполняется одинаково.

Следующие команды выполнят установку evilginx2, а также скачают дополнительные фишлеты:

Запуск для проверки, что всё в порядке:

Я нашёл ещё один репозиторий фишлетов, но, к сожалению, они предназначены для предыдущей версии и на новой версии они не работают, поскольку немного изменился формат файлов фишлетов. В принципе, после небольшой доработки их можно сделать рабочими и для новой версии evilginx2: https://github.com/asmc/evilginxPhishlets/archive/master.zip

Инструкция по использованию evilginx2

К этому моменту необходимо, чтобы записи о новых Серверах Имён уже распространились по сети DNS серверов — это может потребовать часы или даже сутки.

Чтобы проверить текущее значение NS записей домена, выполните команду dig вида:

Например, для домена softocracy.ru:

Если с DNS записями всё в порядке, то переходим в папку evilginx/ и запускаем программу:

Я покажу на примере кражи учётных данных Twitter аккаунта.

В следующих командах вместо softocracy.ru вписывайте имя вашего домена, вместо 185.238.139.203 вписывайте IP вашего виртуального частного сервера и вместо twitter вписывайте название интересующего вас фишлета.

Устанавливаем наш домен:

И IP адрес нашего сервера:

Придумайте имя субдомена, я особо не старался — поскольку это просто пример:

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

Установим сайт, куда будут перенаправляться случайные посетители:

Установим имя переменной для маркера:

И установим значение, которое должен иметь маркер, чтобы была показана фишинговая страница:

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

Всё готово, включает фишлет twitter:

Кстати, если вы не настроили NS сервер и хотите всё сделать в стиле Evilginx, в котором для каждого субдомена нужно было сделать свою A запись, то посмотреть используемые субдомены вы можете командой:

В моём случае выведено:

В таком виде можно добавить строки в файл /etc/hosts.

Обратите внимание, что, во-первых, мы получили валидный SSL сертификат для нашего субдомена, об этом говорит строка:

А во-вторых сразу, в первые же секунды после активации веб-сервера пошли не аутенфицированные запросы, то есть это те, кто пытается открыть сайт без верного маркера:

Попробуем открыть сами сайт без верного токена: https://twitter.gift-card.softocracy.ru. Нас закономерно перебросит на сайт suay.ru.

Наконец, составляем нашу ссылку с верным маркером: https://twitter.gift-card.softocracy.ru?specially_for_you=twit_cards

Наконец-то мы попали в «твиттер»:

На самом деле, в реальной фишинговой атаке ссылку, конечно, нужно было бы обернуть каким-нибудь сократителем ссылок.

Пользователь пытается войти, а мы перехватываем его учётные данные:

Если бы логин и пароль были верными, то мы бы перехватили и кукиз с токеном.

можно увидеть захваченные логины, пароли и токены:

В видео перехваченные кукиз добавляются в браузер с помощью расширения EditThisCookie.

Обратите внимание, что фишинговая страница будет онлайн только если запущен evilginx2, поскольку эта программа обеспечивает работу и веб-сервера, и DNS сервера. Для решения этой проблемы смотрите статью «Как закрыть терминал без убийства запущенной в нём команды».

Статус всех фишлетов можно вывести командой:

Приманки (lures)

Приманки позволяют сделать настройки для снижения заметности фишинговой атаки.

Чтобы создать новую приманку для фишлета, например, twitter:

Чтобы просмотреть имеющиеся приманки:

Некоторые другие опции приманок:

Устанавливает пользовательский url для приманки с заданным

Устанавливает url редиректа, куда пользователь будет перенаправлен при успешной авторизации для приманки с заданным

Изменить фишлет, применяется к приманке с заданным

Изменить фишлет, применяется к приманке с заданным :

Установить заголовок opengraph, который будет показан по превью ссылки для приманки с заданным :

Установить описание opengraph которое будет показано по превью ссылки для приманки с заданным :

Установить url изображения opengraph которое будет показано по превью ссылки для приманки с заданным :

Установить url для opengraph которая будет показана по превью ссылки для приманки с заданным

Заключение

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

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

Блог автора evilginx2 в котором описываются важные особенности программы:

Формат файлов фишлетов (2.3.0) — для тех, кто хочет добавить поддержку других сайтов для фишинга: https://github.com/kgretzky/evilginx2/wiki/Phishlet-File-Format-(2.3.0)

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

Источник