Comments 51
Двухфакторая авторизация сводит на нет такие виды уязвимостей.
Да и банальная осмотрительность — «Это что за адрес отправителя такой?»
Ох, я бы с вами поспорил. Cookie не httpOnly, на видео показан их вывод в тело страницы, а отослать их на сниффер не составит никакого труда. Да, может быть привязка к ip, например, но это уже зависит от сервиса.
Так что, двухфакторая авторизация — не панацея.
Так что, двухфакторая авторизация — не панацея.
Ну значит разработчикам Google есть к чему стремится.
ь
ь
fixed
UFO just landed and posted this here
Даже если двухфакторная авторизация отключена, у 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х факторная авторизация
UFO just landed and posted this here
Остатки ему оплатит поднявшаяся репутация.
UFO just landed and posted this here
Вообще, по их правилам, данная бага стоит 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 по их же правилам.
вчера пришло смс от гугла что кто то пытался зайти в мой акк
Sign up to leave a comment.
Кража пароля от Gmail аккаунта