IBM WebSphere Portal 多个未授权SSRF&RCE漏洞深入分析 - 网安 - 专业的网络安全产业、社区、知识平台

漏洞信息

IBM WebSphere Portal是一种用于构建和管理 Web 门户的企业软件，提供对Web内容和应用程序的访问，同时为用户提供个性化体验。IBM WebSphere Portal是WebSphere应用程序软件的一个组件。

近日网上爆出IBM WebSphere Portal 9及可能更新的版本存在多个SSRF和RCE漏洞。未授权用户可利用SSRF访问内网URL资源，认证后用户可以实现RCE。

调试环境

搭建IBM WebSphere Portal分析环境确实太费劲了。。。直接docker拉取环境并启动服务：

进入容器，找到启动脚本位于`/opt/IBM/WebSphere/AppServer/bin/startServer.sh`，取消`WAS_DEBUG`注释：

重启启动容器成功打开远程调试端口：

但是发现当端口`30015`端口启动后，远程调试端口`7777`将会关闭，经过分析发现`IBM Websphere Portal`的启动模式比较独特，`startServer.sh`启动的Java进程并不是最终的进程，它会首先启动一个Script，启动完毕后退出导致`7777`端口关闭，为了方便调试，这里想了个“笨办法“，先拷贝`java`运行进程命令，然后手动`kill`该进程，加入调试信息后，再手动启动新的Java进程，最终成功解决了远程调试问题：

未授权SSRF漏洞

存在多次SSRF漏洞，这里以其中的一个触发点为例。定位`WebSphere/wp_profile/installedApps/dockerCell/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war`，这里定义的URL规则如下：

找到一个`Servlet`：

在`com.ibm.lotus.quickr.ecm.servlet.AjaxProxy#doGet`打下断点，构造请求访问，成功触发断点：

进入`getUrl`函数：

按照上面函数的处理方式，重新构造请求：

http://***:30015/docpicker/internal_proxy/http/IP/test

最终通过`getConnection`触发HTTP请求，导致SSRF漏洞：

接口访问无需认证，但是限制为HTTP GET或者HEAD请求。完整SSRF触发点梳理如下：

GET full read SSRF:
/docpicker/internal_proxy/https/example.com/docpicker/internal_proxy/http/example.com/docpicker/internal_proxy/https/127.0.0.1:9043/ibm/console/docpicker/internal_proxy/http/127.0.0.1:9100/aa
Redirect chain - turning "bad" SSRF to "good" SSRF
/docpicker/common_proxy/http/www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247798.html?Logout&RedirectTo=http://example.com/wps/proxy/http/www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247798.html?Logout&RedirectTo=http://example.com/wps/myproxy/http/www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247798.html?Logout&RedirectTo=http://example.com/wps/common_proxy/http/www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247798.html?Logout&RedirectTo=http://example.com/wps/cmis_proxy/http/www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247798.html?Logout&RedirectTo=http://example.com/wps/contenthandler/!ut/p/digest!8skKFbWr_TwcZcvoc9Dn3g/?uri=http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247798.html?Logout&RedirectTo=http://example.com
Arbitrary HTTP method + body:
/wps/PA_WCM_Authoring_UI/proxy/http/example.com/wps/PA_WCM_Authoring_UI/proxy/https/example.com

从路径穿越到RCE

用户登录后，在`Script Application`处：

可以上传自定义样式的zip压缩包：

通过功能点很容易找到漏洞，下面从代码审计角度分析下导致漏洞的原因。经过分析对比，发现上传处理模块的代码位于`/opt/IBM/WebSphere/wp_profile/installedApps/dockerCell/wps.ear`：

`uploadForm_InputPage_NextAction`位于`_ScriptImport`，此时action取值为`uploadFormSubmitForm`，进入`com.bowstreet.webapp.engine#processAction`:

继续往下走：

上传的zip文件将缓存在`/opt/IBM/WebSphere/wp_profile/installedApps/dockerCell/wp.scriptportlet.importexport.ear/wp.sp.importexpor.war/WEB-INF/upload/`目录下，往下将调用`parseZip`来解压zip压缩包：

可以构建一个特殊的zip压缩包，网上一般建议都是使用`Evilarc`这个开源项目来生成恶意压缩包，因为这里是zip压缩方式，所以我们可以采用更加简单的方式，利用二进制编辑器修改zip文件名称，`../../`替换文件名称，保证长度一致即可。

将生成的新zip文件上传，最终通过`extractFile`函数解压文件：

路径穿越可以将文件保存到任意位置，但是在解压前在`unzipFile`函数中会检查压缩包里文件的类型：

虽然无法直接上传一些恶意后门，但是我们仍然可以写入一些自启动脚本，实现系统重启后RCE，具体过程这里不过多赘述，有兴趣的小伙伴请自行研究。