Assessing the ‘War on Tech’: Huawei vs. U.S.

[I wrote this with Curtis Kang who did a lot of work researching various aspects of this article and provided invaluable help. His research and written contributions made this article possible. It was originally intended to be published on RiskBasedSecurity.com in early 2020 but was passed over so I am publishing it here.]


In 2019, we saw the steadily-growing social and policy conflicts between the United States and China reach a boiling point. China has been a major talking-point of President Trump’s platform since early in his campaign. However, it wasn’t until last year that we saw active policies enforcing a so-called “war on tech” between the U.S. and major Chinese companies like Huawei and ZTE, and those policies being “sidestepped”. We wanted to examine this from a data perspective, looking at the vulnerabilities in similar companies from both sides.

To set the stage, it is useful to briefly revisit the U.S. vs CN timeline.

The Trade War

Since taking office in January 2017, President Trump has had a specific interest in China, stating early-on that the “U.S. will be on a level playing field”. This led to several rounds of tariffs being imposed against China starting in March 2018, and retaliatory tariffs being imposed against the U.S. Early in 2019, there was conjecture that President Trump may use an executive order to limit some U.S. companies such as wireless carriers from purchasing Chinese electronic devices. That executive order was signed on May 15, 2019, citing the National Emergencies Act (50 U.S.C. 1601 et seq.) that would limit or ban purchases of “technology or services designed, developed, manufactured, or supplied, by persons owned by, controlled by, or subject to the jurisdiction or direction of a foreign adversary”.

While the executive order did not list any country or company, it was widely accepted that it was a move against Huawei in particular. The order contained interesting language, saying that the banned technology or services “poses an undue risk of sabotage” and is “an unacceptable risk” to the United States, among other wording. Technology meeting those criteria would be determined by the Secretary of Commerce, in consultation with nine other bodies “and as appropriate, the heads of other executive departments and agencies”.

On May 20, 2019, the BIS modified the final rule and granted a Temporary General License (TGL) until August 19, 2019 for transactions regarding, among other things, “Continued Operation of Existing Networks and Equipment” and “Cybersecurity Research and Vulnerability Disclosure.” On August 19, 2019, the BIS extended the TGL by 90 days, or until November 19, 2019. Outside the TGL, any request for a license to sell or transfer commodities, software or technology to Huawei is reviewed “under a policy of presumption of denial.” In other words, the BIS provides virtually no avenue for a continued commercial relationship with Huawei after November 19, 2019.

Months later, when asked if China would retaliate, Chinese foreign ministry spokesman Geng Shuang told reporters “stay tuned.” Two weeks after that, China announced tariffs on $75 billion of U.S. products. This was followed in December with China announcing a ban on foreign technology in “all government offices and public institutions” within three years. The ban also prevented companies such as Google, Dropbox, and Facebook from being used within China. With this, the United States and China were in a new type of technology war based on the premise that the adversarial nation was producing equipment that “poses an undue risk of catastrophic effects”.

The Fear of Backdoors

Computer equipment that poses a risk in the context above, typically brings to mind computer vulnerabilities. Issues that, with the right knowledge, would allow one country to use software vulnerabilities to compromise assets in the adversary nation’s government, business, or infrastructure. Another common scenario brought up by security professionals and intelligence officials is that of a backdoor; computer code planted by a party that allows them, and only them, covert remote access to the device. Some members of the U.S. intelligence community would prefer these Chinese products not be used in the technological infrastructure saying it “would undercut the ability of the U.S. to defend itself.”

This fear, specifically of Huawei routers from China, has been front-and-center since 2011, and a growing concern even before that. In the past, the concerns largely stemmed from each nation compromising the other’s computer networks in government and business. More recently, with the race to implement a 5G network, security issues around that technology have been heavily scrutinized. This war of technology has reminded us of 2010, when Huawei published an open letter to the U.S. government attempting to allay fears and shift public perception after a decade of suspicion. The company went so far as to request a “thorough investigation” to prove that they are “a normal commercial institution and nothing more.” This prompted eight U.S. senators to urge the White House to examine Huawei contracts and the House Intelligence Committee to investigate and publish a report on both Huawei and ZTE.

