Как найти хэш пароля

Обновлено: 01.07.2024

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

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

Что такое хэш и как его взломать?

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

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

Хотя хэши лучше, чем хранить пароли в открытом виде, их все же можно взломать, если использовать хорошее правило или список паролей с помощью Hashcat или другой программы для взлома. Но вы не можете просто указать Hashcat на любой хэш и ожидать, что он сработает. Представьте себе Hashcat как дрель с множеством бит разного размера. Для каждого типа хэша, который мы хотим взломать, нам нужно прикрепить к Hashcat другой «бит», установив для него правильный режим для атаки целевого хэша.

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

Можете ли вы с первого взгляда определить, какой из этих двух распространенных хэшей какой?

Несмотря на то, что вы, возможно, уже видели оба хэша, может быть не сразу понятно, какой из этих хэшей является MD5, а какой — SHA1. Это может стать еще более запутанным с похожими типами хэшей, которые имеют разные номера режимов в Hashcat. В случае с приведенными выше хэшами большая разница, что есть что.

При использовании Hashcat для взлома этого хеша мы должны установить параметр -m в правильный режим. Чтобы взломать хеш MD5, мы использовали бы номер режима 0, чтобы получить хеш.

Здесь мы обнаружили, что хэш был создан со словом "hashcat", правильно идентифицировав его как MD5 и используя хороший список слов.

Какие хэши поддерживаются?

В настоящее время можно идентифицировать большое количество хэшей, которые Hashcat способен взломать. В репозитории GitHub для hash-identifier список поддерживаемых хэшей довольно обширен.

Что вам понадобится

Чтобы следовать этому руководству, на вашем компьютере должен быть установлен Python3 (он кроссплатформенный), поэтому установите его, прежде чем продолжить, если у вас его еще нет. Вам также понадобится Hashcat, который можно загрузить, запустив apt install hashcat после обновления компьютера с помощью apt update и apt upgrade.

Если вы хотите сгенерировать несколько собственных хэшей для взлома, вы можете сделать это в формате echo -n PLAINTEXT | (ХЭШТИП)сумма. Чтобы создать хэш SHA1 слова «nullbyte», я бы использовал следующую команду.

Шаг 1. Загрузите и установите Hash-Identifier

Установить скрипт Python очень просто. Для начала откройте окно терминала и выполните следующую команду.

Затем перейдите в его каталог с помощью cd hash-identifier и перечислите его содержимое с помощью ls.

Вы должны увидеть файл с именем hash-id.py, который можно запустить с помощью приведенной ниже команды.

Шаг 2. Неизвестные хэши отпечатков пальцев

Чтобы опробовать хеш-идентификатор, мы попытаемся снять отпечатки следующих пяти неизвестных хэшей.

Для начала давайте введем первый в командную строку ожидающего хэш-идентификатора. Как видите, он дает быстрый идентификатор в виде хэша MySQL. Это тот, который мы попытаемся взломать, поэтому мы вернемся к нему позже.

Наш второй хеш, показанный ниже, идентифицируется как хэш SHA256, а также Haval256.

Наш третий хеш идентифицируется как SHA1:

И наш четвертый хеш идентифицируется как SHA512:

Наконец, наш последний хеш определяется как MD5:

Это было легко, но следующим шагом будет атака на эти хэши путем преобразования идентифицированного типа хэша в номер режима Hashcat.

Шаг 3. Найдите режимы хеширования Hashcat

Чтобы найти режим хеширования, мы можем просмотреть исчерпывающий список типов хэшей, поддерживаемых Hashcat, на странице примеров Hashcat. Ниже приведен сокращенный список некоторых наиболее популярных хэшей.

Выше мы видим два примера, которые могут совпадать с нашим первым хешем (7196759210defdc0) из предыдущего шага. На первый взгляд режим 200 "MySQL323" кажется наиболее подходящим, но мы можем убедиться в этом, пропустив пример хэша через hash-identifier.

Это точное совпадение с нашим образцом хеша:

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

Это доказывает, что мы определили правильный номер режима Hashcat, 200, для использования в нашей атаке Hashcat.

Шаг 4. Атакуйте хэш с помощью Hashcat

Как только мы узнаем, какой режим использовать, идентифицируя хэш, мы можем атаковать его с помощью Hashcat. Чтобы это работало, нам нужно создать файл словаря с паролями, который Hashcat затем будет использовать для атаки на хэш. В Интернете есть много доступных списков, таких как RockYou, но в этом случае мы создадим один с именем example.dict, чтобы поместить в него несколько вариантов пароля.

Если вы все еще находитесь в инструменте хэш-идентификатора, сначала нажмите Control-C на клавиатуре. Затем создайте и откройте файл в nano, введя следующее.

После добавления нескольких вариантов пароля, которые включают слово "hashcat" для этого примера, нажмите Control-X для выхода, затем Y и подтвердите имя файла. Теперь мы можем использовать этот файл в качестве нашего списка предположений открытого текста вместе с обнаруженным нами режимом для взлома хеша. Основная формула, которую мы будем использовать, будет выглядеть так:

Когда мы запустим его с нашим хэшем 7196759210defdc0 ("HASH_VALUE") с нашим режимом 200 ("MODE_NUMBER"), результаты должны выглядеть так, как показано ниже. Если у вас более старая система, подобная той, которую я использую в качестве примера, вам может понадобиться использовать с ней команду --force.

Ну вот! Мы получаем вывод 7196759210defdc0:hashcat, что означает, что мы обнаружили, что значение хэша MySQL323 является словом «hashcat», сравнив его со всеми словами в файле example.dict.

Hash-Identifier упрощает отпечатки хэшей

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

Надеюсь, вам понравилось это руководство по снятию отпечатков неизвестных хэшей! Если у вас есть какие-либо вопросы об этом руководстве по взлому и идентификации хэшей или у вас есть комментарий, задайте их ниже или свяжитесь со мной в Твиттере @KodyKinzie.

Хотите начать зарабатывать как белый хакер? Начните свою карьеру хакера с нашим комплектом обучения Premium Ethical Hacking Certification 2020 от нового магазина Null Byte и пройдите более 60 часов обучения у специалистов по кибербезопасности.

Способ хеширования паролей и надежность паролей важны, потому что, если кто-то получит доступ к хешированным паролям, можно перепробовать много-много паролей за удивительно короткий промежуток времени и взломать любой слабый.< /p>

Вопрос, который у меня есть, заключается в том, как злоумышленник получает доступ к хешированным паролям. Если у них есть доступ, например, к файлу /etc/shadow, разве игра уже не окончена? Это просто неверные настройки разрешений? Резервные копии? Другие ошибки? Дело в том, что когда одна система скомпрометирована, пароль оттуда используется для попытки проникнуть в другие системы?

Думаю, в конечном счете мой вопрос сводится к выводу, который я сделал, прочитав эту тему, о неизбежности того, что злоумышленник получит доступ к хэшам. Как это происходит на практике?

Вы также заметите, что чаще всего происходит утечка не паролей операционной системы ( /etc/shadow ), а паролей веб-приложений/служб. Обычно они хранятся в базе данных и поэтому уязвимы для взлома базы данных.

Это не неизбежно, но это не имеет значения. Хорошая схема безопасности предполагает, что все остальные средства защиты не работают, и направлена на поиск способов сохранить защищенный ресурс. Так почему же мы хотим, чтобы алгоритмы хеширования были устойчивы к атакам? Потому что, по предположению, этот алгоритм — последний человек, стоящий на защите защищенного ресурса.

Необходимо помнить одну важную вещь: даже несмотря на то, что многие проблемы, связанные с раскрытием хэшей паролей, могут означать, что игра окончена для взломанного сервера, ценность не обязательно в этом. Взломанный сервер может быть почти бесполезен для хакера, но если эти хэши могут быть взломаны (или если они были открытым текстом и т. д.), то повторное использование пароля означает, что хакер может получить доступ к учетным записям электронной почты, банковским счетам и т. д.< /p>

5 ответов 5

Существует множество способов:

Внедрение SQL
Утечка резервных копий
Недовольные сотрудники сливают их
Любой взлом сервера, позволяющий выполнить код.

Как вы можете видеть, это может произойти многими, многими способами — как упоминает phihag в комментариях, более половины из 10 лучших OWASP могут привести к утечке хэшей, поэтому их нелегко свести в таблицу в сообщении.

