Sua aplicação está pronta para um ambiente seguro – PARTE II



 


Por Yuri Diógenes


 


1. Introdução


 


Em Maio deste ano eu havia escrito o que foi a parte um deste arquivo, porém nem imaginava de fato que haveria uma parte 2, mas o dia a dia vem me mostrado duas coisas:


·         Primeiro que muitas empresas já se preocupam de fato com a segurança da informação e investem nisso – o que é ótimo;


·         Segundo que muitas empresas tem aplicações antigas que ainda não estão prontas para trabalhar em um ambiente seguro – o que é fato;


 


A dias atrás trabalhei em um outro caso onde o vilão parecia ser o sistema operacional, porém após vários testes podemos concluir que não era, mas até chegar a essa conclusão muita coisa aconteceu.


 


Vamos entender o cenário:


·         O cliente tem uma aplicação que faz uso do protocolo LDAP para fazer consultas no Active Directory;


·         O usuário ao se conectar no AD usando LDAP ele passa suas credenciais via linha de comando;


·         No passado este usuário da aplicação podia usá-la sem maiores problemas e fazer suas consultas no AD também sem problemas;


 


Problema: Após a empresa implementar algumas políticas de segurança o usuário passou a não conseguir mais utilizar esta aplicação de forma alguma.


 


2. Obtendo Dados


 


Primeiramente foi necessário um trabalho de investigação para saber o que tinha mudado no aspecto de segurança, para minha sorte o cliente ainda estava no início da implementação o que facilitou meu trabalho pois não tive que trilhar muito para  achar uma pista fundamental.


 


Uma das políticas que foi implementada foi a de que os usuários só poderiam efetuar logon na rede a partir de algumas estações de trabalho, uma política simples mas eficaz e antiga (temos isso desde o NT 3.51) mas funcional. Lembra desta política? Fica nas propriedades do usuário como mostra abaixo:


 


 


 


Neste momento você deve estar pensando: fácil, basta  colocar a estação a qual o usuário está efetuando o logon e pronto. Bem, não foi bem assim, apesar de que isso também me veio em mente, porém mesmo adicionando a estação a qual o usuário poderia efetuar o logon, continuávamos recebendo o erro de acesso negado.


 


Foi aí que resolvemos fazer um teste rodando localmente (no Domain Controller) e também tivemos problemas, então colocamos o Domain Controller na lista de computadores autorizados para aquele usuário logar e funcionou.


 


Depois disso testamos com outras coisas e sempre que o Domain Controller estava na lista de computadores a qual o usuário poderia logar a aplicação que usava LDAP conseguia fazer a autenticação. Intrigante não?


 


3. Fazendo o “Narrow Down” do problema…


 


Neste momento houve um certo “stress” por parte do cliente pois a princípio ele achava que era um furo da política de segurança que só deixava o usuário logar caso o DC estivesse na lista. Isso foi algo que não me convenceu também, porém como estávamos lidando com uma aplicação de terceiros e não tínhamos conhecimento de como ela funcionava por de trás dos panos então resolvemos usar uma ferramenta nossa para fazer o teste, foi aí que usamos o LDP.EXE. Quando estamos conectando via LDP temos a opção de passar as credencias do usuário que está efetuando o logon, conforme mostra a figura abaixo:


 


 


 


Então tiramos o DC da lista de computadores que o usuário estava permitido de efetuar o logon, deixamos apenas a estação local a qual ele estava logado. Resultado: funcionou sem problemas.


 


4. E por que isso?


 


Agora que já sabemos que com o nosso LDAP funciona resta saber por que, afinal temos não só que resolver mas também provar o porque e defender nossa tese. Para isso nada melhor que o velho e bom Network Monitor, lembre-se: tudo que passa pela placa de rede do computador a qual você está investigando é capturado pelo netmon, então a melhor forma de saber o que realmente está acontecendo é olhar os pacotes, claro pode levar tempo e pode ser algo que não é tão claro para alguns, porém eu recomendo você começar a se familiarizar bem com isso.


 


Vamos então ao teste número 1:


 


·         Uso do LDP.EXE para se conectar ao AD via LDAP:


 


1. Cliente faz uma requisição na porta TCP 389:


192.1.16.15            192.7.11.12            TCP      4507 > ldap [SYN]


 


2. Servidor concorda com a conexão


192.7.11.12            192.1.16.15            TCP      ldap > 4507 [SYN, ACK]


 


3. O MS LDP (no lado do cliente) envia então o “Bind Request” onde passa as credencias e neste caso usa o método NTLM de autenticação:


192.1.16.15            192.7.11.12            LDAP     MsgId=13


Bind Request, DN=(null), NTLMSSP_AUTH, User: DOMAINNAME \TestUser


 


Lightweight Directory Access Protocol


    LDAP Message, Bind Request


        Message Id: 13


        Message Type: Bind Request (0x00)


        Message Length: 225


        Response In: 3175


        Version: 3


        DN: (null)


        Auth Type: SASL (0x03)


        Mechanism: GSS-SPNEGO


        GSS-API Generic Security Service Application Program Interface


            NTLMSSP


                NTLMSSP identifier: NTLMSSP


                NTLM Message Type: NTLMSSP_AUTH (0x00000003)


                Lan Manager Response:


F1DC6D4CFFCD04F900000000000000000000000000000000


                    Length: 24


                    Maxlen: 24


                    Offset: 134


                NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8


                    Length: 24


                    Maxlen: 24


                    Offset: 158


                Domain name: DOMAINNAME


                    Length: 18


                    Maxlen: 18


                    Offset: 72


                User name: TestUser


                    Length: 32


                    Maxlen: 32


                    Offset: 90


                Host name: COMPUTADOR1


                    Length: 12


                    Maxlen: 12


                    Offset: 122


                Session Key: 33724B7018EADC94650FCAAB1F6741EF


                    Length: 16


                    Maxlen: 16


                    Offset: 182


                Flags: 0xe2888215


 


4. O servidor envia uma mensagem de autenticação com sucesso:


 


192.7.11.12            192.1.16.15            LDAP     MsgId=13 Bind Result


Lightweight Directory Access Protocol


    LDAP Message, Bind Result


        Message Id: 13


        Message Type: Bind Result (0x01)


        Message Length: 9


        Response To: 3174


        Time: 0.001953000 seconds


        Result Code: success (0x00) <———————- SUCCESSO


        Matched DN: (null)


        Error Message: (null)


 


Bem, com isso sabemos exatamente como nossa aplicação está se comportando durante a autenticação, ou seja, está usando NTLM.


 


Vamos então ao teste número 2:


 


·         Uso da aplicação de terceiros para se conectar ao AD via LDAP:


 


1. O cliente faz uma requisição de acesso na porta TCP por 389 (dispensarei a visualização dos pacotes pois não há mudança de comportamento)


 


2. O servidor concorda com a requisição;


 


3. O cliente então envia o “Bind Request” e agora vem a diferença:


 


192.1.16.15            192.7.11.12            LDAP     MsgId=1 Bind Request, DN=CN=TestUser,OU=Test,DC=domainname,DC=local


Lightweight Directory Access Protocol


    LDAP Message, Bind Request


        Message Id: 1


        Message Type: Bind Request (0x00)


        Message Length: 83


        Response In: 998


        Version: 3


        DN: DN=CN=TestUser,OU=Test,DC=domainname,DC=local


        Auth Type: Simple (0x00) <——————– Método Simples de Autenticação


        Password: 12345678


 


4. O servidor então envia o resultado abaixo:


192.7.11.12            192.1.16.15            LDAP     MsgId=1 Bind Result, invalidCredentials


Lightweight Directory Access Protocol


    LDAP Message, Bind Result


        Message Id: 1


        Message Type: Bind Result (0x01)


        Message Length: 94


        Response To: 997


        Time: 0.001954000 seconds


        Result Code: invalidCredentials (0x31) <————– ERRO


        Matched DN: (null)


        Error Message: 80090308: LdapErr: DSID-0C090334, comment:


AcceptSecurityContext error, data 531, vece


 


Agora que temos o cenário que funciona e o que não funciona já podemos dizer que:


·         Consulta LDAP via LDP.EXE está usando o método de autenticação NTLM;


·         Consulta LDAP via aplicação de terceiro está usando autenticação simples;


 


O protocolo LDAP implementado pela Microsoft poderá ter os seguintes métodos de autenticação:


 






















Método de Autenticação


Descrição


