Category Archives: Internet of Things

IoT malware sees major rise

Not even your washing machine is safe from new threats, Kaspersky warns. The number of malware targeting Internet of Things (IoT) devices is ‘snowballing’, Kaspersky Lab’s newest report claims.The company’s

The post IoT malware sees major rise appeared first on The Cyber Security Place.

Securelist – Kaspersky Lab’s cyberthreat research and reports: Threats posed by using RATs in ICS

While conducting audits, penetration tests and incident investigations, we have often come across legitimate remote administration tools (RAT) for PCs installed on operational technology (OT) networks of industrial enterprises. In a number of incidents that we have investigated, threat actors had used RATs to attack industrial organizations. In some cases, the attackers had stealthily installed RATs on victim organizations’ computers, while in other cases, they had been able to use the RATs that were installed in the organization at the time of the attacks. These observations prompted us to analyze the scope of the threat, including the incidence of RATs on industrial networks and the reasons for using them.

Methodology

The statistical data presented in this paper was collected using the Kaspersky Security Network (KSN) from ICS computers protected by Kaspersky Lab products that Kaspersky Lab ICS CERT categorizes as part of the industrial infrastructure at organizations. This group includes Windows computers that perform one or several of the following functions:

  • supervisory control and data acquisition (SCADA) servers;
  • data storage servers (Historian);
  • data gateways (OPC);
  • stationary workstations of engineers and operators;
  • mobile workstations of engineers and operators;
  • Human Machine Interface (HMI).

As part of our research, we considered and analyzed all popular RATs for Windows, with the exception of Remote Desktop, which is part of the Windows operating system. Our research into this RAT is ongoing and will be presented in the next paper of the series.

The use of RATs in ICS

According to KSN data, in the first half of 2018, legitimate RATs (programs categorized as not-a-virus: RemoteAdmin) were installed and used on one ICS computer in three.

&&

Percentage of ICS computers that have RATs legitimately installed on them (download)

The statistics support our observations: RATs are indeed often used on OT networks of industrial enterprises. We believe this could be due to attempts to reduce costs associated with maintaining ICS and minimize the response time in the event of malfunction.

As we were able to find out, remote access to computers on the OT network is not restricted to administrators and engineers inside the enterprise network’s perimeter. It can also be made available via the internet to users outside the enterprise network perimeter. Such users can include representatives of third-party enterprises – employees of system integrators or ICS vendors, who use RATs for diagnostics, maintenance and to address any ICS malfunctions. As our industrial network security audits have shown, such access is often poorly supervised by the enterprise’s responsible employees, while remote users connecting to the OT network often have excessive rights, such as local administrator privileges, which is obviously a serious issue in terms of ensuring the information security of industrial automation systems.

From interviews with engineers and operators of various industrial systems that we have audited, and based on an analysis of ICS user documentation, we have determined that RATs are most commonly used on industrial networks according to the following scenarios:

  1. To control/monitor HMI from an operator workstation (including displaying information on a large screen);
  2. To control/maintain HMI from an engineering workstation;
  3. To control SCADA from an operator workstation;
  4. To provide SCADA maintenance from an engineering workstation or a computer of a contractor/vendor (from an external network);
  5. To connect multiple operators to one operator workstation (thin client-like architecture used to save money on licenses for the software used on operator workstations);
  6. To connect to a computer on the office network from the OT network via HMI and perform various tasks on that computer (access email, access the internet, work with office documents, etc.).

Some of the scenarios listed above indicate that the use of RATs on the OT network can be explained by operational requirements, which means that giving up the use of RATs would unavoidably entail modifications to work processes. At the same time, it is important to realize that an attack on a poorly protected RAT could easily cause disruptions to the industrial process and any decisions on using RATs on the OT network should be made with this in mind. Tight controls on the use of RATs on the OT network would help to reduce the attack surface and the risk of infection for systems administered remotely.

&&

TOP 20 countries by percentage of ICS computers on which RATs were used at least once during the first half of 2018 (to all ICS computers in each country) (download)

Scenarios of RAT installation on ICS computers

According to our research, there are three most common scenarios of RAT installation on ICS computers:

  1. Installation of ICS software distribution packages that include RATs (using separate distribution packages or ICS software installers). RATs included in ICS software distribution packages make up 18.6% of all RATs we have identified on ICS computers protected by Kaspersky Lab products.

&&

Percentage of RATs bundled with ICS products to all RATs found on ICS computers (download)

  1. Deliberate installation of RATs by personnel or suppliers – network administrators, engineers, operators, or integrator companies. We do not undertake to judge whether these installations are legitimate. Based on our experience of industrial network audits and incident investigation, we can state that many such installations do not comply with the organization’s information security policy and some are installed without the knowledge of respective enterprises’ responsible employees.
  2. Stealthy installation of RATs by malware. An example of this is a recent attack that we have investigated (see below).

Threats associated with the use of RATs on industrial networks are not always obvious, nor are the reasons for which RATs are used.

Most of the RATs we have identified on industrial systems have the following characteristics that significantly reduce the security level of the host system:

  • Elevated privileges – the server part of a RAT is often executed as a service with system privileges, i.e., NT SYSTEM;
  • No support for restricting local access to the system / client activity;
  • Single-factor authentication;
  • No logging of client activity;
  • Vulnerabilities (our report on zero-day vulnerabilities identified in popular RAT systems that are used, among other applications, in products by many ICS vendors, will be published by the end of the year);
  • The use of relay servers (for reverse connections) that enable RATs to bypass NAT and firewall restrictions on the network perimeter.

The most critical RAT-related problem is the use of elevated privileges and the absence of any means to limit these privileges (or to restrict a remote user’s local access). In practice, this means that if attackers (or malware) gain access to a remote user’s computer, steal authentication data (login/password), hijack an active remote administration session or successfully attack a vulnerability in the RAT’s server part, they will gain unrestricted control of the ICS system. By using relay servers for reverse connections, attackers can also connect to these RATs from anywhere in the world.

There are also other issues that affect RATs built into ICS software distribution packages:

  • RAT components and distribution packages are rarely updated (even if new versions of ICS distribution packages are released). This makes them more likely to contain vulnerabilities;
  • In the vast majority of cases, the default password is used – it is either hardcoded into the RAT by the ICS software vendor or specified in the documentation as “recommended”.

RATs are legitimate software tools that are often used on industrial networks, which means it can be extremely difficult to distinguish attacks involving RATs from legitimate activity. In addition, since the information security service and other employees responsible for ICS security are often unaware that a RAT is installed, the configuration of RATs is in most cases not analyzed when auditing the security of an industrial network. This makes it particularly important to control by whom, when and for what purposes RATs are used on the industrial network and to ensure that it is completely impossible to use RATs without the knowledge of employees responsible for the OT network’s information security.

Attacks of threat actors involving RATs

Everything written above applies to potential threats associated with the use of RATs.

Based on our analysis of KSN statistics, we were able to identify a number of attacks and malware infection attempts involving RATs installed on ICS computers. In most cases, attacks were based on the following scenarios (in the descending order of attack incidence):

  1. A brute force network attack from the local network or the internet designed to crack logins/passwords;
  2. An attacker or malware using a RAT to download and execute malware using stolen or cracked authentication credentials;
  3. A remote user (probably a legitimate user deceived by attackers) using a RAT to download a Trojan to an ICS computer and then executing it; the Trojan can be disguised as an office document, non-industrial software (a game, multimedia software, etc.), a crack/keygen for office, application or industrial software, etc.;
  4. A network attack from the local network or the internet on the server part of the RAT using exploits.

Brute force type network attacks (designed to crack logins/passwords) are the most common: their implementation does not require any special knowledge or skills and the software used in such attacks is publicly available.

It cannot be determined based on available data who connects to a RAT’s server part installed on an ICS computer – a legitimate user, an attacker or malware – or why. Consequently, we can only guess whether this activity represents a targeted attack, sabotage attempts or a client’s error.

Network attacks from the internet were most probably conducted by threat actors using malware, penetration testing tools or botnets.

Network attacks from the local network could indicate the presence of attackers (possibly including an insider) on the network. Another possibility is that there is a compromised computer on the local network that is either infected with malware or is used by the attacker as a point of presence (if the authentication credentials were compromised earlier).

Attacks on industrial enterprises using RMS and TeamViewer

In the first half of 2018, Kaspersky Lab ICS CERT identified a new wave of phishing emails disguised as legitimate commercial offers. Although the attacks targeted primarily industrial companies within the territory of Russia, the same tactics and tools can be used in attacks on industrial companies in any country of the world.

The malware used in these attacks installs legitimate remote administration software on the system — TeamViewer or Remote Manipulator System/Remote Utilities (RMS). In both cases, a system DLL is replaced with a malicious library to inject malicious code into a legitimate program’s process. This provides the attackers with remote control of the infected systems. Various techniques are used to mask the infection and the activity of the software installed on the system.

If necessary, the attackers download an additional malware pack to the system, which is specifically tailored to the attack on each individual victim. This set of malware may contain spyware, additional remote administration tools that extend the threat actor’s control of infected systems, malware to exploit vulnerabilities in the operating system and application software, as well as the Mimikatz utility, which makes it possible to obtain account data for Windows accounts.

According to available data, the attackers’ main goal is to steal money from victim organizations’ accounts, but possible attack scenarios are not limited to the theft of funds. In the process of attacking their targets, the attackers steal sensitive data belonging to target organizations, their partners and customers, carry out surreptitious surveillance of the victim companies’ employees, and record audio and video using devices connected to infected machines. Clearly, on top of the financial losses, these attacks result in leaks of victim organizations’ sensitive data.

Multiple attacks on an auto manufacturer

A characteristic example of attacks based on the second scenario was provided by attacks on the industrial network of a motor vehicle manufacturing and service company, in particular, on computers designed to diagnose the engines and onboard systems of trucks and heavy-duty vehicles. Multiple attempts to conduct such attacks were blocked by Kaspersky Lab products.

A RAT was installed and intermittently used on at least one of the computers in the company’s industrial network. Starting in late 2017, numerous attempts to launch various malicious programs using the RAT were blocked on the computer. Infection attempts were made regularly over a period of several months – 2-3 times a week, at different times of the day. Based in part on other indirect indicators, we believe that RAT authentication data was compromised and used by attackers (or malware) to attack the enterprise’s computers over the internet.

After gaining access to the potential victim’s infrastructure via the RAT, the attackers kept trying to choose a malicious packer that would enable them to evade antivirus protection.

The blocked programs included modifications of the malware detected by Kaspersky Lab products as Net-Worm.Win32.Agent.pm. When launched this worm immediately begins to proliferate on the local network using exploits for the MS17-010 vulnerabilities – the same ones that were published by ShadowBrokers in the spring of 2017 and were used in attacks by the infamous WannaCry and ExPetr cryptors.

The Nymaim Trojan family was also blocked. Representatives of this family are often used to download modifications of botnet agents from the Necus family, which in turn have often been used to infect computers with ransomware from the Locky family.

Conclusion

Remote administration tools are widely used on industrial networks for ICS monitoring, control and maintenance. The ability to manipulate the ICS remotely significantly reduces maintenance costs, but at the same time, uncontrolled remote access, the inability to provide 100% verification of the remote client’s legitimacy, and the vulnerabilities in RAT code and configuration significantly increase the attack surface. At the same time, RATs, along with other legitimate tools, are increasingly used by attackers to mask malicious activity and make attribution more difficult.

To reduce the risk of cyberattacks involving RATs, we recommend the following high-priority measures:

  • Audit the use of application and system remote administration tools on the industrial network, such as VNC, RDP, TeamViewer, and RMS / Remote Utilities. Remove all remote administration tools that are not required by the industrial process.
  • Conduct an audit and disable remote administration tools which came with ICS software (refer to the relevant software documentation for detailed instructions), provided that they are not required by the industrial process.
  • Closely monitor and log events for each remote control session required by the industrial process; remote access should be disabled by default and enabled only upon request and only for limited periods of time.


Securelist - Kaspersky Lab’s cyberthreat research and reports

Threats posed by using RATs in ICS

While conducting audits, penetration tests and incident investigations, we have often come across legitimate remote administration tools (RAT) for PCs installed on operational technology (OT) networks of industrial enterprises. In a number of incidents that we have investigated, threat actors had used RATs to attack industrial organizations. In some cases, the attackers had stealthily installed RATs on victim organizations’ computers, while in other cases, they had been able to use the RATs that were installed in the organization at the time of the attacks. These observations prompted us to analyze the scope of the threat, including the incidence of RATs on industrial networks and the reasons for using them.

Methodology

The statistical data presented in this paper was collected using the Kaspersky Security Network (KSN) from ICS computers protected by Kaspersky Lab products that Kaspersky Lab ICS CERT categorizes as part of the industrial infrastructure at organizations. This group includes Windows computers that perform one or several of the following functions:

  • supervisory control and data acquisition (SCADA) servers;
  • data storage servers (Historian);
  • data gateways (OPC);
  • stationary workstations of engineers and operators;
  • mobile workstations of engineers and operators;
  • Human Machine Interface (HMI).

As part of our research, we considered and analyzed all popular RATs for Windows, with the exception of Remote Desktop, which is part of the Windows operating system. Our research into this RAT is ongoing and will be presented in the next paper of the series.

The use of RATs in ICS

According to KSN data, in the first half of 2018, legitimate RATs (programs categorized as not-a-virus: RemoteAdmin) were installed and used on one ICS computer in three.

Percentage of ICS computers that have RATs legitimately installed on them (download)

The statistics support our observations: RATs are indeed often used on OT networks of industrial enterprises. We believe this could be due to attempts to reduce costs associated with maintaining ICS and minimize the response time in the event of malfunction.

As we were able to find out, remote access to computers on the OT network is not restricted to administrators and engineers inside the enterprise network’s perimeter. It can also be made available via the internet to users outside the enterprise network perimeter. Such users can include representatives of third-party enterprises – employees of system integrators or ICS vendors, who use RATs for diagnostics, maintenance and to address any ICS malfunctions. As our industrial network security audits have shown, such access is often poorly supervised by the enterprise’s responsible employees, while remote users connecting to the OT network often have excessive rights, such as local administrator privileges, which is obviously a serious issue in terms of ensuring the information security of industrial automation systems.

From interviews with engineers and operators of various industrial systems that we have audited, and based on an analysis of ICS user documentation, we have determined that RATs are most commonly used on industrial networks according to the following scenarios:

  1. To control/monitor HMI from an operator workstation (including displaying information on a large screen);
  2. To control/maintain HMI from an engineering workstation;
  3. To control SCADA from an operator workstation;
  4. To provide SCADA maintenance from an engineering workstation or a computer of a contractor/vendor (from an external network);
  5. To connect multiple operators to one operator workstation (thin client-like architecture used to save money on licenses for the software used on operator workstations);
  6. To connect to a computer on the office network from the OT network via HMI and perform various tasks on that computer (access email, access the internet, work with office documents, etc.).

Some of the scenarios listed above indicate that the use of RATs on the OT network can be explained by operational requirements, which means that giving up the use of RATs would unavoidably entail modifications to work processes. At the same time, it is important to realize that an attack on a poorly protected RAT could easily cause disruptions to the industrial process and any decisions on using RATs on the OT network should be made with this in mind. Tight controls on the use of RATs on the OT network would help to reduce the attack surface and the risk of infection for systems administered remotely.

TOP 20 countries by percentage of ICS computers on which RATs were used at least once during the first half of 2018 (to all ICS computers in each country) (download)

Scenarios of RAT installation on ICS computers

According to our research, there are three most common scenarios of RAT installation on ICS computers:

  1. Installation of ICS software distribution packages that include RATs (using separate distribution packages or ICS software installers). RATs included in ICS software distribution packages make up 18.6% of all RATs we have identified on ICS computers protected by Kaspersky Lab products.

Percentage of RATs bundled with ICS products to all RATs found on ICS computers (download)

  1. Deliberate installation of RATs by personnel or suppliers – network administrators, engineers, operators, or integrator companies. We do not undertake to judge whether these installations are legitimate. Based on our experience of industrial network audits and incident investigation, we can state that many such installations do not comply with the organization’s information security policy and some are installed without the knowledge of respective enterprises’ responsible employees.
  2. Stealthy installation of RATs by malware. An example of this is a recent attack that we have investigated (see below).

Threats associated with the use of RATs on industrial networks are not always obvious, nor are the reasons for which RATs are used.

Most of the RATs we have identified on industrial systems have the following characteristics that significantly reduce the security level of the host system:

  • Elevated privileges – the server part of a RAT is often executed as a service with system privileges, i.e., NT SYSTEM;
  • No support for restricting local access to the system / client activity;
  • Single-factor authentication;
  • No logging of client activity;
  • Vulnerabilities (our report on zero-day vulnerabilities identified in popular RAT systems that are used, among other applications, in products by many ICS vendors, will be published by the end of the year);
  • The use of relay servers (for reverse connections) that enable RATs to bypass NAT and firewall restrictions on the network perimeter.

The most critical RAT-related problem is the use of elevated privileges and the absence of any means to limit these privileges (or to restrict a remote user’s local access). In practice, this means that if attackers (or malware) gain access to a remote user’s computer, steal authentication data (login/password), hijack an active remote administration session or successfully attack a vulnerability in the RAT’s server part, they will gain unrestricted control of the ICS system. By using relay servers for reverse connections, attackers can also connect to these RATs from anywhere in the world.

There are also other issues that affect RATs built into ICS software distribution packages:

  • RAT components and distribution packages are rarely updated (even if new versions of ICS distribution packages are released). This makes them more likely to contain vulnerabilities;
  • In the vast majority of cases, the default password is used – it is either hardcoded into the RAT by the ICS software vendor or specified in the documentation as “recommended”.

RATs are legitimate software tools that are often used on industrial networks, which means it can be extremely difficult to distinguish attacks involving RATs from legitimate activity. In addition, since the information security service and other employees responsible for ICS security are often unaware that a RAT is installed, the configuration of RATs is in most cases not analyzed when auditing the security of an industrial network. This makes it particularly important to control by whom, when and for what purposes RATs are used on the industrial network and to ensure that it is completely impossible to use RATs without the knowledge of employees responsible for the OT network’s information security.

Attacks of threat actors involving RATs

Everything written above applies to potential threats associated with the use of RATs.

Based on our analysis of KSN statistics, we were able to identify a number of attacks and malware infection attempts involving RATs installed on ICS computers. In most cases, attacks were based on the following scenarios (in the descending order of attack incidence):

  1. A brute force network attack from the local network or the internet designed to crack logins/passwords;
  2. An attacker or malware using a RAT to download and execute malware using stolen or cracked authentication credentials;
  3. A remote user (probably a legitimate user deceived by attackers) using a RAT to download a Trojan to an ICS computer and then executing it; the Trojan can be disguised as an office document, non-industrial software (a game, multimedia software, etc.), a crack/keygen for office, application or industrial software, etc.;
  4. A network attack from the local network or the internet on the server part of the RAT using exploits.

Brute force type network attacks (designed to crack logins/passwords) are the most common: their implementation does not require any special knowledge or skills and the software used in such attacks is publicly available.

It cannot be determined based on available data who connects to a RAT’s server part installed on an ICS computer – a legitimate user, an attacker or malware – or why. Consequently, we can only guess whether this activity represents a targeted attack, sabotage attempts or a client’s error.

Network attacks from the internet were most probably conducted by threat actors using malware, penetration testing tools or botnets.

Network attacks from the local network could indicate the presence of attackers (possibly including an insider) on the network. Another possibility is that there is a compromised computer on the local network that is either infected with malware or is used by the attacker as a point of presence (if the authentication credentials were compromised earlier).

Attacks on industrial enterprises using RMS and TeamViewer

In the first half of 2018, Kaspersky Lab ICS CERT identified a new wave of phishing emails disguised as legitimate commercial offers. Although the attacks targeted primarily industrial companies within the territory of Russia, the same tactics and tools can be used in attacks on industrial companies in any country of the world.