Ultimately, that report was inconclusive and stated the following – “despite hours of interviews, extensive and repeated document requests, a review of open-source information, and an open hearing with witnesses from both companies, the Committee remains unsatisfied with the level of cooperation and candor provided by each company.” Even over six years later, in 2019, Adam Segal, director of the Digital and Cyberspace Policy Program at the Council on Foreign Relations, officially stated that no one has found a backdoor in a Huawei product.

This is important to note, given the considerable scrutiny Huawei has received. In addition to their open letter in 2010, Huawei also disclosed their source code to a foreign government, something that no U.S. company has done. Despite the numerous information security companies attempting to find and potentially publish findings of an actual backdoor (including the NSA and specifically created testing centers in the UK), none have been confirmed. Given that the U.S. National Security Agency (NSA) has a significant budget and a vested interest in determining if a company like Huawei is shipping backdoored systems, and has not disclosed one, is compelling.

Ignoring Backdoors and Looking at the Data: Is a Ban Warranted?

Given that history and perspective on the growing tech war between the U.S. and China, we at Risk Based Security wanted to look at some concrete numbers around the vulnerabilities in the companies at the center of the issue.

While much of the focus on this topic has been on fear and the threat of backdoors planted by a vendor at the behest of their government, that is not necessarily where we want to direct attention. Using a backdoor, even if it is well-hidden, would likely bring unwanted attention by giving more positive attribution to those who compromised the machine. Nation-state level hackers would have their own ways into a wide variety of vendors and devices purely based on ‘natural’ vulnerabilities in the code. They simply do not need the access, and risk, a backdoor provides. Why provide hints to the enemy that you’ve “cracked the code” when you could hide behind an existing vulnerability?

Setting aside the possibility of backdoors, the question we’re interested in is this: does one of the government-used devices pose more of a risk due to its vulnerabilities? Despite this, we have found that the “war on tech” cannot be simplified into the classic “how many vulnerabilities are there in…” question, else unspoken bias drastically affects the perceived meaning of the numbers. While there is no way to do a perfect one-to-one comparison of U.S. versus Chinese vendors, there may be some that we can begin to compare, with disclaimers.

Phones: BlackBerry vs. Huawei / ZTE

For the general public, and based on much of the mainstream media reporting, Huawei are predominantly associated with their mobile phones. As more of our lives move to mobile, it is no surprise that those in power are concerned about the security of their phones and tablets. For U.S. and Chinese governments, it is widely viewed that BlackBerry and Huawei / ZTE phones, respectively, are dominant. For BlackBerry, they announced a five year deal for their latest handheld and their AtHoc software with the federal government back in July 2016, specifically the Department of Defense (DoD) Joint Emergency Mass Notification Systems (JEMNS). According to the press release, the DoD chose Blackberry because of the “secure end-to-end mobility offering .. that [shows the] secure platform is designed to meet their priorities”.

Despite the contract, BlackBerry is not the most widely used phone in the U.S. government. The U.S. Senate officially “ditched” BlackBerry in 2016, but allows them to continue to use specific devices per an official memo. In fact, BlackBerry themselves have stopped making their own handheld devices and have shifted to business software and other solutions like AtHoc, apparently used by 70% of federal employees including DoD, DHS, VA, DoE, DoA, PFPA, FEMA, IRS, and the TSA. For a majority of government employees, the most commonly used phones are now Apple and Samsung products.

With regards to China’s government, specific details about mobile phone adoption is not readily available. By simply looking at Huawei’s market share in China, one might safely assume that their devices are favored by some in the Chinese government. While it has long been rumored that Huawei has a very direct and complicated relationship with their government, which is supported both by Vietnamese academic and U.S. government research, Huawei says their relationship with the government is “no different” than any other company in China.

