Как обойти двойную аутентификацию

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

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

Большинство пользователей интернета знают о Даркнете. Многие даже пытались зайти и купить там, что-либо. Те, кто уже прошарен в этой теме знают, что в таких местах легко можно приобрести запрещенные товары или услуги, в том числе и взлом любого аккаунта. Конечно, его можно заказать и в Клирнете, но тут происходит недоверие к людям, предлагающим эти услуги. Ведь, как так, мы находимся на светлой, незащищённой стороне паутины, они не боятся ответственности? Или это очередная уловка мошенников?
Ну, речь не об этом, мы немного отвлеклись. В большинстве таких случаев Взлом производят при помощи «фишинга».

Что такое фишинг?

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

Как пробить двухфакторку

Самый нашумевший и трудоёмкий способ эксперементально выявлен австралийским исследователем Шубхамом Шахом (Shubham Shah). Парню было всего 18 лет, когда он многим открыл глаза на ненадежность 2FA.

В его статье «Как я обошел двухфакторную аутентификацию в Google, Facebook, Yahoo,LinkedIn и многих других» молодой человек подмечает, что при виде аутентификации он думал: «Можно ли произвести взлом такими способами, как»:

Все они, по его словам, являются действительными вариантами атак, но навряд ли будут работать, ибо настолько простейшие и уже явно защищены.
После перебора всех этих способов Шубхам понял, что на всех сервисах с 2FA есть слабое место — голосовая почта.
Ибо для получения полного доступа к ящику нужно всего лишь узнать номер жертвы, а затем использовать сервис подделки контактного номера, типа Spoofcard.
Перейдем к последовательности действий(с твоего позволения, в роли хакмастера будешь ты):

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

Источник

Взлом вк, двухфакторная аутентификация не спасет

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

1000-1500 рублей, время взлома

30 минут. Единственное условие — недобросовестный оператор мобильной связи?

Предупреждение. Все материалы и методы, изложенные ниже, представлены исключительно в ознакомительных и экспериментаторских целях. Напоминаем, что взлом персональных страниц пользователей и сбор данных незаконным путём преследуется законодательством РФ (в частности УК РФ). Будьте осторожны и экспериментируйте только со своими или тестовыми аккаунтами!

Приступим сразу к делу.

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

500-1000 рублей. Возможно это выглядит достаточно муторно и проблемно, но по факту это занимает не более получаса и вряд ли вас кто-то будет после искать и найдет. Способы оплаты везде разные, кто-то принимает только биткоины, кто-то не стесняется указать свою карту в телеграме. К слову сказать, достаточно часто встречающееся явление, когда злоумышленник не боится указывать номер своей (или не своей?) карты, ибо, например, деньги с карты на карту уводят досточно беспроблемно и после предъявить обвинение держателю карты, куда были переведены деньги, практически невозможно. Лично у меня нет комментариев по данному поводу.

Итак, мы получили скан паспорта пользователя. Нет, фотошопить фотографию с лицом пользователя, где он держит его перед камерой, мы не будем. Мы пойдем к мобильным операторам, которые с радостью подставят жертву. Регистрируем фейковую страницу ВКонтакте на левый номер телефона, врубаем VPN и пишем в официальное сообщество оператора мобильной связи жертвы сообщение примерно следующего содержания:

«Добрый день. Нам требуется установить переадресацию всех звонков на новый номер телефона. Доступа к самому телефону не имею. Что от меня нужно для совершения данной операции?»

И что же дальше? У вас спросят номер телефона жертвы, новый номер телефона, куда требуется переадресовать все звонки и паспортные данные для «подтверждения вашей личности и владения номером телефона». Здорово, не правда ли? Достаточно просто купить новую симку на вокзале за 300 рублей, либо купить виртуальную симкарту где-нибудь в сети и не париться. Сообщаете всю информацию и все, дело в шляпе — переадресация включена и, что самое удивительное, — жертва не мгновенно оказывается уведомленной о подключении переадресации.

Сначала уведомление вообще не пришло, прошел час — пришло целых 2 раза:

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

Вообщем плохо, если лично у вас такой оператор:

Итак, теперь идем ВКонтакте и начинаем взламывать:

Начинаем восстанавливать пароль:

На данном этапе наша жертва получает смс о том, что кто-то пытается сменить пароль на странице:

Но только вот, что с того? Что вот лично вы успетеете сделать за 2 минуты? Смс мы не перехватим, т.к. переадресация работает только на звонки. Но нам это и не интересно. Нажимаем «Выслать код повторно» и видим следующее окно:

Поняли, что мы дальше сделаем? Ага, пусть робот сделает звонок и оператор переадресует его на на наш номер телефона и сообщит нам код для смены пароля. Итак, звоним:

Робот звонит на наш левый номер телефона, сообщает код и после мы просто берем и меняем пароль:

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

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

а если страницу успеть удалить это поможет??

