This week, we look at the recent vulnerabilities at Verizon and Shenzhen i365-Tech GPS trackers, leaking S3 bucket names, and Facebook cutting API access for some of its partners.
Vulnerability: Verizon
2 million Verizon Wireless Pay Monthly contracts were found open for anyone to access.
The researcher managed to get a valid cookie while browsing the various paths he was able to locate with Google. It turned out that he could then use that cookie to authenticate his calls to the system and retrieve PDFs of customer contracts.
The contract IDs were just sequential numeric values and authorization was not enforced per contract. He could thus simply iterate on the contract ID parameter (m), and the phone number parameter (a) didn’t have to match the ID:
/example?m=12334567890&a=1337
Another example on why you should never use sequential IDs, and why proper authentication and authorization are crucial. Rate limiting helps against brute force enumeration attacks too.
Vulnerability: GPS trackers
API vulnerabilities in cloud services remain the weakest link in consumer IoT.
At least 600K GPS trackers from Shenzhen i365-Tech were found to be vulnerable this week. The cloud service behind the trackers uses sequential IDs that you can enumerate and a default password 123456. Not too complex to breach, then.
This vulnerability poses even a physical security threat considering that GPS trackers are often used to track location of pets, kids, and the elderly.
In addition to sequential IDs, default passwords are also evil. Don’t do it.
Vulnerability: Data leaking in errors
Error messages are a frequent source of data leaks.
Neeraj Edwards found a way to make error messages leak AWS S3 bucket names.
His approach was quite simple:
- Find any CDN object URL
- Append the following string after the URL:
`?AWSAccessKeyId=[Valid_ACCESS_KEY_ID]&Expires=1766972005&Signature=ccc
The approach did not work on CloudFront URL’s, but it did work on other domains set through AWS S3 CNAME.
If you are an API provider, make sure you document and enforce not just API inputs but also outputs, including error responses.
API economy: API Governance
API governance can become a trouble for both parties.
Facebook and Instagram have suffered from scraping apps that used the APIs to download and collect vast amounts of personal data. These days they (and Google too) are trying to hunt down any such use, being afraid of another Cambridge Analytica.
Now we have a case of the other side of the API economy suffering: one of Facebook/Instagram partners, a scheduling app Social Report suffered a blow from the vendor revoking their API tokens.
Managing and posting to the social platforms is Social Report’s core business. Losing the API access has put it in an existential risk.
This shows that both API providers and consumers need to keep API governance in mind and have a Plan B in case the relationship goes wrong.
- If you are the provider, how do you prevent and detect API abuse? What do you do when you uncover abuse?
- As an API consumer, how much do you depend on APIs from a single vendor? How do you ensure that your usage is in line with their policies? How do you manage that relationship and get early warnings of potential trouble ahead? What do you do if you lose access?
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
