\n<\/p>\n
For an app all about spilling the beans on who you\u2019re allegedly dating, it\u2019s ironic that TeaOnHer was spilling the personal information of thousands of its users to the open web.<\/p>\n
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<\/a> it was trying to replicate, TeaOnHer had gaping holes in its security that exposed its users\u2019 personal information, including photos of their driver\u2019s licenses and other government-issued identity documents, as TechCrunch reported<\/a> last week.<\/p>\n 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.<\/p>\n Such risks are only going to worsen; popular apps and web services are already having to comply with age-verification laws<\/a> that require people to submit their identity documents<\/a> before they can be granted access to adult-themed content, despite the privacy and security risks associated with storing databases of people\u2019s personal information.<\/p>\n 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<\/a>, because of the app\u2019s rising popularity and the immediate risks that users faced when using the app. <\/p>\n As of the time of disclosure, TeaOnHer was No. 2 in the free app charts on the Apple App Store, a position still held by the app today.<\/p>\n The flaws we found appear to be resolved. TechCrunch can now share how we were able to find users\u2019 driver\u2019s 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\u2019s public-facing backend system, or API.<\/p>\n The app\u2019s 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.<\/p>\n 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.)<\/p>\n Alright, start the clock.<\/p>\n 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.<\/p>\n This is usually a good place to start as it helps understand what other services the domain is connected to on the internet.\u00a0<\/p>\n To find the domain name, we first looked (by chance) at the app\u2019s listing on the Apple App Store<\/a> to find the app\u2019s 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 \u201cdoes not collect any data from this app,\u201d which is demonstrably false, so take that as you will.)<\/p>\n TeaOnHer\u2019s privacy policy was in the form of a published Google Doc, which included an email address with a The website wasn\u2019t public at the time, so with no website loading, we looked at the domain\u2019s 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<\/a>), such as admin dashboards, databases, or other web-facing services.<\/p>\n But when we looked at the TeaOnHer\u2019s public internet records, it had no meaningful information other than a single subdomain, When we opened this page in our browser, what loaded was the landing page for TeaOnHer\u2019s API (for the curious, we uploaded a copy here<\/a>). An API simply allows things on the internet to communicate with each other, such as linking an app to its central database.<\/p>\n It was on this landing page that we found the exposed email address and plaintext password (which wasn\u2019t that far off \u201cpassword\u201d<\/a>) for Lampkin\u2019s account to access the TeaOnHer \u201cadmin panel.\u201d<\/p>\n The API page showed that the admin panel, used for the document verification system and user management, was located at \u201clocalhost,\u201d which simply refers to the physical computer running the server and may not have been directly accessible from the internet. It\u2019s unclear if anyone could have used the credentials to access the admin panel, but this was in itself a sufficiently alarming finding.<\/p>\n At this point, we were only about two minutes in.<\/p>\n Otherwise, the API landing page didn\u2019t 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\u2019s database, for users to leave reviews, and sending notifications.<\/p>\n 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\u2019t.<\/p>\n But in this case, there was an even easier way.\u00a0<\/p>\n This API landing page included an endpoint called 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\u2019s administrator, such as creating new users, verifying users\u2019 identity documents, moderating comments, and more.\u00a0<\/p>\n The API documentation also featured the ability to query the TeaOnHer API and return user data, essentially letting us retrieve data from the app\u2019s backend server and display it in our browser.<\/p>\n While it\u2019s not uncommon for developers to publish their API documentation, the problem here was that some API requests could be made without any authentication \u2014 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\u2019 private data that should not have been accessible to a user of the app, let alone anyone on the internet.\u00a0<\/p>\n All of this was conveniently and publicly documented for anyone to see.<\/p>\n Requesting a list of users currently in the TeaOnHer identity verification queue, for example \u2014 no more than pressing a button on the API page, nothing fancy here \u2014 would return dozens of account records on people who had recently signed up to TeaOnHer.<\/p>\n The records returned from TeaOnHer\u2019s server contained users\u2019 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\u2019 driver\u2019s licenses and corresponding selfies.\u00a0<\/p>\n Worse, these photos of driver\u2019s 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\u2019s identity documents open the files from anywhere with no restrictions.<\/p>\n With that unique user identifier, we could also use the API page to directly look up individual users\u2019 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<\/a>.<\/p>\n From bean to cup, that was about 10 minutes, and we hadn\u2019t 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.<\/p>\n 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\u2019 verification documents, such as by scraping web addresses from the API.<\/p>\n 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 \u201chealthy.\u201d At least on cursory tests, the API now appears to rely on authentication, and the previous calls made using the API no longer work.\u00a0<\/p>\n The web addresses containing users\u2019 uploaded identity documents have also been restricted from public view.\u00a0<\/p>\n 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.\u00a0<\/p>\n But the email bounced back with an error saying the email address couldn\u2019t 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.<\/p>\n 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 \u201csupport\u201d email address.<\/p>\n 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 \u201csupport\u201d email address if this was the correct address to disclose a security exposure involving TeaOnHer user data.<\/p>\n \u201cYou must have us confused with \u2018the Tea app\u2019,\u201d Lampkin replied by email. (We hadn\u2019t.) \u201cWe don\u2019t have a security breach or data leak,\u201d he said. (It did.) \u201cWe have some bots at most but we haven\u2019t scaled big enough to be in that conversation yet, sorry you were misinformed.\u201d (We weren\u2019t.)<\/p>\n 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\u2019s licenses, and a copy of Lampkin\u2019s own data to underscore the severity of the security issues.<\/p>\n \u201cThank you for this information. This is very concerning. We are going to jump on this right now,\u201d said Lampkin.<\/p>\n Despite several follow-up emails, we have not heard from Lampkin since we disclosed the security flaws.<\/p>\n It doesn\u2019t matter if you\u2019re a one-person software shop or a billionaire vibe coding through a weekend<\/a>: Developers still have a responsibility to keep their users\u2019 data safe. If you can\u2019t keep your users\u2019 private data safe, don\u2019t build it to begin with.<\/p>\n 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.<\/em><\/p>\n We\u2019re always looking to evolve, and by providing some insight into your perspective and feedback into TechCrunch and our coverage and events, you can help us! Fill out\u00a0<\/em>this survey<\/a><\/em>\u00a0to let us know how we\u2019re doing and get the chance to win a prize in return!<\/em><\/p>\n<\/div>\nTeaOnHer exposed \u2018admin panel\u2019 credentials<\/h2>\n
teaonher.com<\/code> domain, but no website.<\/p>\nappserver.teaonher.com<\/code>.<\/p>\nTeaOnHer API allowed unauthenticated access to user data<\/h2>\n
\/docs<\/code><\/a>, which contained the API\u2019s auto-generated documentation (powered by a product called Swagger UI) that contained the full list of commands that can be performed on the API.\u00a0<\/p>\nTeaOnHer developer dismissed efforts to disclose flaws<\/h2>\n