Комментарии 99
Эту ветку OpenSSL мы начали использовать в декабре 2013 года
Знавший об уязвимости, мог прослушивать «зашифрованный» трафик почти во всем интернете с марта 2012 года
Мы решили отталкиваться от временного промежутка, который начинался со времени публикации об уязвимости
Ооок…
На данный момент нету подтверждений, что с марта 2012 года об уязвимости знало большое количество людей или организаций. Массовая эксплуатация стала возможна после появления PoC «запусти и получи результат» (где-то спустя часа три после публикации об уязвимости). Анализ рисков приводит нас к простому выводу: наиболее высок шанс компрометации учетных записей, заходивших после публикации PoC. За вредоносной активностью в их сессия, как я отметил в посте, мы следим _особо_. Но это не значит, что мы не следим за вредоносной активностью в сессиях _всех_ наших пользователей.
Больше количество то и не надо. Достаточно одной-АНБ.
1. В случае «обычной» 0-day уязвимости подход оправдан, в случае уязвимости которая даже теоретически не оставляет следов использования на сервере — это неоправданный оптимизм.
2. Если бы подобное заявление сделал «обычный» сайтик, его можно было понять — кому «он» нужен, когда такие заявления делает сайт из Alexa Top 50 с многомиллионной аудиторией… Если исключить компании напрямую оперирующие деньгами, где еще по вашему мог эксплуатироваться подобный баг?
3. Что опаснее, когда 64 кб куски данных за 3 часа попадают в руки 100500 школьников (которые сами не смогли написать скрипт для использования уязвимости) или когда 1 неизвестный злоумышленник в течении нескольких месяцев планомерно собирает данные?
2. Если бы подобное заявление сделал «обычный» сайтик, его можно было понять — кому «он» нужен, когда такие заявления делает сайт из Alexa Top 50 с многомиллионной аудиторией… Если исключить компании напрямую оперирующие деньгами, где еще по вашему мог эксплуатироваться подобный баг?
3. Что опаснее, когда 64 кб куски данных за 3 часа попадают в руки 100500 школьников (которые сами не смогли написать скрипт для использования уязвимости) или когда 1 неизвестный злоумышленник в течении нескольких месяцев планомерно собирает данные?
Говорится, что не так и все очень плохо (с)
Уязвимость была доступна только в определённой версии OpenSSL, а эта версия, как и было написано, в Яндексе была применена только в декабре 2013 года.
Помимо этого, в Яндексе постоянно работают алгоритмы обнаружения подозрительной активности в аккаунтах, и если она замечена, то система потребует сменить пароль и расскажет владельцу, что произошло что-то плохое. Так выявлять пострадавших гораздо правильнее, нежели рубить всех не глядя.
Помимо этого, в Яндексе постоянно работают алгоритмы обнаружения подозрительной активности в аккаунтах, и если она замечена, то система потребует сменить пароль и расскажет владельцу, что произошло что-то плохое. Так выявлять пострадавших гораздо правильнее, нежели рубить всех не глядя.
А пароли, которые вы предлагаете на своей страничке в качестве надежных… На самом деле не надежны)
Комикс хороший, но в нем не учитывается наличие защиты от перебора паролей :).
[зануда]Оба пароля не надежны. Один ламается брутфорсом, 2ой подбором по словарю.
Имхо нужно использовать пароли Gi702X1eh9X5ywGVIgN6. И для их хранения менеджер паролей (keepass, lastpass). Плюс такого подхода еще и в том, что к каждому сервису свой пароль. Взлом ресурса не компрометирует аккаунты на других ресурсах [/зануда]
Имхо нужно использовать пароли Gi702X1eh9X5ywGVIgN6. И для их хранения менеджер паролей (keepass, lastpass). Плюс такого подхода еще и в том, что к каждому сервису свой пароль. Взлом ресурса не компрометирует аккаунты на других ресурсах [/зануда]
За то взлом мастерпароля от keepass компроментирует все сервисы разом.
Это как кошелек, «устройство которое позволяет потерять сразу все деньги».
Или думаете, что на локальной машине невозможно перехватить ввод пароля?
Это как кошелек, «устройство которое позволяет потерять сразу все деньги».
Или думаете, что на локальной машине невозможно перехватить ввод пароля?
Это возможно, но это должен быть троян, который специально охотится на базы keepass'a. Он должен скейлогить пароль и угнать файл базы. И конечно безопастность должна обеспечиваться комплексом мер (антивирус, руки не из задници и тд). Серебрянной пули не существует.
Если мы говорим о взломе брутфорсом пароля от базы, то во первых нужно, что бы она оказалась у злоумышленника (троян). Во вторых естественно база должна быть защищена сильным паролем, подбор которого невозможен или экономически не выгоден.
Если мы говорим о взломе брутфорсом пароля от базы, то во первых нужно, что бы она оказалась у злоумышленника (троян). Во вторых естественно база должна быть защищена сильным паролем, подбор которого невозможен или экономически не выгоден.
Да, именно так, именно «специально охотится».
Keepass не какая-то супер уникальная программа. Он очень популярен. А т.к. менеджер паролей по умолчанию предполагает хранение ценной информации, то заточить под него специальную версию трояна не составит проблемы. Ведь точат же трояны под конкретные банки, и ничего, вполне успешно. Так что не удивлюсь, если в нормальных троянах есть пунктик по поиску и пересылке баз с паролями. Тем более, что они очень маленькие.
Keepass не какая-то супер уникальная программа. Он очень популярен. А т.к. менеджер паролей по умолчанию предполагает хранение ценной информации, то заточить под него специальную версию трояна не составит проблемы. Ведь точат же трояны под конкретные банки, и ничего, вполне успешно. Так что не удивлюсь, если в нормальных троянах есть пунктик по поиску и пересылке баз с паролями. Тем более, что они очень маленькие.
Не обязательно использовать менеджер паролей, можно использовать простой алгоритм хеширования, подставлять туда адрес сайта, логин пользователя, или другие опорные данные, на втором шаге добавлять к строке соль в виде ключевого слова, на третьем шаге брать хеш от получившегося значения, и уже его использовать в качестве пароля. Можно дополнительно улучшить алгоритм делая часть символов в получившемся пароле заглавными. Правило для создание заглавного символа может быть простым, вроде — каждая чётная буква получившегося хеша заглавная если в исходных данных без соли чётное количество символов, ну или что то в этом духе.
При использовании подобного генератора паролей становится недостаточным узнать мастер-пароль, поскольку ещё потребуется знать имя аккаунта, адрес сайта, а возможно ещё и соль, которая может быть разная для разных ресурсов. К примеру:
md5(yandex.ru+bob+использую для yandex many) или (gmail.com+bob+основная почта)
:)
При использовании подобного генератора паролей становится недостаточным узнать мастер-пароль, поскольку ещё потребуется знать имя аккаунта, адрес сайта, а возможно ещё и соль, которая может быть разная для разных ресурсов. К примеру:
md5(yandex.ru+bob+использую для yandex many) или (gmail.com+bob+основная почта)
:)
Доп: если в хеше вдруг оказались одни цифры и нет символов, можно дополнительно циклически сдвигать хеш до получения символов в пароле. Помимо этого длина пароля может регулироваться в зависимости от необходимых требований со стороны сервера. В общем годный генератор паролей, алгоритм которого можно держать в голове, оказывается лучше любого менеджера паролей.
Я вообще не использую сторонние сервисы по хранению паролей. Причина проста — «дядя» может прикрыть лавочку. Критичные пароли — в голове. Все остальное в самописном приложении с блекджеком шифрованием. База на хостинге + клиент + бэкапы при изменении БД.
НЛО прилетело и опубликовало эту надпись здесь
В таком случае целесообразно использовать менеджер паролей, у которого есть мобильный клиент, например, 1password, KeePass. Зашифрованную базу паролей можно держать на дропбоксе.
У вас смартфон никогда не садился в самый неприятный момент?
Представьте, что смартфон утром например обновил GoogleTalk, новая версия почему-то стала сильно жрать батарейку и к обеду у вас смартфон сел в ноль. Пароль нужен прямо сейчас. Ваши действия?
Представьте, что смартфон утром например обновил GoogleTalk, новая версия почему-то стала сильно жрать батарейку и к обеду у вас смартфон сел в ноль. Пароль нужен прямо сейчас. Ваши действия?
Не спорю, всякое может случиться, я лишь предложил выход из ситуации с онлайн менеджерами паролей. А в ситуацию, описанную вами, я не попаду, ибо пароли от важных сервисов я помню наизусть.
Тот пароль, который нужен «прямо сейчас» надо запоминать, а не беспечно полагаться на менеджер паролей. Я использую ластпасс для всяческих регистраций на форумах где не хочу помнить пароль. Но пароль от Evernote, GetPocket, Google я помню (однако это не исключает того что я их не храню в ластпассе).
Таким образом если мне нужен пароль, который мне действительно нужен — то ластпасс я буду использовать только для быстроты его получения.
Хотя и тут можно возразить. Мол, смарт разрядился, ноут заглючил, ласпасс лежит, а в добавок ещё и провал памяти. Случай не надуманный — до сих пор не понимаю как однажды умудрился просто не вспомнить пароль, который вводил по несколько раз за день.
Как уже говорили раньше — серебрянной пули не существует.
Таким образом если мне нужен пароль, который мне действительно нужен — то ластпасс я буду использовать только для быстроты его получения.
Хотя и тут можно возразить. Мол, смарт разрядился, ноут заглючил, ласпасс лежит, а в добавок ещё и провал памяти. Случай не надуманный — до сих пор не понимаю как однажды умудрился просто не вспомнить пароль, который вводил по несколько раз за день.
Как уже говорили раньше — серебрянной пули не существует.
однажды умудрился просто не вспомнить пароль, который вводил по несколько раз за день
Была аналогичная история. Просто хлоп, один миг, и не помнишь его.
У меня на днях была аналогичная ситуация — пол дня не мог вспомнить мастер-пароль от KeePass. Хотя ввожу его по несколько раз на день.
Если вводить по несколько раз в день, то его можно и не вспоминать – тут уже должна активироваться механическая память. Руки на клаву – и вперёд.
Она тоже не помогла. Кстати, у механической памяти есть и обратная сторона — когда приходится вводить пароль на мобильном устройстве.
Ну, там ей не обойтись, но обычно она тоже немного помогает, хотя зависит от клавиатуры. На HTC, где буквы хъжэбю вынесены в четвёртый ряд, меняется положение букв, и набрать что-то осмысленное сложнее, не говоря уж о паролях.
На мобильных устройствах очень огорчает отсутствие одновременно русских и английских букв на клавиатуре. Набирая русские слова в английской раскладке с рядом специфичных изменений (своеобразная соль) можно получать весьма устойчивые пароли, а главное — их легко запомнить. Но ввод таких паролей с телефона это ад.
В Яндекс-клавиатуре при вводе паролей добавляется третья раскладка, «англо-русская», где одновременно отображена кириллица с латиницей. Вроде как одна из фишек.
Для всяких форумов и одноразовых регистраций я использую один и тот же пароль. Словарное слово, кстати. Брутится на ура, уверен. Потому что все эти учётки мне абсолютно не нужны. Главное, что я не использую этот пароль для важных учёток.
При использовании Keepass с базой паролей в Dropbox у вас во-первых есть одинаковый доступ ко всем паролям с любого своего компа/планшета/телефона (в т.ч. при отсутствии инета), и во-вторых если помнить пароль от Dropbox то можно на любом чужом компе поставить Keepass и получить доступ ко всем своим паролям (если, конечно, не стрёмно на чужом компе вводить мастер-пароль базы keepass). В общем, проблема доступности паролей надумана.
Вполне возможно, что скоро менеджеры паролей будут частью антивирусников. Например, у McAfee есть компонент SafeKey, который сохраняет все пароли и синхронизует между всеми устройствами, зарегистрированными в LiveSafe. Я думаю такой функционал появится через год во всех антивирусных продуктах.
А для внезапно севшего мобильника у меня есть внешняя батарейка, так что пароли можно носить всегда с собой на всех устройствах.
А для внезапно севшего мобильника у меня есть внешняя батарейка, так что пароли можно носить всегда с собой на всех устройствах.
У трубадура получилась низкая энтропия, т.к. паттерн искусственно заужен.
Если допустить, что любая буква в слове может быть заглавной, это уже 9 бит энтропии.
Если позиция 2-х дополнительных символов произвольна — добавляем еще log2(11!/(11-2)!) ~ 6 бит.
Если «другой» символ — любой печатаемый ASCII, добавляем log2(96) ~ 6 бит.
Получается, 28-1-1-4+9+6+6=43 бита.
Если допустить, что любая буква в слове может быть заглавной, это уже 9 бит энтропии.
Если позиция 2-х дополнительных символов произвольна — добавляем еще log2(11!/(11-2)!) ~ 6 бит.
Если «другой» символ — любой печатаемый ASCII, добавляем log2(96) ~ 6 бит.
Получается, 28-1-1-4+9+6+6=43 бита.
Есть статистически более вероятные варианты, которые, как раз, близки к описываемому на картинке. Можно взять какую-нибудь утекшую базу, лежащую в интернете и посмотреть.
Вероятность появления цифры в конце (для пароля содержащего, как минимум, цифры и буквы, с 1-2 цифрами) — выше, чем в других позициях.
Вероятность появления заглавной буквы в начале — выше (для паролей, содержащих буквы в двух регистрах, с 1-2 заглавными).
А такой сдвиг в пространстве вероятностей происходит по одно тривиальной причине: человеческая лень. Правда, в сочетании с политикой ресурса, для которого, используется этот пароль. Ресурс считает, что нужно использовать «надежные» пароли — и требует не менее 3 классов символов (маленькие, большие буквы, цифры). А пользователь upcase'ит первую букву, дописывает одну цифру и т. п. Несмотря на мое, в целом, адекватное отношение к нормальным паролям — на куче ресурсов пароль тоже укладывается в этот паттерн. Просто потому, что расчехлять менеджер паролей для каждого ресурса мне лень.
Вероятность появления цифры в конце (для пароля содержащего, как минимум, цифры и буквы, с 1-2 цифрами) — выше, чем в других позициях.
Вероятность появления заглавной буквы в начале — выше (для паролей, содержащих буквы в двух регистрах, с 1-2 заглавными).
А такой сдвиг в пространстве вероятностей происходит по одно тривиальной причине: человеческая лень. Правда, в сочетании с политикой ресурса, для которого, используется этот пароль. Ресурс считает, что нужно использовать «надежные» пароли — и требует не менее 3 классов символов (маленькие, большие буквы, цифры). А пользователь upcase'ит первую букву, дописывает одну цифру и т. п. Несмотря на мое, в целом, адекватное отношение к нормальным паролям — на куче ресурсов пароль тоже укладывается в этот паттерн. Просто потому, что расчехлять менеджер паролей для каждого ресурса мне лень.
Есть простой способ создать неподбираемый и легко запоминаемый пароль из любого числа символов. Например zaqwedcvbgtyujm. Или vbnhgfrtyujm. Просто проследите паттерн на клавиатуре.
Зато mail.ru сегодня успокоили-по их мнению пароли менять не обязательно, и так сойдет. Но сертификаты себе они все же перегенерили…
Это они поторопились и в комментариях им уже подсказали.
Вкратце: использовалась старая версия OpenSSL, пароли в безопасности. Но, некоторыесами себе злобные буратино используют одни и те же пароли на почте и на сторонних сайтах, поэтому такие пароли могут быть скомпрометированы. Об этом стоит напомнить, также как и о настройках бана отозванных SSL сертификатов, которая стоит по умолчанию не во всех браузерах!
Вкратце: использовалась старая версия OpenSSL, пароли в безопасности. Но, некоторые
«использовалась старая версия OpenSSL, пароли в безопасности» звучит сюрреалистично :)
Старая версия OpenSSL не поддерживает TLS 1.1 и TLS 1.2, а также имеет целую пачку уязимостей: web.nvd.nist.gov/view/vuln/search-results?adv_search=true&cves=on&cve_id=&query=&cwe_id=&cpe_vendor=openssl&cpe_product=cpe%3A%2F%3Aopenssl%3Aopenssl&cpe_version=cpe%3A%2F%3Aopenssl%3Aopenssl%3A1.0.0&pub_date_start_month=-1&pub_date_start_year=-1&pub_date_end_month=-1&pub_date_end_year=-1&mod_date_start_month=-1&mod_date_start_year=-1&mod_date_end_month=-1&mod_date_end_year=-1&cvss_sev_base=MEDIUM_HIGH&cvss_av=&cvss_ac=&cvss_au=&cvss_c=&cvss_i=&cvss_a=
Старая версия OpenSSL не поддерживает TLS 1.1 и TLS 1.2, а также имеет целую пачку уязимостей: web.nvd.nist.gov/view/vuln/search-results?adv_search=true&cves=on&cve_id=&query=&cwe_id=&cpe_vendor=openssl&cpe_product=cpe%3A%2F%3Aopenssl%3Aopenssl&cpe_version=cpe%3A%2F%3Aopenssl%3Aopenssl%3A1.0.0&pub_date_start_month=-1&pub_date_start_year=-1&pub_date_end_month=-1&pub_date_end_year=-1&mod_date_start_month=-1&mod_date_start_year=-1&mod_date_end_month=-1&mod_date_end_year=-1&cvss_sev_base=MEDIUM_HIGH&cvss_av=&cvss_ac=&cvss_au=&cvss_c=&cvss_i=&cvss_a=
Ну да, только TLS 1.1 включен по умолчанию в Firefox начиная только с 27 версии, IE только с 11, Safari только с 7 версии под новым Mac OS X и только Chrome поддерживает с 22 версии.
Старая != устаревшая. Если бы ветку 0.9.x не поддерживали, openssl за раз бы вычистили из дистрибутивов, со всеми последующими версиями (для профилактики). А так даже вся одна уязвимость, найденная в прошлом году, была исправлена до появления CVE.
Ниже вы упрекаете YandexBot (который индексирует _публичные_ ресурсы) в том, что он не поддерживает TLS 1.2, при этом вас устраивает, что кто-то обрабатывает пользовательские данные на версии 0.9.8 в которой нет ни TLS 1.1 ни 1.2?
Яндекс-бот даёт тенденцию рунету. Даже если бы мэйлру оставался на plain-тексте, это бы не мешало людям, думающим о своей безопасности, выбирать яндекс или gmail. А вот отсутствие TLS 1.2 в яндекс-боте активно мешает разработчикам включить PFS-only на своих сайтах.
И вообще мои претензии к Яндекс-боту в комментарии ниже не ограничены только TLS 1.2. Он по всем параметрам TLS-соединения схож с IE6. В какую сторону может развиваться рунет, если его индексирует бот с возможностями IE6?
И вообще мои претензии к Яндекс-боту в комментарии ниже не ограничены только TLS 1.2. Он по всем параметрам TLS-соединения схож с IE6. В какую сторону может развиваться рунет, если его индексирует бот с возможностями IE6?
Тохочка, секурити апдейты для стабильных версий никто не отменял ) Так что старая != уязвимая, а == стабильная как минимум.
PFS мы ещё не умеем, действительно, но ИМХО это не та фича ради которой стоит сломя голову бежать обновляться.
PFS мы ещё не умеем, действительно, но ИМХО это не та фича ради которой стоит сломя голову бежать обновляться.
Зато Яндекс позаботился о пользователях Mail.ru, выложив ссылку на них первым пунктом.
У меня как раз сегодня в 7 утра по Москве украли деньги с яндекс.денег(
И я просто понятия не имею как это могло случится. ((( Пароль я этот «почти» нигде не использую больше, но уж точно не использую где-то сразу сочетание двух(ведь у меня сменили и основной и платежный пароль).
Пароли сменил, прадва не понятно есть ли в этом толк, т.к. как же именно меня взломали не понятно.
Параноик во мне говорит, что это MITM в 06:40, но логически очень сомневаюсь. Какие есть идеи?
И я просто понятия не имею как это могло случится. ((( Пароль я этот «почти» нигде не использую больше, но уж точно не использую где-то сразу сочетание двух(ведь у меня сменили и основной и платежный пароль).
Хронология событий и предпринятые действия
(время Московское)
В 06:40 я пытаюсь оплатить домены, попадаю на яндекс, но мой платежный пароль не срабатывает. 5
раз и я в бане. Подумал я, что заработался… все-таки ночь не спал. Пошел завтракать…
В 08:00 решил повторить попытку оплатить домены… и опа… я деавторизован в самом яндексе. Пытаюсь авторизоваться под основным паролем — не пускает. Восстановил через секретный вопрос, сменил. Чуя неладное — попадаю в money.yandex.ru и… денег нет, осталось 16 с копейками рублей.
В истории вижу платеж совершен сегодня в 07:09 через paymaster.ru.
Пытаюсь просмотреть детали платежа — требует ввести платежный пароль. Он естественно не подходит, жму восстановить — пишет «Служба безопасности Яндекса заблокировала… тралала обратитесь вот ссылка». Заполняю форму.
Параллельно звоню в paymaster.ru — там мне ничем помочь не могут, пока не появится специалист «через час звоните».
Звоню в Яндекс.Деньги:
Поднимает трубку специалист — рассказываю ситуацию, задает вопросы, говорит — щас переключу на старшего специалиста. Время 9 утра, видимо специалист старший еще не доехал до работы… 25 минут ожидания на проводе… повесил трубку.
Жду 10 утра, звоню в paymaster… появился специалист… Отвечаю на вопросы, что нет, я не совершал платежи, не пополнял мобильник и про ваш сайт до сегодняшнего утра не знал.
У меня из данных точное время платежа, точная сумма. — но по этим данным они найти не могут мой платеж, нужен номер транзакции. Он есть в деталях платежа, который закрыт платежным паролем, который сменили мошенники и яндекс не дает мне его сменить самому.
Где-то там приходит ответ по почте от яндекса, уточняют данные.
Параллельно — звоню в яндекс.деньги. Повторно рассказываю всю ситуацию… переключают на старшего специалиста… долго жду — «алло». Описываю ситуацию еще раз… девушка что-то говорит, я не особо расслышал, но кажется она что-то пошла уточнять, я пытаюсь коечто спросить, но в трубке тишина… тишина длится 5-10 минут, надоело — вешаю трубку.
В параллель с разговором приходит письмо
Ок, в этом я особо и не сомневался.
В этот момент на сайте яндекс. деньги происходит что-то невообразимое. то пропадает баланс, то предлагает мне продолжить регистрацию кошелька… видимо ресетили там мой аккаунт… решил пока не трогать, наверное что-то делают.
Но мне все еще нужен номер транзакции, чтобы дальше выяснить — что случилось с деньгами. Звоню опять… попадаю на первого специалиста… описываю ситуацию… перекидывают на старшего… уже быстрее подходит… опять описываю ситуацию. Прошу номер транзакции из деталей платежа — не дают, с правилами сервиса не спорю.
Случается чудо… есть возможность восстановить платежный пароль… но нужно ввести код… девушка по телефону говорит 5 цифр. уточняю всего 5 или не менее 5ти(так написано на странице). Говорит ровно 5 — это меня очень сильно сбило с толку… после нескольких попыток ввел свой очень старый пароль больше 5 цифр и… ура подошло.
Лезу в детали — нашел номер транзакции и IP адрес
IP-адрес с которого совершен платеж: 78.137.24.136 Черкассы, Украина. McLaut ISP
(Немного радуюсь, что хотя бы IP не мой собственный… было бы очень сложно кому-либо что-то доказывать.)
Звоню в paymaster.ru — выясняю, что деньги ушли на телефон — Киевстар, ничего сделать они не могут, пишите в Webmoney.Telepay.UA (подсказали куда что нажать — чего писать). Отправил, пока ответа нет.
Параллельно связываюсь через ВК с Киевстаром (на сайте ниодного email?! ). Дают мне линк на форму обратной связи(плохо я видимо её искал). Отправил, пока ответа нет.
Думаю — как провайдеру написать… контакты не нахожу. Что еще сделать не представляю… позвонить на номер Киевстара?
Меня смущает очень одно. В 06:40 я пытался ввести платежный пароль и он не подошел. Хотя вводил я его скорее всего правильно. в 07:09 злоумышленник увел мои деньги. Совпадение ли? Мне кажется эти события связаны и именно в 06:40 каким-то образом угнали мой пароль, а далее совершили платеж.
Я проверил историю посещения сайтов в хроме:
В 06640 с сайта 2domains я четко попадаю на roboxchange.com он меня переадресовывает на яндекс.деньги. Домены везде верные — это точно не фишинг.
С сертификатом проблем не выскакивало, я бы уж точно заметил.
Попинговал money.yandex.ru, проверил hosts вроде везде ок все.
В 06:40 я пытаюсь оплатить домены, попадаю на яндекс, но мой платежный пароль не срабатывает. 5
раз и я в бане. Подумал я, что заработался… все-таки ночь не спал. Пошел завтракать…
В 08:00 решил повторить попытку оплатить домены… и опа… я деавторизован в самом яндексе. Пытаюсь авторизоваться под основным паролем — не пускает. Восстановил через секретный вопрос, сменил. Чуя неладное — попадаю в money.yandex.ru и… денег нет, осталось 16 с копейками рублей.
В истории вижу платеж совершен сегодня в 07:09 через paymaster.ru.
Пытаюсь просмотреть детали платежа — требует ввести платежный пароль. Он естественно не подходит, жму восстановить — пишет «Служба безопасности Яндекса заблокировала… тралала обратитесь вот ссылка». Заполняю форму.
Параллельно звоню в paymaster.ru — там мне ничем помочь не могут, пока не появится специалист «через час звоните».
Звоню в Яндекс.Деньги:
Поднимает трубку специалист — рассказываю ситуацию, задает вопросы, говорит — щас переключу на старшего специалиста. Время 9 утра, видимо специалист старший еще не доехал до работы… 25 минут ожидания на проводе… повесил трубку.
Жду 10 утра, звоню в paymaster… появился специалист… Отвечаю на вопросы, что нет, я не совершал платежи, не пополнял мобильник и про ваш сайт до сегодняшнего утра не знал.
У меня из данных точное время платежа, точная сумма. — но по этим данным они найти не могут мой платеж, нужен номер транзакции. Он есть в деталях платежа, который закрыт платежным паролем, который сменили мошенники и яндекс не дает мне его сменить самому.
Где-то там приходит ответ по почте от яндекса, уточняют данные.
Параллельно — звоню в яндекс.деньги. Повторно рассказываю всю ситуацию… переключают на старшего специалиста… долго жду — «алло». Описываю ситуацию еще раз… девушка что-то говорит, я не особо расслышал, но кажется она что-то пошла уточнять, я пытаюсь коечто спросить, но в трубке тишина… тишина длится 5-10 минут, надоело — вешаю трубку.
В параллель с разговором приходит письмо
По Вашему запросу мы провели расследование и приняли все необходимые меры. К сожалению, деньги уже потрачены, и вернуть их нам не удалось.
Кроме того, Ваш счёт не идентифицирован, поэтому Ваш случай не подпадает под условия закона 161-ФЗ о возмещении ущерба.
Ок, в этом я особо и не сомневался.
В этот момент на сайте яндекс. деньги происходит что-то невообразимое. то пропадает баланс, то предлагает мне продолжить регистрацию кошелька… видимо ресетили там мой аккаунт… решил пока не трогать, наверное что-то делают.
Но мне все еще нужен номер транзакции, чтобы дальше выяснить — что случилось с деньгами. Звоню опять… попадаю на первого специалиста… описываю ситуацию… перекидывают на старшего… уже быстрее подходит… опять описываю ситуацию. Прошу номер транзакции из деталей платежа — не дают, с правилами сервиса не спорю.
Случается чудо… есть возможность восстановить платежный пароль… но нужно ввести код… девушка по телефону говорит 5 цифр. уточняю всего 5 или не менее 5ти(так написано на странице). Говорит ровно 5 — это меня очень сильно сбило с толку… после нескольких попыток ввел свой очень старый пароль больше 5 цифр и… ура подошло.
Лезу в детали — нашел номер транзакции и IP адрес
IP-адрес с которого совершен платеж: 78.137.24.136 Черкассы, Украина. McLaut ISP
(Немного радуюсь, что хотя бы IP не мой собственный… было бы очень сложно кому-либо что-то доказывать.)
Звоню в paymaster.ru — выясняю, что деньги ушли на телефон — Киевстар, ничего сделать они не могут, пишите в Webmoney.Telepay.UA (подсказали куда что нажать — чего писать). Отправил, пока ответа нет.
Параллельно связываюсь через ВК с Киевстаром (на сайте ниодного email?! ). Дают мне линк на форму обратной связи(плохо я видимо её искал). Отправил, пока ответа нет.
Думаю — как провайдеру написать… контакты не нахожу. Что еще сделать не представляю… позвонить на номер Киевстара?
Меня смущает очень одно. В 06:40 я пытался ввести платежный пароль и он не подошел. Хотя вводил я его скорее всего правильно. в 07:09 злоумышленник увел мои деньги. Совпадение ли? Мне кажется эти события связаны и именно в 06:40 каким-то образом угнали мой пароль, а далее совершили платеж.
Я проверил историю посещения сайтов в хроме:
В 06640 с сайта 2domains я четко попадаю на roboxchange.com он меня переадресовывает на яндекс.деньги. Домены везде верные — это точно не фишинг.
С сертификатом проблем не выскакивало, я бы уж точно заметил.
Попинговал money.yandex.ru, проверил hosts вроде везде ок все.
Пароли сменил, прадва не понятно есть ли в этом толк, т.к. как же именно меня взломали не понятно.
Параноик во мне говорит, что это MITM в 06:40, но логически очень сомневаюсь. Какие есть идеи?
Да ничего удивительного. Был уязвим mail.yandex.ru и passport.yandex.ru.
Причем:
Вот вам пример данных, которые могли быть получены (это mail.yandex.ru)
Причем:
Представитель «Яндекса» Ася Мелкумова утверждает, что злоумышленники не могли прочесть переписку пользователей. «Как было заявлено в сообщении проекта OpenSSL, уязвимость, которой были подвержены две трети серверов в интернете, была в следующем: гипотетические злоумышленники при перехвате данных на сторонних ресурсах могли перехватить произвольные 64 кб данных — по сути это, например, кусочек текста или отрывок технической информации, но совершенно точно не полный текст переписки и не информация о логине или пароле», — рассказала она. «Не было возможности доступа к переписке в течение последних двух лет, так как мы ввели SSL в ноябре 2013 г., но еще раз подчеркиваем: мы уже провели тщательную проверку наших логов за весь период действия уязвимости», — добавила Мелкумова.
Вот вам пример данных, которые могли быть получены (это mail.yandex.ru)
Наш пастор сказал — это духовная война!
Нам очень стыдно за ужасно долгое ожидание саппорта по телефону — нас это не извиняет, но вы попали в пиковый момент, утром было много обращений :( И подскажите, пожалуйста, в личку ваш номер телефона, мы проведём работу с молодцом, который “ровно 5 цифр”.
По поводу сценария взлома — совсем не факт, что ваш пароль перехватили сегодня утром после неудачной попытки платежа. Собранные трояном пароли часто хранятся до набора критической массы, чтобы потом “хакнуть всё пачкой” или продать тому, кто будет хакать. Ваш платёжный пароль и пароль к Яндексу могли украсть давно, просто платёжный пароль сменили чуть раньше, чтобы иметь гарантированный доступ к счёту. В любом случае, с помощью уязвимости SSL, описанной в топике, украсть платёжный пароль невозможно.
Мы очень рекомендуем всем нашим пользователям переходить на SMS-пароли для надёжной защиты денег, для новых кошельков платёжного пароля уже не существует в принципе
По поводу сценария взлома — совсем не факт, что ваш пароль перехватили сегодня утром после неудачной попытки платежа. Собранные трояном пароли часто хранятся до набора критической массы, чтобы потом “хакнуть всё пачкой” или продать тому, кто будет хакать. Ваш платёжный пароль и пароль к Яндексу могли украсть давно, просто платёжный пароль сменили чуть раньше, чтобы иметь гарантированный доступ к счёту. В любом случае, с помощью уязвимости SSL, описанной в топике, украсть платёжный пароль невозможно.
Мы очень рекомендуем всем нашим пользователям переходить на SMS-пароли для надёжной защиты денег, для новых кошельков платёжного пароля уже не существует в принципе
К сожалению, вы промахнулись с ответом. p4s8x
«для новых кошельков платёжного пароля уже не существует в принципе»
У меня есть почтовый ящик на яндексе, к которому привязан телефонный номер.
Пару месяцев назад включил на нем кошелек Яндекс.Деньги — при включении никакого платежного пароля не вводил — не спрашивали. Зато потом при первой же попытке что-либо сделать затребовали платежный пароль.
Хорошо, думаю, сейчас восстановлю платежный пароль с помощью телефона, а вот — нет! «Восстановление платежного пароля недоступно, т.к. телефонный номер привязан меньше чем два дня назад.»
У меня есть почтовый ящик на яндексе, к которому привязан телефонный номер.
Пару месяцев назад включил на нем кошелек Яндекс.Деньги — при включении никакого платежного пароля не вводил — не спрашивали. Зато потом при первой же попытке что-либо сделать затребовали платежный пароль.
Хорошо, думаю, сейчас восстановлю платежный пароль с помощью телефона, а вот — нет! «Восстановление платежного пароля недоступно, т.к. телефонный номер привязан меньше чем два дня назад.»
Спасибо за ответ.
Ожидание не так страшно, как многократное пересказывание своей истории, номеров счетов и других данных сотрудникам техподдержки на каждом уровне :( Очень хотелось бы, чтобы тех поддержка могла как-то фиксировать информацию от уровня к уровню и идентифицировать того же абонента по номеру.
Про 5 цифр, не исключаю, что мы просто не поняли друг друга с сотрудником техподдержки, хотя конечно эти 5 попыток — фактически последняя надежда не усугубить все.
По сценарию взлома — если бы можно было отследить историю — дату\время изменения платежного пароля, возможно стало бы понятнее, когда… что-то произошло. До этого платежный пароль вводился в системе только 8 дней назад — деньги можно было давно увести.
Очень странное совпадение… моя попытка оплатить и увод денег через 20 минут.
Почему вообще они смогли сделать платеж? Я же ввел несколько раз пароль неправильно? Кажется — аккаунт должно было заблокировать.
Еще странность, что злоумышленник действует под айпишником обычной домашней сети.
После восстановления пароля — первым делом перешел на SMS-пароли.
Сейчас задумался об идентификации аккаунта.
Ожидание не так страшно, как многократное пересказывание своей истории, номеров счетов и других данных сотрудникам техподдержки на каждом уровне :( Очень хотелось бы, чтобы тех поддержка могла как-то фиксировать информацию от уровня к уровню и идентифицировать того же абонента по номеру.
Про 5 цифр, не исключаю, что мы просто не поняли друг друга с сотрудником техподдержки, хотя конечно эти 5 попыток — фактически последняя надежда не усугубить все.
По сценарию взлома — если бы можно было отследить историю — дату\время изменения платежного пароля, возможно стало бы понятнее, когда… что-то произошло. До этого платежный пароль вводился в системе только 8 дней назад — деньги можно было давно увести.
Очень странное совпадение… моя попытка оплатить и увод денег через 20 минут.
Почему вообще они смогли сделать платеж? Я же ввел несколько раз пароль неправильно? Кажется — аккаунт должно было заблокировать.
Еще странность, что злоумышленник действует под айпишником обычной домашней сети.
После восстановления пароля — первым делом перешел на SMS-пароли.
Сейчас задумался об идентификации аккаунта.
Очень странное совпадение… моя попытка оплатить и увод денег через 20 минут.
Почему вообще они смогли сделать платеж? Я же ввел несколько раз пароль неправильно? Кажется — аккаунт должно было заблокировать.
В этом месте правда странно. Давайте мы всё-таки посмотрим подробно изнутри, что происходило — нам нужен для этого номер счёта. Или, если вы в саппорт письменно обращались, номер обращения.
Еще странность, что злоумышленник действует под айпишником обычной домашней сети.Ничего странного — на компьютере домашнего пользователя трой с функцией прокси.
Эм… А с чем связано большое число обращений? Реальные факты угона аккаунтов или все кинулись сообщать об уязвимости?
НЛО прилетело и опубликовало эту надпись здесь
Разве у ЯД нет sms-подтверждения платежа? Только паролем?
Есть, но многие по старинке пользуются паролями. Ибо заводили акки когда еще не было такой возможности. А поменять наверно лень как обычно)
Смс-подтверждение(одноразовые пароли) это первое, что я включил, как удалось восстановить платежный пароль.
Наверное также стоит верифицировать аккаунт, чтобы не доказывать если что, что ты не верблюд.
Основная цель моего сообщения — для таких как я сам — показать, что вот денежки раз и «тютю заграницу» и никто Вам уже точно не поможет.
Яндекс неоднократно предлагал привязать телефон, но увы… было видимо лень(
Сумму денег там украли несерьезную, будем считать повезло.
Наверное также стоит верифицировать аккаунт, чтобы не доказывать если что, что ты не верблюд.
Основная цель моего сообщения — для таких как я сам — показать, что вот денежки раз и «тютю заграницу» и никто Вам уже точно не поможет.
Яндекс неоднократно предлагал привязать телефон, но увы… было видимо лень(
Сумму денег там украли несерьезную, будем считать повезло.
Конечно, есть. Все, кто заботится о своих деньгах, уже включили себе такой режим авторизации платежей.
Вот тут от нас (Яндекс.Денег) комментарий.
Картинка к посту абсолютно гениальная!
Кто её автор?
Кто её автор?
Заботу яндекс-боту! Яндекс-бот до сих пор не умеет TLS 1.2 (и не индексирует сайты с отключёнными устаревшими TLS/SSL), не умеет SNI, а среди алгоритмов шифрования поддерживает лишь допотопные RC4 (128-бит) и 3DES (112 бит). И в целом не гарантирует аутентичность данных из-за неработающего secure renegotiation.
www.ssllabs.com/ssltest/viewClient.html?name=YandexBot&version=3.0
www.ssllabs.com/ssltest/viewClient.html?name=YandexBot&version=3.0
JFYI: Или 3DES или RC4 оставляют все в качестве fallback'а для IE старых версий. Насколько я знаю — работа над поддержкой SNI и TLS 1.2 на заключительном этапе и скорее всего выкатится до того как ощутимая часть Рунета полностью перейдет на HTTPS.
оставляют всеСогласно опросу на нашем сайте, 100% людей пользуются интернетом? Вообще-то отключение RC4 уже давно вошло в практику.
IE старых версийПоясню. Не просто старых, а очень-очень старых и неподдерживаемых Microsoft. Это IE6-8, установленные на XP (именно только на XP). IE7 на висте уже поддерживает AES с Forward Secrecy. Шифры 3DES и RC4 неоднократно компрометировались. А поддерживать браузеры без secure renegotiation — всё равно, что ставить бумажную дверь рядом со стальной «для удобства». Можете посчитать, в каком году застрял яндекс-бот.
RC4 давно отключен на критичных сервисах, т.к. он небезопасен.
Пожалуйста, пришлите ссылки на аналогичные публикации о 3DES.
В идеальном мире мы могли бы отключить все протоколы без PFS, но безопасность, как известно, это в том числе и доступность — если тот процент пользователей, который до сих пор использует IE7/8 и WinXP не сможет читать свою почту — такая безопасность им не понравится.
www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP
Кроме того, вы надеюсь понимаете, что для адекватного даунгрейда шифра придется сделать на клиента активный MiTM, что несколько дороже чем пассивный анализ трафика.
Пожалуйста, пришлите ссылки на аналогичные публикации о 3DES.
В идеальном мире мы могли бы отключить все протоколы без PFS, но безопасность, как известно, это в том числе и доступность — если тот процент пользователей, который до сих пор использует IE7/8 и WinXP не сможет читать свою почту — такая безопасность им не понравится.
www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP
Кроме того, вы надеюсь понимаете, что для адекватного даунгрейда шифра придется сделать на клиента активный MiTM, что несколько дороже чем пассивный анализ трафика.
Ну тут уж выбирать надо, либо безопасность, либо «им не понравится». IE8 брошен. Официально. Но пользователи XP всё ещё могут читать почту через почтовые клиенты и с альтернативных браузеров. На этой волне у вас есть шанс вполне обоснованно продвинуть Яндекс-браузер и снизить затраты на поддержку совместимости со старыми IE.
3DES может и не настолько уязвим, как RC4, но не в этом дело. Сейчас многие сайты пишут: «наш сайт был подвержен heartbleed, но даже если у нас украли закрытый ключ, ваши данные в безопасности, поскольку PFS». Только не хватает звёздочки. Если вы хоть раз заходили на такой сайт из браузера без поддержки PFS, то вы соединились по 3DES (например), а это значит, что все перехваченные ранее данные были расшифрованы.
3DES может и не настолько уязвим, как RC4, но не в этом дело. Сейчас многие сайты пишут: «наш сайт был подвержен heartbleed, но даже если у нас украли закрытый ключ, ваши данные в безопасности, поскольку PFS». Только не хватает звёздочки. Если вы хоть раз заходили на такой сайт из браузера без поддержки PFS, то вы соединились по 3DES (например), а это значит, что все перехваченные ранее данные были расшифрованы.
Если вы хоть раз заходили на такой сайт из браузера без поддержки PFS, то вы соединились по 3DES (например), а это значит, что все перехваченные ранее данные были расшифрованы.
Если вы хоть раз заходили на такой сайт из браузера без поддержки PFS за последние 4 месяца, при этом атакующий снял дамп трафика этого захода, при этом если ключи действительно утекли то да — атакующий сможет расшифровать ту самую условно небезопасную сессию, но никак не сессии для которых использовался PFS (все остальные).
Не слишком много если?
атакующий снял дамп трафика этого заходаПроисходит регулярно в открытых wifi-сетях.
если ключи действительно утеклиHeartbleed. Бинго!
но никак не сессии для которых использовался PFSЗачем злоумышленнику все сессии? Достаточно одной, в которой был пароль интернет-банкинга или электронной почты.
заходили на такой сайт из браузера без поддержки PFSЭто единственная вещь из вышеперечисленного, которая находится в руках администратора сайта. Я не говорю, что Яндексу нужно перейти на PFS-only. В интернете должны оставаться доступными для всех: (1) поисковики, чтобы найти нормальный браузер (2) страницы, чтобы скачать нормальный браузер. Но пожалуйста, не надо заставлять разработчиков других систем, связанных с личными данными, проектировать legacy-системы в 2014 году.
В LinkedIn не обязательно менять. А еще нужно поменять свои пароли для Yahoo, AWS, GoDaddy, Box, Dropbox, GitHub, Minecraft, IFTTT, SoundCloud, Wunderlist.
Источник Mashable
Источник Mashable
Яндекс, вы двухфакторную аутентификацию когда-нибудь введете?
А еще есть такие сайты, которые хранят пароли в оригинальном виде (не знаю шифруют у себя или нет), самый известный пример liveinternet (статистика), и сайты вообще не использующие https, по этой логике, если пользователь использовал везде один и тот же пароль, он уже давно мог утечь куда-нибудь и без этой уязвимости.
Двуфакторная авторизация — наше всё. Допустим, украли мой пароль от google/dropbox/facebook/microsoft/twitter, и что? Без подтверждения никто в мой аккаунт не попадет.
На яндексе, похоже, никакой двуфакторной авторизации нет.
На яндексе, похоже, никакой двуфакторной авторизации нет.
Я сначала сменил пароль на гугле, а потом вспомнил, что у меня там уже года два как двухфакторная аутентификация… Так что пугалка работает :)
А вот за PFS респект.
Проблема заключалась в том, что эксплуатация данной уязвимости не оставляет никаких следов в логах веб-сервера.
А на вашем блоге написано следующее
Поэтому мы тщательно проверили статистику наших сервисов – никаких массовых обращений к нашим серверам, которые могли бы свидетельствовать об атаке, не было
где правда?
Это разные вещи, они оба — правда. В логах веб-сервера действительно не остается следов атаки. Однако, если бы массовый взлом учетных записей имел место, наши механизмы контроля подозрительной активности в рамках пользовательских сессий могли бы его обнаружить. Именно это мы и тщательно проверяли, о чем сказано в блоге. Допускаю, что из формулировки это может быть не сразу понятно. Но так иногда бывает, когда с технического языка переводишь на человеческий :).
imgur.com/a/nPZBb — история «взлома» яндекс почты подруги. Мб кому будет интересно.
Угнали около 10 акков. + удалили папку «аккаунты», в которой хранились письма со всех сервисов (иногда с паролями). Причем последнее возможно было наоборот добрым поступком.
Замазаны домашние ip.
Угнали около 10 акков. + удалили папку «аккаунты», в которой хранились письма со всех сервисов (иногда с паролями). Причем последнее возможно было наоборот добрым поступком.
Замазаны домашние ip.
NSA used Heartbleed to spy for 2 years, report says
www.cbc.ca/news/technology/nsa-used-heartbleed-to-spy-for-2-years-report-says-1.2606960
www.cbc.ca/news/technology/nsa-used-heartbleed-to-spy-for-2-years-report-says-1.2606960
Не сообщать пользователям о необходимости смены паролей — неправильная мера. Несмотря на «особо активное» отслеживание, я знаю ещё один случай, когда у человека увели 7.5к с Яндекс.Денег. И возмещения он, конечно, не получил.
bronepoezzd.livejournal.com/280251.html
bronepoezzd.livejournal.com/280251.html
Только случаи краж из Яндекс.Денег не связаны с внутренними уязвимостями, а до сих пор происходили по недосмотру владельцев. Heartbleed мог затронуть наших пользователей только в месте общей с Яндексом авторизации — но доступ к учётной записи на Яндексе не позволяет украсть деньги, т.к. все платёжные операции подтверждаются другими паролями, при их передаче уязвимые модули не использовались вовсе. У пользователя, на которого вы ссылаетесь, украли не только доступ к Яндексу, но и платёжный пароль.
Другой вопрос, конечно, насколько настойчивыми и ультимативными нужно быть сервисам, вроде Яндекс.Денег, предупреждая о риске и давая пользователям выбор рисковать. Но по крайней мере все новые счета с февраля 2014 открываются только с привязкой телефона и одноразовыми SMS-подтверждениями операций.
Зря, конечно, Яндекс принудительно не сбросил пароли всем, кто логинился во время массовой эксплуатации уязвимости.
Мой пароль от яндекс-почты тоже украли. Специально не стал менять его, чтобы проверить, своровали его или нет. И вот сегодня обнаружил в ящике несколько писем со ссылкой для сброса платежного пароля Яндекс.Денег. В журнале ящика последний доступ с польского IP.
Не знаю, какие такие «алгоритмы обнаружения подозрительной активности» у вас действуют, но когда неизвестно кто с IP другой страны попытался сбросить платежный пароль, Яндекс даже не удосужился прислать СМС на привязанный номер телефона.
Гугл, например, блокирует попытки входа с IP другого региона и сообщает об этом по СМС.
Мой пароль от яндекс-почты тоже украли. Специально не стал менять его, чтобы проверить, своровали его или нет. И вот сегодня обнаружил в ящике несколько писем со ссылкой для сброса платежного пароля Яндекс.Денег. В журнале ящика последний доступ с польского IP.
Не знаю, какие такие «алгоритмы обнаружения подозрительной активности» у вас действуют, но когда неизвестно кто с IP другой страны попытался сбросить платежный пароль, Яндекс даже не удосужился прислать СМС на привязанный номер телефона.
Гугл, например, блокирует попытки входа с IP другого региона и сообщает об этом по СМС.
У меня пару месяцев назад тоже угнали почту на яндексе. Пришло смс, мол введите этот код подтверждения для смены номера телефона. В итоге доступ я, имея телефон, восстановил минут за 5. За одно в «процессе смены телефона» остался номер злоумышленника. Обдумываю коварный план мести. В принципе ущерб минимален, угнали только стим аккаунт, который восстанавливали почти неделю, но не приятно.
Пароль, на самом деле, был довольно простой и не менялся давно.
Пароль, на самом деле, был довольно простой и не менялся давно.
Я так понимаю пароль может быть взломан с помощью этой уязвимости, только если на моей машине есть сниффер или иной вирус, который мониторит траффик? Либо на одном из серверов, через который идет мой ssl траффик внедрен сниффер?
Также я должен был в момент эксплуатации уязвимости пытаться авторизоваться на одном из серверов яндекса?
Также я должен был в момент эксплуатации уязвимости пытаться авторизоваться на одном из серверов яндекса?
Скажите, а почему у вас на сайте yandex.ru/security теперь не показываются ссылки на смену паролей в разных социальных сетях? Было очень удобно…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Время менять пароли