The U.S. government officially uses a mix of BlackBerry, Apple, and Samsung (Android), meaning that there are three major vendors and three major operating systems. For the Chinese government, apparently there is no officially sanctioned device, but it is very likely Huawei (formerly Android, but moving to Harmony OS / Hóngméng in 2020) and ZTE (Android) phones are heavily used. Looking at the last three calendar years, here is a comparison between the vendors to see how many vulnerabilities have been posted:

With these numbers it may seem like BlackBerry represents more risk. However, if BlackBerry shares the same vulnerabilities as any other Android device, and they disclose vulnerabilities in applications they ship, that number can be higher. The same can be said for any other Android phone that ships with packaged vulnerable apps and components as well, so the 1,338 Android vulnerabilities are not a full representation for other devices (e.g. Samsung, Huawei, ZTE). We then have to remind readers that comparing open source software such as Android to closed source such as BlackBerry OS and Apple can introduce bias in disclosure numbers. Another aspect to consider is that the amount of devices being used may influence how many people are actually performing security research on them.

Ultimately, this means neither the U.S. or China can justify banning devices based on phone vulnerability history alone. Trying to state one vendor is more “vulnerable” than the other using currently available vulnerability data alone requires so many disclaimers that the end result loses its potency.

Routers & TelCom: Huawei vs. Cisco et al

The second major aspect of concerns over technology from one country being pervasive in another is that of access. Everyone from the carriers to end users expects the equipment to function seamlessly, giving us access to the internet and mobile service. That service is built on a complex infrastructure of telecommunications (telecoms) hardware and software produced by companies such as Huawei, Cisco, Fujitsu, Nokia, and Ericsson. The telecom hardware includes routers, base transceiver stations, fiber optical networks, satellites, and a lot more. As of 2017, Chinese companies produced the most telecom equipment in the world, about 14% more than the United States.

Looking at these vendors for the last four calendar years, we get another lesson in how there is significant bias introduced into vulnerability statistics due to disclosures. Cisco had 2,227 vulnerabilities in that time. Compared to Huawei with only 813, one might conclude that Cisco’s software is inherently riskier. But compare Cisco with the three other companies. Fujitsu enjoys 79% of the market share by revenue, yet only had 24 vulnerabilities in that time frame. Going off that logic, can we conclude that Fujitsu is the most secure?

Consider that of Fujitu’s 24 vulnerabilities, only three are in their products and one of them a keyboard. The other 21 vulnerabilities are in third-party software or hardware (e.g. Intel processors). Cisco on the other hand has an incredible number of vulnerabilities reported, but they rarely publish that they are affected by vulnerabilities in OpenSSL and Intel for example, despite using those technologies in some of their devices.

Both Cisco and Fujitsui maintain contact pages for reporting security vulnerabilities, have a formal PSIRT team to respond to vulnerability reports, and both publish security advisories. Despite this, they have public disclosure histories that are about as opposite as you can find in many ways. We know for a fact both companies use hundreds of third-party libraries in their code, yet neither publish when third-party vulnerabilities affect their software. Based on our extensive history of tracking vulnerabilities, we are quite certain that Fujitsu products have, or have had, more vulnerabilities than they have officially disclosed. Any notion that Fujitsu (24) is a one-off situation can be dismissed when looking at Nokia (11) and Ericsson (8) for the same periods. That suggests Cisco and Huawei are outliers.

We can apply this same scrutiny to Huawei, with only 813 vulnerabilities despite their large market share, and their considerable transparency when it comes to third-party vulnerabilities. In the world of vulnerability research, access to software and equipment is essential, of course. Some may argue that Huawei equipment isn’t readily available to many researchers, and that might be true for U.S.-based researchers. But the last decade has shown an incredible number of extremely talented security researchers in China, who would presumably have more access. If one were to argue that China is looking to restrict vulnerability disclosure, that certainly will be something to consider moving forward. However, that plan is still preliminary and has not been implemented.

Conclusion: Overkill

You need comprehensive, detailed, and actionable data in order to make informed decisions. Following this mantra, we are comfortable in assessing that with the currently available vulnerability data, a hard stance condemning either side is not possible. As much as we would like it to be, the comparison of vulnerabilities within vendors cannot be a panacea.

