Who’s Watching the Watchers (Vol. II): Norton Core Secure WiFi Router
Recently, the articles on hacking IoT devices and their poor security are whirling over the media. In conjunction with that, Trustwave has published its report. There, it is stated that the number of those enterprises that use IoT devices is growing, and, consequently, so does the likelihood of stumbling across security issues a device may have. Kaspersky Lab, in its turn, has released the report focused on a new APT — so-called Slingshot. Kaspersky Lab’s experts claim that a malefactor may infect routers and use them as launching pads for further attacks on the computers connected to a network.
- Device description
- Access to the file system
- Via UART
- Obtaining firmware
- Firmware analysis
- Norton Core Secure WiFi Router attack vectors
- Last hope: Bluetooth Low Energy
- Researching the protocol of the BLE service
- Disclosure timeline
In this view, a considerable part of companies (even antivirus software producers) started developing and promoting hardware security solutions for IoT devices. Some of them have been already reviewed by the Embedi researchers to provide potential consumers with the most relevant and up-to-date information about the security imperfections of the devices consumers might want to purchase. We have already gone through Bitdefender BOX with a fine-tooth comb. Since this field of cybersecurity is the latest trend for developers, we have decided to go on with our research and do hope a new “network guardian” would be more efficient in the way it performs its functions and secures both IoT devices and itself.
The article you read now is a precise description of a device of the kind — Norton Core Secure WiFi Router by Symantec Norton. We will review its weak points and security flaws. Still, there is not much honor in being a mere armchair critic, so we will also speak about the success of Symantec in the domain of IoT security and strong aspects of the device they have developed and launched to the market.
The device in question is a high-performance secured dual-band WiFi router (see Fig. 1) equipped with a dual-core CPU and extended Flash memory (see Table 1). Compared to common WiFi routers, Norton Core Secure WiFi Router is allegedly capable of broadcasting Internet connection at high speed. The main competitive feature of Norton Core Secure WiFi Router is that it also can secure the IoT devices connected to a network with the help of itself.
Fig. 1. Norton Core Secure WiFi Router
Sure thing, the list of advantageous features the device is rich with is not limited by the broadcasting speed. It also includes a wide range of other functions the producer offers to its customers (some require subscription though):
- a built-in firewall;
- protection against viruses data miners, malicious software and other network threats;
- protection for identification forms and transactions;
- integrated parental control (time restrictions, content filtering, disabling access to the Internet for particular devices in a network);
- network-level security (DPI, IDS, IPS, Secure DNS, encryption of user connections);
- remote configuring of the device (with a smartphone application);
- security score;
- automatic detection of connected devices.
It is also claimed users do not need to use additional antivirus software as long as their subscription is activated. According to the official information, the device is distributed and operates only in the US.
|CPU||Qualcomm IPQ8065 (1.7 GHz, 2 cores)|
|Flash||4 GiB (Samsung KLM4G1FEPD)|
|SDRAM||1 GiB (Samsung K4B4G1646E-BYK0 × 2)|
|WiFi chip||Qualcomm Atheros QCA9984|
|Bluetooth Low Energy||Cambridge Silicon Radio (CSR) 8811, Bluetooth 4.1|
|Ethernet chip||Qualcomm IPQ8065|
|USB ports||2 (USB 3.0)|
Table 1. Device specification
The initial setting of the device is performed via the corresponding smartphone application (iOS, Android) if the Internet access and Bluetooth are enabled (Bluetooth Low Energy is supported). In the process, the WAN interface is configured, the firmware is updated by the device (if needed). After that, the router is identified in the cloud and assigned to a particular user (the one authorized in the smartphone application). Subsequently, the setting procedures can be conducted remotely in the application as long as a user is connected to the Internet. The router, in its turn, will synchronize the changes in its configuration. Thus, the direct user-router interaction is minimal, since the device can be managed remotely.
There is a traffic analysis system implemented in the device. This system includes a whole variety of plugins, some of which send information for cloud check (e.g., Mobile Insight). As a result, if there is no Internet access on the router, it will be impossible to change the configuration of the device (even change a WiFi network password). Moreover, some security subsystems, the operation of which is critical for protection from malicious devices in a network, will be disabled.
If a malicious or forbidden website is accessed, the webpage is changed with an information page related to a type of threat the device has come across. For example, the information about a website with mature content being blocked, or about Internet access being restricted at the moment. This means that there is a WEB server operating in the router.
The router is equipped with the continuous firmware updating system — LiveUpdate. Firmware updates are checked for every time the device is started and at regular intervals during the device operation.
Access to the file system
To initiate a detailed system analysis, it is necessary to get access to the files stored in the internal memory of the device. There are several ways to do this. Let us start with the simple ones.
The first method we tested is connecting to the UART (see Fig. 2). In theory, we could obtain access to the file system (even though unprivileged).
Fig. 2. UART connection scheme
As anticipated, during the device loading, the information regarding U-Boot and Linux kernel loading status was displayed. According to the logs, it was crystal clear that 3 serial interfaces had been initialized: presumably, 2 regular ones and the high-speed BLE interface. One of them should grant full I/O access to the system via the UART:
... [ 0.000000] Kernel command line: console=ttyMSM0,115200n8 root=/dev/mmcblk0p10 rootwait ... [ 1.242535] msm_serial_hsl_probe: detected port #0 (ttyMSM0) [ 1.242734] 16340000.serial: ttyMSM0 at MMIO 0x16340000 (irq = 184, base_baud = 115200) is a MSM [ 1.242872] msm_hsl_console_setup: console setup on port #0 [ 1.934480] console [ttyMSM0] enabled [ 1.938436] msm_serial_hsl_probe: detected port #1 (ttyMSM1) [ 1.943913] 16540000.serial: ttyMSM1 at MMIO 0x16540000 (irq = 188, base_baud = 115200) is a MSM [ 1.952800] msm_serial_hsl_init: driver initialized [ 1.958433] 16640000.hs_uart: ttyHS0 at MMIO 0x16640000 (irq = 190, base_baud = 460800) is a MSM HS UART ...
After the system was initialized, we could not entered in because the shell output was disabled by
default and, consequently,
getty just could not make its work. Thus, it was not possible to get
access to the file system. However, we managed to see the router loading status.
The second way is to get the files stored in the internal memory by extracting them from the firmware of the device. As a rule, one can either download firmware at its developer’s official website or get it from a smartphone that has an installed application. Another option is to intercept it while the device is trying to get an update from the Internet.
After a failed attempt to find the firmware in the Symantec Norton resources, a smartphone, and the Norton Core Secure WiFi Router application, we decided to intercept the firmware during the firmware update. We knew there was the LiveUpdate system operating on the device, and the router should check updates during the initial settings.
NB: Another reason to prevent the router from updating its firmware by restricting its access to the Internet was that it limits our chances on taking hold of the device and getting full access to the system, which is indispensable for detecting vulnerabilities. So, at this stage of our research, we analyzed the router with only a limited set of its functions initialized. The out-of-scope functions, however, might contain vulnerabilities of their own.
In order to get the firmware during the updating process, we connected the device to the Internet via a proxy server. As a proxy server, we used a computer run on Linux. NAT was set with iptables, so that the device could get an IP address via DHCP from the proxy server:
$ iptables -t nat -A POSTROUTING -o internet0 -j MASQUERADE $ iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT $ iptables -A FORWARD -i net0 -o internet0 -j ACCEPT $ iptables -I INPUT -p udp --dport 67 -i net0 -j ACCEPT
The WireShark analysis of the traffic showed that the router used its DNSs:
The whole process of obtaining the firmware is not encrypted in any way. The algorithm is as follows:
- Learn the IP address of
liveupdate.symantecliveupdate.comvia the DNS above.
Make a GET request to the
minitri.flgfile that contains
0x20, which is a solid indication of an opportunity to get an update:
$ curl -H "Host: liveupdate.symantecliveupdate.com" -X GET "22.214.171.124//minitri.flg"
nortoncore_core.r1_symalllanguages_livetri.ziparchive that contains the following information about an update: name, version, creation timestamp, checksums, signature, etc.:
$ curl -H "Host: liveupdate.symantecliveupdate.com" -X GET "126.96.36.199//nortoncore_core.r1_symalllanguages_livetri.zip" --output nortoncore_core.r1_symalllanguages_livetri.zip
Based on the acquired data, download the firmware archive.
The firmware archive consists of 2 files:
The first one is firmware update script. It launches the
sysupgrade utility that splits the
firmware into multiple parts, checks their integrity with the help of in-built certificates and hash
functions; and updates the firmware in case the check is successful.
The second one is the very firmware comprised of several parts — FIT images: device tree files,
rootfs, GPT layout, loaders (SBL1, SBL2, SBL3, TrustZone, U-Boot),
Having unpacked and analyzed all the parts of the firmware (v207 at the time of the research), we concluded that the firmware was based on OpenWrt Chaos Calmer 15.05.1 with the Linux 3.14.77 kernel. The software provided by the vendor was written on C++ with the use of numerous open-source libraries and frameworks:
- PF_RING ensures high-speed packet processing;
- lwip is responsible for quick and efficiently operating with the TCP/IP stack;
- libnet framework is utilized for creating and injecting packets;
- NSS-QCA-ECM — Qualcomm Network Subsystem (NSS), Enhanced Connection Manager(ECM) enables low-level operations with a network;
- Bluetopia is supposedly used as Bluetooth stack.
The device has an integrated crypto chip —
Microchip ATECC508A that allows generating
random numbers, providing cycle counting results for Secure Rollback Prevention, generating keys and
hashes, and storing sensitive data, etc. The (
rootfs_data) partition is used to store system
configuration and encrypted with LUKS (the key is stored in the crypto chip).
There is a system of collecting and sending metrics and logs to a network. As metrics, the following information is used:
- system time and timezone;
- firmware version;
- connected clients;
- status of fans and other devices;
- reason for factory reset;
There is a wide variety of systems responsible for filtering and analyzing packets in the firmware, including the Mobile Insight mobile system by Symantec mentioned above. Separate plugins gather metrics to assist developers. Here is the list of operating plugins:
The device has a launched lighttpd/1.4.45 and uses PHP 5.6.17. Some pages are utilized for web page
spoofing, for example, when a malicious domain is addressed to. Others are service pages that work
10 minutes after the device is started. The pages of the kind should be addressed to only by the
norton.core domain name.
Norton Core Secure WiFi Router attack vectors
So, we had the firmware and proceeded with analyzing it and detecting its potential weaknesses, vulnerabilities, and attack vectors (see Fig. 3). The ultimate goal here was to find out how Norton Core Secure WiFi Router providing security for IoT devices was secure itself.
Fig. 3. Norton Core Secure WiFi Router attack vectors
One of the most obvious attack vectors one can think of is spoofing the device firmware during updating. Alas! “Sounds good, doesn’t work.” The thing is, the update servers may be checked. So, even if we managed to spoof the official servers, we would still be unable to upload a modified firmware (more details below). By the way, the developers put only one version of their firmware to the website. Therefore, it is just impossible to analyze other versions but the up-to-date one.
The device is equipped with 2 USB 3.0 ports used for connecting printer to the router. It seems there should be a way to affect the router operation by connecting malicious devices to it. As if! The behavior of the device in case of connecting devices is not configured in the (
udev) settings until the corresponding rules are downloaded from the configuration server. Considering we stopped the device updating, we could not completely configure it either. In addition, only printers may be used as USB devices. They are managed by default Linux software.
As it has been already noted in the “Access to the file system” section, we had information about Das U-Boot loading. There is a peculiar line there. This line indicates an attempt of starting from a USB device (though failed):
(Re)start USB... USB0: Register 2000240 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found USB1: Register 2000240 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found ** Invalid boot device **
While trying to find the way to make a successful attempt, we learned that the format and name of the U-Boot boot file. Trying to boot, we came across an error caused by an incorrect certificate chain. Having delved deeper into the format of the firmware, we saw that Secure Boot Qualcomm was used. As a result, without a private key, we could not load a third-party firmware. Moreover,
rootfsis a subject of specific checks performed by
initrd, which also makes the usability of this attack vector more complicated.
Analysis of open ports and network services started on the device:
- samba (an older version of the firmware),
The only vulnerable thing in these versions is
dnsmasq. However, it is not that exploitable, since to exploit it we would need IPv6, which is disabled on the kernel level:
$ cat /etc/sysctl.conf ... # disable ipv6 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1
Besides, the developers patch known vulnerabilities with every firmware update at the software recompilation stage.
The next step is to analyze setting and the web server directory — the server is launched as proxy to return a parked page. There is a noteworthy thing, though, — service pages. When referred to one of them,
info.php, for 10 minutes after device is started, an unauthorized user can read general information about the router (firmware version, router serial number, assembly date, device temperature, MAC addresses, etc.), restart the device, reset it to factory settings, update firmware (see Fig. 4).
As a result, a potential attacker can launch a DoS attack by repeatedly restarting the device. There is also a chance to reconfigure the router: reset the device to the factory settings, restart it, and configure it from scratch. We should emphasize that a user does not have to authorized to do this!
Fig. 4. WEB interface of the service webpage
As for updates, it is not that simple to upload a modified firmware. The reason is simple — the good old certificate verification. This time it is performed not at the bootloader level, but rather at the software one responsible for updating. An attempt to start the PHP shell was also unsuccessful: after an update or due to some other reason the device restarted immediately, and we could not get access to the loaded shell. The latter is removed since it is stored in a temporary directory.
It is also possible to download logs that contain the information about the state of the kernel, services, started processes, connections, etc. Those logs, however, are encrypted with a public key. We have not managed to find the private one.
Getting to reverse engineering and searching for errors in the software responsible for analyzing and filtering packets and websites, we found out that low-level packet processing was performed with the help of the CPU (IPQ8064 adopted for network operations) and kernel modules. The router uses open-source software developed either by Qualcomm itself or by other companies. The software utilizes the mechanisms popular among embedded software developers.
As long as a higher packet processing level is considered, there are a lot of Symantec plugins performing this function. These plugins are also implemented in other solutions, including Mobile Insight and antivirus software. A certain part of the analysis is conducted in the cloud. Even if we manage to find errors, it will still be close to impossible to get the exploitation process going.
To ensure the effectiveness of the analysis of executable files, it is necessary to obtain access to the system internals. In this view, we decided to try rewriting the memory storing the firmware. Unfortunately, our hopes turned to dust and ashes again, because memory contents storing the device configuration were encrypted. An attempt to modify other parts of the firmware would simply result in a certificate validation error, and the device would not start at all.
The described attack vectors did not provide us with access inside the router. Neither did they enable us to execute arbitrary code. So, we went on with learning the ropes of Norton Core Router.
Last hope: Bluetooth Low Energy
At the end of the day, there is only the system of application-router interaction via Bluetooth Low Energy (BLE) left. The executable file responsible for passing/reception of data via Bluetooth is started if a cable is connected to the WAN port of the device (the Internet access is not required).
When the router is started at the first time or reset to factory settings, it is possible to configure the Internet setting in the smartphone application, so that the device connects to the cloud and gets further settings. By default, the router tries to get an IP via DHCP automatically or attempts getting a static IP, subnet mask, gateway IP address, and optionally IP addresses of DNS servers manually.
The results of the static analysis indicate that proprietary Bluetopia is used as Bluetooth system. At first glance, Bluetopia has no errors.
As for the device setting functionality, there are several points of interest here. First of all,
besides DHCP and connection with a static IP address, there is a possibility to establish PPPoE
connection. This functionality has been widely discussed on the forum and is highly demanded by
users. The official representatives claimed it would be implemented in future. However, it turned
out, that the functionality had been in the device right at the market launch. Moreover, it was
perfectly operable. Second, it was revealed that console commands related to settings were executed
system function, which was odd since other segments of the system written on C++ used a
parser of commands with their safe execution. Third, the program for communicating via the BLE was
launched on behalf of the root user. Considering these, we started analyzing this “future”
functionality in greater details.
We found out that when PPPoE connection was established, a username and password were set. A
username and password, in their turn, are easier to exploit than IP, since the latter underwent the
stage of preliminary parsing (
inet_aton). A username and password are set by executing the
$ uci set network.wan.%s='%s'
%s — is
password, and the second one — a passed value. The line is
checked before its execution: one of the
;^| is searched for as well as the occurrence of such
...; if those symbols and lines are not found, the check is successful (see
Fig. 5. Filtering commands for execution
Not all symbols that should be restricted are listed in this set because a command can be executed by sending the following line as username:
'& cat /etc/passwd > /dev/kmsg'
As output, the router executes the command below:
$ uci set network.wan.username=''& cat /etc/passwd > /dev/kmsg''
This way, the setting command is sent to the background, while we executed the one of ours:
$ cat /etc/passwd > /dev/kmsg
With the help of this command, we entered the contents of the
/etc/passwd file into the debugging
output of the kernel. If we connected via UART, we would be able to read output. A single quotation
mark in the end was used in order to pair the closing one. If we have missed it, the command would
not have been executed at all: it would wait for the syntax group to be closed.
This way, we found the vulnerability in the BLE that allowed launching command injection attacks. By exploiting this vulnerability, a malefactor can start an arbitrary command on the device.
Researching the protocol of the BLE service
To send commands to the device via the BLE, we had to analyze the communication protocol.
WireShark came in handy for this purpose as well. We collected the traffic in the following way: we enabled Bluetooth debugging on the smartphone and attempted to configure the router in the application via the BLE; as a result, we obtained traffic dump.
To simplify the analysis, we reverse-engineered the application. There was no obfuscation, and we managed to decompile most of the code.
During the reverse engineering of the protocol, we identified the key GATT service and associated characteristics (see Table 2).
Table 2. GATT service identifiers and characteristics
All sent commands are written in the
ROVER_CHARACTERISTIC_USER_COMMAND characteristic, reading
from the device is conducted via the
We also identified the types of possible requests/responses listed in Table 3, types of passed data (see Table 4), and possible types of settings of the WAN interface (see Table 5).
|UNLOCK||0||Unblocking device with its serial number|
|DATA_RESP||3||Data received and installed|
|ACK||4||Request is successfully processed|
|NACK||5||Request is rejected|
|NONCE||6||One-time code (on the basis of serial number)|
|COMMIT||7||Finish data sending|
Table 3. Type of requests and responses
Table 4. Types of sent data
|STATIC||2||Static IP address|
Table 5. Types of WAN interface settings
The router uses the
ROVER_CHARACTERISTIC_STATUS_NOTIFICATION characteristic to show the status of
the router. Possible statuses are listed in Table 6.
|MASK_WAN_INTERFACE_CONNECTED||1||WAN cable connected|
|MASK_HAS_IP_ADDRESS||2||IP address obtained|
|MASK_CONNECTED_TO_CLOUD||4||Connected to cloud|
|MASK_PPPOE_AUTH_FAILURE||32||PPPoE authorization error|
Table 6. Bit masks of device statuses
The maximum allowed size of passed data is 18 byte. If a request exceeds the size, a message is split into parts. The form of a request/response depends on a type of passed/received data. We will not review the sending protocol in more details: it is quite simple.
Data transfer with the router is encrypted with the AES-based CBC cryptography. It uses a six-unit serial number as the key. The initialization vector is generated data received by the router at the beginning of the communication process.
The serial number can be found either on the box the device is delivered in, or on the engineering page available during 10 minutes after the start of the router. We chose the second option.
So, we have the following attack scenarios:
- restart the router either by exploiting one of the DoS vulnerabilities or by getting physical access to the device; it is also possible to wait till a user restarts the devices;
- obtain the serial number of the device from the engineering page
- get some random data from the router — initialization vector;
- generate HMAC on the basis of the obtained data and serial number; send it for checking;
- after HMAC is checked, send configuration data to set a password or username with a command we need to be executed put into it; this command should be encrypted with the very same serial number.
Thus, by using this hidden engineering page and device functionality, we can execute virtually any
command on behalf of the
To demonstrate the exploitation, we will use:
- OS GNU/Linux;
- Bluetooth dongle adapter (see Fig. 6);
- BlueZ utility (for testing Bluetooth connection);
- PoC Python3 script.
Fig. 6. Bluetooth dongle adapter
In order to use the script, we will need to set all dependencies in a advance:
$ pip install -r ./requirements.txt
With the help of
BlueZ utilities, we should ensure Bluetooth is enabled and functions properly.
- Restart the router to provide access to the engineering page.
Start the PoC on behalf of the root user (required for operating with Bluetooth) with the command on executing as an argument:
$ ./ble_norton_core.py "/etc/init.d/dropbear start"
After the script is successfully executed, we get access to the device via the SSH connection. We put
rootas a user and
$ ssh firstname.lastname@example.org
Now, with access to the “insides” of the started system, not only firmware files, we can analyze the system in dynamics, check its behavior and the way various operations are performed by the router, which makes it possible to research the device itself and debug the detected vulnerabilities.
The idea behind this report that as we hope will encourage researchers is pretty clear and simple: these “magic” contraptions like Norton Core, BitDefender Box, and F-Secure Sense that are meant to protect IoT devices and prevent the exploitation of their vulnerabilities, are not perfect from a security point of view either. The rich abundance and promiscuity of these devices negate any attempts to conduct a complex and throughout security analysis. Moreover, since there are secure channels used to transfer data between a vulnerable IoT device and a developer’s cloud, the gadgets of the kind are not capable of analyzing pass-through traffic.
The only reasonable option for the IoT world at the current stage of its development is to make devices immune than go on giving some palliative and placebo security pills. We have spent plenty of time and put all available resources on creating such a cutting-edge solution that can become the immunity gene (AntiExploit) securing your non-secured and guarding unguarded guardians.
- 12/27/17 — vulnerability found;
- 01/26/18 — vulnerability reported and PoC provided to Symantec;
- 02/23/18 — firmware update v229 without fixes released;
- 03/29/18 — firmware update v237 with vulnerability fixes released;
- 04/30/18 — vulnerability fixed, and CVE-2018-5234 assigned.
As our experience shows, vulnerabilities are a regular thing. The analysis revealed that the developers had spared neither time nor effort to make the router as secure as possible at the hardware, software, and even organizational levels. However, they still have made a few mistakes, for example:
- HTTPS protocol is not used while the firmware is being obtained, which makes it possible to analyze the internals of the device;
- there are hidden engineering features for debugging; they can be used by malefactors to bring their ill intentions into existence; for example, any network user can reset the device if the latter was restarted;
- serial number is used as an encryption key in the BLE communication protocol; obviously, a serial number is not hard to learn;
- if the device is not connected to the Internet, some of its features that are meant to counteract malicious traffic stop working, the settings installed in the mobile application are not loaded;
- Command injection (CWE-78) in the BLE service.
If the vulnerability described in this article is successfully exploited, any guest or a visitor who has physical access to Norton Core Secure Router (or even those in the Bluetooth range) can write a dataminer into the memory of the device and obtain all sensitive data or change the device settings, so that the traffic will be passed via a particular server. The same can be done by malevolent resellers.