- Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) **groupe Discord** ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-moi** sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [dépôt hacktricks](https://github.com/carlospolop/hacktricks) et au [dépôt hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
Copie de: [https://blog.rapid7.com/2014/01/09/piercing-saprouter-with-metasploit/](https://blog.rapid7.com/2014/01/09/piercing-saprouter-with-metasploit/)
Saprouter est essentiellement un proxy inverse pour les systèmes SAP, généralement situé entre Internet et les systèmes SAP internes. Son objectif principal est de permettre un accès contrôlé depuis des 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 typique.
Cela signifie que saprouter finit généralement par être exposé à Internet, en permettant le port TCP entrant 3299 vers l'hôte saprouter sur les pare-feu de l'organisation. Et à partir du 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'accéder au réseau "à haute valeur".
Tout d'abord, nous commencerons par effectuer une analyse de service SAP de l'adresse IP exposée, en utilisant le module [`sap_service_discovery`](http://www.rapid7.com/db/modules/auxiliary/scanner/sap/sap_service_discovery), dans ce cas, 1.2.3.101.
Le scan nous montre que l'hôte exécute un routeur SAP sur le port TCP attendu 3299. Nous pouvons maintenant creuser plus profondément et essayer d'obtenir des informations à partir du saprouter. S'il a été mal configuré, et souvent c'est le cas, il peut être possible d'obtenir des informations internes, telles que des connexions établies via le saprouter vers des hôtes internes. À cette fin, nous utilisons le module [`sap_router_info_request`](http://www.rapid7.com/db/modules/auxiliary/scanner/sap/sap_router_info_request) :
Ainsi, à 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 commun 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 probablement le réseau 192.168.1.0/24, ou un sous-réseau dans ce réseau.
Avec ces informations, nous sommes maintenant en mesure de commencer à scanner le réseau interne. Comme saprouter fonctionne comme un proxy, nous allons tenter de nous y connecter et de demander des connexions à des hôtes et des ports internes, et voir les réponses de saprouter. Cela peut donner plus d'informations sur les hôtes internes, les services et les ACL, en fonction de la configuration de saprouter. Nous utiliserons le module [`sap_router_portscanner`](http://www.rapid7.com/db/modules/auxiliary/scanner/sap/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 comprend si la connexion demandée est possible ou non. Ce module fournit quelques options qui peuvent être utilisées :
Au minimum, vous devrez définir l'adresse IP du saprouter, dans le cas de 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, de sorte que chaque instance a des ports TCP assignés. Par exemple, l'instance SAP 00 aura le service de dispatcher SAP \(où 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 d'instance, permettant ainsi de scanner les ports pour toutes les instances définies. Ainsi, si nous voulons scanner les instances de 00 à 50, nous pouvons définir les variables INSTANCES et PORTS de cette manière:
Dans la source du module, vous avez des informations sur les ports par défaut couramment utilisés sur les systèmes SAP, que nous allons maintenant utiliser pour le scan :
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 sommes en mesure de voir la réponse du saprouter et de cartographier la liste de contrôle d'accès 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 :
Comme vous pouvez le constater, nous savons maintenant que nous ne pouvons pas nous connecter à un autre hôte sur le port 3200, car il est bloqué par l'ACL définie sur le saprouter.
* Native - Ces connexions sont simplement des connexions TCP ;
* Protocole SAP - Il s'agit de connexions TCP avec une particularité : le protocole indique que tous les messages commencent par 4 octets indiquant la longueur du contenu suivant.
Le protocole SAP est spécifique au saprouter et c'est ce que l'interface utilisateur SAP utilise pour se connecter au port SAP DIAG via le saprouter. Le protocole natif est utilisé pour permettre à d'autres types de connexions de passer par le saprouter.
Ce module permet de spécifier le type de connexion à tester lors de l'analyse dans l'option MODE. La valeur par défaut est le protocole SAP, qui est le plus probable à ê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\) à travers.
Nous pouvons définir le MODE sur TCP afin de vérifier si ce type de connexions est autorisé. Nous allons maintenant analyser les hôtes internes, à la fois sur le port 3200 \(SAP DIAG\) et 80 \(HTTP\), avec VERBOSE défini sur true, sur les deux instances 00 et 01 et voir ce qui se passe :
Si vous vous souvenez, nous avons commencé par obtenir des informations à partir du saprouter qui nous a 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 cette information ?
Une option consiste à simplement commencer à scanner les espaces d'adresses privées et 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 connecter. Saprouter est également assez gentil pour nous faire savoir quelles sont les erreurs lorsqu'il échoue à se connecter (vous pouvez en fait voir les réponses brutes en décommentant la ligne 242 dans la source du module).
Pour cela, nous devons définir l'option RESOLVE sur "remote". Dans ce cas, le module demandera une connexion aux CIBLES définies, sans les résoudre localement, et nous pourrons essayer de deviner les hôtes internes et éventuellement nous y connecter sans jamais connaître leurs adresses IP.
* Nous obtiendrons plus d'informations de saprouter si MODE est défini sur SAP_PROTO ;
* Il suffit de définir un seul port à scanner, car nous ne sommes intéressés pour l'instant que par les informations envoyées par 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.
À 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 que "sapsrv2" existe et que 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'utiliser des noms d'hôtes courants, tels que smtp, exchange, pdc, bdc, fileshare, intranet, ou tout autre nom d'hôte que vous pourriez avoir dans votre sac de trucs.
Maintenant que nous avons obtenu toutes ces informations, nous connaissons les hôtes internes disponibles, les services autorisés et les protocoles que nous pouvons utiliser pour percer le saprouter, nous pouvons en fait nous connecter aux serveurs internes et procéder à notre pentest.
Metasploit nous offre une excellente façon d'utiliser saprouter comme proxy, en utilisant l'option Proxies, grâce à Dave Hartley \([@nmonkee](http://twitter.com/nmonkee)\).
À ce stade, nous voulons commencer à recueillir des informations sur le serveur SAP interne que nous avons découvert sur l'hôte 192.168.1.18. À titre d'exemple, nous utiliserons le module [`sap_hostctrl_getcomputersystem`](http://www.rapid7.com/db/modules/auxiliary/scanner/sap/sap_hostctrl_getcomputersystem) qui exploite 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 :
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 (comme des noms d'utilisateur internes que vous pouvez ensuite essayer de forcer par la méthode brute).
Nous avons vu comment il est possible d'exploiter des configurations 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.
* \[[http://conference.hitb.org/hitbsecconf2010ams/materials/D2T2](http://conference.hitb.org/hitbsecconf2010ams/materials/D2T2) - Mariano Nun ez Di Croce - SAProuter .pdf\]\([http://conference.hitb.org/hitbsecconf2010ams/materials/D2T2](http://conference.hitb.org/hitbsecconf2010ams/materials/D2T2) - Mariano Nunez Di Croce - SAProuter .pdf\)
* [CVE-2013-3319 SAP Host Agent Information Disclosure \| Rapid7](http://www.rapid7.com/db/modules/auxiliary/scanner/sap/sap_hostctrl_getcomputersystem)
* [SAPRouter Port Scanner \| Rapid7](http://www.rapid7.com/db/modules/auxiliary/scanner/sap/sap_router_portscanner)
- Travaillez-vous dans une entreprise de cybersécurité? Voulez-vous voir votre entreprise annoncée dans HackTricks? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au repo [hacktricks](https://github.com/carlospolop/hacktricks) et [hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