That being said, does this mean that both the U.S. and Chinese governments are banning each other’s products solely for political posturing, or is it actually an informed decision? As we can see, it may be easy to arrive at a conclusion when looking at the data. But as informed citizens we all need to be aware of the disclaimers and hidden perspectives that the data may not overtly reveal. The answer is not so simple as “well, this has more vulnerabilities than that”.

Without concrete evidence of backdoors in Huawei products, the concern is definitely valid, but a total ban is overkill and may have far-reaching unintended consequences. As the “war on tech” has raged on, both the U.S. and China have suffered casualties.

Search Speak for Automaton

Alternate titles for this blog could be “Doodle Transition for Machina” perhaps! For at least a decade I have thought about just such an application and today I have Google Translate for Android. Load, aim, and it will process the text and translate on screen for you. Given the state of technology you would think it would be amazing by now, and it sometimes is.

The success largely depends on the language and that can also be seen in using translate.google.com, where some languages will translate fairly cleanly and others are very rough. One language I have to translate frequently is Chinese (simplified) and it is problematic for many things including company names and technical terms. With that in mind, I would expect it to translate with the same issues via the Google Translate app, and more specifically, do so consistently.

Since I am writing this, you know what’s coming…

This is the result of holding the phone up to a mail label from Japan. That’s all! Just moving the phone ever so slightly by tilting it or moving it half an inch closer / farther will make it change the translation. I think it finally got it a bit correct on that last one since the envelope didn’t contain anything living.

Hopefully the translation technology from Google will advance more quickly on Asian languages. Until then, I am just glad I didn’t get any “Sunrise Holy Poop” in that envelope.

It’s 2016, why is rotating a video such a pain?

How many times have you quickly shot a video on your phone and not rotated it for landscape? It happens too often and we see these videos all over social media. I sometimes forget to do it as well, or portrait is more in line with what I am shooting. So, I want to quickly rotate a video 90 degrees sometimes. Should be easy, right?

I’ve asked friends and social media before, but I asked again last night and got a lot of great input. My criteria were very simple, but I did not specify platform; I want to load an MP4 video, rotate it 90 degrees, and save it. I didn’t qualify it, but my expectations are that it would not lose quality, it would keep the original MP4 format, and that the process was “one-click” (or close). While I have plenty of history using Linux, going back to CLI graphics tools to do this is not ideal for me, but I considered those options.

  • @cl suggested Windows Movie Maker – It will rotate trivially, but saves your MP4 as WMV and the quality drops noticeably.
  • @TCMBC suggested mencoder – A command line utility, part of MPlayer. So it is not trivial (download, configure, compile, figure out CLI syntax), but it does rotate. Yet, the quality drops noticeably.
  • @viss suggested ffmpeg – A command line utility and graphics library, not so trivial. It did rotate, but the quality drops noticeably.
  • @viss suggested The ‘Rotate My Video‘ web site – It is a bit slow for file upload and conversion, but very easy to use. It played the video correctly in my browser, but when I saved the video the final copy was not rotated.
  • @DeviantOllam suggested (in DM) the Rotate Video FX app for Android – I thought the UX wasn’t intuitive for starters. It did rotate the video for immediate playback, but no apparently way to save the new video back to the device. Sharing it brings up the usual Android options, but uploading the video to google drive and the video was not rotated.
  • @elkentaro suggested Apple’s QuickTime Player – Even with his reference which is outdated, there is no apparent rotation function. Even the ability to save a file is now ‘Pro’ only.
  • MegaManSec suggested ImageMagick ‘convert’ utility – this didn’t work and gave me a nice reminder of the old ‘terminal flash attacks’ from the early 90s.
  • @DeviantOllum suggested Virtual Dub but warned me that some versions handle MP4 and some don’t. Thus, I didn’t try it.
  • @Grifter801 suggested VLC but qualified it “just for viewing”.
  • @mehebner suggested Open Shot Video Player but said it is Linux only, which isn’t convenient.
  • @cl suggested iMovie but it is Mac OS X only, which isn’t convenient.
  • @cl suggested Facebook but he isn’t sure you can save after. I am fairly sure you lose quality though.

