For an app all about spilling the beans on who you’re allegedly dating, it’s ironic that TeaOnHer was spilling the personal information of thousands of its users to the open web.
TeaOnHer was designed for men to share photos and information about women they claim to have been dating. But much like Tea, the dating-gossip app for women it was trying to replicate, TeaOnHer had gaping holes in its security that exposed its users’ personal information, including photos of their driver’s licenses and other government-issued identity documents, as TechCrunch reported last week.
These gated community-like apps were created ostensibly to let users share information about their relationships under the guise of personal safety. However, shoddy coding and security flaws highlight the ongoing privacy risks inherent in requiring users to submit sensitive information to use apps and websites.
Such risks are only going to worsen; popular apps and web services are already having to comply with age verification laws that require people to submit their identity documents before they can be granted access to adult-themed content, despite the privacy and security risks associated with storing databases of people’s personal information.
When TechCrunch published our story last week, we did not publish specific details of the bugs we discovered in TeaOnHer, erring on the side of caution so as to not help bad actors exploit the bug. Instead, we decided to publish a limited disclosure, because of the app’s rising popularity and the immediate risks that users faced when using the app.
As of the time of disclosure, TeaOnHer was #2 in the free app charts on the Apple App Store, a position still held by the app today.
The flaws we found appear to be resolved. TechCrunch can now share how we were able to find users’ driver’s licenses within 10 minutes of being sent a link to the app in the App Store, thanks to easy to find flaws in the app’s public-facing backend system, or API.
The app’s developer, Xavier Lampkin, did not respond to multiple requests for comment after we submitted details of the security flaws, nor would Lampkin commit to notifying affected TeaOnHer users or state regulators of the security lapse.
We also asked Lampkin if any security reviews were carried out before the TeaOnHer app was launched, but we got no reply. (We have more on disclosure later on.)
Alright, start the clock.
TeaOnHer exposed ‘admin panel’ credentials
Before we even downloaded the app, we first wanted to find out where TeaOnHer was hosted on the internet by looking at its public-facing infrastructure, such as its website and anything hosted on its domain.
This is usually a good place to start as it helps understand what other services the domain is connected to on the internet.
To find the domain name, we first looked (by chance) at the app’s listing on the Apple App Store to find the app’s website. This can usually be found in its privacy policy, which apps must include before Apple will list them. (The app listing also claims the developer “does not collect any data from this app,” which is demonstrably false, so take that as you will.)
TeaOnHer’s privacy policy was in the form of a published Google Doc, which included an email address with a teaonher.com domain, but no website.
The website wasn’t public at the time, so with no website loading, we looked at the domain’s public-facing DNS records, which can help to identify what else is hosted on the domain, such as the type of email servers or web hosting. We also wanted to look for any public subdomains that the developer might use to host functionality for the app (or host other resources that should probably not be public), such as admin dashboards, databases, or other web-facing services.
But when we looked at the TeaOnHer’s public internet records, it had no meaningful information other than a single subdomain, appserver.teaonher.com.
When we opened this page in our browser, what loaded was the landing page for TeaOnHer’s API (for the curious, we uploaded a copy here). An API simply allows things on the internet to communicate with each other, such as linking an app to its central database.
It was on this landing page that we found the exposed email address and plaintext password (which wasn’t that far off “password”) for Lampkin’s account to access the TeaOnHer “admin panel.”
The API page showed that the admin panel, used for the document verification system and user management, was located at “localhost,” which simply refers to the physical computer running the server and may not have been directly accessible from the internet. It’s unclear if anyone could have used the credentials to access the admin panel, but this was in itself a sufficiently alarming finding.
At this point, we were only about two minutes in.
Otherwise, the API landing page didn’t do much other than offer some indication as to what the API can do. The page listed several API endpoints, which the app needs to access in order to function, such as retrieving user records from TeaOnHer’s database, for users to leave reviews, and sending notifications.
With knowledge of these endpoints, it can be easier to interact with the API directly, as if we were imitating the app itself. Every API is different, so learning how an API works and how to communicate with one can take time to figure out, such as which endpoints to use and the parameters needed to effectively speak its language. Apps like Postman can be helpful for accessing and interacting directly with APIs, but this requires time and a certain degree of trial and error (and patience) to make APIs spit out data when they shouldn’t.
But in this case, there was an even easier way.
TeaOnHer API allowed unauthenticated access to user data
This API landing page included an endpoint called /docs, which contained the API’s auto-generated documentation (powered by a product called Swagger UI) that contained the full list of commands that can be performed on the API.
This documentation page was effectively a master sheet of all the actions you can perform on the TeaOnHer API as a regular app user, and more importantly, as the app’s administrator, such as creating new users, verifying users’ identity documents, moderating comments, and more.
The API documentation also featured the ability to query the TeaOnHer API and return user data, essentially letting us retrieve data from the app’s backend server and display it in our browser.
While it’s not uncommon for developers to publish their API documentation, the problem here was that some API requests could be made without any authentication — no passwords or credentials were needed to return information from the TeaOnHer database. In other words, you could run commands on the API to access users’ private data that should not have been accessible to a user of the app, let alone anyone on the internet.
All of this was conveniently and publicly documented for anyone to see.
Requesting a list of users currently in the TeaOnHer identity verification queue, for example — no more than pressing a button on the API page, nothing fancy here — would return dozens of account records on people who had recently signed up to TeaOnHer.
The records returned from TeaOnHer’s server contained users’ unique identifiers within the app (essentially a string of random letters and numbers), their public profile screen name, and self-reported age and location, along with their private email address. The records also included web address links containing photos of the users’ driver’s licenses and corresponding selfies.
Worse, these photos of driver’s licenses, government-issued IDs, and selfies were stored in an Amazon-hosted S3 cloud server set as publicly accessible to anyone with their web addresses. This public setting lets anyone with a link to someone’s identity documents open the files from anywhere with no restrictions.
With that unique user identifier, we could also use the API page to directly look up individual users’ records, which would return their account data and any of their associated identity documents. With uninhibited access to the API, a malicious user could have scraped huge amounts of user data from the app, much like what happened with the Tea app to begin with.
From bean to cup, that was about 10 minutes, and we hadn’t even logged-in to the app yet. The bugs were so easy to find that it would be sheer luck if nobody malicious found them before we did.
We asked, but Lampkin would not say if he has the technical ability, such as logs, to determine if anyone had used (or misused) the API at any time to gain access to users’ verification documents, such as by scraping web addresses from the API.
In the days since our report to Lampkin, the API landing page has been taken down, along with its documentation page, and it now displays only the state of the server that the TeaOnHer API is running on as “healthy.” At least on cursory tests, the API now appears to rely on authentication, and the previous calls made using the API no longer work.
The web addresses containing users’ uploaded identity documents have also been restricted from public view.
TeaOnHer developer dismissed efforts to disclose flaws
Given that TeaOnHer had no official website at the time of our findings, TechCrunch contacted the email address listed on the privacy policy in an effort to disclose the security lapses.
But the email bounced back with an error saying the email address couldn’t be found. We also tried contacting Lampkin through the email address on his website, Newville Media, but our email bounced back with the same error message.
TechCrunch reached Lampkin via LinkedIn message, asking him to provide an email address where we could send details of the security flaws. Lampkin responded with a general “support” email address in response.
When TechCrunch discloses a security flaw, we reach out to confirm first that a person or company is the correct recipient. Otherwise, blindly sending details of a security bug to the wrong person could create a risk. Before sharing specific details of the flaws, we asked the recipient of the “support” email address if this was the correct address to disclose a security exposure involving TeaOnHer user data.
“You must have us confused with ‘the Tea app’,” Lampkin replied by email. (We hadn’t.) “We don’t have a security breach or data leak,” he said. (It did.) “We have some bots at most but we haven’t scaled big enough to be in that conversation yet, sorry you were misinformed.” (We weren’t)
Satisfied that we had established contact with the correct person (albeit not with the response we received), TechCrunch shared details of the security flaws, as well as several links to exposed driver’s licenses, and a copy of Lampkin’s own data to underscore the severity of the security issues.
“Thank you for this information. This is very concerning. We are going to jump on this right now,” said Lampkin.
Despite several follow-up emails, we have not heard from Lampkin since we disclosed the security flaws.
It doesn’t matter if you’re a one-person software shop or a billionaire vibe coding through a weekend: Developers still have a responsibility to keep their users’ data safe. If you can’t keep your users’ private data safe, don’t build it to begin with.
If you have evidence of a popular app or service leaking or exposing information, get in touch. You can securely contact this reporter via encrypted message at zackwhittaker.1337 on Signal.
Great Job Zack Whittaker & the Team @ TechCrunch Source link for sharing this story.
