Ola pessoal, esse tutorial foi escrito por INEM, e tenho o maior prazer em divulgar o material no blog.
O INEM e administrador do www.forum-underground.com e um dos parceiros do blog.
TUTORIAL
KERBEROS vs NTLM
Olá pessoal,
Realizei um tutorial que explica a fundo o funcionamento do Protocol Kerberos, formas de quebrar essas senhas e também como protege-lo. A ideia deste tutorial fornece somente apoio a pessoas que estejam a estudar Networking e Redes em particular e em nada incentiva a possíveis quebras de segurança.
Em parte este tutorial foi realizado depois de uma vasta pesquisa na Internet e também por vários manuais que tenho da Microsoft. No entanto a parte onde me reserva direitos de autor totais é a parte de desenvolvimento onde retrato o procedimento do Kerberos e dos tickets detalhadamento. Créditos no Final.
Um Pouco de História:
Kerberos é um protocolo de autenticação do Projeto Athena. Tem esse nome em alusão ao Cão guarda de três cabeças (Cérbero) do deus Hades da Mitologia grega. Diversas versões do protocolo já existiram, as versões 1 até a 3 foram utilizadas somente dentro da MIT. Steve Miller e Clifford Neuman, foram os principais projetistas da versão 4 do Kerberos, publicada nos anos 80, ainda com foco no Projeto Athena.
A versão 5 foi projetada por John Kohl e Clifford Neuman e publicada em 1993 no RFC 1510 (Ficou obsoleto ao RFC 4120 de 2005), e teve como intenção melhorar a segurança e as limitações relativas a versão 4.
A MIT disponibilizou uma implementação livre sob licença BSD. Autoridades Norte-americanas/Estadundenses proibiram o uso do Kerberos, pois esse utiliza um algoritmo de criptografia com uma chave de 56-bit, chamado DES.
Eles consideraram que o protocolo prejudica a segurança nacional, porque impede que mensagens interceptadas sejam entendidas (Assim como qualquer aplicativo que utilize criptografia com chave maior que 40-bit). Uma implementação não americana do Kerberos, KTH-KRB foi desenvolvida pela Royal Institute of Technology na Suécia, tornando assim o sistema disponível fora dos EUA, até a mudança da regulamentação de exportação de criptografias.
A implementação Sueca é baseada em uma versão chamada eBones. eBones é baseado em um release da versão eBones da MIT (Retirado a criptografia e as chamadas a mesma) que por sua vez foi baseado na versão 4 do Kerberos atualização 9. Esse Kerberos limitado é chamado hoje como eBones. Uma implementação chamada Heimdal, foi feita basicamente, pelo mesmo grupo de pessoas e é baseada na versão 5 do Kerberos.
Windows 2000, Windows XP e o Windows Server 2003 utilizam uma variante do Kerberos, como seu método de autenticação padrão. As adições feitas no conjunto de protocolos do Kerberos pela Microsoft são documentadas no RFC 3244 chamado “Microsoft Windows 2000 Kerberos change Password and Set Password Protocols”. O Mac OS X da Apple também usa o Kerberos, tanto o cliente como o servidor.
Em 2005, o grupo chamado IETF “IETF Kerberos Workgroup” atualizou as especificações Kerberos. As atualizações incluem:
A versão 5 foi projetada por John Kohl e Clifford Neuman e publicada em 1993 no RFC 1510 (Ficou obsoleto ao RFC 4120 de 2005), e teve como intenção melhorar a segurança e as limitações relativas a versão 4.
A MIT disponibilizou uma implementação livre sob licença BSD. Autoridades Norte-americanas/Estadundenses proibiram o uso do Kerberos, pois esse utiliza um algoritmo de criptografia com uma chave de 56-bit, chamado DES.
Eles consideraram que o protocolo prejudica a segurança nacional, porque impede que mensagens interceptadas sejam entendidas (Assim como qualquer aplicativo que utilize criptografia com chave maior que 40-bit). Uma implementação não americana do Kerberos, KTH-KRB foi desenvolvida pela Royal Institute of Technology na Suécia, tornando assim o sistema disponível fora dos EUA, até a mudança da regulamentação de exportação de criptografias.
A implementação Sueca é baseada em uma versão chamada eBones. eBones é baseado em um release da versão eBones da MIT (Retirado a criptografia e as chamadas a mesma) que por sua vez foi baseado na versão 4 do Kerberos atualização 9. Esse Kerberos limitado é chamado hoje como eBones. Uma implementação chamada Heimdal, foi feita basicamente, pelo mesmo grupo de pessoas e é baseada na versão 5 do Kerberos.
Windows 2000, Windows XP e o Windows Server 2003 utilizam uma variante do Kerberos, como seu método de autenticação padrão. As adições feitas no conjunto de protocolos do Kerberos pela Microsoft são documentadas no RFC 3244 chamado “Microsoft Windows 2000 Kerberos change Password and Set Password Protocols”. O Mac OS X da Apple também usa o Kerberos, tanto o cliente como o servidor.
Em 2005, o grupo chamado IETF “IETF Kerberos Workgroup” atualizou as especificações Kerberos. As atualizações incluem:
- "Encryption and Checksum Specifications" (RFC 3961),
- "Advanced Encryption Standard (AES) Encryption for Kerberos 5" (RFC 3962),
- Uma nova edição da especificação do Kerberos versão 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Essa versão substitui o RFC 1510, tornando a especificação do protocolo mais transparente e o explicando de modo mais detalhado e limpo.
- Uma nova edição de especificação do GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).
Desenvolvimento: (by INEM)
O Kerberos é um complexo protocolo de autenticação existente em servidores windows nomeadamente 2000/2003 e 2008 que é devidamente descrito no RFC 1510 que pode ser consultado em: http://tools.ietf.org/html/rfc1510 .
Com a chegada do windows server 2000 em meados do ano 2000, o protocol LM e NTLM cairam em desuso para dar lugar a um protocolo de encriptação muito mais poderoso que se chama Kerberos. Este protocol passou a fazer parte dos sistemas operativos windows XP, 2000, 2003 e mais tarde do windows server 2008.
O Kerberos utiliza basicamente o protocolo Needham-Schroeder. O sistema de confiança tripla é chamado de Centro de Distribuição de Chaves (CDC), que é composta por duas partes separadas: um Servidor de Autenticação (SA) e Servidor de Concessão de Ticket (SCT). O Kerberos trabalha baseado em Tickets, que identificam os usuários.
O CDC mantém um banco de dados de chaves secretas; toda entidade de rede – tanto clientes como servidores – compartilham uma chave secreta que é apenas conhecido por eles mesmos e pelo CDC. O conhecimento da chave secreta pelo CDC é necessário para a identificação das entidades de rede. Para a comunicação entre as entidades o CDC gera uma chave de sessão temporária, que serve para garantir a privacidade das informações. (wikipédia).
Em uma sessão de domínio onde temos um cliente que pode ser uma workstation ou um vulgar desktop e um DC-Domaind Controller efectuando o papel de AD- Active directory, podemos verificar que a autenticação é sempre realizada por meio do Kerberos de forma transparente e segura para o usuário.
Esta autenticação não é visivel ao usuário final, no entanto a microsoft disponibiliza algumas ferramentas no “Resource Kit” para se poder realizar um “troubleshooting” efectivo e esclarecedor.
Neste tutorial eu vou apenas descrever e mostrar as ferramentas microsoft, deixando todo o funcionamento e protocolos, para os textos com as devidas fontes no final deste artigo para serem consultados com mais detalhe, limitando-me a apresentar somente as ferramentas kerbtray.exe e klist.exe.
Para começar precisamos de eleger um standalone server a um DC- controlador de domínio, e de seguida inserir uma máquina cliente no AD, de modo a que em um próximo logon do windows se consiga visualizar os respectivos tickets.Com a chegada do windows server 2000 em meados do ano 2000, o protocol LM e NTLM cairam em desuso para dar lugar a um protocolo de encriptação muito mais poderoso que se chama Kerberos. Este protocol passou a fazer parte dos sistemas operativos windows XP, 2000, 2003 e mais tarde do windows server 2008.
O Kerberos utiliza basicamente o protocolo Needham-Schroeder. O sistema de confiança tripla é chamado de Centro de Distribuição de Chaves (CDC), que é composta por duas partes separadas: um Servidor de Autenticação (SA) e Servidor de Concessão de Ticket (SCT). O Kerberos trabalha baseado em Tickets, que identificam os usuários.
O CDC mantém um banco de dados de chaves secretas; toda entidade de rede – tanto clientes como servidores – compartilham uma chave secreta que é apenas conhecido por eles mesmos e pelo CDC. O conhecimento da chave secreta pelo CDC é necessário para a identificação das entidades de rede. Para a comunicação entre as entidades o CDC gera uma chave de sessão temporária, que serve para garantir a privacidade das informações. (wikipédia).
Em uma sessão de domínio onde temos um cliente que pode ser uma workstation ou um vulgar desktop e um DC-Domaind Controller efectuando o papel de AD- Active directory, podemos verificar que a autenticação é sempre realizada por meio do Kerberos de forma transparente e segura para o usuário.
Esta autenticação não é visivel ao usuário final, no entanto a microsoft disponibiliza algumas ferramentas no “Resource Kit” para se poder realizar um “troubleshooting” efectivo e esclarecedor.
Neste tutorial eu vou apenas descrever e mostrar as ferramentas microsoft, deixando todo o funcionamento e protocolos, para os textos com as devidas fontes no final deste artigo para serem consultados com mais detalhe, limitando-me a apresentar somente as ferramentas kerbtray.exe e klist.exe.
Eu neste exemplo apenas promovi um servidor windows server 2003 a PDC da minha floresta, não elegendo nenhuma máquina cliente a ter permissão de se logar no dominio que no meu caso é teste.local.
Contudo podemos verificar que o Próprio PDC- Primary Domain Controller que é por sua vez o KDC- Kerberos Distribution Center do meu domínio vai originar dois tickets para os seguintes serviços: host e krbtgt. O krbtg é o próprio serviço de kerberos então por norma não se define como serviço de ele próprio, mas consta de igual forma do kerberos tickets.
Serviços como por exemplo IAM$, Common Internet File System (CIFS) e LDAP são normais de verificarem nos tickets gerados pelos KDC, pois são serviços que são solicitados pelas estações clientes onde se vai gerar um TGT- Ticket granting Ticket para o protocol Kerberos se poder implementar durante as autenticações do mesmo.
É certo que o Kerberos v5 é um protocol excelente e muito utilizado nas comunicações de tecnologia cliente-cliente e cliente-servidor, contudo tem falhas de segurança grosseiras que muitos administradores de rede e de infraestrutura desconhecem...
Eu neste tutorial vou-me limitar a falar de uma delas, não vou fornecer nenhuma forma mágica para desencriptar este tipo de autenticação, mas vou falar de um erro que parece simples, mas faz toda a diferença. Ora vejamos:
Quando um Cliente tem necessidade de se autenticar junto de um File Server por exemplo, para fazer o download ou apenas consulta de algum ficheiro contido nele (permissões de Leitura apenas), ele tem duas formas possíveis; ou realiza o acesso através do SMB- send message block pela porta TCP445 um mapeamento a esse “shared drive”, ou tenta simplesmente ter acesso a ele pelos seus locais de rede.
Agora o que acontece é que ele tem que se autenticar primeiro junto do servidor em questão (NetLogon) para de seguida caso a autenticação tenha sucesso, se poder gerar um TGT para o serviço solicitado que no caso é CIFS- Common Internet File System.
O problema reside precisamente aqui, vamos supor hipotéticamente que em outro ponto da rede nesta comunicação particular TCP/IP, temos um intruso com um sniffer de rede ligado a um switch onde também está a ligado a uma porta etternet o nosso File Server. “Esse sniffer por exemplo pode ser o ettercap, um belo sniffer por sinal para este tipo de invasões”.
Bom, à primeira vista está tudo bem, pois os dados vão ser encriptados e a própria autenticação por Kerberos tem segurança que não deixa trafegar os dados em “plaint text”, certo?
A resposta é certo! Está tudo bem, até que alguém está com um problema enorme de obter a leitura de um documento importante e o DNS-Domain Name System está com um problema nos seus “Resource Records” que foram previamente registados por “Dynamic Update” dentro de uma zona segura apenas.
Bem, até aqui está tudo certo, mas tem aqui um grande mas...porque esse “Resource Record” do tipo “Host” que traduz o hostname do file server em questão para o IP address respectivo não se encontra neste momento no nosso Controlador de dominio PDC.
Um dos factos pode ter sido a eliminação desse recurso por descuido ou existiu uma falha no servidor que permitio o “Aging and Scavening” entrar em acção e limpar os recursos que estavam com um “timestamp” para mais de 14 dias o “default” no windows server.
Neste caso, o administrador de redes que está no local para resolver o problema rapidamente vai dar ao usuário o IP do File Server e é aqui que toda a política de segurança e afins entra em colapso.
Com esta simples e inofensiva resolução do problema, o administrador acabou por abrir uma brecha na nossa rede, pois ao dizer o IP do file Server ele permitiu os seguintes pontos:
- A autenticação passou imediatamente de Kerberos para NTLM.
- O Invasor captou os pacotes NTLM da autenticação em vez dos pacotes Kerberos.
- Aumentou em muito a possibilidade deste acesso ser quebrado como vamos ver em seguida
Nesta imagem podemos ver a share file aberta assim como o Protocolo SMB em uso.
Podemos também ver nesta imagem que o protocolo de Autenticação de facto usado na partilha dos ficheiros é o NTLM, susceptível de ser quebrado muito mais facilmente do que o Kerberos v5. Até porque o cliente quando armazena os tickets proveniente da comunicação com o KDC, eles não são fisicamente gravados em discos, não sendo possível paginar os mesmos como acontece com o ficheiro SAM que armazenam as credencias das contas locais quando um computador não pertence a um domínio, mas sim a um workgroup.
Como tal tentar encontrar os tickets e quebrá-los não é uma forma viável neste tipo de autenticação, existem outras!!
Para concluir esta parte do tutorial quero deixar uma ideia de algumas ferramentas que podem ser utilizadas neste tipo de quebra de senhas LM ou NTLM, mas como a intenção do tutorial não é fazer referências extensas a programas de "cracker" e sim explicar o funcionamento do Kerberos, vou só deixar 2 programas que podem utilizar nos vossos testes.
Cain & Abel
Hydra
Esta ultima ferramenta é a minha preferida, pois suporta muitos protocolos de rede, mas ao mesmo tempo é uma ferramenta muito perigosa se cair em mãos erradas.
Protocolos suportados:
TELNET, FTP, HTTP, HTTPS, HTTP-PROXY, SMB, SMBNT, MS-SQL, MYSQL, REXEC,
RSH, RLOGIN, CVS, SNMP, SMTP-AUTH, SOCKS5, VNC, POP3, IMAP, NNTP, PCNFS,
ICQ, SAP/R3, LDAP2, LDAP3, Postgres, Teamspeak, Cisco auth, Cisco enable,
LDAP2, Cisco AAA (incorporated in telnet module).
TELNET, FTP, HTTP, HTTPS, HTTP-PROXY, SMB, SMBNT, MS-SQL, MYSQL, REXEC,
RSH, RLOGIN, CVS, SNMP, SMTP-AUTH, SOCKS5, VNC, POP3, IMAP, NNTP, PCNFS,
ICQ, SAP/R3, LDAP2, LDAP3, Postgres, Teamspeak, Cisco auth, Cisco enable,
LDAP2, Cisco AAA (incorporated in telnet module).
Utilização do Kerberos:
Os seguintes softwares podem utilizar Kerberos para a autenticação:
O Protocolo:
Qualquer um pode especificar o protocolo utilizando a notação de protocolo de segurança, onde Alice(A) se autentica com Bob(B) utilizando um servidor S. Onde:
Funcionamento efectivo do Kerberos:
A seguir, é descrito o funcionamento do protocolo passo a passo.
As seguintes nomenclaturas serão usadas:
Em mais detalhes:
Limitações do Kerberos:
Ponto de falha único: É necessária uma disponibilidade contínua do servidor central. Quando o servidor do Kerberos está indisponível, ninguém pode mais se autenticar na rede. Isso pode ser resolvido utilizando diversos servidores Kerberos.
O Kerberos necessita que os relógios internos dos clientes estejam sincronizados com o dele. Os Tickets têm um tempo de vida, e se o relógio do cliente não estiver sincronizado com o do servidor, a autenticação irá falhar.
Na configuração padrão, é necessário que os relógios dos clientes não tenham uma diferença maior do que 5 minutos. Na prática, servidores NTP são utilizados para manter os relógios do servidor e dos clientes sincronizados.
Eu utilizei uma ferramenta do “resource Kit” precisamente para mostrar a hora exacta do nosso servidor de dominio teste.local.
---------------------------------------------------------------------------------------
Kerberos Operation
Finally, having acquired the concepts described in the preceding paragraphs, it is possible to discuss how Kerberos operates. We'll do this by listing and describing each of the packets which go between the client and KDC and between client and application server during authentication. At this point, it is important to underline that an application server never communicates directly with the Key Distribution Center: the service tickets, even if packeted by TGS, reach the service only through the client wishing to access them. The messages we will discuss are listed below (see also the figure below):
Now each of the previous phases is described in greater detail with reference to Kerberos 5, but pointing out the differences with version 4. Nevertheless, it should be borne in mind that the Kerberos protocol is rather complicated and this document is not intended as a guide for those who wish to know the exact operating details (in any case, these are already written up in RFC1510). The discussion below has been left intentionally abstract, but sufficient for those who examine the KDC logs to understand the various authentication transitions and any problems which occur.
Note: the subsequent paragraphs enclose unencrypted data in round brackets (), and encrypted data in curly brackets {}: ( x, y, z ) means that x, y, z are unencrypted; { x, y, z }K indicates that x, y, z are encrypted all together using the symmetrical key K. It is also important to note that the order in which the components are listed in a packet has nothing to do with the real order found in the actual messages (UDP or TCP). This discussion is very abstract. Should you wish further details, please refer to RFC1510 having a good background on the descriptive protocol ASN.1
Authentication Server Request (AS_REQ)
In this phase, known as the initial authentication request, the client (kinit) asks the KDC (more specifically the AS) for a Ticket Granting Ticket. The request is completely unencrypted and looks like this:
AS_REQ = ( PrincipalClient , PrincipalService , IP_list , Lifetime )
where: PrincipalClient is the principal associated with the user seeking authentication (e.g. pippo@EXAMPLE.COM); PrincipalService is the principal associated to the service the ticket is being asked for and thus is the string "krbtgt/REALM@REALM" (see note*); IP_list is a list of IP addresses that indicate the host where it is possible to use the ticket which will be issued (see note **); Lifetime is the maximum validity time (requested) for the ticket to be issued.
Note *: it may seem superfluous to add the Principalservice to the initial authentication request since this would be constantly set to the TGS principal i.e. krbtgt/REALM@REALM. However, this is not the case, indeed, a user planning to use just one service during a work session, would not use the Single Sign-on, and may ask the AS directly for the ticket for this service, thus skipping the subsequent request to the TGS. From an operational standpoint (MIT 1.3.6) the following command is sufficient: kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM
Note **: IP_list may also be null. In this case the corresponding ticket can be used by any machine. This resolves the problem of those clients under NAT, since their request would arrive at the service with a source address different from that of the requesting user, but the same as the router making the NAT. Instead, in the case of machines with more than one network card, IP_list should contain the IP addresses of all the cards: in fact it would be difficult to predict beforehand with which connection the server which provides the service would be contacted.
Authentication Server Reply (AS_REP)
When the previous request arrives, the AS checks whether PrincipalClient and PrincipalService exist in the KDC database: if at least one of the two does not exist an error message is sent to the client, otherwise the Authentication Server processes the reply as follows:
It may seem that this message contains redundant information (PrincipalService, timestamp, lifetime and session key). But this is not the case: since the information present in the TGT is encrypted using the secret key for the server, it cannot be read by the client and needs to be repeated. At this point, when the client receives the reply message, it will ask the user to enter the password.
The salt is concatenated with the password and then the string2key function is applied: with the resulting key an attempt is made to decrypt the part of the message encrypted by the KDC using the secret key of the user stored in the database. If the user is really who he/she says, and has thus entered the correct password, the decrypting operation will be successful and thus the session key can be extracted and with the TGT (which remains encrypted) stored in the user's credential cache.
Note *: the actual lifetime, i.e. which is put in the ticket is the lowest of the following values: the lifetime requested by the client, the one contained in the user's principal and that in the service principal. Actually in terms of implementation another limit can be set from the configuration of the KDC and applied to any ticket.
Ticket Granting Server Request (TGS_REQ)
At this point, the user who has already proved to be who he/she says (thus in his/her credential cache there is a TGT and session key SKTGS and wants to access the service but does not yet have a suitable ticket, sends a request (TGS_REQ) to the Ticket Granting Service constructing it as follows:
Ticket Granting Server Reply (TGS_REP)
When the previous request arrives, the TGS first verifies that the principal of the requested service (PrincipalService) exists in the KDC database: If it exists, it opens the TGT using the key for krbtgt/REAM@REALM and extracts the session key (SKTGS) which it uses to decrypt the authenticator. For the service ticket to be issued it checks that the following conditions have a positive outcome:
When the client receives the reply, having in the credential cache the session key SKTGS, it can decrypt the part of the message containing the other session key and memorise it together with the service ticket TService which, however, remains encrypted.
Os seguintes softwares podem utilizar Kerberos para a autenticação:
- AFS
- Apache (com o módulo mod_auth_kerb)
- Apache 2 (usando libapache-mod-auth-kerb)
- Roteadores e Switches Cisco utilizando IOS
- Coda File System
- Eudora
- Mac OS X
- Microsoft Windows (2000 e posteriores) utiliza como protocolo de autenticação padrão
- Mulberry, um cliente de e-mail desenvolvido por Cyrusoft, Inc.
- NFS (Desde NFSv3)
- OpenSSH (with Kerberos v5 or higher)
- PAM (com o módulo pam_krb5)
- Samba Desde v3.x
- SOCKS (Desde SOCKS5)
- Netatalk
- As implementações X Window System
- Indire(c)tamente, qualquer software que possa utilizar o SASL para autenticação, como o OpenLDAP, DovecotIMAP4 e servidores POP3, Servidor de e-mail Postfix
- O suíte de aplicativos Kerberos já vem com os clientes e servidores habilitados para rsh, FTP, e Telnet
- Qualquer software baseado em Java (Desde 1.4.2) utilizando JAAS/JGSS pode utilizar o Kerberos para a sua segurança, veja http://java.sun.com/javase/6/docs/te...le-signon.html
O Protocolo:
Qualquer um pode especificar o protocolo utilizando a notação de protocolo de segurança, onde Alice(A) se autentica com Bob(B) utilizando um servidor S. Onde:
- KAS é uma chave pré-estabelecida somente conhecida por A e S;
- Como também KBS é somente conhecido por B e S;
- KAB é uma chave de sessão entre A e B, gerada a cada vez que o protocolo é utilizado;
- TS e TA são marcas temporais geradas por S e por A, respectivamente;
- L é um 'lifespan' definindo o tempo de vida da marca temporal.
Funcionamento efectivo do Kerberos:
A seguir, é descrito o funcionamento do protocolo passo a passo.
As seguintes nomenclaturas serão usadas:
- SA = Servidor de Autenticação (DC)
- SCT = Servidor de Concessão de Ticket (KDC)
- SS = Servidor de Serviço (File Server por ex.)
- cliente = Aplicação cliente do kerberos no sistema
Em mais detalhes:
- O usuário coloca o nome de usuário e a senha no cliente.
- O cliente aplica uma criptografia de mão única na senha digitada, e isso se torna a chave secreta do cliente.
- O cliente envia uma solicitação de serviço, através de uma mensagem em texto-plano, ao SA. Exemplo de mensagem: “O usuário XYZ gostaria de receber um serviço”. Nota: Nem a chave secreta, nem a senha são enviadas ao SA.
- O SA verifica se o cliente está em sua base de dados. Se estiver, ele manda as seguintes duas mensagens ao cliente:
- Mensagem A: Chave de sessão Cliente/SCT criptografada usando a chave secreta do usuário.
- Mensagem B: Ticket de Concessão (Que inclui a ID do cliente, endereço de rede do cliente, validade do ticket e a Chave de sessão Cliente/SCT) criptografado utilizando a chave secreta do SCT.
- Somente após o cliente receber a mensagem A e B, ele descriptografa a mensagem A e obtém a Chave de sessão Cliente/SCT. Essa chave de sessão será utilizada em comunicações futuras com o SCT. (Nota: O cliente não consegue descriptografar a mensagem B, pois essa é criptografada utilizando a chave secreta do SCT). A partir desse momento, o cliente tem informações o suficiente para se autenticar no SCT.
- Após requisitar o serviço, o cliente envia as seguintes duas mensagens ao SCT:
- Mensagem C: Composta pelo Ticket de Concessão vinda da mensagem B e o ID do serviço requisitado.
- Mensagem D: O Autenticador (que é composto do ID do cliente e a marca temporal), criptografado utilizando a Chave de sessão Cliente/SCT.
- Após receber as mensagens C e D, o SCT descriptografa a mensagem B com sua chave secreta e a mensagem D (O Autenticador) utilizando a Chave de sessão Cliente/SCT da mensagem B, verifica se os dados das mensagens conferem com os dados de quem enviou os pacotes e, caso esteja tudo certo, envia as seguintes duas mensagens ao cliente:
- Mensagem E: Ticket Cliente-para-Servidor (que inclui o ID do cliente, endereço de rede do cliente, período válido, e uma chave de sessão Cliente/Servidor) criptografado utilizando a chave secreta do serviço.
- Mensagem F: Chave de sessão Cliente/Servidor criptografado utilizando a chave de sessão Cliente/SCT.
- Após receber as mensagens E e F do SCT, o cliente tem informações suficiente para se autenticar no SS (Nota: O cliente não consegue descriptografar a mensagem E, pois essa é criptografada utilizando a chave secreta do SS). Assim, o cliente se conecta no SS e envia as seguintes mensagens:
- Mensagem E do passo anterior (o Ticket Cliente-para-servidor, criptografado utilizando a chave secreta do serviço) .
- Mensagem G: Um novo Autenticador, que inclui o ID do cliente, uma marca temporal, criptografados com chave de sessão Cliente/Servidor
- Após receber as mensagens, SS descriptografa a mensagem E e, com o Ticket Cliente-para-Servidor que estava nesta, descriptografa a mensagem G. Novamente os dados das mensagens são comparados com os dados de quem as envia e, caso esteja tudo certo, uma mensagem de confirmação, codificada com a Chave de sessão Cliente/Servidor, é enviada ao cliente contendo a marca temporal recebida na mensagem G incrementada em uma unidade.
- O cliente descriptografa a confirmação utilizando a chave compartilhada com o servidor e verifica se a marca temporal está atualizado corretamente. Se tiver, o cliente pode confiar no servidor e começa a pedir serviços ao mesmo.
- O Servidor retorna os serviços solicitados pelo cliente.
Limitações do Kerberos:
Ponto de falha único: É necessária uma disponibilidade contínua do servidor central. Quando o servidor do Kerberos está indisponível, ninguém pode mais se autenticar na rede. Isso pode ser resolvido utilizando diversos servidores Kerberos.
O Kerberos necessita que os relógios internos dos clientes estejam sincronizados com o dele. Os Tickets têm um tempo de vida, e se o relógio do cliente não estiver sincronizado com o do servidor, a autenticação irá falhar.
Na configuração padrão, é necessário que os relógios dos clientes não tenham uma diferença maior do que 5 minutos. Na prática, servidores NTP são utilizados para manter os relógios do servidor e dos clientes sincronizados.
Eu utilizei uma ferramenta do “resource Kit” precisamente para mostrar a hora exacta do nosso servidor de dominio teste.local.
---------------------------------------------------------------------------------------
Visão do Kerberos em Inglês
Kerberos Operation
Finally, having acquired the concepts described in the preceding paragraphs, it is possible to discuss how Kerberos operates. We'll do this by listing and describing each of the packets which go between the client and KDC and between client and application server during authentication. At this point, it is important to underline that an application server never communicates directly with the Key Distribution Center: the service tickets, even if packeted by TGS, reach the service only through the client wishing to access them. The messages we will discuss are listed below (see also the figure below):
- AS_REQ is the initial user authentication request (i.e. made with kinit) This message is directed to the KDC component known as Authentication Server (AS);
- AS_REP is the reply of the Authentication Server to the previous request. Basically it contains the TGT (encrypted using the TGS secret key) and the session key (encrypted using the secret key of the requesting user);
- TGS_REQ is the request from the client to the Ticket Granting Server (TGS) for a service ticket. This packet includes the TGT obtained from the previous message and an authenticator generated by the client and encrypted with the session key;
- TGS_REP is the reply of the Ticket Granting Server to the previous request. Located inside is the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS and encrypted using the previous session key generated by the AS;
- AP_REQ is the request that the client sends to an application server to access a service. The components are the service ticket obtained from TGS with the previous reply and an authenticator again generated by the client, but this time encrypted using the service session key (generated by TGS);
- AP_REP is the reply that the application server gives to the client to prove it really is the server the client is expecting. This packet is not always requested. The client requests the server for it only when mutual authentication is necessary.
Now each of the previous phases is described in greater detail with reference to Kerberos 5, but pointing out the differences with version 4. Nevertheless, it should be borne in mind that the Kerberos protocol is rather complicated and this document is not intended as a guide for those who wish to know the exact operating details (in any case, these are already written up in RFC1510). The discussion below has been left intentionally abstract, but sufficient for those who examine the KDC logs to understand the various authentication transitions and any problems which occur.
Note: the subsequent paragraphs enclose unencrypted data in round brackets (), and encrypted data in curly brackets {}: ( x, y, z ) means that x, y, z are unencrypted; { x, y, z }K indicates that x, y, z are encrypted all together using the symmetrical key K. It is also important to note that the order in which the components are listed in a packet has nothing to do with the real order found in the actual messages (UDP or TCP). This discussion is very abstract. Should you wish further details, please refer to RFC1510 having a good background on the descriptive protocol ASN.1
Authentication Server Request (AS_REQ)
In this phase, known as the initial authentication request, the client (kinit) asks the KDC (more specifically the AS) for a Ticket Granting Ticket. The request is completely unencrypted and looks like this:
AS_REQ = ( PrincipalClient , PrincipalService , IP_list , Lifetime )
where: PrincipalClient is the principal associated with the user seeking authentication (e.g. pippo@EXAMPLE.COM); PrincipalService is the principal associated to the service the ticket is being asked for and thus is the string "krbtgt/REALM@REALM" (see note*); IP_list is a list of IP addresses that indicate the host where it is possible to use the ticket which will be issued (see note **); Lifetime is the maximum validity time (requested) for the ticket to be issued.
Note *: it may seem superfluous to add the Principalservice to the initial authentication request since this would be constantly set to the TGS principal i.e. krbtgt/REALM@REALM. However, this is not the case, indeed, a user planning to use just one service during a work session, would not use the Single Sign-on, and may ask the AS directly for the ticket for this service, thus skipping the subsequent request to the TGS. From an operational standpoint (MIT 1.3.6) the following command is sufficient: kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM
Note **: IP_list may also be null. In this case the corresponding ticket can be used by any machine. This resolves the problem of those clients under NAT, since their request would arrive at the service with a source address different from that of the requesting user, but the same as the router making the NAT. Instead, in the case of machines with more than one network card, IP_list should contain the IP addresses of all the cards: in fact it would be difficult to predict beforehand with which connection the server which provides the service would be contacted.
Authentication Server Reply (AS_REP)
When the previous request arrives, the AS checks whether PrincipalClient and PrincipalService exist in the KDC database: if at least one of the two does not exist an error message is sent to the client, otherwise the Authentication Server processes the reply as follows:
- It randomly creates a session key which will be the secret shared between the client and the TGS. Let's say SKTGS;
- It creates the Ticket Granting Ticket putting inside it the requesting user's principal, the service principal (it is generally krbtgt/REALM@REALM, but read the note* for the previous paragraph), the IP address list (these first three pieces of information are copied as they arrive by the AS_REQ packet), date and time (of the KDC) in timestamp format, lifetime (see note*) and lastly the session key. SKTGS; the Ticket Granting Ticket thus appears as follows:
- It generates and sends the reply containing: the ticket created previously, encrypted using the secret key for the service (let's call it KTGS); the service principal, timestamp, lifetime and session key all encrypted using the secret key for the user requesting the service (let's call it KUser). In summary:
It may seem that this message contains redundant information (PrincipalService, timestamp, lifetime and session key). But this is not the case: since the information present in the TGT is encrypted using the secret key for the server, it cannot be read by the client and needs to be repeated. At this point, when the client receives the reply message, it will ask the user to enter the password.
The salt is concatenated with the password and then the string2key function is applied: with the resulting key an attempt is made to decrypt the part of the message encrypted by the KDC using the secret key of the user stored in the database. If the user is really who he/she says, and has thus entered the correct password, the decrypting operation will be successful and thus the session key can be extracted and with the TGT (which remains encrypted) stored in the user's credential cache.
Note *: the actual lifetime, i.e. which is put in the ticket is the lowest of the following values: the lifetime requested by the client, the one contained in the user's principal and that in the service principal. Actually in terms of implementation another limit can be set from the configuration of the KDC and applied to any ticket.
Ticket Granting Server Request (TGS_REQ)
At this point, the user who has already proved to be who he/she says (thus in his/her credential cache there is a TGT and session key SKTGS and wants to access the service but does not yet have a suitable ticket, sends a request (TGS_REQ) to the Ticket Granting Service constructing it as follows:
- Create an authenticator with the user principal, client machine timestamp and encrypt everything with the session key shared with the TGS, i.e.:
- Create a request packet containing: the service principal for which the ticket is needed and lifetime uncrypted; the Ticket Granting Ticket which is already encrypted with the key of the TGS; and the authenticator just created. In summary:
Ticket Granting Server Reply (TGS_REP)
When the previous request arrives, the TGS first verifies that the principal of the requested service (PrincipalService) exists in the KDC database: If it exists, it opens the TGT using the key for krbtgt/REAM@REALM and extracts the session key (SKTGS) which it uses to decrypt the authenticator. For the service ticket to be issued it checks that the following conditions have a positive outcome:
- the TGT has not expired;
- The PrincipalClient present in the authenticator matches the one present in the TGT;
- The authenticator is not present in the replay cache and has not expired;
- If IP_list is not null it checks that the source IP address of the request packet (TGS_REQ) is one of those contained in the list;
- It randomly creates a session key which will be the secret shared between the client and the service. Let's say SKService;
- It creates the service ticket, putting inside the requesting user's principal, the service principal, the list of IP addresses, the date and time (of the KDC) in timestamp format, the lifetime (as the minimum between the lifetime of the TGT and that associated with the service principal) and lastly the session key SKService. Known as TService the new ticket is:
- It sends the reply message containing: the previously created ticket, encrypted using the service secret key (let's call it KService); the service principal, timestamp, lifetime and new session key all encrypted using the session key extracted from TGT. In summary:
When the client receives the reply, having in the credential cache the session key SKTGS, it can decrypt the part of the message containing the other session key and memorise it together with the service ticket TService which, however, remains encrypted.
Application Request (AP_REQ)
The client, having the credentials to access the service (i.e. the ticket and related session key), can ask the application server for access to the resource via an AP_REQ message. It should be borne in mind that, unlike the previous messages where the KDC was involved, the AP_REQ is not standard, but varies depending on the application.
Thus, the application programmer has the job of establishing the strategy with which the client will use its credentials to prove its identity to the server. However, we can consider the following strategy by way of example:
When the previous request arrives, the application server opens the ticket using the secret key for the requested service and extracts the session key SKService which it uses to decrypt the authenticator. To establish that the requesting user is authentic and thus grant access to the service, the server verifies the following conditions:
Pre-Authentication
As seen in the description of the Authentication Server Reply (AS_REP), before distributing a ticket the KDC simply checks that the principal of the requesting user and service provider exist in the database. Then, particularly if it involves a request for a TGT, it is even easier, because krbtgt/REALM@REALM certainly exists and thus it is sufficient to know that a user's principal exists to be able to obtain a TGT with a simple initial authentication request.
Obviously, this TGT, if the request comes from an illegitimate user, cannot be used because they do not know the password and cannot obtain the session key for creating a valid authenticator. However, this ticket, obtained in such a easy way can undergo a brute-force attack in an attempt to guess the long-term key for the service the ticket is intended for.
Obviously, guessing the secret of a service is not any easy thing even with current processing powers, however, with Kerberos 5, a pre-authentication concept has been introduced to reinforce security.
Thus if the KDC policies (configurable) request pre-authentication for an initial client request, the Authentication Server replies with an error packet indicating the need to pre-authenticate. The client, in light of the error, asks the user to enter the password and resubmit the request but this time adding the timestamp encrypted with the user long term key, which, as we know, is obtained by applying the string2key to the unencrypted password after having added the salt, if there is one.
This time, the KDC, since it knows the secret key of the user, attempts to decrypt the timestamp present in the request and if it is successful and the timestamp is in line, i.e. included within the established tolerance, it decides that the requesting user is authentic and the authentication process continues normally.
It is important to note that pre-authentication is a KDC policy and thus the protocol does not necessarily require it. In terms of implementation, MIT Kerberos 5 and Heimdal have pre-authentication disabled by default, while Kerberos within Windows Active Directory and the AFS kaserver (which is a pre-authenticated Kerberos 4) request it.
The client, having the credentials to access the service (i.e. the ticket and related session key), can ask the application server for access to the resource via an AP_REQ message. It should be borne in mind that, unlike the previous messages where the KDC was involved, the AP_REQ is not standard, but varies depending on the application.
Thus, the application programmer has the job of establishing the strategy with which the client will use its credentials to prove its identity to the server. However, we can consider the following strategy by way of example:
- The client creates an authenticator containing the user principal and timestamp and encrypts everything with the session key SKService that it shares with the application server, i.e.:
- It creates a request packet containing the service ticket TService which is encrypted with its secret key and the authenticator just created. In summary:
When the previous request arrives, the application server opens the ticket using the secret key for the requested service and extracts the session key SKService which it uses to decrypt the authenticator. To establish that the requesting user is authentic and thus grant access to the service, the server verifies the following conditions:
- the ticket has not expired;
- The PrincipalClient present in the authenticator matches the one present in the ticket;
- The authenticator is not present in the reply cache and has not expired;
- If IP_list (extracted from the ticket) is not null it checks that the source IP address of the request packet (AP_REQ) is one of those contained in the list;
Pre-Authentication
As seen in the description of the Authentication Server Reply (AS_REP), before distributing a ticket the KDC simply checks that the principal of the requesting user and service provider exist in the database. Then, particularly if it involves a request for a TGT, it is even easier, because krbtgt/REALM@REALM certainly exists and thus it is sufficient to know that a user's principal exists to be able to obtain a TGT with a simple initial authentication request.
Obviously, this TGT, if the request comes from an illegitimate user, cannot be used because they do not know the password and cannot obtain the session key for creating a valid authenticator. However, this ticket, obtained in such a easy way can undergo a brute-force attack in an attempt to guess the long-term key for the service the ticket is intended for.
Obviously, guessing the secret of a service is not any easy thing even with current processing powers, however, with Kerberos 5, a pre-authentication concept has been introduced to reinforce security.
Thus if the KDC policies (configurable) request pre-authentication for an initial client request, the Authentication Server replies with an error packet indicating the need to pre-authenticate. The client, in light of the error, asks the user to enter the password and resubmit the request but this time adding the timestamp encrypted with the user long term key, which, as we know, is obtained by applying the string2key to the unencrypted password after having added the salt, if there is one.
This time, the KDC, since it knows the secret key of the user, attempts to decrypt the timestamp present in the request and if it is successful and the timestamp is in line, i.e. included within the established tolerance, it decides that the requesting user is authentic and the authentication process continues normally.
It is important to note that pre-authentication is a KDC policy and thus the protocol does not necessarily require it. In terms of implementation, MIT Kerberos 5 and Heimdal have pre-authentication disabled by default, while Kerberos within Windows Active Directory and the AFS kaserver (which is a pre-authenticated Kerberos 4) request it.
---------------------------------------------------------------------
Para terminar queria dizer apenas que existe muito mais informação sobre este assunto, pois o Kerberos hoje em dia tem um papel preponderante na salvaguarda dos interesses dos usuários e existem muitos tutoriais e softwares que explicam por uma lado como defender este protocolo ao máximo e por outro lado como quebra-lo ao máximo, conseguem ver o paradoxo?
Em referências deixo algumas das fontes que debrucei-me neste estudo assim como uma visão da Microsoft sobre o Kerberos e o NTLM.
Para terminar queria dizer apenas que existe muito mais informação sobre este assunto, pois o Kerberos hoje em dia tem um papel preponderante na salvaguarda dos interesses dos usuários e existem muitos tutoriais e softwares que explicam por uma lado como defender este protocolo ao máximo e por outro lado como quebra-lo ao máximo, conseguem ver o paradoxo?
Em referências deixo algumas das fontes que debrucei-me neste estudo assim como uma visão da Microsoft sobre o Kerberos e o NTLM.
MICROSOFT whitepaper
Autenticação Kerberos V5
O Kerberos V5 é o principal protocolo de segurança para autenticação num domínio. O protocolo Kerberos V5 verifica a identidade do utilizador a pedir autenticação e o servidor que fornece a autenticação pedida. Esta verificação dupla é também conhecida por autenticação mútua.
Descrição geral do funcionamento do Kerberos V5
O mecanismo de autenticação Kerberos V5 emite permissões de acesso aos serviços de rede. Estas permissões contêm dados encriptados, incluindo uma palavra-passe encriptada, que confirma a identidade do utilizador perante o serviço pedido. À excepção da introdução de uma palavra-passe ou das credenciais do cartão Smart Card, todo o processo de autenticação não é visível para o utilizador.
O Centro de Distribuição de Chaves (KDC, Key Distribution Center) é um serviço importante do Kerberos V5. O centro de distribuição de chaves (KDC, Key Distribution Center) é executado em cada controlador de domínio como parte do serviço de directório do Active Directory, que armazena todas as palavras-passe de clientes e outras informações de conta.
O processo de autenticação Kerberos V5 funciona do seguinte modo:
Cada controlador de domínio funciona como um KDC. Um cliente utiliza uma pesquisa do serviço DNS (Domain Name Service) para localizar o controlador de domínio disponível mais próximo. Esse controlador de domínio funciona então como o KDC preferido para o utilizador durante o início de sessão do utilizador. Se o KDC preferido ficar indisponível, o sistema localiza um KDC alternativo para fornecer autenticação.
Para mais informações sobre o modo como o Kerberos V5 fornece autenticação, consulte Kerberos Authentication Technical Reference na Referência Técnica do Windows Server 2003.
Para mais informações sobre Kerberos, consulte "Logon and Authentication" no Web site do Microsoft Windows Resource Kits.
O Kerberos V5 é o principal protocolo de segurança para autenticação num domínio. O protocolo Kerberos V5 verifica a identidade do utilizador a pedir autenticação e o servidor que fornece a autenticação pedida. Esta verificação dupla é também conhecida por autenticação mútua.
Descrição geral do funcionamento do Kerberos V5
O mecanismo de autenticação Kerberos V5 emite permissões de acesso aos serviços de rede. Estas permissões contêm dados encriptados, incluindo uma palavra-passe encriptada, que confirma a identidade do utilizador perante o serviço pedido. À excepção da introdução de uma palavra-passe ou das credenciais do cartão Smart Card, todo o processo de autenticação não é visível para o utilizador.
O Centro de Distribuição de Chaves (KDC, Key Distribution Center) é um serviço importante do Kerberos V5. O centro de distribuição de chaves (KDC, Key Distribution Center) é executado em cada controlador de domínio como parte do serviço de directório do Active Directory, que armazena todas as palavras-passe de clientes e outras informações de conta.
O processo de autenticação Kerberos V5 funciona do seguinte modo:
- Num sistema cliente, o utilizador procede à autenticação perante o KDC utilizando uma palavra-passe ou um cartão Smart Card.
- O KDC emite uma permissão de concessão de autorização (TGT) especial para o cliente. O sistema cliente utiliza esta TGT (ticket-granting ticket) para aceder ao serviço de concessão de permissão (TGS), que faz parte do mecanismo de autenticação Kerberos V5 no controlador de domínio.
- Em seguida, o TGS (ticket-granting service) emite uma permissão de serviço para o cliente.
- O cliente apresenta esta permissão de serviço ao serviço de rede pedido. A permissão de serviço comprova a identidade do utilizador perante o serviço e a identidade do serviço perante o utilizador.
Cada controlador de domínio funciona como um KDC. Um cliente utiliza uma pesquisa do serviço DNS (Domain Name Service) para localizar o controlador de domínio disponível mais próximo. Esse controlador de domínio funciona então como o KDC preferido para o utilizador durante o início de sessão do utilizador. Se o KDC preferido ficar indisponível, o sistema localiza um KDC alternativo para fornecer autenticação.
Para mais informações sobre o modo como o Kerberos V5 fornece autenticação, consulte Kerberos Authentication Technical Reference na Referência Técnica do Windows Server 2003.
Para mais informações sobre Kerberos, consulte "Logon and Authentication" no Web site do Microsoft Windows Resource Kits.
Autenticação NTLM
Num ambiente de rede, o NTLM é utilizado como o protocolo de autenticação para transacções entre dois computadores, em que um ou ambos os computadores executem o Windows NT 4.0 ou uma versão anterior. As redes com esta configuração são conhecidas pela designação modo misto, a predefinição na família do Windows Server 2003.
Como exemplos, as configurações seguintes utilizariam o NTLM como mecanismo de autenticação:
Para mais informações sobre NTLM e NTLMv2, consulte "Logon and Authentication" no Web site Microsoft Windows Resource Kits. (http://www.microsoft.com/)
Num ambiente de rede, o NTLM é utilizado como o protocolo de autenticação para transacções entre dois computadores, em que um ou ambos os computadores executem o Windows NT 4.0 ou uma versão anterior. As redes com esta configuração são conhecidas pela designação modo misto, a predefinição na família do Windows Server 2003.
Como exemplos, as configurações seguintes utilizariam o NTLM como mecanismo de autenticação:
- Um cliente do Windows 2000 ou do Windows XP Professional que procede à autenticação perante um controlador de domínio do Windows NT 4.0.
- Um cliente do Windows NT 4.0 Workstation que procede à autenticação perante um controlador de domínio do Windows 2000 ou do Windows Server 2003.
- Um cliente do Windows NT 4.0 Workstation que procede à autenticação perante um controlador de domínio do Windows NT 4.0.
- Utilizadores num domínio do Windows NT 4.0 que procedem à autenticação perante um domínio do Windows 2000 ou perante um domínio a executar a família do Windows Server 2003.
- Um cliente com o Windows 95, Windows 98 ou Windows Millennium Edition que procede à autenticação perante um controlador de domínio.
Para mais informações sobre NTLM e NTLMv2, consulte "Logon and Authentication" no Web site Microsoft Windows Resource Kits. (http://www.microsoft.com/)
Referências INEM
Fonte: http://www.zeroshell.net/eng/kerberos/ (Kerberos Funcionamento)
Fonte: http://tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/links.html (Kerberos)
Fonte: http://docs.google.com/viewer?a=v&q=cache:A4vtHdz9sFEJ:users.tkk.fi/u/autikkan/kerberos/AIWSC03_kerberos_replay_attacks.pdf+replay-attack+em+kerberos&hl=pt-PT&gl=pt&pid=bl&srcid=ADGEESj8DNhN7-yUSkJVDHPbwT8LE3xjFNO4QfzYZPDCEUknEVaV6NyHCu2zmDVY uavVdxn6rcb7QaFUweqDYtxGhFRysA_qHpbGa1JOjpEl5UKH8q Xttug0OynDr0-hGiiUh4I4w1WM&sig=AHIEtbTYNRONee2Lftbi2de6W_JHmOOF KA
(Kerberos Replay Attack)
Fonte: http://docs.google.com/viewer?a=v&q=cache:v8mQxg_KJJYJ:www.blackhat.com/presentations/bh-europe-09/Bouillon/BlackHat-Europe-09-Bouillon-Taming-the-Beast-Kerberous-whitepaper.pdf+replay-attack+em+kerberos&hl=pt-PT&gl=pt&pid=bl&srcid=ADGEESi-7sGuo_umKi8Z9UcLT1nbuzxvqQa0TFLyePlw8YsufRXu_RzsAgr8DiSTibNJyrpAcD88Qotw-ZhbOAEd0YIlaEnOpkW2ppT6MSJV59Ufsrrk26z457HedCqm0X-3f1ng2Cfx&sig=AHIEtbSRtXaK9qSJLfwAFGYcuXP82PZqow
(Kerberos Black Hat point of view)
Fonte: http://pt.wikipedia.org/wiki/Kerberos
Fonte: http://tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/links.html (Kerberos)
Fonte: http://docs.google.com/viewer?a=v&q=cache:A4vtHdz9sFEJ:users.tkk.fi/u/autikkan/kerberos/AIWSC03_kerberos_replay_attacks.pdf+replay-attack+em+kerberos&hl=pt-PT&gl=pt&pid=bl&srcid=ADGEESj8DNhN7-yUSkJVDHPbwT8LE3xjFNO4QfzYZPDCEUknEVaV6NyHCu2zmDVY uavVdxn6rcb7QaFUweqDYtxGhFRysA_qHpbGa1JOjpEl5UKH8q Xttug0OynDr0-hGiiUh4I4w1WM&sig=AHIEtbTYNRONee2Lftbi2de6W_JHmOOF KA
(Kerberos Replay Attack)
Fonte: http://docs.google.com/viewer?a=v&q=cache:v8mQxg_KJJYJ:www.blackhat.com/presentations/bh-europe-09/Bouillon/BlackHat-Europe-09-Bouillon-Taming-the-Beast-Kerberous-whitepaper.pdf+replay-attack+em+kerberos&hl=pt-PT&gl=pt&pid=bl&srcid=ADGEESi-7sGuo_umKi8Z9UcLT1nbuzxvqQa0TFLyePlw8YsufRXu_RzsAgr8DiSTibNJyrpAcD88Qotw-ZhbOAEd0YIlaEnOpkW2ppT6MSJV59Ufsrrk26z457HedCqm0X-3f1ng2Cfx&sig=AHIEtbSRtXaK9qSJLfwAFGYcuXP82PZqow
(Kerberos Black Hat point of view)
Fonte: http://pt.wikipedia.org/wiki/Kerberos
Olá prestável Bhior,
ResponderExcluirÉ um prazer o fórum underground ser parceiro aqui do teu blog, pois sabemos que todo o material que tens publicado é de alto valor e de qualidade.
Ainda maior prazer é ver um trabalho feito por mim aqui publicado, o que me dá uma satisfação ainda maior para continuar em frente, com meu trabalho.
Um bem haja para TI e felicidades para teu blog.
Abraços
INEM
Excelente artigo, eu desconhecia algumas coisas, e vou começar imediatamente minhas pesquisas.
ResponderExcluirOlá...
ResponderExcluirestou escrevendo aki...
para vcs saberem q tem gentes lendo muito seu blog!
e peço que continue, pois estou quase acabando de ver seu blog, ai quando terminar o que eu vou ver?
tipo estou vendo e aprendendo essas "receitas de bolo" que são fundamentais para quem esta começando, estou a dias lendo seu blog, ai peço q continue por favor, não pare não!
aki quem falou foi skletenblack!
valeu ai.
muito bom, otimo blog
ResponderExcluircontinue postando