The final recommendation, and the one that worked the best for me, is Handbrake suggested by @bmirvine. The upside is I had it installed (but an old version) and am familiar with it to a degree. The best part about conversion is that the video does not lose any quality. The downside is trying to figure out the ‘Extra Option’ argument to rotate is a raging mess, as seen on this thread. I found that using “, –rotate=4” as the extra option worked for version 0.10.5.0 64-bit (latest as of this blog). The only other annoyance is that Windows won’t show a thumbnail of the newly saved video for some reason. [Update: with a newer version of the K-Lite codec pack, the thumbnails render fine.]

There are my quick testing results. I hope it helps. I’d like to give a big round of thanks to all who contributed ideas late night. Reminds me that Twitter has some value and isn’t a cesspool of insipid political tripe. =)

Disclosure: Mr Number for Android Screenlock Bypass Concern

mrnumber

Mr. Number is an android app that allows you to do a variety of blocking for incoming communication. I’ve been using it for several months now and am quite happy. Crowd-sourced spam detection lets you know a new number is spam usually. When a call comes in that is suspected spam, a pop-up appears with the option to close it, block the call, etc.

mrnumber-01

If your screen is locked, it still pops up over the lock. Sometimes, but not always, if you block the number and tap ‘done’, it will drop you past the screenlock to the android desktop.

mrnumber-02

I haven’t been able to figure out what causes it to happen sometimes and not the other. I asked someone more familiar with Android and he couldn’t reproduce it reliably, but he did confirm the issue. The attack scenario is that if you spoof a call to a device using a known bad number, you could conceivably bypass the screen lock. Not very practical, especially since it isn’t reliable.

[Thanks to Zach @OSVDB for pointing out I failed by not including the affected version: 1.3.1]

Android & Granular Permissions

For Android-based phone owners, you are no doubt passingly familiar with the permission system that governs applications and what they can do. Every time you install an application, the device will ask you if you accept a list of permissions that it says are required for it to run. If you want the app, you must accept the permissions no matter what they are.

In theory, users can simply decline an app that requires excessive permissions and find an alternative. After all, there are over 1 million apps available right? Many won’t even read the permissions, while others may casually dismiss them because they are clearly stated, and any app in the Google Play store has to be legitimate!

The problem is that even the most simple and legitimate apps may request a variety of permissions that are not needed to make the program run:

Screenshot_2013-08-22-19-09-55   Screenshot_2013-08-23-19-12-04

A classic example of an application requesting permissions that aren’t required can be seen in the T-Mobile MyAccount app. The app is designed to give a user information about their T-Mobile cellular account, nothing else. This should take nothing more than permission to send and receive network data from their servers. Instead, the app has traditionally wanted extra permissions that are excessive. Worse, the latest version wants more, including “System tools” that give the app even more control over the phone. As T-Mobile is my provider and I don’t want to call them to find out account information, I have to accept their overly broad permissions. There is no alternative application in this case.

The second example is Avast Mobile Security & Antivirus that expects keys to the kingdome. There is a bit of irony that a security app wants enough permissions to completely own your phone, the same threat it claims to protect you from.

The Alternative

The obvious solution to this problem is setting it up so permissions are granular. This would allow a user to deny a specific permission while allowing others. If denying a specific permission causes the application to stop functioning, the user could enable it again if desired.

How hard is it to implement this for Google and Android? Trivial. This is readily apparent in that phones that have been jailbroken already allow it. Android users have requested this feature from Google via Ticket 3778. If you are an Android user and want to see this implemented, load the ticket and ‘star it’ (click the star on the upper left) to indicate you want it. If Google opts not to implement that one, there is a similar feature request (Ticket 6266) that would give a set of optional permissions an app wants, but are not required to function.

Until we get granular permissions, the concept of security in the context of applications will be a lost cause.

So far, yet so short…

two days into my smart phone experience, i am simultaneously amazed and disgusted by the state of technology surrounding these devices and ‘cloud’ applications.

