Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Двухфакторая авторизация сводит на нет такие виды уязвимостей.
Да и банальная осмотрительность — «Это что за адрес отправителя такой?»
Ох, я бы с вами поспорил. Cookie не httpOnly, на видео показан их вывод в тело страницы, а отослать их на сниффер не составит никакого труда. Да, может быть привязка к ip, например, но это уже зависит от сервиса.
Так что, двухфакторая авторизация — не панацея.
Так что, двухфакторая авторизация — не панацея.
Ну значит разработчикам Google есть к чему стремится.
ь
ь
fixed
Даже если двухфакторная авторизация отключена, у Gmail есть дополнительный барьер защиты, о котором мало кто знает. Просто пароль от произвольного ящика ничего не даст, нужно еще точно знать страну владельца ящика и использовать прокси с ip этой страны, иначе Gmail при входе запросит дополнительные данные, например, адрес запасного email, и не пустит внутрь, если ответ будет неправильным.
С утра прочитал не багхантер, а бухгалтер, думаю нихренасе у них них гуманитарии отжигают, что же тогда может сделать гуру…
Бухгалтер — гуманитарий?!
Если бухгалтерия это часть экономики как науки, то это скорее общественная наука.
Вы посмотрите, действительно багхантер.
Тоже слегка удивился, что бухгалтер нашёл уязвимость, да ещё и в Gmail.
Тоже слегка удивился, что бухгалтер нашёл уязвимость, да ещё и в Gmail.
Ой да ну прямо, на первой же картинке крупным шрифтом Hatechnion — выпускник электроинжинерного факультета зарегистрировал подопытный аккаунт на название своей альма-матер.
Тоже удивлён был. Но только после вашего комментария увидел что там не бухгалтер было написано.
После клика, клиента отправляет на специально сформированную страницу с JavaScript кодом, который благодаря CSRF отправляет запрос на
Коллеги, подскажите старику, плохо разбирающемуся в вопросах безопасности — а каким образом у них джаваскрипт на левой странице так спокойно ходит к google.com как к себе домой? Ведь специально для предотвращения этого сделаны всякие «Access-Control-Allow-Origin» и прочие защиты. Если я размещу в интернете страничку, которая делает $.ajax( 'google.com/accounts/recovery/verifyuser' ) — оно ведь не сработает.
Так уязвимый скрипт у них на домене :) это как скрипт, который оставили сами разработчики, только передается как параметр урла. Фильтр xss не ловит, так как вывод внутри скрипта другого.
Он разве на левой? Там JSку можно внедрить в параметр, и эта JSка будет работать уже внутри страницы на этом сама домене, а уж отправить на сторону пасс — плевое дело, банально img с параметром грузануть.
А по факт — «Первым делом необходимо было отправить жертве фишинговую ссылку, которая выглядела как настоящая:», понятно что там дальше уязвимость, но если человек ходит по всем левым ссылкам из письма, то тут мало что спасет.
А по факт — «Первым делом необходимо было отправить жертве фишинговую ссылку, которая выглядела как настоящая:», понятно что там дальше уязвимость, но если человек ходит по всем левым ссылкам из письма, то тут мало что спасет.
Насколько я понимаю из описания:
По ссылке из письма клиент переходит на страницу атакующего, с которой уже и начинается атака. Или под словами «специально сформированная страница» подразумевается страница гугла? O_O.
Это все понятно — с тем же успехом ему можно поставить ActiveX, затребовать elevation и отформатировать диск. По самой уязвимости вопросов нет, все понятно. Но я совершенно не понимаю как они со «специально сформированной страницы» отправляют запросу гуглу и те обрабатываются :(. Это идет вразрез с моими довольно скромными знаниями о том, как сейчас работает HTTP — потому и спрашиваю :).
После клика, клиента отправляет на специально сформированную страницу
По ссылке из письма клиент переходит на страницу атакующего, с которой уже и начинается атака. Или под словами «специально сформированная страница» подразумевается страница гугла? O_O.
А по факт — «Первым делом необходимо было отправить жертве фишинговую ссылку, которая выглядела как настоящая:», понятно что там дальше уязвимость, но если человек ходит по всем левым ссылкам из письма, то тут мало что спасет.
Это все понятно — с тем же успехом ему можно поставить ActiveX, затребовать elevation и отформатировать диск. По самой уязвимости вопросов нет, все понятно. Но я совершенно не понимаю как они со «специально сформированной страницы» отправляют запросу гуглу и те обрабатываются :(. Это идет вразрез с моими довольно скромными знаниями о том, как сейчас работает HTTP — потому и спрашиваю :).
Именно специально софрмированная внедренным JS скриптом страница на гугловом домене, XSS из-за того что один из параметров никак не проверяется (не проверялся).
Посмотрите внимательно на скриншоты, там видно с гуглового домена никто не уходит, а JS-ка внедряется через rpu параметр GET запроса.
Посмотрите внимательно на скриншоты, там видно с гуглового домена никто не уходит, а JS-ка внедряется через rpu параметр GET запроса.
А, понятно. В статье «rpu» упоминается как последнее действие — но на самом деле это то, с чего все начинается?
1) формируем ссылку с JSкой в параметре rpu
2) отправляем html письмецо со ссылкой, скрытой под нечто более красивое
3) юзер переходит по ссылке, а там google домен и далее не всем понятные кракозябры*
4) показываем юзеру красивую страничку в гуглостиле, с просьбой вбить пароль, данные кредитки, кличку любимой собаки и т.д. на что фантазии хватит
5) отправляем любые параметры по нужным адресам, а юзеру показываем «спасибо, всё хорошо» и редиректим обратно в почту
* признаться я бы и сам мог на такую ссылку попасться, т.к. обычно не смотрю на параметры, доверяя домену, да и малоли сам гугл туда чего-то пишет, но главное правило — не переходить по непонятным ссылкам строго блюду, иногда, дабы удовлетворить параною, смотрю тело письма, в поисках каких то странностей
** и да, у меня однажды увели пароль от гугла, но дырка была в том, что был привязан давно забытый ящик на mail.ru, в котором по неосторожности был пароль qwerty, примерно в это же время появилась 2х факторная авторизация
2) отправляем html письмецо со ссылкой, скрытой под нечто более красивое
3) юзер переходит по ссылке, а там google домен и далее не всем понятные кракозябры*
4) показываем юзеру красивую страничку в гуглостиле, с просьбой вбить пароль, данные кредитки, кличку любимой собаки и т.д. на что фантазии хватит
5) отправляем любые параметры по нужным адресам, а юзеру показываем «спасибо, всё хорошо» и редиректим обратно в почту
* признаться я бы и сам мог на такую ссылку попасться, т.к. обычно не смотрю на параметры, доверяя домену, да и малоли сам гугл туда чего-то пишет, но главное правило — не переходить по непонятным ссылкам строго блюду, иногда, дабы удовлетворить параною, смотрю тело письма, в поисках каких то странностей
** и да, у меня однажды увели пароль от гугла, но дырка была в том, что был привязан давно забытый ящик на mail.ru, в котором по неосторожности был пароль qwerty, примерно в это же время появилась 2х факторная авторизация
Остатки ему оплатит поднявшаяся репутация.
Вообще, по их правилам, данная бага стоит 5000$.
Во-первых, они не принимают никакие вектора, работающие через фишинг или соц. инженерию (http://www.google.com/about/appsecurity/reward-program/ — "...that the scope of the program is limited to technical vulnerabilities in Google-owned web applications...")
Во-вторых, CSRF тут не нужен, так как уже есть javascript на нужном домене (всё происходит на google.com, в отдельности CSRF не имеет в данном случае импакта). Так что непонятно в статье про «целую цепочку уязвимостей». Их всего две :)
Получается, здесь просто одна XSS на «highly sensitive service», за которую и платят $ 5000 по их же правилам.
Во-первых, они не принимают никакие вектора, работающие через фишинг или соц. инженерию (http://www.google.com/about/appsecurity/reward-program/ — "...that the scope of the program is limited to technical vulnerabilities in Google-owned web applications...")
Во-вторых, CSRF тут не нужен, так как уже есть javascript на нужном домене (всё происходит на google.com, в отдельности CSRF не имеет в данном случае импакта). Так что непонятно в статье про «целую цепочку уязвимостей». Их всего две :)
Получается, здесь просто одна XSS на «highly sensitive service», за которую и платят $ 5000 по их же правилам.
вчера пришло смс от гугла что кто то пытался зайти в мой акк
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кража пароля от Gmail аккаунта