Это не означает, что хакеры неизбежно получат хэши, но вы все равно должны использовать хороший алгоритм хэширования, чтобы защитить себя и своих пользователей на всякий случай. Поскольку резервная копия может быть потеряна или ваш сервер может быть взломан без вашего ведома, правильно хешированные пароли должны быть единственным, что позволит вам спать по ночам. Эта стратегия известна как "глубокоэшелонированная защита" или просто "план на худшее".

Я не хочу сказать, что это неважно, просто иногда кажется, что вокруг этого есть какое-то фаталистическое отношение. Я нашел много информации о взломе паролей, но не так много о том, как предотвратить утечку хэшей.

@JimmyJames Причина, по которой вы не найдете никакой конкретной информации о предотвращении утечки паролей, заключается в том, что это допускает практически каждая уязвимость на стороне сервера. Из 10 лучших классов уязвимостей OWASP классы 1, 2, 4, 5, 6 и 9 могут привести к утечке хэшей паролей. Другими словами, более всех усилий по обеспечению безопасности так или иначе противодействуют раскрытию хэшей паролей.

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

Обратите внимание, что в приведенных ниже эксплойтах я не обязательно привожу примеры кражи хэшей (за исключением SQLi), но примеры того, как эти эксплойты могут работать. Злоумышленник может использовать приведенные ниже эксплойты для дальнейшей компрометации системы.

SQL-инъекция

Пример:
а ИЛИ 1=1'; exec sp_msforeachtable "SELECT * FROM?";--

Вы также можете использовать sp_msforeachdb , например:

а'; exec sp_msforeachdb 'ИСПОЛЬЗОВАТЬ ?;exec sp_msforeachTable "SELECT * FROM !","!"';--

Кнопка -- предназначена для комментирования частей оператора SQL, которые могут помешать вашей инъекции. Это только очень простые примеры. Это действительно зависит от формата запроса.

Небезопасная прямая ссылка на объект, ведущая к уязвимости включения локального или удаленного файла.

/etc/passwd%00 (примечание: пароли, конечно, здесь не хранятся; ключом здесь является поиск действительных имен пользователей, когда люди повторно используют пароли, или использование имен пользователей для повышения привилегий)

%00 — это «нулевой ограничитель», который используется для того, чтобы ничего не шло после него, поэтому вы не пытаетесь включить что-то несуществующее, например: /etc/passwd.txt . Это также может быть \000 , \x00 , \z , \u0000 , \0 или \00 в зависимости от используемого вами языка.

Короче говоря, одна или несколько уязвимостей используются для непрямого доступа. Хорошо, теперь, когда вы так выразились, это кажется очевидным.

Я не уверен, что подписан на вас. Пароль не будет храниться в виде обычного текста, если он сделан правильно, даже если все остальное неверно. Это серьезная проблема, поскольку люди повторно используют пароли, и это может позволить им получить доступ к другим веб-сайтам, используя ту же комбинацию имени пользователя и пароля.

@MikeP Я должен был уточнить: /etc/passwd позволяет вам находить имена пользователей, которые затем можно использовать для входа в систему или повышения привилегий. Это небольшая часть процесса, но фундаментальная. Когда пользователи повторно используют пароли в нескольких системах, вам может просто понадобиться найти действительное имя пользователя, если у вас есть действительные пароли. LFI/RFI также можно использовать для выполнения кода, который может предоставлять учетные данные БД, учетные данные AWS и т. д.

Одно дополнение к Марку Баффало:
7. Атака «Человек посередине». Просмотр незашифрованного трафика часто может выявить хэш пароля. В сценарии с передачей хеша системы будут доверять хэшу и паролю и позволят злоумышленнику просто скопировать хеш, не взламывая его.

@Bergi, OP не указывает "много". Однако, если у кого-то есть доступ к способу атаки MitM, он может получить «много».

Да, если вы можете прослушать незашифрованный трафик между базой данных и сервером приложений, который может раскрыть некоторые хэши, я хотел бы, чтобы вы разъяснили это. Но я думаю, что сценарий с передачей хэша, когда вы можете контролировать хэши, будучи митмом, не имеет отношения к этому вопросу.

Единственный по-настоящему безопасный компьютер — это тот, который изолирован от Интернета, выключен, отключен от сети, закопан в бункер на глубине 100 футов под землей, а у единственного входа есть вооруженная охрана. Даже тогда я время от времени проверял бы это.

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

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

