Shulou(Shulou.com)05/31 Report--

This article is to share with you about the example analysis of finding loopholes in the intelligent toy APP chat application of "small Train Thomas". The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Vulnerability discovery background

ToyTalk is an artificial intelligence toy startup founded by former Pixar executives. They design smart toys with visual tracking, voice recognition and network expansion functions, which enable children to communicate with each other through APP and behavior response recognition, stimulate children's ability to talk to virtual characters, and better achieve the fun of interaction with toys.

ToyTalk launched a paid APP called "Thomas & Friends Talk To You" in July 2015, which allows children to interact with the well-known cartoon character "Thomas the Tank Engine". It allows children to take part in eight storytelling trips to many islands. Have a two-way dialogue with Thomas and his friends Percy, Gordon, Henry, James, Edward, Toby, and Mr. Tofenhei (Sir Topham Hatt), the "fat manager".

In order to test the security of ToyTalk toy products and the security risks of accessing the home network environment, I decided to do some analysis and research on the "Thomas and his friends chat with you" APP. Because ToyTalk products all use the same code base, and this Thomas conversation APP is easy to install and remove, easy to test, and representative. In addition, other ToyTalk products such as Hello Barbie (Hello Barbie) and Barbie Hello Dreamhouse (Barbie Dream House) may have the same loophole.

Vulnerability situation

# loophole 1:-lack of authentication mechanism, attackers can easily pretend to be a child to talk to Thomas toys

# vulnerability 2-can impersonate support@toytalk.com or other registered users and send emails that inject malicious phishing links into HTML

Analysis of working principle of APP

After the APP of "Thomas and his friends chat with you" is launched, you are asked to enter an email address of the parent to confirm the use of the voice recognition function provided by APP. When the email address is submitted, APP enters the runtime interface.

At first, you may feel that the attack surface exposed by the APP is very limited, because it needs to provide confirmation permission to talk to the toy.

Next, I'm going to analyze the web browsing interception of the APP. And in the analysis, it is found that the APP is different from other applications, it provides a certificate to authenticate with the client, that is to say, there will be a process of mutual authentication between APP and its WEB server. Based on this, let's first take a look at the working mechanism of client certificate and related password authentication.

After reversing, we find that the following two functions are more interesting:

Public void setSslClientCertificate (String filename, String passphrase) {InputStream file = null; try {KeyStore store = KeyStore.getInstance ("PKCS12"); file = this.mContext.getResources (). GetAssets (). Open (filename); store.load (file, passphrase.toCharArray ()); this.mClientCertificate = KeyManagerFactory.getInstance (TrustManagerFactory.getDefaultAlgorithm ()); this.mClientCertificate.init (store, new char [0]) } catch (Exception e) {Log.OMG (e);} finally {Utils.close (file);}} public void setSslCaCertificate (String filename, String passphrase) {InputStream file = null; try {KeyStore store = KeyStore.getInstance ("BKS"); file = this.mContext.getResources (). GetAssets (). Open (filename) Store.load (file, passphrase.toCharArray ()); this.mCaCertificate = TrustManagerFactory.getInstance (TrustManagerFactory.getDefaultAlgorithm ()); this.mCaCertificate.init (store);} catch (Exception e) {Log.OMG (e);} finally {Utils.close (file);}}

After that, instead of looking in reverse for the password pass-in function, I used the following Python script with frida hook function to dump the password and filename:

Import fridaimport sysdef on_message (message, data): print messagedevice = frida.get_device_manager (). Enumerate_devices () [- 1] pid = device.spawn (["com.toytalk.thomas"]) print (pid) session = device.attach (pid) ss =''Java.perform (function () {var MyClass = Java.use ("com.toytalk.library.HttpRequester") MyClass.setSslCaCertificate.overload ("java.lang.String", "java.lang.String"). Implementation = function (a) {send (a); send (b); return this.setSslCaCertificate.overload ("java.lang.String", "java.lang.String") .call (this,a,b) } MyClass.setSslClientCertificate.overload ("java.lang.String", "java.lang.String"). Implementation = function (amemb) {send (a); send (b); return this.setSslCaCertificate.overload ("java.lang.String", "java.lang.String") .call (this,a,b) }}) script = session.create_script (ss) script.load () script.on ('message', on_message) device.resume (pid) # session.detach () sys.stdin.read ()

Happily, the correct authentication certificate file can be extracted from apk and can be used to perform man-in-the-middle attacks (MITM), while interestingly, the file toytalk.12 is not protected with any password.

