Sha1 0x14196fba что это

Что такое 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 для любой группы текста, символов и/или чисел.

Источник

Sha1 0x14196fba что это

Содержание

История [ ]

В 1993 году NSA совместно с NIST разработали алгоритм безопасного хеширования (сейчас известный как SHA-0) (опубликован в документе FIPS PUB 180) для стандарта безопасного хеширования. Однако вскоре NSA отозвало данную версию, сославшись на обнаруженную ими ошибку, которая так и не была раскрыта. И заменило его исправленной версией, опубликованной в 1995 году в документе FIPS PUB 180-1. Эта версия и считается тем, что называют SHA-1. Много спустя, на конференции CRYPTO в 1998 году два французских исследователя представили атаку на алгоритм SHA-0, которая не работала на алгоритме SHA-1 Возможно, это и была ошибка, открытая NSA.

Описание алгоритма [ ]

Одна итерация алгоритма SHA1

SHA-1 реализует однонаправленную хеш-функцию, простроенную на идее функции сжатия. Входами функции сжатия являются блок сообщения длиной 512 бит и выход предыдущего блока сообщения. Выход представляет собой значение всех хеш-блоков до этого момента. Иными словами хеш блока равен . Хеш-значением всего сообщения является выход последнего блока.

Исходное сообщение разбивается на блоки по 512 бит в каждом. Последний блок дополняется до длины, кратной 512 бит. Сначала добавляется 1 а потом нули, чтобы длина блока стала равной 512 — 64 бит. В оставшиеся 64 бита записывается длина исходного сообщения. Дополнение последнего блока осуществляется всегда, даже если сообщение уже имеет нужную длину. Таким образом, число добавляемых битов находится в диапазоне от 1 до 512.

Инициализируются пять 32-битовых переменных.

Определяются четыре нелинейные операции и четыре константы.

	= 0x5A827999	0≤t≤19
	= 0x6ED9EBA1	20≤t≤39
	= 0x8F1BBCDC	40≤t≤59
	= 0xCA62C1D6	60≤t≤79

Главный цикл [ ]

Главный цикл итеративно обрабатывает каждый 512-битный блок. Итерация состоит из четырех этапов по двадцать операций в каждом. Блок сообщения преобразуется из 16 32-битовых слов в 80 32-битовых слов по следующему правилу:

здесь Псевдокод SHA-1 [ ]

Псевдокод алгоритма SHA-1 следущий:

Вместо оригинальной формулировки FIPS PUB 180-1 приведены следующие эквивалентные выражения и могут быть использованы на компьютере f в главном цикле:

Примеры [ ]

Ниже приведены примеры хешей SHA-1. Для всех сообщений подразумевается использование кодировки ASCII.

Хеш панграммы на русском:

Хеш панграммы на английском:

Небольшое изменение исходного текста (одна буква в верхнем регистре) приводит к сильному изменению самого хеша. Это происходит вследствие лавинного эффекта.

Даже для пустой строки вычисляется нетривиальное хеш-значение.

Криптоанализ [ ]

Криптоанализ хеш-функций направлен на исследование уязвимости к различного вида атакам. Основные из них:

В январе 2005 года Rijmen and Oswald опубликовали сообщение об атаке на усеченную версию SHA-1 (53 раунда вместо 80), которая позволяет находить коллизии меньше, чем за 2 80 операций.

О методе авторы пишут:

Мы представляем набор методик и соответствующих технологий, которые могут быть использованы для устранения главных препятствий в нахождении коллизий в SHA-1. Сначала мы ищем близкие к коллизии дифференциальные пути, которые имеют небольшой «вес Хамминга» в «векторе помех», где каждый 1-бит представляет 6-шаговую локальную коллизию. Потом, мы соответствующим образом корректируем дифференциальный путь из первого раунда до другого приемлимого дифференциального пути, чтобы избежать неприемлимых последовательных коллизий и усеченных коллизий. В конце концов мы преобразуем два одноблоковых близких к коллизии дифференциальных пути в один двухблоковый коллизионный путь с удвоенной вычислительной сложностью. [1]

We introduce a set of strategies and corresponding techniques that can be used to remove some major obstacles in collision search for SHA-1. Firstly, we look for a near-collision differential path which has low Hamming weight in the «disturbance vector» where each 1-bit represents a 6-step local collision. Secondly, we suitably adjust the differential path in the first round to another possible differential path so as o avoid impossible consecutive local collisions and truncated local collisions. Thirdly, we transform two one-block near-collision differential paths into a twoblock collision differential path with twice the search complexity.

Также они заявляют:

В особенности, наш анализ основан на оригинальных дифференциальных атаках на SHA-0, близких к коллизиям атаках на SHA-0, мультиблокой методике, а также методике модификации исходного сообщения, использованной при атаке на MD5. Взлом SHA-1 не был бы возможным без этих мощных аналитических методологий.

