For an app all about spilling the beans on who you’re allegedly courting, it’s ironic that TeaOnHer was spilling the non-public data of hundreds of its customers to the open internet.
TeaOnHer was designed for males to share pictures and details about girls they declare to have been courting. However very like Tea, the dating-gossip app for girls it was making an attempt to duplicate, TeaOnHer had gaping holes in its safety that uncovered its customers’ private data, together with pictures of their driver’s licenses and different government-issued identification paperwork, as TechCrunch reported final week.
These gated community-like apps have been created ostensibly to let customers share details about their relationships beneath the guise of non-public security. Nevertheless, shoddy coding and safety flaws spotlight the continuing privateness dangers inherent in requiring customers to submit delicate data to make use of apps and web sites.
Such dangers are solely going to worsen; fashionable apps and internet companies are already having to adjust to age verification legal guidelines that require folks to submit their identification paperwork earlier than they are often granted entry to adult-themed content material, regardless of the privateness and safety dangers related to storing databases of individuals’s private data.
When TechCrunch printed our story final week, we didn’t publish particular particulars of the bugs we found in TeaOnHer, erring on the aspect of warning in order to not assist dangerous actors exploit the bug. As a substitute, we determined to publish a restricted disclosure, due to the app’s rising recognition and the quick dangers that customers confronted when utilizing the app.
As of the time of disclosure, TeaOnHer was #2 within the free app charts on the Apple App Retailer, a place nonetheless held by the app at present.
The failings we discovered look like resolved. TechCrunch can now share how we have been capable of finding customers’ driver’s licenses inside 10 minutes of being despatched a hyperlink to the app within the App Retailer, because of straightforward to seek out flaws within the app’s public-facing backend system, or API.
The app’s developer, Xavier Lampkin, didn’t reply to a number of requests for remark after we submitted particulars of the safety flaws, nor would Lampkin decide to notifying affected TeaOnHer customers or state regulators of the safety lapse.
We additionally requested Lampkin if any safety critiques have been carried out earlier than the TeaOnHer app was launched, however we bought no reply. (We’ve got extra on disclosure afterward.)
Alright, begin the clock.
TeaOnHer uncovered ‘admin panel’ credentials
Earlier than we even downloaded the app, we first wished to seek out out the place TeaOnHer was hosted on the web by taking a look at its public-facing infrastructure, akin to its web site and something hosted on its area.
That is normally an excellent place to begin because it helps perceive what different companies the area is linked to on the web.
To seek out the area identify, we first seemed (by likelihood) on the app’s itemizing on the Apple App Retailer to seek out the app’s web site. This could normally be present in its privateness coverage, which apps should embody earlier than Apple will record them. (The app itemizing additionally claims the developer “doesn’t accumulate any knowledge from this app,” which is demonstrably false, so take that as you’ll.)
TeaOnHer’s privateness coverage was within the type of a broadcast Google Doc, which included an e-mail deal with with a teaonher.com area, however no web site.
The web site wasn’t public on the time, so with no web site loading, we seemed on the area’s public-facing DNS data, which can assist to establish what else is hosted on the area, akin to the kind of e-mail servers or hosting. We additionally wished to search for any public subdomains that the developer would possibly use to host performance for the app (or host different sources that ought to most likely not be public), akin to admin dashboards, databases, or different web-facing companies.
However after we seemed on the TeaOnHer’s public web data, it had no significant data aside from a single subdomain, appserver.teaonher.com.
After we opened this web page in our browser, what loaded was the touchdown web page for TeaOnHer’s API (for the curious, we uploaded a replica right here). An API merely permits issues on the web to speak with one another, akin to linking an app to its central database.
It was on this touchdown web page that we discovered the uncovered e-mail deal with and plaintext password (which wasn’t that far off “password”) for Lampkin’s account to entry the TeaOnHer “admin panel.”
The API web page confirmed that the admin panel, used for the doc verification system and person administration, was positioned at “localhost,” which merely refers back to the bodily laptop working the server and will not have been immediately accessible from the web. It’s unclear if anybody might have used the credentials to entry the admin panel, however this was in itself a sufficiently alarming discovering.
At this level, we have been solely about two minutes in.
In any other case, the API touchdown web page didn’t do a lot aside from provide some indication as to what the API can do. The web page listed a number of API endpoints, which the app must entry so as to perform, akin to retrieving person data from TeaOnHer’s database, for customers to depart critiques, and sending notifications.
With information of those endpoints, it may be simpler to work together with the API immediately, as if we have been imitating the app itself. Each API is totally different, so studying how an API works and methods to talk with one can take time to determine, akin to which endpoints to make use of and the parameters wanted to successfully communicate its language. Apps like Postman could be useful for accessing and interacting immediately with APIs, however this requires time and a sure diploma of trial and error (and endurance) to make APIs spit out knowledge once they shouldn’t.
However on this case, there was a fair simpler manner.
TeaOnHer API allowed unauthenticated entry to person knowledge
This API touchdown web page included an endpoint known as /docs, which contained the API’s auto-generated documentation (powered by a product known as Swagger UI) that contained the complete record of instructions that may be carried out on the API.
This documentation web page was successfully a grasp sheet of all of the actions you possibly can carry out on the TeaOnHer API as a daily app person, and extra importantly, because the app’s administrator, akin to creating new customers, verifying customers’ identification paperwork, moderating feedback, and extra.
The API documentation additionally featured the flexibility to question the TeaOnHer API and return person knowledge, basically letting us retrieve knowledge from the app’s backend server and show it in our browser.
Whereas it’s not unusual for builders to publish their API documentation, the issue right here was that some API requests may very well be made with none authentication — no passwords or credentials have been wanted to return data from the TeaOnHer database. In different phrases, you could possibly run instructions on the API to entry customers’ non-public knowledge that ought to not have been accessible to a person of the app, not to mention anybody on the web.
All of this was conveniently and publicly documented for anybody to see.
Requesting a listing of customers presently within the TeaOnHer identification verification queue, for instance — not more than urgent a button on the API web page, nothing fancy right here — would return dozens of account data on individuals who had lately signed as much as TeaOnHer.
The data returned from TeaOnHer’s server contained customers’ distinctive identifiers throughout the app (basically a string of random letters and numbers), their public profile display identify, and self-reported age and placement, together with their non-public e-mail deal with. The data additionally included internet deal with hyperlinks containing pictures of the customers’ driver’s licenses and corresponding selfies.
Worse, these pictures of driver’s licenses, government-issued IDs, and selfies have been saved in an Amazon-hosted S3 cloud server set as publicly accessible to anybody with their internet addresses. This public setting lets anybody with a hyperlink to somebody’s identification paperwork open the information from anyplace with no restrictions.
With that distinctive person identifier, we might additionally use the API web page to immediately lookup particular person customers’ data, which might return their account knowledge and any of their related identification paperwork. With uninhibited entry to the API, a malicious person might have scraped big quantities of person knowledge from the app, very like what occurred with the Tea app to start with.
From bean to cup, that was about 10 minutes, and we hadn’t even logged-in to the app but. The bugs have been really easy to seek out that it could be sheer luck if no one malicious discovered them earlier than we did.
We requested, however Lampkin wouldn’t say if he has the technical potential, akin to logs, to find out if anybody had used (or misused) the API at any time to realize entry to customers’ verification paperwork, akin to by scraping internet addresses from the API.
Within the days since our report back to Lampkin, the API touchdown web page has been taken down, together with its documentation web page, and it now shows solely the state of the server that the TeaOnHer API is working on as “wholesome.” No less than on cursory checks, the API now seems to depend on authentication, and the earlier calls made utilizing the API now not work.
The online addresses containing customers’ uploaded identification paperwork have additionally been restricted from public view.
TeaOnHer developer dismissed efforts to reveal flaws
On condition that TeaOnHer had no official web site on the time of our findings, TechCrunch contacted the e-mail deal with listed on the privateness coverage in an effort to reveal the safety lapses.
However the e-mail bounced again with an error saying the e-mail deal with couldn’t be discovered. We additionally tried contacting Lampkin by means of the e-mail deal with on his web site, Newville Media, however our e-mail bounced again with the identical error message.
TechCrunch reached Lampkin by way of LinkedIn message, asking him to offer an e-mail deal with the place we might ship particulars of the safety flaws. Lampkin responded with a normal “assist” e-mail deal with.
When TechCrunch discloses a safety flaw, we attain out to verify first that an individual or firm is the proper recipient. In any other case, blindly sending particulars of a safety bug to the incorrect individual might create a threat. Earlier than sharing particular particulars of the issues, we requested the recipient of the “assist” e-mail deal with if this was the proper deal with to reveal a safety publicity involving TeaOnHer person knowledge.
“You need to have us confused with ‘the Tea app’,” Lampkin replied by e-mail. (We hadn’t.) “We don’t have a safety breach or knowledge leak,” he stated. (It did.) “We’ve got some bots at most however we haven’t scaled sufficiently big to be in that dialog but, sorry you have been misinformed.” (We weren’t.)
Glad that we had established contact with the proper individual (albeit not with the response we obtained), TechCrunch shared particulars of the safety flaws, in addition to a number of hyperlinks to uncovered driver’s licenses, and a replica of Lampkin’s personal knowledge to underscore the severity of the safety points.
“Thanks for this data. That is very regarding. We’re going to leap on this proper now,” stated Lampkin.
Regardless of a number of follow-up emails, we’ve got not heard from Lampkin since we disclosed the safety flaws.
It doesn’t matter for those who’re a one-person software program store or a billionaire vibe coding by means of a weekend: Builders nonetheless have a duty to maintain their customers’ knowledge protected. If you happen to can’t maintain your customers’ non-public knowledge protected, don’t construct it to start with.
If in case you have proof of a well-liked app or service leaking or exposing data, get in contact. You possibly can securely contact this reporter by way of encrypted message at zackwhittaker.1337 on Sign.
