一个教育实验室虚拟机，用于学习 Open Management Infrastructure 软件中 9.6 CVSS 未认证远程代码执行（RCE）漏洞（CVE-2021-38647）。
披露（原始研究）：https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-omi-azure
OMI 源代码：https://github.com/microsoft/omi
新闻：
分析文章：
在继续之前，请先阅读以上部分内容。
git clone https://github.com/craig-m-unsw/omigod-lab.git
cd omigod-lab
vagrant up
vagrant ssh
这将搭建 Ubuntu 20.04（Focal Fossa）。感谢 Roboxes 提供的 Vagrant 镜像。
通过 Ansible playbook.yml 安装：
sha256:2e0813ee3f2a71028f071d9933ca2f336faaaf9b6126d5f1767ffcbc7e803279sha256:1cba16e3b307177cbe15bd3fd8a2a87ab8d638846988202be8a17981b5e900c9不要将这个虚拟机放到互联网上 :-)
借助 Vagrant，从宿主机可以通过 localhost:5986 端口转发到虚拟机内的 5986 端口。现在我们有了一个可用的实验虚拟机。
我们只需向存在漏洞的 OMI 服务器发送一个 SOAP 请求。可以使用 Ansible 的 uri 模块 来发送以下 XML 载荷：
cd /vagrant
ansible-playbook attack-play.yml -e "rcecmd=uptime"
你应该能在 <p:StdOut> 中看到 uptime 命令的输出。
如果将命令改为 id，你会看到 uid=0(root) gid=0(root) groups=0(root) 的输出。
😬😬😬
其他公开利用代码：
微软的入门文档： https://github.com/microsoft/omi/blob/master/Unix/doc/omi/omi.pdf
虚拟机内部已安装 auditd。
记录所有命令执行：
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
发送命令后的输出：
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"
有人执行了 "whoami"。
微软在其关于检测的博文《关于 Azure VM 管理扩展中 OMI 漏洞的补充指南》中提到了这一点：