500,000 UandMe record entries exposed online
According to their website, UandMe is a “Communication app for Teams.” I’ve recently found that the company may, through a MongoDB misconfiguration, be responsible for leaking its own production database (named “uandmeprod_main”). It’s hard to say for sure though because I can’t get a response out of them.
I dispatched the following email to various UandMe contact addresses earlier last week:
I have discovered an apparent data breach involving your organization. There is a publicly exposed MongoDB database sitting out on the internet right now that looks to contain a vast amount of your company's internal data.
The server is located at:
IP address: 126.96.36.199
There is no username or password required to access it.
If this is indeed your data, please secure the database immediately!
As I do plan to publicly disclose word of this event (but not the sensitive data itself), I have a few questions:
- How long has this data been exposed?
- How many users are affected?
- Will you be notifying your users of this breach?
Please also note that any response, or lack of response, may be included in my reporting of the event.
As you can see in the screenshots above this post, the database contains nearly 500,000 “USERINFO” record entries.
The UandMe website states that the application “is developed implementing secure industry-best practices incorporating security reviews in the whole design, prototyping and deployment process.” That is clearly not the case if what I found is indeed a copy of their production database.
The database disappeared at some point after my email notification was sent. This leads me to believe that someone at UandMe saw my email and took action.
Lacking any sort of direct response from UandMe, it’s hard to say whether or not any affected users will receive notification that their personal info may have been exposed. I have high hopes that appropriate action will be taken, but I guess we’ll have to wait and see.
Stay tuned to the latest security news with MacKeeper Security Research Center.
Attention - Portions of this article may be used for publication if properly referenced and credit is given to MacKeeper Security Researcher, Chris Vickery.