Apache JSPWiki is a leading open source Wiki engine, feature-rich and built around standard JEE components (Java, servlets, JSP), according to the Apache website. It seems to be used a common Java CMS used host websites similar to Wikipedia and seems fairly widespread.
CVE-2022-24948
We found a very tricky XSS bug that can be exploited by an unauthenticated attacker. It was difficult to exploit so we decided to share some of our findings about how we approached the exploitation.
The vulnerability resided in the username field. When a user changes their username, the username is put into a <meta> tag in the ‘content’ attribute like the following:
<meta name="wikiUserName" content='USERNAME' />
However, while double quotes and other characters that are useful for typical XSS are banned, we can still escape from the attribute using single quotes. So if we set our username to 5;URL=//evilzone.org’ http-equiv=’refresh
<meta name="wikiUserName" content='5;URL=//evilzone.org' http-equiv='refresh' />
Which causes an open redirect to evilzone.org
But one of the banned characters is a colon (:) so we can’t supply a scheme like URL=javascript:this() or data:this() or even http://evil. Even if we could have caused a redirection to the javascript: url, the latest versions of all major browsers assign “null” domain to meta, which redirects to javascript/data schemes and is useless for an XSS bug.
XSS vulnerabilities were seeming very difficult to exploit using meta tags due to everything described above. After brainstorming with the great Gareth Hayes, we became aware of one way to exploit XSS in the meta tag,
<meta onfocus=alert(1) id=x tabindex=0 style=display:block>#x
Now that is a wonderful way to trigger an XSS on meta tag. We just have to reference the id to trigger the XSS by going to http://site.com/?#x to focus on the id. One important part of the payload is the “display:block” part, and as described earlier, we can not use color (:) anywhere in the payload.
The trick we used to bypass that restriction is to look into the CSS files and look for a “class” that has “display:block” referenced to it. Looking at https://jspwiki.apache.org/css/haddock.css we found the following:
Ok, so a modified payload that doesn’t use colon looks like the following:
Username: 1000' onfocus=alert(1) id=x tabindex=0 class="form-control"
Generates the following:
<meta content='1000' onfocus=alert(1) id=x tabindex=0 class="form-control"/>
Now going to https://JSPWIKI/?#x triggers our alert.
In some versions of JSPWiki, the payload is added to a <head> tag, instead of a <body>, which doesn’t execute scripts in meta tags. For this scenario we can use the payload 10000;’ onclick=alert(12) accesskey=x> which doesn’t need colons at all.
CVE-2022-24947
Now we still need to trick the victim into changing their username to the above payload so they trigger the XSS on their account. Thanks to a misconfiguration in Apache JSPWiki , CVE-2022-24947 is a trivial to exploit CSRF vulnerability which can change the victim’s username.
Setup:
- Send victim to malicious page where CSRF vulnerability changes their username to our XSS payload
- Load homepage after a few seconds so XSS vulnerability triggers
- Use XSS payload to change email address of the victim to the attacker’s email
- Reset password using the attacker’s email address and receive password reset token to access the victim’s account
- w00t.
Timeline:
January 7th: Reported to Apache
January 13th: Initial Fix for XSS was released
February 12: Fix for CSRF was released
March 2: Public Disclosure
References:
https://lists.apache.org/thread/86p0yzopc4mw2h5bkwpt927b2c8tfq3b
https://lists.apache.org/thread/txrgykjkpt80t57kzpbjo8kfrv8ss02c
https://blogs.apache.org/foundation/date/202202