Tracfone learned the hard way that API security testing matters. To the tune of a $16 million dollar settlement with the FCC.

There is a lot we can learn from the FCC ruling as API hackers.

Let’s get right to it.

Who is Tracfone? 

Tracfone is a prepaid wireless service provider in the United States. It operates as a mobile virtual network operator (MVNO), meaning it doesn’t own its own wireless infrastructure but leases network access from larger carriers such as Verizon, AT&T, and T-Mobile. 

They offer various plans without long-term contracts, catering to customers who prefer the flexibility and control of prepaid services. The company is known for providing affordable options and has a range of brands under its umbrella, including Straight Talk, Simple Mobile, Total Wireless, and Walmart Family Mobile. 

Verizon acquired Tracfone in 2020, further expanding its reach and capabilities in the prepaid wireless market.

They have had three security incidents that allowed third-party threat actors to access customer personally identifiable information (PII) and customer proprietary network information (CPNI). In all three cases, this was accomplished by abusing public-facing APIs with security vulnerabilities.

Incident #1

In January of 2021, threat actors were able to exploit a broken authentication vulnerability in the customer-facing APIs that allowed the attackers to wreak havoc across several of their brands. Bad actors accessed customer names, addresses, dates of birth, PIN codes, account numbers, secret questions, and email addresses.

In the notification to their customers they disclosed that these bad actors not only gained access to customer accounts, but in some cases, they fraudulently transferred, or “ported out”, mobile telephone numbers to other carriers.

Tracfone did not notice this until December 2021, giving these bad actors the ability to seize phone numbers for almost a year. 

Why was this bad? It gave attackers the window of opportunity to run SIM swapping attacks, which allowed for financial and identity theft, as well as unauthorized access to accounts where SMS two-factor authentication was used. This included several well-known social media platforms and email services.

The Verge reported that this incident affected at least 6,000 customers, but some say the number was significantly higher.

Incident #2

In December 2022, Tracfone detected that bad actors had been abusing a broken object-level authorization (BOLA) vulnerability in the APIs tied to the websites customers use to order services and products. 

Bad actors had found a way to exploit a vulnerability that allowed the threat actor to access order information (including certain CPNI and other Customer information) without being properly authenticated. 

Incident #3

After Tracfone pushed a fix to block access to the vulnerability discovered in incident #2, threat actors discovered the company did not fix the underlying class of vulnerability and found another method to exploit it. API security testing was lacking.

This third breach was detected in January of 2023.

TracFone ultimately implemented a long-term fix for the underlying vulnerability by February 2023.      

The FCC Consent Decree

In a news release from the Federal Communications Commission (FCC), they shared information about the Tracfone incidents. As part of the release, they published a consent decree for Tracfone. 

This includes several key requirements and measures to enhance data security and prevent future incidents. 

Let’s look at the essential items covered in the decree.

Financial Penalty

As Tracfone’s parent company, Verizon agreed to pay a $16 million settlement. This fine is meant to address the breaches and enforce stricter compliance with data protection regulations.

Development of an Information Security Program 

Tracfone is required to create a comprehensive information security program. This program must:

• Adhere to standards such as those set by the National Institute of Standards and Technology (NIST) and the Open Web Application Security Project (OWASP).
• Implement secure API controls to prevent unauthorized access.
• Conduct regular testing and updating of security measures to ensure their effectiveness.

SIM Change and Port-Out Protections 

To combat SIM swapping attacks, Tracfone must:

• Use secure authentication methods for SIM changes and port-out requests.
• Notify customers of such requests.
• Offer number transfer PINs to add an extra layer of security.

Annual Security Assessments 

Tracfone must perform annual assessments of its information security program to ensure its effectiveness. These assessments include independent third-party evaluations every two years to gauge the sufficiency and maturity of the security measures.

Employee Training

The company is required to organize annual privacy and security awareness training for its employees. This training aims to enhance their ability to safeguard customer data and comply with security protocols.

Summary

These measures are intended to address the vulnerabilities that led to the data breaches and to strengthen Tracfone’s overall security posture. The settlement emphasizes the importance of API security and the need for continuous monitoring and improvement in data protection practices.

But what can we learn from these incidents as security testers?

Lesson #1 – Broken authentication & authorization vulns matter 

There is a reason why broken object-level authorization and broken authentication are the top two vulnerability classes in the OWASP API Security Top 10. It is still too easy for developers to miss this since their unit tests rarely have ways to validate this properly.

But that’s no excuse. As part of your HAST processes, you should be constructing reusable tests that can test for proper authentication and authorization checks on the API endpoints. In my Beginners Guide to Writing API Security Tests in Postman, I discuss how you can construct test collections and folders in a way that would allow tools like Newman to be inserted into your CI pipeline to act as a security guardrail against these classes of vulnerabilities. 

Most API frameworks offer middleware to make authN and authZ easier. Once you understand how to detect when they are and aren’t in use, you can build tests to look for these signals and alert everyone when they aren’t properly seen.     

Lesson #2 – HAST matters

Human Application Security Testing (HAST) is a cornerstone of any good API security program. Despite the latest AI advancements, traditional API security vendors often miss authentication and authorization issues.

The core challenge lies in the complexities of business logic that governs access to API endpoints and their data. Authentication and authorization mechanisms vary significantly; one API might use intricate claims in JSON Web Tokens (JWT), while another employs custom session tokens.

The use of the OpenAPI specification offers the ability to describe API security, but that doesn’t guarantee that it’s been properly implemented by the developers. 

Again, human expertise matters here, as it ensures we can build reusable tests that validate the security expectations for every endpoint. 

As Tracfone found, NOT doing this can be costly.

Lesson #3 – OWASP matters

I was really happy to see in the FCC consent decree that the government clearly mandated that Tracfone implement an information security program to reduce API vulnerabilities and consider adhering to OWASP standards.

It could had been clearer “how” that should be done. I wrote about How to Use OWASP guidance as your testing blueprint before. So I won’t go deep into it here. But imagine if the FCC mandated that Tracfone demonstrate OWASP ASVS Level 1 within the next 180 days by their API security testing processes and Level 2 within a year. 

My point is that the government acknowledges that verification standards exist, and companies like these wireless carriers can impact us as a society and should be held to a higher standard. I would take that a step further and say that is true of all critical infrastructure as well. 

Corporations and governments should invest more money, time, and effort in OWASP. We should all agree that OWASP matters.  

Conclusion

Tracfone’s costly lesson in API security underscores a critical reality: neglecting security can erode customer trust and lead to hefty fines. Their failure to secure their APIs resulted in bad actors’ unauthorized access to customer data and, ultimately, significant financial losses through penalties, remediation efforts, and new policies and procedures that now need to be implemented.

It could have been worse. Or it may have been. We simply don’t know the bad actors’ true intentions to understand how far they took the SIM swapping attacks. We do know bad actors took over customer phone numbers. 

Think about where you may be using your phone number. Account recovery. Two-factor authentication. Sign-in approvals. Access to cloud services. Crypto wallets. Bank accounts. Medical records. 

The list goes on. We rely on our phones far too much.  

In the end, Tracfone’s experience illustrates the severe consequences of neglecting API security. For any organization, investing in thorough security testing and adhering to established security standards is not just a regulatory requirement but a fundamental aspect of maintaining customer trust and business integrity.

API security testing matters. Don’t learn this the hard way. 

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.

The post Why API Security Testing Matters – Learning from Tracfone appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/why-api-security-testing-matters-learning-from-tracfone