Heads of the Hydra. Malware for Network Devices

Network devices such as routers, access points and DSL modems are an integral part of today’s home and small office networks. Typically, these devices will have been provided by a user’s ISP or bought to extend a user’s existing infrastructure and are usually managed by people who do not have any special technical knowledge. Often poorly configured and vulnerable, such devices are an easy target for network-based attacks, allowing cybercriminals to quickly and easily gain control over a network. Surprisingly perhaps, these seemingly innocuous devices can also offer a perfect hiding place for malware.

Introduction

Main security issues

The weakest link in any IT security chain is in fact the user, and this holds true for network threats and devices also. It’s obvious that a highly trained and competent administrator can provide resilient protection for most networks, while someone without the necessary experience and training can easily expose network users to significant risk. Big companies that manage huge numbers of users typically have expensive professional networking equipment and hire qualified and experienced network specialists. However, small businesses with 10-15 workstations can hardly be expected to buy expensive hardware and employ a network professional. Moreover, it cannot be assumed that those with a router or modem at home will be in the least bit familiar with network management – it’s like expecting every single computer user to be an IT professional. Home users generally assume that everything will work just as it should, relying on a device’s default settings without referring to complex technical manuals. Therefore network providers and hardware vendors need to be aware of their responsibilities in maintaining network security on the devices they sell.

Small, user-friendly network devices that simply need to be plugged into the network are becoming more and more popular. But how secure are their default settings? Can we use them without modifying their default configurations and still feel secure? Alas, in most of cases, the answer is no. Let’s assume you don’t change the default password on your newly purchased router. This could pose a great risk because the default passwords are usually widely known, and even if not, they tend to be quite simple to guess or to crack. This is the greatest weakness of small network equipment, but not the only one. Sometimes the manufacturer enables remote administration by default or even creates a hidden administrative account for use by technical support! Additionally, most modern household routers are UPnP-enabled, which means that in some cases they allow applications to change router settings without any authentication. This is sufficient to pwn the devices of non-technical users and careless professionals.

Unfortunately, even the most attentive user cannot ensure that their equipment is 100% secure. This is down to the numerous vulnerabilities in device firmware, especially in their web interfaces which are particularly prone to authentication bypass, XSS and CSRF attacks. This problem is not limited to devices found in homes and small offices – there are known exploits targeting professional networking equipment produced by several large vendors. Moreover, both users and vendors do not seem to be fully aware of the security issues and do not pay them enough attention. Even for firmware bugs that are easily fixed, updates for network devices are at best slow to be released and at worst left unresolved, and users do not usually care or are unaware of how to install these device updates. If there are implementation errors, it’s impossible to eliminate them without making significant changes, so most of these defects persist for years.

Attacks: reasons and consequences

Summarizing the previous paragraph, there are specific issues concerning network devices:

• Weak default passwords / no password change enforcement
• Insecure default configuration
• Firmware vulnerabilities & service implementation errors
• Lack of user and vendor awareness / trivialization of the problems

All these issues make a router/modem an easy target for cybercriminals. But why would someone want to attack a network device? The reason is always the same – money. Permanent and transparent network monitoring, data theft, redirecting users to malicious websites – having access to the router makes all of the above possible. Also, such devices can provide the perfect hideaway for malware, which may transparently reinfect connected computers or build a huge botnet from infected devices.

So while the above is fresh in our minds, let’s recall the possible consequences of unauthorized router access:

• The capture of network traffic
• The ability to eavesdrop on VoIP conversations
• The theft of WEP/WPA keys
• The possibility to change a device’s configuration
  • change / reset passwords
  • expose internal networks to the WAN
  • the risk of open backdoors (port forwarding)
  • the changing of DNS settings (drive-by pharming)

Most of the above issues are associated with targeted attacks, but not many people know that they are often related to malware. At present, it seems that the most interesting thing for cybercriminals is the changing of DNS settings and the creation of DDoS capable botnets, but there are far more possibilities, like extracting valuable data from captured traffic, hiding PC malware inside a router’s RAM or spreading router ransomware. The sky is the limit, as they say.

Watch your DNS!

The process of URL to IP mapping is crucial to the security of users who browse the Internet. If these settings are nefariously modified, known and trusted URLs may be associated with rogue IP addresses and thus a user might be exposed to phishing, exploits or other malicious websites. This redirection is completely transparent from the user’s point of view: they just type the URL into the browser and wait to see the expected content. It only takes one malicious change – it’s not hard to imagine how devastating the damage caused by a rogue DNS server can be.

