{"id":103530,"date":"2020-08-05T21:01:06","date_gmt":"2020-08-06T04:01:06","guid":{"rendered":"\/blogs\/?p=103530"},"modified":"2024-07-07T23:23:00","modified_gmt":"2024-07-08T06:23:00","slug":"call-an-exorcist-my-robots-possessed","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/call-an-exorcist-my-robots-possessed\/","title":{"rendered":"Call an Exorcist! My Robot\u2019s Possessed!"},"content":{"rendered":"

<\/a>Overview<\/span><\/h2>\n

As part of our continued goal of helping developers provide safer products for businesses and consumers, we here at McAfee Advanced Threat Research (ATR) recently investigated temi<\/em>, a teleconference robot produced by Robotemi Global Ltd. Our research led us to discover four separate vulnerabilities in the temi robot, which this paper will describe in great detail. These include:<\/p>\n

    \n
  1. CVE-2020-16170 \u2013 Use of Hard-Coded Credentials<\/li>\n
  2. CVE-2020-16168 \u2013 Origin Validation Error<\/li>\n
  3. CVE-2020-16167 \u2013 Missing Authentication for Critical Function<\/li>\n
  4. CVE-2020-16169 \u2013 Authentication Bypass Using an Alternate Path of Channel<\/li>\n<\/ol>\n

    Together, these vulnerabilities could be used by a malicious actor to spy on temi\u2019s video calls, intercept calls intended for another user, and even remotely operate temi \u2013 all with zero authentication.<\/p>\n

    Per McAfee\u2019s vulnerability disclosure policy, we reported our findings to Robotemi Global Ltd. on March 5, 2020. Shortly thereafter, they responded and began an ongoing dialogue with ATR while they worked to adopt the mitigations we outlined in our disclosure report. As of July 15, 2020, these vulnerabilities have been successfully patched\u00a0\u2013 mitigated in version 120 of the temi’s Robox OS and all versions after 1.3.7931 of the temi Android app. We commend Robotemi for their prompt response and willingness to collaborate throughout this process. We\u2019d go so far as to say this has been one of the most responsive, proactive, and efficient vendors McAfee has had the pleasure of working with.<\/p>\n

    This paper is intended as a long-form technical analysis of the vulnerability discovery process, the exploits made possible by the vulns, and the potential impact such exploits may have. Those interested in a higher-level, less technical overview of these findings should refer to our summary blog post here<\/a>.<\/p>\n

    <\/a>Contents<\/h2>\n

    Overview<\/a>
    \n    Contents<\/a>
    \n    What is temi<\/a>
    \n    Normal Operation of temi<\/a>
    \n    Initial Recon<\/a>
    \n    Port Scanning<\/a>
    \n    Capturing Traffic<\/a>
    \n    Getting a Shell<\/a>
    \n    Finding temi\u2019s Code<\/a>
    \n    Reversing the Code for Video Calls<\/a>
    \n    Brute-Forcing the Channel Name as an Attack Vector<\/a>
    \n    Exploring MQTT Attack Vectors<\/a>
    \n    Overview<\/a>
    \n    Modifying the temi Phone App<\/a>
    \n    The Relationship Between Robot IDs and MQTT Topics<\/a>
    \n    How are MQTT Call Invite Messages Published?<\/a>
    \n    Intercepting Calls<\/a>
    \n    Problem: temi Won\u2019t Answer My Calls<\/a>
    \n    Solution: Become an OWNER<\/a>
    \n    Adding an OWNER: Phone App\u2019s Perspective<\/a>
    \n    Adding an OWNER: temi\u2019s Perspective<\/a>
    \n    Detour: Sneaking Onto temi\u2019s Contact List<\/a>
    \n    Gaining OWNER Privileges<\/a>
    \n    Refining the Exploits<\/a>
    \n    Impact<\/a>
    \n    Conclusion<\/a><\/p>\n

    <\/a>What is temi?<\/h2>\n

    Robots.<\/p>\n

    The final frontier.<\/p>\n

    For an Android tablet \u2018brain\u2019 sitting atop a 4-foot-tall robot, temi packs a lot of sensors into a small form factor. These include 360\u00b0 LIDAR, three different cameras, five proximity sensors, and even an Inertial Measurement Unit \u00a0(IMU) sensor, which is a sort of accelerometer + gyroscope + magnetometer all-in-one. All these work together to give temi something close to the ability to move autonomously through a space while avoiding any obstacles. If it weren\u2019t for the nefarious forces of stairs and curbs, temi would be unstoppable.<\/p>\n

    \"\"<\/p>\n

    Robotemi markets its robot as being used primarily for teleconferencing. Articles linked from the temi website describe the robot\u2019s applications in various industries: Connected Living recently partnered with temi for use in elder care, the Kellog\u2019s caf\u00e9 in NYC adopted temi to \u201cenhance the retail experience\u201d, and corporate staffing company Collabera uses temi to \u201cimprove cross-office communication.\u201d Despite its slogan of \u201cpersonal robot\u201d, it appears that temi is designed for both consumer and<\/em> enterprise applications, and it\u2019s the latter that really got us at McAfee Advanced Threat Research interested in it as a research target. Its growing presence in the medical space, which temi\u2019s creators have accommodated by stepping up production to 1,000 units a month, is especially interesting given the greatly increased demand for remote doctor\u2019s visits. What would a compromised temi mean for its users, whether it be the mother out on business, or the patient being diagnosed via robotic proxy? We placed our preorder and set out to find out.<\/p>\n

    <\/a>Normal Operation of temi<\/h2>\n

    Once it finally arrived, we got to setting it up the way any user might: we unboxed it, plugged in its charging dock, and connected it to WiFi. Normal operation of the temi robot is done through the use of its smart phone app, and at first startup temi prompted us to scan a QR code with the app. The phone used to scan the QR code becomes temi\u2019s \u201cadmin\u201d, allowing you to control the robot remotely by simply calling it. Temi can have many contacts outside of its singular admin, and becoming a contact is fairly straightforward. Whenever you launch the temi phone app, it scans your phone\u2019s contacts and automatically adds any numbers that have been registered with the temi app to the app\u2019s contact list. If any of those contacts happens to be a temi admin, you can call their temi simply by clicking that contact, as shown in Figure 1<\/u>.<\/p>\n

    \"\"<\/p>\n

    Figure 1: Selecting a contact from the temi phone app<\/p>\n

    In this way, users of the phone app besides temi\u2019s admin can still call a temi robot using this method. Since initiating a call with a temi allows you to remotely operate it in addition to seeing through its camera and hearing through its microphone, giving anyone the ability to call your temi could prove\u2026 problematic. Temi\u2019s creators address this exact issue on their FAQ page, as shown in Figure 2<\/u>.<\/p>\n

    \"\"<\/p>\n

    Figure 2: “Can anyone connect to my temi?”, from the temi’s FAQ page<\/p>\n

    The first line here is a bit misleading, since adding a temi’s admin as a phone contact seems to be sufficient to call that temi \u2013 the admin does not need to also have you added as a phone contact for this to work. That being said, this doesn\u2019t mean that just anyone can start controlling your temi; “physical permission on the robot side” is required for calls made by users that aren’t temi’s admin or explicitly authorized by said admin. In practice, this corresponds to a call notification on the temi’s screen that the user can either answer or decline. In other words, it\u2019s no more or less \u201csecure\u201d than receiving cold calls on your cell phone.<\/p>\n

    As for the last line, which refers to an admin\u2019s ability to grant certain users the option to \u201chop in\u201d to the robot, this is also done through the phone app by simply selecting the \u201cInvite New Member\u201d option from the temi\u2019s contact entry in the app, and then selecting one or more users from the app\u2019s contact list to \u201cinvite\u201d, as shown in Figure 3<\/u>.<\/p>\n

    \"\"<\/p>\n

    Figure 3: How to grant users special permissions from the phone app<\/p>\n

    Once a call has been established between the robot and a phone user, which either party may initiate, the phone user can do things like manually drive the robot around, add, remove, and navigate to saved locations, patrol between saved locations, control its volume, and more.<\/p>\n

    \"\"<\/p>\n

    Figure 4: Driving the temi using the phone app<\/p>\n

    Due to the level of control afforded to temi\u2019s callers, the calling functionality quickly became a priority during our investigation of the temi robot.<\/p>\n

    <\/a>Initial Recon<\/h2>\n

    <\/a>Port Scanning<\/h3>\n

    While a robot was certainly a bit different from our typical targets, we began our reconnaissance with methods that have stood the test of time: port scans, packet captures, and a local shell.<\/p>\n

    \"\"<\/p>\n

    Figure 5: Running Nmap on the temi<\/p>\n

    An Nmap scan revealed only one open port: TCP port 4443. Immediately we knew that Nmap\u2019s classification of this port being used for Pharos, a \u201csecure office printing solution for your business\u201d, was almost certainly wrong. Instead, it was likely that this port was being used for TLS communication as an alternative to the standard 443. While good to know, this didn\u2019t tell us much about the type of traffic temi expected on this port, or even what service(s) was handling that traffic, so we moved on.<\/p>\n

    <\/a>Capturing Traffic<\/h3>\n

    Next on our checklist was to obtain some captures of the robot\u2019s network traffic, focusing on traffic generated during boot, during an update, and during a video call.<\/p>\n

    Traffic captured when temi was booting up but otherwise idling showed three unique external IP addresses being accessed: 98.137.246.7, 54.85.186.18, and 34.206.180.208.<\/p>\n

    Running nslookup<\/a> on these IPs revealed that the first pointed to some Yahoo! media server, likely used for its news app, while the other two appeared to be AWS instances.<\/p>\n

    \"\"<\/p>\n

    Figure 6: Running nslookup on IPs accessed by temi<\/p>\n

    As for the data being sent\/received, there wasn\u2019t much to look at. The Yahoo! address was being accessed via HTTP (port 80), but the TCP packets had no payload. As for the AWS addresses, these were being accessed via TLS (port 443) and the data was encrypted.<\/p>\n

    For updates, temi accessed \u201ctemi-ota-updates.s3-accelerate.amazonaws.com\u201d, which was almost certainly a custom AWS instance set up by the folks at Robotemi. As with the other traffic to AWS, the updates were being encrypted.<\/p>\n

    <\/a>Getting a Shell<\/h3>\n

    In order to prod deeper, we needed a local shell on our temi. Fortunately, wireless connections via Android Debug Bridge, or ADB<\/a>, could be enabled through temi\u2019s settings from its touchscreen. Better still, the shell provided through ADB had root privileges, although the device itself was not \u201crooted\u201d. This was likely done to help facilitate \u201ctemi Developers\u201d, since the temi website has an entire portal dedicated to helping users develop custom apps for their robot<\/a>.<\/p>\n

    Unfortunately, the default shell granted via ADB was fairly stripped down, and each reboot would mean having to manually reopen temi\u2019s ADB port from its touchscreen before being able to connect to it again. Furthermore, this method required the temi software to be running in order to access our shell, which would leave us without recourse if our prodding somehow bricked that software. This was far from ideal.<\/p>\n

    While commands like adb push<\/a> made moving custom ARM binaries for bash, busybox<\/a>, and ssh onto temi fairly trivial, getting anything to run on boot proved more challenging. For starters, temi did not have the standard \/etc\/init.d\/ directory. Additionally, the primary scripts that would run on boot, like \/init.rc, would be loaded directly from the boot image, meaning any edits made to them would not persist across reboots. This was likely by design as part of Android\u2019s SELinux security model \u2013 we would have to be a little more creative if we wanted to convince temi to start an SSH server on boot.<\/p>\n

    Digging through the contents of \/init.rc, however, gave us a clue:<\/p>\n

    \"\"<\/p>\n

    Figure 7: Interesting entry in \/init.rc<\/p>\n

    For those unfamiliar with Android\u2019s Init language,<\/p>\n

    \u201cThe init language is used in plain text files that take the .rc file extension. There are typically multiple of these in multiple locations on the system, described below.
    \n\/init.rc is the primary .rc file and is loaded by the init executable at the beginning of its execution. It is responsible for the initial set up of the system.\u201d \u2013     Android docs<\/a>.<\/p>\n

    The entry shown in Figure 7<\/u>, one of the hundreds contained in temi\u2019s init.rc, tells the system to launch the service \u201cflash_recovery\u201d during boot with the argument \u201c\/system\/bin\/install-recovery.sh\u201d. The \u201cclass main\u201d is just a label used to group entries together, and \u201coneshot\u201d just means \u201cdo not restart the service when it exits.\u201d This entry stood out to us because it was invoking a script located in \/system\/bin\/, which was not<\/strong> loaded from the boot image, meaning any changes should stick. While the \/system partition is read-only by default, our root privileges made it trivial to temporarily remount \/system as read-write in order to add the following line to the end: \u201c\/system\/bin\/sshd\u201d. With that, we had a reliable means of getting a root shell on our temi to explore further.<\/p>\n

    <\/a>Finding temi\u2019s Code<\/h3>\n

    The first thing we did with our newfound freedom was run netstat:<\/p>\n

    \"\"<\/p>\n

    Figure 8: Running netstat<\/p>\n

    It appeared that most networking, including the open port 4443 we found using Nmap earlier, was being handled by \u201ccom.roboteam.teamy.usa\u201d. Based on the name alone, this was likely the main temi software running on the robot. Additionally, the name looked more like the name of an Android package than a native binary. We confirmed this by running:<\/p>\n

    \"\"<\/p>\n

    Figure 9: Trying to find the binary for com.roboteam.teamy.usa in \/proc<\/p>\n

    app_process32 (or app_process64, depending on architecture), is the binary used by Android for running Android apps, meaning we were looking for an APK, not an ELF. Under this assumption, we instead tried to find the code for this process using Android\u2019s pm<\/a> command:<\/p>\n

    \"\"<\/p>\n

    Figure 10: Looking for the APK for “com.roboteam.teamy.usa”<\/p>\n

    Sure enough, we had our APK.<\/p>\n

    Typically, every installed app on Android has a corresponding data directory, and we were able to find the one for this package under \/data\/data\/com.roboteam.teamy.usa:<\/p>\n

    \"\"<\/p>\n

    Figure 11: data directory for “com.roboteam.teamy.usa”<\/p>\n

    The lib\/ directory contained native code used by the package:<\/p>\n

    \"\"<\/p>\n

    Figure 12: native code used by “com.roboteam.teamy.usa”<\/p>\n

    After looking into several of these libraries, libagora-rtc-sdk-jni.so in particular stood out to us since it was part of Agora<\/a>, a platform that provides SDKs for voice, video, and Real-Time-Messaging (RTM) services. It was likely that temi was using Agora to implement its video calling functionality \u2013 the functionality we were most interested in.<\/p>\n

    By looking at this binary\u2019s strings, we were also able to determine that temi was using version 2.3.1 of the Agora Video SDK:<\/p>\n

    \"\"<\/p>\n

    Figure 13: Finding the Agora SDK version using strings<\/p>\n

    Of course, we were equally interested in the code for the temi phone app, which we obtained through the use of APK Extractor<\/a> and ADB. We were also curious to see if the Android phone app used the same version of the Agora SDK, which we checked by comparing their MD5 hashes:<\/p>\n

    \"\"<\/p>\n

    Figure 14: Comparing MD5 hashes for libagora between temi robot and temi phone app<\/p>\n

    Sure enough, they were the identical.<\/p>\n

    <\/a>Reversing the Code for Video Calls<\/h2>\n

    The next step was to begin reversing these apps in order to better understand how they worked. We decided to start by looking at the phone app\u2019s code, since it was easier to test the behavior of the phone app compared to the robot.<\/p>\n

    In order to decompile and analyze the APK, we used JADX<\/a>. Although there are many Java decompilers out there that work on Android code, JADX stood out to us due to its various features:<\/p>\n