The malware used in these attacks installs legitimate remote administration software on the system — TeamViewer or Remote Manipulator System/Remote Utilities (RMS). In both cases, a system DLL is replaced with a malicious library to inject malicious code into a legitimate program’s process. This provides the attackers with remote control of the infected systems. Various techniques are used to mask the infection and the activity of the software installed on the system.

If necessary, the attackers download an additional malware pack to the system, which is specifically tailored to the attack on each individual victim. This set of malware may contain spyware, additional remote administration tools that extend the threat actor’s control of infected systems, malware to exploit vulnerabilities in the operating system and application software, as well as the Mimikatz utility, which makes it possible to obtain account data for Windows accounts.

According to available data, the attackers’ main goal is to steal money from victim organizations’ accounts, but possible attack scenarios are not limited to the theft of funds. In the process of attacking their targets, the attackers steal sensitive data belonging to target organizations, their partners and customers, carry out surreptitious surveillance of the victim companies’ employees, and record audio and video using devices connected to infected machines. Clearly, on top of the financial losses, these attacks result in leaks of victim organizations’ sensitive data.

Multiple attacks on an auto manufacturer

A characteristic example of attacks based on the second scenario was provided by attacks on the industrial network of a motor vehicle manufacturing and service company, in particular, on computers designed to diagnose the engines and onboard systems of trucks and heavy-duty vehicles. Multiple attempts to conduct such attacks were blocked by Kaspersky Lab products.

A RAT was installed and intermittently used on at least one of the computers in the company’s industrial network. Starting in late 2017, numerous attempts to launch various malicious programs using the RAT were blocked on the computer. Infection attempts were made regularly over a period of several months – 2-3 times a week, at different times of the day. Based in part on other indirect indicators, we believe that RAT authentication data was compromised and used by attackers (or malware) to attack the enterprise’s computers over the internet.

After gaining access to the potential victim’s infrastructure via the RAT, the attackers kept trying to choose a malicious packer that would enable them to evade antivirus protection.

The blocked programs included modifications of the malware detected by Kaspersky Lab products as Net-Worm.Win32.Agent.pm. When launched this worm immediately begins to proliferate on the local network using exploits for the MS17-010 vulnerabilities – the same ones that were published by ShadowBrokers in the spring of 2017 and were used in attacks by the infamous WannaCry and ExPetr cryptors.

The Nymaim Trojan family was also blocked. Representatives of this family are often used to download modifications of botnet agents from the Necus family, which in turn have often been used to infect computers with ransomware from the Locky family.

Conclusion

Remote administration tools are widely used on industrial networks for ICS monitoring, control and maintenance. The ability to manipulate the ICS remotely significantly reduces maintenance costs, but at the same time, uncontrolled remote access, the inability to provide 100% verification of the remote client’s legitimacy, and the vulnerabilities in RAT code and configuration significantly increase the attack surface. At the same time, RATs, along with other legitimate tools, are increasingly used by attackers to mask malicious activity and make attribution more difficult.

To reduce the risk of cyberattacks involving RATs, we recommend the following high-priority measures:

  • Audit the use of application and system remote administration tools on the industrial network, such as VNC, RDP, TeamViewer, and RMS / Remote Utilities. Remove all remote administration tools that are not required by the industrial process.
  • Conduct an audit and disable remote administration tools which came with ICS software (refer to the relevant software documentation for detailed instructions), provided that they are not required by the industrial process.
  • Closely monitor and log events for each remote control session required by the industrial process; remote access should be disabled by default and enabled only upon request and only for limited periods of time.

Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique

Experts at the CSE Cybsec Z-Lab have found a Gafgyt variant implementing the “Non Un-Packable” technique recently presented in a cyber security conference

A new variant of the Gafgyt botnet is spreading in the last hours and experts of the CSE Cybsec Z-Lab have found it with the support of the Italian cyber security experts @Odisseus and GranetMan.

The new variant analyzed in the report published by the experts was found on a system resolving the IP address owned by the Italian ISP Aruba. This specific version implements some advanced packing techniques that make the static analysis much harder.

We downloaded the sample directly from the compromised server, we found four samples of the Gafgyt variant that were already compiled for the specific architecture, X86-64, X86-32, MIPS, ARM.

The sample shows the same behavior associated with the classic Gafgyt botnet but we immediately noticed a distinctive feature, the implementation of “Non Un-Packable” NUP technique.

Malware Must Die leader @unixfreaxjp presented the sophisticated technique at the recent Radare conference (r2con2018) in his talk about the “Non Un-Packable” packer.

According to the experts the “Non Un-Packable” ELF was around since a few months before the talk and our discovery confirms that malware developers started adopting it.

The report includes a detailed analysis of the malware.

You can download the full ZLAB Malware Analysis Report at the following URL:

http://csecybsec.com/download/zlab/20180919_CSE_Gafgyt_v2.pdf

 

Pierluigi Paganini

(Security Affairs – Gafgyt, malware)

The post Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique appeared first on Security Affairs.

Security Affairs: Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique

Experts at the CSE Cybsec Z-Lab have found a Gafgyt variant implementing the “Non Un-Packable” technique recently presented in a cyber security conference

A new variant of the Gafgyt botnet is spreading in the last hours and experts of the CSE Cybsec Z-Lab have found it with the support of the Italian cyber security experts @Odisseus and GranetMan.

The new variant analyzed in the report published by the experts was found on a system resolving the IP address owned by the Italian ISP Aruba. This specific version implements some advanced packing techniques that make the static analysis much harder.

We downloaded the sample directly from the compromised server, we found four samples of the Gafgyt variant that were already compiled for the specific architecture, X86-64, X86-32, MIPS, ARM.

The sample shows the same behavior associated with the classic Gafgyt botnet but we immediately noticed a distinctive feature, the implementation of “Non Un-Packable” NUP technique.

Malware Must Die leader @unixfreaxjp presented the sophisticated technique at the recent Radare conference (r2con2018) in his talk about the “Non Un-Packable” packer.

According to the experts the “Non Un-Packable” ELF was around since a few months before the talk and our discovery confirms that malware developers started adopting it.

The report includes a detailed analysis of the malware.

You can download the full ZLAB Malware Analysis Report at the following URL:

http://csecybsec.com/download/zlab/20180919_CSE_Gafgyt_v2.pdf

 

Pierluigi Paganini

(Security Affairs – Gafgyt, malware)

The post Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique appeared first on Security Affairs.



Security Affairs

Kaspersky: Attacks on Smart Devices Rise Threefold in 2018

Attacks against smart devices are surging, with both old and new threats targeting connected devices that remain largely unsecured, according to researchers at Kaspersky Lab. Kaspersky researchers observed three times as many malware samples against smart devices in the first half of 2018 than they did in all of 2017, according to new findings...

Read the whole entry... »

Related Stories

Key weapon for closing IoT-era cybersecurity gaps? Artificial intelligence

As businesses struggle to combat increasingly sophisticated cybersecurity attacks, the severity of which is exacerbated by both the vanishing IT perimeters in today’s mobile and IoT era, and an acute shortage of skilled

The post Key weapon for closing IoT-era cybersecurity gaps? Artificial intelligence appeared first on The Cyber Security Place.

Evolution of threat landscape for IoT devices – H1 2018

Security experts from Kaspersky have published an interesting report on the new trends in the IoT threat landscape. What is infecting IoT devices and how?

The researchers set up a honeypot to collect data on infected IoT devices, the way threat actors infect IoT devices and what families of malware are involved.

The first data that emerged from the study is that threat actors continue to look at the IoT devices with increasing interest. In the first six months of 2018, the experts observed a number of malware samples that was up three times as many samples targeting IoT devices as in the whole of 2017. In 2017 there were ten times more than in 2016.

IoT devices attacks

In the first half of 2018, researchers at Kaspersky Lab said that the most popular attack vector against IoT devices remains cracking Telnet passwords (75,40%), followed by cracking SSH passwords (11,59%).

Mirai dominates the IoT threat landscape, 20.9% of IoT devices were infected by this malicious code, other prominent malware are Hajime (5.89%) and Gafgyt.

Top 10 countries from which Kaspersky traps were hit by Telnet password attacks is led by Brazil, China, and Japan.

“As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%).” reads the report.

“Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.”

Experts pointed out that infected MikroTik routers made up 37.23 percent of all the data collected, followed by TP-Link that accounted for 9.07%.

MikroTik devices running under RouterOS are targeted by malicious code that includes the exploit for the Chimay-Red vulnerability.

The Chimay Red hacking tool leverages 2 exploits, the Winbox Any Directory File Read (CVE-2018-14847) and Webfig Remote Code Execution Vulnerability.

MikroTik devices were involved in several campaigns in the past months, including the VPNfilter botnet that infected almost a million routers in more than 50 countries

Iot devices

Experts highlighted that IoT malware is increasing both in quantity and quality.

“More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.” concludes Kaspersky.

Let me suggest to read to read the report, is full of interesting data.

Pierluigi Paganini

(Security Affairs – IoT devices, hacking)

The post Evolution of threat landscape for IoT devices – H1 2018 appeared first on Security Affairs.

Security Affairs: Evolution of threat landscape for IoT devices – H1 2018

Security experts from Kaspersky have published an interesting report on the new trends in the IoT threat landscape. What is infecting IoT devices and how?

The researchers set up a honeypot to collect data on infected IoT devices, the way threat actors infect IoT devices and what families of malware are involved.

The first data that emerged from the study is that threat actors continue to look at the IoT devices with increasing interest. In the first six months of 2018, the experts observed a number of malware samples that was up three times as many samples targeting IoT devices as in the whole of 2017. In 2017 there were ten times more than in 2016.

IoT devices attacks

In the first half of 2018, researchers at Kaspersky Lab said that the most popular attack vector against IoT devices remains cracking Telnet passwords (75,40%), followed by cracking SSH passwords (11,59%).

Mirai dominates the IoT threat landscape, 20.9% of IoT devices were infected by this malicious code, other prominent malware are Hajime (5.89%) and Gafgyt.

Top 10 countries from which Kaspersky traps were hit by Telnet password attacks is led by Brazil, China, and Japan.

“As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%).” reads the report.

“Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.”

Experts pointed out that infected MikroTik routers made up 37.23 percent of all the data collected, followed by TP-Link that accounted for 9.07%.

MikroTik devices running under RouterOS are targeted by malicious code that includes the exploit for the Chimay-Red vulnerability.

The Chimay Red hacking tool leverages 2 exploits, the Winbox Any Directory File Read (CVE-2018-14847) and Webfig Remote Code Execution Vulnerability.

MikroTik devices were involved in several campaigns in the past months, including the VPNfilter botnet that infected almost a million routers in more than 50 countries

Iot devices

Experts highlighted that IoT malware is increasing both in quantity and quality.

“More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.” concludes Kaspersky.

Let me suggest to read to read the report, is full of interesting data.

Pierluigi Paganini

(Security Affairs – IoT devices, hacking)

The post Evolution of threat landscape for IoT devices – H1 2018 appeared first on Security Affairs.



Security Affairs

The State of Security: U.S. Federal IoT Policy: What You Need to Know

Over the past several months, increased attention has been paid to U.S. federal government policies surrounding internal use of IoT devices. In January 2018, researchers discovered they could track the movements of fitness tracker-wearing military personnel over the Internet. In July, a similar revelation occurred with fitness app Polar, which was exposing the locations of […]… Read More

The post U.S. Federal IoT Policy: What You Need to Know appeared first on The State of Security.



The State of Security

U.S. Federal IoT Policy: What You Need to Know

Over the past several months, increased attention has been paid to U.S. federal government policies surrounding internal use of IoT devices. In January 2018, researchers discovered they could track the movements of fitness tracker-wearing military personnel over the Internet. In July, a similar revelation occurred with fitness app Polar, which was exposing the locations of […]… Read More

The post U.S. Federal IoT Policy: What You Need to Know appeared first on The State of Security.

Radware Blog: IoT, 5G Networks and Cybersecurity: Safeguarding 5G Networks with Automation and AI

By 2020, Gartner says there will be 20.4 billion IoT devices. That rounds out to almost three devices per person on earth. As a result, IoT devices will show up in just about every aspect of daily life. While IoT devices promise benefits such as improved productivity, longevity and enjoyment, they also open a Pandora’s […]

The post IoT, 5G Networks and Cybersecurity: Safeguarding 5G Networks with Automation and AI appeared first on Radware Blog.



Radware Blog

Securelist – Kaspersky Lab’s cyberthreat research and reports: New trends in the world of IoT threats

Cybercriminals’ interest in IoT devices continues to grow: in H1 2018 we picked up three times as many malware samples attacking smart devices as in the whole of 2017. And in 2017 there were ten times more than in 2016. That doesn’t bode well for the years ahead.

We decided to study what attack vectors are deployed by cybercriminals to infect smart devices, what malware is loaded into the system, and what it means for device owners and victims of freshly armed botnets.

&&

Number of malware samples for IoT devices in Kaspersky Lab’s collection, 2016-2018. (download)

One of the most popular attack and infection vectors against devices remains cracking Telnet passwords. In Q2 2018, there were three times as many such attacks against our honeypots than all other types combined.

service % of attacks
Telnet 75.40%
SSH 11.59%
other 13.01%

When it came to downloading malware onto IoT devices, cybercriminals’ preferred option was one of the Mirai family (20.9%).

# downloaded malware % of attacks
1 Backdoor.Linux.Mirai.c 15.97%
2 Trojan-Downloader.Linux.Hajime.a 5.89%
3 Trojan-Downloader.Linux.NyaDrop.b 3.34%
4 Backdoor.Linux.Mirai.b 2.72%
5 Backdoor.Linux.Mirai.ba 1.94%
6 Trojan-Downloader.Shell.Agent.p 0.38%
7 Trojan-Downloader.Shell.Agent.as 0.27%
8 Backdoor.Linux.Mirai.n 0.27%
9 Backdoor.Linux.Gafgyt.ba 0.24%
10 Backdoor.Linux.Gafgyt.af 0.20%

Top 10 malware downloaded onto infected IoT device following a successful Telnet password crack

And here are the Top 10 countries from which our traps were hit by Telnet password attacks:

&&

Geographical distribution of the number of infected devices, Q2 2018. (download)

As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%). Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.

Since some smart device owners change the default Telnet password to one that is more complex, and many gadgets don’t support this protocol at all, cybercriminals are constantly on the lookout for new ways of infection. This is stimulated by the high competition between virus writers, which has led to password bruteforce attacks becoming less effective: in the event of a successful crack, the device password is changed and access to Telnet is blocked.

An example of the use of “alternative technology” is the Reaper botnet, whose assets at end-2017 numbered about 2 million IoT devices. Instead of bruteforcing Telnet passwords, this botnet exploited known software vulnerabilities:

Advantages of this distribution method over password cracking:

  • Infection occurs much faster
  • It is much harder to patch a software vulnerability than change a password or disable/block the service

Although this method is more difficult to implement, it found favor with many virus writers, and it wasn’t long before new Trojans exploiting known vulnerabilities in smart device software started appearing.

New attacks, old malware

To see which vulnerabilities are targeted by malware, we analyzed data on attempts to connect to various ports on our traps. This is the picture that emerged for Q2 2018:

Service Port % of attacks Attack vector Malware families
Telnet 23, 2323 82.26% Bruteforce Mirai, Gafgyt
SSH 22 11.51% Bruteforce Mirai, Gafgyt
Samba 445 2.78% EternalBlue, EternalRed, CVE-2018-7445
tr-069 7547 0.77% RCE in TR-069 implementation Mirai, Hajime
HTTP 80 0.76% Attempts to exploit vulnerabilities in a web server or crack an admin console password
winbox (RouterOS) 8291 0.71% Used for RouterOS (MikroTik) authentication and WinBox-based attacks Hajime
Mikrotik http 8080 0.23% RCE in MikroTik RouterOS < 6.38.5 Chimay-Red Hajime
MSSQL 1433 0.21% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft
GoAhead httpd 81 0.16% RCE in GoAhead IP cameras Persirai, Gafgyt
Mikrotik http 8081 0.15% Chimay-Red Hajime
Etherium JSON-RPC 8545 0.15% Authorization bypass (CVE-2017-12113)
RDP 3389 0.12% Bruteforce
XionMai uc-httpd 8000 0.09% Buffer overflow (CVE-2018-10088) in XionMai uc-httpd 1.0.0 (some Chinese-made devices) Satori
MySQL 3306 0.08% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft

The vast majority of attacks still come from Telnet and SSH password bruteforcing. The third most common are attacks against the SMB service, which provides remote access to files. We haven’t seen IoT malware attacking this service yet. However, some versions of it contain serious known vulnerabilities such as EternalBlue (Windows) and EternalRed (Linux), which were used, for instance, to distribute the infamous Trojan ransomware WannaCry and the Monero cryptocurrency miner EternalMiner.

Here’s the breakdown of infected IoT devices that attacked our honeypots in Q2 2018:

Device % of infected devices
MikroTik 37.23%
TP-Link 9.07%
SonicWall 3.74%
AV tech 3.17%
Vigor 3.15%
Ubiquiti 2.80%
D-Link 2.49%
Cisco 1.40%
AirTies 1.25%
Cyberoam 1.13%
HikVision 1.11%
ZTE 0.88%
Miele 0.68%
Unknown DVR 31.91%

As can be seen, MikroTik devices running under RouterOS are way out in front. The reason appears to be the Chimay-Red vulnerability. What’s interesting is that our honeypot attackers included 33 Miele dishwashers (0.68% of the total number of attacks). Most likely they were infected through the known (since March 2017) CVE-2017-7240 vulnerability in PST10 WebServer, which is used in their firmware.

Port 7547

Attacks against remote device management (TR-069 specification) on port 7547 are highly common. According to Shodan, there are more than 40 million devices in the world with this port open. And that’s despite the vulnerability recently causing the infection of a million Deutsche Telekom routers, not to mention helping to spread the Mirai and Hajime malware families.

Another type of attack exploits the Chimay-Red vulnerability in MikroTik routers running under RouterOS versions below 6.38.4. In March 2018, it played an active part in distributing Hajime.

IP cameras

IP cameras are also on the cybercriminal radar. In March 2017, several major vulnerabilities were detected in the software of GoAhead devices, and a month after information about it was published, there appeared new versions of the Gafgyt and Persirai Trojans exploiting these vulnerabilities. Just one week after these malicious programs were actively distributed, the number of infected devices climbed to 57,000.

On June 8, 2018, a proof-of-concept was published for the CVE-2018-10088 vulnerability in the XionMai uc-httpd web server, used in some Chinese-made smart devices (for example, KKMoon DVRs). The next day, the number of logged attempts to locate devices using this web server more than tripled. The culprit for this spike in activity was the Satori Trojan, known for previously attacking GPON routers.

New malware and threats to end users

DDoS attacks

As before, the primary purpose of IoT malware deployment is to perpetrate DDoS attacks. Infected smart devices become part of a botnet that attacks a specific address on command, depriving the host of the ability to correctly handle requests from real users. Such attacks are still deployed by Trojans from the Mirai family and its clones, in particular, Hajime.

This is perhaps the least harmful scenario for the end user. The worst (and very unlikely) thing that can happen to the owner of the infected device is being blocked by their ISP. And the device can often by “cured” with a simple reboot.

Cryptocurrency mining

Another type of payload is linked to cryptocurrencies. For instance, IoT malware can install a miner on an infected device. But given the low processing power of smart devices, the feasibility of such attacks remains in doubt, even despite their potentially large number.

A more devious and doable method of getting a couple of cryptocoins was invented by the creators of the Satori Trojan. Here, the victim IoT device acts as a kind of key that opens access to a high-performance PC:

  • At the first stage, the attackers try to infect as many routers as possible using known vulnerabilities, in particular:
    • CVE-2014-8361 – RCE in the miniigd SOAP service in Realtek SDK
    • CVE 2017-17215 – RCE in the firmware of Huawei HG532 routers
    • CVE-2018-10561, CVE-2018-10562 – authorization bypass and execution of arbitrary commands on Dasan GPON routers
    • CVE-2018-10088 – buffer overflow in XiongMai uc-httpd 1.0.0 used in the firmware of some routers and other smart devices made by some Chinese manufacturers
  • Using compromised routers and the CVE-2018-1000049 vulnerability in the Claymore Etherium miner remote management tool, they substitute the wallet address for their own.

Data theft

The VPNFilter Trojan, detected in May 2018, pursues other goals, above all intercepting infected device traffic, extracting important data from it (user names, passwords, etc.), and sending it to the cybercriminals’ server. Here are the main features of VPNFilter:

  • Modular architecture. The malware creators can fit it out with new functions on the fly. For instance, in early June 2018 a new module was detected able to inject javascript code into intercepted web pages.
  • Reboot resistant. The Trojan writes itself to the standard Linux crontab job scheduler, and can also modify the configuration settings in the non-volatile memory (NVRAM) of the device.
  • Uses TOR for communication with C&C.
  • Able to self-destruct and disable the device. On receiving the command, the Trojan deletes itself, overwrites the critical part of the firmware with garbage data, and then reboots the device.

The Trojan’s distribution method is still unknown: its code contains no self-propagation mechanisms. However, we are inclined to believe that it exploits known vulnerabilities in device software for infection purposes.

The very first VPNFilter report spoke of around 500,000 infected devices. Since then, even more have appeared, and the list of manufacturers of vulnerable gadgets has expanded considerably. As of mid-June, it included the following brands:

  • ASUS
  • D-Link
  • Huawei
  • Linksys
  • MikroTik
  • Netgear
  • QNAP
  • TP-Link
  • Ubiquiti
  • Upvel
  • ZTE

The situation is made worse by the fact that these manufacturers’ devices are used not only in corporate networks, but often as home routers.

Conclusion

Smart devices are on the rise, with some forecasts suggesting that by 2020 their number will exceed the world’s population several times over. Yet manufacturers still don’t prioritize security: there are no reminders to change the default password during initial setup or notifications about the release of new firmware versions, and the updating process itself can be complex for the average user. This makes IoT devices a prime target for cybercriminals. Easier to infect than PCs, they often play an important role in the home infrastructure: some manage Internet traffic, others shoot video footage, still others control domestic devices (for example, air conditioning).

Malware for smart devices is increasing not only in quantity, but also quality. More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.

Here are some simple tips to help minimize the risk of smart device infection:

  • Don’t give access to the device from an external network unless absolutely necessary
  • Periodic rebooting will help get rid of malware already installed (although in most cases the risk of reinfection will remain)
  • Regularly check for new firmware versions and update the device
  • Use complex passwords at least 8 characters long, including upper and lower-case letters, numerals, and special characters
  • Change the factory passwords at initial setup (even if the device does not prompt you to do so)
  • Close/block unused ports, if there is such an option. For example, if you don’t connect to the router via Telnet (port TCP:23), it’s a good idea to disable it so as to close off a potential loophole to intruders.


Securelist - Kaspersky Lab’s cyberthreat research and reports

New trends in the world of IoT threats

Cybercriminals’ interest in IoT devices continues to grow: in H1 2018 we picked up three times as many malware samples attacking smart devices as in the whole of 2017. And in 2017 there were ten times more than in 2016. That doesn’t bode well for the years ahead.

We decided to study what attack vectors are deployed by cybercriminals to infect smart devices, what malware is loaded into the system, and what it means for device owners and victims of freshly armed botnets.

Number of malware samples for IoT devices in Kaspersky Lab’s collection, 2016-2018. (download)

One of the most popular attack and infection vectors against devices remains cracking Telnet passwords. In Q2 2018, there were three times as many such attacks against our honeypots than all other types combined.

service % of attacks
Telnet 75.40%
SSH 11.59%
other 13.01%

When it came to downloading malware onto IoT devices, cybercriminals’ preferred option was one of the Mirai family (20.9%).

# downloaded malware % of attacks
1 Backdoor.Linux.Mirai.c 15.97%
2 Trojan-Downloader.Linux.Hajime.a 5.89%
3 Trojan-Downloader.Linux.NyaDrop.b 3.34%
4 Backdoor.Linux.Mirai.b 2.72%
5 Backdoor.Linux.Mirai.ba 1.94%
6 Trojan-Downloader.Shell.Agent.p 0.38%
7 Trojan-Downloader.Shell.Agent.as 0.27%
8 Backdoor.Linux.Mirai.n 0.27%
9 Backdoor.Linux.Gafgyt.ba 0.24%
10 Backdoor.Linux.Gafgyt.af 0.20%

Top 10 malware downloaded onto infected IoT device following a successful Telnet password crack

And here are the Top 10 countries from which our traps were hit by Telnet password attacks:

Geographical distribution of the number of infected devices, Q2 2018. (download)

As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%). Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.

Since some smart device owners change the default Telnet password to one that is more complex, and many gadgets don’t support this protocol at all, cybercriminals are constantly on the lookout for new ways of infection. This is stimulated by the high competition between virus writers, which has led to password bruteforce attacks becoming less effective: in the event of a successful crack, the device password is changed and access to Telnet is blocked.

An example of the use of “alternative technology” is the Reaper botnet, whose assets at end-2017 numbered about 2 million IoT devices. Instead of bruteforcing Telnet passwords, this botnet exploited known software vulnerabilities:

Advantages of this distribution method over password cracking:

  • Infection occurs much faster
  • It is much harder to patch a software vulnerability than change a password or disable/block the service

Although this method is more difficult to implement, it found favor with many virus writers, and it wasn’t long before new Trojans exploiting known vulnerabilities in smart device software started appearing.

New attacks, old malware

To see which vulnerabilities are targeted by malware, we analyzed data on attempts to connect to various ports on our traps. This is the picture that emerged for Q2 2018:

Service Port % of attacks Attack vector Malware families
Telnet 23, 2323 82.26% Bruteforce Mirai, Gafgyt
SSH 22 11.51% Bruteforce Mirai, Gafgyt
Samba 445 2.78% EternalBlue, EternalRed, CVE-2018-7445
tr-069 7547 0.77% RCE in TR-069 implementation Mirai, Hajime
HTTP 80 0.76% Attempts to exploit vulnerabilities in a web server or crack an admin console password
winbox (RouterOS) 8291 0.71% Used for RouterOS (MikroTik) authentication and WinBox-based attacks Hajime
Mikrotik http 8080 0.23% RCE in MikroTik RouterOS < 6.38.5 Chimay-Red Hajime
MSSQL 1433 0.21% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft
GoAhead httpd 81 0.16% RCE in GoAhead IP cameras Persirai, Gafgyt
Mikrotik http 8081 0.15% Chimay-Red Hajime
Etherium JSON-RPC 8545 0.15% Authorization bypass (CVE-2017-12113)
RDP 3389 0.12% Bruteforce
XionMai uc-httpd 8000 0.09% Buffer overflow (CVE-2018-10088) in XionMai uc-httpd 1.0.0 (some Chinese-made devices) Satori
MySQL 3306 0.08% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft

The vast majority of attacks still come from Telnet and SSH password bruteforcing. The third most common are attacks against the SMB service, which provides remote access to files. We haven’t seen IoT malware attacking this service yet. However, some versions of it contain serious known vulnerabilities such as EternalBlue (Windows) and EternalRed (Linux), which were used, for instance, to distribute the infamous Trojan ransomware WannaCry and the Monero cryptocurrency miner EternalMiner.

Here’s the breakdown of infected IoT devices that attacked our honeypots in Q2 2018:

Device % of infected devices
MikroTik 37.23%
TP-Link 9.07%
SonicWall 3.74%
AV tech 3.17%
Vigor 3.15%
Ubiquiti 2.80%
D-Link 2.49%
Cisco 1.40%
AirTies 1.25%
Cyberoam 1.13%
HikVision 1.11%
ZTE 0.88%
Miele 0.68%
Unknown DVR 31.91%

As can be seen, MikroTik devices running under RouterOS are way out in front. The reason appears to be the Chimay-Red vulnerability. What’s interesting is that our honeypot attackers included 33 Miele dishwashers (0.68% of the total number of attacks). Most likely they were infected through the known (since March 2017) CVE-2017-7240 vulnerability in PST10 WebServer, which is used in their firmware.

Port 7547

Attacks against remote device management (TR-069 specification) on port 7547 are highly common. According to Shodan, there are more than 40 million devices in the world with this port open. And that’s despite the vulnerability recently causing the infection of a million Deutsche Telekom routers, not to mention helping to spread the Mirai and Hajime malware families.

Another type of attack exploits the Chimay-Red vulnerability in MikroTik routers running under RouterOS versions below 6.38.4. In March 2018, it played an active part in distributing Hajime.

IP cameras

IP cameras are also on the cybercriminal radar. In March 2017, several major vulnerabilities were detected in the software of GoAhead devices, and a month after information about it was published, there appeared new versions of the Gafgyt and Persirai Trojans exploiting these vulnerabilities. Just one week after these malicious programs were actively distributed, the number of infected devices climbed to 57,000.

On June 8, 2018, a proof-of-concept was published for the CVE-2018-10088 vulnerability in the XionMai uc-httpd web server, used in some Chinese-made smart devices (for example, KKMoon DVRs). The next day, the number of logged attempts to locate devices using this web server more than tripled. The culprit for this spike in activity was the Satori Trojan, known for previously attacking GPON routers.

New malware and threats to end users

DDoS attacks

As before, the primary purpose of IoT malware deployment is to perpetrate DDoS attacks. Infected smart devices become part of a botnet that attacks a specific address on command, depriving the host of the ability to correctly handle requests from real users. Such attacks are still deployed by Trojans from the Mirai family and its clones, in particular, Hajime.

This is perhaps the least harmful scenario for the end user. The worst (and very unlikely) thing that can happen to the owner of the infected device is being blocked by their ISP. And the device can often by “cured” with a simple reboot.

Cryptocurrency mining

Another type of payload is linked to cryptocurrencies. For instance, IoT malware can install a miner on an infected device. But given the low processing power of smart devices, the feasibility of such attacks remains in doubt, even despite their potentially large number.

A more devious and doable method of getting a couple of cryptocoins was invented by the creators of the Satori Trojan. Here, the victim IoT device acts as a kind of key that opens access to a high-performance PC:

  • At the first stage, the attackers try to infect as many routers as possible using known vulnerabilities, in particular:
    • CVE-2014-8361 – RCE in the miniigd SOAP service in Realtek SDK
    • CVE 2017-17215 – RCE in the firmware of Huawei HG532 routers
    • CVE-2018-10561, CVE-2018-10562 – authorization bypass and execution of arbitrary commands on Dasan GPON routers
    • CVE-2018-10088 – buffer overflow in XiongMai uc-httpd 1.0.0 used in the firmware of some routers and other smart devices made by some Chinese manufacturers
  • Using compromised routers and the CVE-2018-1000049 vulnerability in the Claymore Etherium miner remote management tool, they substitute the wallet address for their own.

Data theft

The VPNFilter Trojan, detected in May 2018, pursues other goals, above all intercepting infected device traffic, extracting important data from it (user names, passwords, etc.), and sending it to the cybercriminals’ server. Here are the main features of VPNFilter:

  • Modular architecture. The malware creators can fit it out with new functions on the fly. For instance, in early June 2018 a new module was detected able to inject javascript code into intercepted web pages.
  • Reboot resistant. The Trojan writes itself to the standard Linux crontab job scheduler, and can also modify the configuration settings in the non-volatile memory (NVRAM) of the device.
  • Uses TOR for communication with C&C.
  • Able to self-destruct and disable the device. On receiving the command, the Trojan deletes itself, overwrites the critical part of the firmware with garbage data, and then reboots the device.

The Trojan’s distribution method is still unknown: its code contains no self-propagation mechanisms. However, we are inclined to believe that it exploits known vulnerabilities in device software for infection purposes.

The very first VPNFilter report spoke of around 500,000 infected devices. Since then, even more have appeared, and the list of manufacturers of vulnerable gadgets has expanded considerably. As of mid-June, it included the following brands:

  • ASUS
  • D-Link
  • Huawei
  • Linksys
  • MikroTik
  • Netgear
  • QNAP
  • TP-Link
  • Ubiquiti
  • Upvel
  • ZTE

The situation is made worse by the fact that these manufacturers’ devices are used not only in corporate networks, but often as home routers.

Conclusion

Smart devices are on the rise, with some forecasts suggesting that by 2020 their number will exceed the world’s population several times over. Yet manufacturers still don’t prioritize security: there are no reminders to change the default password during initial setup or notifications about the release of new firmware versions, and the updating process itself can be complex for the average user. This makes IoT devices a prime target for cybercriminals. Easier to infect than PCs, they often play an important role in the home infrastructure: some manage Internet traffic, others shoot video footage, still others control domestic devices (for example, air conditioning).

Malware for smart devices is increasing not only in quantity, but also quality. More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.

Here are some simple tips to help minimize the risk of smart device infection:

  • Don’t give access to the device from an external network unless absolutely necessary
  • Periodic rebooting will help get rid of malware already installed (although in most cases the risk of reinfection will remain)
  • Regularly check for new firmware versions and update the device
  • Use complex passwords at least 8 characters long, including upper and lower-case letters, numerals, and special characters
  • Change the factory passwords at initial setup (even if the device does not prompt you to do so)
  • Close/block unused ports, if there is such an option. For example, if you don’t connect to the router via Telnet (port TCP:23), it’s a good idea to disable it so as to close off a potential loophole to intruders.

Blog | Avast EN: Could smart speakers undo your smart home? | Avast

Juniper Research predicts that by 2022 more than half the homes in the U.S. will contain smart speakers like today’s popular Amazon Alexa and Google Home, and it’s easy to see why. Providing the answer to any question we can dream up, producing music and other entertainment on demand, handling our online shopping, they are one giant step towards the personal droid assistants we’ve all been craving since meeting C-3PO and R2-D2.



Blog | Avast EN

Podcast Episode 112: what it takes to be a top bug hunter

In this week’s episode (#112): top bug hunters can earn more than $1 million a year from “bounties” paid for information on exploitable software holes in common platforms and applications. What does it take to be among the best? We talk with Jason Haddix of the firm Bug Crowd to find out. Also: The Internet Society’s Jeff...

Read the whole entry... »

Related Stories

Security Affairs: One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable

One year after the discovery of the BlueBorne Bluetooth vulnerabilities more than 2 billion devices are still vulnerable to attacks.

In September 2017, experts with Armis Labs devised a new attack technique, dubbed BlueBorne, aimed at mobile, desktop and IoT devices that use Bluetooth.  The BlueBorne attack exposes devices to a new remote attack, even without any user interaction and pairing, the unique condition for BlueBorne attacks is that targeted systems must have Bluetooth enabled.

The attack technique leverages on a total of nine vulnerabilities in the Bluetooth design that expose devices to cyber attacks.

A hacker in range of the targeted device can trigger one of the Bluetooth implementation issues for malicious purposes, including remote code execution and man-in-the-middle (MitM) attacks. The attacker only needs to determine the operating system running on the targeted device in order to use the correct exploit.

According to the experts, in order to launch a BlueBorne attack, it is not necessary to trick the victim into clicking on a link or opening a malicious file.

The attack is stealthy and victims will not notice any suspicious activity on their device.

blueborne attack

Two months later, experts at Armis also revealed that millions of AI-based voice-activated personal assistants, including Google Home and Amazon Echo, were affected by the Blueborne flaws.

At the time of BlueBorne disclosure, Armis estimated that the security flaw initially affected roughly 5.3 billion Bluetooth-enabled devices.

One year after the company published a new report that warns that roughly one-third of the 5.3 billion impacted devices are still vulnerable to cyber attacks.

“Today, about two-thirds of previously affected devices have received updates that protect them from becoming victims of a BlueBorne attack, but what about the rest? Most of these devices are nearly one billion active Android and iOS devices that are end-of-life or end-of-support and won’t receive critical updates that patch and protect them from a BlueBorne attack.” states the new report published by Armis.

“The other 768 million devices are still running unpatched or unpatchable versions of Linux on a variety of devices from servers and smartwatches to medical devices and industrial equipment.

  • 768 million devices running Linux
  • 734 million devices running Android 5.1 (Lollipop) and earlier
  • 261 million devices running Android 6 (Marshmallow) and earlier
  • 200 million devices running affected versions of Windows
  • 50 million devices running iOS version 9.3.5 and earlier”

It is disconcerting, one billion devices are still running a version of Android that no longer receives security updates, including Android 5.1 Lollipop and earlier (734 million), and Android 6 Marshmallow and earlier (261 million).

It is interesting to note that 768 million Linux devices are running an unpatched or unpatchable version, they include servers, industrial equipment, and IoT systems in many industries.

“An inherent lack of visibility hampers most enterprise security tools today, making it impossible for organizations to know if affected devices connect to their networks,” continues the report published by Armis.

“Whether they’re brought in by employees and contractors, or by guests using enterprise networks for temporary connectivity, these devices can expose enterprises to significant risks.”

Armis notified its findings to vendors five months ago, but the situation is not changed.

“As vulnerabilities and threats are discovered, it can take weeks, months, or more to patch them. Between the time Armis notified affected vendors about BlueBorne and its public disclosure, five months had elapsed. During that time, Armis worked with these vendors to develop fixes that could then be made available to partners or end-users.” added Armis.

Unmanaged and IoT devices grow exponentially in the enterprise dramatically enlarging the attack surface and attracting the interest of hackers focused in the exploitation of Bluetooth as an attack vector.

Pierluigi Paganini

(Security Affairs – BlueBorne, hacking)

The post One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable appeared first on Security Affairs.



Security Affairs

One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable

One year after the discovery of the BlueBorne Bluetooth vulnerabilities more than 2 billion devices are still vulnerable to attacks.

In September 2017, experts with Armis Labs devised a new attack technique, dubbed BlueBorne, aimed at mobile, desktop and IoT devices that use Bluetooth.  The BlueBorne attack exposes devices to a new remote attack, even without any user interaction and pairing, the unique condition for BlueBorne attacks is that targeted systems must have Bluetooth enabled.

The attack technique leverages on a total of nine vulnerabilities in the Bluetooth design that expose devices to cyber attacks.

A hacker in range of the targeted device can trigger one of the Bluetooth implementation issues for malicious purposes, including remote code execution and man-in-the-middle (MitM) attacks. The attacker only needs to determine the operating system running on the targeted device in order to use the correct exploit.

According to the experts, in order to launch a BlueBorne attack, it is not necessary to trick the victim into clicking on a link or opening a malicious file.

The attack is stealthy and victims will not notice any suspicious activity on their device.

blueborne attack

Two months later, experts at Armis also revealed that millions of AI-based voice-activated personal assistants, including Google Home and Amazon Echo, were affected by the Blueborne flaws.

At the time of BlueBorne disclosure, Armis estimated that the security flaw initially affected roughly 5.3 billion Bluetooth-enabled devices.

One year after the company published a new report that warns that roughly one-third of the 5.3 billion impacted devices are still vulnerable to cyber attacks.

“Today, about two-thirds of previously affected devices have received updates that protect them from becoming victims of a BlueBorne attack, but what about the rest? Most of these devices are nearly one billion active Android and iOS devices that are end-of-life or end-of-support and won’t receive critical updates that patch and protect them from a BlueBorne attack.” states the new report published by Armis.

“The other 768 million devices are still running unpatched or unpatchable versions of Linux on a variety of devices from servers and smartwatches to medical devices and industrial equipment.

  • 768 million devices running Linux
  • 734 million devices running Android 5.1 (Lollipop) and earlier
  • 261 million devices running Android 6 (Marshmallow) and earlier
  • 200 million devices running affected versions of Windows
  • 50 million devices running iOS version 9.3.5 and earlier”

It is disconcerting, one billion devices are still running a version of Android that no longer receives security updates, including Android 5.1 Lollipop and earlier (734 million), and Android 6 Marshmallow and earlier (261 million).

It is interesting to note that 768 million Linux devices are running an unpatched or unpatchable version, they include servers, industrial equipment, and IoT systems in many industries.

“An inherent lack of visibility hampers most enterprise security tools today, making it impossible for organizations to know if affected devices connect to their networks,” continues the report published by Armis.

“Whether they’re brought in by employees and contractors, or by guests using enterprise networks for temporary connectivity, these devices can expose enterprises to significant risks.”

Armis notified its findings to vendors five months ago, but the situation is not changed.

“As vulnerabilities and threats are discovered, it can take weeks, months, or more to patch them. Between the time Armis notified affected vendors about BlueBorne and its public disclosure, five months had elapsed. During that time, Armis worked with these vendors to develop fixes that could then be made available to partners or end-users.” added Armis.

Unmanaged and IoT devices grow exponentially in the enterprise dramatically enlarging the attack surface and attracting the interest of hackers focused in the exploitation of Bluetooth as an attack vector.

Pierluigi Paganini

(Security Affairs – BlueBorne, hacking)

The post One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable appeared first on Security Affairs.

Researchers exploring how IoT apps can to imitate human decisions

CA Technologies announced its participation in scientific research to discover how Internet of Things (IoT) applications can use a type of AI known as ‘deep learning’ to imitate human decisions. The research will also explore how to prevent that AI-based decisions are not producing biased results. This three-year research project is named ALOHA (adaptive and secure deep learning on heterogeneous architectures). “The future of all technologies will include AI and deep learning in some way,” … More

The post Researchers exploring how IoT apps can to imitate human decisions appeared first on Help Net Security.

Veeam mishandles Own Data, exposes 440M Customer E-mails

Data-management Veeam found itself in need of some self-help after mismanaging its own data with a misconfigured server that exposed more than 440 million e-mail addresses and other types of customer information. Security researcher Bob Diachenko discovered that a MongoDB server operated by Veeam was left wide open and searchable for some days in...

Read the whole entry... »

Related Stories

Inside a Modern-Day Smart Home

Ever wonder how the Internet of Things (IoT) first began? Often regarded as the first IoT device, John Romkey created a toaster that could be turned on and off over the internet for the October ’89 INTEROP conference. Then in 2000, LG announced its first internet refrigerator plans. So on and so forth IoT grew and grew, populating homes everywhere. Soon enough, we got the smart home. Though the name itself has become household, many people may not fully understand the ins and outs of a smart home. And beyond that, many don’t know the security implications tied to it. Let’s take a look.

Popularity via Convenience

According to Gartner, 20.8 billion connected devices are predicted to exist in consumer homes by 2020. So why have these devices and the smart homes they fill boomed so drastically in popularity in the past few years? One word: convenience.

If we use enough of them, these devices automate our daily existence. They turn our lights on for us, flip music on at the sound of our voice, even change the temperature in our house. And they’ve become all too easy to accumulate since the technology has started to become more affordable. A few of the key and common smart devices that can be found in a modern smart home include smart refrigerators, smart lights, smart speakers, smart TVs. Beyond that, more family-oriented devices are becoming smart — including baby cams, thermometers, and children’s toys.

As we look ahead, it’s been predicted that the type of devices that are “smart” will grow to become more diverse, driving wider adoption. And that will cause more businesses to jump on the IoT train — builders, developers and anyone in the world of residential life are going to link up with smart tech.

The Digital (and Physical) Impact of IoT

But the continuous growth of these devices, now and in the future, is something we all have to smart about. These IoT devices are convenient, but their build makes them a convenient target for cybercriminals. This is because many IoT devices aren’t built with security in mind, and users often leave default settings on, which makes it easy for hackers to breach them. Just take the McAfee ATR team’s recent discovery about the Wemo Insight Smart Plug for example – the device was found to contain a crucial vulnerability that could allow hackers to manipulate it. Not to mention, digital assistants are susceptible to something called a ‘Dolphin Attack,’ which can be leveraged by cybercriminals to potentially breach a user.

And since all these IoT devices must connect to Wi-Fi, they can expose an entire network to threats. In fact, according to a recent McAfee survey, the biggest worry among recent respondents about having their wireless home network hacked is that cybercriminals could steal personal information and make them a victim of identity theft (63%).

There are physical repercussions to a vulnerable IoT device as well. Once they’ve hacked a connected device, cybercriminals can also manipulate the device itself and can flip the lights off, listen in on your smart baby monitor, the list goes on.

Connecting With Care

The good news is there are a few things we can all do to prevent IoT attacks and still enjoy our smart homes. First things first, we must all buy IoT devices with security in mind. Just by doing some basic research and looking up the manufacturers, we can get a feel if they have security top of mind. Most importantly, we have to change default settings and use a security solution that protects our homes at the router-level, such as McAfee Secure Home Platform.

By following these best practices, we can live our connected lives with confidence and enjoy the convenience of our high-tech homes. Both our homes and our personal security will remain smart.

To learn more about smart homes and IoT, be sure to follow us at @McAfee and @McAfee_Home.

The post Inside a Modern-Day Smart Home appeared first on McAfee Blogs.

Taking Stock: The Internet of Things, and Machine Learning Algorithms at War

It’s in the news every day; hackers targeting banks, hospitals, or, as we’ve come to fear the most, elections.

Suffice to say then that cybersecurity has, in the last few years, gone from a relatively obscure industry – let’s qualify that: not in the sense of importance, but rather how folks have been interacting with it – to one at the forefront of global efforts to protect our data and applications.

 A decade ago, cybersecurity researchers were almost as caliginous as the hackers they were trying to defend folks against, and despite the lack of fanfare, some people still chose it as a career (*gasp).

We spoke to one of our whizz-kids, Gilad Yehudai, to find out what makes him tick and why, of all the possible fields in tech, he chose cybersecurity at a time when it might not have been the sexiest of industries.

Protecting data and applications, a different beast altogether

One of the major challenges facing the industry is the ability to attract new talent; especially when competing against companies that occupy the public sphere from the moment our alarm wakes us up to the moment we lay our phones to rest. Gilad, who has a master’s degree in mathematics and forms part of our team in Israel, offers a pretty interesting perspective,

“The world of cybersecurity is a fascinating one from my point of view, especially when trying to solve machine learning problems related to it. Cybersecurity is adversarial in nature, where hackers try to understand security mechanisms and how to bypass them. Developing algorithms in such environments is much more challenging than algorithms where the data doesn’t try to fool you.”

Never a dull moment

Additionally, our industry is one in flux, as more threats and vulnerabilities are introduced, and hackers find new ways to bypass security mechanisms. The latter was a pretty big draw for Gilad, whose experience in mathematics and serving in the Israeli Army’s cyber defense department made him a great candidate for the Imperva threat research team.

“The research group at Imperva seemed like the perfect fit, as large parts of my day to day job is to develop machine learning algorithms in the domain of cybersecurity, and the data I use is mostly attacks on web applications.”

Speaking of attacks, Gilad and the rest of our research team sure have their hands full.

“In my opinion, the Internet of Things (IoT) security is one of the biggest challenges out there. More and more devices are connected to the internet every day and these devices may be put to malicious use. Hackers may enlist these devices to their botnet in order to launch attacks like DDoS, ATO (account takeover), comment spam and much more.”

Worse still, our growing network of ‘micro-computers’ (smartphones, tablets etc.) could be manipulated and their computational power used to mine cryptocurrencies.

“Protecting these devices the same way we protect endpoint PCs will be one of the biggest challenges.”

Change brings new challenges, and opportunities

On the topic of change, the cybersecurity industry, according to Gilad, is headed increasingly towards machine learning and automation; which serves us well.

“If in the past most security mechanisms were based on hard-coded rules written by security experts, today more and more products are based on rules that are created automatically using artificial intelligent algorithms. These mechanisms can be much more dynamic and adapt better to the ever-changing world of cybersecurity.”

That said, the more the industry relies on machine learning algorithms for defense, the higher the likelihood that hackers will look to manipulate those same algorithms for their own purposes.

“Hackers may try to create adversarial examples to fool machine learning algorithms. Securing algorithms will require more effort, effort that will intensify as these algorithms are used in more sensitive processes. For example, facial recognition algorithms that authorize access to a specific location may be fooled by hackers using an adversarial example in order to gain access to an unauthorized location.”

While the cyber threat landscape continues to evolve, and the bad actors looking to nick our data and compromise our applications get increasingly creative, it’s good to know that there are experts whose sole purpose it is to ‘fight the good fight’, so to speak.

“Research is a bit like walking in the dark, you don’t know in which direction to go next, and you never know what you are going find. Sometimes you begin to research in some direction, and in the process you find a completely other direction which you haven’t even though about at the beginning. Research is not for everybody, but I get really excited about it.

NIST Launches Privacy Framework Effort

On September 4, 2018, the Department of Commerce’s National Institute of Standards and Technology (“NIST”) announced a collaborative project to develop a voluntary privacy framework to help organizations manage privacy risk. The announcement states that the effort is motivated by innovative new technologies, such as the Internet of Things and artificial intelligence, as well as the increasing complexity of network environments and detail of user data, which make protecting individuals’ privacy more difficult. “We’ve had great success with broad adoption of the NIST Cybersecurity Framework, and we see this as providing complementary guidance for managing privacy risk,” said Under Secretary of Commerce for Standards and Technology and NIST Director Walter G. Copan.

The goals for the framework stated in the announcement include providing an enterprise-level approach that helps organizations prioritize strategies for flexible and effective privacy protection solutions and bridge gaps between privacy professionals and senior executives so that organizations can respond effectively to these challenges without stifling innovation. To kick off the effort, the NIST has scheduled a public workshop on October 16, 2018, in Austin, Texas, which will occur in conjunction with the International Association of Privacy Professionals’ “Privacy. Security. Risk. 2018” conference. The Austin workshop is the first in a series planned to collect current practices, challenges and requirements in managing privacy risks in ways that go beyond common cybersecurity practices.

In parallel with the NIST’s efforts, the Department of Commerce’s National Telecommunications and Information Administration (“NTIA”) is “developing a domestic legal and policy approach for consumer privacy.” The announcement stated that the NTIA is coordinating its efforts with the department’s International Trade Administration “to ensure consistency with international policy objectives.”

Podcast Episode 111: Click Here to Kill Everybody and CyberSN on Why Security Talent Walks

In this week’s podcast (episode #111), sponsored by CyberSN: what happens when the Internet gets physical? Noted author and IBM security guru Bruce Schneier joins us to talk about his new book on Internet of Things risk: Click Here to Kill Everybody. Also: everyone knows that cyber security talent is hard to come by, and even harder to keep....

Read the whole entry... »

Related Stories

The Risk of IoT Security Complacency

Cyber security professionals are increasingly relying on their key security solutions to bridge staff and knowledge gaps.

Trend Micro recently surveyed 1,150 IT executives globally. We found a gap between the perceived risk from IoT and the planned mitigation for that risk. Most senior executives recognize that IoT can introduce security risk to the organization, but few will invest resources to remediate that risk. Click here for more details. Senior leadership should perform an IoT Gap Analysis on their IoT risk vs. remediation plans.

Your Gap Analysis should look at two things. First, discover the perceived risk of any IT-connected IoT (and Industrial Control Systems generally) held by your senior leadership. Include their understanding of the responsible persons and organizational functions addressing that risk. Compare that with the view held by your supervisors and technicians managing those devices, including the actual individuals and organizations or teams handling the mitigation efforts. Second, assess the investment in mitigation supported by senior leadership compared with the actual steps taken to deploy and use those supported actions by the supervisors and technicians (and anything else they might have innovated, as well).

You are looking for consistency of intent and effectiveness of investment.

Figure 1: Cybersecurity Risk Matrix

When evaluating the likelihood of an event, remember that cybercriminals use automated tools to scan all networks for vulnerabilities. Any Internet-connected, unpatched IoT device has a “High” likelihood of being attacked.

As you stage your remediation activities, start with the items in the top right three boxes, labeled in red. Then address the items on the diagonal. Once you have mitigated the issues in these zones, you can then institute a program of continually monitoring activity that might change the risk profile, and as a result broaden your attach profile. As you roll new technology out, build this assessment into your design or product selection, release, and operations procedures. Verify that your business partners who also use those technologies are in harmony with your security program. Supply chain risks abound in the Internet of Things. Finally, consider the items that fall into the three lower left boxes shown in green.

Use your internal audit team to help your IoT Gap Analysis. They know how to assess program risk, and they know how to talk to technologists and managers. If your organization perceives high risk but does not take steps to mitigate that risk, you may be violating your business partners’ expectations – not to mention their contractual terms, and possibly regulatory or legal constraints.

As you complete your risk assessment, remain pragmatic. It is far better to be generally right than precisely wrong. With a bit of effort, you can justify a cost-effective, comprehensive information security program that will include your ICS, IoT, and existing IT infrastructure.

Let me know what you think! Comment below, or reach me on Twitter: @WilliamMalikTM . 

The post The Risk of IoT Security Complacency appeared first on .

Trending: IoT Malware Attacks of 2018

Since January 1st of 2018, a barrage of cyberattacks and data breaches have hit almost every industry, targeting businesses large and small, many of which are now from IoT devices. By 2025, it is estimated that there will be approximately 75 billion connected devices around the world. With more IoT devices ­–from wearables and pacemakers to thermometers and smart plugs–on the market and in the home, cybercriminals are keen to leverage them in attacks. This heightened interest is due to the vulnerabilities in many IoT devices, not to mention their ability to connect to each other, which can form an IoT botnet.

In a botnet scenario, a network of internet-connected devices is infected with malware and controlled without the users’ knowledge, in order to launch ransomware and DDoS attacks (distributed denial-of-service). Once unleashed, the consequences of botnet attacks can be devastating. This possible reality sounds like the plot of a science fiction movie, one which we hypothesized in our 2018 Threats Prediction Report. As we head into this year’s final months, we take a look at how this year’s threats compared to our predictions for you, the consumer.

At the end of 2017, we predicted that the convenience and ease of a connected home could lead to a decrease in privacy. Our devices already transmit significant data, with or without the knowledge of the consumer, back to the corporations the devices are made. This unprecedented access to consumer data is what is driving cybercriminals to become more familiar with IoT botnet attacks. Just in 2018 alone, we’ve seen smart TVs, virtual assistants, and even smart plugs display detrimental security flaws that could be exploited by bad actors. Some IoT devices were used to facilitate botnet attacks, like an IoT thermometer and home Wi-Fi routers. In 2017, these security concerns were simply predictions- but now they are very much a reality. And while the window to get ahead of these attacks is closing, consumers need to be prepared in case your IoT devices go haywire.

Be the difference in your home when it comes to security and IoT devices. Protect both you and your family from these threats with these tips:

  • When buying an IoT device, make security a priority. Before your next IoT purchase, do your research. Prioritize purchasing devices that have been on the market for a while, have a name brand, or have a lot of online reviews. If you follow this protocol, the chances are that the device’s security standards will be higher, due to being vetted by the masses.
  • Change default device passwords. As soon as you bring a new device into your home, change the password to something difficult to guess. Cybercriminals often know the default settings and can use them to access your devices. If the device has advanced security options, use them.
  • Keep your software up-to-date. To protect against potential vulnerabilities, manufacturers often release software updates. Set your device to auto-update, if possible, so you always have the latest software.
  • Use a comprehensive security program. It’s important to think about security holistically. Not all IoT devices are restricted to the home; many are mobile (such as smart watches). If you’re out and about, you may need to connect to an unsecured network – say an airport with public Wi-Fi. Your kids may have devices. The scenarios may be different, but the risk is the same. Protect your network of connected devices no matter where you are and consider a suite of security products to protect what matters.

Interested in learning more about IoT and mobile security tips and trends? Stop by ProtectWhatMatters.online, and follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post Trending: IoT Malware Attacks of 2018 appeared first on McAfee Blogs.

Securing the Convergence of IT with OT

The Industrial Internet of Things (IIoT) is the leading edge of the convergence of Operational Technology (OT) with IT. This convergence begins with network connectivity but requires enhancements in operational procedures, technology, and training as well.

Beginning with the network, IT and OT use different protocols. Within the OT world, vendors have created many proprietary protocols over the past 50 years: MODBUS dates from 1969; ABB alone has over 20 protocols. IIoT vendors offer gateways to simplify and transform information before it moves to IT’s cloud for aggregation and processing. The volume of data can be huge, so IIoT gateways use compression, aggregation, and exception reporting to minimize network traffic. Gateways are Edge processors.

Operational procedures differ between IT and OT environments. The guiding principles of OT networks are two: safety, and service reliability. However, the IT information security principles are data availability, data integrity, and data confidentiality. These principles are orthogonal: they do not overlap. From an IT perspective, and industrial process is not “information” so falls out of scope for information security.

IT and OT processes could converge as they each evolve. DevOps breaks down the barriers between development and operations for more rapid deployment of new function without compromising controls governing software quality. Figure 1 shows a converged DevOps process:

 

Figure 1: Converged DevOps Process

In the OT realm, enhancements to Process Hazard Analysis are driving the evolution of Cyber Process Hazard Analysis, as shown in Figure 2.

Figure 2: Cyber Process Hazard Analysis (Cyber PHA)

The OT evolution shows two processes: on the left in blue, the ongoing asset security analysis, which influences the OT Program and Governance Model in step 5 on the right. As new threats come to light, engineers update the model which flows into a new, more secure, steady state for the environment.

OT technology is evolving as core technologies offer greater processing power, storage capacity, battery life, and network connectivity. Early OT protocols had no authentication or encryption, and could not accept over-the-air software and firmware updates securely. Newer processor chips can support these requirements, but the IIoT vendors must build these capabilities, requiring larger code bases for development and some mechanism to issue patches during operations. IIoT vendors do not have experience running bug bounty programs. They will need some way to get feedback from their customers and researchers to fix problems before they get out of hand.

Training means more than ad hoc learning as the opportunity presents itself. Information security skills are scares and growing more so. Organizations need to provide additional skills to their existing staff, and may need to rely on outsourced support to bridge the gap while those new skills come on-line. But simply handing off responsibility to a third party will not eliminate risk: the organization itself will have to enhance its operational procedures to handle patch/fix requirements in time.

At Trend Micro, we understand this complexity, so we address it from different angles. Securing the connected world is one of our highest priorities.  So far this year, we have launched a series of programs and partnerships to help IIoT manufacturers and their marketplaces. The Zero-Day Initiative (ZDI) includes Industrial Control Systems (ICT) defect reports. ZDI processed 202 SCADA HCI defects in the first half of 2018. Deep Security already has over 500 filters/virtual patches for OT protocols traveling over IP. Trend Micro offers guidance on deploying information security tools in the development cycle so the CD/CI process does not experience a disruption as security contexts change with production deployment. The IoT SDK helps IoT device manufacturers build core information security functions into devices during development, as with Panasonic’s In-Vehicle Infotainment (IVI) systems. By offering IoT vendors access to ZDI, Trend Micro extends its expertise in managing bug bounty programs to new entrants from outside the conventional IT realm. Partnerships with IIoT vendors such as Moxa extend 30 years of Trend’s information security expertise to a broad range of industrial control platforms. Trend Micro’s offering for telecommunications brings work-hardened network and server security to carriers for secure, reliable communications. Contact Trend Micro for more information about the threat landscape and available solutions.

For more information, please click here.

What do you think? Let me know by commenting below, or reach me @WilliamMalikTM .

The post Securing the Convergence of IT with OT appeared first on .

What are botnets downloading?

Spam mailshots with links to malware and bots downloading other malware are just a couple of botnet deployment scenarios. The choice of infectious payload is limited only by the imagination of the botnet operator or customer. It might be a ransomware, a banker, a miner, a backdoor, the list goes on, and you don’t need to go far for examples: take Gandcrab and Trik, or Locky and Necurs, for instance. Every day we intercept numerous file-download commands sent to bots of various types and families. Here we present the results of our botnet activity analysis for H2 2017 and H1 2018.

Methodology

Excluded from the statistics are update files downloaded by bots, since their number depends heavily on the algorithm of the particular malware in question and has an impact on the final distribution. The analysis also excludes configuration files whose download depends on the botnet algorithm and is not relevant to this article. What’s more, we only took account of unique (in terms of MD5 hash) files. The results are based on the analysis of commands from more than 60,000 different C&C associated with 150 bot families and their modifications.

Kaspersky Lab tracks the activity of botnets using Botnet Tracking, a technology that emulates infected computers (bots) to retrieve operational data about the actions of botnet operators.

The total number of unique malicious files downloaded by our bots in H1 2018 fell by 14.5% against H2 2017.

Number of unique malicious files, H2 2017 — H1 2018 (download)

After analyzing the files downloaded by the bots, we identified the most widespread families. Note that the top of the list of most “popular” downloads changes little over time. In 2018, as last year, the backdoor njRAT accounted for many downloads. Its share among all files downloaded by bots increased from 3.7% to 5.2%, meaning that more than 1 in each 20 bot-downloaded files is njRAT. This widespread distribution is due to the variety of versions of the malware and the ease of setting up one’s own backdoor, creating a low entry threshold.

H2 2017 Share H1 2018 Share
1 Lethic 17.0% njRAT 5.2%
2 Neutrino.POS 4.6% Lethic 5.0%
3 njRAT 3.7% Khalesi 4.9%
4 Emotet 3.5% Miners 4.6%
5 Miners 2.9% Neutrino.POS 2.2%
6 Smoke 1.8% Edur 1.3%
7 Cutwail 0.7% PassView 1.3%
8 Ransomware 0.7% Jimmy 1.1%
9 SpyEye 0.5% Gandcrab 1.1%
10 Snojan 0.3% Cutwail 1.1%

Most downloaded threats, H2 2017 — H1 2018

Very often, botnets are used to distribute cryptocurrency mining tools. In H1 2018 miners accounted for 4.6% of all downloaded files, a far higher figure than in H2 2017 (2.9%).

Yet cybercriminal interest in ordinary currencies remains high, as evidenced by the presence of Neutrino.POS and Jimmy in the Top 10. In H2 2017, Neutrino.POS was downloaded in 4.6% of all cases. In 2018, its share in the overall stream of downloaded files declined, but its “cousin” Jimmy helped out by adding 1.1% to the share of banking Trojans.

Distribution map of the Top 10 downloaded threats, H2 2017 (download)

In H1 2018, the Trojan Khalesi was in third place in our ranking, accounting for 4.9% of downloaded files. But while in 2017 the Remcos, BetaBot, Smoke, and Panda bots were involved in downloading the Trojan, in 2018 Khalesi was downloaded only by the spam bot Lethic.

On a separate note, the H1 2018 Top 10 features Mail PassView, a legal password recovery tool for various email clients. Distributed via the Remcos backdoor, it is likely used to obtain passwords for victim mailboxes.

The Cutwail, Lethic, and newly rebranded Emotet bots are also firmly rooted in the Top 10.

Compared to H2 2017, the number of ransomware encryptors downloaded by bots has risen this year. Despite the overall decline in the distribution of ransomware programs, botnet operators continue to deliver them to victims. According to our data, most ransomware programs in 2017 were downloaded by the Smoke bot, but in 2018 top spot has been seized by Nitol. GandCrab ransomware is a newbie in the Top 10 most downloaded families of 2018. It appeared in 2018 and was immediately deployed and distributed by several botnet operators, most actively by Trik.

Distribution map of the Top 10 downloaded threats, H1 2018 (download)

In terms of behavior, the clear leaders in both halves are Trojans with such diverse capabilities that it’s difficult to pinpoint their “specialization.” A significant proportion is made up of bankers and backdoors ensuring maximum theft of important information. What’s more, last year’s most common malware included a large number of spam bots, largely due to the above-mentioned Lethic.

Distribution of downloaded files by behavior, H2 2017 — H1 2018 (download)

Most “versatile”

Among the families under observation, we identified the most “versatile” — that is, those downloading the largest number of different files. Such diversity can be the result of several factors:

  • Different botnets from the same family are managed by different operators with varying objectives.
  • Operators “lease” their botnets, allowing them to be used to distribute malware.
  • A botnet changes its “specialization” (for example, Emotet turned from a banking Trojan turned into a spam bot)

In 2018, as in 2017, the most “versatile” bots were Hworm, Smoke, and BetaBot (a.k.a. Neurevt).

Distribution of downloaded files by behavior for Hworm, H2 2017 — H1 2018 (download)

Distribution of downloaded files by behavior for Smoke, H2 2017 — H1 2018 (download)

Distribution of downloaded files by behavior for Betabot, H2 2017 — H1 2018 (download)

As we already mentioned, hidden mining software is very popular, as confirmed by the statistics. Despite the variety of downloaded malware, miners invariably end up in the Top 3.

Backdoors also feature heavily due to the wide-ranging options they provide for cybercriminals, from saving screenshots and keystrokes to direct control over the target device.

Most “international”

In terms of territorial distribution of control servers, the backdoor Njrat unsurprisingly claimed the “most international” prize, with C&C centers in 99 countries. This geographical scope is down to the ease of configuring a personal backdoor, allowing anyone to create their own botnet with minimal knowledge of malware development.

Distribution map of Njrat C&C centers, H2 2017 — H1 2018 (download)

Next come the backdoors DarkComet and NanoCore RAT. They share silver and bronze, having C&Cs in almost 80 countries worldwide. Despite the arrest of the creator of NanoCore, he managed to sell the source code of his privately developed RAT, which is now actively used by other cybercriminals.

Distribution map of DarkComet C&C centers, H2 2017 — H1 2018 (download)

Distribution map of NanoCore RAT C&C centers, H2 2017 — H1 2018 (download)

A look at the geography of infection targets reveals that another backdoor, QRAT, has the largest reach. In H2 2017, we registered infection attempts in 190 countries, and this year QRAT added two more countries, bringing the total to 192.

QRAT distribution map, H2 2017 — H1 2018 (download)

This extensive scope is due to the SaaS (Software-as-a-Service), or rather MaaS (Malware-as-a-Service), distribution model QRAT can be purchased for 30 or 90 days, or for one year. Its cross-platform nature (the malware is written in Java) also plays a role.

Conclusion

By intercepting bot commands, we can track the latest trends in the world of virus writers and provide maximum protection for our users.

Here are the main trends that we identified from analyzing files downloaded by bots:

  • The share of miners in bot-distributed files is increasing, as cybercriminals have begun to view botnets as a tool for mining cryptocurrency.
  • Backdoors consistently make up the bulk of downloads; that is, botnet operators are keen to gain maximum possible control over infected devices.
  • The number of downloaded droppers is also on the rise, indicative of attacks that are multistage and growing in complexity.
  • The share of banking Trojans among bot-downloaded files in 2018 decreased, but it’s too soon to speak of an overall reduction in number, since they are often delivered by droppers (see above).
  • Increasingly, botnets are leased according to the needs of the customer, and in many cases it is difficult to pinpoint the “specialization” of the botnet.

McAfee Opens State-of-the-Art Security Research Lab in Oregon

McAfee’s Advanced Threat Research team has operated from several locations around the world for many years. Today we are pleased to announce the grand opening of our dedicated research lab in the Hillsboro, Oregon, office near Portland. Although we have smaller labs in other locations, the new McAfee Advanced Threat Research Lab was created to serve two purposes. First, it gives our talented researchers an appropriate work space with access to high-end hardware and electronics for discovery, analysis, automation, and exploitation of vulnerabilities in software, firmware, and hardware. Second, the lab will serve as a demo facility, where the Advanced Threat Research team can showcase current research and live demos to customers or potential customers, law enforcement partners, academia, and even vendors.

The lab has been a labor of love for the past year, with many of the team members directly contributing to the final product. Visitors will have the unique opportunity to experience live and recorded demos in key industry research areas, including medical devices, autonomous and connected vehicles, software-defined radio, home and business IoT, blockchain attacks, and even lock picking! Our goal is to make vulnerability research a tangible and relatable concept, and to shed light on the many security issues that plague nearly every industry in the world.

Much of the research highlighted in the lab has been disclosed by McAfee. Links to recent disclosures from the Advanced Threat Research team:

Articles

Podcasts

Security researcher Douglas McKee prepares his demo of hacking a medical patient’s vitals. 

Onsite visitors will have the opportunity to solve a unique, multipart cryptographic challenge, painted on our custom mural wall in the lab. Those who are successful will receive an Advanced Threat Research team challenge coin! We will soon have an official video from the lab’s opening event online.

The post McAfee Opens State-of-the-Art Security Research Lab in Oregon appeared first on McAfee Blogs.

McAfee ATR Team Discovers New IoT Vulnerability in Wemo Insight Smart Plugs

From connected baby monitors to smart speakers — IoT devices are becoming commonplace in modern homes. Their convenience and ease of use make them seem like the perfect gadgets for the whole family, but their poor security standards also make them conveniently flawed for someone else: cybercriminals. As a matter of fact, our McAfee Labs Advanced Threat Research team has uncovered a flaw in one of these IoT devices: the Wemo Insight Smart Plug, which is a Wi-Fi–connected electric outlet.

Once our research team figured out how exactly the device was vulnerable, they leveraged the flaw to test out a few types of cyberattacks. The team soon discovered an attacker could leverage this vulnerability to turn off or overload the switch. What’s more – this smart plug, like many vulnerable IoT devices, creates a gateway for potential hackers to compromise an entire home Wi-Fi network. In fact, using the Wemo as a sort of “middleman,” our team leveraged this open hole in the network to power a smart TV on and off.

Now, our researchers have already reported this vulnerability to Belkin on May 21st. However, regardless if you’re a Wemo user or not, it’s still important you take proactive security steps to safeguard all your IoT devices. Start by following these tips:

  • Keep security top of mind when buying an IoT device. When you’re thinking of making your next IoT purchase, make sure to do your research first. Start by looking up the device in question’s security standards. A simple Google search on the product, as well as the manufacturer, will often do the trick.
  • Change default passwords and do an update right away. If you purchase a connected device, be sure to first and foremost change the default password. Default manufacturer passwords are rather easy for criminals to crack. Also, your device’s software will need to be updated at some point. In a lot of cases, devices will have updates waiting from them as soon as they’re taken out of the box. The first time you power up your device, you should check to see if there are any updates or patches from the manufacturer.
  • Keep your firmware up-to-date. Manufacturers often release software updates to protect against these potential vulnerabilities. Set your device to auto-update, if you can, so you always have the latest software. Otherwise, just remember to consistently update your firmware whenever an update is available.
  • Secure your home’s internet at the source. These smart home devices must connect to a home Wi-Fi network in order to run. If they’re vulnerable, they could expose your network as a result. Since it can be challenging to lock down all the IoT devices in a home, utilize a solution like McAfee Secure Home Platform to provide protection at the router-level.

And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post McAfee ATR Team Discovers New IoT Vulnerability in Wemo Insight Smart Plugs appeared first on McAfee Blogs.

‘Insight’ into Home Automation Reveals Vulnerability in Simple IoT Product

Eoin Carroll, Charles McFarland, Kevin McGrath, and Mark Bereza contributed to this report. 

The Internet of Things promises to make our lives easier. Want to remotely turn lights and appliances on and off and monitor them online? A “smart plug,” a Wi-Fi–connected electric outlet, is one simple method. But IoT devices can turn into attack vectors if they are not properly secured.

The McAfee Labs Advanced Threat Research team is committed to uncovering security issues in both software and hardware to help their developers provide safer products for businesses and consumers. We recently investigated a consumer product produced by Belkin. Our research into the Wemo Insight Smart Plug led to the discovery of an unreported buffer overflow in the libUPnPHndlr.so library. This flaw, CVE-2018-6692, allows an attacker to execute remote code. Following our responsible disclosure policy, we reported this research to Belkin on May 21.

Can this vulnerability lead to a useful attack? A smart plug by itself has a low impact. An attacker could turn off the switch or at worst possibly overload the switch. But if the plug is networked with other devices, the potential threat grows. The plug could now be an entry point to a larger attack. Later in this report, we will look at one possible attack.

Exploring the attack surface

Following the manual’s advice, the team used the Wemo phone application to set up the smart plug. We were able to remotely turn the outlet on and off. We then tested the software, including port scanning, monitoring normal network traffic, and reading online research. The Wemo listens on Universal Plug and Play (UPnP) ports TCP 49152 and 49153. The manuals, disassembly images, and the general-purpose programming language (GPL) were all online; they provided information on CPU architecture, the operating system, and applications.

We turned to the hardware and disassembled the device. We identified chips on the main board, found headers for communicating with the device, and pulled the memory off flash. Our online research provided datasheets for each of the chips on the board.

We found universal asynchronous receiver-transmitter (UART) pads on the board and confirmed them with the documentation. We soldered wires to these headers to discover if they were actively transmitting. To test communication with the device, we used an Exodus XI Breakout board, shown below:

After brute-forcing the baud rate, we were able to get debug information via the UART interface. The UART also provided a login prompt; however, neither online research nor simple guessing led us to a working password.

Extraction and firmware analysis

The flash chip discovered on the board was a Maxronix MX25L12835F, which is supported by flashrom, a well-known open-source tool for extracting firmware. Using flashrom and the XI Breakout board, we extracted the firmware from the Wemo device. After we obtained the original firmware image shipped with the device, we updated it using the Wemo mobile application. Once the device was updated, we again extracted the firmware from the device, providing us with a second image. We ran basic sanity checks with the new firmware to ensure our earlier software reconnaissance had not changed.

With the firmware extracted, we analyzed the firmware using binwalk, an open-source binary analysis tool. Binwalk extracted the file system from the firmware for further inspection. Access to the file system allowed us to review system configuration and access binaries.

Finding a vulnerability 

Network or remote vulnerabilities are more dangerous than local flaws, so we took a close look at the UPnP ports listening on the local network. During this testing phase our lead analyst was taking a class on Exodus Intelligence Embedded Exploitation. One of the class instructors, Elvis Collado (@b1ack0wl) was developing a UPnP fuzzer and offered to assist our efforts. Using this tool we started fuzzing the open UPnP ports, while monitoring the UART interface on the Wemo. After a short time we saw a crash on the UART interface.

11:37:16.702 stuntsx0x46ac6 STUN client transaction destroyed
sending SIGSEGV to wemoApp for invalid write access to
464d4945 (epc == 2ac1fb58, ra == 2ac1fccc)
Cpu 0
$ 0 : 00000000 00000001 0000006d 464d4945
$ 4 : 31d2e654 31d2e770 00000003 00000001
$ 8 : 0000007c fffffff8 00000007 00000002
$12 : 00000200 00000100 00000807 00000800
$16 : 31d2e6f0 31d2e898 004a1cb8 00000002
$20 : 31d2e638 31d2e6c0 004a1388 31d2e640
$24 : 00000400 2ac1fb30
$28 : 2ac77d40 31d2e600 31d2e648 2ac1fccc
Hi : 00000008
Lo : 00000000
epc : 2ac1fb58 Tainted: P
ra : 2ac1fccc Status: 0100fc13 USER EXL IE
Cause : 8080000c
BadVA : 464d4945
PrId : 0001964c
Modules linked in: softdog rt_rdm rt2860v2_ap(P) raeth
Process wemoApp (pid: 2157, threadinfo=80fa0000, task=802c87f0)
Stack : 2a0000d0 fffffffe 31d2e6f0 31d2e770 31d2e76f 31d2e6f0 31d2e6f0 31d2e770
00000000 31d2e604 00000000 00000000 2ac77d40 00000000 4f464751 4a484d4c
4e444241 47454f49 50464658 45414d42 43445044 464d4945 5552414c 46495048
4b524141 41445a4f 44534e4a 4e4e494c 44434357 494a4855 44515455 44494b45
55584a44 584e4f52 545a5247 51545954 595a4c42 4e594a45 484f5158 46474944

Call Trace:

Code: 80a20000 50480004 a0600000 <5440fffa> a0620000 a0600000 10a00006 24840004 24a50001
thready: Destructor freeing name “ChildFDTask”.
Aborted

After repeating and closely observing the experiment several times, we determined that the crash was caused by the following packet:

POST /upnp/control/basicevent1 HTTP/1.1
Host: 192.168.225.183:49154
User-Agent: python-requests/2.9.1
Accept: */*
Connection: keep-alive
SOAPAction: “urn:Belkin:service:basicevent:1#UpdateInsightHomeSettings”
Content-Type: text/xml
Accept-Encoding: gzip, deflate
Content-Length: 3253

<?xml version=”1.0″ ?><s:Envelope s:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/”><s:Body><b1ack0wl_ns:UpdateInsightHomeSettingsxmlns:b1ack0wl_ns=”urn:Belkin:service:basicevent:1″><EnergyPerUnitCost>210</EnergyPerUnitCost><Currency>236</Currency><EnergyPerUnitCostVersion>KWWZWIVYBQZKDGSSAAPBCQVQQFAVYZEOEUFIDXXQPDYGESTOD
GIJFERXZNMYAFJQLUZPSIJXFQSPADCRIVHDAJLLPQMPLAVECIQUWLXDLIGPLBKCROGPOCVUI
KTSLIIXULOEBVFKWIERCFGHWHCBBDLWFBKBZXAVGRKTDALDNRPOFQJDXAEOC(…snip…)XHU
OUZPCHUBFGLLWSJBFYFOMCGZZMJIQIUVCDETFBRBZVDVKNBVZFBRSVBSZPAYKZYNQZEQPDV
DWSZNDUPUDCPAVWNFBFBTYMXTBNCWTBJPKORUBHBSCQBPOPOBZNVADMGWRI
</EnergyPerUnitCostVersion></b1ack0wl_ns:UpdateInsightHomeSettings></s:Body></s:Envelope>

For space reasons some of the payload has been removed. (The original data in “EnergyPerUnitCostVersion” was 2,828 characters.) After examining the crash data and the packet, this appears to be a standard buffer overflow, in which data is being overwritten onto the stack. We continued fuzzing, now focused on the “EnergyPerUnitCost” field and found we needed only 32 characters to crash the application.

Although the crash dump provides us with a lot of good information, there is still a lot we do not know. For example, the crash occurs in the “WemoApp” and provides us an offset, but what is the base address of this library? What has been overwritten on the stack? Without access to the application during runtime these questions are difficult to answer. Because we obtained the file system earlier, we could statically analyze the WemoApp binary; but we would still be unable to determine the exact point of the crash easily.

To answer these questions we needed to take one of two paths. We could virtualize the Wemo firmware or binary to continue testing; or if we could determine the root password on the UART interface, there is a chance we could debug on the device itself. Generally, virtualizing firmware is not simple and can sometimes lead to inaccurate test results. It is better to debug on the device. With all the information we found during reconnaissance, it seemed promising that we could bypass the root password. (We did spend some time attempting to virtualize the WemoApp—with no success.)

Bypassing the root password

From the extracted file system, we learned the Wemo runs the embedded Linux system OpenWRT, with the user account information held in either the standard /etc/passwd or /etc/shadow files. We extracted the hash for the root password from /etc/passwd and submitted it to a cracking rig. This method proved ineffective in a reasonable amount of time.

With our ability to read the flash chip we had a good chance to write to the chip. Barring any checksum or validations done on the firmware, we might be able to replace the /etc/passwd file with a known password.

To test this theory, we would have to repack the firmware. Since the GPL for the Wemo is public, we chose to use the same tools used by the developers. Using the GPL, we compiled the same version of squash tools 3.0 with Izma and repackaged the firmware file system with a modified /etc/passwd file. We added padding to ensure the firmware section was the same size as the original. We then used “dd” to insert the new file system segment into the firmware binary. During this process, we discovered that using binwalk to extract the firmware prevented us from correctly repackaging the firmware. We used “dd” with the information provided by binwalk to extract the correct section of the firmware binary for repackaging.

With a new firmware binary in hand, we used the XI Breakout board and flashrom to write the firmware to the flash chip on the board. After rebooting the device, we were able to log in using the new password.

Analyzing the crash 

With root access on the Wemo, we could gather more information about the crash during the UPnP fuzzing. First, we needed to compile the tools required to perform more in-depth analysis for this specific architecture. Using the GPL, we compiled gdbserver and gdb for the device. The Wemo had a large amount of installed tools, such as “wget,” making it simple to add files. We downloaded and executed the tools from the /tmp directory.

After a large amount of trying, we failed to get gdb running directly or remotely with the device. So we used gdbserver, in conjunction with Interactive Disassembler Pro, for all debugging. With the debugger connected, we sent the packet causing the crash and saw the exact location of the crash. A segmentation fault occurred at address 0x2AC15B98. From the memory layout from the Linux “proc” directory, we determined his memory address resides in library libUPnPHndlr.so.

2abf3000-2ac4d000 r-xp 00000000 1f:02 82 /rom/lib/libUPnPHndlr.so

Because the crash was caused by a UPnP packet, it was logical to find the crash inside this library . With the base address 0x2abf3000, we calculated the offset for static analysis in IDA to be 0x22b98.  At this address, we found the following:

LOAD:00022B70  # =============== S U B R O U T I N E =======================================

LOAD:00022B70

LOAD:00022B70

LOAD:00022B70                 .globl TokenParser

LOAD:00022B70 TokenParser:                             # CODE XREF: ProcessEnergyPerunitCostNotify+84↓p

LOAD:00022B70                                          # DATA XREF: LOAD:00004210↑o …

LOAD:00022B70                 beqz    $a1, locret_22BC0

LOAD:00022B74                 move    $a3, $zero

LOAD:00022B78                 move    $a3, $zero

LOAD:00022B7C                 b       loc_22BB4

LOAD:00022B80                 li      $t0, 0x7C  # ‘|’

LOAD:00022B84  # —————————————————————————

LOAD:00022B84

LOAD:00022B84 loc_22B84:                               # CODE XREF: TokenParser+28↓j

LOAD:00022B84                 addiu   $a1, 1

LOAD:00022B88                 addiu   $v1, 1

LOAD:00022B8C

LOAD:00022B8C loc_22B8C:                               # CODE XREF: TokenParser+48↓j

LOAD:00022B8C                 lb      $v0, 0($a1)

LOAD:00022B90                 beql    $v0, $t0, loc_22BA4

LOAD:00022B94                 sb      $zero, 0($v1)

LOAD:00022B98                 bnezl   $v0, loc_22B84

LOAD:00022B9C                 sb      $v0, 0($v1)

LOAD:00022BA0                 sb      $zero, 0($v1)

LOAD:00022BA4

LOAD:00022BA4 loc_22BA4:                               # CODE XREF: TokenParser+20↑j

LOAD:00022BA4                 beqz    $a1, locret_22BC0

LOAD:00022BA8                 addiu   $a0, 4

LOAD:00022BAC                 addiu   $a1, 1

LOAD:00022BB0                 addiu   $a3, 1

LOAD:00022BB4

LOAD:00022BB4 loc_22BB4:                               # CODE XREF: TokenParser+C↑j

LOAD:00022BB4                 slt     $v0, $a3, $a2

LOAD:00022BB8                 bnezl   $v0, loc_22B8C

LOAD:00022BBC                 lw      $v1, 0($a0)

LOAD:00022BC0

LOAD:00022BC0 locret_22BC0:                            # CODE XREF: TokenParser↑j

LOAD:00022BC0                                          # TokenParser:loc_22BA4↑j

LOAD:00022BC0                 jr      $ra

LOAD:00022BC4                 move    $v0, $a3

LOAD:00022BC4  # End of function TokenParser

 

Because the developers left the binary unstripped, we can name this function TokenParser. The segmentation fault occurs at a branch instruction; however, in MIPS the delay instruction is executed before the branch occurs. Thus the instruction at 0x22B9C is causing the crash. Here the application attempts to load what is at the address stored in $v1 and place it in $v0. Taking a look at the registers, we find the data from our packet in XML tags “EnergyPerUnitCostVersion” is in $v1, leading to an “invalid write access” segmentation fault error.

After statically analyzing the function, it appears to copy data from one section to another, looking three times for a 0x7C or “|” character. If it never finds the “|,” it keeps copying into a statically defined buffer. To fully understand why the overwrite occurs, let’s take a look at the stack as we step through the function:

2EF17630 2AC692F0 MEMORY:2AC692F0
2EF17634 00000000 MEMORY:saved_fp
2EF17638 34333231 MEMORY:34333231 ← previously copied data
2EF1763C 00000035 MEMORY:retaddr+31  ← next byte will be written at 0x2EF1763D
2EF17640 00000000 MEMORY:saved_fp  ← zeroed out memory prepared for the copy
2EF17644 00000000 MEMORY:saved_fp
2EF17648 00000000 MEMORY:saved_fp
2EF1764C 00000000 MEMORY:saved_fp
2EF17650 2EF17638 MEMORY:2EF17638 ← start writing at this address; can be overwritten

As the function copies data onto the stack, it eventually copies over the address for the original buffer. Once this address is overwritten, the function attempts to write the next byte at the new value, in this case is an invalid address. This overflow gives an attacker two exploitable vectors: a write-what-where condition allows an attacker to write data to an arbitrary location in memory; by continuing to overwrite data on the stack, an attacker can overwrite the $RA register or return address for the calling function, providing the attacker control of the execution flow.

Writing the exploit

Now that that we understand the vulnerability, can we exploit it? Because this is a standard buffer overflow, we need to answer two questions. How much room is available on the stack, and are there any “bad” bytes that cannot make it onto the stack? To determine the available room, we can examine how much of the payload makes it onto the stack if we repair the address overwritten on the stack with a valid address. We learned only 91 bytes can be written onto the stack.

The next step is to determine if there are any “bad” bytes. After running a few tests, we noticed that only ASCII characters can make it onto the stack. Before the vulnerable code is executed, the packet is parsed by the open-source XML parser “mxml.” This library follows the standard of allowing only ASCII and Unicode characters to exist between tags.

This standard is very problematic for both shellcode and return-oriented programming (ROP) techniques because both memory address and shellcode tend to use mostly nonreadable characters. We could use several techniques to combat room on the stack; however, due to the hard limitation on characters that will pass through the XML sanitization process, it would be best to use functions that are already loaded into memory. One method that does not require extensive shellcode is to use a “return to libc” attack to execute the system command. Because the system call typically takes a string as a parameter, this might pass through the filter. Because the Wemo does not use address space layout randomization, if we use ROP it would be theoretically possible to make a call to system without needing to pass additional shellcode through the XML filter.

We still face a major challenge: Only addresses comprising entirely ASCII characters can pass through the XML filter. This drastically limits the potential for finding usable gadgets. We used IDA to see where libc and system are loaded into memory, and found two implementations: in libuClibc-0.9.33.2.so at address 0x2B0C0FD4; and in libpthread-0.9.33.2.so at address 0x2AD104F4. However, neither of these addresses meet the requirements to pass through the XML filter. Thus even if we could create an ROP chain, we would not be able to send just the address for system in the packet.

Addresses with bad characters are not a new problem for exploit development. One of the most common bypasses is to use addition or subtraction ROP gadgets to create the required address in a register and call that register. Again, however, we face the limitation on which operands can be used for this addition or subtraction equation due to the XML filter.

After studying the memory layout, we discovered that libuClibc-0.9.33.2.so sits at a memory location with addresses that can bypass the XML filter. We were fortunate that this is a large library, providing a decent list of addresses, because it is the only library in such a space. With this discovery, the team created a tool to assist with the creation of this exploit. The tool pulls out all possible ROP gadgets with usable memory addresses and determines if an addition or subtraction equation could call one of the two system calls found in memory, using only the values that will bypass the filter. The address for system in libuClibc-0.9.33.2.so, 0x2B0C0FD4, did not have any usable operands. However, 0x2AD104F4 did. We found several “filter-proof” operands that when added together equaled 0x2AD104F4.

We employed our tool’s output for all possible ROP gadgets that bypass the filter to build an ROP chain, which uses an addition instruction to create the final address for system and stores it in $s0. After the addition, another gadget moves the address for system into $t9 and calls system. This final gadget also moves an address that can be controlled from the stack into the register holding the parameter for the system call. The entire ROP chain consists of only three gadgets, which easily fit in the stack space provided by the buffer overflow. 

 

Piecing everything together 

Earlier we discovered two attack techniques that can be used with this vulnerability: a write-what-where, and overwriting the return address on the stack. Each packet sent can use each technique once. To get a parameter to the system call, we must use write-what-where to place the parameter in a writable memory address and pass this address to system. Fortunately, this vulnerable application sets aside a large amount of writable memory that is never used, and in a range accessible to our limited set of addresses that bypass the filter. Unfortunately, the ROP chain that calls system requires the use of write-what-where to handle extra instructions in one of the ROP gadgets. This means that two packets are required to execute the exploit: one to write the parameter for system into memory, and a second to make the call to system. Thus it is important that the first packet exits cleanly and does not crash the program.

One way to execute cleanly is to use three well-placed pipes (“|”) inside the payload to stop writing and exit TokenParser at the appropriate time. It is also important to not overwrite the RA pointer so the program can continue normal execution after the packet is received. Then the second packet is sent containing the ROP chain calling system with the address of the parameter written by the previous packet. 

Payload 

With the discovery of a valid ROP chain that can call system, we must decide what system should call. Because system executes as root, we can gain complete control of the device. Our research has showed that the device has many Linux commands installed. We leveraged this earlier with wget to copy gdbserver to the device. An attacker could also call wget from system to download and execute any script. We explored further for installed applications and found NetCat, which could allow an attacker to write a script to create a reverse shell. An attacker could download a script using wget, and execute the script containing a NetCat command to create a reverse shell. We tested and proved this is one simple, effective method, opening a reverse shell as root. Attackers could choose many other methods to leverage this exploit and execute code. The following video demonstrates this exploit working with a reverse shell.

To illustrate, the team wrote an attack scenario. After the plug is compromised, it could use the built-in UPnP library to poke a hole in the network router. This hole creates a backdoor channel for an attacker to connect remotely, unnoticed on the network. In the following video, we used a remote shell to control a TCL smart TV connected to the network. The Roku API implementation on the TV uses simple unencrypted HTTP GET/POST requests to issue commands and does not authenticate the machine sending these commands, making remote control trivial. Using the Wemo as a middleman, the attacker can power the TV on and off, install or uninstall applications, and access arbitrary online content. Smart TVs are just one example of using the Wemo to attack another device. With the attacker having established a foothold on the network and able to open arbitrary ports, any machine connected to the network is at risk. Because attacks can be conducted through the Wemo and the port mappings generated using this exploit are not visible from the router’s administration page, the attacker’s footprint remains small and hard to detect.

Conclusion 

Discoveries such as CVE-2018-6692 underline the importance of secure coding practices on all devices. IoT devices are frequently overlooked from a security perspective; this may be because many are used for seemingly innocuous purposes such as simple home automation. However, these devices run operating systems and require just as much protection as desktop computers. A vulnerability such as we discovered could become the foothold an attacker needs to enter and compromise an entire business network.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through analysis and responsible disclosure, we aim to guide product manufacturers toward a more comprehensive security posture.

The post ‘Insight’ into Home Automation Reveals Vulnerability in Simple IoT Product appeared first on McAfee Blogs.

80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals

The author thanks Shaun Nordeck, MD, for his assistance with this report.

With the explosion of growth in technology and its influence on our lives, we have become increasingly dependent on it. The medical field is no exception: Medical professionals trust technology to provide them with accurate information and base life-changing decisions on this data. McAfee’s Advanced Threat Research team is exploring these devices to increase awareness about their security.

Some medical devices, such as pacemakers and insulin pumps, have already been examined for security concerns. To help select an appropriate target for our research, we spoke with a doctor. In our conversations we learned just how important the accuracy of a patient’s vital signs is to medical professionals. “Vital signs are integral to clinical decision making” explained Dr. Shaun Nordeck. Bedside patient monitors and related systems are key components that provide medical professionals with the vital signs they need to make decisions; these systems are now the focal point of this research.

Exploring the attack surface

Most patient monitoring systems comprise at minimum of two basic components: a bedside monitor and a central monitoring station. These devices are wired or wirelessly networked over TCP/IP. The central monitoring station collects vitals from multiple bedside monitors so that a single medical professional can observe multiple patients.

With the help of eBay, we purchased both a patient monitor and a compatible central monitoring station at a reasonable cost. The patient monitor monitored heartbeat, oxygen level, and blood pressure. It has both wired and wireless networking and appeared to store patient information. The central monitoring station ran Windows XP Embedded, with two Ethernet ports, and ran in a limited kiosk mode at start-up. Both units were produced around 2004; several local hospitals confirmed that these models are still in use.

The two devices offer a range of potential attack surfaces. The central monitoring station operates fundamentally like a desktop computer running Windows XP, which has been extensively researched by the security community. The application running on the central monitoring station is old; if we found a vulnerability, it would likely be tied to the legacy operating system. The patient monitor’s firmware could be evaluated for vulnerabilities; however, this would affect only one of the two devices in the system and is the hardest vector to exploit. This leaves the communication between the two devices as the most interesting attack vector since if the communication could be compromised, an attack could possibly be device independent, affecting both devices by a remote attack. Given this possibility, we chose networking as the first target for this research. Dr. Nordeck confirmed that if the information passing to the central monitoring system could be modified in real time, this would be a meaningful and valid concern to medical professionals. Thus the primary question of our research became “Is it possible in real time to modify a patient’s vitals being transmitted over the network?”

Setup

When performing a vulnerability assessment of any device, it is best to first operate the device as originally designed. Tracking vital signs is the essence of the patient monitor, so we looked for a way to accurately simulate those signs for testing. Many hardware simulators are on the market and vary drastically in cost. The cheapest and easiest vital sign to simulate turned out to be a heartbeat. For less than $100 we purchased an electrocardiogram (ECG) simulator on eBay. The following image illustrates our test network:

In our test bed, the patient monitor (left), central monitoring station (right), and a research computer (top) were attached to a standard switch. The research computer was configured on a monitor port of the switch to sniff the traffic between the central monitoring device and the patient monitor. The ECG simulator was attached to the patient monitor.

Reconnaissance

With the network configured, we turned to Wireshark to watch the devices in action. The first test was to boot only the central monitor station and observe any network traffic.

In the preceding screenshot a few basic observations stand out. First, we can see that the central station is sending User Datagram Protocol (UDP) broadcast packets every 10 seconds with a source and destination port of 7000. We can also see clear-text ASCII in the payload, which provides the device name. After collecting and observing these packets for several minutes, we can assume this is standard behavior. Because the central station is running on a Window XP embedded machine, we can attempt to verify this information by doing some quick reverse engineering of the binaries used by the application. After putting several libraries into Interactive Disassembler Pro, it is apparent that the symbols and debugging information has been left behind. With a little cleanup and work from the decompilers, we see the following code:

This loop calls a function that broadcasts Rwhat, a protocol used by some medical devices. We also can see a function called to get the amount of time to wait between packets, with the result plugged into the Windows sleep function. This code block confirms what we saw with Wireshark and gives us confidence the communication is consistent.

Having gained basic knowledge of the central monitoring station, the next step was to perform the same test on the patient monitor. With the central station powered down, we booted the patient monitor and watched the network traffic using Wireshark.

We can make similar observations about the patient monitor’s broadcast packets, including the 10-second time delay and patient data in plaintext. In these packets we see that the source port is incrementing but the destination port, 7000, is the same as the central monitoring station’s.  After reviewing many of these packets, we find that offset 0x34 of the payload has a counter that increments by 0xA, or 10, with each packet. Without potentially damaging the patient monitor, there is no good way to extract the firmware to review its code. However, the central monitoring station must have code to receive these packets. With a bit of digging through the central station’s binaries, we found the section parsing the broadcast packets from the patient monitor.

The first line of code parses the payload of the packet plus 12 bytes. If we count in 12 bytes from the payload on the Wireshark capture, we can see the start of the patient data in clear text. The next function called is parse_logical_name, whose second parameter is an upper limit for the string being passed. This field has a maximum length of 0x20, or 32, bytes. The subsequent code handles whether this information is empty and stores the data in the format logical_name. This review again helps confirm what we see in real time with Wireshark.

Now that we understand the devices’ separate network traffic, we can look at how they interact. Using our network setup and starting the ECG simulator we can see the central monitor station and the patient monitor come to life.

With everything working, we again use Wireshark to examine the traffic. We find a new set of packets.

In the preceding screen capture we see the patient monitor at IP address 126.4.153.150 is sending the same-size data packets to the central monitoring station at address 126.1.1.1. The source port does not change.

Through these basic tests we learn a great deal:

  • The two devices are speaking over unencrypted UDP
  • The payload contains counters and patient information
  • The broadcast address does not require the devices to know each other’s address beforehand
  • When the data is sent distinct packets contain the waveform

Attacking the protocol

Our reconnaissance tells us we may have the right conditions for a replay attack. Such an attack would not satisfy our goal of modifying data in real time across the network; however, it would provide more insight about the requirements and may prove useful in reaching our goal.

After capturing the packets from the simulated heartbeat, we attempted to replay the captures using Python’s Scapy library. We did this with the patient monitor turned off and the central monitoring station listening for information. After several attempts, this test was unsuccessful. This failure shows the system expects more than just a device sending data packets to a specific IP address.

We examined more closely the packets that are sent before the data packets. We learned that even though the packets are sent with UDP, some sort of handshake is performed between the two devices. The next diagram describes this handshake. 

 

In this fanciful dialog, CMS is the central monitoring system; PM is the patient monitor.

To understand what is happening during the handshake, we can relate each phase of this handshake to that of a TCP three-way handshake. (This is only an analogy; the device is not actually performing a TCP three-way handshake.)

The central monitoring station first sends a packet to port 2000 to the patient monitor. This can be considered the “SYN” packet. The patient monitor responds to the central station; notice it responds to the source port of the initial request. This can be considered the “SYN,ACK.” The central station sends the final “ACK,” essentially completing a three-way (or three-step) handshake. Directly following this step, the patient monitor sends another packet to the initial port of the “SYN” packet. The central monitor responds to the patient monitor on port 2000 with a new source port. Immediately following, we see the data packets being sent to the new source port, 3627, named in the previous exchange.

This exam provides insight into why the replay attack did not work. The central station defines for each connection which ports will be open for the incoming data; we need to consider this when attempting a replay attack. Modifying our previous Scapy scripts to account for the handshake, we retested the replay attack. With the new handshake code in place, the test still failed. Taking another look at the “SYN,ACK” packets provides a potential reason for the failure.

At offset 0x3D is a counter that needs to be incremented each time one of these packets is sent. In this case the patient monitor’s source IP address is embedded in the payload at offsets 0x2A and 0x30. This embedded IP address is not as important for this attack because during the replay our scripts can become the patient monitor’s IP; however, this will become more important later. The newly discovered counter needs to be accounted for and incremented.

Emulating a patient monitor

By taking these new findings into account our replay attack becomes successful. If we can observe a certain ECG pattern, we can play it back to the central monitoring station without the patient monitor on the network. Thus we can emulate the function of the patient monitor with any device. The following video demonstrates this emulation using a Raspberry Pi. We set our Scapy scripts to load after booting the Pi, which mimics the idle function of the patient monitor. When the central monitor requests information about the patient’s vitals, the Pi provides the station with an 80-beats-per-minute wave form. This also works with the other vital signs.

Impact of emulation

Although we have not yet reached our goal of real-time modification, we must consider the implications of this type of attack. If someone were to unplug the monitor of a stable patient and replace it with a device that continued to report the same stable vitals, would that cause any harm? Probably not immediately. But what if the stable patient suddenly became unstable? The central station would normally sound an alarm to alert medical personal, who could take appropriate action. However, if the monitor had been replaced, would anyone know help was needed? The patient monitor also normally sounds alarms that might be heard in and outside of the patient’s room, yet if the monitor was replaced, those alarms would be absent.

In hospitals, nurses and other personal generally make periodic checks even of stable patients. So any deception might not last long, but it might not need to. What if someone were trying to kidnap a patient? A kidnapper would alert fewer people than would be expected.

Switching from a real patient monitor to an emulator would cause a short loss in communication from the patient’s room to the central monitoring station. Is this enough to make the scenario unrealistic or not a threat? We asked Dr. Nordeck if a short loss in connection could be part of a reasonable scenario. “A momentary disconnection of the ECG would likely go unnoticed as this happens often due to patient movement or changing clothes and, as long as it is reconnected, will be unlikely to cause an alert,” he said.

Modifying vitals in real time

Although emulating the patient monitor is interesting, it did not accomplish our goal of making real-time modifications. Using what we learned while testing emulation, could we perform real-time injection? To answer this question, we must first understand the difference between emulation and real-time injection.

Emulation requires a deeper understanding of how the initial connection, the handshake, between the two devices occurred. When considering real-time modification, this handshake has already taken place. But an attacker would not know which port the data packets are being sent too, nor any of the other ports used in the data stream. Plus, because the real patient monitor is still online, it will constantly send data to the central monitoring station.

One way to account for these factors is to use Address Resolution Protocol (ARP) spoofing. If the patient monitor is ARP spoofed, then the attacker, instead of the central monitoring station, would receive the data packets. This step would allow the attacker to determine which ports are in use and stop the patient monitor’s data from getting to the central monitoring station. Because we have already shown that emulation works, the attacker simply has to send replacement data to the central station while appearing as the patient monitor.

For example, consider the following original packet coming from the patient monitor:

The patient monitor sends a packet with the patient’s heartbeat stored at offset 0x71 in the payload. The patient monitor in this screen capture is at IP address 126.4.153.150. An attacker can ARP spoof the patient monitor with a Kali virtual machine.

The ARP packets indicate that the central station, IP address 126.1.1.1, is at MAC address 00:0c:29:a1:6e:bf, which is actually the Kali virtual machine. Wireshark recognizes two MACs with the same IP address assigned and highlights them, showing the ARP spoof.

Next the attacker from the virtual machine at address 126.4.153.153 sends false information to the central monitoring station, still at address 126.1.1.1. In this example, offset 0x71 has been changed to 0x78, or 120. (The attacker could choose any value; the following demo videos use the heartbeat value 180 because it is more alarming.) Also notice the IP address stored in the payload, which we discovered during the reconnaissance phase. It still indicates this data is coming from the original patient monitor address, which is different from the IP address on the packet’s IP header. Due to this implementation, there is no need for the attacker to spoof their IP address for the attack to be successful.

Two videos show this modification happening in real time:

 

Impact of real-time modification

Although the monitor in the patient’s room is not directly affected, real-time modification is impactful because medical professionals use these central stations to make critical decisions on a large number of patients—instead of visiting each room individually. As long as the changes are believable, they will not always be verified.

Dr. Nordeck explains the impact of this attack: “Fictitious cardiac rhythms, even intermittent, could lead to extended hospitalization, additional testing, and side effects from medications prescribed to control heart rhythm and/or prevent clots. The hospital could also suffer resource consumption.” Dr. Nordeck explained that short changes to a heartbeat would generally trigger the nurse or technician monitoring the central station to page a doctor. The doctor would typically ask for a printout from the central station to review the rhythm. The doctor might also order an additional test, such as an EKG, to verify the rhythm. An EKG, however, would not likely capture an abnormal rhythm if it is intermittent, but the test might reveal an underlying cause for intermittent arrythmia. Should the rhythm recur intermittently throughout the day, the doctor might make treatment decisions based on this erroneous printout.

The American Heart Association and American College of Cardiology publish guidelines that hospitals are to follow, including for “intermittent cardiac rhythms,” seen in this chart:

A decision tree for treating an intermittent heart rate. Source: American Heart Association.

The first decision point in this tree asks if the patient is hemodynamically stable (whether the blood pressure is normal). This attack does not affect the bedside monitor. A nurse might retake the patient’s blood pressure, which would be normal. The next decision point following the “Yes” path is a diagnosis of focal atrial tachycardia. Regardless of the medical terms and answers, the patient is issued medication. In the case of a network attack, this is medication the patient does not need and could cause harm.

Conclusion

This research from McAfee’s Advanced Threat Research team shows it is possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and central monitoring station. For this attack to be viable, an attacker would need to be on the same network as the devices and have knowledge of the networking protocol. Any modifications made to patient data would need to be believable to medical professionals for there to be any impact.

During our research we did not modify the patient monitor, which always showed the true data; but we have proven the impact of an attack can be meaningful. Such an attack could result in patients receiving the wrong medications, additional testing, and extended hospital stays—any of which could incur unnecessary expenses.

Both product vendors and medical facilities can take measures to drastically reduce the threat of this type of attack. Vendors can encrypt network traffic between the devices and add authentication. These two steps would drastically increase the difficulty of this type of attack. Vendors also typically recommend that medical equipment is run on a completely isolated network with very strict network-access controls. If medical facilities follow these recommendations, attackers would require physical access to the network, greatly helping to reduce the attack surface.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through responsible disclosure we aim to assist and encourage the industry toward a more comprehensive security posture. As part of our policy, we reported this research to the vendor whose products we tested and will continue to work with other vendors to help secure their products.

The post 80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals appeared first on McAfee Blogs.

5 Tips To Protect Your IoT Devices

Do you think as yourself as living in a “smart home”? If you look around you may notice that you are surrounded by internet-connected, computing devices, including IP cameras, speakers, doorbells, and even refrigerators. These physical products embedded with electronics and software are generally referred to as the Internet of Things (IoT).

IoT products differ from dedicated tech devices, like computers, smartphones and tablets, in that their primary function is to do offline tasks, which are enhanced by connecting to the internet. An internet-enabled car, for instance, is still made for driving, but it can also potentially connect to the driver’s device and home electronics, make phone calls, and display cameras.

There’s no doubt that the Internet of Things can make our lives more convenient (just think how easy it is to ask an interactive speaker to place an order online), but it also opens us up to new risks. This is because most IoT devices lack built-in security features, making them vulnerable to malware and hacking.

Take the 2016 Mirai botnet attack, which took down a large part of the internet on the East Coast. This botnet was actually made up of 2.5 million compromised IoT devices, such as webcams and routers, which were infected by malware programmed to guess default passwords. The combined power of these IoT devices was then used to flood the internet’s Domain Name System servers with traffic, crippling the internet’s address book.

And since Mirai, IoT attacks have increased substantially both in number and sophistication. The IoT_Reaper malware, for instance, leveraged nine different vulnerabilities in webcams and routers to infect millions of devices, creating a massive army of “bots” that could potentially be used to launch attacks.

These threats are increasing at the same time as our thirst for more connected devices is growing. Everything from smart thermostats to interactive eyeglasses are expected to make up the 20.8 billion connected devices that are predicted to exist in consumer homes by 2020.

The more connected devices we have in our homes and lives, the more opportunities cybercriminals have to infiltrate our networks, and reach other data-rich devices. This can potentially put your private and financial information at risk, not to mention your privacy.

So, what can we as consumers do to protect our data and devices, while enjoying all the convenience that IoT brings?

Here are some important IoT Safety Tips:

  • Research before you buy—Look for devices that have built-in security features, when possible, and check other users’ reviews before you buy to see if there are any issues, such as known exploits or vulnerabilities, that you should know about.
  • Change Default Passwords—As soon as you bring a new connected device home make sure you change the default password to something hard to guess. This is because cybercriminals often know these default settings and can use them to access your devices. If the device has advanced security options, take advantage of them.
  • Keep them separate—Consider setting up a separate network just for your IoT devices. This way, even if a device is compromised the attacker will not be able to leapfrog to other data-rich devices on the same network, like computers and smartphones. Check your router’s user manual to learn how to setup a second, or “guest” network. Or, consider investing in a network that has built-in protection for IoT devices. Security is now being integrated into home routers, providing first-line protection for all the devices connected to the network.
  • Keep your firmware up-to-date—Manufacturers often release software updates to protect against potential vulnerabilities and upgrade features. Set your device to auto-update, if you can, so you always have the latest software.
  • Use comprehensive security software—Keep all your computers and devices protected by using robust security software that can help safeguard your private information and stop known threats.

Looking for more mobile security tips and trends? Be sure to follow @McAfee Home on Twitter, and like us on Facebook.

The post 5 Tips To Protect Your IoT Devices appeared first on McAfee Blogs.

5 Screen Time Principles to Establish When Your Kids are Still Babies

Screen time — how much is too much — is a red-hot issue right now and for good reasons. Now, with several decades of a technology-saturated lifestyle behind us, the research repeatedly tells us: Too much screen time can be detrimental to kids.

Balance is the new black when it comes to screen time. However, if you are parenting younger children, you may be confused by the mixed signals surrounding you. Studies state the risks, yet everywhere you turn, the retail shelves are brimming with digital products targeting babies, toddlers, and preschoolers. Which way should a parent turn?

The Wee Ones

The American Academy of Pediatrics (AAP) recommends keeping all screens off around babies and toddlers younger than 18 months. They note that a small amount of screen time is acceptable for older toddlers and that children two and older should get no more than an hour of screen time per day as long as it’s quality shows or games.

So the focus remains on balance for the entire family. It’s tempting to use technology as a babysitter when your kids are younger (guilty party, right here!). However, the more we know about the downside of too much screen time, the more motivating it is to curb it. If you are parenting a younger crew, here are some basics to keep in mind if you want to stay on top of their screen time.

5 Tech Principles for Young Families

  1. Set goals early. When your kids are still babies, sit down with your partner and develop a healthy screen time plan. What is healthy for your child? What works in the context of your family? If you decide on 30 minutes a day of a specific program or interactive game, stick to that limit. As difficult as it can be at times, try to avoid the temptation to calm a crying baby or toddler with television, tablet, or a handheld game. Options to screens depending on age might include books, a stroller ride, exploring outdoors, self-directed play, music, touch/sensory toys, face-to-face play. Every age group will vary on acceptable screen time. When kids get older, establish family ground rules and attach consequences to those rules. Be sure you do your part, parent. Don’t leave kids unsupervised with their technology, keep screens out of bedrooms, and monitor their connected devices and online activity. Revisit your ground rules from time to time and make sure your child not only understand the rules but also why they are necessary. When age-appropriate, be sure to include kids in amending ground rules, so they feel the rules are in place to protect a privilege and not a punishment.
  2. Limit and co-view content. The AAP recommends for children ages two to five years of age, limit screen use to one hour per day of high-quality programs. Also, parents should consider co-viewing media with children to help them understand what they are seeing and apply it to the world around them.
  3. Be consistent, maintain balance over time. For children, ages six and older, the AAP recommends placing consistent limits on the time spent using media, and the types of media. Make every effort screen time does not take the place of adequate sleep, physical activity and other behaviors essential to your child’s health.
  4. Media free time. Establish media-free family times as well as zones such as the bedroom, dinner table, car time and restaurants. Keep in mind that modeling this behavior, as a parent is key to your child adopting his or her healthy screen time habits. Be aware of the time you spend on devices and binging on those TV shows — your kids are watching and absorbing your media habits.
  5. Start talking early and often. It’s never too early to start having the technology discussion. Just as you teach a child why eating cake for every meal isn’t healthy, so too, for health reasons, limits must be put on screen time. As kids begin interacting with peers online, start talking about online citizenship and safety, including treating others with respect online and offline.

No doubt about it — technology has improved our lives in incredible ways and enhanced every part of our culture from education to health, to entertainment, to business. However, as parents, it’s critical to present our kids with the whole picture, which includes the ways technology, if poorly used, can threaten our quality of life. Helping kids understand that too much technology can make you tired, cranky, and even harm your brain, has become part of our role as digital parents, caregivers, and grandparents.

toni page birdsong

 

Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her on Twitter @McAfee_Family. (Disclosures).

The post 5 Screen Time Principles to Establish When Your Kids are Still Babies appeared first on McAfee Blogs.

Internet Safety Month: 5 Tips to Keep You Secure

The internet is infinitely expansive, but that’s often easy to forget as we now have immediate access to it in the palm of our hands. We feel safe scouring the digital world from the comfort of our homes, offices, or local coffee shops, but there is real danger lurking behind those virtual walls. Cybercriminals using the internet to infiltrate the Internet of Things (IoT) and our mobile devices is no longer the stuff of science fiction movies. Hacks, phishing scams, malicious sites, and malware, just to name a few — this world of hyper-connectivity has left us exposed to far greater threats than we could have ever imagined. To combat these looming threats and highlight the importance of staying safe online, June was dubbed Internet Safety Month. Seeing as the internet gives us the opportunity to learn, explore, create, and socialize, we should be doing so safely and securely.

According to a recent Pew Research Center survey, 77% of American adults own a smartphone, up from 35% just six years ago. Whether we’re traveling, working, or just having fun, our mobile devices — tablet, smartphone, or laptop — are within reach at all times. Our gadgets make it easier to connect with the world, but they also store tons of sensitive information about our lives. Yes, we may use our devices to talk and text, but we also use applications on those devices to access banking information, share our location, and check emails. This wealth of personal information on an easily hackable device should galvanize us to ensure that data stays out of the hands of cybercriminals. From ransomware to phishing scams, the numerous threats that can infect our IoT and mobile devices through the internet are ever-evolving menaces.

With the rise of IoT, the probability of a debilitating attack increases. Just like everything else online, IoT devices are one part of a massively distributed network. The billions of extra entry points that IoT devices create make them a greater target for cybercriminals. In 2016, this fact was proven and executed by the Mirai botnet, a malware strain that remotely enslaved IoT objects for use in large-scale attacks designed to knock websites and entire networks offline. The authors of Mirai discovered previously unknown vulnerabilities in IoT devices that could be used to strengthen their botnet, which at its height infected 300,000 devices. While this is an extreme example, it is very much a reality that could happen again — only this time worse. These ever-present threats make it crucial to maintain proper cyber hygiene while using the internet.

Internet Safety Month emphasizes the importance of staying safe while surfing the web, not just in June but all 365 days of the year. With new threats appearing every day, the time to be proactive about your online safety is now. Don’t find yourself on the wrong side of the most recent internet threat, follow these tips to stay protected:

  • Secure your devices. Strong passwords or touch ID features are your first line of defense against cybercriminals stealing your sensitive information. With security measures in place, your data is protected in the case of your device being lost or stolen. And reset those default passwords — many of today’s exploits come from leveraging devices where the default settings were never changed.
  • Only use apps you trust. Information about you is collected through the apps you use. Think about who is getting that data and if you’re comfortable with how it could be used.
  • Be picky about what Wi-Fi you’re using. Hotspots and public Wi-Fi networks are often unsecured, meaning anyone can see what you’re doing on your device. Limit your activity and avoid logging into accounts that hold sensitive information. Consider using a virtual private network (VPN) or a personal/mobile hotspot.
  • Disable Wi-Fi and Bluetooth when not in use. Stores and other locations use this information to track your movements when you are in range. Both Bluetooth and Wi-Fi can also act as digital entrances into your phone. When it’s not absolutely necessary, consider turning it off.
  • Keep your devices and apps up-to-date. Having the most up-to-date software and applications is the best defense against threats. If an app is no longer in use, just delete it to ensure your devices clutter-free and no longer housing unsupported or outdated apps.

Interested in learning more about IoT and mobile security tips and trends? Stop by ProtectWhatMatters.online, and follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post Internet Safety Month: 5 Tips to Keep You Secure appeared first on McAfee Blogs.

What the Mobile-Born Mean for IoT and Cybersecurity

Since before they knew how to walk, Gen Z – or the mobile-born generation – has had a wealth of information, quite literally, at their fingertips. Their lives are exponentially hyper-connected with social media, music, ride sharing, shopping, and more, all through their mobile devices. But Gen Z’s haste to be on the cutting edge of technology and trends can often leave them arrogant to the security implications. They prioritize personalization over privacy and willingly share personal data so they can have a more predictive and personalized experience, without the same sense of security awareness as that of previous generations. Through increased data sharing, and the modern-day usage of social media, the mobile-born could be naively exposing themselves, and loved ones, to security issues they don’t fully realize or understand.

Social Media

Apps such as Snapchat and Facebook constantly know where consumers are located through default settings, geotagging photos, and videos, “checking in” to reap promotional rewards or to just show off their latest experiences. This may not seem pressing, but in actuality, it tells people where you are at any given moment and, depending on your privacy settings, this information could get out to audiences that it wasn’t intended for. If you posted a picture while at home, you are likely taking a GPS location snapshot and potentially letting your home address get into the wrong hands. The metadata within your photo can now be used by cybercriminals to track where you live, opening up your home and devices to a slew of cybersecurity concerns. Geotagging can be fun and beneficial, but issues arise when user data is distributed unknowingly.

Furthermore, past generations have learned the hard way that once something is on the internet, it’s nearly impossible to get it back. We’ve gotten into the habit of oversharing our experiences online – whether mere photos of friends, our pets, birthday celebrations or the address of your favorite spot to hang out on the weekends, you may be giving the keys to all of your data. How does this seemingly harmless series of posts affect personal security? A combination of the information being shared on these social media sites can also be utilized to crack common passwords.

Passwords

Another common theme among Gen Z is poor password hygiene. There is more importance placed on ease and convenience rather than data security. Passwords are often the weakest entry point for hackers and, according to a recent McAfee survey, nearly a quarter of people currently use passwords that are 10 or more years old. While Post-Millennials may not have passwords that old, they still display poor password hygiene by reusing the same credentials among multiple online sites and granting login access to third-party applications through networking platforms like Facebook.

If a cybercriminal cracks one password, they now have the skeleton key to the rest of your digital life. Passwords are our data’s first defense when it comes to cybercriminals, so by differentiating passwords across several accounts or using a password manager, Gen Z-ers can make sure the proper precautions are in place and better defend against unwanted access.

Public Wi-Fi

The mobile-born generation has a totally new outlook on digital experiences and their connection to the online world. They expect to have free, authentic, and secure Internet provided to them at all times, without having to take the necessary security precautions themselves. The internet isn’t just a tool for these digital natives, but rather a way of life and with that expectation, they will connect to public Wi-Fi networks without a second thought toward who’s hosting it and if it’s secure.

If they head to the library or a coffee shop to do homework or stream a video while out to lunch, they’re likely connecting to an unsecured public Wi-Fi network. Connecting to public Wi-Fi can be an easy data/money-saving trick for those on a family shared data plan, but it may be one that puts your data at risk. Much like all individuals have a social security number, all devices have a unique Internet Protocol (IP) address being tracked by Internet Service Providers (ISPs). This allows a device to communicate with the network, but if it’s doing so insecurely, it can act as a watering hole for cybercriminals to eavesdrop, steal personal information, and potentially infect devices with malware.

Educating the Next Generation

Whether it’s ignorant use of social media, poor password protection or careless connection to the internet, the iGeneration does not show the same level of security knowledge or experience as previous generations. Maybe they just don’t know about the various threats out there, or they don’t have the proper education to be using their devices and the internet safely, but it’s our duty to educate our kids about the implications of cybercriminals, privacy breaches, and data exploits to ensure proper cyber hygiene for years to come.

Consider these tips when setting ground rules for keeping you and your family safe:

  • Parental Controls. While these may be a nuisance sometimes, they are also a necessity in keeping you and your children safe from malicious sites. Consider using McAfee Secure Home Platform to ensure your family’s security while in the home.
  • Turn off geolocation. In ‘Settings’ on your device, you can select which apps are allowed to use your location. Make sure only the ones you know you can trust are selected.
  • Restrict access to your information. If you go into your browser, you can adjust your privacy settings to delete information from your browsing history (i.e. cookies, history, saved passwords, or banking information).
  • Install a Virtual Private Network (VPN). A personal VPN extends a private network across a public Wi-Fi network to help secure and encrypt your data and keep your connections safe. Software like McAfee Safe Connect can help protect your data at home and on the go.
  • Talk with your children. Understanding that their personal information is invaluable is the first step towards creating and maintaining safe online habits.

Interested in learning more about IoT and mobile security tips and trends? Follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post What the Mobile-Born Mean for IoT and Cybersecurity appeared first on McAfee Blogs.

High-Tech & Hackable: How to Safeguard Your Smart Baby Devices

It’s just about as creepy as it gets: A hacker breaking into a smart device in your baby’s nursery. The Internet of Things (IoT) has wrapped our homes technology, which means any piece of technology you own — be it a smartphone, a thermostat, or even a baby toy or monitor — is fair game for hackers.

High tech products geared toward parents of newborns and kids are on the rise. Reports show that new parents are fueling this industry and purchasing everything from smart diapers, onesies, baby monitors, digital bassinets, soothers, high-tech swings, breathing monitors, play pads, and a string of smart toys. Parents purchasing baby tech and digital toys are counting on fresh tech ideas and products to increase efficiency and maintain a constant connection to their kids.

But these seemingly efficient products, some argue, could be increasing parent’s stress in some cases. Are these tech products, which are also highly hackable, worth the risk and worry?

The Pros

Peace of mind, safety. Smart baby devices give anxious parents added peace of mind when it comes to worries. Who doesn’t want to see their sweet baby deep in sleep and go to bed without worry? Given a chance, many parents welcome the opportunity to know their baby’s temperature, oxygen levels, heartbeat, and breathing are on track.

Remote monitoring, convenience. When you can be downstairs or working in the yard, or in your home gym, and still check on a sleeping baby, that’s an incredible convenience that many parents welcome as a productivity booster.

Learning and development. Many parents purchase smart devices for kids in an effort to help them stay on track developmentally and ensure they are prepared for the tech-driven world they are heading into.

The Cons

Hackable. Any device that is web-enabled or can connect to the cloud has the potential to be hacked, which can create a whole new set of issues for a family. If you are getting sleeping, breathing, and health data on your child, anyone else could be getting that same information.

False readings. Baby technology, as useful as it appears, can also have glitches that medical professionals argue can be more harmful than helpful. Can you imagine waking up at 2 a.m. to a monitor alarm that falsely says your baby isn’t breathing?

Complex, pricey. Some of the products can be complicated to program and set up and pricey to purchase or replace.

So why would a hacker even want to break into a baby monitor, you may ask? For some hackers, the motive is simply because they can. Being able to intercept data, crash a device, or prove his or her digital know-how is part of a hacker’s reward system. For others, the motives for stalking your family’s activities or talking to kids in the middle of the night can prove to be a far more nefarious activity.

Tips to safeguard baby tech:

Think before you purchase. According to the tech pros, think before buying baby tech and evaluate each item’s usefulness. Ask yourself: Do I need this piece of technology? Will this product potentially decrease or increase my stress? If a product connects to the wi-fi or the cloud, weight its convenience against any risk to your family’s data.

Change default passwords. Many products come with easy-to-guess default passwords that many consumers don’t take the time to change. This habit makes it easy for hackers to break in. Hackers can also gain access to entire wifi networks just by retrieving the password stored on one device. (Sometimes all a hacker does is google a specific brand to find the product’s password — yes, it’s as easy as that!)

Buy from known brands. Buy from reputable manufacturers and vendors. Google to see if that company’s products have ever been digitally compromised. And although it’s tempting to get your device used to save a little money, second-hand technology might have malware installed on it so beware.

Update software, use strong passwords. If there’s a software update alert connected to your baby tech, take the time to update immediately and be sure to choosing a password with a minimum of 16 characters and not using the same password for more than one device.

Turn off. When your devices are not on, there’s no vulnerability so, even with all the safeguards, remember to turn off devices not in use for that last layer of protection.

toni page birdsong

 

 

Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her on Twitter @McAfee_Family. (Disclosures).

The post High-Tech & Hackable: How to Safeguard Your Smart Baby Devices appeared first on McAfee Blogs.

America’s Dirty Little Secrets: Opening the Door to Protected Data

It’s 2018. Digital assistants have started taking over our homes, with adoption growing tenfold. These smart speakers know everything about us, from our shopping habits to our music tastes — they likely know more about our daily lives than we do. This ever-growing, ever-changing relationship between humans and devices highlights the importance of protecting data – verbal or otherwise – in the home. With connected devices using our personal data to be the most comprehensive in-home assistants possible, we need to prioritize Internet of Things (IoT) security, awareness and the implications of using such devices.

It’s estimated that by 2022, over half of U.S. households will have at least one smart speaker in their home — that’s over 70 million households, topping 175 million installed devices. These devices are aimed at making our lives easier and more convenient than ever before, but to do so they require that we willingly share access to our personal and private information. Whether it’s banking and home address stored directly on the device, or learnings it’s picked up from our conversations, the amount of private data that these devices carry opens up a new array of threats. New research from McAfee reveals that 60% of Americans have considered their digital assistants could be recording or listening to them. If so, what are the security implications of using a digital assistant?

From answering a quick question to ordering items online, controlling the lights, or changing thermostat temperature, digital assistants have become a pseudo-family member in many households, connecting to more IoT things than ever before. But if one of these devices is breached, it can open up an entire home Wi-Fi network and our valuable information could get into the wrong hands. Beyond this, many Americans have developed a very personal relationship with their devices, with 50% admitting to being embarrassed if friends or family knew what questions they asked their digital assistants. Now imagine if any of that information fell into the hands of cybercriminals — it could open the door to your personal data and threaten your family’s security.

In addition to the sensitive data that our smart speakers have stored, and the conversations they may or may not be recording, there are other security risks associated with this technology in the home. In 2016, it was determined that music or TV dialogue could take control of our digital assistants with commands undetectable to human ears. Known as the “Dolphin Attack,” this occurrence essentially hides commands in high-frequency sounds that our assistant-enabled gadgets can detect, but we are unable to hear. Instances of TV commercials activating digital assistants have already been reported, so we can see how this technique could be quite easy for cybercriminals to imitate if they wanted to access our smart homes’ network.

The growing trend of connecting these always-listening assistants to our home appliances and smart home gadgets is only exacerbating these concerns. Aside from digital assistants, other IoT devices such as game consoles, home security systems, thermostats, and smartphones may be at risk and must be secured to avoid becoming targets for cybercriminals. We must proceed with caution and be aware of who, or what could be listening in order to protect ourselves accordingly. Whenever bringing any kind of new, connected device into the home, prioritize safety and privacy.

Here are some top tips to securely manage the connected devices in your home:

  • Vary your passwords. Create passwords that are difficult to crack to ensure accounts are secure and update your passwords on a regular basis. Use multi-factor authentication whenever possible. Simplify password management by using a password manager.
  • Consider setting up a PIN code. Particularly for voice command purchases. Help keep cybercriminals away from your data by setting up an extra layer of security.
  • Invest in a router that delivers security for all your connected devices. It’s important to secure your entire connected home network. And the launch of McAfee Secure Home Platform skill for Alexa is set to make this easier and more convenient than ever before.

Technology is changing our everyday lives but being aware of the security concerns is the key to becoming an empowered consumer.

Interested in learning more about IoT and mobile security tips and trends? Follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post America’s Dirty Little Secrets: Opening the Door to Protected Data appeared first on McAfee Blogs.

Rooting a Logitech Harmony Hub: Improving Security in Today’s IoT World

Introduction

FireEye’s Mandiant Red Team recently discovered vulnerabilities present on the Logitech Harmony Hub Internet of Things (IoT) device that could potentially be exploited, resulting in root access to the device via SSH. The Harmony Hub is a home control system designed to connect to and control a variety of devices in the user’s home. Exploitation of these vulnerabilities from the local network could allow an attacker to control the devices linked to the Hub as well as use the Hub as an execution space to attack other devices on the local network. As the Harmony Hub device list includes support for devices such as smart locks, smart thermostats as well as other smart home devices, these vulnerabilities present a very high risk to the users.

FireEye disclosed these vulnerabilities to Logitech in January 2018. Logitech was receptive and has coordinated with FireEye to release this blog post in conjunction with a firmware update (4.15.96) to address these findings.

The Red Team discovered the following vulnerabilities:

  • Improper certificate validation
  • Insecure update process
  • Developer debugging symbols left in the production firmware image
  • Blank root user password

The Red Team used a combination of the vulnerabilities to gain administrative access to the Harmony Hub. This blog post outlines the discovery and analysis process, and demonstrates the necessity of rigorous security testing of consumer devices – particularly as the public places an increasing amount of trust in devices that are not just connected to home networks, but also give access to many details about the daily lives of their users.

Device Analysis

Device Preparation

Publicly available research indicated the presence of a universal asynchronous receiver/transmitter (UART) interface on some of the test points on the Harmony Hub. We soldered jumper wires to the test pads, which allowed us to connect to the Harmony Hub using a TTL to USB serial cable. Initial analysis of the boot process showed that the Harmony Hub booted via U-Boot 1.1.4 and ran a Linux kernel (Figure 1).


Figure 1: Initial boot log output from UART interface

After this point in the boot process, the console stopped returning output because the kernel was not configured with any console interfaces. We reconfigured the kernel boot parameters in U-Boot to inspect the full boot process, but no useful information was recovered. Furthermore, because the UART interface was configured to only transmit, no further interaction could be performed with the Harmony Hub on this interface. Therefore, we shifted our focus to gaining a better understanding of the Linux operating system and associated software running on the Harmony Hub.

Firmware Recovery and Extraction

The Harmony Hub is designed to pair with a companion Android or iOS application over Bluetooth for its initial configuration. We created a wireless network with hostapd and installed a Burp Suite Pro CA certificate on a test Android device to intercept traffic sent by the Harmony mobile application to the Internet and to the Harmony Hub. Once initial pairing is complete, the Harmony application searches for Harmony Hubs on the local network and communicates with the Harmony Hub over an HTTP-based API.

Once connected, the Harmony application sends two different requests to Harmony Hub’s API, which cause the Harmony Hub to check for updates (Figure 2).


Figure 2: A query to force the Harmony Hub to check for updates

The Harmony Hub sends its current firmware version to a Logitech server to determine if an update is available (Figure 3). If an update is available, the Logitech server sends a response containing a URL for the new firmware version (Figure 4). Despite using a self-signed certificate to intercept the HTTPS traffic sent by the Harmony Hub, we were able to observe this process – demonstrating that the Harmony Hub ignores invalid SSL certificates.


Figure 3: The Harmony Hub checks for updates to its firmware


Figure 4: The server sends a response with a URL for the updated firmware

We retrieved this firmware and examined the file. After extracting a few layers of archives, the firmware can be found in the harmony-image.squashfs file. This filesystem image is a SquashFS filesystem compressed with lzma, a common format for embedded devices. However, vendors often use old versions of squashfstools that are incompatible with more recent squashfstools builds. We used the unsqashfs_all.sh script included in firmware-mod-kit to automate the process of finding the correct version of unsquashfs to extract the filesystem image (Figure 5).


Figure 5: Using firmware-mod-kit to extract the filesystem

With the filesystem contents extracted, we investigated some of the configuration details of the Harmony Hub’s operating system. Inspection revealed that various debug details were available in the production image, such as kernel modules that were not stripped (Figure 6).


Figure 6: Unstripped Linux kernel objects on the filesystem

Investigation of /etc/passwd showed that the root user had no password configured (Figure 7). Therefore, if we can enable the dropbear SSH server, we can gain root access to the Harmony Hub through SSH without a password.


Figure 7: /etc/passwd shows no password is configured for the root user

We observed that an instance of a dropbear SSH server will be enabled during initialization if the file /etc/tdeenable is present in the filesystem (Figure 8).


Figure 8: A dropbear SSH server is enabled by /etc/init.d/rcS script if /etc/tdeenable is present

Hijacking Update Process

During the initialization process, the Harmony Hub queries the GetJson2Uris endpoint on the Logitech API to obtain a list of URLs to use for various processes (Figure 9), such as the URL to use when checking for updated firmware or a URL to obtain information about updates’ additional software packages.


Figure 9: The request to obtain a list of URL endpoints for various processes

We intercepted and modified the JSON object in the response from the server to point the GetUpdates member to our own IP address, as shown in Figure 10.


Figure 10: The modified JSON object member

Similar to the firmware update process, the Harmony Hub sends a POST request to the endpoint specified by GetUpdates containing the current versions of its internal software packages. The request shown in Figure 11 contains a sample request for the HEOS package.


Figure 11: The JSON request object containing the current version of the “HEOS” package

If the sysBuild parameter in the POST request body does not match the current version known by the server, the server responds with an initial response containing information about the new package version. For an undetermined reason, the Harmony Hub ignores this initial response and sends a second request. The second response contains multiple URLs pointing to the updated package, as shown in Figure 12.


Figure 12: The JSON response containing URLs for the software update

We downloaded and inspected the .pkg files listed in the response object, which are actually just ZIP archives. The archives contain a simple file hierarchy, as shown in Figure 13.


Figure 13: The .pkg archive file hierarchy

The manifest.json file contains information used to instruct the Harmony Hub’s update process on how to handle the archive’s contents (Figure 14).


Figure 14: The contents of the manifest.json file

The Harmony Hub’s update process executes the script provided by the installer parameter of the manifest if it is present within the archive. We modified this script, as shown in Figure 15, to create the /etc/tdeenable file, which causes the boot process to enable the SSH interface as previously described.


Figure 15: The modified update.sh file

We created a new malicious archive with the appropriate .pkg extension, which was hosted on a local web server. The next time the Harmony Hub checked for updates against the URL supplied in the modified GetJson2URIs response, we sent a modified response to point to this update. The Harmony Hub retrieved our malicious update package, and after rebooting the Harmony Hub, the SSH interface was enabled. This allowed us to access the device with the username root and a blank password, as shown in Figure 16.


Figure 16: The SSH interface was enabled after a reboot

Conclusion

As technology becomes further embedded into our daily lives, the trust we place in various devices unknowingly increases exponentially. Due to the fact that the Harmony Hub, like many IoT devcies, uses a common processor architecture, malicious tools could easily be added to a compromised Harmony Hub, increasing the overall impact of a targeted attack. However, Logitech worked with our team to quickly address the vulnerabilities with their current firmware, 4.15.96. Developers of the devices we place our trust should be vigilant when removing potential attack vectors that could expose end users to security risks. We also want to share Logitech’s statement on the research and work by the Red Team:

"At Logitech, we take our customers’ security and privacy very seriously. In late January 2018, security research firm FireEye pointed out vulnerabilities that could impact Logitech Harmony Hub-based products*.

If a malicious hacker had already gained access to a Hub-users network, these vulnerabilities could be exploited. We appreciate the work that professional security research firms like FireEye provide when identifying these types of vulnerabilities on IoT devices.

As soon as FireEye shared their research findings with us, we reviewed internally and immediately started to develop firmware to address it. As of April 10, we have released firmware that addresses all of the vulnerabilities that were identified. For any customers who haven’t yet updated to firmware version 4.15.96, we recommend you check the MyHarmony software and sync your Hub-based remote and receive it. Complete directions on updating your firmware can be found here.

*Hub-based products include: Harmony Elite, Harmony Home Hub, Harmony Ultimate Hub, harmony Hub, Harmony Home Control, Harmony Pro, Harmony Smart Control, Harmony Companion, Harmony Smart Keyboard, Harmony Ultimate and Ultimate Home."

The big things at CES? Drones, privacy and The Internet of Things

F-Secure is back from CES — where the tech world comes together in Las Vegas to preview some of the latest innovations – some which might change our lives in the coming years, others never to be seen or heard again.

Inside the over 200,000 square meter exhibit space, Drones flew, and made a fashion statementhearing aids got smartphone appsand 3-D printers printed chocolate.

We made a stir of our own with Freedome. Our David Perry reminded the industry professionals that the mobile devices nearly all of them were carrying can do more than connect us.

“I want you to stop and think about this,” he told RCR Wireless News as he held his smartphone up on the event floor. “This has two cameras on it. It has two microphones. It has GPS. It has my email. It has near-field detectors that can tell not only where I am but who I’m sitting close to. This is a tremendous amount of data. Every place I browse on the internet. What apps I’m running. What credit cards I have. And this phone doesn’t take any steps to hide my privacy.”

In this post-Snowden world, where professionals are suddenly aware of how much their “meta-data” can reveal about them.

Privacy also played a big role in the discussion of one the hottest topics of 2015 — the Internet of Things (IoT).

The world where nearly everything that can be plugged in — from washing machines to light bulbs to toasters — will be connected to the internet is coming faster than most predicted. Samsung promised every device they make will connect to the net by the end of the decade.

If you think your smartphone holds a lot of private data, how about your smarthome?

“If people are worried about Facebook and Google storing your data today, wait until you see what is coming with #IoT in next 2-5 years,” our Ed Montgomery tweeted during the event’s keynote speeches, which included a talk from US Federal Trade Commission Chairwoman Edith Ramirez that tackled privacy issues on the IoT.

Newly detected attacks on home routers suggest that the data being collected in our connected appliances could end up as vulnerable to snoops and hackers as our PCs.

Some fear that these privacy risks may prevent people from adopting technologies that could eventually save us time, effort and energy.

At F-Secure we recognize the promise that IoT and smart homes hold and we’re excited about the coming years. But we also understand the potential threats, risks, and dangers. We feel that our job is to enable our customers to fully enjoy the benefits of IoT and that is why we’re working on new innovations that will help customers to adopt IoT and smart home solutions in a safe and controlled way. It will be an exciting journey and we invite you to learn more about our future IoT solutions in the coming months.

We at F-Secure’s IoT team would like to hear from you! Are you ready to jump on the IoT? What would your dream connected home look like? Or have you perhaps already set up your smart home? What are you worried about? How could your smart home turn into a nightmare?

[Image by One Tech News | via Flickr]

For an Internet of Things, We Are Going to Need Better Things

There's a lot of hype around at the moment about "The Internet of Things" (IoT), which, I suppose, is all about attaching, uh, things to the Internet. By "things", it seems we are supposed to be thinking household goods, vehicles; basically anything with electrical current running through it is a candidate for the "internet of things".

While setting up a cheapo DVD player last week, I couldn't help thinking of Chief Brody in the film "Jaws"... "You're going to need a bigger boat", he says, on seeing the enormous shark. We're going to need a bigger mindset on security if we are to survive the onslaught of "things". The firmware in the kind of devices we are already routinely connecting up is drivel. I mean some of it is absolute garbage. I know there are exceptions, but most of it is badly built, and almost none of it is ever updated.

Each of these devices is likely perfectly capable as a host in a botnet - for DDoS, for sending SPAM, SPIM and SPIT (OK, we are yet to see much in the way of unsolicited Internet Telephony... but with the IoT, devices built to make calls/send texts are likely to get hijacked), so each of these devices has a value to the Internet's vast supply of wrongdoers.

Researchers at Eurcom recently completed a study showing up vulnerabilities in the 30 thousand or so firmware images they scraped from vendor websites. Apparently one image even contained a linux kernel whose age had just hit double figures. Ouch. The "Nest" next-gen thermostat hasn't been without issues either, a high profile target, at least we can expect firmware updates from them!

Synology's NAS storage devices are among the early victims of malware attacking non-traditional computing devices, and may be an indication of IoT issues to come. Users of these storage devices have found themselves victim of a crypto-ransomware attack: their files are encrypted, and the encryption keys offered for sale back to them! Other early warnings come in the form of attacks on SCADA industrial control systems. These are all places that traditionally, little or no emphasis has been placed on security.

What can we do to help ourselves here? My advice is be careful before you buy anything you're going to add to your network. Look to see if the vendor has a firmware download, and if there's a recent-ish update. If they're the fire'n'forget types, you're probably not going to want to deploy it.

Footnote: Gartner appears to believe the Internet of Things to have reached "peak hype". Reminds me of an old saying about those dwelling in vitreous abodes launching masonry...