WikiDer > Передайте хеш

Pass the hash

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

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

Этот метод может быть применен к любому серверу или службе, принимающим аутентификацию LM или NTLM, независимо от того, работает ли он на машине с Windows, Unix или любой другой операционной системой.

Описание

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

Собственные приложения Windows запрашивают у пользователей пароль в виде открытого текста, а затем звонят API как LsaLogonUser[2] которые преобразуют этот пароль в одно или два значения хэша (хэши LM или NT) и затем отправляют его на удаленный сервер во время аутентификации NTLM.[Примечания 1][3] Анализ этого механизма показал, что пароль в открытом виде не требуется для успешного завершения сетевой аутентификации, нужны только хэши.

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

История

В передать хеш метод был первоначально опубликован Полом Эштоном в 1997 году.[4] и состоял из модифицированного Самба SMB клиент, который принимал хеши паролей пользователей вместо паролей в открытом виде. Более поздние версии Samba и другие сторонние реализации протоколов SMB и NTLM также включали эту функциональность.

Эта реализация метода была основана на стеке SMB, созданном третьей стороной (например, Samba и другими), и по этой причине страдала от ряда ограничений с точки зрения хакера, включая ограниченную или частичную функциональность: протокол SMB имеет продолжал развиваться с годами, это означает, что третьи стороны, создающие свою собственную реализацию протокола SMB, должны вносить изменения и дополнения в протокол после того, как они будут внесены в более новые версии Windows и SMB (исторически путем обратного проектирования, что очень сложно и требует много времени). Это означает, что даже после успешного выполнения NTLM-аутентификации с помощью передать хеш В таких инструментах, как SMB-клиент Samba, возможно, не реализована функциональность, которую злоумышленник может захотеть использовать. Это означало, что было сложно атаковать программы Windows, использующие DCOM или RPC.

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

В 2008 году Эрнан Очоа опубликовал инструмент под названием «Pass-the-Hash Toolkit».[5] это позволяло «передать хеш» в Windows. Это позволило кэшировать имя пользователя, имя домена и хеши пароля в памяти Местный орган безопасности быть измененным во время выполнения после пользователь был аутентифицирован - это позволяло «передавать хэш» с помощью стандартных приложений Windows и тем самым подрывать фундаментальные механизмы аутентификации, встроенные в операционную систему.

Инструмент также представил новую технику, которая позволяла сбрасывать хэши паролей, кэшированные в памяти lsass.exe процесс (не в постоянном хранилище на диске), который быстро стал широко использоваться тестеры на проникновение (и злоумышленники). Этот метод сбора хешей является более продвинутым, чем ранее использовавшиеся методы (например, сброс локального Менеджер учетных записей безопасности база данных (SAM) с использованием pwdump и аналогичные инструменты), главным образом потому, что хеш-значения, хранящиеся в памяти, могут включать учетные данные пользователей домена (и администраторов домена), которые вошли в систему. Например, хэши аутентифицированных пользователей домена, которые не хранятся постоянно в локальном SAM, также могут быть сброшены. Это позволяет тестировщику проникновения (или злоумышленнику) скомпрометировать весь Домен Windows после компрометации одной машины, которая была членом этого домена. Более того, атака может быть реализована мгновенно и без каких-либо затрат на дорогостоящие вычислительные ресурсы для проведения атаки методом грубой силы.

Этот набор инструментов впоследствии был заменен редактором учетных данных Windows, который расширяет функциональность исходного инструмента и поддержку операционной системы.[6][7] Некоторые поставщики антивирусных программ классифицируют этот инструментарий как вредоносное ПО.[8][9]

Сбор хеша

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

  • Кэшированные хэши или учетные данные пользователей, которые ранее входили в систему (например, с консоли или через RDP), могут быть прочитаны из SAM любым, у кого есть привилегии уровня администратора. Поведение по умолчанию для кэширования хэшей или учетных данных для использования в автономном режиме может быть отключено администраторами, поэтому этот метод может не всегда работать, если машина достаточно защищена.
  • Выгрузка базы данных учетных записей локальных пользователей (СЭМ). Эта база данных содержит только учетные записи пользователей, локальные для конкретной машины, которая была взломана. Например, в среде домена СЭМ база данных машины не будет содержать пользователей домена, только пользователей, локальных для этой машины, которые, скорее всего, не будут очень полезны для аутентификации в других службах в домене. Однако, если одни и те же пароли локальных административных учетных записей используются в нескольких системах, злоумышленник может получить удаленный доступ к этим системам, используя хэши локальных учетных записей пользователей.
  • Нюхать Диалоги запроса-ответа LM и NTLM между клиентом и серверами, а затем перебор захваченных зашифрованных хэшей (поскольку хэши, полученные таким образом, зашифрованы, необходимо выполнить атаку методом грубой силы, чтобы получить фактические хэши).
  • Сброс учетных данных аутентифицированных пользователей, хранящихся в Windows, в память процесса lsass.exe. Учетные данные, сброшенные таким образом, могут включать учетные данные пользователей или администраторов домена, например тех, кто вошел в систему через RDP. Таким образом, этот метод можно использовать для получения учетных данных пользователей, которые не являются локальными для взломанного компьютера, а происходят из домена безопасности, членом которого является компьютер.

Смягчения

Любая система, использующая аутентификацию LM или NTLM в сочетании с любым протоколом связи (SMB, FTP, RPC, HTTP и т. Д.), Подвергается риску этой атаки.[1] От эксплойта очень сложно защититься из-за возможных эксплойтов в Windows и приложений, работающих в Windows, которые могут быть использованы злоумышленником для поднять их привилегии, а затем выполнить сбор хэша, который облегчает атаку. Кроме того, может потребоваться, чтобы только одна машина в домене Windows была неправильно настроена или в ней не было исправления безопасности, чтобы злоумышленник мог найти выход. Кроме того, доступен широкий спектр инструментов тестирования на проникновение для автоматизации процесса обнаружения уязвимости на машине.

Нет единой защиты от техники, поэтому стандарт глубокая защита практика применяется[10] - например, использование брандмауэры, системы предотвращения вторжений, 802.1x аутентификация, IPsec, антивирусное программное обеспечение, уменьшая количество людей с повышенными привилегиями,[11] упреждающая установка исправлений безопасности[12] и т. д. Запрещение Windows хранить кэшированные учетные данные может ограничить злоумышленников получением хэшей из памяти, что обычно означает, что целевая учетная запись должна быть зарегистрирована на машине при выполнении атаки.[13] Разрешение администраторам домена входить в системы, которые могут быть скомпрометированы или ненадежны, создаст сценарий, в котором хэши администраторов станут целями злоумышленников; Таким образом, ограничение входа администратора домена на доверенные контроллеры домена может ограничить возможности для злоумышленника.[10] В принцип наименьших привилегий предлагает использовать подход с минимальным доступом пользователя (LUA), в котором пользователи не должны использовать учетные записи с большим количеством привилегий, чем необходимо для выполнения поставленной задачи.[10] Настройка систем, не использующих LM или NTLM, также может усилить безопасность, но новые эксплойты могут пересылать Билеты Kerberos Аналогичным образом.[14] Ограничение объема отлаживать привилегии в системе могут препятствовать некоторым атакам, которые ввести код или украсть хэши из памяти чувствительных процессов.[10]

Ограниченный режим администратора - это новая функция операционной системы Windows, представленная в 2014 году в бюллетене по безопасности 2871997, которая предназначена для снижения эффективности атаки.[15]

Смотрите также

Примечания

  1. ^ Обратите внимание, что Windows может использовать Kerberos аутентификация по умолчанию.

Рекомендации

  1. ^ а б Крис Хаммел (12 октября 2009 г.). «Зачем взламывать, если можно передать хэш?». Институт SANS. Цитировать журнал требует | журнал = (помощь)
  2. ^ "LsaLogonUser". Microsoft. 7 сентября 2011 г.. Получено 25 октября 2011.
  3. ^ «Как работает интерактивный вход». Microsoft. 22 января 2009 г.. Получено 25 октября 2011.
  4. ^ а б Даниэль Стирниманн (9 августа 2010 г.). «Windows Attack - получите права администратора предприятия за 5 минут» (PDF). Compass Security AG. Получено 10 октября 2010.
  5. ^ Эрнан Очоа (2 июля 2008 г.). "Что такое набор инструментов Pass-The-Hash?". Получено 20 октября 2011.
  6. ^ Эрнан Очоа (2011). WCE Внутреннее устройство. RootedCON.
  7. ^ Эрнан Очоа (2011). "Редактор учетных данных Windows (WCE) F.A.Q." Amplia Security. Получено 25 октября 2011.
  8. ^ «SecurityRisk.WinCredEd». Symantec. 21 марта 2011 г.. Получено 25 октября 2011.
  9. ^ "HackTool: Win32 / Wincred.A". Microsoft. 1 октября 2011 г.. Получено 25 октября 2011.
  10. ^ а б c d Башар Эвайда (21 января 2010 г.). «Атаки с передачей хэша: инструменты и меры по их устранению». Институт SANS. Цитировать журнал требует | журнал = (помощь)
  11. ^ Роджер Граймс (26 июля 2011 г.). «Остановите атаки с передачей хэша до их начала». InfoWorld. Получено 25 октября 2011.
  12. ^ Роб Краус; Брайан Барбер; Майк Боркин; Наоми Альперн (2010). Семь самых смертоносных атак Microsoft. Syngress. С. 12–14. ISBN 1-59749-551-4.
  13. ^ «Предотвращение атак Pass-the-Hash и атак с использованием кэшированных учетных данных». Программа защиты компьютеров Berkley Lab. Получено 20 октября 2011.
  14. ^ «Уязвимость обхода безопасности Microsoft Windows Kerberos 'Pass The Ticket' Replay». securityfocus.com. 13 августа 2010. Архивировано с оригинал 12 марта 2016 г.. Получено 20 октября 2010.
  15. ^ https://technet.microsoft.com/library/security/2871997

внешняя ссылка