Критические уязвимости в Samba от 12.04.2016

Samba — открытая реализация протокола SMB (Server Message Block), также известного как CIFS (Common Internet File System), предназначенного для организации сетевого взаимодействия разнотипных операционных систем и обеспечения совместного доступа к файлам и принтерам с PC-совместимых компьютеров. Red Hat сообщает об устранении нескольких уязвимостей во всех официально поддерживаемых версиях Samba. Наиболее важную информацию об уязвимости Badlock (CVE-2016-2118) можно найти в этой статье.

Уязвимые версии:

CVE-2015-5370: серия ошибок в коде DCE/RPC

В реализации протокола DCE/RPC был обнаружен ряд уязвимостей, воспользовавшись которыми, действующий удаленно нарушитель мог вызвать отказ в обслуживании сервера Samba (сбой в работе или необоснованно высокое потребление процессорных ресурсов) и потенциально выполнить произвольный код с разрешениями пользователя, запустившего Samba (root). Это также позволяло понизить уровень защиты соединения DCE/RPC и получить контроль над объектом Active Directory (AD), тем самым подвергнув риску безопасность контроллера домена Active Directory.

Примечание. Несмотря на то, что пакеты Samba в Red Hat Enterprise Linux не поддерживают работу Samba в режиме контроллера домена Active Directory, эта уязвимость проявляется независимо от того, какую роль выполняет сервер Samba.

CVE-2016-2118 (Badlock): угроза MITM-атаки на SAMR и LSA

Подробную информацию можно найти в статье Уязвимость Badlock в Samba - CVE-2016-2118

CVE-2016-2110: угроза MITM-атаки в реализации NTLMSSP

Уязвимости в реализации аутентификации NTLMSSP позволяют инициировать MITM-атаку и сбросить флаги NTLMSSP_NEGOTIATE_SIGN и NTLMSSP_NEGOTIATE_SEAL, тем самым спровоцировав передачу данных в открытом виде, даже если при установке соединения запрашивалось шифрование.

LDAP (с аутентификацией NTLMSSP) используется в качестве клиента множеством административных инструментов Samba, в частности net, samba-tool, ldbsearch и ldbedit.

Указанные уязвимости характерны для всех режимов работы Samba и имеют прямое отношение к CVE-2016-2112 и CVE-2016-2113.

CVE-2016-2111: спуфинг NETLOGON

Если Samba выступает в роли контроллера домена, то при установке защищенного канала связи нарушитель может подделать имя компьютера, установить от его имени несанкционированное соединение с другим узлом домена и получить доступ к данным сеанса.

Эта уязвимость представляет опасность для сервера Samba, выступающего в роли классического основного или резервного контроллера домена, а также для контроллера домена Active Directory.

Для Microsoft Windows Server эта уязвимость была задокументирована как CVE-2015-0005

В исправлении была представлена новая директива для smb.conf:

  raw NTLMv2 auth (G)

    Этот параметр определяет, будет ли smbd(8) разрешать клиентам SMB1
    без усиленной безопасности (без SPNEGO) использовать аутентификацию NTLMv2.

    Если отключить эту директиву одновременно с отключением «langman auth» и «ntlm auth»,
    то подключение будет разрешаться только клиентам с поддержкой SPNEGO.
    Это значит, что NTLMv2 будет поддерживаться только в рамках NTLMSSP.

    По умолчанию: raw NTLMv2 auth = no

CVE-2016-2112: сервер и клиент LDAP не регламентируют проверку целостности

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

Эта уязвимость имеет место независимо от того, какую роль выполняет Samba.

В исправлении была представлена новая директива для smb.conf:

  ldap server require strong auth (G)

    Эта директива определяет, будет ли сервер LDAP требовать,
    чтобы весь трафик LDAP был как минимум подписан
    либо не только подписан, но и зашифрован.
    Возможные значения: «no», «allow_sasl_over_tls» и «yes».

    «no» разрешает простую привязку и привязку SASL независимо от транспортного протокола.

    «allow_sasl_over_tls» разрешает простую привязку и привязку SASL (без подписи и шифрования)
    для зашифрованных соединений TLS. Незашифрованные соединения
    допускают привязку SASL только с подписью или шифрованием.

    «yes» разрешает только простые привязки для зашифрованного TLS.
    Незашифрованные соединения разрешают создавать привязки SASL только с подписью или шифрованием.

    По умолчанию: ldap server require strong auth = yes

Примечание. LDAP-сервер сам по себе не предусматривает наличие параметра для принудительного использования аутентификации. Эту задачу как раз и решает директива ldap server require strong auth, принимающая значения no, allow_sasl_over_tls и yes.

Раньше по умолчанию устанавливалось значение no, поэтому не исключено, что его потребуется изменить вручную, чтобы клиенты могли корректно обрабатывать ошибки LDAP_STRONG_AUTH_REQUIRED. Клиенты Windows и рядовые серверы Samba уже используют подобную защиту.

CVE-2016-2113: отсутствие проверки сертификата TLS/SSL

Samba не осуществляет проверку сертификатов SSL/TLS для некоторых типов соединений, что потенциально может послужить поводом для MITM-атаки и спуфинга сервера Samba путем предоставления специально подготовленного сертификата SSL/TLS

Эта уязвимость имеет место независимо от того, какую роль выполняет Samba.

В исправлении была представлена новая директива для smb.conf:

  tls verify peer (G)

    Эта директива отвечает за проверку
    сертификата и имени сервера клиентом.
    Возможные значения: «no_check», «ca_only», «ca_and_name_if_available», «ca_and_name», «as_strict_as_possible».

    «no_check» полностью отключает проверку сертификата,
    что создает риск проведения стандартной MITM-атаки.

    «ca_only» проверяет, действительно ли сертификат был подписан удостоверяющим
    центром, заданным директивой «tls ca file». При этом строка «tls ca file» должна
    содержать действительный файл. Время действия сертификата тоже будет проверено.
    Если дополнительно задана директива «tls crl file»,
    сертификат будет проверен на принадлежность списку CA CRL.

    «ca_and_name_if_available» осуществляет все проверки по аналогии с «ca_only»
    и дополнительно проверяет соответствие имени узла
    (если оно было получено на уровне приложения, а не из IP-адреса)
    имени, указанному в сертификате.

    «ca_and_name» выполняет все те же проверки, что и «ca_and_name_if_available»,
    а также подтверждает имя узла и даже проверяет его IP-адрес
    на соответствие имени в сертификате.

    «as_strict_as_possible» включает все проверки из «ca_and_name»
    и дополнительно требует, чтобы был настроен параметр «tls crl file».
    В будущих версиях Samba могут быть добавлены дополнительные проверки.

    По умолчанию: tls verify peer = as_strict_as_possible

CVE-2016-2114: отсутствие строго применения "server signing = mandatory"

Так как Samba не предъявляет никаких требований касательно контроля подписи SMB (Server Message Block) к клиентам, использующим протокол SMB1, это может послужить причиной MITM-атаки и несанкционированной модификации передаваемых между сервером и клиентом данных.

Эта уязвимость представляет опасность для серверов, выступающих в роли автономного сервера, классического основного или резервного контроллера домена, а также контроллера домена Active Directory.

Меры предосторожности:

Явное указание server signing = mandatory и server min protocol = SMB2 в секции [global] в файле smb.conf предотвратит возможность установки соединения без цифровой подписи. Следует отметить, однако, что это может привести к тому, что более ранние клиенты, в которых поддержки SMB2 и выше не предусмотрено, больше не смогут подключаться к серверу.

CVE-2016-2115: отсутствие защиты целостности трафика IPC для клиентов SMB

По умолчанию Samba не включает защиту целостности трафика IPC, что может быть использовано для осуществления MITM-атаки с целью отслеживания и модификации данных, передаваемых между клиентом и сервером.

Последние рекомендации по безопасности представили несколько новых директив smb.conf:

  client ipc signing (G)

    Определяет, будет ли клиент подписывать трафик SMB
    соединений IPC$ при использовании транспорта DCE/RPC.
    Возможные значения: «auto», «mandatory», «disabled».

    «mandatory» и «default» включают механизм подписи пакетов SMB.

    «auto» означает, что возможность подписи SMB предлагается, но не в принудительном порядке.
    «disabled» отключает использование цифровой подписи.

    При подключении winbindd к контроллерам доменов Active Directory
    передаваемый трафик будет подписываться принудительно.

    По умолчанию: client ipc signing = default

  client ipc max protocol (G)

    Значение этой директивы (строка) определяет максимальную версию протокола,
    которая будет поддерживаться в качестве транспорта DCE/RPC для соединений IPC$.

    Обычно эту директиву не требуется настраивать, так как версия определяется
    протоколом SMB на стадии автоматического согласования подключения.

    «default» обозначает последнюю поддерживаемую версию протокола (SMB3_11 на данный момент).

    Полный список протоколов можно найти в описании директивы «client max protocol».
    Значения CORE, COREPLUS, LANMAN1, LANMAN2 по умолчанию обновляются до NT1.
    По умолчанию: client ipc max protocol = default

    Пример: client ipc max protocol = SMB2_10

  client ipc min protocol (G)

    Значение этой директивы определяет минимальную версию протокола,
    которая может приниматься в качестве транспорта DCE/RPC для соединений IPC$.

    Обычно эту директиву не требуется настраивать, так как версия определяется
    протоколом SMB на стадии автоматического согласования подключения.

    «default» присваивает значение NT1,
    которое также переопределяет «client min protocol».

    Полный список протоколов можно найти в описании директивы «client max protocol».
    Значения CORE, COREPLUS, LANMAN1, LANMAN2 по умолчанию обновляются до NT1.

    По умолчанию: client ipc min protocol = default

    Пример: client ipc min protocol = SMB3_11

Меры предосторожности:

Явное указание client signing = mandatory в секции [global] в файле smb.conf

Эта уязвимость имеет место независимо от того, какую роль выполняет Samba.