DIA#14-Ethical Hacking Tools (Metasploit- Payload)

    Continuo outra vez no tutorial da Offensive Security, desta vez, começando nos payloads. 

    

Tipos de Payloads    

    Um payload é basicamente um módulo de exploit. Para ter uma maior versatilidade, em diferentes cenários existem diferentes tipos de payloads:

• Singles: referem-se a payloads que funcionam de maneira completamente contida em si mesmos e autónoma. Como estes payloads são contidos em si mesmos, podem ser apanhados por handlers non-Metasploit como o netcat. Exemplos de singles payloads são criar um novo utilizador no target system e correr a calc.exe;  
• Stagers: criam a conexão à network entre o attacker e a victim, sendo desenhados para serem pequenos e fiáveis. Como é bastante difícil ser pequeno e fiável ao mesmo tempo, criam-se múltiplos stagers semelhantes, sendo escolhida a melhor versão consoante as circunstâncias. Um exemplo é o caso de Windows NX e NO-NX Stagers, em que existem problemas de fiabilidade para CPUs de NX e DEP e com NX stagers a serem maiores, o default tornou-se compatível com NX+Win7; 
• Stages: são componentes do payload que descarregados por módulos stagers, os vários stages de payloads proporcionam features avançadas sem limites de tamanho como por exemplo: Meterpreter, VNC Injection, and the iPhone ‘ipwn’ Shell. Os payloads do tipo stages usam automaticamente 'middle stagers', por exemplo se um "recv()"(usado para receber mesagens de sockets) falha com payloads grandes o stager recebe o middle stager e o middle stager faz um download total, o que também é melhor para RWX. 

    Para ver que tipo de payload se trata tem-se como exemplo "windows/shell_bind_tcp" que é um payload single sem stage, enquanto que "windows/shell/bind_tcp" consiste num stager (bind_tcp) e num stage(shell).

    

    Para além destes tipos de payloads existem bastantes outros, cada um com a sua função na framework, entre os quais:

• Inline(não staged): é um payload que contém o exploit e o shellcode completo para uma determinada tarefa. Estes payloads foram concebidos para serem mais estáveis, uma vez que contêm tudo, no entanto nem sempre são suportados por alguns exploits devido ao seu tamanho;  
• Stager: funcionam em conjunto com payloads stage para fazer uma tarefa, o stager estabelece um canal de comunicação entre o attacker e a vitima, lendo num payload stage o que executar no remote host;  
• Meterpreter: também conhecido como Meta-interpreter é um payload bastante avançado e com diferentes vertentes que opera por injecção de DLL(Dynamic-link library é a implementação feita pela Microsoft para o conceito de bibliotecas compartilhadas). O Meterpreter reside completamente na memória do host remoto e não deixa quaisquer vestígios na hard drive, fazendo com que seja de difícil detecção com técnicas normais. Scripts e plugins podem ser loaded ou unloaded dinamicamente, consoante a necessidade;  
• PassiveX: é um payload que ajuda a passar firewalls externas, através do uso de um ActiveX control (add-ons usados para melhorar a experiência de navegação na web, proporcionando barras de ferramentas, barras de cotação de acções, vídeo, conteúdo animado, etc) para criar um instância escondida de Internet Explorer, depois com o ActiveX controll comunica-se com o attcker via HTTP requests e responses;
• NoNX: NX(No eXecute) bit é uma funcionalidade que se encontra em alguns CPUs para prevenir algum codigo de correr em determinadas partes da memória. No windows, NX é implementado como DEP (Data Execution Prevention). As payloads de NoNX do metasploit foram concebidas para contornar o DEP;
• ORD: Mais conhecidas como Ordinal payloads payloads do windows baseadas em stagers que tem como vantagens ser compatível com qualquer linguagem ou tipo de windows desde o Windows 9x(refere-se a Windows 95, Windows 98 e Windows ME), sem ser necessário a definição explicita da um return address e para além disso são extremamente pequenas. As desvantagens que fazem com que estes payloads não sejam a escolha default são o facto de precisar de ter "ws2_32.dll" loaded no processo a ser exploited antes da exploitation e o facto de não ser tão estável como outros stagers; 
• IPv6: são payloads construídas para funcionar via networks IPv6; 
• Reflective DLL injection: é uma técnica em que um stage payload é injectado num host process comprometido a correr na memória, nunca tocando na hard drive. Tanto as payloads do VNC como do Meterpreter usam esta técnica.

