craig-m-unsw/omigod-labUn laboratorio de pruebas con una VM de Vagrant para aprender sobre CVE-2021-38647 en el agente de Open Management Infrastructure (también conocido como "omigod").
Una VM de laboratorio educativa para aprender sobre la vulnerabilidad de ejecución remota de código (RCE) no autenticada con CVSS 9.6 en el software Open Management Infrastructure (CVE-2021-38647).
Divulgación (investigación original): https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-omi-azure
Código fuente de OMI: https://github.com/microsoft/omi
noticias:
Análisis:
Lee algo de lo anterior antes de continuar.
git clone https://github.com/craig-m-unsw/omigod-lab.git
cd omigod-lab
vagrant up
vagrant ssh
Esto configurará Ubuntu 20.04 (Focal Fossa). Gracias a Roboxes por la Vagrant box.
Instalados por Ansible playbook.yml:
sha256:2e0813ee3f2a71028f071d9933ca2f336faaaf9b6126d5f1767ffcbc7e803279sha256:1cba16e3b307177cbe15bd3fd8a2a87ab8d638846988202be8a17981b5e900c9No pongas esta VM en internet :-)
Gracias a Vagrant, un reenvío de puertos en localhost:5986 al 5986 en la VM estará abierto después de levantar la caja. Ahora tenemos una VM de laboratorio con la que probar.
Solo necesitamos enviar una solicitud SOAP al servidor OMI vulnerable; se puede usar el módulo uri de Ansible para publicar este payload XML:
cd /vagrant
ansible-playbook attack-play.yml -e "rcecmd=uptime"
Deberías ver la salida del comando uptime en <p:StdOut>.
Si cambias el comando a id puedes ver las salidas uid=0(root) gid=0(root) groups=0(root).
😬😬😬
Otro código de exploit público:
La documentación de primeros pasos de Microsoft: https://github.com/microsoft/omi/blob/master/Unix/doc/omi/omi.pdf
Dentro de la VM está instalado auditd.
Registra toda ejecución de comandos:
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
La salida al enviar un comando:
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"
Alguien ha ejecutado "whoami".
Microsoft señala esto en la entrada de blog "Additional Guidance Regarding OMI Vulnerabilities within Azure VM Management Extensions" sobre la detección: