1 May, 2018

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.


  1. Introduction
  2. Device description
  3. Behavior
  4. Access to the file system
    • Via UART
    • Obtaining firmware
  5. Firmware analysis
  6. Norton Core Secure WiFi Router attack vectors
  7. Last hope: Bluetooth Low Energy
    • Researching the protocol of the BLE service
  8. Exploitation
  9. Disclosure timeline
  10. Conclusion


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.

Device description

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

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.

Type Values
CPU Qualcomm IPQ8065 (1.7 GHz, 2 cores)
Flash 4 GiB (Samsung KLM4G1FEPD)
SDRAM 1 GiB (Samsung K4B4G1646E-BYK0 × 2)
WiFi1 Foxconn EWZ510-A1-SN-5G-025(AC)
WiFi1 protocols an+ac
WiFi2 Foxconn EWZ510-A1-SN-2G-025(XC)
WiFi2 protocols bgn
WiFi chip Qualcomm Atheros QCA9984
Bluetooth Low Energy Cambridge Silicon Radio (CSR) 8811, Bluetooth 4.1
Ethernet chip Qualcomm IPQ8065
LAN ports 3
WAN ports 1
USB ports 2 (USB 3.0)
Power 12V, 3A

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

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.

Obtaining firmware

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:

  1. Learn the IP address of liveupdate.symantecliveupdate.com via the DNS above.
  2. Make a GET request to the minitri.flg file that contains 0x20, which is a solid indication of an opportunity to get an update:

    $ curl -H "Host: liveupdate.symantecliveupdate.com" -X GET ""
  3. Get the nortoncore_core.r1_symalllanguages_livetri.zip archive that contains the following information about an update: name, version, creation timestamp, checksums, signature, etc.:

    $ curl -H "Host: liveupdate.symantecliveupdate.com" -X GET "" --output nortoncore_core.r1_symalllanguages_livetri.zip
  4. Based on the acquired data, download the firmware archive.

Firmware analysis

The firmware archive consists of 2 files:

  • install.sh
  • emmc-ipq806x-single.img

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, loader settings, rootfs, GPT layout, loaders (SBL1, SBL2, SBL3, TrustZone, U-Boot), initramfs, and other.

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;
  • etc.

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:

  • IDSPlugin,
  • UserAgentPlugin,
  • WBListPlugin,
  • ContentPlugin,
  • WhitelistPlugin,
  • MobileInsightPlugin,
  • TitaniumPlugin,
  • WebPulsePlugin,
  • NetworkSecurityPlugin.

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

Fig. 3. Norton Core Secure WiFi Router attack vectors

  1. 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.

  2. 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, rootfs is a subject of specific checks performed by initrd, which also makes the usability of this attack vector more complicated.

  3. Analysis of open ports and network services started on the device:

    • lighttpd,
    • samba (an older version of the firmware),
    • zebra,
    • quagga,
    • dnsmasq.

    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.

  4. 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

    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.

  5. 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.

  6. 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 by the 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 following command:

$ uci set network.wan.%s='%s'

where first %s — is username or 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 lines as && and ...; if those symbols and lines are not found, the check is successful (see Fig. 5).

Fig. 5. Filtering commands for execution

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).

Name Identifier Permissions
ROVER_SERVICE_UUID 1E9EF32B-2809-4326-921B-CBF535C9D761

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 ROVER_CHARACTERISTIC_COMMAND_RESPONSEcharacteristic.

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).

Name Code Description
UNLOCK 0 Unblocking device with its serial number
DATA_SET 1 Data sending
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

Name Code Description
DATA_USER_NAME 0 User name
DATA_PASSW 1 Password
DATA_PROTO 2 Protocol type
DATA_WAN_NETMASK 4 Network mask
DATA_DNS_LIST 6 DNS addresses
DATA_GWID 7 Gateway ID

Table 4. Types of sent data

Name Code Description
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.

Name Bit mask Description
MASK_HAS_IP_ADDRESS 2 IP address obtained
MASK_CONNECTED_TO_CLOUD 4 Connected to cloud
MASK_GATEWAY_READY 16 Gateway ready
MASK_PPPOE_AUTH_FAILURE 32 PPPoE authorization error
MASK_REBOOT_NEEDED 64 Restart required

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:

  1. 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;
  2. obtain the serial number of the device from the engineering page norton.core/info.php;
  3. get some random data from the router — initialization vector;
  4. generate HMAC on the basis of the obtained data and serial number; send it for checking;
  5. 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 root user.


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

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.

  1. Restart the router to provide access to the engineering page.
  2. 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 root as a user and admin as password:

    $ ssh root@norton.core

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.

Disclosure timeline

  • 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:

  1. HTTPS protocol is not used while the firmware is being obtained, which makes it possible to analyze the internals of the device;
  2. 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;
  3. serial number is used as an encryption key in the BLE communication protocol; obviously, a serial number is not hard to learn;
  4. 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;
  5. 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.