Способы возникновения этих атак безграничны. У вас могут быть атаки SQL-инъекций, если вы не смогли очистить свои входные данные. У вас может произойти переполнение буфера, что даст злоумышленнику возможность запустить свой собственный код. У вас может быть ошибка прав доступа, когда вы случайно сделаете файл доступным для чтения людям, когда вы не должны были этого делать. Злоумышленник может получить в свои руки одну из ваших резервных лент из-за неправильного обращения со службой резервного копирования!

Все эти атаки позволяют злоумышленнику закрепиться на вашем компьютере, но не всегда приводят к полному взлому. Возможно, у вас есть chroot для вашего SQL-сервера, так что процесс SQL-сервера буквально не может видеть всю остальную часть компьютера. Однако в таких ситуациях необходимая пользователям информация для входа в систему должна находиться в пределах досягаемости SQL-сервера, иначе она не будет иметь значения. Таким образом, данные для входа обычно скомпрометированы до того, как произойдут другие более гнусные компрометации.

Хешируя пароли, вы снижаете их ценность. Хэш бесполезен для входа в систему. У них должен быть пароль, который хешируется до этого значения. Они могут или не могут позволить себе затраты на взлом хеша. В лучшем случае вам вообще никогда не нужно было об этом беспокоиться, но если вы подписываетесь на подход, предусматривающий всестороннюю безопасность, вы можете быть уверены, что даже успешное вторжение не поставит под угрозу все ваши данные.

PPA поддерживает несколько различных методов получения хэшей паролей для дальнейшей атаки/аудита, как описано ниже.

Существует несколько сторонних инструментов, которые могут создавать файлы дампа с хэшами паролей, например pwdump, pwdump2, pwdump3 и самдамп. Файлы, создаваемые этими инструментами, имеют следующий формат:

Программа PPA может открывать файлы этого типа и считывать из них хэши паролей.

Реестр локального компьютера

Во всех системах, не использующих Active Directory, хэши паролей хранятся в системном реестре, и программа может извлечь их из реестра, даже если они зашифрованы с помощью SYSKEY.

Файлы реестра (SAM, SYSTEM)

Программа может извлекать хэши паролей непосредственно из файлов реестра: SAM и SYSTEM. Вам нужно будет выбрать эти два файла (или только файл SAM, если файл исходит из старой системы NT, которая не использует защиту SYSKEY: в этом случае установите флажок Не использовать SYSKEY). Если SYSKEY был сгенерирован из пароля запуска или сохранен на гибком диске, вам придется указать этот пароль или дискету соответственно. Обратите внимание, что с помощью этой функции вы не можете делать дамп из файлов SAM и SYSTEM, которые используются в данный момент (находятся в папке WINDOWS\SYSTEM32\config), поскольку они заблокированы операционной системой. Однако вы можете сделать копии этих файлов, загрузив альтернативную операционную систему, такую как другая установка Windows или даже DOS (хотя может потребоваться драйвер NTFS, такой как NTFS Reader для DOS или NTFSDOS); другой способ — подключить жесткий диск (где находятся эти файлы) в качестве дополнительного диска к другой рабочей станции Windows.

Память локального компьютера

Если у вас есть права администратора на машине, на которой вы запускаете PPA, вы можете сбрасывать хэши паролей из ее памяти. Этот метод работает независимо от режима SYSKEY и дает хэши для всех пользователей, включая пользователей Active Directory.

Память удаленного компьютера

Этот метод аналогичен предыдущему, но позволяет создавать дамп хэшей с любого удаленного компьютера в вашей локальной сети — сервера или рабочей станции, с Active Directory или без нее. Нажмите кнопку «Обзор» и выберите компьютеры, с которых вы хотите получить хэши. После получения хэшей паролей PPA показывает следующую информацию:

Инструменты

Несколько месяцев назад я участвовал в публичных дебатах о политике паролей с моим коллегой и другом Кевином Митником. Это была жаркая дискуссия, в которой Кевин выступал за гораздо более длинные пароли, чем рекомендуют большинство экспертов, включая меня. Я просто не поверил его аргументам.

Затем он прислал мне электронное письмо, которое, когда я его открыл, отправило Кевину мой хэш пароля Microsoft Windows, который он затем взломал.Это был нокаутирующий удар. Я не знал, что это возможно.

