Intro/Recap
In our previous post we showed a teardown of the Hello Barbie. In this post we will discuss its overall architecture, the security vulnerabilities found, and what we took away from these results. Initially it appeared that ToyTalk had put some consideration into their security model, by building upon existing hardware and attempting to adhere to the minimal KidSafe Seal Program information security requirements. Additionally, they encrypted nearly all communication between devices and chose to keep sensitive information in the cloud, rather than on the doll. However, what they failed to do was properly harden their web services. In the vulnerabilities that we found, most existed in either ToyTalk’s websites or web services. This leads us to believe that ToyTalk performed little to no pre-production security analysis and is using their bug bounty program as a low-cost alternative. This is supported by our observations that ToyTalk was actively patching and even discarding entire websites as we were performing analysis and how many of the same vulnerabilities were discovered by other groups on HackerOne. If this is the case, then it was a short-sighted cost-cutting decision with repercussions that could have been prevented by simply hiring independent security team to audit their product. Their actions left customers’ personal information vulnerable in a race between security researchers and malicious hackers to see who could find those vulnerabilities first. Companies need to understand that a bug bounty program is a last resort, not a replacement for proper security analysis before a product’s release.
Vulnerabilities Found
During our investigation we analyzed the memory dump, reverse engineered the firmware and Android application, observed network traffic, and analyzed the security of ToyTalk’s web applications and services.
Through these methods we were able to intercept encrypted communication from the mobile application, trick the mobile application and web application into leaking data, and communicate with ToyTalk servers, masquerading as either Barbie or the mobile application. Minor security weaknesses were found in the device, while larger and more impactful vulnerabilities were found in ToyTalk’s web applications and web services.
The nastiest vulnerability allows an attacker to enumerate account usernames and brute force their passwords with unlimited retries, without triggering any form of account lockout. There was also a weak password policy in place making this an even more viable attack vector.
Additional vulnerabilities include the ToyTalk website issuing password reset requests over HTTP that do not expire, pages vulnerable to Stored Cross-Site Scripting (XSS) and session cookies that did not expire. Throughout the analysis, 14 vulnerabilities were discovered. Further details on our security analysis and the vulnerabilities can be found in our full write up.
System Architecture
Some may remember the articles about the My Friend Cayla doll hack that could force it to say curse words and other colorful things. This was made possible due to poor design decisions. That doll was a simple device acting as a Bluetooth headset that could pair with any mobile device without authentication. It relied heavily upon the mobile application, which acted as the core of the product, handling all querying of questions and responses. What researchers tried to illustrate was that if a Cayla doll could accidentally lose connection and pair with an attacker’s device that the attacker could listen to what the doll records and control what it says.
This is not the same case with Hello Barbie. Barbie is built upon hardware specifically designed for IoT, and its architecture is comparable to that of other IoT services like Amazon AWS IoT. The system has three possible clients that interface with each other and the cloud. The doll uses WiFi, in-place of Bluetooth. Pairing with the mobile application is much more involved and is only used to associate Barbie with a WiFi access point and ToyTalk account. After that, Barbie mainly communicates with ToyTalk servers, doing all of its storage and data-processing in the cloud. Staging a man-in-the-middle attack on any of the devices are difficult as it requires an attacker to have access to a trusted network. Even then, communication between the devices and the cloud are being encrypted.
Attack Model
The resulting threat model leaves home WiFi credentials and audio recordings as the data that would be attractive to attackers. However, accessing this information is not easy. Network SSIDs and passwords are stored on the doll, but the passwords are encrypted in doll’s memory and are difficult to extract. Accessing audio recordings could be achieved by eavesdropping on a Barbie’s conversation or a data breach of the ToyTalk’s website. However, eavesdropping would require an attacker to generate a valid toytalk.com certificate, which is not easy. ToyTalk’s website is a different story, and its security rests on community participation in their bug bounty program.
Info for Consumers
What does this mean for consumers interested in this product? It means that ToyTalk requests basic information about their users, voice recordings are stored in the cloud, and for the most part this isn’t much different from using other cloud services. The actual doll and mobile device do not store or share much interesting information. What consumers need to decide is whether they are willing to trust their children’s content with ToyTalk.
Info for IoT Companies, Engineers, and Developers
What does this mean for creators and tinkerers of IoT? IoT products are a combination of multiple, potentially complex, devices that connect and form a network architecture. Designing all these devices, protocols, and services for a product can be challenging and prone to error. By leveraging pre-existing IoT hardware modules and services, one can minimize the amount of custom work that needs to be done to a product, thus minimizing the attack surface. In Hello Barbie’s overall design, its weakest pieces were ToyTalk’s web services that they implemented, but the IoT hardware itself presents few opportunities for an attacker.
Conclusion/Takeaways
In the end, we believe that ToyTalk started off well by utilizing pre-designed hardware and software, but fell short when it came to their web security. The number of vulnerabilities found in both ToyTalk’s websites and web services, and in such a short amount of time, indicate that they had little to no pre-production security analysis and are relying on their bug bounty program to patch up the holes. However, this could have been easily remedied by hiring a professional security team to audit the attack surface that is left. It also seems that the KidSafe Seal Program does not provide strict or clear enough information security requirements for web related technologies. In the end, it’s a decision for the parents about the trust they place in ToyTalk. If ToyTalk’s servers are ever eventually breached, they wouldn’t be the first company to leak personal information about children to hackers. It’s up to the parents to decide whether they want to take that risk.
Follow us on twitter @SomersetRecon to catch our next posts!