Password Hash Synchronization ADConnect

Parte essencial na configuração do ADConnect o formato de autenticação deve ser bem avaliado considerando vários aspectos que vão além do puro conhecimento técnico. Falando especificamente sobre possibilidades criadas para cloud temos o PHS (Password hash synchronization) e o PTA (Password through agent). Cada qual tem suas particularidades por isso estudaremos um por vez!

Há, informação importante. Eu já disse isso no artigo inicial sobre o ADConnect mas vale repetir, em se tratando de senha o sync ocorre a cada 2 minutos, ok?!

O que é o PHS?

O escolhido para começar a jornada de estudo é o Password hash synchronization (PHS). Como o nome propõe esse método de sincronização leva o hash da senha do AD para nuvem e com isso os usuários conseguem utilizar a mesma senha que usam “dentro de casa” para logarem em cargas de nuvem (OneDrive, Exchange…).

Utilizando vários mecanismos para realizar essa sincronização de maneira segura e efetiva (relax que vou explicar), o PHS, a meu ver, é o método mais popular e fácil para se iniciar um ambiente híbrido de pequeno ou grande porte! Esse “popularismo” se dá ao fato de não exigir nada além do ADConnect pra que funcione e, em caso de falha ou indisponibilidade temporária do ADConnect o acesso a cargas cloud não são prejudicados. Entenda aqui que, obviamente, se houver uma alteração de senha enquanto houver uma indisponibilidade do ADConnect, o hash da nova senha não será sincronizado e como esperado a senha antiga deve ser utilizada. Após reestabelecimento do serviço e sincronização Delta o user poderá utilizar a nova senha para login!

Como funciona o PHS?

Como sempre digo, melhor do que saber qual opção selecionar ou qual botão apertar, é saber como as opções funcionam “por baixo dos panos”.

Muitos pensam que optar pelo PHS é basicamente permitir que o ADConnect copie a senha do seu AD e cole no AzureAD! Not that simple, bitch! É super importante dizer que o AzureAD, em momento algum, tem contato com a senha de ambiente local. O que é enviado ao AzureAD é hash do hash da senha do AD.

“Ok Nathan, mas o que diabos é hash?”

Eu não sou matemático pra entender a fundo como um hash funciona, mas sei que o “Hash” é um tipo de criptografia utilizada para garantir a integridade de uma informação sem expor tal informação. Um exemplo (nada real, apenas fictício a nível didático):

MinhaSenha + hash = 2ab96390c5dbe1437na23l0c6b1b1762

Agora que temos uma ideia básica do que seja o hash, vamos entender como o processo todo funciona, de forma simples e direta.

1. A cada 2 minutos um o agente de sincronização utilizando o protocolo MS-DRSR consulta o atributo “UnicodePWD” e busca o MD4 da senha no AD.
2. Antes de enviar o MD4 o DC encripta esse hash com uma chave baseada em MD5+salt (entenda salt como alguns bit que são acrescido para fins de segurança) da sessão RPC.
3. O DC então envia essas informações ao agente de sincronização
4. Por sua vez o agente de sincronização remove o MD5 para ter acesso ao Hash MD4 da senha.
5. O Agente de sincronização realiza alguns processos de expansão e conversão desse Hash MD4. No final, o hash de 16 bytes torna-se um de 64 bytes.
6. Em posse do do hash de 64-bytes o processo ainda adiciona um salt de mais 10-bytes.
7. Não acaba por ai…depois disso tudo o agente de sincronização combinará o MD4 como salt e imputará isso tudo em uma função PBKDF2 que é basicamente um mecanismo de criptografia que expande chaves de forma randômica para aumentar o nível de complexidade da mesma. Além disso são realizadas 1000 interações com o algoritmo HMAC-SHA256.
8. No final, tudo isso é concatenado (MD4+salt+PBKDF2+HMAC-SHA256) é enviado ao AzureAD através de um túnel TLS 1.2.
9. A validação da senha ocorre com o AzureAD comparando os hashes que ele já possui com os recebidos por esses processos

 

copyright: https://security4cloud.fr/

O PHS é seguro?

Você leu o topico anterior?

Eu ouvi muito e li alguns textos de pessoas defendendo que o PHS não seria um método seguro de sincronização de senha. Esse tipo de afirmação vem da falsa ideia de que a senha, em texto plano, é transmitida e armazenada no AzureAD.

Eu já citei, mas vale reforçar: Sua senha em texto plano não é exposta em momento algum a nenhum serviço que faz parte de todo esse processo!

Entenda que, do passo 1 ao passo 7, tudo ocorre do lado local, entre ADConnect e DC. A autenticação do usuário em si ocorre na nuvem. O pacote enviado ao AzureAD contendo o hash do hash da senha do AD está mais protegido do que é armzenado no seu AD OnPrem.

Caso esteja curioso de como uma senha comum fica depois de parte desse processo realizado pelo ADConnect, de uma olhada nesse site.

Mas e se capturarem o hash do hash e fizerem engenharia reversa?

A Microsoft garante que esse processo não é possível. Por conta do SHA256 uma decriptação não é opção e, tentar utilizar o hash enviado ao AzureAD localmente, numa tentativa de ataque pass-the-hash, não funcionará.

O tenho de Pros/Cons utilizando o PHS?

• Pro – Smart Lockou
• Pro – IP Lockout
• Pro – Microsoft Leaked credentials Service
• Pro – DoS Protection
• Pro – Password Spray Attack protection
• Con – Não pode utilizar recursos como restrição de horários para login

Conclusão

Embora simples o PHS é uma baita solução de autenticação e em minha opinião a melhor escolha para grande parte dos ambientes.

Unindo simplicidade e segurança o método e autenticação ainda consegue entregar estabilidade e mais alguns recursos nativos da Cloud Microsoft (se a licença do AzureAD permitir, é claro).

Obviamente temos ainda o PTA e o ADFS (veio de guerra) que, dependendo da situação, podem ser boas opções também.

Espero que tenha te ajudado! Grande abraço \,,/