А что ж так то, хороших операторов порекламировали, а плохого нет?

Как вообще найти этого «недобросовестного оператора»? Зайти в салон, увидеть самую бандитскую рожу а-ля Колян из «Реальных пацанов» и спросить не продает ли он сведения о своих клиентах?

Оператор Lifecell ворует даже содержимое вашего буфера обмена

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

ИБ на пальцах. Вводный пост

Здравствуйте, товарищи пикабушники. Без малого почти 10 лет я занимаюсь вопросами информационной безопасности в разрезе утечек информации (уверен, ника уже достаточно, чтобы Лига Детективов устроила полный деанон, но я и не шифруюсь вроде). И с течением времени всё больше начала напрягать ситуация, когда люди попадают в неприятности из-за пробелов в вопросах инфобеза. Вы можете возразить, что не обязаны это знать. Увы, лет 5-10 назад, когда интернет был более дружелюбным, этот аргумент бы прокатил. Но не сегодня. Цифровизация, бигдата, машинное обучение и прочие умные слова понравились большим политикам и технологии стремительно врываются в нашу жизнь. Горящие сроки (внедрения) превращаются в горящие сраки со всеми вытекающими. В общем, можно было бы много ворчать на тему, что всё плохо. Но я решил попробовать хоть что-то изменить.

Так и родилась идея проекта «ИБ на пальцах». Суть проста: быть этаким капитанам-очевидностью от ИБ. Пояснять простым языком для неспециалистов, что хорошо, а что плохо в этих ваших интернетах. Поднимать темы, над которыми вы не задумывались или не хотели задумываться.

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

Смартфоны. Выбор пал на них, потому что сегодня это самый распространённый девайс, который человек таскает с собой везде и всюду. Уверен, кто-то сейчас этот пост читает сидя верхом на белом «друге». Вот на столько близок сегодня человек и смартфон.

Но сперва данные надо собрать. Сделать можно двумя способами: либо берём у операторов, либо из приложений. Таки есть разница. У сотовых операторов взять проще. Вот только будет ли достаточно точности? Хорошо растыканные базовые станции обеспечивают точность 3-5 метров сегодня. Вот только учитывают ли такие данные то, что мы живём в как минимум трёхмерном мире. Грубо говоря, я могу определить дом, в котором живёт заражённый. А этаж? Не говоря уже о квартире. Кого изолировать? Подъезд заварить что ли? Да ну, бред какой-то.

Поэтому рассмотрим вопрос с приложением. Задумка со сбором данных из приложений лучше, потому что те же условные неяндекс.карты используют гибридный способ определения местоположения пользователя: по GPS\Глонасс, wi-fi, базовым станциям. В итоге получается более точная картина. Но есть одна проблема: надо заставить условный неяндекс делиться этой информацией. Кроме того, не до конца понятно, достаточно ли данных собирают они, чтобы строить графы связей пользователей (кто с кем контактировал). Поэтому мысль о создании собственного приложения не стоило бы сбрасывать со счетов. Со всех сторон удобнее: собираем что хотим (на самом деле, нет) и ни с кем не делимся. Google и Apple даже совместный протокол разработали и внедряют его на уровне своих операционных систем. Что собирает и передаёт этот протокол и уже ли мы все под колпаком техногигантов здесь разбирать не буду. Давайте оставим это на следующий пост.

Скажу лишь, что их идее уже лет 10 как. Как по мне, главной проблемой любого из подходов к сбору данных является достоверное определение контактирующих с заражённым. Для этого надо, чтобы смартфоны встретившихся людей автоматически общались друг с другом, фиксируя продолжительность и «близость» контакта. То есть как долго и на каком расстоянии друг от друга общались люди. Можно ли сделать такую штуку? Да. Причём нечто похожее уже не раз использовалось. Технология uXDT (ultrasound cross-device tracking), опирается ультразвуковые маячки. Активно её используют как минимум с 2017 года.

Цитата из-под гиперссылки для лл: «Идея в том, что во время воспроизведения рекламы по ТВ, на мобильном устройстве или в офлайновом магазине/ресторане издаётся неслышимый уху ультразвуковой сигнал. Обычно он добавляется к музыкальному клипу или джинглу. Этот сигнал регистрируется микрофонами окружающих электронных устройств (ноутбуки, ПК, смартфоны, планшеты) — и после этого рекламодатель знает, что этот конкретный пользователь одновременно владеет перечисленными устройствами. Это нужно в том числе для связывания рекламных профилей и отслеживания пользователя, который выходит в интернет с разных устройств».

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

Это было описание принципа. Что реально умеют (а не могли бы) делать такие приложения, предлагаю расписать в следующем посте. Обратная связь от вас приветствуется. У меня, конечно, есть какая-то тактика и я её придерживаюсь, но интересные темы из комментов тоже можно раскрыть.

Источник

Обход двухфакторной аутентификации 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!

Источник