Criação de payloads

    Com o Metasploit podem-se gerar payloads a partir da msfconsole. 

    Quando se usa o comando "use <nome do módulo>", o Metasploit adiciona os comandos "generate", "pry" e "reload", é possível observar isto com o uso do comando "help" depois de utilizar o comando "use", que faz aparecer, entre outros, tanto os comandos mencionados como a sua descrição. No tutorial da Offensive Security foca-se apenas no "generate".

    Como é costume, ao utilizar o comando "generate -h" é possível ver as opções do comando generate, mas caso se queira gerar shellcode sem utilizar nenhuma opção pode-se executar o comando "generate", mas a probabilidade de gerar shellcode sem mudar nada é bastante baixa, apesar disto corri esse mesmo comando para o módulo "payload/windows/shell_bind_tcp", tendo aparecido o apresentado na imagem seguinte.

    No output gerado é possível observar a existência do null byte (\x00), que é um character quase universalmente mau, uma vez  que normalmente apenas indica o fim de strings. Apesar de alguns exploits permitirem o uso de \x00, a maioria não o permite. Tendo isto em conta, vai-se gerar o mesmo shellcode mas sem os null bytes, para fazer isto usa-se o comando "generate -b <character/s to avoid>", sendo neste caso o "character to avoid" o null byte (\x00).

    Como se pode ver na imagem em cima, já não há null bytes na bind shell, também se nota que o tamanho do shellcode aumentou, sendo 27 bytes maior, isto deve-se ao facto de ser necessário durante a geração do shellcode substituir (ou codificar) a utilidade que o null byte proporcionava, de modo a ter a certeza que uma vez na memória o bind shell continua funcional.

    Outra mudança que se pode fazer é o uso de um encoder (em Metasploit o comportamento default é escolher automaticamente, o exploit que melhor se adequa à tarefa), neste caso, para remover unwanted characters que entraram quando se utilizou o "-b". Quando apenas se quer retirar o null byte usou-se o encoder "x86/shikata_ga_nai", como é possível observar na imagem anterior. Se forem adicionados mais bytes à lista obtém-se a imagem seguinte. 

    Nesta imagem pode-se ver que o encoder já é diferente, provavelmente devido ao encoder anterior não ser capaz de fazer o encoding com a lista de restricted bytes usada. Se forem escolhidos demasiados restricted bytes, em que nenhum encoder consiga realizar a tarefa, ira ocorrer um payload generation fail.

    Para poder ver os encoders existentes pode-se usar o comando "show encoders", sendo possível explicitar o encoder a usar com "generate -e <encoder a utilizar>", na imagem seguinte usou-se o encoder "x86/nonalpha".

   Se tudo correu bem o payload obtido não contém caracteres alfanuméricos, mas não se pode esquecer que ao usar um encoder diferente do default, normalmente irá resultar num payload maior que o normal, o que se verifica neste caso.

    Com o uso do comando "generate -o <diretoria onde guardar>" é possível guardar a payload gerado para um ficheiro. Na imagem seguinte é possível observar uma junção de todos os comandos mencionados até agora nas seguinte imagem.

    Que criou o documento filename.txt no Desktop, que é apresentado de seguida. 

    Continuando para o próximo comando, temos o "generate -i <número de iterações>" que informa o número de iterações de encoding que devem ser feitas antes de produzir o payload final, isto é usado para anti-virus evasion, ou stealth. De seguida apresenta-se uma imagem em que se usam duas iterações.

      

    Comparando com o anteriormente obtido, quando apenas se usou uma iteração, o payload é maior, quanto mais iterações maior o payload, olhando para os bytes da payload estes também são diferentes devido a depois do primeiro encoding fazer-se outro encoding do resultado obtido. Se utiliza-se, por exemplo, cinco iterações o tamanho iria ser ainda maior e os bytes não teriam nada a haver com os do payload original, o que teoricamente faz o payload menos provável de ser detectado.

    

    Com o uso de "generate -o <Variavel>=<valor>" pode-se configurar os ports, exitfunc, etc. Apesar de este não ser o melhor uso de "-o", o melhor uso é o mencionado anteriormente no output do ficheiro  como não encontrei outra forma ficou assim. Na imagem seguinte encontra-se um uso do comando descrito em cima.   

   Com o comando "generate -f <linguagem a utilizar>" é possível escolher que linguagem de programação o output sai, com é possível observar na imagem seguinte.

    Com o uso do comando em cima é possível copiar o código obtido para scripts, de modo a o poder utilizar.

    Uma maneira de adicionar um NOP(No Operation/ Next Operation) sled é através do uso de "generate -s <numero de NOPs>", isto irá adicionar o sled ao inicio da payload, ao adicionar NOPs está-se também a adicionar bytes ao shellcode, por exemplo, adicionar dez NOPs irá adicionar dez bytes ao tamanho total.   

    

PS:

• Bind shells: shells com o listener a correr no target, sendo o attacker que conecta ao listener de modo a obter uma remote shell;
• Reverse shells: shells com o listener a correr no attacker, sendo o target que conecta com o attacker com uma shell;
• Encrypted Shells: enquanto as shells anteriores comunicam com plaintext, esta encripta a informação de modo a ser mais difícil alguém que use um packet sniffer consiga ver o que se esta a comunicar.
•  Encoders e anti-virus evasion irão ser mencionados mais profundamente no futuro.
• Na parte de colocar o payload gerado num txt e escolher a linguagem de programação, está diferente do tutorial da Offensive Security, penso que os comandos mudaram.
• NOP Sled é uma sequência de instruções sem operação utilizados para direccionar a execução de um programa em que não se sabe em que parte do programa se vai, fazendo com que corra até chegar ao ponto desejado.