Example analysis of discovering chat application vulnerabilities in the 'Thomas the Tank Engine' smart toy APP

Vulnerability Discovery Background

ToyTalk is an artificial intelligence toy start-up company founded by former Pixar executives. The smart toys they design have visual tracking, voice recognition and network expansion functions, allowing children to interact with them through APPs. Voice communication and behavioral response recognition are carried out between toys, stimulating children's ability to talk with virtual characters, and better realizing the fun of interaction with toys.

ToyTalk launched a paid APP called "Thomas & Friends Talk To You" in July 2015, which allows children to "talk to famous cartoon characters" "Thomas the Tank Engine" interactive chat, which allows children to interact with Thomas and his friends Percy, Gordon, Henry, James, Edward, Toby, and the "Fat Controller" on 8 story trips to the Island of Sodor. Sir Topham Hatt conducted a two-way conversation.

In order to test the security of ToyTalk toy products and the security risks caused by accessing the home network environment, I decided to conduct a two-way conversation with "Thomas and His Friends" Conduct some analysis and research on the "Chat with You" APP. Since ToyTalk products all use the same code base, and this Thomas Talk APP is easy to install and remove, it is convenient for testing and can also be representative. In addition, ToyTalk's other products, such as Hello Barbie (Hello Barbie) and Barbie Hello Dreamhouse (Barbie Dreamhouse) may also have the same vulnerability.

Vulnerability Situation

#Vulnerability 1: - Lack of authentication mechanism, attack An attacker can easily pretend to be a child and have a conversation with Thomas Toy

#Vulnerability 2: - Possible to impersonate support@toytalk.com or other registered users and send emails with malicious HTML phishing links injected

Analysis of how the APP works

After the "Thomas and his friends chat with you" APP is launched, it requires a parent's email address to confirm the use of the voice recognition function provided by the APP. After submitting the email address, the APP enters the running interface.

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

Next, I will perform a network browsing interception analysis on the APP. And during the analysis, I found that this APP is different from other applications in that it provides an authentication method with the client. Certificate, that is to say, there will also be a mutual authentication process between the APP and its WEB server. Based on this, we need to first look at the working mechanism of the client certificate and related password verification.

After reversing, we found 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, I did not continue to reverse the search for password input functions, but used the following Python with frida hook function, which can dump passwords and file names. Script to dig deeper:

import frida
import sys
def on_message(message, data):
    print message
device = 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,b){
        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(a,b){
        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 the apk and can be used to perform a man-in-the-middle attack (MITM). Interestingly, the file toystalk.12 does not use any password protection.

#Client certificates can now be used, but the certificate pinning mechanism still needs to be bypassed. Although there are many ways to achieve this, the easiest way is to delete the certificate in the apk, rebuild the program, and reinstall it. Import the client certificate into Burpsuite to disable the certificate locking function. After that, we can enter the first step of testing most APP programs - traffic interception.

Vulnerability Analysis

Vulnerability 1 - Lack of authentication mechanism

The APP also provides a less obvious function, that is, the captured conversation audio files will be stored online , which can be used by parents for subsequent replay listening. This function is bound to the email address used for previous authorization, although this email address is only used when parents perform a password reset.

When the "speak" button is pressed, the APP will send the captured audio file to the remote web server in the following POST request method:

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/1/c/01cd49694727bbcf1c0cefd7a4a24f2e_intelligence.tiz&ruleset_id=rs_b92dd8d9 -cba9-4a76-a56b-51fc3d15f8f5&rate=16000

虽然其中的发送内容涉及很多变量值，但通过把当前用户ID更改为其它用户ID后，就能把音频文件发送到指定的用户账户名下，这将会允许一些恶意攻击者向儿童父母发送一些淫秽音频信息。

在这种情况下，虽然用户ID是一个随机的全局惟一标识符（GUID），但我们可以根据邮箱地址等已知线索来发现一些有效的用户ID信息。

此外，通过在ToyTalk代码库上运行“strings”命令，我们也可以找到一些线索：

所以，根据上图信息，一旦客户端证书被安装到浏览器中后，通过访问地址：

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

就能下载到一个包含用户ID的文件。有用户ID信息在手，就能更改POST请求中的ID信息，将对话音频发送到任何注册了该APP的邮箱地址中去。修复该漏洞的方法是要求提供正确的设备ID和相关联的用户ID。我们还没测试设备ID是否能以其它方法获取，但要向某个用户账号添加一个设备ID，貌似需要访问到关联的邮箱地址才行。

漏洞报送进程

2017.8.14 -  向ToyTalk报告漏洞

2017.11.16 - 被分类为一般漏洞并被初次修复，变为closed状态

2017.11.29 - ToyTalk再次测试发现漏洞仍然存在，并重置为reopen状态

2017.12.8  - 完全修复漏洞

2017.12.18 - 漏洞赏金发放并关闭漏洞报告

漏洞2 - 可向ToyTalk邮件中注入恶意HTML框架

几天过后，我的朋友建议我学习一下ToyTalk的邮箱注入机制，这是在提交漏洞1后发生的。在使用诸如“Thomas And You”等APP应用注册设备时，它会将一封电子邮件发送到用户提供的邮箱地址中， 由于该电子邮件中包含了用户信息（设备名称），如果攻击者利用漏洞1方法获取到受害者的用户ID之后，那么，接下来可以修改电子邮件HTML中包含的设备名称，以该受害者用户ID为可信发件人，向其它受害者发送恶意钓鱼邮件，或任意更改过的邮件内容。

为了向受害者发送钓鱼邮件，攻击者先要用邮箱在该APP上进行注册，利用该注册邮箱地址，再用漏洞1方法获取到受害者用户ID，用以后续进行钓鱼邮件发送。

也即，首先，攻击者用受害者注册过的邮箱地址，执行以下请求，以获取到相应的受害者用户ID：

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

然后，再以该用户ID为可信发件人，用以下POST方式，向其它受害者发送包含钓鱼链接的恶意邮件内容：

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

以上只是一个简单的PoC示例，它利用标签将HTML链接注入到邮件内容框架中，但如果花时间调整，也可以精心制作出一个更具迷惑性的钓鱼邮件来，例如，某位家长可以假冒support@toytalk.com邮件来欺骗其它家长的用户名密码信息。以下邮件内容包含钓鱼链接，是我们冒充toytalk官方发送的：

漏洞报送进程：

2017.12.4 - 提交漏洞

2017.12.12 - 官方致谢

2017.12.18 - 官方修复漏洞

2017.12.18 - 发布赏金并关闭漏洞报告

整体来说，两个漏洞的利用方式都存在一定的受限条件，但也侧面说明了大量APP在开发过程中忽视了全面的安全考虑。

The above is the detailed content of Example analysis of discovering chat application vulnerabilities in the 'Thomas the Tank Engine' smart toy APP. For more information, please follow other related articles on the PHP Chinese website!