The process of changing URL -> IP associations is widely known as pharming. First to use this attack were Trojans altering the Windows hosts file. The second step in the evolution of this method was changing DNS addresses in the Windows registry. A more sophisticated piece of malware that used this attack vector appeared in 2007 in the shape of the Zlob/DNSChanger Trojan. Apart from modifying registry settings, this malware checks if the router is connected to an infected computer, and if so, tries to gain access by brute forcing the password and then altering its DNS servers.

How can a user protect themself from such attacks? Well, in this case the answer is simple:

• Security software inside current databases should prevent malware from infecting a PC and thus attacking the router;
• A strong, unique password to the router’s management interface should be used.

The situation gets more complicated when the attack is conducted without the use of malware installed on a user’s computer. Such a situation occurred at the beginning of 2011, when a targeted attack was conducted against an ISP company. Lots of customers’ modems were compromised by changing their DNS settings, probably via a hidden administrative account meant for remote technical support, implemented on each device. The attack probably included some kind of automation component which was deleted from the devices after the DNS changes were applied. In such cases a user is effectively powerless. The ISP should ensure the security of modems/routers before providing them to their customers, especially in terms of access passwords and remote access. Connections from a WAN should be prohibited by default and any IP addresses able to establish a remote connection should be strictly specified.

Exploiting vulnerabilities

CSRF and drive-by pharming

In short, Cross-Site Request Forgery (CSRF/XSRF) is a web-based attack in which sensitive actions are performed on behalf of a trusted user without their knowledge. This is possible because a request coming from the browser of an authenticated user is usually not verified by the website it concerns and is immediately applied. If lured into visiting malicious sites with such requests embedded into their code in the form of HTML or JavaScript, a user’s browser may start performing actions the user didn’t initiate or intend, for example, logging the user out of XYZ portal, sending posts to XYZ forum, changing preferences, etc. Drive-by pharming is simply the CSRF attack used against routers to change their DNS settings.

This technique was described in the proof-of-concept paper by researchers from the University of Indiana in 2006. The first in-the-wild drive-by pharming attack occurred one year later in Mexico and targeted the CSRF vulnerability of 2Wire routers. An email infected with an exploit was spammed to millions of users with the main goal of stealing online banking credentials. The exploit consisted of a request to the router’s web interface to change the IP association of the www.banamex.com URL to a malicious address. Once the user visited their online banking website, they were transparently redirected to a phishing site. This site was of course almost the same as the original one, except for an additional field: NetKey. Suffice it to say that NetKey is a randomly generated value used for authorizing online transactions in this bank.

Figure 1: CSRF request

Figure 2: Phishing site (Source: blog.hispasec.com)

Similar attacks continued to occur for months afterwards, but not every email was malicious – sometimes a CSRF attack followed right after a user clicked the malicious link and was redirected to a malicious website.

As this vulnerability is more an implementation issue, it is not possible for the user to eliminate it unless there is a firmware update available. From the vendor’s side, there are relatively few solutions available for fixing the problem. One of them is to use a unique token which is sent along with a request as a hidden form value.

UPnP: very friendly, very dangerous

The previously mentioned attack was only possible if there was no router password set or if the user was logged into the web interface when the attack occurred. Essentially, it means that people who have set strong and unique passwords on their devices are at less risk. But what if there is a method that allows the router’s settings to be changed without any authentication at all?

Universal Plug and Play is a set of protocols that simplifies cooperation between networked devices such as PCs, printers, phones, routers/modems and access points, etc. It specifies rules about how these devices automatically discover each other and establish communication. Once connected to the network, a device that is UPnP enabled does not require any user intervention to set up a working configuration. Great for the non-technical user, but as with pretty much everything designated ‘user-friendly’ – it is rarely good from the security point of view. Suffice it to say that UPnP does not offer any authentication method and thus it does not need any credentials to perform administrative actions such as changing a device’s crucial settings. Moreover, most contemporary routers/modems have UPnP enabled by default.

Let’s take a look at how UPnP works in detail:

• Every device joining the network gets an IP address, either from DHCP or by self-assignment (local-link address)
• A newly connected device uses Simple Service Discovery Protocol (SSDP) to announce the services it offers along with the URL through which these services are available
• The UPnP control point retrieves the device’s description from this URL (in XML format)
• Now the control point is able to submit valid requests for services offered by this device. These messages use Simple Object Access Protocol (SOAP), which mostly relies on XML format and RPC & HTTP protocols.

Specially crafted SOAP messages can be passed from a malicious website to the device via the XmlHTTPRequest API in JavaScript or the navigateToURL function in Flash. While the first can only be used from inside the network, providing that it is not combined with some remote-access exploit, the latter allows for remote execution when required.

As this is a serious implementation problem concerning UPnP and to a lesser extent, Flash format design, this is not easily rectifiable by either the user or the vendor. Of course, we can simply switch UPnP off – thereby solving the issue immediately – but that is a fairly primitive solution. Manually configuring every device in the network and every application that uses networking resources would be tiresome, if not impossible in many cases. The only way is to re-write the UPnP specification to include a strong authentication method. A temporary solution that users might consider is to disable Flash in their browsers, but this does not provide 100% assurance as there may be other ways to exploit the UPnP vulnerability without using Flash.

SNMP: yet another (hidden) feature

Simple Network Management Protocol is designed to provide centralized management of all devices in the network. Although not always implemented in household devices, its weaknesses are worth mentioning as it can be used as another vector of attack.

SNMP consist of three elements:

• The manager, which is an administrative computer;
• Software agents installed on other devices in the network;
• Communication between the manager and software agents, plus the retrieval or modification of settings on the remote device; the most important types of messages are GetRequest, SetRequest, Response and Trap.

All messages contain a so-called community string, which acts as a kind of password to ensure that the communication is trusted and to distinguish between read-write and read-only rights. But here is where the SNMP protection comes to an end. There is no encryption available, so even the community string is sent in plain text. Moreover, the default strings are widely-known and extremely weak – there is no string change enforcement either. However, the worst is yet to come: a lot of devices have SNMP enabled by default despite most users not even being aware of SNMP’s existence! It’s like a hidden feature which – in some cases – may act as a backdoor as well. These issues are enough to allow a successful attack on a router with SNMP enabled and a default or weak community string.

Once an attacker is able to use SNMP requests on the router, they will have plenty of possibilities to obtain information and play with the device’s settings. On some devices modifying crucial settings may not be possible via SNMP even if write access is enabled, but an SNMP injection attack can still be used successfully. This kind of attack injects malicious code into the HTML pages of a web interface and thus silently redirects users to phishing or infected websites or performs other actions like CSRF attacks.

Figure 3: SNMP – having community string set to default may result in code injection into the web interface of the router

As this is once again an implementation issue, it means that SNMP security is not in the hands of users. Although the recent version of the SNMP specification (SNMPv3) partially addresses these insecurities by adding encryption to the messages, its designers decided to change some conceptual elements and thus this version is not widely supported by the major hardware vendors. This is a very important and immediate problem, especially where business networks are involved, and vendors should be paying close attention to this as they are putting their customers at risk.

If you are thinking of buying new network equipment for your office and you need it to be SNMP-enabled, it is a good idea to look for something that supports SNMPv3. Generally speaking, in the context of a small home network SNMP is practically useless. Thus if your household router has SNMP enabled, the best thing to do is to disable it unless you really need to use it. In such a case, changing the default community string to a long and non-dictionary phrase is absolutely essential.

Binary malware

Hydra: an open source prototype of router malware

The first known router malware that operated automatically appeared in 2008 in the form of an open-source tool. It was managed by IRC and its main purpose was to access routers using brute force methods for the purposes of performing DDoS attacks. Getting access to the router was possible by either using a built-in list of default passwords or with the use of a D-Link authentication bypass exploit.

Figure 4: Part of Readme file, distributed with Hydra sources

Before compiling the code, the malicious user had to edit one of the source files in order to provide the URL address of the C&C IRC server as well as the link to download the malicious binary.

The tool was published on the author’s blog in April 2011, but had been doing the rounds on underground forums since 2008. All further MIPS malware found in the wild is more or less based on Hydra.

Psyb0t: the first in-the-wild malware targeting the MIPS platform

