Earlier this year, during an engagement with the European consumer organization Test-Aankoop, leading Penetration Testing company SureCloud was tasked with investigating the security of a variety of devices within the home of a volunteer. One of these devices was the VTech Storio Max tablet which is a device aimed at children.
This article initially started out as a walkthrough of our process for testing these kinds of devices but ended up turning into a critical disclosure to VTech and the vulnerability being granted a CVE (CVE-2018-16618).
In summary, Senior Security Consultant Elliott Thompson found a vulnerable service was enabled on the tablet which could be exploited by a script placed on a website and triggered by child visiting the page. This code would attack any Storio Max tablet that visited the page, granting the attacker full root control over the device including access webcam, speakers and microphone. This was reported to VTech and a patch fixing the vulnerability was released within 30 days.
Technical Walk-through
The following technical walk-through details the process we followed when investigating the tablet starting with the enumeration of interesting features.
The Storio Max is intended to be used by 3 – 11 year olds and contains a few interesting features.
From the marketing material we can see the tablet is Android based, connects to Wi-Fi, includes a browser, microphone/speaker combination as well as a cartridge reader on the back and a whole heap of custom Android apps.
With the above in mind we started attempting to reverse engineer how the device worked and enumerate more detailed technical information of the device, we quickly found it to be running a very old Linux kernel. Great start…
We took a variety of different paths, from physical disassembly, reading chip documentation and liberal use of Google Translate. I should mention the device’s entire interface was exclusively in Dutch. There were a few interesting but otherwise irrelevant discoveries along the way including the following:
The demo cartridge contained the simplest PCB I’ve ever reverse engineered. Unfortunately, we didn’t get chance to disassemble any other cartridges, those might have a bit more to them.
Firmware is stored entirely on an 8GB MicroSD card. No need for a Bus Pirate or desoldering tiny chips!
From a hardware perspective the rest was pretty much as you would expect from a relatively low cost tablet. A cheap ARM processor handling the camera and primary OS functions, a smaller chip most likely for handling the display and a daughterboard for Wi-Fi.
- Rockchip RK3168 – Primary ARMv7 Processor (Unfortunately I couldn’t find a datasheet with a map of the balls)
- Rockchip RK616 – Display processor based on the datasheet
- Realtek RTL8188EUS – Fairly standard wireless chip on the daughterboard. According to some GitHub thread it may be possible to get this to work in monitor mode. Now there’s a thought…
Moving onto the software side, after powering on the device we eventually land on what Google Translate tells me is a login page. Let’s try and quickly escape from this far too friendly interface into something a bit more familiar.
Success! That’s more like it, we’re into the Android settings. To make things a little easier, can we change the language to something I have a poor grasp of instead of no grasp of?
Apparently so! That makes the process far less of an ordeal, we can start exploring. It does seem to be a fairly standard, if a little dated Android build.
- Model number: rk30sdk_rtl8723
- Wifi driver version: 4.3.0.6
- Android version: 4.2.2
- Kernel version: 3.0.36+ root@vtech #3134
- Build number: RK30_ANDROID4.2.2-SDK-v1.00.82 rk30sdk_rtl8723-eng 4.2.2 JDQ39 eng.vtech.20160607.152353 test-keys
Android 4.2.2 is heavily out of date, vulnerable to a buffet of privilege escalation exploits and hasn’t had security updates in at least 3 years. But we’re getting ahead of ourselves, does “root@vtech” mean what I think it means? Is everything already running as root?
Let’s enable USB debugging and find out.
That would have been way too easy!
While we explore with ADB there a couple of gotchas for anyone following along at home:
- ADB reboot bootloader will succeed but show a black screen, the rockusb device will become available over USB for firmware flashing and dumping.
- ADB reboot recovery will just reboot the device, nothing special here
Also, can we load arbitrary APKs containing inappropriate games for a kids tablet?
Why yes you can! It also worked with the hardware buttons! ?
Lets try and find a way to root this thing. As mentioned before, there is no shortage of root exploits for Android 4.2.2. But I’d like to avoid manually identifying kernel address offsets unique to this device.
The most promising candidate looked to be CVE-2014-3153 (Towelroot) but after a few attempts with the Metasploit module and the pre-made exploit APK files it was nothing but a series of reboots.
No dice.
After a half dozen failed attempts at rooting, my sanity slipping and patience fraying I was getting desperate. The following attempts didn’t work:
- Towelroot APK/Teathered Exploit/Compiled NDK binary (Bootloops, bootloops everywhere)
- Kingoroot (It did successfully install some awful battery monitor and something quietly listening on an IPv6 port though)
- Modifying the firmware on the SDCard (I couldn’t make enough sense of the layout to mount a filesystem, binwalk struggled too)
- Various other rooting tools from various progress less reputable sources (I now have a VM with digital MRSA)
But eventually, SUCCESS!! (Kudos to the RootGenuis tool for only slightly contributing to my digital plague)
At this point it was getting late and I needed to make a choice
And that’s where this story ends, with root access to a kid’s toy finally obtained…
Who am I kidding, you can see the article continues on the next line. Let’s look at netstat. (I know we don’t need root for this but bear with me.)
We see two processes listening on TCP ports, we’ll focus on the first one. It’s open but it closes immediately when we attempt to connect.
As a note, the service listening on IPv6 port 10086 was created by what appears to be malware installed in one of the desperate rooting attempts. It’s only running as a standard user and was easy enough to remove.
After a bit of hunting we find that the binary listening on port 1668 is “/system/xbin/storeintenttranslate.x” which I can’t find any reference to online. But ‘strings’ show something interesting:
References to /system/bin/sh, listening on port 1668 and what looks like basic HTTP support… Damn right I’m not sleeping.
Attempting to connect using netcat while running logcat also gives us something interesting. While our connection gets immediately terminated, logcat does show a some custom rejection text.
Connection attempt with netcat
Tcpdump showing immediate rejection
adb logcat showing the rejection
(The IPs don’t match up because there’s a VM and NAT involved)
Time to look at that binary, because I don’t yet know radare2 yet. Let’s look at the it in IDA.
You, skilled reader, may have already identified what the 0x100007F value refers to. My initial thoughts were that it was a memory address, this turned out to be wrong…
It’s just checking whether the originating IP address is 127.0.0.1. Let’s run the same netcat command through ADB and monitor logcat again.
YES!
Having explored the binary further with IDA the following shone like a terrible, glorious beacon:
Submitting a GET request to /dacdb70[[ REDACTED ]]96eef? will execute the command with our value after the question mark:
- am start ‘llstore://jump?’
With a bit of experimenting to escape from the command we come up with the following request:
- GET /dacdb70[[ REDACTED ]]96eef?’;cat<default.prop>/data/local/tmp/surecloudtest’
And it worked perfectly. Although we can’t use any spaces in our payload. For two reasons. Firstly, because our input gets cut at the first space and second because we want to make sure a standard browser doesn’t URL encode any of our characters. Brace expansion to the rescue.
- GET /dacdb70[[ REDACTED ]]eef?’;{ping,172.16.42.134}’
Our final step is going to be executing this from the web. But for the exploit to work I’ve so far being making a very big assumption:
“Single quotes are not URL encoded by the web browser”
If this is not true, the exploit will not work and it will just be an easier way of achieving local root, admittedly a malicious app could easily exploit this, but there probably aren’t many malicious VTech cartridges floating around. Anyway, onto our assumption…
My local copy of Firefox DOES encode single quotes by default, it’s not looking good. 🙁
But in testing the actual VTech browser, we see that it doesn’t encode them! 🙂
This means if we can convince someone to browse our page, we get full root RCE on the tablet! So let’s test this out…
Damn, the kid’s browser blocks the attempt to access non-whitelisted content.
As an interesting aside, the kid’s browser presents a very friendly warning if the TLS certificate is untrusted with a nice friendly green Yes/Ja button too. (I had set the language to English at this point, but the browser ignores it).
But it works perfectly fine in the parental browser. It also works if we route one of the permitted kid’s domains to 127.0.0.1 and change the link to include that domain. Although this would only work over the local network.
To exploit this for real, we would need to be in control of some HTML being rendered by the browser. It’s not like we can start emailing links around to these kinds of devices.
Parent accounts can browse to any web page on the device, but kids can only browse to a pre-defined list of whitelisted websites set by the parent account. Let’s look at those websites.
- Esa Kids – Static site
- Jeugdjjournaal – No user controlled content
- Rangers WNF – No user controlled content
- School TV – No user controlled content
- nu – Limited user controlled content
- Wikikids – Wiki capabilities
- Zappelin – No user controlled content
It is important to note that no changes were made to the actual wikikids website. But during testing on our own wiki-based site it was possible to create an external link in markdown which triggered the exploit. On the child’s browser, images and scripts are loaded from any destination regardless of the parental whitelisting, so the parent doesn’t need to whitelist 127.0.0.1 for the requests to go through.
It’s at this point I will stop for real. There are still plenty of avenues I’ve not had chance to explore. But it’s getting light outside now. In summary the following haven’t been touched:
- The APIs used by the built-in apps
- Memory handling in storeintenttranslate.x or other native apps
- VTech firmware update mechanism
- Anything server side (Unfortunately we had no permission to test for things like SQL injection in the web APIs)
Findings
In summary there were a couple of interesting finds within the tablet. One of which is critical and can be leveraged to gain root access over the Storio Max tablet over the internet with a single web request to 127.0.0.1.
In the time we had, the following vulnerabilities were identified:
- The “storeintenttranslate.x” application can be leveraged to gain root RCE using a web request to 127.0.0.1
- It’s possible escape from the VTech interface using the keyboard language options
- Once escaped options such as USB Debugging are not restricted
- The warnings displayed on untrusted HTTPS are easy to ignore
- Outdated Android version 4.2.2
Realistically the storeintenttranslate attack could be used maliciously to capture the webcam and microphone of the device. In our demonstration with Test-Aankoop, we used the exploit to upload an Android meterpreter APK, take control of the webcam and send audio through the speakers to our volunteer.
Video
An example of the attack can be seen in the project video Test-Aankoop released, the dialog is in Dutch so you may need to use the English subtitles.
Solution
The patched tablet software version is “56.D3JM6” or later. So, if you haven’t already done so, ensure you patch your device as soon as possible.
However, due to the nature of this attack there is absolutely no way to know if your device is already compromised without forensic investigation which clearly the average consumer is not going to do. Therefore, the only way to be certain here is to replace the device, and ensure it’s been patched before it’s used. Factory resetting ‘should’ work, but an attack could bypass this by changing the reset process if the device is already compromised (albeit not an easy process, but technically possible).
VTech Disclosure Timeline
- 4th May 2018: Reported to VTech
- 24th May 2018: Chase sent
- 31st May 2018: Confirmation received from VTech that the patch has been released
- 31st May 2018: Patch checked and found to be effective
- 6th September 2018: Confirmation that fix has been successful
- 6th September 2018: Created CVE submission
- 7th September to 31st October 2018 – Various communication with VTech around the disclosure and a request that their userbase be informed (where possible)
- 1st November to 4th December 2018 – Waiting period to give parents as long as possible between VTech’s notice and our release to patch their tablets
- 5th December 2018 – Public Release
We left it much longer than we usually would to disclosure this kind of vulnerability for the simple reason that the patching process has to be manually invoked by a parent. Due to the seriousness of this vulnerability, we wanted to give a good window between a patch being available and releasing public details on how to exploit an unpatched tablet.
We have also worked with VTech around this disclosure and delayed public release until they issued an email to all affected users encouraging them to patch. This email went out around the middle of October. It must be stressed that VTech’s response to our reports and general communication has been fantastic, so real credit to them there in terms of their remediation processes.
About SureCloud
SureCloud is a provider of Cybersecurity services and cloud-based, integrated Risk Management products which reinvent the way you manage risk. Certified by the National Cyber Security Centre (NCSC) & CREST and delivered using the innovative Pentest-as-a-Service (underpinned by a highly configurable technology platform), SureCloud acts as an extension of your in-house security team and ensures you have everything you need to improve your risk posture.