Опасный алгоритм SHA-1 убирают из библиотек SSH
Сложность атак на SHA-1. Стоимость указана из расчёта стоимости аренды одного GTX 1060 в 35 долларов/месяц
Намного позже всех остальных, но разработчики библиотек для SSH приняли решение наконец-то отключить по умолчанию устаревшую криптофункцию SHA-1. Сегодня подбор серверного ключа аутентификации SHA-1, то есть коллизия с выбранным префиксом, на арендованном кластере GPU обойдётся в $45 тыс., как указано в таблице вверху. Это делает атаку доступной не только для государственных спецслужб, но и для коммерческих клиентов.
Об отключении 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, чтобы никому даже не пришлось конвертировать свои репозитории.
Для чего нужны хеши файла MD5, SHA-1 и SHA-256 – как проверять хеш
Иногда Вы можете встретить упоминание MD5, SHA-1 или SHA-256 хешей, отображаемых вместе с вашими, но, на самом деле, не знаете, что они означают. Эти, казалось бы, случайные строки текста позволяют Вам проверить, что файлы, которые вы загрузили, не были повреждены или подделаны.
Как используют хеши для проверки данных
Хэши являются результатом работы криптографических алгоритмов, и представляют собой строку символов. Часто эти строки имеют фиксированную длину, независимо от размера входных данных.
Взгляните на диаграмму, и вы увидите, что хеш «Fox» и «The red fox jumps over the blue dog» имеет одинаковую длину. Теперь сравните второй пример на графике с третьим, четвертым и пятым. Вы увидите, что, несмотря на незначительные изменения во входных данных, хеши сильно отличаются друг от друга. Даже если кто-то изменит очень маленький фрагмент входных данных, хэш будет резко меняться.
MD5, SHA-1 и SHA-256 – это разные алгоритмы хеш-функции. Создатели программного обеспечения часто указывают хеш для загружаемых файлов.
Таким образом, Вы можете загрузить файл, а затем сравнить опубликованный с рассчитанным для загруженного файла, чтобы подтвердить, что Вы получили оригинальный файл, и что он не был поврежден во время процесса загрузки или подделан злонамеренно.
Как мы видели выше, даже небольшое изменение в файле резко изменит хэш.
Они также могут быть полезны, если файл получен из неофициального источника, и вы хотите проверить, что это «законно». Допустим, у Вас есть Linux.iso-файл, который вы откуда-то получили, и вы хотите убедиться, что он оригинальный. Вы можете посмотреть хеш этого ISO-файла в интернете на веб-сайте дистрибутивов Linux. Затем рассчитать хеш-функцию на вашем компьютере и убедиться, что результат соответствует хеш-значению, которое вы ожидаете от него. Это подтверждает, что у вас тот же файл, который предлагается для загрузки на официальном веб-сайте дистрибутива Linux.
Сравнение хеша в любой операционной системе
Имея это в виду, давайте посмотрим, как проверить хеш файла, который вы загрузили, и сравнить его с тем, который должен быть. Вот методы для Windows, macOS и Linux. Хеши всегда будут идентичны, если вы используете одну и ту же функцию хеширования в одном файле. Не имеет значения, какую операционную систему Вы используете.
Хэш файла в Windows
Этот процесс возможен без какого-либо стороннего программного обеспечения на Windows, благодаря PowerShell.
Чтобы начать работу, откройте окно PowerShell, запустив ярлык Windows PowerShell из меню Пуск .
Выполните следующую команду, заменив "C:\path\to\file.iso" путём к любому файлу, для которого вы хотите просмотреть хеш:
Для создания хеша файла потребуется некоторое время, в зависимости от размера файла, используемого алгоритма и скорости диска, на котором находится файл.
По умолчанию команда покажет хеш SHA-256 для файла. Однако, можно указать алгоритм хеширования, который необходимо использовать, если вам нужен хэш MD5, SHA-1 или другой тип.
Выполните одну из следующих команд, чтобы задать другой алгоритм хэширования:
Get-FileHash C:\path\to\file.iso -Algorithm MD5
Get-FileHash C:\path\to\file.iso -Algorithm SHA1
Get-FileHash C:\path\to\file.iso -Algorithm SHA256
Get-FileHash C:\path\to\file.iso -Algorithm SHA384
Get-FileHash C:\path\to\file.iso -Algorithm SHA512
Get-FileHash C:\path\to\file.iso -Algorithm MACTripleDES
Get-FileHash C:\path\to\file.iso -Algorithm RIPEMD160
Сравните результат хеш-функций с ожидаемым результатом. Если это то же значение, файл не был поврежден, подделан или иным образом изменен от исходного.
Хэш файла на macOS
macOS содержит команды для просмотра различных типов хэшей. Для доступа к ним запустите окно терминала. Вы найдете его в Finder → Приложения → Утилиты → Терминал.
Команда md5 показывает MD5-хеш файла:
Команда shasum показывает хеша SHA-1 по умолчанию. Это означает, что следующие команды идентичны:
shasum -a 1 /path/to/file
Чтобы отобразить хеш файла SHA-256, выполните следующую команду:
shasum -a 256 /path/to/file
Хэш файла в Linux
В Linux обратитесь к терминалу и выполните одну из следующих команд для просмотра хеша файла, в зависимости от типа хеша, который вы хотите посмотреть:
Хэши с криптографической подписью
Хотя хэши могут помочь вам подтвердить, что файл не был подделан, здесь остаётся возможность для атаки. Злоумышленник может получить контроль веб-сайтом с дистрибутивом Linux и изменить хеш-коды, которые отображаются на нём, или злоумышленник может изменять веб-страницу во время передачи информации, если доступ происходит по протоколу http, вместо зашифрованного протокола https.
Вот почему современные дистрибутивы Linux часто предоставляют больше, чем хеши, перечисленные на веб-страницах. Они криптографически подписывают эти хеши, чтобы помочь защититься от злоумышленников, которые могут попытаться изменить хеши. Вы можете проверить криптографическую подпись, чтобы убедиться, что хеш действительно относится к дистрибутиву Linux. Проверка криптографической подписи хеша – более сложный процесс, выходящий за рамки представленной статьи.
Чудеса хеширования
Криптографические хеш-функции — незаменимый и повсеместно распространенный инструмент, используемый для выполнения целого ряда задач, включая аутентификацию, защиту файлов и даже обнаружение зловредного ПО. Как они работают и где применяются?
Криптографические хеш-функции — незаменимый и повсеместно распространенный инструмент, используемый для выполнения целого ряда задач, включая аутентификацию, проверку целостности данных, защиту файлов и даже обнаружение зловредного ПО. Существует масса алгоритмов хеширования, отличающихся криптостойкостью, сложностью, разрядностью и другими свойствами. Считается, что идея хеширования принадлежит сотруднику IBM, появилась около 50 лет назад и с тех пор не претерпела принципиальных изменений. Зато в наши дни хеширование обрело массу новых свойств и используется в очень многих областях информационных технологий.
Что такое хеш?
Если коротко, то криптографическая хеш-функция, чаще называемая просто хешем, — это математический алгоритм, преобразовывающий произвольный массив данных в состоящую из букв и цифр строку фиксированной длины. Причем при условии использования того же типа хеша длина эта будет оставаться неизменной, вне зависимости от объема вводных данных. Криптостойкой хеш-функция может быть только в том случае, если выполняются главные требования: стойкость к восстановлению хешируемых данных и стойкость к коллизиям, то есть образованию из двух разных массивов данных двух одинаковых значений хеша. Интересно, что под данные требования формально не подпадает ни один из существующих алгоритмов, поскольку нахождение обратного хешу значения — вопрос лишь вычислительных мощностей. По факту же в случае с некоторыми особо продвинутыми алгоритмами этот процесс может занимать чудовищно много времени.
Как работает хеш?
Например, мое имя — Brian — после преобразования хеш-функцией SHA-1 (одной из самых распространенных наряду с MD5 и SHA-2) при помощи онлайн-генератора будет выглядеть так: 75c450c3f963befb912ee79f0b63e563652780f0. Как вам скажет, наверное, любой другой Брайан, данное имя нередко пишут с ошибкой, что в итоге превращает его в слово brain (мозг). Это настолько частая опечатка, что однажды я даже получил настоящие водительские права, на которых вместо моего имени красовалось Brain Donohue. Впрочем, это уже другая история. Так вот, если снова воспользоваться алгоритмом SHA-1, то слово Brain трансформируется в строку 97fb724268c2de1e6432d3816239463a6aaf8450. Как видите, результаты значительно отличаются друг от друга, даже несмотря на то, что разница между моим именем и названием органа центральной нервной системы заключается лишь в последовательности написания двух гласных. Более того, если я преобразую тем же алгоритмом собственное имя, но написанное уже со строчной буквы, то результат все равно не будет иметь ничего общего с двумя предыдущими: 760e7dab2836853c63805033e514668301fa9c47.
Впрочем, кое-что общее у них все же есть: каждая строка имеет длину ровно 40 символов. Казалось бы, ничего удивительного, ведь все введенные мною слова также имели одинаковую длину — 5 букв. Однако если вы захешируете весь предыдущий абзац целиком, то все равно получите последовательность, состоящую ровно из 40 символов: c5e7346089419bb4ab47aaa61ef3755d122826e2. То есть 1128 символов, включая пробелы, были ужаты до строки той же длины, что и пятибуквенное слово. То же самое произойдет даже с полным собранием сочинений Уильяма Шекспира: на выходе вы получите строку из 40 букв и цифр. При всем этом не может существовать двух разных массивов данных, которые преобразовывались бы в одинаковый хеш.
Вот как это выглядит, если изобразить все вышесказанное в виде схемы:
Для чего используется хеш?
Отличный вопрос. Однако ответ не так прост, поскольку криптохеши используются для огромного количества вещей.
Для нас с вами, простых пользователей, наиболее распространенная область применения хеширования — хранение паролей. К примеру, если вы забыли пароль к какому-либо онлайн-сервису, скорее всего, придется воспользоваться функцией восстановления пароля. В этом случае вы, впрочем, не получите свой старый пароль, поскольку онлайн-сервис на самом деле не хранит пользовательские пароли в виде обычного текста. Вместо этого он хранит их в виде хеш-значений. То есть даже сам сервис не может знать, как в действительности выглядит ваш пароль. Исключение составляют только те случаи, когда пароль очень прост и его хеш-значение широко известно в кругах взломщиков. Таким образом, если вы, воспользовавшись функцией восстановления, вдруг получили старый пароль в открытом виде, то можете быть уверены: используемый вами сервис не хеширует пользовательские пароли, что очень плохо.
Вы даже можете провести простой эксперимент: попробуйте при помощи специального сайта произвести преобразование какого-нибудь простого пароля вроде «123456» или «password» из их хеш-значений (созданных алгоритмом MD5) обратно в текст. Вероятность того, что в базе хешей найдутся данные о введенных вами простых паролях, очень высока. В моем случае хеши слов «brain» (8b373710bcf876edd91f281e50ed58ab) и «Brian» (4d236810821e8e83a025f2a83ea31820) успешно распознались, а вот хеш предыдущего абзаца — нет. Отличный пример, как раз для тех, кто все еще использует простые пароли.
Еще один пример, покруче. Не так давно по тематическим сайтам прокатилась новость о том, что популярный облачный сервис Dropbox заблокировал одного из своих пользователей за распространение контента, защищенного авторскими правами. Герой истории тут же написал об этом в твиттере, запустив волну негодования среди пользователей сервиса, ринувшихся обвинять Dropbox в том, что он якобы позволяет себе просматривать содержимое клиентских аккаунтов, хотя не имеет права этого делать.
Впрочем, необходимости в этом все равно не было. Дело в том, что владелец защищенного копирайтом контента имел на руках хеш-коды определенных аудио- и видеофайлов, запрещенных к распространению, и занес их в список блокируемых хешей. Когда пользователь предпринял попытку незаконно распространить некий контент, автоматические сканеры Dropbox засекли файлы, чьи хеши оказались в пресловутом списке, и заблокировали возможность их распространения.
Где еще можно использовать хеш-функции помимо систем хранения паролей и защиты медиафайлов? На самом деле задач, где используется хеширование, гораздо больше, чем я знаю и тем более могу описать в одной статье. Однако есть одна особенная область применения хешей, особо близкая нам как сотрудникам «Лаборатории Касперского»: хеширование широко используется для детектирования зловредных программ защитным ПО, в том числе и тем, что выпускается нашей компанией.
Как при помощи хеша ловить вирусы?
Примерно так же, как звукозаписывающие лейблы и кинопрокатные компании защищают свой контент, сообщество создает списки зловредов (многие из них доступны публично), а точнее, списки их хешей. Причем это может быть хеш не всего зловреда целиком, а лишь какого-либо его специфического и хорошо узнаваемого компонента. С одной стороны, это позволяет пользователю, обнаружившему подозрительный файл, тут же внести его хеш-код в одну из подобных открытых баз данных и проверить, не является ли файл вредоносным. С другой — то же самое может сделать и антивирусная программа, чей «движок» использует данный метод детектирования наряду с другими, более сложными.
Криптографические хеш-функции также могут использоваться для защиты от фальсификации передаваемой информации. Иными словами, вы можете удостовериться в том, что файл по пути куда-либо не претерпел никаких изменений, сравнив его хеши, снятые непосредственно до отправки и сразу после получения. Если данные были изменены даже всего на 1 байт, хеш-коды будут отличаться, как мы уже убедились в самом начале статьи. Недостаток такого подхода лишь в том, что криптографическое хеширование требует больше вычислительных мощностей или времени на вычисление, чем алгоритмы с отсутствием криптостойкости. Зато они в разы надежнее.
Кстати, в повседневной жизни мы, сами того не подозревая, иногда пользуемся простейшими хешами. Например, представьте, что вы совершаете переезд и упаковали все вещи по коробкам и ящикам. Погрузив их в грузовик, вы фиксируете количество багажных мест (то есть, по сути, количество коробок) и запоминаете это значение. По окончании выгрузки на новом месте, вместо того чтобы проверять наличие каждой коробки по списку, достаточно будет просто пересчитать их и сравнить получившееся значение с тем, что вы запомнили раньше. Если значения совпали, значит, ни одна коробка не потерялась.