back in the day, i had a ‘hacker’ mindset. i found flaws in systems that let me circumvent security or gain privileges not intended for users (or remote people not intended to have any access). over the years, that mindset shifted away from ‘hacking’ (penetration testing as a day job) and moved more toward usability (QA). these days, the idea of hacking and pen testing is boring and i avoid it as best i can. however, i am still a consumer and end user, so when a product doesn’t work, it bugs the hell out of me. more so if i believe any standard QA process should have caught it. my new phone is a world of new opportunity to find shortcomings in applications.

the other thing that bothers me about this process, is that when i find an annoyance and confirm it with a friend, i invariably get “that annoys me too!” so i am not the only one finding these bugs and shortcomings. is it complacency? do users no longer try to demand better from vendors? do they no longer report bugs and ask for simple features?

a great example of this is the Android Market (app store), the place to get applications for your Android based phone. i have a Samsung Vibrant through T-mobile, which uses Android apps, so this is now my go-to place to find neat utilities for the phone. go to that site, and search for applications that let you do $whatever. notice that? the distinct lack of a SEARCH MECHANISM? seriously, what brain dead dickholes run this operation, that didn’t think to put some kind of rudimentary search or at least embed a Google search link with “site:android.com”? unbelievable.

it’s ok, you can search the site via the smart phone! unfortunately, when you do it via your phone, you are given results straight from a 1995 search engine. the pattern matching is horrible. search for something with a space and results are hit or miss (e.g., “my app” will frequently not find “myapp”). further, applications that appear on the site you find via browsing, get no matches when you search for the exact name on the phone. there are some 100,000 applications out there. when you search for a common term, it isn’t surprising to receive 1000 results. but, instead of giving me primitive filtering (e.g., list only free apps, list only apps with 4+ star ratings), i get to scroll through all 1000 applications that do not appear to be listed in any discernible order.

my phone lets me connect via Wi-Fi in favor of 3G if i am in range. but, if i need to enter a password for the hotspot, i can’t enter the password. i am relegated to dealing with behavior of devices from 2000 that force you to enter the hex key.

the phone is advertised as being able to multi-task. i can run multiple applications at once! of course, very few let me cleanly exit the application. instead, they just keep running in the background, slowly helping drain the battery faster. everyone downloads a third-party application to help with this, a ‘Task Killer’ app. while this app is very helpful, it also makes me scream as i see countless apps start up that were never invoked by me. why does Amazon MP3 need to keep being invoked when i never did it, and i am not using any program that plays MP3s?

the built in ‘memo’ program is weak. so i got ‘Evernote’, a “cloud” based application that syncs my notes between phone and the web site. in theory, this is great. i sit at my computer and create a To-do list on the web site, and when i grab my phone and go, it syncs up the list from the web site. perfect! oh wait, the second list i created, i cannot edit. i can add text to it, but i can’t delete anything in it. i can’t use ‘DEL’, i can’t backspace over anything, i can’t even highlight and ‘cut’ the text via mouse/menu. seriously, what kind of drooling idiots write this application and don’t notice this? i can do it on the first list i created, but the invisible formatting crap i notice reminds me of MS Word from 1998. un-fucking-believable. so i deleted that list, and will re-create it by hand-typing the list instead of pasting it from a web page, which apparently caused the problems.

seriously people, hire a small QA team. if you are cheap and refuse to use the product yourself, then crowd-source the QA work. you do this by giving any users who want to help the ability to quickly and easily report bugs / annoyances or give feedback on features they would like to see. if you identify a person that seems to be knowledgeable and files accurate bug reports, flag their account/id and prioritize their submissions. example: a while back, i started giving feedback on a new version of Trillian, a program i use every day all day. within a few days, the lead developer was replying to my mails quickly. i believe he recognized a user that was familiar with the QA process (i marginally am), reported problems that were not one-off issues and would try to repeat the issue or provide debug output as requested.

in short, companies and developers need to use some of their time to use their own products, test them thoroughly and consider what features users may want. whipping up new code and flashy gadgets only goes so far before you have a product that is more annoying than it is helpful.