craig-m-unsw/omigod-labEin Vagrant-VM-Testlabor zum Lernen über CVE-2021-38647 im Open Management Infrastructure Agent (auch bekannt als „omigod“).
Eine Lab-VM für Lernzwecke, um die Schwachstelle „unauthenticated Remote Code Execution (RCE)“ mit einem CVSS-Score von 9.6 in der Open Management Infrastructure-Software (CVE-2021-38647) kennenzulernen.
Offenlegung (Originalforschung): https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-omi-azure
OMI-Quellcode: https://github.com/microsoft/omi
Neuigkeiten:
Bericht:
Lies einige der obigen Links, bevor du fortfährst.
git clone https://github.com/craig-m-unsw/omigod-lab.git
cd omigod-lab
vagrant up
vagrant ssh
Dadurch wird Ubuntu 20.04 (Focal Fossa) eingerichtet. Danke an Roboxes für die Vagrant-Box.
Installiert von Ansible playbook.yml:
sha256:2e0813ee3f2a71028f071d9933ca2f336faaaf9b6126d5f1767ffcbc7e803279sha256:1cba16e3b307177cbe15bd3fd8a2a87ab8d638846988202be8a17981b5e900c9Stelle diese VM nicht ins Internet :-)
Dank Vagrant wird nach dem Starten der Box eine Portweiterleitung von localhost:5986 auf 5986 in der VM geöffnet sein. Wir haben jetzt eine Lab-VM zum Testen.
Wir müssen lediglich eine SOAP-Anfrage an den verwundbaren OMI-Server senden. Das Ansible-uri-Modul kann verwendet werden, um diese XML-Nutzlast zu übermitteln:
cd /vagrant
ansible-playbook attack-play.yml -e "rcecmd=uptime"
Du solltest die Ausgabe des Befehls uptime in <p:StdOut> sehen.
Wenn du den Befehl in id änderst, kannst du die Ausgabe uid=0(root) gid=0(root) groups=0(root) sehen.
😬😬😬
Weiterer öffentlicher Exploit-Code:
Die Getting-Started-Doku von MS: https://github.com/microsoft/omi/blob/master/Unix/doc/omi/omi.pdf
In der VM ist auditd installiert.
Alle Befehlsausführungen protokollieren:
sudo auditctl -a exit,always -F arch=b32 -S execve -k execve
sudo auditctl -a exit,always -F arch=b64 -S execve -k execve
sudo tail -f /var/log/audit/audit.log
Die Ausgabe beim Senden eines Befehls:
type=SYSCALL msg=audit(1631977306.937:107): arch=c000003e syscall=59 success=yes exit=0 a0=7f906c002570 a1=7f906c001330 a2=7fffe5148108 a3=7f90751453f0 items=2 ppid=8552 pid=9974 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/dash" key="execve"
type=EXECVE msg=audit(1631977306.937:107): argc=3 a0="/bin/sh" a1="-c" a2="whoami"
type=CWD msg=audit(1631977306.937:107): cwd="/var/opt/microsoft/scx/tmp"
type=PATH msg=audit(1631977306.937:107): item=0 name="/bin/sh" inode=5374016 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1631977306.937:107): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=5377053 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PROCTITLE msg=audit(1631977306.937:107): proctitle=2F62696E2F7368002D630077686F616D69
type=SYSCALL msg=audit(1631977306.937:108): arch=c000003e syscall=59 success=yes exit=0 a0=564c4e436b90 a1=564c4e436b38 a2=564c4e436b48 a3=7f5b83f28850 items=2 ppid=9974 pid=9975 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="whoami" exe="/usr/bin/whoami" key="execve"
type=EXECVE msg=audit(1631977306.937:108): argc=1 a0="whoami"
type=CWD msg=audit(1631977306.937:108): cwd="/var/opt/microsoft/scx/tmp"
type=PATH msg=audit(1631977306.937:108): item=0 name="/usr/bin/whoami" inode=5374366 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1631977306.937:108): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=5377053 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PROCTITLE msg=audit(1631977306.937:108): proctitle="whoami"
Jemand hat „whoami“ ausgeführt.
Microsoft weist in dem Blogbeitrag „Additional Guidance Regarding OMI Vulnerabilities within Azure VM Management Extensions“ zur Erkennung auf Folgendes hin: