CVE-2017-3748

Description

On Lenovo VIBE mobile phones, improper access controls on the nac_server component can be abused in conjunction with CVE-2017-3749 and CVE-2017-3750 to elevate privileges to the root user (commonly known as 'rooting' or "jail breaking" a device).

All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.If you are an owner of some content and want it to be removed, please mail to content@vulners.com Vulners, 2018

{"fireeye": [{"lastseen": "2018-08-31T00:18:21", "bulletinFamily": "info", "description": "In May of 2016, Mandiant\u2019s Red Team discovered a series of vulnerabilities present on Lenovo\u2019s Vibe P1 Android-based mobile device that allow local privilege escalation to the user \u201croot\u201d. Mandiant disclosed these vulnerabilities to Lenovo in May of 2016. Lenovo advised Mandiant that it should work with Motorola, who it had acquired and was now responsible for Lenovo\u2019s mobile product portfolio. Mandiant then disclosed the vulnerabilities to Motorola for correction. The vulnerabilities discovered by Mandiant\u2019s Red Team were as follows:\n\n * Local backups enabled in Lenovo \u201cSecurity\u201d application (CVE-2017-3750)\n * Local backups enabled in Lenovo \u201cIdea Friend\u201d application (CVE-2017-3749)\n * Improper access controls in \u201cnac_server\u201d binary (CVE-2017-3748)\n\nThe [official Lenovo advisory](<https://support.lenovo.com/us/en/product_security/LEN-15823>) that includes the affected devices and software versions can be found on Motorola\u2019s website. Motorola has indicated that these vulnerabilities have since been patched, and the company supported Mandiant regarding the release of this post.\n\nWe have provided general details in an FAQ, and a technical analysis of the vulnerabilities follows.\n\n### FAQ\n\n**What devices are affected and (potentially) how many devices are affected?**\n\nThe vulnerabilities described in this post affect a subset of Lenovo-branded devices. A full list of the affected devices can be found within [Motorola\u2019s official advisory](<https://support.lenovo.com/us/en/product_security/LEN-15823>). Note that the vulnerabilities described in this post do not affect the Android Open Source Project (\u201cAOSP\u201d) developed by Google.\n\n**How is the issue being addressed?**\n\nMotorola has redesigned the affected mechanism to use a more secure process.\n\n**How would an attacker exploit these vulnerabilities?**\n\nThe described exploit chain requires local, physical access to a device. Therefore, is very unlikely to see this exploit \u201cin the wild\u201d. Users are recommended to update their devices to the most recent software package provided by Lenovo, and protect their devices using strong lock screen settings.\n\n**Who discovered these vulnerabilities?**\n\nJake Valletta ([@jake_valletta](<https://twitter.com/jake_valletta>))\n\n### Technical Analysis\n\nNow we will walk through the exploitation process Mandiant\u2019s Red Team used to obtain code execution as the user \u201croot\u201d by chaining the disclosed vulnerabilities together in a unique way.\n\n#### Identifying Our Target: \u201cnac_server\u201d\n\nA popular process for escalating privileges on Android devices is to enumerate locally listening sockets. While AF_INET sockets (think IP addresses and TCP/UDP ports) listening locally are rare on Android devices, AF_UNIX sockets (hereforth refered to as \u201cUNIX sockets\u201d) are used frequently by native Android daemons, including \u201cnetd\u201d, \u201cinstalld\u201d, and \u201cvold\u201d, most of which run with elevated privileges. UNIX sockets are represented as files on the filesystem, and are typically bound to socket-type files in the \u201c/dev/socket/\u201d directory. A specific subset of UNIX sockets bind to the abstract namespace (which are not bound to a filesystem-backed file), and are denoted with a leading \u2018@\u2019 character, such as \u201c@android:debuggerd32\u201d and \u201c@jdwp-control\u201d.\n\nUsing the \u201cnetstat\u201d module of the [\u201cbusybox\u201d](<https://busybox.net/about.html>) utility on a test Vibe, we can note interesting abstract sockets that do not appear to be part of the Android Open Source Project (\u201cAOSP\u201d), as highlighted in Figure 1. Note that we\u2019ll be using the Android Debug Bridge (\u201cadb\u201d) to interface with a test Lenovo Vibe throughout the post.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig1.jpeg) \nFigure 1: Abstract sockets on test Lenovo Vibe device\n\nTo find the binary that may be responsible for these UNIX sockets, a string search across all DEX bytecode and binaries on the device can be useful. A string search across system binaries (located on the device in the directories \u201c/system/bin/\u201d, \u201c/vendor/bin/\u201d, and \u201c/system/xbin/\u201d) indicated that the strings \u201cnac_server\u201d, \u201cnac_safe_server\u201d, and \u201csupercmdlocalsocket\u201d were all present in the binary file \u201c/system/bin/nac_server\u201d, a non-AOSP binary.\n\nTo confirm this, we can extract and view the \u201c/init.rc\u201d file present on the Vibe. In this file, we can see that Lenovo added an [init service](<https://android.googlesource.com/platform/system/core/+/master/init/README.md>) called \u201cnac_server\u201d, shown in Figure 2.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig2.png) \nFigure 2: \u201cnac_server\u201d service defined in \u201c/init.rc\u201d file\n\nThe \u201cinit\u201d process registers the \u201cnac_server\u201d service and runs as the user \u201croot\u201d at system boot. We can confirm this by checking the \u201cinit.svc.nac_server\u201d system property and by viewing the running processes on a test device, shown in Figure 3 and Figure 4 respectively. It is also important to note that the \u201cnac_server\u201d binary was running under the [SE for Android (\u201cSEAndroid\u201d)](<https://source.android.com/security/selinux/index.html>) context \u201cnac_server\u201d.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig3.png) \nFigure 3: Checking \u201cinit.svc.nac_server\u201d system property\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig4.png) \nFigure 4: \u201cnac_server\u201d process running as \u201croot\u201d user and \u201cnac_server\u201d SEAndroid context\n\nSince we know this process runs as a privileged process and listens on UNIX sockets, we shifted our analysis to the \u201cnac_server\u201d binary to understand its full capabilities.\n\n##### Binary Analysis of the \u201cnac_server\u201d\n\nTo map out the capabilities of the \u201cnac_server\u201d binary, Mandiant\u2019s Red Team worked along side FireEye Labs Advanced Reverse Engineers (\u201cFLARE\u201d) (shoutout to [@m_r_tz](<https://twitter.com/m_r_tz>)). As stated above, the \u201cinit\u201d process starts \u201c/system/bin/nac_server\u201d at system boot as the user \u201croot\u201d. Once started, \u201cnac_server\u201d spawns three threads, each bound to an abstract UNIX socket: \u201cnac_server\u201d, \u201cnac_safe_server\u201d, and \u201csupercmdlocalsocket\u201d. Each of these threads expects to receive a file path from a client across the socket. \u201cnac_server\u201d then performs the following security checks based on the file path:\n\n * Tokenizes the file path based on \u201c/\u201d, and assumes the third element is the calling package name, and the fourth argument the file to execute. The package name is then checked against a whitelist, shown in Figure 5.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig5.png) \nFigure 5: Whitelisted Lenovo-branded applications in \u201cnac_server\u201d\n\n * Parses the \u201c/data/system/packages.xml\u201d file to check if the calling package name is installed and the signature matches a list of internal signatures. One of the allowed signatures is depicted in Figure 6.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig6.png) \nFigure 6: Hardcoded package signature in \u201cnac_server\u201d\n\nAfter validating the file path, \u201cnac_server\u201d copies the file from the fourth argument to the directory \u201c/data/local/root_channel/[package_name]\u201d, sets the SEAndroid context to \u201croot_channel\u201d, and then executes the file using the \u201csystem(..)\u201d function as the user \u201croot\u201d. We\u2019ll be exploring the significance and capabilities of the \u201croot_channel\u201d SEAndroid context in the following section.\n\nIn short, the \u201cnac_server\u201d binary provides a mechanism for applications signed by Lenovo to execute files as a privileged process and context. There are obvious malicious reasons to include this functionality; however, Mandiant\u2019s research suggests that Lenovo used this functionality to create custom [\u201ciptables\u201d](<http://ipset.netfilter.org/iptables.man.html>) firewall rules from the Android runtime.\n\nBecause the \u201cnac_server\u201d falsely assumes the caller is the third token of the file path, we are able to confuse the service and feed it a file that we control (CVE-2017-3748).\n\n#### Understanding SEAndroid Contexts\n\nSEAndroid is a security feature added to Android devices starting in Android 4.3 (\u201cJelly Bean\u201d). One of the key reasons for adopting SEAndroid was to provide granular security control of powerful UIDs such as those associated with \u201csystem\u201d, \u201cradio\u201d, and \u201croot\u201d. Note that this section will not be a complete tutorial on SEAndroid (a more comprehensive description of SEAndroid can be found [here](<http://selinuxproject.org/page/NB_SEforAndroid_1>)). The SEAndroid-related files for our analysis are as follows:\n\n * /sepolicy \u2013 Binary kernel policy file loaded at system boot\n * /seapp_contexts \u2013 Rules for determining the SEAndroid domain and type of Android applications\n * /etc/security/mac_permissions.xml \u2013 x.509 certificate information to determine the correct domain to apply when the Zygote process spawns a new application (more information on the Zygote process can be found [here](<http://coltf.blogspot.com/p/android-os-processes-and-zygote.html>))\n\n##### \u201cnac_server\u201d UNIX Socket Analysis\n\nUnfortunately for us, attempting to connect to any of the three aforementioned UNIX sockets as the built-in \u201cshell\u201d user results in SEAndroid policy violation. Figure 7 shows a \u201cPermission denied\u201d error when we attempted to connect to the UNIX socket \u201csupercmdlocalsocket\u201d using the [\u201csocat\u201d](<https://linux.die.net/man/1/socat>) utility.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig7.png) \nFigure 7: Attempting to connect to \u201csupercmdlocalsocket\u201d abstract socket using \u201csocat\u201d\n\nFigure 8 shows the SEAndroid policy violation captured in the Android log buffers.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig8.png) \nFigure 8: Policy violation included in Android log buffers\n\nIn Figure 8, we see that the operating system denied the source context \u201cshell\u201d, the \u201cconnectto\u201d permission of the \u201cunix_stream_socket\u201d class for the \u201cnac_server\u201d type. As a researcher, we now want to know: _who can access this permission?_ To answer this, we can use the [\u201csesearch\u201d](<https://linux.die.net/man/1/sesearch>) utility as follows:\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig9.png) \nFigure 9: Performing lookup for \u201cconnectto\u201d permission using \u201csesearch\u201d\n\nRunning this tool indicates that three SEAndroid domains possess the correct permission: \u201csystem_app\u201d, \u201cplatform_app\u201d, and \u201cunconfineddomain\u201d. Fortunately, there are over 100 applications running in either the \u201cplatform_app\u201d or \u201csystem_app\u201d security domain. Based on this, our next goal is to achieve code execution in either the \u201csystem_app\u201d or the \u201cplatform_app\u201d domains so that we can connect to the \u201cnac_server\u201d UNIX sockets.\n\n##### \u201croot_channel\u201d Analysis\n\nIt is also worth exploring the capabilities of the \u201croot_channel\u201d SEAndroid context that the \u201cnac_server\u201d binary applies just prior to executing the command. On the Lenovo Vibe, the \u201croot_channel\u201d context is quite powerful, and includes full access to application data and Android runtime and write access to the \u201c/data/\u201d filesystem. What this context lacks is the ability to mount or remount filesystems and disable SEAndroid (we will leave this as an exercise for the reader).\n\n#### Triggering the \u201cnac_server\u201d Bug via Local Backups\n\nAndroid introduced local backups in Android 2.2 (\u201cFroyo\u201d). Local backups allow a user with physical access to a device with USB debugging enabled to download application data for specific applications and restore this data back to the device. Determination of whether an application can be backed up is controlled by the \u201candroid:backupAllowed\u201d attribute within an application\u2019s \u201cAndroidManifest.xml\u201d file. By default, this value is set to \u201ctrue\u201d for all applications except applications running as the shared UID \u201candroid.uid.system\u201d.\n\nTo create a backup of an application locally, we can use the \u201cadb\u201d command \u201cbackup\u201d shown in Figure 10.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig10.png) \nFigure 10: Creating a local backup for the \u201ccom.some.app\u201d application using \u201cadb\u201d\n\nThese local backups can then be unpacked using the open-source [Android Backup Extractor (\u201cabe\u201d)](<https://github.com/nelenkov/android-backup-extractor>) and the \u201ctar\u201d utility. Since these backups are not signed, we are free to make changes to the backup, such as edit configuration files or even add new files entirely. To repackage the backup, we can reverse the steps and use \u201ctar\u201d (or the [\u201cpax\u201d](<https://linux.die.net/man/1/pax>) utility), \u201cabe\u201d, and finally the \u201cadb\u201d command \u201crestore\u201d to restore the backup on our device. Figure 11 shows the command to restore a backup.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig11.png) \nFigure 11: Restoring new local backup using \u201cadb\u201d\n\n##### Abusing Backups Part 1: Code Execution (CVE-2017-3749)\n\nOne particularly dangerous side effect of allowing local backups is that a malicious user can modify an application\u2019s private files without the application knowing. This typically includes modifying configuration files to alter the behavior of the application (like changing your Angry Bird high score data), but in more rare cases, an attacker can modify supplemental DEX bytecode included as part of an application to take full control of an application. Note that an application\u2019s primary DEX bytecode is processed upon installation and stored outside of the application\u2019s data directory, so it is not a target.\n\nThis is the case for the Idea Friend application (\u201ccom.lenovo.ideafriend\u201d), which is the Lenovo-branded contact manager application. This application did not run as a privileged UID, but it did run in the \u201cplatform_app\u201d SEAndroid domain, shown in Figure 12.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig12.png) \nFigure 12: \u201ccom.lenovo.ideafriend\u201d application running in \u201cplatform_app\u201d security context\n\n**_Identifying and Modifying Supplemental Bytecode_**\n\nIf we create a local backup for the Idea Friend application using the aforementioned process, we will notice the directory \u201cf/parse/\u201d (which corresponds to \u201c/data/data/com.lenovo.ideafriend/files/parse/\u201d on a test device) contains 14 signed Java JAR archives, each containing DEX bytecode, as shown in Figure 13.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig13.png) \nFigure 13: JAR archives included in \u201cf/parse/\u201d directory of Idea Friend backup\n\nThe DEX code included in the JAR files \u201cParseUtilBubble_8.jar\u201d and \u201cparseUtilMain_8.jar\u201d is loaded dynamically by the Idea Friend application when launched, which means that if we can modify these JAR files, we can execute arbitrary code as the Idea Friend application. These JAR files are signed, which does not permit us to modify the contents of the archives; however, because our test device utilizes the [Android Runtime (\u201cART\u201d)](<https://source.android.com/devices/tech/dalvik/#features>), the operating system automatically optimizes DEX bytecode using \u201cdex2oat\u201d to produce an unsigned ELF binary. To confirm this behavior, we can see two OAT files in the directory \u201cr/app_outdex\u201d (which corresponds to \u201c/data/data/com.lenovo.ideafriend/app_outdex/\u201d on a test device). Figure 14 shows the OAT binaries optimized from the JAR files \u201cParseUtilBubble_8.jar\u201d and \u201cparseUtilMain_8.jar\u201d found in the directory \u201cr/app_outdex/\u201d, and Figure 15 confirms that these are ELF binaries (the file format used by ART).\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig14.png) \nFigure 14: Optimized OAT binaries in Idea Friend backup\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig15.png) \nFigure 15: Determining file type of ART binaries\n\nUsing techniques described in the [Black Hat Asia 2014 white paper \u201cHiding Behind ART\u201d](<https://www.blackhat.com/docs/asia-15/materials/asia-15-Sabanal-Hiding-Behind-ART-wp.pdf>), it is possible to create our own OAT ELF binaries given the original DEX bytecode. The process is summarized as follows:\n\n 1. Disassemble the existing DEX bytecode. For this, we can use [\u201cbaksmali\u201d](<https://github.com/JesusFreke/smali>).\n 2. Modify the disassembled DEX bytecode. In our case, we are going to add a LocalSocket client to connect to the UNIX socket \u201csupercmdlocalsocket\u201d within a method we know will be called by the Idea Friend application (keep reading for more on this).\n 3. Reassemble the new DEX. We can use [\u201csmali\u201d](<https://github.com/JesusFreke/smali>) for this.\n 4. Push the new DEX bytecode to our device with a filename that matches the exact length of the destination filename. For example, if our destination filename is \u201c/data/data/com.lenovo.ideafriend/app_outdex/parseUtilMain_8.dex\u201d, we need to push a file with the exact filename size of 63, or \u201c/data/local/tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.jar\u201d. This is important for a later step.\n 5. Manually invoke the \u201cdex2oat\u201d utility on our test device against the DEX bytecode to generate an optimized OAT file.\n 6. Pull the new OAT binary from the test device.\n 7. Replace the padded filename (which corresponds to the \u201cdex_file_location_data\u201d field) in the OAT DEX file header with the original file path. Note that because we padded it to the proper length, this will not affect any offsets in the binary. A text editor such as vim or 010 works here.\n 8. Reset the \u201cdex_file_location_checksum\u201d CRC32 checksum in the DEX header to be that of the original OAT binary. For this, we can use \u201cdexdump\u201d to obtain the checksum, and \u201cdd\u201d to replace it.\n\nWe will use this process in conjunction with a local backup for the Idea Friend application to connect to one of the UNIX sockets exposed by the \u201cnac_server\u201d binary. First, we will need to modify one of the JAR files and insert our malicious code.\n\n**_Creating the Socket Client_**\n\nOur first step is to generate the bytecode to connect to one of the \u201cnac_server\u201d\u2019s abstract UNIX socket. For this example, we have chosen to use the \u201csupercmdlocalsocket\u201d UNIX socket. We start by creating a Java class similar to Figure 16.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig16.png) \nFigure 16: \u201crun()\u201d method written in Java to connect to \u201csupercmdlocalsocket\u201d abstract UNIX socket\n\nWe can then compile this class, convert the class to DEX bytecode, and then disassemble using \u201csmali\u201d. Next, we find an opportune location to place this function.\n\n**_Inserting the Hook_**\n\nBy performing static and dynamic analysis on the Idea Friend application, we determined that the Idea Friend application executed the method \u201cgetBubbleViewVersion(..)\u201d of the class \u201ccn.com.xy.sms.sdk.Iservice.ParseUtilBubble\u201d contained in the JAR \u201cparseUtilBubble_8.jar\u201d when the application was launched. Knowing this, we add our malicious code to this class, and insert our hook in the \u201cgetBubbleViewVersion(..)\u201d method, as shown in Figure 17 and Figure 18.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig17.png) \nFigure 17: Hook in \u201cgetBubbleViewVersion(..)\u201d to call malicious code\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig18.png) \nFigure 18: \u201crun()\u201d method written in disassembled Dalvik to connect to \u201csupercmdlocalsocket\u201d\n\nWe can then perform steps 3-8 in the previously described process to generate our new ELF and restore our modified backup. All that remains now is to stage our malicious payload to be executed by the \u201cnac_server\u201d binary.\n\n##### Abusing Backups Part 2: Staging a Payload (CVE-2017-3750)\n\nWe know that the Idea Friend application can communicate with the \u201cnac_server\u201d UNIX sockets, but unfortunately, the Idea Friend application is not in the whitelist checked by the \u201cnac_server\u201d binary. This means we will need to find a second application to stage our payload. By comparing the list of applications in the whitelist of \u201cnac_server\u201d (Figure 5) against applications that allow local backups, we can determine a few potential targets. We will use the Lenovo Security application (\u201ccom.lenovo.security\u201d) as our target.\n\nWe will first follow the process outlined in the section \u201cAbusing Backups Part 1: Code Execution\u201d to generate a local backup for the Lenovo Security application. We then modify the backup to include the \u201cgo.sh\u201d shell script depicted in Figure 19. The \u201cgo.sh\u201d script will simply start a telnet server on TCP port 1234 when executed.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig19.png) \nFigure 19: Contents of \u201cgo.sh\u201d\n\nAfter re-packaging and restoring the backup, we can confirm that the file has been pushed to the device successfully using \u201cls\u201d:\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig20.png) \nFigure 20: Successfully pushed \u201cgo.sh\u201d to Lenovo Security application\n\n##### Chaining the Vulnerabilities\n\nWith our chain of vulnerabilities mapped out, we can now trigger the exploit with the following steps:\n\n 1. Launch the Settings application and clear the application data for the Idea Friend application. This removes any legitimate OAT binaries that may already exist.\n 2. Create a local backup of the Lenovo Security application.\n 3. Modify the local backup to contain the \u201cgo.sh\u201d payload.\n 4. Restore the modified backup to the device.\n 5. Create a local backup of the Idea Friend application.\n 6. Modify the local backup to include our malicious OAT binary.\n 7. Restore the modified backup to the device.\n 8. Launch the Idea Friend application. Since the OAT binaries already exist (and appear valid), the application will execute our code. This will cause the Idea Friend application to connect to the UNIX sockets exposed by \u201cnac_server\u201d and pass the file path of our staged payload, \u201cgo.sh\u201d. The \u201cnac_server\u201d will then execute our payload, starting the telnetd server.\n 9. Connect to the device using a telnet connection.\n\nFigure 21 depicts this process, and shows the output of the command \u201cid\u201d, indicating that we have code execution as the user \u201croot\u201d, with SEAndroid context of \u201croot_channel\u201d.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig21.png) \nFigure 21: Running as UID \u201croot\u201d and \u201croot_channel\u201d SEAndroid context\n\n### Conclusions\n\nPlatform developers should exercise caution when exposing sensitive functionality using abstract UNIX sockets. Instead, use file-based UNIX sockets with the proper filesystem permissions and SEAndroid policy in conjunction with a privileged [Android System Services](<http://processors.wiki.ti.com/index.php/Android-Adding_SystemService>) to create a more structured and secure model. Based on follow up analysis, this is the model that Motorola has decided to use.\n\nIn addition, allowing backups on privileged applications can also be detrimental and should be disallowed. Just because an application is not running as a privileged Android user ID such as \u201candroid.uid.system\u201d, does not mean that it cannot introduce vulnerabilities and be used to escalate privileges. Finally, applications should never allow executable code (Java classes, ELF binaries, or shared objects) within backups. This can be limited using a [BackupAgent](<https://developer.android.com/reference/android/app/backup/BackupAgent.html>).\n", "modified": "2017-06-29T12:30:00", "published": "2017-06-29T12:30:00", "id": "FIREEYE:5C58843A26441257A080D119A319D731", "href": "https://www.fireeye.com/blog/threat-research/2017/05/gaining-root-on-lenovo-vibe.html", "title": "Back That App Up: Gaining Root on the Lenovo Vibe", "type": "fireeye", "cvss": {"score": 7.2, "vector": "AV:LOCAL/AC:LOW/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2017-07-28T03:19:51", "bulletinFamily": "info", "description": "In May of 2016, Mandiant\u2019s Red Team discovered a series of vulnerabilities present on Lenovo\u2019s Vibe P1 Android-based mobile device that allow local privilege escalation to the user \u201croot\u201d. Mandiant disclosed these vulnerabilities to Lenovo in May of 2016. Lenovo advised Mandiant that it should work with Motorola, who it had acquired and was now responsible for Lenovo\u2019s mobile product portfolio. Mandiant then disclosed the vulnerabilities to Motorola for correction. The vulnerabilities discovered by Mandiant\u2019s Red Team were as follows:\n\n * Local backups enabled in Lenovo \u201cSecurity\u201d application (CVE-2017-3750)\n * Local backups enabled in Lenovo \u201cIdea Friend\u201d application (CVE-2017-3749)\n * Improper access controls in \u201cnac_server\u201d binary (CVE-2017-3748)\n\nThe [official Lenovo advisory](<https://support.lenovo.com/us/en/product_security/LEN-15823>) that includes the affected devices and software versions can be found on Motorola\u2019s website. Motorola has indicated that these vulnerabilities have since been patched, and the company supported Mandiant regarding the release of this post.\n\nWe have provided general details in an FAQ, and a technical analysis of the vulnerabilities follows.\n\n### FAQ\n\n**What devices are affected and (potentially) how many devices are affected?**\n\nThe vulnerabilities described in this post affect a subset of Lenovo-branded devices. A full list of the affected devices can be found within [Motorola\u2019s official advisory](<https://support.lenovo.com/us/en/product_security/LEN-15823>). Note that the vulnerabilities described in this post do not affect the Android Open Source Project (\u201cAOSP\u201d) developed by Google.\n\n**How is the issue being addressed?**\n\nMotorola has redesigned the affected mechanism to use a more secure process.\n\n**How would an attacker exploit these vulnerabilities?**\n\nThe described exploit chain requires local, physical access to a device. Therefore, is very unlikely to see this exploit \u201cin the wild\u201d. Users are recommended to update their devices to the most recent software package provided by Lenovo, and protect their devices using strong lock screen settings.\n\n**Who discovered these vulnerabilities?**\n\nJake Valletta ([@jake_valletta](<https://twitter.com/jake_valletta>))\n\n### Technical Analysis\n\nNow we will walk through the exploitation process Mandiant\u2019s Red Team used to obtain code execution as the user \u201croot\u201d by chaining the disclosed vulnerabilities together in a unique way.\n\n#### Identifying Our Target: \u201cnac_server\u201d\n\nA popular process for escalating privileges on Android devices is to enumerate locally listening sockets. While AF_INET sockets (think IP addresses and TCP/UDP ports) listening locally are rare on Android devices, AF_UNIX sockets (hereforth refered to as \u201cUNIX sockets\u201d) are used frequently by native Android daemons, including \u201cnetd\u201d, \u201cinstalld\u201d, and \u201cvold\u201d, most of which run with elevated privileges. UNIX sockets are represented as files on the filesystem, and are typically bound to socket-type files in the \u201c/dev/socket/\u201d directory. A specific subset of UNIX sockets bind to the abstract namespace (which are not bound to a filesystem-backed file), and are denoted with a leading \u2018@\u2019 character, such as \u201c@android:debuggerd32\u201d and \u201c@jdwp-control\u201d.\n\nUsing the \u201cnetstat\u201d module of the [\u201cbusybox\u201d](<https://busybox.net/about.html>) utility on a test Vibe, we can note interesting abstract sockets that do not appear to be part of the Android Open Source Project (\u201cAOSP\u201d), as highlighted in Figure 1. Note that we\u2019ll be using the Android Debug Bridge (\u201cadb\u201d) to interface with a test Lenovo Vibe throughout the post.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig1.jpeg) \nFigure 1: Abstract sockets on test Lenovo Vibe device\n\nTo find the binary that may be responsible for these UNIX sockets, a string search across all DEX bytecode and binaries on the device can be useful. A string search across system binaries (located on the device in the directories \u201c/system/bin/\u201d, \u201c/vendor/bin/\u201d, and \u201c/system/xbin/\u201d) indicated that the strings \u201cnac_server\u201d, \u201cnac_safe_server\u201d, and \u201csupercmdlocalsocket\u201d were all present in the binary file \u201c/system/bin/nac_server\u201d, a non-AOSP binary.\n\nTo confirm this, we can extract and view the \u201c/init.rc\u201d file present on the Vibe. In this file, we can see that Lenovo added an [init service](<https://android.googlesource.com/platform/system/core/+/master/init/README.md>) called \u201cnac_server\u201d, shown in Figure 2.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig2.png) \nFigure 2: \u201cnac_server\u201d service defined in \u201c/init.rc\u201d file\n\nThe \u201cinit\u201d process registers the \u201cnac_server\u201d service and runs as the user \u201croot\u201d at system boot. We can confirm this by checking the \u201cinit.svc.nac_server\u201d system property and by viewing the running processes on a test device, shown in Figure 3 and Figure 4 respectively. It is also important to note that the \u201cnac_server\u201d binary was running under the [SE for Android (\u201cSEAndroid\u201d)](<https://source.android.com/security/selinux/index.html>) context \u201cnac_server\u201d.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig3.png) \nFigure 3: Checking \u201cinit.svc.nac_server\u201d system property\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig4.png) \nFigure 4: \u201cnac_server\u201d process running as \u201croot\u201d user and \u201cnac_server\u201d SEAndroid context\n\nSince we know this process runs as a privileged process and listens on UNIX sockets, we shifted our analysis to the \u201cnac_server\u201d binary to understand its full capabilities.\n\n##### Binary Analysis of the \u201cnac_server\u201d\n\nTo map out the capabilities of the \u201cnac_server\u201d binary, Mandiant\u2019s Red Team worked along side FireEye Labs Advanced Reverse Engineers (\u201cFLARE\u201d) (shoutout to [@m_r_tz](<https://twitter.com/m_r_tz>)). As stated above, the \u201cinit\u201d process starts \u201c/system/bin/nac_server\u201d at system boot as the user \u201croot\u201d. Once started, \u201cnac_server\u201d spawns three threads, each bound to an abstract UNIX socket: \u201cnac_server\u201d, \u201cnac_safe_server\u201d, and \u201csupercmdlocalsocket\u201d. Each of these threads expects to receive a file path from a client across the socket. \u201cnac_server\u201d then performs the following security checks based on the file path:\n\n * Tokenizes the file path based on \u201c/\u201d, and assumes the third element is the calling package name, and the fourth argument the file to execute. The package name is then checked against a whitelist, shown in Figure 5.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig5.png) \nFigure 5: Whitelisted Lenovo-branded applications in \u201cnac_server\u201d\n\n * Parses the \u201c/data/system/packages.xml\u201d file to check if the calling package name is installed and the signature matches a list of internal signatures. One of the allowed signatures is depicted in Figure 6.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig6.png) \nFigure 6: Hardcoded package signature in \u201cnac_server\u201d\n\nAfter validating the file path, \u201cnac_server\u201d copies the file from the fourth argument to the directory \u201c/data/local/root_channel/[package_name]\u201d, sets the SEAndroid context to \u201croot_channel\u201d, and then executes the file using the \u201csystem(..)\u201d function as the user \u201croot\u201d. We\u2019ll be exploring the significance and capabilities of the \u201croot_channel\u201d SEAndroid context in the following section.\n\nIn short, the \u201cnac_server\u201d binary provides a mechanism for applications signed by Lenovo to execute files as a privileged process and context. There are obvious malicious reasons to include this functionality; however, Mandiant\u2019s research suggests that Lenovo used this functionality to create custom [\u201ciptables\u201d](<http://ipset.netfilter.org/iptables.man.html>) firewall rules from the Android runtime.\n\nBecause the \u201cnac_server\u201d falsely assumes the caller is the third token of the file path, we are able to confuse the service and feed it a file that we control (CVE-2017-3748).\n\n#### Understanding SEAndroid Contexts\n\nSEAndroid is a security feature added to Android devices starting in Android 4.3 (\u201cJelly Bean\u201d). One of the key reasons for adopting SEAndroid was to provide granular security control of powerful UIDs such as those associated with \u201csystem\u201d, \u201cradio\u201d, and \u201croot\u201d. Note that this section will not be a complete tutorial on SEAndroid (a more comprehensive description of SEAndroid can be found [here](<http://selinuxproject.org/page/NB_SEforAndroid_1>)). The SEAndroid-related files for our analysis are as follows:\n\n * /sepolicy \u2013 Binary kernel policy file loaded at system boot\n * /seapp_contexts \u2013 Rules for determining the SEAndroid domain and type of Android applications\n * /etc/security/mac_permissions.xml \u2013 x.509 certificate information to determine the correct domain to apply when the Zygote process spawns a new application (more information on the Zygote process can be found [here](<http://coltf.blogspot.com/p/android-os-processes-and-zygote.html>))\n\n##### \u201cnac_server\u201d UNIX Socket Analysis\n\nUnfortunately for us, attempting to connect to any of the three aforementioned UNIX sockets as the built-in \u201cshell\u201d user results in SEAndroid policy violation. Figure 7 shows a \u201cPermission denied\u201d error when we attempted to connect to the UNIX socket \u201csupercmdlocalsocket\u201d using the [\u201csocat\u201d](<https://linux.die.net/man/1/socat>) utility.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig7.png) \nFigure 7: Attempting to connect to \u201csupercmdlocalsocket\u201d abstract socket using \u201csocat\u201d\n\nFigure 8 shows the SEAndroid policy violation captured in the Android log buffers.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig8.png) \nFigure 8: Policy violation included in Android log buffers\n\nIn Figure 8, we see that the operating system denied the source context \u201cshell\u201d, the \u201cconnectto\u201d permission of the \u201cunix_stream_socket\u201d class for the \u201cnac_server\u201d type. As a researcher, we now want to know: _who can access this permission?_ To answer this, we can use the [\u201csesearch\u201d](<https://linux.die.net/man/1/sesearch>) utility as follows:\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig9.png) \nFigure 9: Performing lookup for \u201cconnectto\u201d permission using \u201csesearch\u201d\n\nRunning this tool indicates that three SEAndroid domains possess the correct permission: \u201csystem_app\u201d, \u201cplatform_app\u201d, and \u201cunconfineddomain\u201d. Fortunately, there are over 100 applications running in either the \u201cplatform_app\u201d or \u201csystem_app\u201d security domain. Based on this, our next goal is to achieve code execution in either the \u201csystem_app\u201d or the \u201cplatform_app\u201d domains so that we can connect to the \u201cnac_server\u201d UNIX sockets.\n\n##### \u201croot_channel\u201d Analysis\n\nIt is also worth exploring the capabilities of the \u201croot_channel\u201d SEAndroid context that the \u201cnac_server\u201d binary applies just prior to executing the command. On the Lenovo Vibe, the \u201croot_channel\u201d context is quite powerful, and includes full access to application data and Android runtime and write access to the \u201c/data/\u201d filesystem. What this context lacks is the ability to mount or remount filesystems and disable SEAndroid (we will leave this as an exercise for the reader).\n\n#### Triggering the \u201cnac_server\u201d Bug via Local Backups\n\nAndroid introduced local backups in Android 2.2 (\u201cFroyo\u201d). Local backups allow a user with physical access to a device with USB debugging enabled to download application data for specific applications and restore this data back to the device. Determination of whether an application can be backed up is controlled by the \u201candroid:backupAllowed\u201d attribute within an application\u2019s \u201cAndroidManifest.xml\u201d file. By default, this value is set to \u201ctrue\u201d for all applications except applications running as the shared UID \u201candroid.uid.system\u201d.\n\nTo create a backup of an application locally, we can use the \u201cadb\u201d command \u201cbackup\u201d shown in Figure 10.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig10.png) \nFigure 10: Creating a local backup for the \u201ccom.some.app\u201d application using \u201cadb\u201d\n\nThese local backups can then be unpacked using the open-source [Android Backup Extractor (\u201cabe\u201d)](<https://github.com/nelenkov/android-backup-extractor>) and the \u201ctar\u201d utility. Since these backups are not signed, we are free to make changes to the backup, such as edit configuration files or even add new files entirely. To repackage the backup, we can reverse the steps and use \u201ctar\u201d (or the [\u201cpax\u201d](<https://linux.die.net/man/1/pax>) utility), \u201cabe\u201d, and finally the \u201cadb\u201d command \u201crestore\u201d to restore the backup on our device. Figure 11 shows the command to restore a backup.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig11.png) \nFigure 11: Restoring new local backup using \u201cadb\u201d\n\n##### Abusing Backups Part 1: Code Execution (CVE-2017-3749)\n\nOne particularly dangerous side effect of allowing local backups is that a malicious user can modify an application\u2019s private files without the application knowing. This typically includes modifying configuration files to alter the behavior of the application (like changing your Angry Bird high score data), but in more rare cases, an attacker can modify supplemental DEX bytecode included as part of an application to take full control of an application. Note that an application\u2019s primary DEX bytecode is processed upon installation and stored outside of the application\u2019s data directory, so it is not a target.\n\nThis is the case for the Idea Friend application (\u201ccom.lenovo.ideafriend\u201d), which is the Lenovo-branded contact manager application. This application did not run as a privileged UID, but it did run in the \u201cplatform_app\u201d SEAndroid domain, shown in Figure 12.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig12.png) \nFigure 12: \u201ccom.lenovo.ideafriend\u201d application running in \u201cplatform_app\u201d security context\n\n**_Identifying and Modifying Supplemental Bytecode_**\n\nIf we create a local backup for the Idea Friend application using the aforementioned process, we will notice the directory \u201cf/parse/\u201d (which corresponds to \u201c/data/data/com.lenovo.ideafriend/files/parse/\u201d on a test device) contains 14 signed Java JAR archives, each containing DEX bytecode, as shown in Figure 13.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig13.png) \nFigure 13: JAR archives included in \u201cf/parse/\u201d directory of Idea Friend backup\n\nThe DEX code included in the JAR files \u201cParseUtilBubble_8.jar\u201d and \u201cparseUtilMain_8.jar\u201d is loaded dynamically by the Idea Friend application when launched, which means that if we can modify these JAR files, we can execute arbitrary code as the Idea Friend application. These JAR files are signed, which does not permit us to modify the contents of the archives; however, because our test device utilizes the [Android Runtime (\u201cART\u201d)](<https://source.android.com/devices/tech/dalvik/#features>), the operating system automatically optimizes DEX bytecode using \u201cdex2oat\u201d to produce an unsigned ELF binary. To confirm this behavior, we can see two OAT files in the directory \u201cr/app_outdex\u201d (which corresponds to \u201c/data/data/com.lenovo.ideafriend/app_outdex/\u201d on a test device). Figure 14 shows the OAT binaries optimized from the JAR files \u201cParseUtilBubble_8.jar\u201d and \u201cparseUtilMain_8.jar\u201d found in the directory \u201cr/app_outdex/\u201d, and Figure 15 confirms that these are ELF binaries (the file format used by ART).\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig14.png) \nFigure 14: Optimized OAT binaries in Idea Friend backup\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig15.png) \nFigure 15: Determining file type of ART binaries\n\nUsing techniques described in the [Black Hat Asia 2014 white paper \u201cHiding Behind ART\u201d](<https://www.blackhat.com/docs/asia-15/materials/asia-15-Sabanal-Hiding-Behind-ART-wp.pdf>), it is possible to create our own OAT ELF binaries given the original DEX bytecode. The process is summarized as follows:\n\n 1. Disassemble the existing DEX bytecode. For this, we can use [\u201cbaksmali\u201d](<https://github.com/JesusFreke/smali>).\n 2. Modify the disassembled DEX bytecode. In our case, we are going to add a LocalSocket client to connect to the UNIX socket \u201csupercmdlocalsocket\u201d within a method we know will be called by the Idea Friend application (keep reading for more on this).\n 3. Reassemble the new DEX. We can use [\u201csmali\u201d](<https://github.com/JesusFreke/smali>) for this.\n 4. Push the new DEX bytecode to our device with a filename that matches the exact length of the destination filename. For example, if our destination filename is \u201c/data/data/com.lenovo.ideafriend/app_outdex/parseUtilMain_8.dex\u201d, we need to push a file with the exact filename size of 63, or \u201c/data/local/tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.jar\u201d. This is important for a later step.\n 5. Manually invoke the \u201cdex2oat\u201d utility on our test device against the DEX bytecode to generate an optimized OAT file.\n 6. Pull the new OAT binary from the test device.\n 7. Replace the padded filename (which corresponds to the \u201cdex_file_location_data\u201d field) in the OAT DEX file header with the original file path. Note that because we padded it to the proper length, this will not affect any offsets in the binary. A text editor such as vim or 010 works here.\n 8. Reset the \u201cdex_file_location_checksum\u201d CRC32 checksum in the DEX header to be that of the original OAT binary. For this, we can use \u201cdexdump\u201d to obtain the checksum, and \u201cdd\u201d to replace it.\n\nWe will use this process in conjunction with a local backup for the Idea Friend application to connect to one of the UNIX sockets exposed by the \u201cnac_server\u201d binary. First, we will need to modify one of the JAR files and insert our malicious code.\n\n**_Creating the Socket Client_**\n\nOur first step is to generate the bytecode to connect to one of the \u201cnac_server\u201d\u2019s abstract UNIX socket. For this example, we have chosen to use the \u201csupercmdlocalsocket\u201d UNIX socket. We start by creating a Java class similar to Figure 16.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig16.png) \nFigure 16: \u201crun()\u201d method written in Java to connect to \u201csupercmdlocalsocket\u201d abstract UNIX socket\n\nWe can then compile this class, convert the class to DEX bytecode, and then disassemble using \u201csmali\u201d. Next, we find an opportune location to place this function.\n\n**_Inserting the Hook_**\n\nBy performing static and dynamic analysis on the Idea Friend application, we determined that the Idea Friend application executed the method \u201cgetBubbleViewVersion(..)\u201d of the class \u201ccn.com.xy.sms.sdk.Iservice.ParseUtilBubble\u201d contained in the JAR \u201cparseUtilBubble_8.jar\u201d when the application was launched. Knowing this, we add our malicious code to this class, and insert our hook in the \u201cgetBubbleViewVersion(..)\u201d method, as shown in Figure 17 and Figure 18.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig17.png) \nFigure 17: Hook in \u201cgetBubbleViewVersion(..)\u201d to call malicious code\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig18.png) \nFigure 18: \u201crun()\u201d method written in disassembled Dalvik to connect to \u201csupercmdlocalsocket\u201d\n\nWe can then perform steps 3-8 in the previously described process to generate our new ELF and restore our modified backup. All that remains now is to stage our malicious payload to be executed by the \u201cnac_server\u201d binary.\n\n##### Abusing Backups Part 2: Staging a Payload (CVE-2017-3750)\n\nWe know that the Idea Friend application can communicate with the \u201cnac_server\u201d UNIX sockets, but unfortunately, the Idea Friend application is not in the whitelist checked by the \u201cnac_server\u201d binary. This means we will need to find a second application to stage our payload. By comparing the list of applications in the whitelist of \u201cnac_server\u201d (Figure 5) against applications that allow local backups, we can determine a few potential targets. We will use the Lenovo Security application (\u201ccom.lenovo.security\u201d) as our target.\n\nWe will first follow the process outlined in the section \u201cAbusing Backups Part 1: Code Execution\u201d to generate a local backup for the Lenovo Security application. We then modify the backup to include the \u201cgo.sh\u201d shell script depicted in Figure 19. The \u201cgo.sh\u201d script will simply start a telnet server on TCP port 1234 when executed.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig19.png) \nFigure 19: Contents of \u201cgo.sh\u201d\n\nAfter re-packaging and restoring the backup, we can confirm that the file has been pushed to the device successfully using \u201cls\u201d:\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig20.png) \nFigure 20: Successfully pushed \u201cgo.sh\u201d to Lenovo Security application\n\n##### Chaining the Vulnerabilities\n\nWith our chain of vulnerabilities mapped out, we can now trigger the exploit with the following steps:\n\n 1. Launch the Settings application and clear the application data for the Idea Friend application. This removes any legitimate OAT binaries that may already exist.\n 2. Create a local backup of the Lenovo Security application.\n 3. Modify the local backup to contain the \u201cgo.sh\u201d payload.\n 4. Restore the modified backup to the device.\n 5. Create a local backup of the Idea Friend application.\n 6. Modify the local backup to include our malicious OAT binary.\n 7. Restore the modified backup to the device.\n 8. Launch the Idea Friend application. Since the OAT binaries already exist (and appear valid), the application will execute our code. This will cause the Idea Friend application to connect to the UNIX sockets exposed by \u201cnac_server\u201d and pass the file path of our staged payload, \u201cgo.sh\u201d. The \u201cnac_server\u201d will then execute our payload, starting the telnetd server.\n 9. Connect to the device using a telnet connection.\n\nFigure 21 depicts this process, and shows the output of the command \u201cid\u201d, indicating that we have code execution as the user \u201croot\u201d, with SEAndroid context of \u201croot_channel\u201d.\n\n![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/Back%20that%20app%20up/Fig21.png) \nFigure 21: Running as UID \u201croot\u201d and \u201croot_channel\u201d SEAndroid context\n\n### Conclusions\n\nPlatform developers should exercise caution when exposing sensitive functionality using abstract UNIX sockets. Instead, use file-based UNIX sockets with the proper filesystem permissions and SEAndroid policy in conjunction with a privileged [Android System Services](<http://processors.wiki.ti.com/index.php/Android-Adding_SystemService>) to create a more structured and secure model. Based on follow up analysis, this is the model that Motorola has decided to use.\n\nIn addition, allowing backups on privileged applications can also be detrimental and should be disallowed. Just because an application is not running as a privileged Android user ID such as \u201candroid.uid.system\u201d, does not mean that it cannot introduce vulnerabilities and be used to escalate privileges. Finally, applications should never allow executable code (Java classes, ELF binaries, or shared objects) within backups. This can be limited using a [BackupAgent](<https://developer.android.com/reference/android/app/backup/BackupAgent.html>).\n", "modified": "2017-06-29T12:30:00", "published": "2017-06-29T12:30:00", "href": "https://www.fireeye.com/blog/threat-research/2017/05/gaining-root-on-lenovo-vibe.html", "id": "FIREEYE:8149FEA32D1CE10748ECD995597C9CD9", "title": "Back That App Up: Gaining Root on the Lenovo Vibe", "type": "fireeye", "cvss": {"score": 7.2, "vector": "AV:LOCAL/AC:LOW/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}], "lenovo": [{"lastseen": "2018-07-13T19:27:31", "bulletinFamily": "info", "description": "**Lenovo Security Advisory**: LEN-15823\n\n**Potential Impact:** Elevation of Privilege\n\n**Severity:** Medium\n\n**Scope of Impact: **Lenovo specific\n\n**CVE Identifier: **CVE-2017-3748, CVE-2017-3749, CVE-2017-3750\n\n**Summary Description:**\n\nVulnerabilities have been identified on Lenovo VIBE Mobile Phones that allow the user or an attacker with physical possession of a device that is not protected with a secure lock screen, e.g. PIN/Password, to elevate privileges to the root user (commonly known as \u201crooting\u201d or \u201cjailbreaking\u201d a device) with the ability to modify the device\u2019s operation and functionality in myriad ways.\n\n1\\. CVE-2017-3748 - Improper access controls on the nac_server component can be abused in conjunction with CVE-2017-3749 and CVE-2017-3750 to elevate privileges to the root user (commonly known as \u2018rooting\u2019 or \u201cjail breaking\u201d a device).\n\n2\\. CVE-2017-3749 - The Idea Friend Android application allows private data to be backed up and restored via Android Debug Bridge, which allows tampering leading to privilege escalation in conjunction with CVE-2017-3748 and CVE-2017-3750\n\n3\\. CVE-2017-3750 - The Lenovo Security Android application allows private data to be backed up and restored via Android Debug Bridge, which allows tampering leading to privilege escalation in conjunction with CVE-2017-3748\n\n**Mitigation Strategy for Customers (what you should do to protect yourself):**\n\nLenovo does not advise end users to root devices as it may adversely affect device security &amp; stability.\n\nUsers on older Android releases (earlier than Android 6.0 Marshmallow) are advised to take the following actions:\n\n1) If you have enabled the Android Developer Options menu on your device (uncommon), disable ADB when not in use\n\n2) Enable lock screen authentication mechanisms; e.g. PIN/Password protection\n", "modified": "2017-06-23T00:00:00", "published": "2017-06-23T00:00:00", "id": "LENOVO:PS500116-NOSID", "href": "https://support.lenovo.com/us/en/product_security/len-15823", "title": "Local Root Exploit on Lenovo VIBE Mobile Phones - us", "type": "lenovo", "cvss": {"score": 7.2, "vector": "AV:LOCAL/AC:LOW/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}]}