A bug on a T-Mobile website meant for employees let anyone with a T-Mobile customer’s phone number access sensitive information, according to a ZDNet report. While T-Mobile has since fixed the issue, the bug sounds similar to one found by researchers in October 2017, bringing into question the security practices of T-Mobile, a company in the middle of a $26 billion merger with Sprint.
The bug was located on a publicly facing T-Mobile site, promotool.t-mobile.com, a subdomain used by staff to access account details through the company’s customer care portal. With no password protection, the site left exposed personal data like names, addresses, and the status of your bill. ZDNet reports that all a malicious actor needed was a user’s phone number, which simply needed to be tacked onto the end of the website’s address. The data provided by T-Mobile even included account PINs, an extra security measure used to authenticate a user’s identity during a support request, according to ZDNet.
The offending API was removed in April, according to T-Mobile. Security researcher Ryan Stevenson found the bug and reported it to the company, participating in its bug bounty program, and winning a cool grand in prize money.
While I’m glad T-Mobile’s got a bug bounty program, I’m not sure how much faith I’d put in the company to ensure that this won’t happen again. This incident is seemingly similar to one that occurred last year, when hackers exploited an API bug using a user’s phone number to obtain personal and sensitive data.
In both instances, the bugs were found on T-Mobile subdomains, and both required only a phone number to gain access to a user’s personal and identifiable information. What’s more, T-Mobile has in the past stated that no user information was compromised, though Motherboard reports that the vulnerability has been a well-known method of obtaining new SIM cards illegally, through social engineering tactics.
Gizmodo has reached out to T-Mobile for further clarification about the most recent issue and will update when we receive a response.
[ZDNet]