February 13th, 2020

А внутри у ней неонка и думатель

Микрософт лапочки. Читаешь про Azure Files и про безопасность трафика в SMB 3.0 - шифрование, цифровые подписи, все дела - и восхищаешься: вот здорово! А потом думаешь - а как, ёлы-палы, ты вообще знаешь, что подключаешься к настоящему серверу \\mydearfiles.file.core.windows.net, а не к липовому? И тут понимаешь, что никак.

Сертификата, как в HTTPS нету. Да, SMB работает с Kerberos, который аутентификацию обеих сторон умеет, но какой тебе Керберос при обращении к Azure Files через Интернет? А что есть? А есть древний NTLM, который умеет лишь серверу юзерскую личность доказать, а наоборот нет.

А потом думаешь - а тогда на основе чего, граждане, вы ключи для своего замечательного шифрования вырабатываете, о котором с гордостью рассказываете, что оно на самых модных алгоритмах из лучших домов Парижа, от самого месье Галуа? А на основе того самого NTLM, про который сами же честно пишете, что:

  • NTLM is a challenge response protocol and its session key is based on password hashing that relies on weak cryptography.
  • NTLM does not support any modern cryptographic methods, such as AES or SHA-256. Its key derivation from the password is based on MD4 [RFC1320], DES [FIPS46-2], HMAC_MD5, and RC4.
  • NTLM does not use any salt. It is possible to observe a network packet trace and produce the same key if the attacker knows password, as shown in the appendix by an example of NTLMv2 session key calculation.
  • NTLM does not offer mutual authentication between client and server. The is no so such flag in the protocol.
  • The password length and complexity should be chosen carefully to mitigate brute force attacks.
  • At a minimum, NTLMv2 should be used, and auditing should be in place.

  • Ну и чего ж тогда эти ваши AES-128-CMAC, AES-128-GCM и HMAC-SHA256 стоят?

    То есть реально полагаться на шифрование в SMBv3 можно там, где оно особо и не нужно: в контролируемых корпоративных средах, где есть Active Directory и можно через политики отключить использование NTLM, чтобы избежать вражеских хитростей типа downgrade.

    А вот атаки man-in-the-middle на Azure Files по SMB ничто не предотвращает. Даже если "настоящий" пароль (access key) расшифровать не получится - это нафиг не надо: ничто не мешает запросить у настоящего сервера челлендж, передать клиенту, получить шифрованный пароль, передать серверу, получить доступ. Причём полный - иного варианта по SMB через Интернет просто не предусмотрено.

    Update: последний абзац неверен, кота занесло. SMB Signing таки предотвращает MiTM, хотя я долго не мог понять, как. Ответ узнал из этой блестящей презентации - любителям криптопорна всячески её советую. Очень грубо говоря: NTLM использует третью производную от юзерского пароля, а для того, чтобы создавать подписи на пакетах, надо знать первую. Если атакующий перехватывает-подменяет полностью весь обмен между клиентом и сервером, он увидит эту самую третью производную (параметр NTProofStr), но он будет не в состоянии использовать первую (NT Hash), чтобы вычислить общий с сервером сессионный ключ, который затем используется для подписей и для шифрования. То есть аутентификацию от имени клиента атакующий пройдёт, но затем всё - ни расшифровывать трафик, ни подделывать трафик не выйдет. Возможно, какие-то replay attacks и выгорят.

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

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

    Но поскольку в случае Azure Files пароль уникален для каждого "сервера" (access key для storage account), генерируется самим облаком и не может быть назначен клиентом, то и это не беда. В общем, мой наезд был не по делу, моё поведение недостойно советского офицера, я был нетрезв.