
Un laboratoire de test Vagrant VM pour apprendre sur CVE-2021-38647 dans l'agent Open Management Infrastructure (aka "omigod").
Une VM de laboratoire éducative pour apprendre la vulnérabilité d'exécution de code à distance (RCE) sans authentification (CVSS 9.6) dans le logiciel Open Management Infrastructure (CVE-2021-38647).
Divulgation (recherche originale) : https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-omi-azure
Code source d'OMI : https://github.com/microsoft/omi
actualités :
Analyse :
Lisez certains des éléments ci-dessus avant de continuer.
git clone https://github.com/craig-m-unsw/omigod-lab.git
cd omigod-lab
vagrant up
vagrant ssh
Cela configurera Ubuntu 20.04 (Focal Fossa). Merci à Roboxes pour la box Vagrant.
Installé par Ansible playbook.yml :
sha256:2e0813ee3f2a71028f071d9933ca2f336faaaf9b6126d5f1767ffcbc7e803279sha256:1cba16e3b307177cbe15bd3fd8a2a87ab8d638846988202be8a17981b5e900c9Ne mettez pas cette VM sur Internet :-)
Grâce à Vagrant, une redirection de port de localhost:5986 vers 5986 dans la VM sera ouverte après avoir démarré la box. Nous avons maintenant une VM de laboratoire pour tester.
Nous devons simplement envoyer une requête SOAP au serveur OMI vulnérable, le module Ansible uri peut être utilisé pour poster cette charge utile XML :
cd /vagrant
ansible-playbook attack-play.yml -e "rcecmd=uptime"
Vous devriez voir la sortie de la commande uptime dans <p:StdOut>.
Si vous changez la commande pour id, vous pouvez voir les sorties uid=0(root) gid=0(root) groups=0(root).
😬😬😬
Autres codes d'exploitation publics :
La documentation de démarrage de Microsoft : https://github.com/microsoft/omi/blob/master/Unix/doc/omi/omi.pdf
À l'intérieur de la VM, auditd est installé.
Journaliser toutes les exécutions de commandes :
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 sortie après envoi d'une commande :
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"
Quelqu'un a exécuté 'whoami'.
Microsoft le note dans l'article de blog « Additional Guidance Regarding OMI Vulnerabilities within Azure VM Management Extensions » sur la détection :