Psyb0t is the first in-the-wild binary malware infecting network devices themselves. It was discovered by the Australian researcher Terry Baume in January 2009, when he noticed strange attempted attacks in his firewall logs. It drew still more attention in March of the same year when a botnet consisting of infected routers performed a DDoS attack on the DroneBL portal.

Basically, Psyb0t is an IRC bot which connects to the server, joins the channel and looks up the topic for commands. When it was discovered and the bot was still active, the command included in the topic was to scan all devices in the network and try to gain access to routers/modems by using the default username and password, or if unsuccessful, a password gained through a known authentication bypass exploit. This meant that the malware self-proliferated across the network, infecting all vulnerable devices as it went. Apart from code for proliferating, Psyb0t also contains numerous commands for initiating various types of DDoS attacks, brute forcing the router password, executing shell commands and brute forcing access to other services like MySQL, PHP MyAdmin, FTP servers, SMB shares, etc. As the router firmware is usually read-only, Psyb0t resides exclusively in RAM and a simple reboot results in the machine being disinfected. Nevertheless, vulnerable devices will be re-infected all over again unless the password has been changed and/or the firmware upgraded to the patched version.

Growth in public interest was probably the reason why its creator deactivated the botnet. On 22 March, 2009, the creator changed commands in the IRC channel topic to make all bots kill their processes and exit. He also left a message in the topic saying that the botnet reached 80 thousand infected machines and suggesting that the purpose was research-oriented, a claim which is fairly dubious.

Technical details

Psyb0t was designed to work on Linux-based systems running on the MIPSel platform (e.g. OpenWRT, DD-WRT, MontaVista Linux, VxWorks, etc.). MIPSel is a RISC architecture with little endian encoding and is mainly used in embedded devices. Unlike ARM, which is the main platform for mobile phones and mobile devices, MIPS/MIPSel is at the core of most contemporary network equipment.

The binary itself was packed with the UPX packer, although the headers had been corrupted in order to impede analysis. Actually, it is more like a primitive obfuscation than a real anti-reversing technique. To unpack the file with the standard UPX unpacker, one just needed to fix the headers by inserting the missing “UPX!” string in the proper places.

Figure 5: Psyb0t – corrupted UPX header

Some of the strings inside the file were obfuscated in order to keep them secret, if only for a short while. Here’s what some of these strings look like before decryption:

Figure 6: Psyb0t – encrypted strings

…and after:

Figure 7: Psyb0t – decrypted commands

The decryption routine is simple: it takes a specific key, which is hardcoded into the binary, and subtracts each subsequent byte of the key from each subsequent byte of the encrypted string.

Figure 8: Psyb0t – decryption routine

Proliferation

The very first thing the bot does after joining the IRC channel is to check the commands in the topic. The most important command here is the scan command, or its variants: rscan, lscan and rlscan. It issues a search for network devices in a specified address range and attempts to login using the default username and password (root/[Aa]dmin). If the attempt is unsuccessful, the bot tries to use the exploit code to retrieve the password from the device’s configuration file. It exploits the authentication bypass vulnerability in the web interface by sending a specially crafted request to the cgi-bin/firmwarecfg, which results in the malicious user receiving the entire contents of the configuration file, including the password in plain text. This vulnerability concerns several different devices, of which D-Link and Telecom are but two, and although it was fixed in newer versions users who have older hardware are still vulnerable to such attacks.

Figure 9: Psyb0t – authentication bypass exploit

After gaining access to the shell, Psyb0t searches the list of running processes looking for its own process. If the router is not infected already, Psyb0t uses either wget or tftp to download its body from the server and execute it. Next it sends a message about the successful attack to the botnet owner and goes on to the next host.

The first thing the newly-launched process does is to create a zero-sized file called udhcpc.mtx, the extension mtx probably being an abbreviation of mutex. It then decrypts certain strings before disappearing into the background where it executes the following commands:

It creates a backup copy of the /var/tmp/hosts file, connects to the password-protected IRC server and joins the #mipsel channel with a randomly-generated nickname consisting of [NIP] – prefix and nine random letters and numbers. If the reply from the server is ERR_NOMOTD, the bot also sets the channel modes.

Figure 10: Psyb0t – connecting to the IRC server

Figure 11: Psyb0t – joining IRC channel

Figure 12: Psyb0t – setting channel modes

The bot performs commands included in the channel topic and loops, waiting for other commands that may be sent in private messages.