In particular, our analysis is built upon the original differential attack on SHA-0, the near collision attack on SHA-0, the multi-block collision techniques, as well as the message modification techniques used in the collision search attacks on MD5.

В этой же статье авторы опубликовали атаку на усеченный SHA-1 (58 раундов), которая позволяет находить коллизии за 2 33 операций.

В августе 2005 года на CRYPTO 2005 эти же специалисты представили улучшенную версию атаки на полноценный SHA-1, с вычислительной сложностью в 2 63 операций. В декабре 2007 года детали этого улучшения были проверены Мартином Кохраном.

Хотя теоретически SHA-1 считается взломанным (количество вычислительных операций сокращено в 2 80-63 = 131 000 раз), на практике подобный взлом неосуществим, так как займет пять миллиардов лет.

Ввиду того, что теоретические атаки на SHA-1 оказались успешными NIST планирует полностью отказаться от использования SHA-1 в цифровых подписях. [4]

Сравнение SHA-1 с другими алгоритмами [ ]

Сравнение с MD5 [ ]

И MD5, и SHA-1 являются, по сути, улучшенными продолжениями MD4.

Брюс Шнайер делает следующий вывод : « SHA-1 — это MD4 с добавлением расширяющего преобразования, дополнительного этапа и улучшенным лавинным эффектом. MD5 — это MD4 с улучшенным битовым хешированием, дополнительным этапом и улучшенным лавинным эффектом.»

Сравнение с ГОСТ Р 34.11-94 [ ]

Ряд отличительных особенностей ГОСТ Р 34.11-94 :

Сравнение с другими SHA [ ]

В таблице, «промежуточный размер хеша» означает «размер внутренней хеш-суммы» после каждой итерации.

Использование [ ]

SHA-1 является наиболее распространенным из всего семейства SHA и применяется в различных широко распространенных криптографических приложениях и алгоритмах.

SHA-1 используется в следующих приложениях:

Примечания [ ]

Ссылки [ ]

Литература [ ]

cs:Secure Hash Algorithm da:SHA de:Secure Hash Algorithm en:SHA hash functions es:SHA fi:SHA fr:SHA-1 he:SHA hr:SHA-1 it:Secure Hash Algorithm ja:SHA ko:SHA lt:SHA nl:SHA-familie pl:SHA-1 pt:SHA1 sk:Secure Hash Algorithm sr:SHA vi:SHA zh:SHA 家族

Источник

Опасный алгоритм SHA-1 убирают из библиотек SSH

Сложность атак на SHA-1. Стоимость указана из расчёта стоимости аренды одного GTX 1060 в 35 долларов/месяц

Об отключении SHA-1 по умолчанию одновременно объявили разработчики опенсорсных библиотек OpenSSH (release notes) и libssh (изменение кода).

Алгоритм SHA (Secure Hash Algorithm) разработан АНБ совместно с NIST. Первую версию SHA-0 представили в 1993 году, но вскоре АНБ отозвало данную версию, сославшись на обнаруженную ими ошибку, которая так и не была раскрыта.

Исправленную версию АНБ опубликовала в 1995 году, она получила название SHA-1.

Криптографическая хеш-функция SHA-1 (Secure Hash Algorithm 1) генерирует строку из 160 бит, которая называется хэш-дайджестом. Теоретически, дайджесты должны быть уникальными для каждого файла, сообщения или другого входного сигнала, подаваемого в функцию. В качестве входного значения SHA-1 принимает сообщение не более бит, то есть примерно 2 эксабайта.

Понятно, что область значений дайджеста меньше области входных значений. Но на практике дайджест-коллизии должны быть неосуществимы, учитывая возможности производительности имеющихся вычислительных ресурсов. К сожалению, SHA-1 уже не соответствует этому критерию.

В 2017 году сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый способ генерации коллизий для SHA-1.

Они опубликовали и доказательство: два документа PDF с разным содержимым, но одинаковыми цифровыми подписями SHA-1.

На сайте shattered.it можно проверить любой файл на предмет того, входит ли он в пространство возможных коллизий. То есть можно ли подобрать другой набор данных (файл) с таким же хешем. Вектор атаки здесь понятен: злоумышленник может подменить «хороший» файл своим экземпляром с закладкой, вредоносным макросом или загрузчиком трояна. И этот «плохой» файл будет иметь такой же хеш или цифровую подпись.

В последние годы множество программ и сервисов перестали использовать SHA-1 после того, как исследователи продемонстрировали практические способы подделки цифровых подписей, использующих SHA-1. Единодушное мнение экспертов состоит в том, что этот алгоритм теперь не безопасен почти во всех контекстах безопасности.

Компания Google давно выразила своё недоверие SHA-1, особенно в качестве использования этой функции для подписи сертификатов TLS. Ещё в 2014 году группа разработчиков Chrome объявила о постепенном отказе от использования SHA-1.

