Sha1 0xaf1a342b что это
Прекращена поддержка конечных точек Центра обновления Windows на основе SHA-1 для устройств со старыми версиями Windows
Введение
В соответствии с политикой завершения поддержки алгоритма SHA-1 (Майкрософт) Центр обновления Windows прекращает использовать конечные точки на основе SHA-1 в конце июля 2020 г. Это означает, что устройства со старыми версиями Windows, не обновленные до SHA-2, больше не будут получать обновления через Центр обновления Windows. Ваши устройства со старыми версиями Windows могут продолжать использование Центра обновления Windows путем установки вручную определенных обновлений, включающих поддержку SHA-2.
Все остальные платформы Windows продолжат получать обновления через Центр обновления Windows, так как они подключены к конечным точкам службы SHA-2.
С чем связано это обновление?
Поддержка устаревших конечных точек службы Центра обновления Windows, использовавшихся только для старых платформ, прекращается. Это изменение вносится, из-за слабостей алгоритма хеширования SHA-1 и для обеспечения соответствия отраслевым стандартам.
Хотя конечная точка SHA-1 больше не поддерживается, устройства с новыми версиями Windows продолжат получать обновления через Центр обновления Windows, так как эти устройства используют более безопасный алгоритм SHA-2. Чтобы узнать, затрагивается ли ваше устройство, см. таблицу в разделе «Какие устройства с Windows затронуты».
Какие устройства с Windows затронуты?
Большинство пользователей не затрагиваются этим изменением. С Windows 8 для компьютеров и Windows Server 2012 подключения к конечным точкам службы Центра обновления Windows используют более современный алгоритм (SHA-256). В более ранних версиях Windows для подключения к конечным точкам службы Центра обновления Windows используется менее надежный алгоритм SHA-1.
Для большинства затронутых версий Windows обновление SHA-2 добавит поддержку, необходимую для продолжения получения обновлений через Центр обновления Windows. В таблице ниже показано влияние на различные версии Windows. Некоторые платформы больше не поддерживаются, поэтому они не будут обновлены.
Windows для рабочего стола
Устройство не поддерживается
Центры обновления Windows больше не будут поддерживаться.
64-разрядная версия Windows XP
Windows XP с пакетом обновления 3 (SP3)
Windows Vista с пакетом обновления 1 (SP1)
Windows Vista с пакетом обновления 2 (SP2)
Поддержка Центра обновления Windows будет затронута.
Проблему можно устранить путем ручной установки обновлений KB.
Windows 7 с пакетом обновления 1 (SP1)
Windows 8 и более поздние версии
Не затрагивается
Обновление не требуется
Windows 2000 Server
Устройство не поддерживается
Центры обновления Windows больше не будут поддерживаться.
Windows Server 2003
Windows Server 2003 с пакетом обновления 2 (SP2)
Windows Server 2008
Поддержка Центра обновления Windows будет затронута.
Проблему можно устранить путем ручной установки обновлений KB.
Windows Server 2008 с пакетом обновления 2 (SP2)
Windows Server 2008 R2
Windows Server 2008 R2 с пакетом обновления 1 (SP1)
Windows 2012 и более поздние версии
Не затрагивается
Обновление не требуется
Что произойдет с затронутыми устройствами?
В соответствии с предыдущей таблицей это изменение затрагивает только устройства со старыми версиями Windows, которые не обновлены до SHA-2. Затронутые устройства больше не смогут получать обновления через Центр обновления Windows, пока вы вручную не обновите их до SHA-2. Чтобы вручную обновить устройства с Windows, см. раздел «Как обновить устройства с Windows до SHA-2».
Устройство с Windows, не обновленное до SHA-2, попытается найти обновления и вернет одну из следующих ошибок:
Код ошибки 80072ee2: Устройству не удается подключиться к Центру обновления Windows.
Код ошибки 8024402c: Устройство не может найти Центр обновления Windows.
Код ошибки 80244019: Устройству не удается подключиться к Центру обновления Windows.
Некоторые проверки на наличие обновлений выполняются без непосредственного взаимодействия с пользовательским интерфейсом, например автоматические обновления, драйверы устройств, подписи антивирусной программы в Защитнике, обновления Microsoft Office и т. д. Для таких «фоновых» проверок эти сбои будут неочевидными. В таком случае вы можете проверить файл журнала Центра обновления Windows (c:\windows\windowsupdate.log) на наличие кодов сбоев: 0x8024402c, 8024402c, 0x80072ee2, 80072ee2, 0x80244019 или 80244019.
Как обновить устройства с Windows до SHA-2
Чтобы продолжать использовать Центр обновления Windows для устройств со старыми версиями Windows, вам требуется скачать и установить следующие два обновления:
Обновление 1: поддержка подписи кода SHA-2
При применении этого обновления добавляется поддержка для проверки подписей с использованием более безопасных алгоритмов хеширования SHA-2. Применяйте только обновление, подходящее для вашего устройства с Windows.
KB4474419: обновление поддержки подписи кода SHA-2
Область применения: Windows 7 SP1, Windows Server 2008 R2 SP1 и Windows Server 2008 SP2
KB4484071: поддержка SHA-2 для Windows Server Update Services
Область применения: Windows Server Update Services 3.0 SP1 и Windows Server Update Services 3.2
Примечание. Большинству пользователей следует устанавливать только обновление KB4474419. Корпоративные администраторы также могут установить обновление KB4484071.
Обновление 2: обновления стека обслуживания, связанного с SHA-2
При установке этого обновления добавляется поддержка в стек обслуживания Центра обновления Windows, чтобы проверять подписи SHA-2 и инструктировать затронутые устройства с Windows на выполнение связи с использованием современных конечных точек службы на основе SHA-2 в Центре обновления Windows. Применяйте только обновление, подходящее для вашего устройства с Windows.
KB4490628: Обновление стека обслуживания
Область применения: Windows 7 SP1 и Windows Server 2008 R2 SP1
KB4493730: обновления стека службы WU
Область применения: Windows Server 2008 SP2
Первый способ генерации коллизий для SHA-1
Коллизии существуют для большинства хеш-функций, но для самых хороших из них количество коллизий близко к теоретическому минимуму. Например, за десять лет с момента изобретения SHA-1 не было известно ни об одном практическом способе генерации коллизий. Теперь такой есть. Сегодня первый алгоритм генерации коллизий для SHA-1 представили сотрудники компании Google и Центра математики и информатики в Амстердаме.
Вот доказательство: два документа PDF с разным содержимым, но одинаковыми цифровыми подписями SHA-1.
На сайте shattered.it можно проверить любой файл на предмет того, входит ли он в пространство возможных коллизий. То есть можно ли подобрать другой набор данных (файл) с таким же хешем. Вектор атаки здесь понятен: злоумышленник может подменить «хороший» файл своим экземпляром с закладкой, вредоносным макросом или загрузчиком трояна. И этот «плохой» файл будет иметь такой же хеш или цифровую подпись.
Криптографические хеш-функции вроде SHA-1 — это универсальный криптографический инструмент, который повсеместно используется в практических приложениях. Они нужны при построении ассоциативных массивов, при поиске дубликатов в наборах данных, при построении уникальных идентификаторов, при вычислении контрольных сумм для обнаружения ошибок. Например, на хеши SHA-1 полностью полагается система управлениями версиями программного обеспечения Git.
Но ещё важнее, что хеширование критически важно в сфере информационной безопасности: оно используется при сохранении паролей, при выработке электронной подписи и т.д. В общем виде, хеш-функции преобразуют любой большой массив данных в небольшое сообщение.
Учитывая повсеместное распространение хеш-функций очень важным требованием является минимальное количество коллизий, когда два различных блока входных данных преобразуются в два одинаковых хеша.
В официальном сообщении авторы говорят, что эта находка стала результатом двухлетнего исследования, которая началась вскоре после публикации в 2013 году работы криптографа Марка Стивенса из Центра математики и информатики в Амстердаме о теоретическом подходе к созданию коллизии SHA-1. Он же в дальнейшем продолжил поиск практических методов взлома вместе с коллегами из Google.
Компания Google давно выразила своё недоверие SHA-1, особенно в качестве использования этой функции для подписи сертификатов TLS. Ещё в 2014 году, вскоре после публикации работы Стивенса, группа разработчиков Chrome объявила о постепенном отказе от использования SHA-1. Теперь они надеются, что практическая атака на SHA-1 увеличит понимание у сообщества информационной безопасности, так что многие ускорят отказ от SHA-1.
Специалисты начали поиск практического метода атаки с создания PDF-префикса, специально подобранного для генерации двух документов с разным контентом, но одинаковым хешем SHA-1.
PDF-префикс
Идентичный префикс для коллизии, рассчитанной на инфраструктуре Google
Затем они использовали инфраструктуру Google, чтобы произвести вычисления и проверить теоретические выкладки. Разработчики говорят, что это было одно из самых крупных вычислений, которые когда-либо проводила компания Google. В общей сложности было произведено девять квинтиллионов вычислений SHA-1 (9 223 372 036 854 775 808), что потребовало 6500 процессорных лет на первой фазе и 110 лет GPU на второй фазе атаки.
Числа кажутся большими, но на самом деле такая атака вполне практически реализуема для злоумышленника, у которого есть крупный компьютерный кластер или просто деньги на оплату процессорного времени в облаке. По оценке Google, атака проводится примерно в 100 000 быстрее, чем брутфорс, который можно считать непрактичным.
Чтобы представить число хешей, которые обсчитала Google во время брутфорса, можно упомянуть, что примерно такое же количество хешей SHA-256 обсчитывается в сети Bitcoin каждые три секунды, так что в атаке нет ничего фантастического. Вполне можно предположить, что в криптографических отделах некоторых организаций с большими дата-центрами уже давно обсчитываются коллизии SHA-1. Правда, чтобы подобрать коллизию для конкретного сертификата TLS, нужен какой-то другой метод, потому что идентичный префикс из научной работы Google для PDF там не подойдёт. С другой стороны, содержимое сертификатов во многом совпадает, так что теоретически префикс для коллизии можно подобрать.
Сейчас Марк Стивенс с соавторами опубликовали научную работу, в которой описывают общие принципы генерации документов с блоками сообщений, которые подвержены коллизии SHA-1.
Блоки сообщений, которые подвержены коллизии SHA-1
В соответствии с принятыми правилами раскрытия уязвимостей Google обещает через 90 дней опубликовать в открытом доступе полный код для проведения атаки. Тогда кто угодно может создавать разные документы с одинаковыми цифровыми подписями SHA-1. Возможно, даже разные сертификаты, разные обновления программного обеспечения в Git, разные раздачи на торрентах (хеши DHT), разные старые ключи PGP/GPG и т.д. Впрочем, не стоит преувеличивать опасность таких атак, ведь далеко не каждый документ будет подвержен атаке на поиск коллизии. То есть злоумышленнику придётся изначально создавать два файла: один «хороший», а второй «плохой» с такой же подписью. Затем распространять «хороший» документ по нормальным каналам (например, через Git или торрент-трекер), а впоследствии пробовать подменить его «плохим» файлом с той же цифровой подписью. Впрочем, всё это чисто теоретические рассуждения.
Защита от документов, подверженных коллизии хешей SHA-1 уже встроена в программное обеспечение Gmail и GSuite. Как уже упоминалось выше, детектор уязвимых документов работает в открытом доступе на сайте shattered.io. Кроме того, библиотека для обнаружения коллизий опубликована на Github.
В качестве защиты от атаки на отыскание коллизий SHA-1 компания Google рекомендует перейти на более качественные криптографические хеш-функции SHA-256 и SHA-3.
🔒 Учебное пособие по алгоритму хеширования SHA1 с примерами использования
SHA1 больше не безопасен
SHA1 используется для обеспечения целостности и безопасности данных.
В особенности после 2005 года существует множество различных атак на алгоритм SHA1.
Первый публичные коллизиии опубликованы в 2017 году, и после этого SHA1 не считается безопасным.
Атака коллизий – это просто другое входное значение, которое может генерировать такое же выходное хеш-значение, которое обманывает системы безопасности.
Инструменты SHA1
В настоящее время существует множество инструментов, и даже некоторые из них есть в интернет для создания хеш-значений SHA1.
По следующему адресу вы можете найти инструмент, который поддерживает множество различных алгоритмов хеширования и кодирования.
Инструменты для взлома SHA1
Есть также некоторые инструменты взлома, которые могут легко взломать популярные слова и пароли.
В частности, системы Linux, Network и Windows используют SHA1 для хеширования и скрытия паролей, но это можно легко взломать с помощью следующих сайтов для взлома.
Использование SHA1 на Linux
Использование SHA1 в PHP
Язык программирования PHP предоставляет встроенную функцию вычисления SHA1 с именем sha1 ().
Нам просто нужно предоставить данные или текст, для которого мы можем вычислить хэш.
В этом примере мы вычислим хеш «crackme123».
Использование SHA1 в Python
Python также обеспечивает поддержку алгоритма хеширования SHA1 с модулем / библиотекой hashlib.
Сначала мы импортируем hashlib, а затем используем функцию sha1 (), предоставляя данные или текст, для которого мы хотим вычислить хэш.
В этом примере мы вычислим хеш «crackme».
MD5 – еще один популярный алгоритм хеширования, созданный до SHA1.
Но они использовались в 1990-х и 2000-х годах и были альтернативой друг другу.
В этой части мы сравним алгоритмы хэширования SHA1 и MD5.
Что такое SHA-1 и как он используется для проверки данных?
SHA-1 (сокращение от Secure Hash Algorithm 1 ) – одна из нескольких криптографических хеш-функций.
SHA-1 чаще всего используется для проверки того, что файл не был изменен. Это делается путем создания контрольной суммы до того, как файл был передан, а затем еще раз, как только он достигнет места назначения.
История и уязвимости хэш-функции SHA
SHA-1 – это только один из четырех алгоритмов в семействе алгоритмов безопасного хэширования (SHA). Большинство из них были разработаны Агентством национальной безопасности США (NSA) и опубликованы Национальным институтом стандартов и технологий (NIST).
SHA-0 имеет 160-битный размер дайджеста сообщений (хэш-значение) и был первой версией этого алгоритма. Хэш-значения SHA-0 имеют длину 40 цифр. Он был опубликован под названием «SHA» в 1993 году, но не использовался во многих приложениях, потому что он был быстро заменен на SHA-1 в 1995 году из-за недостатка безопасности.
SHA-1 – это вторая итерация этой криптографической хеш-функции. SHA-1 также имеет дайджест сообщения в 160 битов и стремится повысить безопасность за счет устранения слабости, обнаруженной в SHA-0. Однако в 2005 году SHA-1 также оказался небезопасным.
После того, как в SHA-1 были обнаружены криптографические недостатки, NIST сделал заявление в 2006 году, призывая федеральные агентства принять использование SHA-2 к 2010 году. SHA-2 сильнее, чем SHA-1, и атаки на SHA-2 маловероятны произойти с текущей вычислительной мощностью.
Не только федеральные агентства, но даже такие компании, как Google, Mozilla и Microsoft, либо начали планы прекращения приема сертификатов SHA-1 SSL, либо уже заблокировали загрузку таких страниц.
У Google есть доказательства коллизии SHA-1, которая делает этот метод ненадежным для генерации уникальных контрольных сумм, будь то пароль, файл или любая другая часть данных. Вы можете загрузить два уникальных файла PDF из SHAttered, чтобы увидеть, как это работает. Используйте калькулятор SHA-1 в нижней части этой страницы, чтобы сгенерировать контрольную сумму для обоих, и вы обнаружите, что значение точно такое же, даже если они содержат разные данные.
SHA-2 и SHA-3
Разработанный не-NSA дизайнерами и выпущенный NIST в 2015 году, он является еще одним членом семейства Secure Hash Algorithm, который называется SHA-3 (ранее Keccak ).
SHA-3 не предназначен для замены SHA-2, как предыдущие версии предназначались для замены более ранних. Вместо этого SHA-3 был разработан как еще одна альтернатива SHA-0, SHA-1 и MD5.
Как используется SHA-1?
Один из реальных примеров использования SHA-1 – это когда вы вводите свой пароль на странице входа на веб-сайт. Хотя это происходит в фоновом режиме без вашего ведома, это может быть метод, который веб-сайт использует для надежной проверки подлинности вашего пароля.
В этом примере представьте, что вы пытаетесь войти на сайт, который вы часто посещаете. Каждый раз, когда вы запрашиваете вход в систему, вы должны ввести свое имя пользователя и пароль.
Если веб-сайт использует криптографическую хэш-функцию SHA-1, это означает, что ваш пароль превращается в контрольную сумму после ее ввода. Затем эта контрольная сумма сравнивается с контрольной суммой, которая хранится на веб-сайте и связана с вашим текущим паролем, независимо от того, не изменил свой пароль с момента регистрации или если вы только что изменили его несколько минут назад. Если они совпадают, вам предоставляется доступ; если они этого не делают, вам говорят, что пароль неверный.
Другой пример, где может использоваться хеш-функция SHA-1, – для проверки файла. Некоторые веб-сайты предоставляют контрольную сумму файла SHA-1 на странице загрузки, чтобы при загрузке файла вы могли проверить контрольную сумму самостоятельно, чтобы убедиться, что загруженный файл совпадает с тем, который вы намеревались загрузить.
Вы можете спросить, где реальное использование этого типа проверки. Рассмотрим сценарий, в котором вы знаете контрольную сумму файла SHA-1 с веб-сайта разработчика, но хотите загрузить ту же версию с другого веб-сайта. Затем вы можете сгенерировать контрольную сумму SHA-1 для вашей загрузки и сравнить ее с подлинной контрольной суммой на странице загрузки разработчика.
Если эти два значения отличаются, это означает, что содержимое файла не только идентично, но что может быть скрытой вредоносной программой в файле, данные могут быть повреждены и нанести ущерб файлам вашего компьютера, файлу. не имеет ничего общего с реальным файлом и т. д.
Однако это также может означать, что один файл представляет более старую версию программы, чем другой, поскольку даже небольшое изменение приведет к созданию уникального значения контрольной суммы.
Вы также можете проверить, идентичны ли эти два файла, если вы устанавливаете пакет обновления или какую-либо другую программу или обновление, потому что возникают проблемы, если некоторые файлы отсутствуют во время установки.
Калькуляторы контрольной суммы SHA-1
Для определения контрольной суммы файла или группы символов можно использовать специальный калькулятор.
Например, SHA1 Online и SHA1 Hash Generator – это бесплатные онлайн-инструменты, которые могут генерировать контрольную сумму SHA-1 для любой группы текста, символов и/или чисел.
Security Week 42: коллизии в SHA-1, практический взлом роутеров, Android/Безопасность/Грусть
В новом выпуске дайджеста по кибербезопасности Константин Гончаров пытается сделать выводы из позорных неудач известных ИТ компаний.
Когда вы находитесь в эпицентре событий, иногда сложно понять, что на самом деле произошло. Находясь в пробке, вы не узнаете, что она произошла из-за ДТП, пока не доберетесь до двух подбитых летчиков, занявших три полосы. До этого момента у вас просто недостаточно информации, чтобы сделать выводы.
В индустрии информационной безопасности так часто происходит: тема сложная, нюансов много, а результат некоторых исследований можно реально оценить только через несколько лет.
На этой неделе три самые интересные новости о безопасности не имеют между собой ничего общего, кроме толстого слоя подтекстов. Если не заниматься темой постоянно, важность некоторых событий можно оценить неправильно или не увидеть какие-то важные детали.
Попробую по мере сил объяснить на примерах, хотя подтексты — штука такая: каждому видится что-то свое. Добро пожаловать в 11-й эпизод сериала Security Week им. Срыва Покровов. Традиционные правила: каждую неделю редакция новостного сайта Threatpost выбирает три наиболее значимые новости, к которым я добавляю расширенный и беспощадный комментарий. Все эпизоды сериала можно найти тут.
Поиск коллизий для алгоритма SHA-1 серьезно подешевел
Новость. Предсказание Джесси Уокера трехлетней давности. Новое исследование, изменившее представления о безопасности алгоритма.
Те, кто продвинулся в освоении Linux чуть дальше автоматической установки Ubuntu, знают, что эта система мотивирует читать инструкции. В смысле первым делом я, конечно, пробую нагуглить доку, где просто указана последовательность команд, но в некоторых случаях у меня сначала ничего не заработает, а потом вообще все сломается.
Эта новость из той же серии: без хотя бы минимального погружения в матчасть в ней сложно разобраться. Несмотря на то что это, пожалуй, самая сложная тема за все время существования сериала, я попробую рассказать, в чем суть, простыми словами.
Ну, как-то так попробую
SHA-1 — алгоритм криптографического хеширования. Такому алгоритму можно дать на входе последовательность данных почти неограниченной длины, а на выходе получить 160 бит информации, которые позволяют идентифицировать исходный массив данных. Если, конечно, он у вас есть: восстановить информацию из хеша не получится, фарш невозможно провернуть назад.
Точнее, не должно получаться, даже если на входе, например, у вас пароль незадачливого пользователя типа «123456». К любому подобному алгоритму есть два требования: невозможность получить исходные данные, имея на руках только хеш, и невозможность подобрать такую пару наборов данных, чтобы их хеш совпадал.
Если быть точным, возможность сделать и то, и другое почти всегда имеется. Просто это должно быть связано с настолько большим объемом вычислений, что нечего даже и пытаться. Ну, то есть вы покупаете самый мощный суперкомпьютер, даете ему задачу сломать шифр. Через 240 лет он говорит, что ответ — 42, но вас к тому времени это уже никак не волнует.
Но есть нюанс. Во-первых, производительность компьютеров постоянно растет. Во-вторых, исследователи ищут обходные пути, позволяющие взломать криптографические системы. Для алгоритма хеширования найти коллизию гораздо проще, чем расшифровать исходные данные.
Между тем тот же SHA-1 используется в различных системах шифрования и авторизации, где его главная задача — убедиться, что данные у двух разных абонентов совпадают. Если можно найти два или больше массивов данных, у которых хеш будет одинаковый, причем сделать это дешево и быстро, — значит, алгоритм больше не надежен.
Если у вас в ближайшие пару лет накопится 75 тысяч долларов, то у вас есть все шансы ломануть алгоритм SHA-1: https://t.co/Z2qzi1NclE
Пожалуй, на этом остановлюсь, потому что дальше начинается совсем уж суровый матан, который сути дела не меняет. Работа исследователей выглядит примерно так: придумываем алгоритм поиска коллизии, который позволяет найти таковую за чуть меньшее количество операций, чем простой перебор. Точнее, тут имеет смысл говорить про атаку «Дней рождения». Дней рождения, Карл!
Какие-то неправильные у меня простые слова.
Затем исследователи улучшают этот алгоритм, еще больше уменьшая количество операций. В результате ту самую атаку, требовавшую 240 лет, становится возможно выполнить за 120 лет. Или за 12. Или за 2. Вот когда вместо двух с половиной веков требуется всего два месяца, можно начинать волноваться.
Так вот, три года назад специалист по криптографии Джесси Уокер из Intel предположил, что к 2015 году для нахождения коллизий алгоритма SHA-1 потребуется два в одиннадцатой степени серверо-лет (ну, если взять за основу такой сферический типовой сервер в вакууме).
Но это была оценка 2012 года. Получалось, что уже тогда алгоритм SHA-1 был не настолько надежен, как хотелось бы, только эксплуатировать эту ненадежность могли очень состоятельные организации, например разведка какой-нибудь небедной страны.
Естественно, такие конторы не торопятся выпускать пресс-релизы о своих успехах на ниве борьбы с криптографией. Так что важнее понять, когда доступ к такому «инструменту» получат пусть и состоятельные, но киберпреступники.
Ну или дороже и побыстрее, кому как удобно. Известный эксперт в области криптографии Брюс Шнайер прокомментировал это таким образом: оценка 2012 года учитывала закон Мура, но не принимала во внимание усовершенствование алгоритма атаки и метода проведения атаки (например, использование графических процессоров для вычислений, которые выполняют задачу быстрее и дешевле). Надежно предсказать эффект такой оптимизации действительно невозможно.
А дальше задаем традиционный вопрос: на практике это новое исследование и новая оценка кому-то угрожают? Не так чтобы очень. А как вообще такие «уязвимости» могут эксплуатироваться? Есть пример для значительно менее стойкого алгоритма MD5: берем два разных файла (в данном случае использовались фотографии рок-звезд) и, последовательно модифицируя данные в одном из них, получаем в итоге одинаковый хеш для двух абсолютно разных изображений.
А что с SHA-1? Алгоритм применяется с 1995 года, и, в общем-то, уже в 2005-м, 10 лет назад, было понятно, что это не самая надежная в мире технология. Но даже с новыми вводными данными до практической эксплуатации еще далеко, в то время как SHA-1 постепенно выводится из использования и заменяется более надежными алгоритмами хеширования.
В новой версии Google Chrome будут помечаться небезопасными SSL-сертификаты, использующие алгоритм SHA-1 http://t.co/bIe7x63a1E
С другой стороны, все исследования уязвимости SHA-1 пока что имеют чисто научную ценность. Пытаться понять на практике, чем это грозит, — это все равно что из сообщения «12 апреля 1961 года над Казахстаном сгорело 250 тонн ракетного топлива» сделать вывод, что человек впервые полетел в космос, не зная об этом заранее. Поживем — увидим.
Fun fact: хеш вообще-то правильно называть digest или message digest. Получается, вы только что прослушали дайджест про дайджест. Рекурсия, уи-и-и-и!
Уязвимость в роутерах Netgear эксплуатируется на практике
В маршрутизаторах Netgear N300 обнаружили уязвимость. Ну да, еще одна дыра в роутерах, и как-то получается, что они все разные, но при этом на одно лицо. В одной из прошлых серий уже обсуждали пачку дыр в устройствах Belkin. У Netgear причем все как-то совсем обидно.
Открываем веб-интерфейс роутера. Вводим пароль, неправильный, так как роутер чужой и пароль мы не знаем. Нас отправляют на страничку, где пишут Access Denied. Но если попытаться открыть страничку с именем BRS_netgear_success.html, то… нас тоже никуда не пустят. А вот если попытаться сделать это несколько раз подряд, то — пустят.
Естественно, при этом желательно быть уже внутри локальной сети, что несколько усложняет задачу. Хотя если роутер, например, раздает Wi-Fi в кафе, то попасть внутрь — не проблема. А если владелец зачем-то включил доступ к веб-интерфейсу из Интернета, то вообще все просто.
Кстати, кто-нибудь может сказать, зачем в принципе нужен доступ к веб-интерфейсу снаружи? Именно к веб-интерфейсу роутера, а не к каким-нибудь штукам в локальной сети. Мне кажется, причин так делать вообще нет, а поводов НЕ делать, как видите, предостаточно.
Уязвимость в маршрутизаторах Netgear оказалась атакована. Не успели пропатчить, чего ждали — непонятно: https://t.co/oWwyAU0yXA
В общем-то, тут все шло достаточно хорошо: вендора уведомили, через два месяца он сделал бета-версию прошивки. Еще бы чуть-чуть — и обошлось, но нет, оказалось, что уязвимость уже эксплуатируют, что называется, «в полях».
Швейцарская компания Compass Security обнаружила такой роутер с измененными настройками: в качестве DNS-сервера был прописан не адрес провайдера, как это обычно бывает, а не пойми что. Соответственно, через это «не пойми что» проходили все DNS-запросы. Исследование сервера атакующих показало, что он «обслуживает» больше 10 тыс. взломанных роутеров.
Netgear наконец-то разродилась патчем для атакованных роутеров. Обновлению подлежат восемь моделей: https://t.co/57UhYFX7iY
Fun fact: компания Compass Security довольно долго не могла добиться никакого ответа от Netgear. Затем диалог таки случился, и им даже прислали бета-версию прошивки на проверку. Но тут (откуда ни возьмись) появилась компания Shellshock Labs и опубликовала свое исследование той же уязвимости, вообще ни с кем не договариваясь (что как бы не очень хорошо).
Конечно, назвать компанию в честь бага в bash — это круто, но принцип «не навреди» никто не отменял. Зато из исследования «потрясателей шелла» становится понятно, откуда взялась уязвимость в веб-интерфейсе. В коде прошивки предусмотрена возможность войти в веб-интерфейс без пароля один раз, при первом запуске. Чтобы дальше это не работало, был предусмотрен флажок, про который просто забыли. Да, прошивку в итоге все же обновили.
85% Android-устройств небезопасны
Новость. Сайт исследователей, с рейтингом безопасности по вендорам.
Да вы что! Никогда такого не было, и вот опять! Между тем речь идет еще об одном научном исследовании, хотя, конечно, не таком забористом, как в истории про SHA-1. Исследователи из Кембриджского университета проделали интересную штуку. Собрали данные о 32 серьезных уязвимостях в Android, потом выбрали из них 13 наиболее серьезных и проверили сразу много телефонов разных производителей на наличие этой уязвимости.
Проверяли так: сделали приложение Device Analyzer, через которое открыто собирали различную анонимную телеметрию у участников эксперимента, включая такие параметры, как версия ОС и номер билда. Всего удалось собрать информацию более чем с 20 тыс. смартфонов.
Далее, сопоставив номер версии Android с информацией об уязвимостях, смогли примерно оценить масштаб беды. В результате получилась вот такая картинка:
Усреднение показателей за все время исследования и дало ту самую цифру 85% — в среднем в любой момент времени именно такая доля устройств на Android подвержена одной из известных и потенциально опасных уязвимостей. Или не одной. Как обычно, ударение надо делать на «потенциально» — на примере Stagefright понятно, что даже на самую опасную уязвимость накладываются суровые ограничения по практической реализации.
Но на этом исследователи не остановились и сделали рейтинг «опасности» устройств по производителям, назвав его FUM Score. В нем учитывается и время реакции вендора на информацию о новой уязвимости — как быстро патч появляется в устройствах конкретного производителя.
Победителем стала — предсказуемо — серия смартфонов Nexus: в ней баги исправляются максимально быстро. На втором месте LG, на третьем — Motorola. Впрочем, «победителей» тут на самом деле нет, одни проигравшие.
В расчете учитывается именно доля обновленных устройств, то есть не только вендор должен выпустить патч, но и владелец — не полениться обновить. Чем старше устройство, тем хуже: в отдельном рейтинге по моделям смартфонов у не самых старых устройств двух-трехлетней давности совсем уж унылые показатели. Почему? Не обновляют. Но пользуются.
85% Android-устройств небезопасны, потому что операторы так и не научились вовремя обеспечивать аппараты патчами: https://t.co/maJ7KGiNBV
В общем, в методике исследования есть немало вольных допущений, да и доказывает она то, что и так всем известно. По словам исследователей, одной из целей их работы является дополнительная мотивация производителей таки починить систему латания дыр в своих устройствах. А вот что на самом деле важно: на картинке выше мы видим пример экосистемы, которая в принципе не может быть на 100% безопасной.
Хотя Android со своей фрагментацией — это самый показательный пример, таких экосистем много. Можно говорить о том, что iOS безопаснее, но, как показывает первая история дайджеста про, эм, дайджест, не бывает абсолютно надежных систем, бывает мало водки ограничение по бюджету. А это такой очень важный момент при выборе стратегии защиты.
Что еще произошло:
Apple удалила из App Store приложения, устанавливавшие корневые сертификаты, что позволяло им перехватывать, отслеживать или модифицировать данные, передающиеся по защищенному соединению. Например, для блокировки рекламы или чего похуже. Я так понимаю, что и новые приложения с таким функционалом теперь загружать нельзя. А почему раньше было можно?
В Apple говорят, что вычистили из App Store вредоносные приложения, но какие именно — не говорят: https://t.co/oT90olHNkQ
Европейское агентство по авиационной безопасности рассказало об уязвимости в системе ACARS, использующейся для передачи данных между самолетом и наземной станцией. В общем-то, изначально было ясно, что в системе без какой-либо верификации пакетов отправить поддельное сообщение несложно.
Найденные в адресно-отчетной системе авиационной связи (ACARS) уязвимости позволят хакать самолеты: https://t.co/3eAhVx7ROV
Порулить самолетом не получится, но отправить сообщение, которое введет в заблуждение пилотов, можно. Об уязвимости ACARS исследователи говорили (документами в формате PDF) еще в 2013 году, но то были ИБ-специалисты, а тут непосредственно отвечающий за безопасность надзорный орган. А это хорошие новости.
Древности:
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страница 70.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.