LDAP_AUTH_SIMPLE


Autenticação simples com texto limpo.


LDAP_AUTH_NTLM


Autenticação NT Lan Manager


LDAP_AUTH_DPA


Autenticação distribuída, usada pelo MMS (Microsoft Membership System)


LDAP_AUTH_NEGOTIATE


Generic security services (GSS)


LDAP_AUTH_SSPI


Método antigo o qual está incluso por compatibilidade retroativa.


Fonte da Tabela: White Paper Understanding LDAP


 


Agora vem a pergunta: o que tem haver o método de autenticação do usuário com a política de segurança que define que estações o usuário pode logar?


 


Vejamos então como todo o processo ocorre:


 


1. A aplicação de terceiro envia uma consulta LDAP para o AD usando o método de autenticação simples (LDAP_AUTH_SIMPLE). Este tipo de método envia uma string que contém apenas o nome do usuário e senha;


2. Quando o DC recebe este pedido de autenticação do cliente o DC então verifica as credenciais do usuário assim como as propriedades da conexão para checar se o computador a qual o usuário está locado está na lista dos computadores autorizados para aquele usuário;


3. Como a aplicação envia uma requisição simples de autenticação LDAP o nome do computador não vai junto do pacote então o DC usa o nome NetBIOS dele mesmo para fazer a autenticação.


4. O DC então verifica se o nome NetBIOS dele mesmo está contido ou não na lista dos computadores (atributo userWorkstations) autorizados e neste caso como não está então retorna um “Access Denied”.


 


Agora fica fácil entender o por que de que quando colocávamos o nome do DC na lista a autenticação funcionava. O problema não ocorre com NTLM pois o nome do computador vai junto do pacote, conforme mostra a captura de rede apresentada anteriormente. Vamos rever os campos contidos no pacote LDAP usando NTLM:


 


                NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8


                    Length: 24


                    Maxlen: 24


                    Offset: 158


                Domain name: DOMAINNAME


                    Length: 18


                    Maxlen: 18


                    Offset: 72


                User name: TestUser


                    Length: 32


                    Maxlen: 32


                    Offset: 90


                Host name: COMPUTADOR1


                    Length: 12


                    Maxlen: 12


                    Offset: 122


                Session Key: 33724B7018EADC94650FCAAB1F6741EF


                    Length: 16


                    Maxlen: 16


                    Offset: 182


                Flags: 0xe2888215


 


 


5. Conclusão


 


Ambiente seguro é algo de extrema importância nos dias de hoje, porém tão importante quanto isso é um ambiente de validação das políticas de segurança, principalmente quando estamos saindo de um ambiente onde existem aplicações antigas que não se preocupam com o aspecto de segurança. A implementação de novas políticas trazem benefícios ao negócio mas também podem ser tornar uma dor de cabeça caso não seja bem planejado.


 


6. Referências


 


Understanding LDAP


http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/ldap.asp


 


User-Workstations Attribute


http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/a_userworkstations.asp 


 


User Security Attributes


http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/security_properties.asp


 


 

Comments (2)

  1. Luciano de Lima - MVP Windows Server - Brasil says:

    Grande mestre Yuri.

    Esse artigo ficou muito bom!!!

    Descobrir esse tipo de comportamento exige conhecer como o Windows trabalha realmente.

    Parabéns por mais esse artigo.

    Caso ainda você ou outro membro do Latin America Support não tenham escrito um artigo sobre o Network Monitor, gostaria de sugerir se possível é claro, que você ou outro membro escrevessem alguns artigos sobre como utilizar o Network Monitor e como interpretar as capturas de pacotes com o Network Monitor.

    Acredito que esse tipo de informação seria muito útil para todos nós.

    Um abraço e sucesso.

  2. Yuri Diogenes says:

    Olá Luciano,

    Esse é sim um bom tema. O uso do Network Monitor em si é simples, ainda mais na nova versão. Porém juntar todas as dicas de análise de pacotes em um artigo só as vezes é complicado, então o que estou procurando fazer é criar diversos artigos onde a prática do uso do Network Monitor seja realizada.

    Com isso somado a práticas do dia a dia (que você pode realizar em ambientes de teste) então ficará mais fácil se familiarizar com os tipos de tráfegos de rede.

    Até a próxima.