Exemple d'analyse de la découverte des vulnérabilités des applications de chat dans l'application de jouet intelligent « Thomas the Tank Engine »

bug découverte background

ToyTalk est une startup de jouets d'intelligence artificielle fondée par d'anciens dirigeants de Pixar. Ils conçoivent des jouets intelligents dotés de fonctions de suivi visuel, de reconnaissance vocale et d'extension de réseau pour permettre aux enfants de communiquer via la voix et. reconnaissance de la réponse comportementale entre l'APP et les jouets, les enfants peuvent stimuler leur capacité à parler à des personnages virtuels et mieux comprendre le plaisir de l'interaction avec les jouets.

ToyTalk a lancé une application payante appelée "Thomas & Friends Talk To You" en juillet 2015, qui permet aux enfants de discuter avec des dessins animés bien connus. Chat interactif avec le personnage "Thomas the Tank Engine", qui permet les enfants pour interagir avec Thomas et ses amis Percy, Gordon, Henry, James, Edward, Toby, "Fat" et Thomas lors de 8 voyages d'histoire sur l'île de Sodor. M. Topham Hatt a mené un dialogue à double sens

.

Afin de tester la sécurité des produits jouets ToyTalk et les risques de sécurité causés par l'accès à l'environnement du réseau domestique, j'ai décidé de mener un dialogue bidirectionnel avec l'application « Thomas et ses amis discutent avec vous » pour mener des Analyse et recherche. Étant donné que les produits ToyTalk utilisent tous la même base de code et que cette application Thomas Talk est facile à installer et à supprimer, elle est pratique pour les tests et peut également être représentative d'autres produits ToyTalk tels que Hello Barbie et Barbie Hello. Dreamhouse peut également avoir la même vulnérabilité. 1 : - Manque de mécanisme d'authentification, l'attaquant peut facilement se faire passer pour un enfant pour parler à Thomas Toy

# Vulnérabilité 2 : - Peut se faire passer pour support@toytalk. com ou d'autres utilisateurs enregistrés pour envoyer des injections HTML lien de phishing malveillant email

Analyse du fonctionnement de l'APP

Après le "Thomas et ses amis discutent avec vous" L'APP est lancée, elle nécessite une saisie pour fournir un L'adresse e-mail du parent est utilisée pour confirmer l'utilisation de la fonction de reconnaissance vocale fournie par l'APP Après avoir soumis l'adresse e-mail, l'APP entre dans l'interface en cours d'exécution 🎜🎜#Au début, vous. peut avoir l'impression que la surface d'attaque exposée par cette application est très limitée, car elle doit fournir une autorisation de confirmation pour parler au jouet

Ensuite, je bloquerai la navigation Web de l'application. L'analyse a révélé que cette application est différente des autres applications dans la mesure où elle fournit un certificat d'authentification auprès du client. En d'autres termes, il y aura un processus d'authentification mutuelle entre l'application et son serveur WEB. jetez un œil au mécanisme de fonctionnement du certificat client et à la vérification du mot de passe associé

Après l'inversion, nous avons constaté que les deux fonctions suivantes sont plus intéressantes :

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);
        }
    }

Après cela, au lieu de en continuant à procéder à l'ingénierie inverse de la fonction de saisie du mot de passe, j'ai utilisé le script Python suivant avec la fonction Frida Hook pour vider les mots de passe et les noms de fichiers afin de creuser plus profondément :

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()

Heureusement, il peut être extrait de l'apk L'authentification correcte Le fichier de certificat peut être utilisé pour effectuer une attaque de l'homme du milieu (MITM). Fait intéressant, le fichier toystalk.12 n'est protégé par aucun mot de passe.

Les certificats clients peuvent désormais être utilisés, mais le mécanisme d'épinglage des certificats doit encore être contourné. Bien qu'il existe de nombreuses façons d'y parvenir, le moyen le plus simple consiste à supprimer le certificat dans l'apk, à reconstruire le programme et à le réinstaller. Importez le certificat client dans Burpsuite pour désactiver la fonction de verrouillage du certificat. Après cela, nous pouvons passer à la première étape du test de la plupart des programmes APP : l'interception du trafic.

Analyse de vulnérabilité

Vulnérabilité 1 - Absence de mécanisme d'authentification

Le programme APP fournit également une fonction moins évidente, à savoir qu'il capture l'audio Le fichier de la conversation est stocké en ligne et peut être relu par le parent ultérieurement. Cette fonctionnalité est liée à l'adresse e-mail utilisée pour l'autorisation précédente, bien que cette adresse e-mail ne soit utilisée que lorsque le parent effectue une réinitialisation du mot de passe.

Lorsque le bouton « parler » est enfoncé, l'application enverra le fichier audio capturé au serveur Web distant selon la méthode de requête POST suivante : # 🎜🎜#

https://asr.2.toytalk.com/v3/asr/0673bcb8-367a-44bc-aed5-8c21fb7086af/thomas/1502714441?account=&client=com.toytalk.thomas&locale=en_GB&device_id=&device_model=&os=Android&os_version=5.1&intelligence=0%2F1%2Fc%2F01cd49694727bbcf1c0cefd 7a4a24f2e_intelligence.ti z&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在开发过程中忽视了全面的安全考虑。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!