Now we can use the client certificate, but we still need to bypass certificate locking (Certificate Pinning). Although there are several ways to do this, the easiest way is to delete the certificate from apk, rebuild the program, and then reinstall it. After importing the client certificate into Burpsuite and disabling the certificate locking feature, we can move on to the first step in most APP program testing-traffic interception.

Vulnerability analysis vulnerability 1-lack of authentication mechanism

The APP program also provides a less obvious feature that the audio files of the conversations captured are stored online and can be replayed by parents later, which is bound to the email address used for previous authorization, although this email address is only used when parents perform password resets.

When the "speak" button is pressed, APP sends the captured audio file to the remote Web server with the following POST request:

Https://asr.2.toytalk.com/v3/asr/0673bcb8-367a-44bc-aed5-8c21fb7086af/thomas/1502714441?account=&play_session=&client=com.toytalk.thomas&locale=en_GB&device_id=&device_model=&os=Android&os_version=5.1&intelligence=0%2F1%2Fc%2F01cd49694727bbcf1c0cefd7a4a24f2e_intelligence.tiz&ruleset_id=rs_b92dd8d9-cba9-4a76-a56b-51fc3d15f8f5&rate=16000

Although the content of the message involves a lot of variable values, by changing the current user ID to another user ID, the audio file can be sent to the specified user account name, which will allow some malicious attackers to send obscene audio messages to the children's parents.

In this case, although the user ID is a random globally unique identifier (GUID), we can find some valid user ID information based on known clues such as mailbox addresses.

In addition, after running the "strings" command of the ToyTalk code base, there are a few clues to follow:

So, according to the above information, once the client certificate is installed in the browser, access the address by:

Https://api.toytalk.com/v3/account/

You can download a file containing the user's ID. With the user's ID information in hand, you can change the ID information in the POST request and send the conversation audio to any email address that registers the APP. The vulnerability can be fixed by requiring the correct device ID and associated user ID. We haven't tested whether the device ID can be obtained in other ways, but to add a device ID to a user account, it seems that you need to access the associated email address.

Vulnerability reporting process

2017.8.14-report vulnerabilities to ToyTalk

2017.11.16-classified as a general vulnerability and fixed for the first time, changed to closed status

2017.11.29-ToyTalk tests again and finds that the vulnerability still exists and resets to the reopen state

2017.12.8-full fix of vulnerability

2017.12.18-vulnerability reward issues and closes vulnerability report

Vulnerability 2-malicious HTML framework can be injected into ToyTalk messages

A few days after the above loophole 1 was submitted, my friend suggested that I could study the mailbox injection mechanism of ToyTalk. When using an APP application registration device such as "Thomas And You", it sends an email to the email address provided by the user. Because the email contains the user information (device name), if the attacker uses the vulnerability 1 method to obtain the victim's user ID, then the device name contained in the email HTML can be modified to make the victim user ID the trusted sender. Send malicious phishing emails or arbitrarily changed messages to other victims.

In order to send phishing mail to the victim, the attacker first uses the mailbox to register on the APP, uses the registered mailbox address, and then uses the vulnerability 1 method to obtain the victim user ID, which is used to send the phishing mail later.

That is, first, the attacker uses the victim's registered email address and executes the following request to get the corresponding victim user ID:

GET / v3/account/ HTTP/1.1User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.1.1; ONEPLUS A3003 Build/NMF26F) Host: api.2.toytalk.comConnection: close

Then, using the user ID as the trusted sender, send malicious email content containing phishing links to other victims in the following POST way:

POST / v3/account//email/consent?device_id=asdf&device_name=TEST%20DEVICE "% 20click%20here&application=Thomas+And+You&always HTTP/1.1Content-Type: text/plainContent-Length: 0User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.1.1; ONEPLUS A3003 Build/NMF26F) Host: api.2.toytalk.comConnection: close

The above is just a simple example of PoC, which uses tags to inject HTML links into the email content framework, but if you take the time to adjust, you can also craft a more confusing phishing email, for example, a parent can fake an support@toytalk.com email to deceive other parents' username and password information. The following figure shows the content of an email containing phishing links sent by us impersonating the official toytalk:

Vulnerability reporting process:

2017.12.4-submission vulnerability

2017.12.12-official thanks

2017.12.18-official fix of vulnerability

2017.12.18-release reward and close vulnerability report

On the whole, there are certain restrictions on the exploitation of the two vulnerabilities, but it also shows that a large number of APP ignores comprehensive security considerations in the development process.

The above is the example analysis of the vulnerabilities found in the "small Train Thomas" smart toy APP chat application. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.