Я был немного смущен, мало того, что я не знал, что это можно сделать, но это было широко известно в течение многих лет. Это означает красные щеки для любого специалиста по компьютерной безопасности, но поскольку я выдаю себя за специалиста по проверке подлинности Windows, это вдвойне смущает. С тех пор я узнал, что большинство специалистов по компьютерной безопасности не знают, что это можно сделать.

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

Говоря более ясно, я могу отправить вам электронное письмо и получить хэш вашего пароля, а затем взломать его до открытого текста.

Как можно получить хэш пароля по электронной почте?

Когда компьютер (через программное обеспечение) пытается подключиться к веб-серверу, он часто по умолчанию пытается подключиться без аутентификации. После одного или нескольких сбоев компьютеру часто предлагается войти в систему, используя текущие активные учетные данные для входа. Компьютеры, поддерживающие встроенную проверку подлинности Windows, могут попытаться автоматически войти в систему, используя учетные данные проверки подлинности Windows пользователя. Пользователь не узнает, что что-то произошло. Если автоматическая аутентификация не удалась, пользователю может быть предложено выполнить вход вручную.

Встроенная автоматическая проверка подлинности Windows – очень востребованная функция единого входа (SSO), особенно для локальных ресурсов и ранее доверенных серверов. Эта функция позволяет пользователям подключаться к веб-серверам по всей корпоративной среде без необходимости отправлять учетные данные для входа каждый раз, когда они хотят подключиться к другому серверу. Большинство современных популярных браузеров поддерживают его в той или иной степени.

В конце 1990-х хакеры-злоумышленники злоупотребляли этой функцией, чтобы перехватывать учетные данные пользователей для аутентификации Windows. Они отправляли пользователю электронное письмо, заставляли его щелкнуть ссылку (или заставляли их почтовый клиент молча отвечать на невидимый встроенный прозрачный веб-маяк в один пиксель), и компьютер пользователя незаметно подключался к мошенническому серверу. Если включена встроенная проверка подлинности Windows, как это обычно бывает, компьютер пользователя отправляет корпоративные учетные данные пользователя на мошеннический удаленный веб-сервер.

На самом деле отправляется ответ пользователя на запрос сетевой аутентификации LAN Manager (LM) или Windows NT LM, из которого можно вычислить хэш пользователя LM или NT.

В ответ Microsoft отключила стандартную отправку учетных данных Windows для аутентификации пользователя на серверы вне локальной сети. Microsoft включила это новое значение по умолчанию в Internet Explorer версии 4 или 5. На сегодняшний день вы можете открыть дополнительные параметры конфигурации Internet Explorer («Свойства обозревателя», «Дополнительно», «Включить встроенную проверку подлинности Windows»). Это предотвратило подобные атаки, по крайней мере, я так думал.

Оказывается, есть еще способы обмануть Windows (и другие встроенные в Windows программы, поддерживающие аутентификацию, такие как Google Chrome), чтобы они отправляли запросы сетевой аутентификации NTLM на удаленные серверы. Насколько мне известно, это включает в себя включение встроенной ссылки в следующем формате: файл://// /. Например:

Если у вас не заблокирован исходящий TCP-порт 445, это работает независимо от того, какой параметр встроенной проверки подлинности Windows установлен в Internet Explorer. После демонстрации Кевина многие люди связались со мной, чтобы узнать подробности. В то время я не знал многих деталей, но теперь я смог проверить, что работает, а что нет.

Самый важный вывод: да, щелчок по встроенной ссылке file://// действительно передает мой запрос ответа NTLM на удаленный сервер, где мой хэш NT может быть взломан. Это работает:

В локальной сети и удаленно через Интернет
В конфигурациях по умолчанию на полностью исправленных системах
С брандмауэром Windows в состоянии по умолчанию
Как для локальных учетных записей SAM, так и для учетных записей Active Directory.

Удаленный злоумышленник получает имя вашего компьютера, доменное имя и ответ на вызов NTLMv2. Он будет работать в большинстве корпоративных сред. Это плохие новости.

Возможные решения этой атаки

