суббота, ноября 12, 2011
Unknown
| A+ A- |
Steam взломан
6го ноября 2011 года были взломаны официальные форумы steam, в сеть утекла база данных форума, а так же вся база данных пользователей steam, включая все личные данные.
Официальное обращение от Valve:
По неподтвержденным данным, успешная атака была проведена хакерской группировкой «fkn0wned».
Официальное обращение от Valve:
10 ноября 2011
Уважаемые пользователи Steam и Steam форумов.
В воскресенье, шестого ноября, наши форумы были взломаны. Мы начали расследовать это происшествие, и обнаружили, что вторжение затронуло не только сами форумы.
Мы выяснили, что в дополнение к форумам, взломщики также получили доступ к базе данных Steam. Эта база содержала такую информацию, как имена аккаунтов, зашифрованные (хешированные с солью) пароли, списки покупок, адреса электронной почты, физические адреса и зашифрованную информацию о кредитных картах. У нас нет причин полагать, что зашифрованные номера кредитных карт или другая личная информация попала в руки злоумышленников, или что защита номеров кредитных карт и паролей была взломана. В данный момент мы продолжаем расследование.
У нас также нет никаких данных, указывающих на то, что злоумышленники воспользовались кредитными картами. Тем не менее, вы должны внимательно следить за использованием вашей кредитной карты.
На данный момент, мы знаем всего о нескольких форумных аккаунтах, которые были похищены, но всем пользователям форумов придется поменять свои пароли при следующем входе на форум. Если вы используете ваш пароль от Steam-форума на каких-либо других аккаунтах, вы должны изменить эти пароли тоже.
Нам не известен ни один похищенный Steam аккаунт, вследствие чего мы не планируем заставлять пользователей менять пароли (так как Steam аккаунты отличаются от форумных аккаунтов). Тем не менее, вероятно имеет смысл сменить пароль, особенно если он такой же, как на вашем форумном аккаунте.
Мы откроем форумы, как только сможем.
Мне очень жаль, что это произошло, и я приношу свои извинения за причиненные неудобства.
Гейб.
По неподтвержденным данным, успешная атака была проведена хакерской группировкой «fkn0wned».
Персональные данные из ПФР попали в интернет
Файл с данными о клиентах Пенсионного фонда России (ПФР) был опубликован на сайте фонда — ФИО, ИНН, информацию о страховых и накопительных взносах можно найти через поиск «Яндекса», сообщила «Русская служба новостей» со ссылкой на одного из клиентов фонда. Сейчас доступ к файлу на сайте Пенсионного фонда закрыт, однако файл, содержащий более 1000 записей, сохранился в кэше «Яндекса».«Этот файл доступен для скачивания для любого пользователя интернет. „Яндекс“ выпускает конфиденциальные данные в поиск. Я стал проверять свои данные и случайно нашел этот файл, в котором содержатся данные о плательщиках. Заходим на сайт, и там находятся его фамилия, имя и отчество, ИНН, сумма платежа, страховой, накопительной части и еще много всего», — заявил в эфире «Русской службы новостей» радиослушатель Николай.
Появление данной информации в открытом доступе — следствие технической ошибки, сообщила «Ведомостям» представитель ПФР Марита Нагога. По ее словам, общедоступной стала информация об индивидуальных предпринимателях, имеющих задолженность по страховым взносам. Утечка носит локальный характер — в интернете появилась информация примерно о 600 должниках в нескольких районах Тверской области, подчеркивает она. Доступ к файлу был закрыт примерно через час после обнаружения ошибки, но «Яндекс» успел проиндексировать его — сегодня к 15.00 поисковик обещает закрыть доступ к этой информации, говорит Нагога. Содержащаяся в файле информация не относится к персональным данным, подчеркивает она. Файл с данными ПФР проиндексировал не только «Яндекс» — ссылки на информацию из него присутствуют также в поиске Mail.ru и Bing.
Первая работающая атака на SSL/TLS-протокол
Передаваемые по SSL-соединению данные можно расшифровать! Для этого Джулиану Риццо и Тай Дуонгу удалось использовать недоработки в самом протоколе SSL. И пусть речь пока не идет о полной дешифровке трафика, разработанная ими утилита BEAST может извлечь из зашифрованного потока то, что представляет собой наибольший интерес, — секретные кукисы с идентификатором сессии пользователя.
Всего 103 секунды потребовалось утилите BEAST (Browser Exploit Against SSL/TLS), чтобы расшифровать секретную кукису для входа в аккаунт PayPal. Посмотреть видеокаст можно на Youtube. Это не фейк. Живая демонстрация утилиты прошла в рамках конференции Ekoparty в Буэнос-Айросе, где исследователи выступили с докладом и показали работающий proof-of-concept. Используемая уязвимость действительно позволяет незаметно перехватывать данные, передаваемые между веб-сервером и браузером пользователя. По иронии судьбы атака эксплуатирует не какую-то новую найденную в протоколе брешь, а уязвимость SSL/TLS десятилетней давности, долгое время считавшуюся чисто теоретической. Но, как говорится, раз в год и палка стреляет, так что уж за десять лет уязвимость точно может перейти из разряда теоретических во вполне себе практическую.
Исследователи пока не публикуют утилиту, но делятся whitepaper'ом о проделанной работе. Программа состоит из двух элементов: снифера, который анализирует HTTPS-трафик, и специального агента, написанного на JavaScript и Java, который должен быть подгружен в браузере жертвы (для этого, к примеру, необходимо заставить пользователя открыть страницу с нужным кодом). Агент нужен для того, чтобы особым образом внедрять данные в тот же безопасный канал связи, который используется для передачи секретных кукисов. Как это позволяет дешифровать данные? Вот здесь вступает давно известная уязвимость SSL 3.0/TLS 1.0, на которой мы остановимся подробнее.
Протокол SSL 1.0/TLS 3.0 позволяет использовать шифрование симметричным ключом, используя либо блочные, либо потоковые шифры. На практике, однако, обычно используется блочные шифры, и описываемая нами атака применима именно для них. Чтобы вникнуть в суть, нужно хорошо представлять себе базовые понятия.
Принцип работы блочного шифра заключается в отображении блоков открытого текста в зашифрованные блоки того же размера. Проще всего представить блочный шифр в виде гигантской таблицы, содержащей 2^128 записей, каждая из которых содержит блок текста М и соответствующий ему зашифрованный блок С. Соответственно, для каждого ключа шифрования будет отдельная такая таблица. Далее мы будем обозначать шифрование в виде функции:
C = E(Key, M), где M — исходные данные, Key — ключ шифрования, а C — полученные зашифрованные данные.
Блоки имеют небольшой размер (как правило, 16 байт). Поэтому возникает вопрос: как зашифровать длинное сообщение? Можно разбить сообщение на блоки одинаковой длины (те же самые 16 байт) и зашифровать каждый блок в отдельности. Такой подход называется режимом простой замены (ECB, Electronic codebook), но используется редко. На то есть причина: если мы будем шифровать два одинаковых по содержимому блока, то в результате и на выходе получим два одинаковых зашифрованных блока. Это влечет за собой проблему сохранения статистических особенностей исходного текста, которая хорошо продемонстрирована на иллюстрации. Для избегания такого эффекта был разработан режим сцепления блоков шифротекста (СВС, Cipher-block chaining), в котором каждый следующий блок открытого текста XOR'ится с предыдущим результатом шифрования:
Во время шифрования первого блока исходный текст XOR’ится некоторым вектором инициализации (Initialization Vector, IV), который заменяет результат предыдущего шифрования, которого по понятной причине нет. Как видишь, все довольно просто. Однако эта теория описывает ситуацию для одного большого объекта, такого, например, как файл, который легко разбивается на блоки. В свою очередь, SSL/TLS является криптографическим протоколом — ему необходимо шифровать не отдельный файл, а серию пакетов. SSL/TLS-соединение может быть использовано для отправки серии HTTPS-запросов, каждый из которых может быть разбит на один или более пакетов, которые, в свою очередь, могут быть отправлены в течение как нескольких секунд, так и нескольких минут. В данной ситуации есть два способа использовать режим CBC:
Атака строится на нескольких допущениях, но опыт создателей BEAST показал, что их вполне реально реализовать в реальной жизни. Первое допущение: злоумышленник должен иметь возможность снифать трафик, который передает браузер. Второе допущение: плохой парень каким-то образом должен заставить жертву передавать данные по тому же самому безопасному каналу связи. Зачем это нужно? Рассмотрим случай, когда между компьютерами Боба и Элис установлено безопасное соединение. К нам попадает сообщение, i-блок которого, как мы предполагаем, содержит, пароль Элис (или секретную кукису — неважно). Обозначим зашифрованный блок как Ci, соответственно Mi — ее пароль. Напомню, что Ci = E (Key, Mi xor Ci-1). Теперь предположим, что ее пароль — это Р. Главная идея в том, что мы можем проверить правильность нашего предположения!
Итак, мы знаем (так как смогли перехватить) вектор инициализации, который будет использоваться для шифрования первого блока следующего сообщения. Это, соответственно, последний блок предыдущего сообщения (в зашифрованном виде) — обозначим его IV. Мы также перехватили и знаем значение блока, идущего перед Ci — обозначим его Ci-1. Эти данные нам очень нужны. С их помощью мы особым образом формируем сообщение так, чтобы первый блок был равен следующему:
Если сообщение удалось передать по тому же защищенному каналу связи, то первый блок нового сообщения после шифрования будет выглядеть следующим образом:
Все, что я сделал, — это использовал полную форму записи M1, после чего упростил формулу, используя тот факт, что (IV xor IV) уничтожится (замечательное свойство XOR'а). Получается, что если наше предположение относительно пароля Элис верное (то есть M действительно равен P), то первый зашифрованный блок нового сообщения C1 будет равен ранее перехваченному Ci! И наоборот: если предположение неверное, равенства не будет. Так мы можем проверять наши предположения.
Если предположить, что у нас есть кучу времени и множество попыток, мы можем повторять эту технику вновь и вновь, пока не найдем верное значение M. Однако на практике блок M — 16 байтов в длину. Даже если мы знаем значение всех байт кроме двух, на то, чтобы отгадать оставшиеся байты, нам понадобится 2^15 (32 768) попыток. А если мы не знаем вообще ничего? Короче говоря, техника может сработать лишь в единственном случае — если у тебя есть некоторое ограниченное количество предположений относительно значения M. Еще точнее: мы должны знать большую часть содержимого этого блока — это единственный способ использовать описанную уязвимость. Тут есть одна хитрость.
Предположим, что злоумышленник может контролировать, каким образом данные будут располагаться в шифруемом блоке. Вернемся опять к примеру с Элис. Допустим, мы знаем, что длина ее пароля — 8 символов. Если злоумышленник может расположить пароль таким образом, чтобы в первый блок попал только один символ, а оставшиеся семь попали в следующий. Идея в том, чтобы передать в первых 15 байтах первого блока заведомо известные данные — тогда можно будет подобрать только последний байт, являющийся первым символом пароля. Например, допустим, что нужно отправить строку вида: «user: alice password: ********», где "********" — непосредственно сам пароль. Если злоумышленнику удастся передать строку так, чтобы она была разбита на следующие блоки "[lice password: *] [*******.........]", то подбор первого символа пароля уже не кажется невыполнимой задачей. Напротив, в худшем случае нам понадобится жалкие 256 попыток. А в случае особой удачи и вовсе одна :)! Подобрав первый байт, можно сдвинуть границу разбиения на один символ: то есть передавать в первом сообщении 14 заранее известных байт. Блок теперь будет заканчиваться двумя первыми байтами пароля, первый из которых мы уже подобрали. И опять: получаем 256 необходимых попыток для того, чтобы угадать второй его байт. Процесс можно повторять до тех пор, пока пароль не будет подобран. Этот принцип используется и в BEAST для подбора секретной кукисы, а в качестве известных данных используются модифицированные заголовки запроса. Подбор ускоряется за счет сужения возможных символов (в запросе можно использовать далеко не все), а также за счет предположений имени кукисы.
Впрочем, сама уязвимость и оптимизированный способ для выполнения дешифрования описаны уже давно. Что действительно удалось разработчикам BEAST, так это реализовать все необходимые условия для выполнения атаки:
Незаметно внедрить апплет или JavaScript пользователю на самом деле не является такой уж сложной задачей. Но остается небольшой нюанс — для того, чтобы скрипт или апплет могли отправлять данные по установленному жертвой соединению, необходимо обойти еще и ограничения SOP (same-origin policy, правило ограничения домена). Это важная концепция безопасности для некоторых языков программирования на стороне клиента, таких как JavaScript. Политика разрешает сценариям, находящимся на страницах одного сайта, доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц на разных сайтах. Проще говоря, запущенный на одной странице клиент не сможет делать запросы к нужному сайту (скажем, Paypal.com). Чтобы обойти политику SOP, авторы нашли в виртуальной машине Java 0day-уязвимость и написали для нее работающий сплоит. Только не думай, что это позволяет читать существующие кукисы. Если бы это было так, тогда зачем нужен был весь этот сыр-бор с зашифрованным трафиком? Используя сплоит для обхода SOP, можно отправлять запросы и читать ответы сервера (в том числе ответы с новыми кукисами), но нельзя считывать существующие кукисы, которые сохранены в браузере. Разработчики делятся целой историей о создании агента в своем блоге.
В заключение хочется отметить огромный труд исследователей, которые не только сумели использовать уязвимость, забытую всеми десять лет назад, но также приложили много труда для того, чтобы заставить свою утилиту работать. В рамках этого материала мы довольно сильно упростили описания используемых техник, пытаясь передать основную идею. Но мы получили истинное удовольствие от прочтения детального документа от исследователей, в которых они в деталях рассказывают о реализованной атаке. Good job!
Итак, каковы же масштабы бедствия? Или иными словами — кто уязвим? Практически любой сайт, использующий TLS1.0, который является наиболее распространенным протоколом безопасности. Забавно, что после всей этой шумихи с BEAST, многие стали проявлять интерес к более новым версиям протокола — TLS 1.1 и выше. Но многие ли сайты уже сейчас поддерживают эти протоколы? Да практически никто! Посмотри на иллюстрацию. Даже несмотря на то, что TLS 1.1 уже пять лет, его используют единицы!
Другой вопрос: как обезопасить себя? На самом деле, паниковать нет смысла — уязвимость уже исправлена в большинстве браузеров. Но если паранойя берет верх, можешь попробовать отключить небезопасные протоколы в браузере (TLS 1.0 и SSL 3.0), а заодно и Java. Правда, не стоит в этом случае сильно удивляться, что многие сайты перестанут работать.
Журнал Хакер, Ноябрь (11) 154
Коллективный разум.
Что такое BEAST?
Всего 103 секунды потребовалось утилите BEAST (Browser Exploit Against SSL/TLS), чтобы расшифровать секретную кукису для входа в аккаунт PayPal. Посмотреть видеокаст можно на Youtube. Это не фейк. Живая демонстрация утилиты прошла в рамках конференции Ekoparty в Буэнос-Айросе, где исследователи выступили с докладом и показали работающий proof-of-concept. Используемая уязвимость действительно позволяет незаметно перехватывать данные, передаваемые между веб-сервером и браузером пользователя. По иронии судьбы атака эксплуатирует не какую-то новую найденную в протоколе брешь, а уязвимость SSL/TLS десятилетней давности, долгое время считавшуюся чисто теоретической. Но, как говорится, раз в год и палка стреляет, так что уж за десять лет уязвимость точно может перейти из разряда теоретических во вполне себе практическую.
Исследователи пока не публикуют утилиту, но делятся whitepaper'ом о проделанной работе. Программа состоит из двух элементов: снифера, который анализирует HTTPS-трафик, и специального агента, написанного на JavaScript и Java, который должен быть подгружен в браузере жертвы (для этого, к примеру, необходимо заставить пользователя открыть страницу с нужным кодом). Агент нужен для того, чтобы особым образом внедрять данные в тот же безопасный канал связи, который используется для передачи секретных кукисов. Как это позволяет дешифровать данные? Вот здесь вступает давно известная уязвимость SSL 3.0/TLS 1.0, на которой мы остановимся подробнее.
Проблема режима простой замены
Особенности шифрования SSL 1.0
Протокол SSL 1.0/TLS 3.0 позволяет использовать шифрование симметричным ключом, используя либо блочные, либо потоковые шифры. На практике, однако, обычно используется блочные шифры, и описываемая нами атака применима именно для них. Чтобы вникнуть в суть, нужно хорошо представлять себе базовые понятия.
Принцип работы блочного шифра заключается в отображении блоков открытого текста в зашифрованные блоки того же размера. Проще всего представить блочный шифр в виде гигантской таблицы, содержащей 2^128 записей, каждая из которых содержит блок текста М и соответствующий ему зашифрованный блок С. Соответственно, для каждого ключа шифрования будет отдельная такая таблица. Далее мы будем обозначать шифрование в виде функции:
C = E(Key, M), где M — исходные данные, Key — ключ шифрования, а C — полученные зашифрованные данные.
Блоки имеют небольшой размер (как правило, 16 байт). Поэтому возникает вопрос: как зашифровать длинное сообщение? Можно разбить сообщение на блоки одинаковой длины (те же самые 16 байт) и зашифровать каждый блок в отдельности. Такой подход называется режимом простой замены (ECB, Electronic codebook), но используется редко. На то есть причина: если мы будем шифровать два одинаковых по содержимому блока, то в результате и на выходе получим два одинаковых зашифрованных блока. Это влечет за собой проблему сохранения статистических особенностей исходного текста, которая хорошо продемонстрирована на иллюстрации. Для избегания такого эффекта был разработан режим сцепления блоков шифротекста (СВС, Cipher-block chaining), в котором каждый следующий блок открытого текста XOR'ится с предыдущим результатом шифрования:
Ci = E(Key, Mi xor Ci-1)Во время шифрования первого блока исходный текст XOR’ится некоторым вектором инициализации (Initialization Vector, IV), который заменяет результат предыдущего шифрования, которого по понятной причине нет. Как видишь, все довольно просто. Однако эта теория описывает ситуацию для одного большого объекта, такого, например, как файл, который легко разбивается на блоки. В свою очередь, SSL/TLS является криптографическим протоколом — ему необходимо шифровать не отдельный файл, а серию пакетов. SSL/TLS-соединение может быть использовано для отправки серии HTTPS-запросов, каждый из которых может быть разбит на один или более пакетов, которые, в свою очередь, могут быть отправлены в течение как нескольких секунд, так и нескольких минут. В данной ситуации есть два способа использовать режим CBC:
- обрабатывать каждое сообщение как отдельный объект, генерировать новый вектор инициализации и шифровать по описанной схеме.
- обрабатывать все сообщения как будто они объединены в один большой объект, сохраняя CBC-режим между ними. Этого можно достичь, используя в качестве вектора инициализации для сообщения n последний блок шифрования предыдущего сообщения (n-1).
Принцип действия CBC-шифра
Предсказуемый вектор инициализации
Атака строится на нескольких допущениях, но опыт создателей BEAST показал, что их вполне реально реализовать в реальной жизни. Первое допущение: злоумышленник должен иметь возможность снифать трафик, который передает браузер. Второе допущение: плохой парень каким-то образом должен заставить жертву передавать данные по тому же самому безопасному каналу связи. Зачем это нужно? Рассмотрим случай, когда между компьютерами Боба и Элис установлено безопасное соединение. К нам попадает сообщение, i-блок которого, как мы предполагаем, содержит, пароль Элис (или секретную кукису — неважно). Обозначим зашифрованный блок как Ci, соответственно Mi — ее пароль. Напомню, что Ci = E (Key, Mi xor Ci-1). Теперь предположим, что ее пароль — это Р. Главная идея в том, что мы можем проверить правильность нашего предположения!
Итак, мы знаем (так как смогли перехватить) вектор инициализации, который будет использоваться для шифрования первого блока следующего сообщения. Это, соответственно, последний блок предыдущего сообщения (в зашифрованном виде) — обозначим его IV. Мы также перехватили и знаем значение блока, идущего перед Ci — обозначим его Ci-1. Эти данные нам очень нужны. С их помощью мы особым образом формируем сообщение так, чтобы первый блок был равен следующему:
M1 = Ci-1 xor IV xor PЕсли сообщение удалось передать по тому же защищенному каналу связи, то первый блок нового сообщения после шифрования будет выглядеть следующим образом:
C1 = E(Key, M1 xor IV) =
= E(Key, (Ci-1 xor IV xor P) xor IV)
= E(Key, (Ci-1 xor P))
= СiВсе, что я сделал, — это использовал полную форму записи M1, после чего упростил формулу, используя тот факт, что (IV xor IV) уничтожится (замечательное свойство XOR'а). Получается, что если наше предположение относительно пароля Элис верное (то есть M действительно равен P), то первый зашифрованный блок нового сообщения C1 будет равен ранее перехваченному Ci! И наоборот: если предположение неверное, равенства не будет. Так мы можем проверять наши предположения.
Передача запроса на сервер для реализации атаки на SSL
Особенности перебора
Если предположить, что у нас есть кучу времени и множество попыток, мы можем повторять эту технику вновь и вновь, пока не найдем верное значение M. Однако на практике блок M — 16 байтов в длину. Даже если мы знаем значение всех байт кроме двух, на то, чтобы отгадать оставшиеся байты, нам понадобится 2^15 (32 768) попыток. А если мы не знаем вообще ничего? Короче говоря, техника может сработать лишь в единственном случае — если у тебя есть некоторое ограниченное количество предположений относительно значения M. Еще точнее: мы должны знать большую часть содержимого этого блока — это единственный способ использовать описанную уязвимость. Тут есть одна хитрость.
Предположим, что злоумышленник может контролировать, каким образом данные будут располагаться в шифруемом блоке. Вернемся опять к примеру с Элис. Допустим, мы знаем, что длина ее пароля — 8 символов. Если злоумышленник может расположить пароль таким образом, чтобы в первый блок попал только один символ, а оставшиеся семь попали в следующий. Идея в том, чтобы передать в первых 15 байтах первого блока заведомо известные данные — тогда можно будет подобрать только последний байт, являющийся первым символом пароля. Например, допустим, что нужно отправить строку вида: «user: alice password: ********», где "********" — непосредственно сам пароль. Если злоумышленнику удастся передать строку так, чтобы она была разбита на следующие блоки "[lice password: *] [*******.........]", то подбор первого символа пароля уже не кажется невыполнимой задачей. Напротив, в худшем случае нам понадобится жалкие 256 попыток. А в случае особой удачи и вовсе одна :)! Подобрав первый байт, можно сдвинуть границу разбиения на один символ: то есть передавать в первом сообщении 14 заранее известных байт. Блок теперь будет заканчиваться двумя первыми байтами пароля, первый из которых мы уже подобрали. И опять: получаем 256 необходимых попыток для того, чтобы угадать второй его байт. Процесс можно повторять до тех пор, пока пароль не будет подобран. Этот принцип используется и в BEAST для подбора секретной кукисы, а в качестве известных данных используются модифицированные заголовки запроса. Подбор ускоряется за счет сужения возможных символов (в запросе можно использовать далеко не все), а также за счет предположений имени кукисы.
Всего 103 секунды потребовалось для расшифровки секретной кукисы PayPal
Реализация атаки
Впрочем, сама уязвимость и оптимизированный способ для выполнения дешифрования описаны уже давно. Что действительно удалось разработчикам BEAST, так это реализовать все необходимые условия для выполнения атаки:
- атакующий должен иметь возможность прослушивать сетевые соединения, инициированные браузером жертвы;
- у атакующего должна быть возможность внедрить агент в браузер жертвы;
- агент должен иметь возможность отправлять произвольные (более-менее) HTTPS-запросы;
Незаметно внедрить апплет или JavaScript пользователю на самом деле не является такой уж сложной задачей. Но остается небольшой нюанс — для того, чтобы скрипт или апплет могли отправлять данные по установленному жертвой соединению, необходимо обойти еще и ограничения SOP (same-origin policy, правило ограничения домена). Это важная концепция безопасности для некоторых языков программирования на стороне клиента, таких как JavaScript. Политика разрешает сценариям, находящимся на страницах одного сайта, доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц на разных сайтах. Проще говоря, запущенный на одной странице клиент не сможет делать запросы к нужному сайту (скажем, Paypal.com). Чтобы обойти политику SOP, авторы нашли в виртуальной машине Java 0day-уязвимость и написали для нее работающий сплоит. Только не думай, что это позволяет читать существующие кукисы. Если бы это было так, тогда зачем нужен был весь этот сыр-бор с зашифрованным трафиком? Используя сплоит для обхода SOP, можно отправлять запросы и читать ответы сервера (в том числе ответы с новыми кукисами), но нельзя считывать существующие кукисы, которые сохранены в браузере. Разработчики делятся целой историей о создании агента в своем блоге.
Respect
В заключение хочется отметить огромный труд исследователей, которые не только сумели использовать уязвимость, забытую всеми десять лет назад, но также приложили много труда для того, чтобы заставить свою утилиту работать. В рамках этого материала мы довольно сильно упростили описания используемых техник, пытаясь передать основную идею. Но мы получили истинное удовольствие от прочтения детального документа от исследователей, в которых они в деталях рассказывают о реализованной атаке. Good job!
Масштабы проблемы
Итак, каковы же масштабы бедствия? Или иными словами — кто уязвим? Практически любой сайт, использующий TLS1.0, который является наиболее распространенным протоколом безопасности. Забавно, что после всей этой шумихи с BEAST, многие стали проявлять интерес к более новым версиям протокола — TLS 1.1 и выше. Но многие ли сайты уже сейчас поддерживают эти протоколы? Да практически никто! Посмотри на иллюстрацию. Даже несмотря на то, что TLS 1.1 уже пять лет, его используют единицы!
Другой вопрос: как обезопасить себя? На самом деле, паниковать нет смысла — уязвимость уже исправлена в большинстве браузеров. Но если паранойя берет верх, можешь попробовать отключить небезопасные протоколы в браузере (TLS 1.0 и SSL 3.0), а заодно и Java. Правда, не стоит в этом случае сильно удивляться, что многие сайты перестанут работать.
Журнал Хакер, Ноябрь (11) 154
Коллективный разум.
Microsoft Security Bulletin MS11-083 - Критические
Уязвимость в протоколе TCP/IP делает возможным Удаленное Выполнение Кода (2588516)
Опубликовано:
Версия: 1.0Общая Информация
Резюме
Это обновление для системы безопасности имеет существенный уровень важности для всех поддерживаемых выпусков Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2. Дополнительную информацию см. в подразделе Затронутых и Не Затронутых Программное обеспечение, в этом разделе.
Это обновление для системы безопасности устраняет уязвимость, изменяя способ, которым Windows TCP/IP стек сохраняет ссылки UDP пакетов в памяти. Для получения более подробной информации об уязвимости, см. Часто Задаваемые Вопросы (FAQ) , подраздел о данной уязвимости вступления в разделе Уязвимость Информации.
Рекомендации. Большинство клиентов имеют автоматическое обновление включено, и не нужно предпринимать каких-либо действий, потому что это обновление для системы безопасности будут загружены и установлены автоматически. Клиенты, которые не включена возможность автоматического обновления необходимо, чтобы проверка наличия обновлений и установить это обновление вручную. Для получения информации о конкретной опции конфигурации в автоматическом обновлении, см. Статье Базы Знаний Майкрософт 294871.
Для администраторов предприятия и объекты, или конечных пользователей, которые хотят установить это обновление для системы безопасности вручную, Microsoft рекомендует пользователям обновить объект немедленно, используя управление обновлениями программного обеспечения, либо проверка на обновления с помощью Microsoft Update сервис.
См. также раздел, Обнаружение и Развертывание Инструментов и руководств, позднее в данном бюллетене.
Известные Проблемы. Нет
Затронутых и Не Затронутых Программное обеспечение
Программное Обеспечение
Управление Установкой Ядра Сервера и Обслуживание Установки Server Core. Обратите внимание, что установка Основных компонентов Сервера не распространяется на некоторые выпуски Windows Server 2008 и Windows Server 2008 R2, см. Сравнить Установки Server Core Опции.
Не Подвержены Уязвимости
| Операционная Система |
|---|
| Windows XP Service Pack 3 |
| Windows XP Professional x64 Edition с пакетом Обновления 2 |
| Windows Server 2003 Service Pack 2 |
| Windows Server 2003 x64 Edition с пакетом Обновления 2 |
| Windows Server 2003 с пакетом обновления SP2)для платформы Itanium |
Часто Задаваемые Вопросы (FAQ) , Связанные с данным Обновлением для системы Безопасности
Уязвимость Информации
Строгость Рейтинги и Уязвимости Идентификаторы
Контрольный Счетчик Переполнения Уязвимости CVE-2011-2013 гг.
Обновление Информации
Обнаружение и Развертывание Инструментов и руководств
Безопасности Развертывание Обновления
Другая Информация
Microsoft Active Protections Program (МАПП)
Для улучшения защиты для клиентов, Microsoft предоставляет сведения об уязвимости в безопасности крупных поставщиков программного обеспечения, в преддверии очередного ежемесячного обновления безопасности релиз. Разработчики программного обеспечения могут затем использовать эту уязвимость информацию, чтобы предоставлять обновление защиты для клиентов через их безопасности программного обеспечения или устройств, таких как антивирус, сетевой системы обнаружения вторжений, или host-based intrusion prevention systems. Чтобы определить, является ли активное защиты доступны из разработчики программного обеспечения, пожалуйста, посетите активной защиты Веб-сайтов, предоставляемых партнерами программы, перечисленные в Microsoft Active Protections Program (МАПП) Партнеры.
Поддержка
- Клиенты в США и Канаде, могут получать техническую поддержку от Службы или по телефону 1-866-ВЕРХНЕЙ (1-866-727-2338). Существует не взимать плату за поддержку звонки, связанные с обновлениями для системы безопасности. Для получения более подробной информации о вариантах поддержки, см. Справки и Поддержки Microsoft.
- Международные клиенты могут получать поддержку от своих местных Microsoft дочерних компаний. Существует не взимать плату за поддержку, связанных с обновлениями для системы безопасности. Для получения дополнительной информации о том, как связаться с Microsoft по поддержке вопросы, посетите Веб-сайте Международной Поддержки.
Информация Об Ограничении Ответственности
Пересмотр
- 1.0(8 Ноября 2011 г.): Бюллетень опубликован.
Posted in: 
