загруженный файл имеет неправильный sha1 хеш что делать
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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Решение проблемы ошибки хеша торрента
Ошибки хеша во время пользования торрент-клиентом возникают довольно редко, зато почти всегда в самый неподходящий момент. Например, вы нашли какой-то интересный фильм или программу, которая в чём-то уникальна и не слишком распространена на просторах интернета. Открываете торрент-клиент, ставите на закачку, причём скачивается файл, как по закону подлости, с единственного источника, но не тут-то было. Закачка светится красным цветом и появляется комментарий «Отказано в доступе (Hash)».
Как решить ошибку закачки торрента «Отказано в доступе (Hash)».
В итоге закачка прервана, другие источники отсутствуют, а устранить досадную проблему без определённых знаний не выйдет. Однако не стоит отчаиваться — ещё не всё потеряно! Сейчас мы подробно изучим причины сбоя и вместе решим эту задачу.
Хеширование данных. Суть ошибки
Пиринговые сети, которые используют торрент-клиенты, проверяют закачиваемые файлы на наличие повреждений с помощью хеширования. Суть состоит в том, что если искомый файл имеет дефекты со стороны источника (файл повреждён или изменены какие-то его параметры), то обязательно возникает ошибка хеша.
Как правило, такое происходит при скачивании музыки. Владелец торрента регенерирует сид, а затем по незнанию вносит какие-то изменения в раздачу. При хешировании определяется сумма параметров сида и, если эта сумма в процессе закачки не совпадает с первоначальной, появляется ошибка хеша.
Как понять, что у вас ошибка хеша
Для ошибки хеша можно выделить следующие характерные признаки:
Правильная работа клиента выглядит так:
Как исправить ошибку хеша
С принципом хеширования и особенностями работы торрент-клиента мы уже познакомились в начале статьи. Для поиска методов решения придётся немного углубиться в эту тему.
Итак, ошибка хеша возникает, когда владелец торрента внёс изменения при активной раздаче. Программа торрентов получает информацию от источника и считает хеш-сумму. Если сумма не равна первоначальной, то закачка последнего сектора файла повторяется. Когда один и тот же сектор закачивается определённое количество раз, а сумма всё так же отличается от первоначальной, этот источник отбрасывается. Если другие сиды отсутствуют или для вас важно скачать торрент именно с этого источника, то можно решить проблему отправлением личного сообщения человеку, которому принадлежат файлы с просьбой перезалить раздачу.
Второй метод, скорее, относится к рекомендациям и является логическим продолжением первого. Есть программы для торрентов, которые не отбрасывают некорректные файлы (такие как Transmission и BitTornado). Всё бы ничего, но, как сказано выше, закачка одного и того же сектора повторяется бесчисленное множество раз, из-за чего объём скачанной информации непрерывно растёт, а это может негативно влиять на работоспособность программы и операционной системы в целом. Чтобы повысить надёжность, мы советуем не использовать проблемные программы.
Чтобы исправить ошибку хеша, повторите хеширование раздачи. Для этого выберите из списка необходимую закачу, кликните правой клавишей мыши и выберите опцию «Обновить хеш».
Далее, снова кликните правой кнопкой мыши на загрузке и выберите пункт «Сброс банов» — эта опция снимет блокировку с проблемных источников. Если проблемных раздач несколько, повторите процедуру для каждой из них.
Делаем выводы
Ошибка при хешировании файлов в торрент-клиенте возникает по вине владельца файла. Если эта ошибка случайная, то вам поможет обновление хеша и разблокировка проблемных источников. Если же вам не повезло и перехеширование не дало результатов, имеет смысл обратиться к владельцу торрента с просьбой предоставить корректную раздачу. Уместно будет отметить, что если вы сами создаёте раздачу, то не нужно вносить изменения в теги — это доставит неудобства и личерам и, вероятно, вам самим.
Для чего нужны хеши файла 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.
Выполните следующую команду, заменив «C:\path\to\file.iso» путём к любому файлу, для которого вы хотите просмотреть хеш:
Для создания хеша файла потребуется некоторое время, в зависимости от размера файла, используемого алгоритма и скорости диска, на котором находится файл.
По умолчанию команда покажет хеш SHA-256 для файла. Однако, можно указать алгоритм хеширования, который необходимо использовать, если вам нужен хэш MD5, SHA-1 или другой тип.
Выполните одну из следующих команд, чтобы задать другой алгоритм хэширования:
Сравните результат хеш-функций с ожидаемым результатом. Если это то же значение, файл не был поврежден, подделан или иным образом изменен от исходного.
Хэш файла на macOS
macOS содержит команды для просмотра различных типов хэшей. Для доступа к ним запустите окно терминала. Вы найдете его в Finder → Приложения → Утилиты → Терминал.
Команда md5 показывает MD5-хеш файла:
Команда shasum показывает хеша SHA-1 по умолчанию. Это означает, что следующие команды идентичны:
Чтобы отобразить хеш файла SHA-256, выполните следующую команду:
Хэш файла в Linux
В Linux обратитесь к терминалу и выполните одну из следующих команд для просмотра хеша файла, в зависимости от типа хеша, который вы хотите посмотреть:
Хэши с криптографической подписью
Хотя хэши могут помочь вам подтвердить, что файл не был подделан, здесь остаётся возможность для атаки. Злоумышленник может получить контроль веб-сайтом с дистрибутивом Linux и изменить хеш-коды, которые отображаются на нём, или злоумышленник может изменять веб-страницу во время передачи информации, если доступ происходит по протоколу http, вместо зашифрованного протокола https.
Вот почему современные дистрибутивы Linux часто предоставляют больше, чем хеши, перечисленные на веб-страницах. Они криптографически подписывают эти хеши, чтобы помочь защититься от злоумышленников, которые могут попытаться изменить хеши. Вы можете проверить криптографическую подпись, чтобы убедиться, что хеш действительно относится к дистрибутиву Linux. Проверка криптографической подписи хеша – более сложный процесс, выходящий за рамки представленной статьи.