Commands

Here is the complete list of commands that this version of the bot is capable of interpreting:

In most cases the command names are self-explanatory. We have some IRC-related commands (login, logout, rejoin, silent, mode), malware self-management commands (kill, killall, exit, sleep, upgrade, wupgrade, ver, report, split, *sel) and system information acquisition commands (tlist, getip, getinfo, uptime, viri). Additionally, it has the capacity to download additional files (wget), visit specified web pages (visit), modify the hosts file (spoof) and execute system commands. Probably the most interesting commands, however, are the DDoS-related ones which are used for SYN, UDP and ICMP attacks (*flood), plus various scan commands. Apart from the standard scan command and its variants described above, there is a group of commands that all use the same routine inside the file, with each command performing a specific action: pscan activates port scanning, r00t makes an attempt to brute force a device’s access password, while the fscan, sql, pma and smb commands perform the same attacks against FTP server, SQL server, PHP MyAdmin panel and SMB respectively.

Figure 13: Psyb0t – password used for brute force attacks

Uteltend: In nome di Chuck Norris

Although the Psyb0t botnet was shut down in late March 2009, this is not the end of the router malware story. A few months later, in December 2009, researchers from the Masaryk University located in the Czech Republic discovered another router IRC bot which in many ways reminded us of Psyb0t. The C&C centre of this new botnet was located in Italy and the strings and function names inside the malicious binaries also indicate that the code is of Italian origin. The malware contained the text ”In nome di Chuck Norris“, a phrase which occurs several times in the code, and thus the botnet’s nickname became ”Chuck Norris”. Kaspersky Lab’s signature for this malware is Trojan.Linux.Uteltend, which comes from another string in the file – a command used to prevent the utelnetd service from running on an infected machine.

Figure 14: Chuck Norris – some strings inside the binary

Let’s look first at what Chuck Norris and Psyb0t binaries have in common:

• Same platform: Linux on MIPSel devices
• Same packer: UPX; some versions have headers corrupted in exactly the same way as Psyb0t.
• IRC bot functionality
• Same method of encrypting the most sensitive information
• Similar way of proliferating
• Use of D-Link routers’ authentication bypass exploit

Chuck Norris consists of more than one file. The main binary performs a port scan using a Linux tool called pscan and a range of IP addresses taken from either the ip.txt file on the router, if it exists, or from a list encoded into the binary:

Figure 15: Chuck Norris – IP ranges

It then tries a brute force access of each network device using a set of default passwords. The command it executes afterwards is also stored in encrypted form:

Figure 16: Chuck Norris – decrypting the commands

The name of the main binary is syslgd and it imitates the name of a legitimate Linux process – syslogd – which is responsible for logging system messages. This is an attempt- albeit a very primitive one – to mask itself in the system. Additionally, this command causes the malware to try to download the small SSH server/client which is compiled especially for MIPS architecture. Among the other components found on the malicious server there was a binary with IRC bot functionality that is detected by Kaspersky Lab as Backdoor.Linux.IrcShell.c, and a Linux Trojan compiled for MIPS architecture (Trojan.Linux.Small.e).

Tsunami: the Hydra’s new head

The Chuck Norris C&C centre had been shut down before any information about it appeared in the public domain; nevertheless, the story continues. In early March 2010 a new head of the Hydra appeared in Latin America, most probably a direct descendant of the previous one. This malware was classified as a variant of Backdoor.Linux.Tsunami as it shared many of the distinguishing features associated with the Linux Kaiten/Tsunami open source DDoS tool. However, some parts of its code are also very similar to the Chuck Norris binaries, for instance, the function for obfuscating strings and the encryption key. Moreover, some of the strings and IP addresses are in fact identical.

Figure 17: Tsunami – decrypting channel name and password

Figure 18: Tsunami – IP addresses

One new thing that we hadn’t seen in any of the previous x86 Tsunami versions, or indeed Chuck Norris, were attempts to change the DNS settings – in this particular sample the name servers were set to Open DNS addresses – and it blocked a range of ports from 22 through to 80:

Figure 19: Tsunami – blocking ports, changing DNS

Tsunami bot commands are easily readable thanks to the bot’s built-in help. Most of these commands are renamed or modified Kaiten commands:

Disinfection process

As all the above mentioned binary malware only resides in RAM it is easy enough to disinfect the device. However, just restarting the router means that it is highly likely that the router will be re-infected. The most important things to do in order to protect the router are to change the password, secure the router’s settings and update the firmware to the latest version.

Conclusions

Isn’t it all just a lot of fuss about nothing?

In summary, over the last 4 years the MIPS platform has seen a few drive-by pharming attacks and a handful of malware incidents. Not that much compared to other platforms, even mobile ones, so why the hue and cry? Why is the topic still important?

First of all, if something has already been invented and has been seen in-the-wild more than once, it’s very likely to occur again and again, especially if the attacks were profitable for the cybercriminals. As we recall from history, the beginnings of malware for each platform seem to be similar. For example, right now the numbers of malicious files for mobile and 64-bit platforms are still minute compared with x86 malware, but no one can deny that they are growing fast and will probably dominate the malware market once the older architectures fade away.

Attacks via MIPS devices are relatively new and have enormous potential to do significant damage. Let’s take a look at some of the reasons why malware for network devices could become a major issue:

• Prevalence – most people have such a device in their homes, be it an ADSL modem provided by their ISP or a Wi-Fi router which allows them to share their Internet connection between desktops, laptops, tablets and other devices;
• Stealth – network devices are an ideal place for malware to lurk as no one gives a second thought to their security. Installing malware on a router instead of on a PC or Mac means that it will not be detected by contemporary desktop antivirus solutions;
• Easy access – with lots of vulnerabilities and a lack of awareness among most users, MIPS devices are just what the cybercriminals have been looking for;
• Constant access – routers usually run all the time and are rarely rebooted or powered down – ideal for the bad guys!;
• Constant control – by taking control of a router, an attacker can transparently monitor all the traffic on a network and search for packets containing sensitive information;
• Mass DNS redirections – one of the most lucrative prospects for the cybercriminals: changing the IP addresses of DNS servers results in completely transparent redirection to malicious or phishing sites of all the hosts in the network.

Another thing worth mentioning when talking about the scope of the MIPS malware threat is that it’s actually very difficult to track how widely spread such malware really is. Up until now, those cases that were detected were discovered accidentally when they affected security researchers themselves. The average home user with little or no knowledge of network security has almost no chance of detecting such malware unaided. This poses a question: how many MIPS botnets continue to operate undetected? Also, if the only goal of the cybercriminal is to change the DNS settings, it doesn’t require malware to constantly run on the device. A malicious process can exit just as soon as it has applied its configuration changes, leaving the device apparently uninfected. This approach would make the process of tracking attacks even more difficult. It seems like a very interesting area for further research.

What can be done to reduce the security risk?

Users should ensure that they use strong passwords, check their security settings and update their firmware and any relevant software regularly – at present, these are the only things they can really do. The rest is squarely in the hands of the vendors – the only people who can change the devices’ designs. The first step should be to implement randomly-generated default passwords, unique for each single device. Some vendors already do this. Also, some newer devices have many more secured settings than their predecessors – which do not allow remote access with default credentials. However, there is still a lot of work to be done. UPnP implementation needs to be rewritten and SNMP should be used in its secured version only. Greater emphasis should be placed on firmware vulnerabilities and firmware security, so every device should be thoroughly security tested before being released.

What does the future hold?

All malware evolves and multiplies and we must expect MIPS malware to follow this pattern too. Here are some predictions that I made while writing this article:

• Attacks on the ARM platform – as it is the second most popular network device platform;
• Attacks on proprietary operating systems from major vendors – as not every device runs a Linux based OS;
• Constantly updated firmware – as cybercriminals may create malware that doesn’t disappear after a reboot;
• Further adoption of Linux/Unix malware – as there are already a lot of open-source hack tools, bots and backdoors which can easily be adapted to the MIPS platform;
• Significant advances in exploits – as there are a lot of known and unpatched vulnerabilities, and probably more still of the unknown variety;
• Advanced obfuscation techniques – once the problem of router malware becomes widely known and security solutions begin to appear;
• Cross-platform malware – in order to extend the flexibility and effectiveness of attacks. This could mean malware containing code for different router platforms or code that re-infects PCs connected to a router or a router running on a PC.

As they say, the sky is the limit. Let’s see how the situation changes in the next few years. Most importantly though, let’s not be passive about this – it’s not too late to change the way in which network device security evolves.