Главная » Разные статьи » Как обойти двухэтапную аутентификацию гугл

Как обойти двухэтапную аутентификацию гугл


Обход двухфакторной аутентификации 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 токены предоставляют более гибкую модель авторизации и могут быть использованы для ограничения доступа только к определенным данным или сервисам в вашем аккаунте. С другой стороны, пароли приложений, если уж быть совсем точным, не совсем ТОЛЬКО для приложений!
Остановимся на втором пункте подробнее. Если вы создаете ПП для XMPP чат-клиента, этот же самый пароль может быть использован для чтения почты через IMAP или получения списка событий из CalDAV календаря. Что, собственно, не является таким уж сюрпризом. На самом деле, Eric Gorss и Mayank Upadhyay из Google уже указывали на эту слабость в их статье о 2ФА Google: «Другая слабость ПП в обманчивом впечатлении, что они предоставляют доступ к конкретному приложению, а не полномасштабный доступ к аккаунту» 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

Ответ, помимо всего прочего, содержал следующее:

Token=1/f1Hu...

Несмотря на то, что урл и некоторые параметры не документированы, это очень напоминает 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 аккаунта — настроек. Атакующий может предпринять рад действий, используя ПП жертвы: Это больше невозможно, начиная с 21 февраля, когда инженеры Google закрыли эту дыру. Насколько мы можем судить, Google теперь поддерживает некое дополнительное состояние, которое позволяет определить, как именно вы аутентифицировались — с помощью MergeSession URL и с помощью обычного логина и пароля, используя 2ФА. Страница настроек станет доступна только в последнем случае. Если же вы залогинились с помощь MergeSession URL, вас перенаправлят на страницу 2ФА, которую нельзя пропустить.
Насколько всё было плохо?
Мы считаем, что это большая дыра в системе аутентификации, если пользователь имеет некую форму для ввода пароля, которая позволит получить доступ к полному контролю над аккаунтом. Но несмотря на это, мы всё же согласны, что даже до того, как Google выкатил свой фикс, включить 2ФА на своём аккаунте гораздо лучше, чем не делать этого. В наши дни, злоумышленник всё ещё имеет в своём арсенале набор методов для получения контроля над аккаунтом. Например:
  • Создание фишингового сайта, с целью заставить пользователя отдать свой пароль.
  • Использование того факта, что пользователи часто используют один и тот же пароль на различных сайтах. Взломав базу с паролями одного слабозащищенного сайта, злоумышленник может попытаться получить доступ к аккаунтам на других сайтах.
Оба этих примера представляют собой типы атак, которые могут быть предотвращены с помощью следования простым правилам и «цифровой гигиены». Например, не использовать один и тот же пароль на различных сайтах и не нажимать на подозрительные ссылки в e-mail сообщениях. К сожалению, такого рода «образовательные программы для пользователей» редко работают хорошо на практике(и могут быть нецелесообразны с экономической точки зрения). Несмотря на это, даже с ПП, 2ФА Google может сгладить оба этих типа атак, даже если пользователи продолжают делать глупые вещи. ПП генерируются Google и не предполагают запоминание пользователем, т.о. маловероятно, что он использует точно такой же пароль на другом сайте. Если даже злоумышленник создаст фишинговый сайт и выманит ПП, его шансы на успех будут значительно (возможно, на порядки) ниже, чем с обычным паролем.

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

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

Апдейт #1

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

Апдейт #2

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

Хронология событий:

2012/07/16: Исследователи из Duo подтвердили наличие ПП уязвимости. 2012/07/18: Описание проблемы направлено в [email protected] 2012/07/20: Дискуссия со службой безопасности Google с целью уточнения деталей. 2012/07/24: Проблема подтверждена и классифицирована Google как «ожидаемое поведение». 2013/02/21: Google выпустила фикс, который запрещает доступ к критичной информации для ПП сессий.

2013/02/25: Duo публикуют статью с описанием проблемы.

Теги:
  • безопасность
  • google
  • аутентификация
  • 5 января 2016 в 17:22
  • 27 декабря 2015 в 03:45
  • 20 мая 2011 в 15:46

habr.com

FUCK 2FA! Обходим двухфакторную аутентификацию с помощью Modlishka - «Хакер»

Содержание статьи

Теневые форумы изобилуют предложениями о взломе аккаунтов. В большинстве случаев атаки устраивают при помощи фишинга с подделкой страницы авторизации. Однако такой метод неэффективен, если пользователю приходит SMS с проверочным кодом. Я покажу, как пробить двухфакторную аутентификацию, на примере взлома аккаунта Google редактора «Хакера».

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

Метод 2FA (Two-Factor authentication) был придуман как дополнительный способ подтверждения владельца аккаунта. Он основан на нескольких способах аутентификации:

  • пользователь что-то знает (например, может ответить, какая была девичья фамилия его матери или кличка первого домашнего питомца);
  • пользователь обладает уникальными чертами, которые можно оцифровать и сравнить (биометрическая аутентификация);
  • пользователь имеет девайс с уникальным идентификатором (например, номер мобильного, флешку с ключевым файлом).

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

Самый популярный метод 2FA — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код приходит каждый раз разный, поэтому угадать его практически невозможно.

Однако чем сложнее преодолеть защиту техническими методами, тем легче бывает это сделать социальной инженерией. Все настолько уверены в надежности 2FA, что используют ее для самых ответственных операций — от авторизации в Google (а это сразу доступ к почте, диску, контактам и всей хранимой в облаке истории) до систем клиент-банк.

При этом возможность обхода такой системы уже показывал австралийский исследователь Шабхэм Шах (Shubham Shah). Правда, его метод был довольно сложен в практической реализации. В нем использовалась авторизация по звонку, а не SMS, а предварительно нужно было узнать номер телефона жертвы и часть учетных данных. PoC был не особо убедительным, но наметил вектор атаки.

В начале 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

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

xakep.ru

Google: почти никто не пользуется двухфакторной аутентификацией

За семь лет, которые прошли с момента включения Google двухфакторной аутентификации, менее 10% из более чем миллиарда пользователей начали ей пользоваться. Гжежож Милка (Grzegorz Milka), программный инженер Google На странице Google, посвящённой двухфакторной аутентификации в сервисах компании, пользователей встречает надпись «Миллионы пользователей уже защитили свой аккаунт с помощью двухэтапной аутентификации. Присоединяйтесь!». Надпись выглядит весьма иронично, если знать, что уже пару лет назад количество пользователей почты Gmail перевалило за миллиард, а этим способом аутентификации пользуются не десятки и не сотни миллионов.

На конференции по информационной безопасности Usenix's Enigma 2018 программный инженер Google Гжежож Милка (Grzegorz Milka) рассказал, что менее 10% пользователей выбрали двухфакторную аутентификацию в сервисы Google, и всего 12% американцев используют менеджер паролей.

В теории, Google могла бы подключить двухфакторную аутентификацию всем пользователям сразу, вместо них позаботившись о безопасности аккаунтов. На вопрос, почему компания этого не сделала, Milka на конференции ответил «Вопрос в юзабилити. В том, как много людей перестанут пользоваться нашими сервисами, если мы заставим их использовать дополнительные инструменты безопасности».

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

В 2016 году в Великобритании и США провели опрос 4000 человек на тему сложности и количества используемых паролей, «угона» аккаунтов и использования двухфакторной аутентификации. Оказалось, что наиболее внимательно к безопасности относится поколение бэби-бумеров — люди, которым на тот момент было от 51 до 69 лет. Они реже других используют один пароль для всех аккаунтов и чаще используют двухфакторную аутентификацию.

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

Теги:

habr.com

Как не вводить код при двухэтапной аутентификации Google

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

Telegram-канал создателя Трешбокса с инсайдами разработки

Для начала давайте разберемся в понятии «двухфакторная аутентификация». В большинстве случаев для доступа к своим учетным записям мы используем логин и пароль. Такая простая процедура имеет один существенный недостаток – эти данные могут быть украдены и использованы сторонними людьми. Двухфакторная аутентификация предполагает доступ к личным аккаунтам в два этапа. Первый этап проверки подлинности – это логин и пароль, второй этап – подтверждение владельца учетной записи с помощью цифрового кода (SMS, электронная почта), голосового сообщения или специального устройства. На сегодняшний день это наиболее оптимальный метод авторизации с точки зрения безопасности. Двухфакторную аутентификацию уже давно предлагают своим пользователям компании Google, Apple, Microsoft, социальные сети ВКонтакте, Twitter, Facebook и многие другие популярные сервисы. Чтобы использовать смартфон как устройство подтверждения авторизации, первым делом нужно включить двухфакторную аутентификацию Google-аккаунта. Сделать это можно как через веб-интерфейс, так и непосредственно в настройках учетной записи на мобильном устройстве.

