На днях вскрылся жуткий баг в библиотеке OpenSSL, реализующей защищённые протоколы.
Баг позволяет получать доступ к памяти сервера, включая чтение и расшифровку сертификатов, логины и пароли.
Оказывается, бага, которую заметили только сейчас, присутствовала уже года примерно два и успела распространиться по интернету.
Сейчас админы серверов срочно патчатся, но рекомендуется сменить пароли на всех сайтах, доступ к которым осущестляется через HTTPS, POP/IMAP/SMTP с применением SSL/TLS и т.п.
Возможно, Google был также уязвим. Также Dropbox и т.п.
Подробности: http://heartbleed.com , там же указаны версии OpenSSL с багом.
Вкратце, уязвима библиотека OpenSSL с версии 1.0.1 по 1.0.1f включительно.
В остальных версиях уязвимости нет.
Heartbleed Bug
08.04.2014 10:49
В OpenSSL обнаружена критическая уязвимость, которая может привести к утечке закрытых ключей
В OpenSSL выявлена одна из самых серьёзных уязвимостей (CVE-2014-0160) в истории проекта, затрагивающая огромное число сайтов, серверных систем и клиентских приложений, использующих OpenSSL 1.0.1 для организации обмена данными через защищённое соединение. Суть проблемы проявляется в возможности доступа к 64Кб памяти клиентского или серверного процесса с которым установлено шифрованное соединение.
Практическая опасность уязвимости связана с тем, что в подверженной утечке области памяти могут размещаться закрытые ключи или пароли доступа, которые потенциально могут быть извлечены удалённым злоумышленником. При удачном проведении атаки злоумышленник может получить содержимое ключа, используемого для организации шифрованного доступа к серверу, и организовать перехват на транзитном узле защищённого трафика. Также не исключена утечка паролей, идентификаторов сессий и других закрытых данных клиентских приложений при попытке их соединения с подконтрольными злоумышленникам серверными системами.
Причиной проблемы является отсутствие проверки выхода за допустимые границы в коде реализации TLS-расширения heartbeat (RFC 6520), что позволяет инициировать отправку удалённой стороне до 64Кб данных из области за границей текущего буфера. При этом возможна отправка произвольных 64Кб данных, а не только примыкающих к границе буфера (путем повторения запросов атакующий может шаг за шагом прочитать всё содержимое памяти). По некоторым оценкам проблема охватывает до половины поддерживающих защищённое соединение серверных систем в Сети, включая собранные с OpenSSL 1.0.1 web-серверы (Apache httpd, nginx), почтовые серверы, XMPP-серверы, VPN-системы, шлюзы и скрытые сервисы анонимной сети Tor.
Связанная с атакой активность не проявляется в серверных логах, что затрудняет выявление фактов эксплуатации уязвимости. Возможность создания рабочего эксплоита для извлечения ключей безопасности без оставления следов в логе подтверждена исследователями из компаний Google и Codenomicon, выявивших уязвимость. В связи с тем, что проблема присутствует в коде OpenSSL уже более двух лет и, при этом, невозможно отследить по логу уже совершённые атаки, помимо установки обновления пользователям рекомендуется поменять ключи доступа и пароли. Для выявления возможного применения атаки в диком виде продвигается инициатива по развёртыванию сети подставных honeypot-серверов, фиксирующих попытки эксплуатации уязвимости.
Проблема проявляется только в актуальной стабильной ветке OpenSSL 1.0.1 и тестовых выпусках 1.0.2, прошлые стабильные ветки 0.9.x и 1.0.0x уязвимости не подвержены. Системы, использующие выпуски OpenSSL 1.0.1[abcdef], требуют срочного обновления. Уязвимость устранена в выпуске OpenSSL 1.0.1g. Обновления пакетов уже выпущены для RHEL 6, CentOS 6, Fedora 19/21, FreeBSD 8.4+, Ubuntu 12.04-13.10, Debian wheezy/squeeze. Проблема пока не исправлена в OpenSUSE 12.2+, NetBSD 5.0+ и OpenBSD 5.3+. SUSE Linux Enterprise Server и Debian Squeeze проблеме не подвержены. В качестве запасного варианта отмечается возможность пересборки OpenSSL с опцией "-DOPENSSL_NO_HEARTBEATS", отключающей TLS-расширение heartbeat. Для проверки серверных систем на предмет наличия уязвимости подготовлены специальные online-сервисы.
http://www.opennet.ru/opennews/art.shtml?num=39518
В OpenSSL обнаружена критическая уязвимость, которая может привести к утечке закрытых ключей
В OpenSSL выявлена одна из самых серьёзных уязвимостей (CVE-2014-0160) в истории проекта, затрагивающая огромное число сайтов, серверных систем и клиентских приложений, использующих OpenSSL 1.0.1 для организации обмена данными через защищённое соединение. Суть проблемы проявляется в возможности доступа к 64Кб памяти клиентского или серверного процесса с которым установлено шифрованное соединение.
Практическая опасность уязвимости связана с тем, что в подверженной утечке области памяти могут размещаться закрытые ключи или пароли доступа, которые потенциально могут быть извлечены удалённым злоумышленником. При удачном проведении атаки злоумышленник может получить содержимое ключа, используемого для организации шифрованного доступа к серверу, и организовать перехват на транзитном узле защищённого трафика. Также не исключена утечка паролей, идентификаторов сессий и других закрытых данных клиентских приложений при попытке их соединения с подконтрольными злоумышленникам серверными системами.
Причиной проблемы является отсутствие проверки выхода за допустимые границы в коде реализации TLS-расширения heartbeat (RFC 6520), что позволяет инициировать отправку удалённой стороне до 64Кб данных из области за границей текущего буфера. При этом возможна отправка произвольных 64Кб данных, а не только примыкающих к границе буфера (путем повторения запросов атакующий может шаг за шагом прочитать всё содержимое памяти). По некоторым оценкам проблема охватывает до половины поддерживающих защищённое соединение серверных систем в Сети, включая собранные с OpenSSL 1.0.1 web-серверы (Apache httpd, nginx), почтовые серверы, XMPP-серверы, VPN-системы, шлюзы и скрытые сервисы анонимной сети Tor.
Связанная с атакой активность не проявляется в серверных логах, что затрудняет выявление фактов эксплуатации уязвимости. Возможность создания рабочего эксплоита для извлечения ключей безопасности без оставления следов в логе подтверждена исследователями из компаний Google и Codenomicon, выявивших уязвимость. В связи с тем, что проблема присутствует в коде OpenSSL уже более двух лет и, при этом, невозможно отследить по логу уже совершённые атаки, помимо установки обновления пользователям рекомендуется поменять ключи доступа и пароли. Для выявления возможного применения атаки в диком виде продвигается инициатива по развёртыванию сети подставных honeypot-серверов, фиксирующих попытки эксплуатации уязвимости.
Проблема проявляется только в актуальной стабильной ветке OpenSSL 1.0.1 и тестовых выпусках 1.0.2, прошлые стабильные ветки 0.9.x и 1.0.0x уязвимости не подвержены. Системы, использующие выпуски OpenSSL 1.0.1[abcdef], требуют срочного обновления. Уязвимость устранена в выпуске OpenSSL 1.0.1g. Обновления пакетов уже выпущены для RHEL 6, CentOS 6, Fedora 19/21, FreeBSD 8.4+, Ubuntu 12.04-13.10, Debian wheezy/squeeze. Проблема пока не исправлена в OpenSUSE 12.2+, NetBSD 5.0+ и OpenBSD 5.3+. SUSE Linux Enterprise Server и Debian Squeeze проблеме не подвержены. В качестве запасного варианта отмечается возможность пересборки OpenSSL с опцией "-DOPENSSL_NO_HEARTBEATS", отключающей TLS-расширение heartbeat. Для проверки серверных систем на предмет наличия уязвимости подготовлены специальные online-сервисы.
http://www.opennet.ru/opennews/art.shtml?num=39518
Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноября прошлого года
10.04.2014 13:03
Стали появляться свидетельства возможного применения Heartbeat-уязвимости в OpenSSL (CVE-2014-0160) для совершения вредоносных действий за несколько месяцев до выявления проблемы сотрудниками компаний Google и Codenomicon. Следы одной из таких атак зафиксированы компанией MediaMonks в журналах аудита, датированных ноябрём прошлого года. Сохранённые в журналах пакеты с нескольких серверов, подозреваемых во вредоносной активности, совпали по своему характеру с пакетами, применяемыми при эксплуатации Heartbeat-уязвимости.
По мнению Брюса Шнайера, известного эксперта в области компьютерной безопасности, Heartbeat-уязвимость в OpenSSL следует причислить к категории катастрофических уязвимостей, уровень опасности которой составляет 11 баллов, если рассматривать существующую 10-бальную шкалу степеней опасности с учётом того, что OpenSSL является самой распространённой криптографической библиотекой в Сети.
Благодаря широкому освещению проблемы за два дня с момента её обнародования около 1/3 всех серверов уже применили обновление с устранением уязвимости. Тем не менее, по предварительным данным в Сети ещё остаются уязвимыми около 600 тысяч серверов. Но проблема далека от своего решения - непонятно, что делать со встраиваемыми и мобильными продуктами, подверженными уязвимости, но не предусматривающими возможность автоматического обновления прошивки.
Кроме того, начинается волна атак на клиентские приложения, использующие OpenSSL. Например, вслед за появлением эксплоитов для серверных систем уже доступен прототип эксплоита с реализацией фиктивного HTTPS-сервера, при обращении к которому осуществляется атака на клиента. Эксплоит успешно протестирован для извлечения данных из памяти таких приложений, как wget 1.15, curl 7.36.0, links 2.8, git 1.9.1, MariaDB 5.5.36 (клиент), nginx 1.4.7 (в режиме прокси). Например, можно извлечь параметры прошлых запросов, в том числе содержащих пароли доступа.
В условиях возможности незаметного проведения атаки, без оставления следов в логе, также предстоит длительный процесс смены SSL-сертификатов, ключей шифрования и обычных паролей, отсутствие утечки которых невозможно гарантировать. Потенциально любой пароль и сертификат мог попасть в руки злоумышленников, и непонятно, когда и где подобные утечки могут проявиться. Из крупных сайтов, которые потенциально могли подвергнуться атаке отмечаются Twitter, GitHub, Yahoo, Tumblr, Steam, DropBox, а также многие банки и финансовые сервисы.
Шнайер считает близкой к единице вероятность того, что различные спецслужбы уже успели воспользоваться уязвимостью для массового извлечения приватных ключей. Другой вопрос, случайно или нет подобная уязвимость появилась в OpenSSL. Даже если проблема была внесена случайно, за два года присутствия в кодовой базе заинтересованные лица вполне могли её обнаружить и молча использовать.
Дополнение: администраторам у которых сохранились дампы трафика за время до публикации информации об уязвимости, предлагается проанализировать наличие в них сигнатур "18 03 02 00 03 01 40 00" или "18 03 01 00 03 01 40 00" (вместо "40 00" в конце может быть меньшее число), свидетельствующих о применении эксплоита. Особое внимание рекомендуется уделить на подсеть 193.104.110.* с которой в ноябре была выявлена подобная активность, а также другие подсети с которых наблюдается активность ботов.
http://www.opennet.ru/opennews/art.shtml?num=39544
10.04.2014 13:03
Стали появляться свидетельства возможного применения Heartbeat-уязвимости в OpenSSL (CVE-2014-0160) для совершения вредоносных действий за несколько месяцев до выявления проблемы сотрудниками компаний Google и Codenomicon. Следы одной из таких атак зафиксированы компанией MediaMonks в журналах аудита, датированных ноябрём прошлого года. Сохранённые в журналах пакеты с нескольких серверов, подозреваемых во вредоносной активности, совпали по своему характеру с пакетами, применяемыми при эксплуатации Heartbeat-уязвимости.
По мнению Брюса Шнайера, известного эксперта в области компьютерной безопасности, Heartbeat-уязвимость в OpenSSL следует причислить к категории катастрофических уязвимостей, уровень опасности которой составляет 11 баллов, если рассматривать существующую 10-бальную шкалу степеней опасности с учётом того, что OpenSSL является самой распространённой криптографической библиотекой в Сети.
Благодаря широкому освещению проблемы за два дня с момента её обнародования около 1/3 всех серверов уже применили обновление с устранением уязвимости. Тем не менее, по предварительным данным в Сети ещё остаются уязвимыми около 600 тысяч серверов. Но проблема далека от своего решения - непонятно, что делать со встраиваемыми и мобильными продуктами, подверженными уязвимости, но не предусматривающими возможность автоматического обновления прошивки.
Кроме того, начинается волна атак на клиентские приложения, использующие OpenSSL. Например, вслед за появлением эксплоитов для серверных систем уже доступен прототип эксплоита с реализацией фиктивного HTTPS-сервера, при обращении к которому осуществляется атака на клиента. Эксплоит успешно протестирован для извлечения данных из памяти таких приложений, как wget 1.15, curl 7.36.0, links 2.8, git 1.9.1, MariaDB 5.5.36 (клиент), nginx 1.4.7 (в режиме прокси). Например, можно извлечь параметры прошлых запросов, в том числе содержащих пароли доступа.
В условиях возможности незаметного проведения атаки, без оставления следов в логе, также предстоит длительный процесс смены SSL-сертификатов, ключей шифрования и обычных паролей, отсутствие утечки которых невозможно гарантировать. Потенциально любой пароль и сертификат мог попасть в руки злоумышленников, и непонятно, когда и где подобные утечки могут проявиться. Из крупных сайтов, которые потенциально могли подвергнуться атаке отмечаются Twitter, GitHub, Yahoo, Tumblr, Steam, DropBox, а также многие банки и финансовые сервисы.
Шнайер считает близкой к единице вероятность того, что различные спецслужбы уже успели воспользоваться уязвимостью для массового извлечения приватных ключей. Другой вопрос, случайно или нет подобная уязвимость появилась в OpenSSL. Даже если проблема была внесена случайно, за два года присутствия в кодовой базе заинтересованные лица вполне могли её обнаружить и молча использовать.
Дополнение: администраторам у которых сохранились дампы трафика за время до публикации информации об уязвимости, предлагается проанализировать наличие в них сигнатур "18 03 02 00 03 01 40 00" или "18 03 01 00 03 01 40 00" (вместо "40 00" в конце может быть меньшее число), свидетельствующих о применении эксплоита. Особое внимание рекомендуется уделить на подсеть 193.104.110.* с которой в ноябре была выявлена подобная активность, а также другие подсети с которых наблюдается активность ботов.
http://www.opennet.ru/opennews/art.shtml?num=39544
Типа, если кто не понял - даже если ты не админ сервера, а сидишь просто на клиентском луниксе, срочно пропатчись.
-
Axl
- Благодарил (а): 1 раз
Пошёл посмотреть, а там:
Да, но через сколько "современных" OpenSSL все эти годы гонялись мои пароли. Беда-огорчение
Код: Выделить всё
Уже установлена самая новая версия openssl
Description: Ubuntu 11.10
OpenSSL 1.0.0e 6 Sep 2011Да, но через сколько "современных" OpenSSL все эти годы гонялись мои пароли. Беда-огорчение
OpenSSL что это такое ? И как выглядит кусок кода на языке С (видимо) в котором допущена ошибка ?
Патч для OpenSSL был выпущен Ником Салливаном (Nick Sullivan) — системным программистом компании CloudFlare. Ему помогали программист Google Адам Лэнгли (Adam Langley) и советник по безопасности The OpenSSL Project Бодо Мюллер (Bodo Moeller).
Наиболее важная часть исправлений коснулась добавления проверки длины полезной нагрузки.
/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->rrec.length)
return 0; /* silently discard */
из комментов:
unk32 маргинлефт • 6 дней назад
Тут даже приведенный фикс написан в венгерской нотации: "если сумма трех чего-то больше чем троллейбус то троллейбус никуда не едет". И потом проверяющий должен найти к чему относятся "1 + 2 + 16" и прочитать наоборот: "если длина записи меньше чем что-то то ничего не делать".
http://www.computerra.ru/97739/openssl-vulnerability/
Наиболее важная часть исправлений коснулась добавления проверки длины полезной нагрузки.
/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->rrec.length)
return 0; /* silently discard */
из комментов:
unk32 маргинлефт • 6 дней назад
Тут даже приведенный фикс написан в венгерской нотации: "если сумма трех чего-то больше чем троллейбус то троллейбус никуда не едет". И потом проверяющий должен найти к чему относятся "1 + 2 + 16" и прочитать наоборот: "если длина записи меньше чем что-то то ничего не делать".
http://www.computerra.ru/97739/openssl-vulnerability/
ещё (исчо) из комментов:
unk32 • 7 дней назад
Ну вот, а сколько было песен несколько назад о неуязвимости никсов вообще и опенсорса в частности, в котором не может быть уязвимостей в принципе потому что вот такая огромная армия проверяющих.
Теперь мы имеем Андроид и уже вторую критическую дыру в шифровании (известную).
Любой опытный программист, ходивший по граблям, на своей шкуре знает или догадывается что не бывает кода без скрытых или отложенных багов. За исключением разве что "Hello World". Пока не найдут критическую дыру в функции print как минимум (стек ею переполнить или управляющие символы в строку зашить ...).
________________________________________
Андрей Васильков Компьютерра unk32 • 6 дней назад
Открытый исходный код - необходимое, но не достаточное условие. Сам по себе он не защищает программу от наличия ошибок, включая критические уязвимости. Часто случается наоборот - сторонники Open Source надеются друг на друга и на возможность проверки "тысячами специалистов". Вот только вы пробовали проверить листинг своей же программы через пару лет? Даже с комментариями и внятным оформлением это сложная задача (многое забылось, появились новые приёмы). Анализировать чужой код - это отдельный круг ада. Сложнее заметить именно те ошибки, которые очевидны. Например, в TrueCrypt версии 5.1 некорректная работа с драйвером диска приводила к записи данных в открытом виде при использовании hibernate. http://is.gd/JCJjY6
________________________________________
Айрат Ягудин unk32 • 6 дней назад
Периодически всплывают сообщения о таких "багах", которые на самом деле кого нужно "фичи". Всегда есть любопытные организации, которым по силам создать сотни "багов" в важных библиотеках.
________________________________________
unk32 • 7 дней назад
Ну вот, а сколько было песен несколько назад о неуязвимости никсов вообще и опенсорса в частности, в котором не может быть уязвимостей в принципе потому что вот такая огромная армия проверяющих.
Теперь мы имеем Андроид и уже вторую критическую дыру в шифровании (известную).
Любой опытный программист, ходивший по граблям, на своей шкуре знает или догадывается что не бывает кода без скрытых или отложенных багов. За исключением разве что "Hello World". Пока не найдут критическую дыру в функции print как минимум (стек ею переполнить или управляющие символы в строку зашить ...).
________________________________________
Андрей Васильков Компьютерра unk32 • 6 дней назад
Открытый исходный код - необходимое, но не достаточное условие. Сам по себе он не защищает программу от наличия ошибок, включая критические уязвимости. Часто случается наоборот - сторонники Open Source надеются друг на друга и на возможность проверки "тысячами специалистов". Вот только вы пробовали проверить листинг своей же программы через пару лет? Даже с комментариями и внятным оформлением это сложная задача (многое забылось, появились новые приёмы). Анализировать чужой код - это отдельный круг ада. Сложнее заметить именно те ошибки, которые очевидны. Например, в TrueCrypt версии 5.1 некорректная работа с драйвером диска приводила к записи данных в открытом виде при использовании hibernate. http://is.gd/JCJjY6
________________________________________
Айрат Ягудин unk32 • 6 дней назад
Периодически всплывают сообщения о таких "багах", которые на самом деле кого нужно "фичи". Всегда есть любопытные организации, которым по силам создать сотни "багов" в важных библиотеках.
________________________________________
вот и ещё одна статья из журнала "Компутерра". для тех, кому лень проходить по ссылкам, делать репост статьи я не буду, сама статья находится здесь:
О Heartbleed человеческим языком: пять самых важных вопросов
http://www.computerra.ru/98046/heartbleed-simple/
Как работает баг:
Обращаясь к серверу, клиент просит вернуть ему ответ определённой длины. Но из-за ошибки сервер не замечает, что, хоть сам запрос состоит всего из трёх символов, вернуть его просят значительно больше...
О Heartbleed человеческим языком: пять самых важных вопросов
http://www.computerra.ru/98046/heartbleed-simple/
Как работает баг:
Обращаясь к серверу, клиент просит вернуть ему ответ определённой длины. Но из-за ошибки сервер не замечает, что, хоть сам запрос состоит всего из трёх символов, вернуть его просят значительно больше...
Данные около 70 000 карт были скомпрометированы на платежном шлюзе РЖД
Данные карточек, которые использовались для покупки билетов на сайте РЖД были скомпрометированы по той простой причине, что уязвимость Heartbleed была закрыта на нем только спустя неделю (15.04.2013). Все это время неизвестные злоумышленники могли безнаказанно воровать данные с сайта, пользуясь нашумевшей уязвимостью.
Для привлечения внимания к проблеме и чтобы мотивировать пользователей перевыпустить свои карты неизвестными хакерами был создан сайт sos-rzd.com, на котором выложен дамп платежных данных за 14 апреля. Общее количество записей 10532, что позволяет говорить о примерно 70 тысячах карточках скомпрометированных за неделю с момента уязвимости. Сами авторы называют почему то цифру 200 тысяч.
В этой ситуации выглядит странной реакция РЖД и самого банка ВТБ24. Они полностью отрицают уязвимость и обвиняют сайт в фишинговой деятельности
Вот комментарий от пресс-службы ВТБ24 с сайта РБК
«Никаких атак на платежный шлюз, через который проходит покупка билетов на сайте http://www.rzd.ru, не было. Шлюз защищен последней версией стандарта безопасности данных платежных карт. Всем клиентам, совершающим транзакции через него, гарантируется абсолютная безопасность платежей», — заявил РБК представитель пресс-службы кредитной организации. Источник РБК в банке уверен: сайт создан для того, чтобы его посетители оставляли там данные своих карт.
Однако это заявление не соответствует действительности. Уязвимость на сайт РЖД была, об этом писал автор в топике Чем грозит Heartbleed простому пользователю?, он подтверждает что уязвимость им была обнаружена именно на шлюзе ВТБ24 и именно на сайте РЖД.
Еще один комментарий от пресс-службы
Также подлинность данных косвенно подтверждает Виктор Лысенко, СЕО Рокетбанка, пообещав перевыпустить все карточки из списка.
Не сходится также и с фишинговой деятельностью. Сайт предлагает проверить только 10 из 16 цифр номера карты. А также для особо недоверчивых дает возможность скачать базу в виде файла и проверить локально.
Более того, складывается впечатление что против сайта запущена кампания в СМИ. Такие крупные сайты как РБК, SecurityLab, JustMedia и другие, не разобравшись в вопросе, занимают позицию ВТБ24 и называют сайт фишинговым.
Печально, что крупные российские компании вместо того, чтобы признать проблему и совместно принять меры для ее решения, делают вид, что ничего не произошло, параллельно, пытаясь заткнуть рот неравнодушным ИТ-специалистам.
http://habrahabr.ru/post/219691/
Данные карточек, которые использовались для покупки билетов на сайте РЖД были скомпрометированы по той простой причине, что уязвимость Heartbleed была закрыта на нем только спустя неделю (15.04.2013). Все это время неизвестные злоумышленники могли безнаказанно воровать данные с сайта, пользуясь нашумевшей уязвимостью.
Для привлечения внимания к проблеме и чтобы мотивировать пользователей перевыпустить свои карты неизвестными хакерами был создан сайт sos-rzd.com, на котором выложен дамп платежных данных за 14 апреля. Общее количество записей 10532, что позволяет говорить о примерно 70 тысячах карточках скомпрометированных за неделю с момента уязвимости. Сами авторы называют почему то цифру 200 тысяч.
В этой ситуации выглядит странной реакция РЖД и самого банка ВТБ24. Они полностью отрицают уязвимость и обвиняют сайт в фишинговой деятельности
Вот комментарий от пресс-службы ВТБ24 с сайта РБК
«Никаких атак на платежный шлюз, через который проходит покупка билетов на сайте http://www.rzd.ru, не было. Шлюз защищен последней версией стандарта безопасности данных платежных карт. Всем клиентам, совершающим транзакции через него, гарантируется абсолютная безопасность платежей», — заявил РБК представитель пресс-службы кредитной организации. Источник РБК в банке уверен: сайт создан для того, чтобы его посетители оставляли там данные своих карт.
Однако это заявление не соответствует действительности. Уязвимость на сайт РЖД была, об этом писал автор в топике Чем грозит Heartbleed простому пользователю?, он подтверждает что уязвимость им была обнаружена именно на шлюзе ВТБ24 и именно на сайте РЖД.
Еще один комментарий от пресс-службы
Тоже очень странное заявление. Уязвимость позволяет получить данные из памяти сервера, соответственно, если пользователь ввел неполные или некорректные данные, то они будут такими же и в дампе. Однако подлинность большинства данных подтверждают сами пользователи. Например, Алексей Копылов, один из директоров компании Flexis, подтверждает, что его данные есть в этом списке и приводит фотографию карточки + скриншот электронного билета.Если внимательно посмотреть на сайт, он уже сам по себе вызывает много вопросов: вместо фамилий используются цифры, сокращения, встречаются русские или неполные имена, чего не может быть в случае банковских карт. Очень похоже, что это просто фейк.
Также подлинность данных косвенно подтверждает Виктор Лысенко, СЕО Рокетбанка, пообещав перевыпустить все карточки из списка.
Не сходится также и с фишинговой деятельностью. Сайт предлагает проверить только 10 из 16 цифр номера карты. А также для особо недоверчивых дает возможность скачать базу в виде файла и проверить локально.
Более того, складывается впечатление что против сайта запущена кампания в СМИ. Такие крупные сайты как РБК, SecurityLab, JustMedia и другие, не разобравшись в вопросе, занимают позицию ВТБ24 и называют сайт фишинговым.
Печально, что крупные российские компании вместо того, чтобы признать проблему и совместно принять меры для ее решения, делают вид, что ничего не произошло, параллельно, пытаясь заткнуть рот неравнодушным ИТ-специалистам.
http://habrahabr.ru/post/219691/
9: BadBlock:
Карта товарища тоже там
Карта товарища тоже там
10: Desperanto:
Там щас принудительно всем перевыпускают карты, кто на РЖД покупал.
Там щас принудительно всем перевыпускают карты, кто на РЖД покупал.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей
