插件编写和测试期间,成立几个额外的漏洞发现ManageEngine OpManager。
# 1远程DoS NMS服务器的多个方法
OpManager使用一个定制的NMS服务器用java编写运行在JVM由所有OpManager共享组件。NMS服务器FE(前端)和(后端)组件监听任意相邻端口(例如TCP端口49197、49253和49254在我们的测试)。这些服务是容易识别远程发送的请求,服务器将发送一个序列化返回响应。第一次反序列化的代码包似乎没有健康检查长度,甚至一个字段是否存在。可以向服务器发送畸形数据包重复直到JVM内存被耗尽,或引发其他错误导致JVM重启并否认服务直到管理员重新启动服务。成立创建了一个脚本(opmanager_exploit4.py春光)供应商仅仅发送输入触发此类错误导致立即崩溃,并且不需要身份验证。
# 2 NMS是远程代码执行服务器REFRESH_CLIENTCOUNT命令反序列化Java对象
这个漏洞是构建成功利用1150年和1200年。在1150年建立,JVM是足够低的版本,我们可以利用其附带一个脆弱类。1200(最新版本的测试)commons-beanutils附带一个类容易与反序列化对象代码注入。利用这个最简单的方法是通过发送一个精心制作的REFRESH_CLIENTCOUNT指挥和控制要反序列化的数据。成立创建了一个PoC,利用依赖OpManager版本payload.bin。在1200年建立,有效载荷,利用一个例子commons-beanutils执行命令的cmd / c whoami > . . /帮助/ nessus_1.txt“(在windows命令运行”nt authority) \系统默认情况下,我们听到不好)。文件可以从远程访问管理web服务器验证是成功的(如攻击。http://[目标]/帮助/ nessus_1.txt)。在1150年建立,有效负载使用JRE类工作并执行cmd。exe / C / test_nessus12345678.txt whoami >帮助”nt_authority \系统。再一次,这个文件可以从远程访问管理web服务器验证是成功的(如攻击http://(主持人):8080 /帮助/ test_nessus12345678.txt)。
OpManager还附带Apache Commons FileUpload 1.3.1 +,称为DiskFileItem包含一个对象,通常是无害的。然而,对象被序列化后可以修改行为,没有目的。具体我们可以修改DiskFileItem:
- 创建一个新文件任何Java进程的许可。
- 写任何我们想要的新文件。
- 我们也可以移动(复制和删除)远程系统上的任何文件的许可。
不过有两个局限性:
- 我们不控制文件名。这是由DiskFileItem类
upload_ uuid_ counter.tmp美元。
- 文件是使用创建的
File.createTempFile ()接口。这意味着文件的生命周期是完全依赖于使用deleteOnExit ()JVM运行多长时间,如果是创建后(如果做的是利用它仍将被删除。然而,如果所做的举动InvokerTransformer利用,它将不会被删除)。我们观察到文件生活~ 2分钟时由NetIQ前哨。
使用一个frohoff ysoserial载荷未经过身份验证的远程攻击者可以复制和删除任意文件。
# 3 TFTP服务器存储XSS未经身份验证的文件上传
默认情况下,未经过身份验证的用户可以访问通过TFTP可以上传任意文件,在“tftp_files“管理web服务器上的目录,一个身份验证的用户。上传的文件将出现在[uploaded_file] http://[目标]/ tftp_files /
这显然是不可取的,因为攻击者可以上传HTML文件包含恶意JavaScript XSS载荷,可以帮助远程攻击者获得的管理界面(例如饼干偷)。注意,web服务器将不会运行. jsp文件很不幸,但是将任何其他扩展。
# 4 TFTP服务器远程路径信息披露的弱点
小烦恼的类别,TFTP服务器还将披露完整的系统路径如果提供了一个畸形的请求。不要说我们从来没有发布poc !认为这是一个奖励读到这里:
((电子邮件保护)~]美元tftp 192.168.24.70 tftp > *错误代码1:文件未找到C: \ ManageEngine \ OpManager \ tftp_files \ *