В 2017 году исследователи использовали инфраструктуру Google, чтобы произвести вычисления и проверить теоретические выкладки, сколько займёт поиск коллизии. Разработчики говорят, что это было одно из самых крупных вычислений, которые когда-либо проводила компания Google. В общей сложности было произведено девять квинтиллионов вычислений SHA-1 (9 223 372 036 854 775 808), что потребовало 6500 процессорных лет на первой фазе и 110 лет GPU на второй фазе атаки.

Блоки сообщений с одинаковым хешем SHA-1

В 2019 году исследователи Гаэтан Лоран и Томас Пейрин продемонстрировали атаку на отыскание коллизии с выбранным префиксом (chosen-prefix), которая имеет практический смысл для подбора конкретных ключей шифрования PGP/GnuPG. Наконец, в январе 2020 года авторам удалось на порядок оптимизировать атаку и снизить её теоретическую стоимость до коммерчески приемлемой цены (см. таблицу выше и pdf). Для демонстрации они создали пару разных ключей PGP/GnuPG с одинаковыми сертификатами SHA-1.

В качестве защиты от атаки на отыскание коллизий SHA-1 рекомендуется перейти на более качественные криптографические хеш-функции SHA-256 и SHA-3.

На это исследование от января 2020 года ссылаются разработчики OpenSSH, которые написали в примечаниях к последнему релизу: «Теперь можно выполнять атаки с выбранным префиксом по алгоритму SHA-1 менее чем за 50 тысяч долларов США. По этой причине в ближайшем будущем мы будем отключать алгоритм подписи открытого ключа «ssh-rsa» по умолчанию. К сожалению, этот алгоритм всё еще широко используется. Несмотря на существование лучших альтернатив, он долгое время оставался единственным алгоритмом подписи открытого ключа, заданным оригинальными SSH RFC».

В числе лучших альтернатив разработчики OpenSSH называют алгоритмы RFC8332 RSA SHA-2 (поддерживается с версии OpenSSH 7.2 и уже используется по умолчанию, если сервер и клиент его поддерживают), ssh-ed25519 (поддерживается с версии 6.5) и RFC5656 ECDSA (с версии 5.7).

Для проверки, что сервер при генерации открытого ключа для аутентификации использует слабый алгоритм SHA-1, попробуйте подключиться к нему после удаления алгоритма ssh-rsa из списка разрешённых в ssh(1):

Если верификация не проходит и другие типа ключей недоступны, то серверное программное обеспечение следует обновить.

В будущих версиях OpenSSH по умолчанию будет включена опция UpdateHostKeys, при которой клиент будет автоматически переходить на лучшие алгоритмы. Её можно активировать вручную.

Судя по всему, полное отключение SHA-1 займёт немало времени. Гаэтан Лоран из Национального института исследований в информатике и автоматике (Франция), один из соавторов январского исследования, не ожидает, что разработчики OpenSSH быстро это сделают: «Когда они полностью отключат SHA-1, будет невозможно подключиться с новой версии OpenSSH к устройству со старым SSH-сервером, — пишет он. — Вероятно, перед этим они предпримут ряд постепенных шагов (с громкими предупреждениями). С другой стороны, во встроенных системах с SSH, которые не обновлялись в течение многих лет, вероятно, много проблем с безопасностью, так что, возможно, не так уж плохо будет нарушить их работу… Во всяком случае, я вполне доволен этим ходом, это именно то, чего мы хотели добиться :-)».

После того как OpenSSH и libssh объявили о планах отключения SHA-1, список пользователей SHA-1 стал короче, но не исчез. Функция всё еще поддерживается в последних версиях библиотеки OpenSSL, которую многие веб-сайты и интернет-службы используют для реализации HTTPS и других протоколов шифрования. Последняя версия компилятора GNU Collection, выпущенная ранее в этом месяце, подписана цифровой подписью с хешем SHA-1.

Линус Торвальдс сказал, что в репозиториях Git коллизии хеша не представляют угрозы безопасности. Он пояснил, что сть большая разница между использованием криптографического хеша для цифровых подписей в системах шифрования и для генерации «идентификации контента» в системе вроде Git. Когда все данные лежат в открытом доступе, то реальная атака практически невозможна. Авторы научной работы приводят пример атаки на документы с идентичным префиксом. Эта атака успешна, потому что сам префикс «закрыт» внутри документа, как блоб. Если же у нас открытые исходники в репозитории, то это совсем другое дело. Вряд ли можно сделать такой префикс из исходного кода (только из блоба). Другими словами, для создания идентичного префикса и последующей генерации веток кода с одинаковыми хешами SHA-1 придётся внедрить в код некие случайные данные, что сразу же будет замечено. Линус говорит, что есть места, куда можно спрятать данные, но git fsck уже вылавливает такие фокусы. Тем не менее, у Линуса есть план, как уйти от использования 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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Источник