XSS in IceWarp Webmail – CVE-2017-7855

In my latest post, I am going to run through my process of identifying XSS in IceWarp Webmail during a penetration assessment.

It was a chilly Nebraska February, temperatures were slightly below average for this time of year but nothing a hot cup of cocoa couldn’t handle. I was performing, up to this point, a rather standard penetration assessment with findings that didn’t inspire much excitement. Until lo and behold, I saw successful Cross-Site Scripting in a webmail application that previous to this assessment was not a known vendor.

Ok, ok, so I’m not going to make it as a fiction book author. So, instead, let’s break down from start to finish the discovery of Cross-Site Scripting (XSS) in IceWarp Webmail I discovered this vulnerability during a penetration assessment and realized this, like the Citrix vulnerability I wrote about last time, had never been publicly disclosed or reported. So, I once again tried to take the vulnerability as far as I could with the idea of stealing a user’s session and then using those session details to access the webmail of that user. I was able to do just that by injecting JavaScript into an HTTP POST request. I noticed however, that not only did the JavaScript get reflected in one location of the application response, it was also injected right into the cookie itself. This means that there could be some continued execution for every request that also set a cookie in an HTTP response.

The initial injection point was the ‘language’ parameter within a HTTP POST request and a lack of proper input validation of this POST parameter resulted in the injected code being reflected in the response. Since the injected JavaScript was unaltered in the response, this resulted in the end user’s browser executing the injected JavaScript. Another part of this vulnerability includes how the session token was being set. Application Security Best practice indicates all session tokens should be set with both the ‘Secure’ and ‘HttpOnly’ flags to prevent session token exposure to non-TLS connections and to prevent JavaScript access to the session token.

I first discovered this vulnerability February 9, 2017. Once verified, we reported this to the vendor February 24, 2017 to which they replied immediately. IceWarp responded February 28, 2017 that they knew about one aspect of the XSS but not the other at the time. IceWarp issued a fix which I verified prevented JavaScript from executing. NTT Security recommends applying the IceWarp patch as soon as possible as it remediates this vulnerability.

REFERENCE LINKS: https://www.icewarp.com/