How does the TeenSafe data leak present a classic false sense of security?

Security researcher Robert Wiggins recently uncovered a serious security issue in the TeenSafe “secure” monitoring product for Android and iOS platforms.

The app allows users (typically parents) to monitor devices (typically their children’s) to view location, text messages, calls, browsing history, and more.

TeenSafe claims the technology can and will help protect your child. There is a debate among privacy advocates and parents about whether this type of monitoring is acceptable, but for our analysis today, let’s just roll with the idea that the app is intended to keep children safe.

What Robert found was that publicly available services were leaking information about TeenSafe accounts. Once notified, TeenSafe took down the affected services for analysis.

When Robert found the leak, he wasn’t assessing the security of TeenSafe directly. Rather, he was searching for misconfigurations in AWS across the web when he found the TeenSafe servers. The misconfigurations highlighted are not exclusive to TeenSafe and can be found easily by attackers who may not be targeting a specific company.

So how did this happen?

From what we know, there are three key points as to why the data was at risk:

1. First, the sensitive data hosted by AWS was not adequately protected owing to misconfiguration and TeenSafe’s failure to make use of fundamental AWS security features.
2. The monitored Apple IDs and passwords (those of the children) were stored insecurely in plaintext so the system could authenticate as those children.
3. Finally, for the system’s authentication to work, the children’s accounts had to disable multifactor authentication (MFA).

This combination of factors gives an attacker all the information required to impersonate a child and access their account. An attacker may not be able to obtain device content directly from the exposed servers, but using the obtained credentials, they most certainly can get some forms of sensitive data directly from Apple.

Could this have been avoided?

All the factors that contributed to this data being exposed could have been avoided.

First, user credentials for authenticating to another service shouldn’t be stored in plaintext, or even stored at all if possible. It’s typical for systems to use credentials to authenticate to a service, then receive an access token of some sort (e.g., a cookie or OAuth access token) in return. This token can be encrypted and stored instead of the user’s credentials, reducing the impact if exposed. If the service does not provide an API that does this, it may be necessary to authenticate using user credentials each time the system interacts with the service, although this is far from ideal. In this case, TeenSafe could have stored the credentials after encrypting them using an HSM-backed cryptographic key (e.g., AWS CloudHSM).

Second, administration/monitoring consoles such as Celery Flower should not be publicly accessible, especially without authentication. Ideally, TeenSafe would have used some form of firewall or AWS Elastic Load Balancer to restrict access to this portal, unless the visitor was accessing from a location internal to TeenSafe. Furthermore, a proxy can be configured to authenticate a user before providing access to data. There’s no reason that this data should have been exposed to the internet in the way it was.

Finally, if TeenSafe was using Celery for task management, they should have ensured that appropriate security measures were in place, such as using TLS and strong credentials.