Хорошая новость: в полностью пропатченной системе мне не удалось запустить ни одну итерацию атаки, просто открыв электронное письмо и не нажимая на ссылку. Я видел более старую атаку, упомянутую в патче Microsoft, который будет работать с использованием электронной почты RTF в Microsoft Office 365, но, похоже, эта дыра закрыта. Это хорошо, потому что никто не хочет просто открыть электронное письмо и быть использованным. Конечно, мы все знаем, что заставить пользователя щелкнуть ссылку не так уж и сложно, и теперь вы знаете, что это может привести к компрометации корпоративного пароля пользователя.

Один новый друг, Роб Томпкинс, отличный аналитик по кибербезопасности, самостоятельно провел множество тестов. Он подтвердил мои выводы и протестировал их в других программах. У него были интересные предписывающие выводы. Его самым важным было то, что даже если вы заблокируете TCP-порт 445 в корпоративной сети, чтобы предотвратить мошеннические исходящие подключения SMB/NetBIOS, если мобильное устройство не заблокировало порт в локальном брандмауэре, оно успешно передало свой ответ на вызов NTLM, когда это было вне сети. Это важное замечание. Роб также нашел правило/сигнатуру AlienVault для распознавания таких типов атак и защиты своих клиентов.

Установите исправление Microsoft

В ноябре 2017 г. корпорация Майкрософт выпустила соответствующее исправление и параметр реестра, которые доступны только для Windows 10 и Windows Server 2016. Для этого необходимо использовать и включить брандмауэр Windows, а также определить, в каких сетях разрешено и запрещено использовать NTLM. ССО. Эти требования означают, что множество организаций не могут его использовать. Кроме того, я читал о некоторых анекдотических случаях, когда компании, которые не точно определили разрешенные сети, имели перебои в обслуживании, поэтому продолжайте тестирование и проявляйте осторожность.

Используйте надежный пароль и заблокируйте неавторизованные порты аутентификации

Ничто не сравнится с надежным паролем с достаточной энтропией, чтобы взломщик паролей не смог его взломать, независимо от того, насколько мощный взломщик. Это должно быть защитой номер один. Также само собой разумеется, что вы должны блокировать неавторизованные исходящие порты аутентификации, такие как SMB/NETBIOS, используя ваши обычные методы фильтрации и отфильтровывая псевдонимы file:////.

Как проверить эту уязвимость

Если вы хотите поэкспериментировать, чтобы увидеть, насколько уязвима ваша организация и ее программное обеспечение, вы можете быстро настроить лабораторию с двумя компьютерами, клиентом Windows и сервером Linux, и начать тестирование примерно через час. Вот как.

Во-первых, сделайте себе одолжение и получите утилиту Responder на основе Python от Лорана Гаффи. Responder — отличный инструмент, с которым можно поэкспериментировать, чтобы увидеть кражу хэшей паролей в сети в действии. Он действует как мошеннический сервер (веб, NetBIOS, SQL, FTP и LDAP) с возможностью автоматического «отравления» LLMNR (протокол разрешения локальных имен Microsoft Windows), NetBIOS и многоадресный DNS (mDNS). Множество видеороликов в Интернете показывают, как люди используют Responder для отравления и захвата ответов на запросы NTLM.

Если вы хотите сэкономить время на правильную настройку Responder, загрузите и запустите Kali Linux и выполните следующие действия:

Войдите как root, пароль toor
Откройте меню "Приложения", выберите 09 – "Обнаружение и спуфинг" и запустите Responder.
Затем запустите responseer -I eth0 –v (обратите внимание на IP-адрес прослушивания)

На компьютере с Windows:

Откройте Проводник и подключитесь к файлу:////
/test.htlm (или любое имя файла)
Ответчик получит ответы на запрос NTLM

Чтобы взломать хэши, вернитесь на компьютер Linux:

Начать сеанс терминала
Введите cd /usr/share/responder/logs
Запустите John the Ripper, чтобы взломать хэши в файлах журналов

Боже, я люблю хакерство! Я никогда не получаю большего удовольствия, чем когда я исследую, что можно и что нельзя сделать с помощью хакерского инструмента. Конечно, узнав, что нажатие на встроенную ссылку в электронной почте вдвойне подтверждает, что я никогда не сделаю этого в реальной жизни. Оказывается, это может навредить вам.

Подробнее о тестировании на проникновение и этичном взломе

Роджер Граймс, ведущий колонку по безопасности с 2005 года, имеет более 40 компьютерных сертификатов и является автором десяти книг по компьютерной безопасности.

Читайте также: