Badlock: protocolos SAMR e LSA ataque man-in-the-middle contra Samba (CVE-2016-2118)

A equipe do Red Hat Product Security tomou conhecimento sobre uma falha no protocolo DCE/RPC baseado nos protocolos SAMR e LSA usados na infraestrutura do Microsoft Windows Active Directory. Esta falha foi atribuída à CVE-2016-2118

Nota: Este é um problema de protocolo e afeta todos os aplicativos que implementam este protocolo, incluindo Samba - [CVE-2016-2118] (https://access.redhat.com/security/cve/CVE-2015-2118) e Microsoft Windows - CVE-2016-0128.

Informações Gerais

DCE/RPC é a especificação para o mecanismo de chamada de procedimento remoto que define tanto APIs quanto um protocolo sobre uma rede. O Security Account Manager (SAM) do protocolo remoto (Cliente-para-Servidor) oferece a funcionalidade de gerenciamento de contas ou diretórios contendo usuários e grupos. O protocolo expõe o "banco de dados de contas" para domínios locais ou remotos do Microsoft Active Directory. A Autoridade de Segurança Local (Política de Domínio) do protocolo remoto é usado para gerenciar várias máquinas e políticas de segurança de domínios. Este protocolo, com pequenas exceções, permite cenários de gerenciamento de políticas remotas. Os protocolos SAMR e LSA são baseados no protocolo DCE 1.1 RPC.

Estes protocolos estão tipicamente disponíveis para todas as instalações do Windows, assim como em todo servidor Samba. Eles são usados para manter o banco de dados do Security Account Manager. Isto aplica-se a todas as funções (por exemplo, controlador de domínio autônomo ou membro de domínio).

Descrição e impacto do ataque

Qualquer conexão DCE/RPC autenticada que um cliente iniciar contra um servidor pode ser usada por um ataque "man-in-the-middle" para imitar o usuário autenticado contra o serviço SAMR ou LSA no servidor. Como resultado, o invasor estaria apto a ter acesso para leitura ou gravação no banco de dados do Security Account Manager, o que poderia revelar todas as senhas e qualquer outra informação potencialmente sensível.

A escolha do cliente em relação ao protocolo de aplicativo, tipo de autenticação (por exemplo, Kerberos ou NTLMSSP) e nível de autenticação (NONE, CONNECT, SIGN, ou SEAL) não é relevante neste caso. O invasor, através do ataque"man-in-the-middle" pode reduzir o nível de autentificação para CONNECT e assim, tomar o controle da conexão.

Todas as versões do pacote Samba enviados com o servidor do Red Hat Enterprise Linux e Red Hat Gluster Storage foram afetados por essa falha de segurança. A equipe do Red Hat Product Security classificou esse problema como de [IMPORTANTE] impacto (https://access.redhat.com/security/updates/classification/#important).

Configurações afetadas

• Uma infraestrutura de Active Directory com servidor Samba como membro de domínio está vulnerável a esta falha. Um ataque man-in-the-middle pode interceptar o tráfego de DCE/RPC entre o membro de domínio e o controlador de domínio para imitar o cliente e conseguir acesso aos mesmos privilégios de uma conta de usuário autenticado. O invasor poderia visualizar ou modificar segredos dentro de um banco de dados AD, incluindo hashes da senha de segurança de usuário ou desconectar serviços críticos.

• Qualquer servidor Samba configurado como um servidor de arquivo ou impressão também está vulnerável a esta falha. O invasor poderá usar esta falha para modificar permissões de usuário em arquivos ou diretórios.

Mitigação

O risco pode ser reduzido ao não utilizar contas privilegiadas para acessar serviços SMB/CIFS até que um pacote contendo a correção seja aplicado. Acesso administrativo restrito para hardware físico (console, servidor), para que a autenticação não envolva qualquer comunicação de rede.

Resolução

Agradecimentos

A Red Hat gostaria de agradecer ao projeto Samba por reportar este problema. O projeto reconhece Stefan Metzmacher (SerNet) como o original relator dessa falha de segurança.

Notas adicionais

A atualização de segurança para esta falha apresenta uma nova opção em smb.conf, documentada como:

  allow dcerpc auth level connect (G)

    Esta opção controla se os serviços DCERPC podem ser usados com
    DCERPC_AUTH_LEVEL_CONNECT, o qual fornece autenticação, mas não por integridade da mensagem (SIGN) ou por proteção de privacidade (SEAL).

    Algumas interfaces como samr, lsarpc e netlogon possuem o valor padrão pré-definido
    de "no"; epmapper, mgmt e rpcecho possuem o valor padrão pré-definid de "yes".

    O comportamento pode ser sobrescrito pelo nome da interface (por exemplo, lsarpc,
    netlogon, samr, srvsvc, winreg ou wkssvc) por meio da especificação
    'allow dcerpc auth level connect:interface = yes'.

    Esta opção abre precedentes a qualquer implementação de restrições específicas. Por
    exemplo:
* Os protocolos drsuapi e backupkey requerem DCERPC_AUTH_LEVEL_PRIVACY.
* O protocolo dnsserver requer DCERPC_AUTH_LEVEL_INTEGRITY.

    Valor padrão: allow dcerpc auth level connect = no
    Exemplo: allow dcerpc auth level connect = yes

Perguntas Frequentes

É necessário atualizar tanto os servidores Samba quanto os clientes Samba em minha infraestrutura??

É necessário, no mínimo, que os servidores Samba sejam atualizados. Devido ao fato do Badlock ser uma falha de protocolo, tanto os servidores quanto clientes podem ser afetados, dependendo da configuração na infraestrutura do Samba. A equipe do Red Hat Product Security aconselha aos clientes a atualizar ambos, clientes e servidores.

Os pacotes atualizados são incompatíveis com os clientes existentes que estão executando versões antigas do Samba?

Esta consulta de segurança restringe algumas das opções de segurança usadas para configurar o Samba. Poderá haver a quebra de configurações quando o servidor Samba for atualizado, mas o cliente não for. É possível desfazer e voltar para as opções não seguras para continuar a interoperabilidade (por exemplo, ao configurar allow dcerpc auth level connect = yes no arquivo smb.conf), entretanto, a equipe do Red Hat Product Security altamente recomenda a não fazê-lo, uma vez isto poderá reintroduzir alguns vetores de ataque.

Minhas instâncias do servidor Samba não estão conectados a nenhum domínio do Windows, mesmo assim eu posso ser afetado?

Sim, se um usuário admin comunicar com um servidor Samba, usando um cliente que não é seguro, ou usar um cliente seguro para comunicar com um servidor Samba que não esteja seguro, um ataque "man-in-the-middle" pode, potencialmente, usar isto para explorar esta falha.

Os clientes e servidores Samba já foram atualizados. É preciso reiniciá-los?

Não, quando a atualização é aplicada no seu sistema, o serviço smbserá automaticamente reiniciado.

A encriptação poderá me proteger contra um ataque MITM?

O protocolo SMB, por padrão, somente criptografa credenciais e comandos enquanto os arquivos são transferidos em um texto simples. É recomendado que, em cenários de segurança e privacidade sensíveis, a criptografia seja usada para proteger todas as comunicações. Uma criptografia foi adicionada ao Samba na versão 3.2, mas somente para clientes Samba. A Microsoft adicionou o suporte de criptografia do SMB para o SMB 3.0 no Windows 8 e Windows Server 2012.
Entretanto, ambos os tipos de criptografia somente protege as comunicações, tal como a transferência de arquivos, após a conclusão das negociações e comandos SMB. É nesta fase que contém a vulnerabilidade descrita acima. A criptografia do Samba/SMB é uma boa prática, porém não é suficiente para proteção contra esta vulnerabilidade.

Referências

http://badlock.org/