Способ 1. Через веб-интерфейс

  1. Зайдите в настройки безопасности вашей учетной записи.

  • Прокрутите страницу вниз до раздела «Вход в аккаунт Google» и найдите опцию «Двухэтапная аутентификация».

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

    • Способ 2. На мобильном устройстве

    1. Зайдите в настройки вашего устройства и выберите Google-аккаунт.
    2. В разделе «Безопасность и вход» найдите опцию «Двухэтапная аутентификация».

  • Введите еще раз пароль от своей учетной записи.
  • Выполните 3 этапа настройки двухэтапной аутентификации, аналогичные первому способу.
    • Теперь, когда вы включили двухфакторную аутентификацию, доступ к вашему аккаунту будет осуществляться в два этапа. В качестве резервного способа входа для второго этапа аутентификации Google предлагает несколько вариантов. В нашем случае необходимо, чтобы вторым фактором вместо SMS-сообщения с кодом выступал смартфон. Для этого ищем опцию Google Prompt и добавляет туда свой смартфон.

    Стоит отметить, что для этой процедуры требуется устройство с активной блокировкой экрана. Пользователям iOS-устройств дополнительно потребуется установить приложение Google из App Store.

    Как это работает

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

    Использовать смартфон в качестве устройства подтверждения авторизации – очень удобно. Но учтите, такой способ работает только при активном интернет-соединении. В другом случае вы всегда сможете выбрать альтернативный вариант входа, например, по коду подтверждения из SMS-сообщения.

    trashbox.ru

    Как хакеры обходят двухэтапную аутентификацию в Google-аккаунтах

    Доступ к учетной записи по одноразовому, короткоживущему паролю в SMS-сообщении до недавнего времени считался простой и надежной преградой для киберзлодеев. Однако в начале лета Алекс МакКоу (Alex MacCaw), сооснователь Clearbit.com, столкнулся с новым механизмом обмана пользователей. О чем и поспешил поведать Интернет-сообществу после проверки деталей.

    Как это работает

    Хакеры любыми удобными путям получают логин и пароль от аккаунта некоего пользователя в сервисе Google – зачастую тот полагается на двухфакторную аутентификацию и не слишком осторожен. Узнать номер телефона, к которому привязан аккаунт, тоже труда не составляет. Но со взломом никто не торопится, вместо этого сначала формируется послание в стиле официальных сообщений сервиса с фальшивым уведомлением. Дескать, была предпринята попытка несанкционированного входа в вашу учетную запись, но мы поймали хулиганов за руку. Чтобы избежать блокировки аккаунта и доказать, что вы – его истинный владелец, пришлите нам проверочный код из следующего SMS.

    Сообщение содержит достоверные данные – IP-адрес и логин, его стиль копирует реальные послания техподдержки Google, так что жертва обеспокоена, но подвоха не ощущает, мысли скользят в ином направлении. Далее все разыгрывается по минутам, так как срок жизни кода невелик:

    • хакеры инициируют вход в аккаунт и получают требование ввода кода
    • SMS с ним приходит на номер телефона жертвы в штатном порядке
    • код доверчиво пересылается хакерам
    • происходит верификация и вуаля

    Фактически, вместо факта взлома системы безопасности имеет место обман, выманивание у доверчивого пользователя конфиденциального ключа. Претензии к Google? За что – двухфакторная аутентификация сработала так, как и описано в стандарте и пользовательском соглашении. Другое дело, что когда ее создавали, не подумали о «защите от дурака», как бы обидно это не звучало для миллионов людей.

    ПО ТЕМЕ: 

    Что можно сделать?

    Ключевой информацией для взлома является связка логин-пароль – если хакерам есть, за что зацепиться, появляется смысл начать атаку. Эти данные они могут выудить тысячей и одним способов, но зачастую страдают самые беспечные пользователи. Например, Марк Цукерберг, оконфузившийся своим супер-паролем «dadada» в нескольких аккаунтах совсем недавно. Гигантские базы данных регулярно воруются и утекают в Сеть – возьмите за привычку использовать разные, красивые и сложные пароли, а также менять их хотя бы раз в квартал, а не когда станет поздно и обидно.

    Алекс МакКоу также рекомендует вчитываться в тексты сообщений от роботов сервисов, пусть вы и получаете их десятками на дню. А вдруг вовремя обратите внимание, что адресатом указан Facebook, а ваш аккаунт на Яндексе или в Gmail? Злоумышленники постоянно меняют личины, но из-за мелких нестыковок в схеме работы их можно вывести на чистую воду. Если просят перейти по ссылке – вглядитесь в символы, это может быть фишинговая страничка. А если есть сомнения хоть в чем-то, лучше лишний раз оповестить службу безопасности. Это проще, чем отвоевывать свой аккаунт назад.

    Смотрите также:

    yablyk.com

    Двухфакторную аутентификацию в Google, Apple и других сервисах легко обойти

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

    Ресурс BreakDev сообщил о том, что старшему хакеру компании KNowBe4 Кевину Митнику удалось легко обойти систему двухфакторной аутентификации. Он уже протестировал свой метод на Google, Apple, Microsoft и даже Amazon. В каждом случае он сработал. Данный способ защиты надежнее привычной связки логина и пароля, потому как после ввода этих данных пользователю на номер телефона отправляется SMS-сообщение с одноразовым кодом для авторизации. Без него попасть в аккаунт невозможно.

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

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

    Если вы используете двухфакторную систему защиты от взлома, всегда вводить одноразовый PIN-код только на проверенных ресурсах и максимально внимательно смотрите на то, чтобы доменное имя сайта полностью соответствовало настоящему. Только так можно защититься от нового способа обмана в сети. Раннее сотрудник Google сообщил о том, как легко взломать любой компьютер на Windows 10.

    До 13 октября включительно у всех желающих есть возможность совершенно бесплатно получить смарт-браслет Xiaomi Mi Band 4, потратив на это всего 1 минуту своего личного времени.

    Присоединяйтесь к нам в Twitter, Facebook, ВКонтакте, YouTube, Google+ и RSS чтобы быть в курсе последних новостей из мира технологий будущего.

    AppleGoogleВзломЗащитаХакеры

    akket.com

    Смотрите также