Verizon Messages (Message+) is a group of software clients available for mobile, desktop, and web aimed at enhancing/unifying the VZW text messaging experience across multiple devices. While it has a few additional features outside of SMS, I was most interested in activating it for its web app client when at a desktop/laptop.
After I installed the Android app and signed up, I logged in to the web app and starting using it. After a while, I noticed that messages containing links were being displayed with a preview/summary embedded in both the web and mobile interfaces.
I was interested in learning more about the types of links that were supported (images, videos, etc.) and how they were parsed. It was easier to start with the web app, so I sent myself a few test links. Here’s how a few examples were rendered:
It seemed pretty straightforward: HTML web pages were parsed server side and returned the URL’s Open Graph properties. Here’s a partial response:
{
"webPreview": {
"valid": true,
"url": "http://money.cnn.com/2017/05/13/technology/ransomware-attack-nsa-microsoft/index.html",
"title": "Ransomware: World reels from massive cyberattack",
"description": "Organizations around the world were digging out Saturday from what experts are calling one of the biggest cyberattacks ever. ",
"imageUrl": "/vma/web2/attachment/WebPreview.do?id=KDvS9ip4Afj6fPMTClAzqhegDyT9mSaM0zrQQfrBu8EbtJ0Xu_DyughZu53i-vOLkSeEpbLIk756f4o6igDFp0VHU5kVYFnJoeshsfy7eR3Q8XGwTY_rsu3FHEAAI4DJEmqYl7yBEqeWKSTYUnl48LRpXAokSGi1LWdWZqP0Bovl_EVMpdWB2JfnUz8Qxb0d&mdn=3026323617",
"imageDim": {
"width": 420,
"height": 236
}
}
}
As you can see, the response contains the OG attributes used in the UI’s preview elements. Note the imageUrl is actually a proxied image returned by Verizon’s servers (rather than an external host) — this is generally a good move to maintain more control over the images rendered in the user’s browser.
Since the “attachment” preview attributes were fetched asynchronously (and the resulting markup rendered client side), I decided to check for DOM XSS vectors that may have been overlooked. I texted myself some more test links — this time with some special characters in order to see how the web app would render them. After sending some single quotes included in the querystring of a test URL, I immediately noticed I was able to break out of the HREF attribute in the main anchor element above. Here is an example payload:
http://i.imgur.com/0wmSPiU.jpg?'onmouseover='alert(document.cookie)'style='position:fixed;top:0;left:0;width:100%;height:100%;'class='1'target='2
And the resulting markup:
By forcing the anchor to cover the user’s entire screen with inline styles, the onmouseover event triggers immediately upon opening the message:
This meant that an attacker could control the page with a specifically crafted text message, resulting in a complete takeover of the user’s session — this would allow control of any functionality, including sending and receiving SMS messages on behalf of the victim.
With the PoC working, I started searching the JavaScript sources to track down the cause of the issue. I soon found where the main attachment anchor was prepared:
Note how the HREF value is surrounded by single quotes. While there would have been a few ways to resolve this specific issue, the best option would have been to use the DOM API, e.g.:
var a = document.createElement('a');
a.setAttribute('href',g);
a.innerText = b[f].original;
Update: Looks like they did end up using the DOM API — see below.
Disclosure
I sent the PoC and screenshots/video of the issue to Verizon. As always, they were quick to respond, appreciated the report, and patched the issue quickly.
| 2016-11-18 | Sent initial report of vuln |
| 2016-11-18 | Received response, working on it immediately |
| 2016-12-09 | Confirmed a patched was released |
Share this:
