Category Archives: Vulnerabilities

Another Spectre-Like CPU Vulnerability

Google and Microsoft researchers have disclosed another Spectre-like CPU side-channel vulnerability, called "Speculative Store Bypass." Like the others, the fix will slow the CPU down.

The German tech site Heise reports that more are coming.

I'm not surprised. Writing about Spectre and Meltdown in January, I predicted that we'll be seeing a lot more of these sorts of vulnerabilities.

Spectre and Meltdown are pretty catastrophic vulnerabilities, but they only affect the confidentiality of data. Now that they -- and the research into the Intel ME vulnerability -- have shown researchers where to look, more is coming -- and what they'll find will be worse than either Spectre or Meltdown.

I still predict that we'll be seeing lots more of these in the coming months and years, as we learn more about this class of vulnerabilities.

SecurityWeek RSS Feed: Two Vulnerabilities Patched in BIND DNS Software

Updates announced on Friday by the Internet Systems Consortium (ISC) for BIND, the most widely used Domain Name System (DNS) software, patch a couple of vulnerabilities.

While attackers may be able to exploit both of the flaws remotely for denial-of-service (DoS) attacks, the security holes have been assigned only a “medium” severity rating.

read more

SecurityWeek RSS Feed

Cisco Warns of Three Critical Bugs in Digital Network Architecture Platform

The company urges customers to patch three vulnerabilities that received the highest severity rating of 10.

Cybersecurity Threats in 2018: Cryptojacking, Ransomware and a Divided Zero-Day Market

Data from the first quarter of 2018 revealed that the cybersecurity threats landscape is changing. As noted by CSO Online, cryptojacking continues to gain ground: In the first quarter of 2018, 28 percent of companies reported crypto-mining malware, up from just 13 percent in Q4 2017.

According to Nasdaq, meanwhile, ransomware remains a critical threat. BlackRuby, SamSam and GandCrab all made an impact over the last three months, with GandCrab’s ransom demand marking the first time malicious actors asked for payment in Dash digital currency.

But there’s another story here: The growing division (and multiplication) of the zero-day market.

The Attack Surface Expands

As Computer Weekly reported, the total number of malware families grew by 25 percent last quarter while unique variants saw a 19 percent boost. In addition, cybercriminals are now taking the time to conduct reconnaissance on potential targets and leverage automation to maximize attack impact. The Nasdaq piece pointed to the Olympic Destroyer malware, which was specifically designed to interfere with the global sporting event in Pyeongchang this year.

Corporate attack surfaces are also expanding thanks to the uptake of Internet of Things (IoT) technologies. Three of the top 20 reported cybersecurity threats last quarter targeted these devices. Although 60 percent of all web traffic is now encrypted, this “represents a real challenge for traditional security technology that has no way of filtering encrypted traffic.” So it’s no surprise that zero-day threats haven’t received as much attention, even as the market for discovery and distribution evolves.

No Zero-Sum Game

According to Fortinet’s “Threat Landscape Report Q1 2018,” the zero-day market is maturing. While there were 214 zero-day threats discovered in all of 2017, 45 were found in Q1 2018 alone, affecting everything from popular content management systems (CMSs) to device makers and industry-leading operating system (OS) developers. Division of the market by “hat” — white-, gray- and black-hat IT experts — has produced three distinct zero-day streams:

  • White hat — This market supports bug bounty programs, which pay law-abiding security professionals to find new vulnerabilities, but secure disclosure and patching of these exploits is critical to limit accidental exposure.
  • Grey hatHere, zero-day “brokers” purchase bugs for customers. The caveat is that these customers are typically anonymous. The Fortinet report noted that it’s “possible that the buyer is a hostile nation-state, cybercriminal enterprise or otherwise maliciously inclined.”
  • Black hatFor black-hat actors, the goal is to both find and create new zero-day exploits for profit, and threat researchers have confirmed that “the creation and distribution of zero days by cybercriminals is on the rise.”

This triple-threat market adds up to a kind of multiplicative effect: Companies concerned about zero-day bugs invest more money into white-hat programs to find and eliminate them, while for-profit gray- and black-hat actors look to discover and create new bugs to continue the cycle.

Transformative Cybersecurity Threats

The Fortinet report emphasized that the rise of malware innovation, IoT risks, cryptojacking and zero-day threats “points to the continued transformation of cybercrime.” Specifically, companies need to do the math on zero-day exploits — division of outcomes, combined with multiplying interest, makes this a market to watch in 2018.

The post Cybersecurity Threats in 2018: Cryptojacking, Ransomware and a Divided Zero-Day Market appeared first on Security Intelligence.

DHS announces New Cybersecurity Strategy

The U.S. Department of Homeland Security (DHS) has a new strategy to steer its cybersecurity efforts to meet what it recognizes as a growing threat to U.S. national security and critical infrastructure days after the White House eliminated its Cybersecurity Coordinator position. The simultaneous decisions by the White House show the persistent...

Read the whole entry... »

Related Stories

Ireland Bank Chiefs Concerned About Cyber-Attack Vulnerability

The threat regarding cyber-attack is keeping the bank and capital market executives awake at night, as shown by a new

Ireland Bank Chiefs Concerned About Cyber-Attack Vulnerability on Latest Hacking News.

Vulnerability Spotlight: Multiple Adobe Acrobat Reader DC Vulnerabilities

Discovered by Aleksandar Nikolic of Cisco Talos


Today, Talos is releasing details of a new vulnerabilities within Adobe Acrobat Reader DC. Adobe Acrobat Reader is the most popular and most feature-rich PDF reader. It has a big user base, is usually a default PDF reader on systems and integrates into web browsers as a plugin for rendering PDFs. As such, tricking a user into visiting a malicious web page or sending a specially crafted email attachment can be enough to trigger this vulnerability.

A specific Javascript script embedded in a PDF file can cause the document ID field to be used in an unbounded copy operation leading to stack-based buffer overflow when opening a specially crafted PDF document in Adobe Acrobat Reader DC 2018.009.20044. This stack overflow can lead to return address overwrite which can result in arbitrary code execution. In order to trigger this vulnerability, the victim would need to open the malicious file or access a malicious web page.

TALOS-2018-0517 - Adobe Acrobat Reader DC Net.Discovery.queryServices Remote Code Execution Vulnerability (CVE-2018-4946)

A specific Javascript script embedded in a PDF file can lead to a pointer to previously freed object to be reused when opening a PDF document in Adobe Acrobat Reader DC 2018.009.20044. With careful memory manipulation, this can potentially lead to sensitive memory disclosure or arbitrary code execution. In order to trigger this vulnerability, the victim would need to open the malicious file or access a malicious web page. Detailed vulnerability information can be found here.

TALOS-2018-0518 - Adobe Acrobat Reader DC ANFancyAlertImpl Remote Code Execution Vulnerability (CVE-2018-4947)

A specific Javascript script embedded in a PDF file can lead to a pointer to previously freed object to be reused when opening a PDF document in Adobe Acrobat Reader DC 2018.009.20044. With careful memory manipulation, this can potentially lead to sensitive memory disclosure or arbitrary code execution. In order to trigger this vulnerability, the victim would need to open the malicious file or access a malicious web page. Detailed vulnerability information can be found here.

Known vulnerable versions

Adobe Acrobat Reader DC 2018.009.20044


The following Snort Rules will detect exploitation attempts. Note that additional rules may be released at a future date and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your FireSIGHT Management Center or

Snort Rules: 45506-45507, 45521-45522

Details on a New PGP Vulnerability

A new PGP vulnerability was announced today. Basically, the vulnerability makes use of the fact that modern e-mail programs allow for embedded HTML objects. Essentially, if an attacker can intercept and modify a message in transit, he can insert code that sends the plaintext in a URL to a remote website. Very clever.

The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.

The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.

A few initial comments:

1. Being able to intercept and modify e-mails in transit is the sort of thing the NSA can do, but is hard for the average hacker. That being said, there are circumstances where someone can modify e-mails. I don't mean to minimize the seriousness of this attack, but that is a consideration.

2. The vulnerability isn't with PGP or S/MIME itself, but in the way they interact with modern e-mail programs. You can see this in the two suggested short-term mitigations: "No decryption in the e-mail client," and "disable HTML rendering."

3. I've been getting some weird press calls from reporters wanting to know if this demonstrates that e-mail encryption is impossible. No, this just demonstrates that programmers are human and vulnerabilities are inevitable. PGP almost certainly has fewer bugs than your average piece of software, but it's not bug free.

3. Why is anyone using encrypted e-mail anymore, anyway? Reliably and easily encrypting e-mail is an insurmountably hard problem for reasons having nothing to do with today's announcement. If you need to communicate securely, use Signal. If having Signal on your phone will arouse suspicion, use WhatsApp.

I'll post other commentaries and analyses as I find them.

EDITED TO ADD (5/14): News articles.

Slashdot thread.

Security Gaps Remain as OT, IT Converge

The accelerating digitization of business, driven by compelling commercial arguments, is driving the integration of new information technology (IT) networks with older operational technology (OT) networks. This is introducing new security risks to old technology and old technology practices -- and where the OT is driving a critical manufacturing plant, the new risk is from nation-state actors as well as traditional cyber criminals.

read more

Critical PGP Vulnerability

EFF is reporting that a critical vulnerability has been discovered in PGP and S/MIME. No details have been published yet, but one of the researchers wrote:

We'll publish critical vulnerabilities in PGP/GPG and S/MIME email encryption on 2018-05-15 07:00 UTC. They might reveal the plaintext of encrypted emails, including encrypted emails sent in the past. There are currently no reliable fixes for the vulnerability. If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now.

This sounds like a protocol vulnerability, but we'll learn more tomorrow.

News articles.

OPC UA security analysis

This paper discusses our project that involved searching for vulnerabilities in implementations of the OPC UA protocol. In publishing this material, we hope to draw the attention of vendors that develop software for industrial automation systems and the industrial internet of things to problems associated with using such widely available technologies, which turned out to be quite common. We hope that this article will help software vendors achieve a higher level of protection from modern cyberattacks. We also discuss some of our techniques and findings that may help software vendors control the quality of their products and could prove useful for other software security researchers.

Why we chose the OPC UA protocol for our research

The IEC 62541 OPC Unified Architecture (OPC UA) standard was developed in 2006 by the OPC Foundation consortium for reliable and, which is important, secure transfer of data between various systems on an industrial network. The standard is an improved version of its predecessor – the OPC protocol, which is ubiquitous in modern industrial environments.

It is common for monitoring and control systems based on different vendors’ products to use mutually incompatible, often proprietary network communication protocols. OPC gateways/servers serve as interfaces between different industrial control systems and telemetry, monitoring and telecontrol systems, unifying control processes at industrial enterprises.

The previous version of the protocol was based on the Microsoft DCOM technology and had some significant limitations inherent to that technology. To get away from the limitations of the DCOM technology and address some other issues identified while using OPC, the OPC Foundation developed and released a new version of the protocol.

Thanks to its new properties and well-designed architecture, the OPC UA protocol is rapidly gaining popularity among automation system vendors. OPC UA gateways are installed by a growing number of industrial enterprises across the globe. The protocol is increasingly used to set up communication between components of industrial internet of things and smart city systems.

The security of technologies that are used by many automation system developers and have the potential to become ubiquitous among industrial facilities across the globe is one the highest-priority areas of research for Kaspersky Lab ICS CERT. This was our main reason to do an analysis of OPC UA.

Another reason was that Kaspersky Lab is a member of the OPC Foundation consortium and we feel responsible for the security of technologies developed by the consortium. Getting ahead of the story, we can say that, following the results of our research, we received an invitation to join the OPC Foundation Security Working Group and gratefully accepted it.

OPC UA protocol

Originally, OPC UA was designed to support data transport for two data types: the traditional binary format (used in previous versions of the standard) and SOAP/XML. Today, data transfer in the SOAP/XML format is considered obsolete in the IT world and is almost never used in modern products and services. The prospects of it being widely used in industrial automation systems are obscure, so we decided to focus our research on the binary format.

If packets exchanged by services running on the host are intercepted, their structure can easily be understood. There are four types of messages transmitted over the OPC UA protocol:

  • OPEN

The first message is always HELLO (HEL). It serves as a marker for the start of data transfer between the client and the server. The server responds by sending the ACKNOWLEDGE (ACK) message to the client. After the initial exchange of messages, the client usually sends the message OPEN, which means that the data transmission channel using the encryption method proposed by the client is now open. The server responds by sending the message OPEN (OPN), which includes the unique ID of the data channel and shows that the server agrees to the proposed encryption method (or no encryption).

Now the client and the server can start exchanging messages –MESSAGE (MSG). Each message includes the data channel ID, the request or response type, a timestamp, data arrays being sent, etc. At the end of the session, the message CLOSE (CLO) is sent, after which the connection is terminated.

OPC UA is a standard that has numerous implementations. In our research, we only looked at the specific implementation of the protocol developed by the OPC Foundation.

The initial stage

We first became interested in analyzing the OPC UA protocol when the Kaspersky Lab ICS CERT team was conducting security audits and penetration tests at several industrial enterprises. All of these enterprises used the same industrial control system (ICS) software. With the approval of the customers, we analyzed the software for vulnerabilities as part of the testing.

It turned out that part of the network services in the system we analyzed communicated over the OPC UA protocol and most executable files used a library named “uastack.dll”.

The first thing we decided to do as part of analyzing the security of the protocol’s implementation was to develop a basic “dumb” mutation-based fuzzer.

“Dumb” fuzzing, in spite of being called “dumb”, can be very useful and can in some cases significantly improve the chances of finding vulnerabilities. Developing a “smart” fuzzer for a specific program based on its logic and algorithms is time-consuming. At the same time, a “dumb” fuzzer helps quickly identify trivial vulnerabilities that can be hard to get at in the process of manual analysis, particularly when the amount of code to be analyzed is large, as was the case in our project.

The architecture of the OPC UA Stack makes in-memory fuzzing difficult. For the functions that we want to check for vulnerabilities to work correctly, the fuzzing process must involve passing properly formed arguments to the function and initializing global variables, which are structures with a large number of fields. We decided not to fuzz-test functions directly in memory. The fuzzer that we wrote communicated with the application being analyzed over the network.

The fuzzer’s algorithm had the following structure:

  • read input data sequences
  • perform a pseudorandom transformation on them
  • send the resulting sequences to the program over the network as inputs
  • receive the server’s response
  • repeat

After developing a basic set of mutations (bitflip, byteflip, arithmetic mutations, inserting a magic number, resetting the data sequence, using a long data sequence), we managed to identify the first vulnerability in uastack.dll. It was a heap corruption vulnerability, successful exploitation of which could enable an attacker to perform remote code execution (RCE), in this case, with NT AUTHORITY/SYSTEM privileges. The vulnerability we identified was caused by the function that handled the data which had just been read from a socket incorrectly calculating the size of the data, which was subsequently copied to a buffer created on a heap.

Upon close inspection, it was determined that the vulnerable version of the uastack.dll library had been compiled by the product’s developers. Apparently, the vulnerability was introduced into the code in the process of modifying it. We were not able to find that vulnerability in the OPC Foundation’s version of the library.

The second vulnerability was found in a .NET application that used the UA .NET Stack. While analyzing the application’s traffic in wireshark, we noticed in the dissector that some packets had an is_xml bit field, the value of which was 0. In the process of analyzing the application, we found that it used the XmlDocument function, which was vulnerable to XXE attacks for .NET versions 4.5 and earlier. This means that if we changed the is_xml bit field’s value from 0 to 1 and added a specially crafted XML packet to the request body (XXE attack), we would be able to read any file on the remote machine (out-of-bound file read) with NT AUTHORITY/SYSTEM privileges and, under certain conditions, to perform remote code execution (RCE), as well.

Judging by the metadata, although the application was part of the software package on the ICS that we were analyzing, it was developed by the OPC Foundation consortium, not the vendor, and was an ordinary discovery server. This means that other products that use the OPC UA technology by the OPC Foundation may include that server, making them vulnerable to the XXE attack. This makes this vulnerability much more valuable from an attacker’s viewpoint.

This was the first step in our research. Based on the results of that step, we decided to continue analyzing the OPC UA implementation by the OPC Foundation consortium, as well as products that use it.

OPC UA analysis

To identify vulnerabilities in the implementation of the OPC UA protocol by the OPC Foundation consortium, research must cover:

  • The OPC UA Stack (ANSI C, .NET, JAVA);
  • OPC Foundation applications that use the OPC UA Stack (such as the OPC UA .NET Discovery Server mentioned above);
  • Applications by other software developers that use the OPC UA Stack.

As part of our research, we set ourselves the task to find optimal methods of searching for vulnerabilities in all three categories.

Fuzzing the UA ANSI C Stack

Here, it should be mentioned that there is a problem with searching for vulnerabilities in the OPC UA Stack. OPC Foundation developers provide libraries that are essentially a set of exported functions based on a specification, similar to an API. In such cases, it is often hard to determine whether a potential security problem that has been discovered is in fact a vulnerability. To give a conclusive answer to that question, one must understand how the potentially vulnerable function is used and for what purpose – i.e., a sample program that uses the library is necessary. In our case, it was hard to make conclusions on vulnerabilities in the OPC UA Stack without looking at applications in which it was implemented.

What helped us resolve this problem associated with searching for vulnerabilities was open-source code hosted in the OPC Foundation’s repository on GitHub, which includes a sample server that uses the UA ANSI C Stack. We don’t often get access to product source code in the course of analyzing ICS components. Most ICS applications are commercial products, developed mostly for Windows and released with a licensing agreement the terms of which do not include access to the source code. In our case, the availability of the source code helped find errors both in the server itself and in the library. The UA ANSI C Stack source code was helpful for doing manual analysis of the code and for fuzzing. It also helped us find out whether new functionality had been added to a specific implementation of the UA ANSI C Stack.

The UA ANSI C Stack (like virtually all other products by the OPC Foundation consortium) is positioned as a solution that is not only secure, but is also cross-platform. This helped us our during fuzzing, because we were able to build a UA ANSI С Stack together with the sample server code published by the developers in their GitHub account, on a Linux system with binary source code instrumentation and to fuzz-test that code using AFL.

To accelerate fuzzing, we overloaded the networking functions –socket/sendto/recvfrom/accept/bind/select/… – to read input data from a local file instead of connecting to the network. We also compiled our program with AddressSanitizer.

To put together an initial set of examples, we used the same technique as for our first “dumb” fuzzer, i.e., capturing traffic from an arbitrary client to the application using tcpdump. We also added some improvements to our fuzzer – a dictionary created specifically for OPC UA and special mutations.

It follows from the specification of the binary data transmission format in OPC UA that it is sufficiently difficult for AFL to mutate from, say, the binary representation of an empty string in OPC UA (“\xff\xff\xff\xff”) to a string that contains 4 random bytes (for example, “\x04\x00\x00\x00AAAA”). Because of this, we implemented our own mutation mechanism, which worked with OPC UA internal structures, changing them based on their types.

After building our fuzzer with all the improvements included, we got the first crash of the program within a few minutes.

An analysis of memory dumps created at the time of the crash enabled us to identify a vulnerability in the UA ANSI C Stack which, if exploited, could result at least in a DoS condition.

Fuzzing OPC Foundation applications

Since, in the previous stage, we had performed fuzzing of the UA ANSI C Stack and a sample application by the OPC Foundation, we wanted to avoid retesting the OPC UA Stack in the process of analyzing the consortium’s existing products, focusing instead on fuzzing specific components written on top of the stack. This required knowledge of the OPC UA architecture and the differences between applications that use the OPC UA Stack.

The two main functions in any application that uses the OPC UA Stack are OpcUa_Endpoint_Create and OpcUa_Endpoint_Open. The former provides the application with information on available channels of data communication between the server and the client and a list of available services. The OpcUa_Endpoint_Open function defines from which network the service will be available and which encryption modes it will provide.

A list of available services is defined using a service table, which lists data structures and provides information about each individual service. Each of these structures includes data on the request type supported, the response type, as well as two callback functions that will be called during request preprocessing and post-processing (preprocessing functions are, in most cases, “stubs”). We included converter code into the request preprocessing function. It uses mutated data as an input, outputting a correctly formed structure that matches the request type. This enabled us to skip the application startup stage, starting an event loop to create a separate thread to read from our pseudo socket, etc. This enabled us to accelerate our fuzzing from 50 exec/s to 2000 exec/s.

As a result of using our “dumb” fuzzer improved in this way, we identified 8 more vulnerabilities in OPC Foundation applications.

Analyzing third-party applications that use the OPC UA Stack

Having completed the OPC Foundation product analysis stage, we moved on to analyzing commercial products that use the OPC UA Stack. From the ICS systems we worked with during penetration testing and analyzing the security status of facilities for some of our customers, we selected several products by different vendors, including solutions by global leaders of the industry. After getting our customers’ approval, we began to analyze implementations of the OPC UA protocol in these products.

When searching for binary vulnerabilities, fuzzing is one of the most effective techniques. In previous cases, when analyzing products on a Linux system, we used source code binary instrumentation techniques and the AFL fuzzer. However, the commercial products using the OPC UA Stack that we analyzed are designed to run on Windows, for which there is an equivalent of the AFL fuzzer called WinAFL. Essentially, WinAFL is the AFL fuzzer ported to Windows. However, due to differences between the operating systems, the two fuzzers are different in some significant ways. Instead of system calls from the Linux kernel, WinAFL uses WinAPI functions and instead of static source code instrumentation, it uses the DynamoRIO dynamic instrumentation of binary files. Overall, these differences mean that the performance of WinAFL is significantly lower than that of AFL.

To work with WinAFL in the standard way, one has to write a program that will read data from a specially created file and call a function from an executable file or library. Then WinAFL will put the process into a loop using binary instrumentation and will call the function many times, getting feedback from the running program and relaunching the function with mutated data as arguments. That way, the program will not have to be relaunched every time with new input data, which is good, because creating a new process in Windows consumes significant processor time.

Unfortunately, this method of fuzzing couldn’t be used in our situation. Owing to the asynchronous architecture of the OPC UA Stack, the processing of data received and sent over the network is implemented as call-back functions. Consequently, it is impossible to identify a data-processing function for each type of request that would accept a pointer to the buffer containing the data and the size of the data as arguments, as required by the WinAFL fuzzer.

In the source code of the WinAFL fuzzer, we found comments on fuzzing networking applications left by the developer. We followed the developer’s recommendations on implementing network fuzzing with some modifications. Specifically, we included the functionality of communication with the local networking application in the code of the fuzzer. As a result of this, instead of executing a program, the fuzzer sends payload over the network to an application that is already running under DynamoRIO.

However, with all our efforts, we were only able to achieve the fuzzing rate of 5 exec/s. This is so slow that it would take too long to find a vulnerability even with a smart fuzzer like AFL.

Consequently, we decided to go back to our “dumb” fuzzer and improve it.

  1. We improved the mutation mechanism, modifying the data generation algorithm based on our knowledge of the types of data transferred to the OPC UA Stack.
  2. We created a set of examples for each service supported (the python-opcua library, which includes functions for interacting with virtually all possible OPC UA services, proved very helpful in this respect).
  3. When using a fuzzer with dynamic binary instrumentation to test multithreaded applications such as ours, searching for new branches in the application’s code is a sufficiently complicated task, because it is difficult to determine which input data resulted in a certain behavior of the application. Since our fuzzer communicated to the application over the network and we could establish a clear connection between the server’s response and the data sent to it (because communication took place within the limits of one session), there was no need for us to address this issue. We implemented an algorithm which determined that a new execution path has been identified simply when a new response that had not been observed before was received from the server.

As a result of the improvements described above, our “dumb” fuzzer was no longer all that “dumb”, and the number of executions per second grew from 1 or 2 to 70, which is a good figure for network fuzzing. With its help, we identified two more new vulnerabilities that we had been unable to identify using “smart” fuzzing.


As of the end of March 2018, the results of our research included 17 zero-day vulnerabilities in the OPC Foundation’s products that had been identified and closed, as well as several vulnerabilities in the commercial applications that use these products.

We immediately reported all the vulnerabilities identified to developers of the vulnerable software products.

Throughout our research, experts from the OPC Foundation and representatives of the development teams that had developed the commercial products promptly responded to the vulnerability information we sent to them and closed the vulnerabilities without delays.

In most cases, flaws in third-party software that uses the OPC UA Stack were caused by the developers not using functions from the API implemented in the OPC Foundation’s uastack.dll library properly – for example, field values in the data structures transferred were interpreted incorrectly.

We also determined that, in some cases, product vulnerabilities were caused by modifications made to the uastack.dll library by developers of commercial software. One example is an insecure implementation of functions designed to read data from a socket, which was found in a commercial product. Notably, the original implementation of the function by the OPC Foundation did not include this error. We do not know why the commercial software developer had to modify the data reading logic. However, it is obvious that the developer did not realize that the additional checks included in the OPC Foundation’s implementation are important because the security function is built on them.

In the process of analyzing commercial software, we also found out that developers had borrowed code from OPC UA Stack implementation examples, copying that code to their applications verbatim. Apparently, they assumed that the ОРС Foundation has made sure that these code fragments were secure in the same way that it had ensured the security of code used in the library. Unfortunately, that assumption turned out to be wrong.

Exploitation of some of the vulnerabilities that we identified results in DoS conditions and the ability to execute code remotely. It is important to remember that, in industrial systems, denial-of-service vulnerabilities pose a more serious threat than in any other software. Denial-of-service conditions in telemetry and telecontrol systems can cause enterprises to suffer financial losses and, in some cases, even lead to the disruption and shutdown of the industrial process. In theory, this could cause harm to expensive equipment and other physical damage.


The fact that the OPC Foundation is opening the source code of its projects certainly indicates that it is open and committed to making its products more secure.

At the same time, our analysis has demonstrated that the current implementation of the OPC UA Stack is not only vulnerable but also has a range of significant fundamental problems.

First, flaws introduced by developers of commercial software that uses the OPC UA Stack indicate that the OPC UA Stack was not designed for clarity. Unfortunately, an analysis of the source code confirms this. The current implementation of the protocol has plenty of pointer calculations, insecure data structures, magic constants, parameter validation code copied between functions and other archaic features scattered throughout the code. These are features that developers of modern software tend to eliminate from their code, largely to make their products more secure. At the same time, the code is not very well documented, which makes errors more likely to be introduced in the process of using or modifying it.

Second, OPC UA developers clearly underestimate the trust software vendors have for all code provided by the OPC Foundation consortium. In our view, leaving vulnerabilities in the code of API usage examples is completely wrong, even though API usage examples are not included in the list of products certified by the OPC Foundation.

Third, we believe that there are quality assurance issues even with products certified by the OPC Foundation.

It is likely that use fuzz testing techniques similar to those described in this paper are not part of the quality assurance procedures used by OPC UA developers – this is demonstrated by the statistics on the vulnerabilities that we have identified.

The open source code does not include code for unit tests or any other automatic tests, making it more difficult to test products that use the OPC UA Stack in cases when developers of these products modify their code.

All of the above leads us to the rather disappointing conclusion that, although OPC UA developers try to make their product secure, they nevertheless neglect to use modern secure coding practices and technologies.

Based on our assessment, the current OPC UA Stack implementation not only fails to protect developers from trivial errors but also tends to provoke errors –we have seen this in real-world examples. Given today’s threat landscape, this is unacceptable for products as widely used as OPC UA. And this is even less acceptable for products designed for industrial automation systems.

Crypto-Miners Supplant Ransomware as the Top Healthcare Cybersecurity Threat

Malicious crypto-miners have supplanted ransomware as the top healthcare cybersecurity threat, a cross-sector report revealed.

The April 2018 edition of the Healthcare Information and Management Systems Society (HIMSS)’s “Healthcare and Cross-Sector Cybersecurity Report,” which referenced the recent “Comodo Cybersecurity Q1 2018 Report,” found that crypto-miner attacks increased over the course of the quarter while ransomware attacks decreased.

Comodo’s researchers also noted that attackers are debuting innovations for embedding malware within crypto-miners, a trend that could indicate a preference among bad actors for cryptojacking over more traditional threats.

Crypto-Miners, Backdoors and More

On June 11 at the Healthcare Security Forum, Lee Kim, privacy and security director for HIMSS, will present her a talk titled “Through the Looking Glass: What’s Happening Now and in the Future.” Her session will expand on some of the findings from the April 2018 HIMSS report.

In addition to crypto-miners, HIMSS featured other threats in its roundup, including an authentication bypass vulnerability that facilitates code execution with root privileges on some ASUS routers. The report noted that public exploits are readily available for this weakness.

HIMSS also covered a threat group targeting healthcare firms with a custom backdoor, a remote code execution vulnerability in the 7-Zip program and a Python-based crypto-miner that uses the ETERNALROMANCE exploit to spread to vulnerable Windows PCs.

Improving Healthcare Cybersecurity, One Asset at a Time

Ahead of her presentation at the Healthcare Security Forum, Lee advised healthcare organizations to take inventory of their assets’ locations and configurations. That way, security teams will be in a better position to defend the network from national-state actors, criminals and zealous competitors.

“Think like an attacker and a defender,” she advised, as quoted by Healthcare IT News. “Know how the enemy moves, what they go after, and who they may be — this intelligence can go a long way.”

Lee also emphasized the importance of establishing communication channels for defending against phishing emails.

The post Crypto-Miners Supplant Ransomware as the Top Healthcare Cybersecurity Threat appeared first on Security Intelligence.

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


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


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

Vulnerability Spotlight: Foscam IP Video Camera Firmware Recovery Unsigned Image Vulnerability

This vulnerability was discovered by Claudio Bozzato of Cisco Talos.

Executive Summary

The Foscam C1 Indoor HD Camera is a network-based camera that is marketed for a variety of uses, including as a home security monitoring device. Talos recently identified 32 vulnerabilities present in these devices, and worked with Foscam to develop fixes for them, which we published the details of in two blog posts here and here. In continuing our security assessment of these devices, Talos has discovered an additional vulnerability. In accordance with our coordinated disclosure policy, Talos has worked with Foscam to ensure that this issue has been resolved and that a firmware update is made available for affected customers. This vulnerability could be leveraged by an attacker to gain the ability to completely take control of affected devices.

Vulnerability Details

Foscam IP Video Camera Firmware Recovery Unsigned Image Vulnerability (TALOS-2017-0378 / CVE-2017-2871)

Foscam C1 HD Indoor cameras provide multiple ways to recover from firmware corruption without requiring physical device access. One of the ways allows for the hosting of firmware images on a TFTP server. When the device reboots, it will look for a TFTP server present on the same subnet as the device. An attacker with access to the same subnet as the affected device could leverage this functionality to perform a firmware upgrade on the device without requiring authentication. This could be used to replace the device's firmware with a specially crafted image, and result in complete device compromise. TALOS-2017-0378 has been assigned CVE-2017-2871. For additional information, please see the advisory here.

Versions Tested

Talos has tested and confirmed that the following Foscam firmware versions are affected:

Foscam Indoor IP Camera C1 Series
System Firmware Version:
Application Firmware Version:
Plug-In Version:


One of the most commonly deployed IP cameras is the Foscam C1. In many cases, these devices may be deployed in sensitive locations. They are marketed for use in security monitoring, and many people use these devices to monitor their homes, children and pets remotely. As such, it is highly recommended that the firmware running on these devices be kept up-to-date to ensure the integrity of the devices, as well as the confidentiality of the information and environments that they are monitoring. Foscam has released a firmware update, available here, to resolve this issue. Users of affected devices should update to this new version as quickly as possible to ensure that their devices are not vulnerable.


The following Snort Rules will detect exploitation attempts. Note that additional rules may be released at a future date, and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your FireSIGHT Management Center or

Snort Rules: 43559

Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware in Recent Campaign


FireEye researchers recently observed threat actors leveraging relatively new vulnerabilities in Microsoft Office to spread Zyklon HTTP malware. Zyklon has been observed in the wild since early 2016 and provides myriad sophisticated capabilities.

Zyklon is a publicly available, full-featured backdoor capable of keylogging, password harvesting, downloading and executing additional plugins, conducting distributed denial-of-service (DDoS) attacks, and self-updating and self-removal. The malware may communicate with its command and control (C2) server over The Onion Router (Tor) network if configured to do so. The malware can download several plugins, some of which include features such as cryptocurrency mining and password recovery, from browsers and email software. Zyklon also provides a very efficient mechanism to monitor the spread and impact.

Infection Vector

We have observed this recent wave of Zyklon malware being delivered primarily through spam emails. The email typically arrives with an attached ZIP file containing a malicious DOC file (Figure 1 shows a sample lure).

The following industries have been the primary targets in this campaign:

  • Telecommunications
  • Insurance
  • Financial Services

Figure 1: Sample lure documents

Attack Flow

  1. Spam email arrives in the victim’s mailbox as a ZIP attachment, which contains a malicious DOC file.
  2. The document files exploit at least three known vulnerabilities in Microsoft Office, which we discuss in the Infection Techniques section. Upon execution in a vulnerable environment, the PowerShell based payload takes over.
  3. The PowerShell script is responsible for downloading the final payload from C2 server to execute it.

A visual representation of the attack flow and execution chain can be seen in Figure 2.

Figure 2: Zyklon attack flow

Infection Techniques


This vulnerability was discovered by FireEye in September 2017, and it is a vulnerability we have observed being exploited in the wild.

The DOC file contains an embedded OLE Object that, upon execution, triggers the download of an additional DOC file from the stored URL (seen in Figure 3).

Figure 3: Embedded URL in OLE object


Similarly, we have also observed actors leveraging another recently discovered vulnerability (CVE-2017-11882) in Microsoft Office. Upon opening the malicious DOC attachment, an additional download is triggered from a stored URL within an embedded OLE Object (seen in Figure 4).

Figure 4: Embedded URL in OLE object

Figure 5: HTTP GET request to download the next level payload

The downloaded file, doc.doc, is XML-based and contains a PowerShell command (shown in Figure 6) that subsequently downloads the binary Pause.ps1.

Figure 6: PowerShell command to download the Pause.ps1 payload

Dynamic Data Exchange (DDE)

Dynamic Data Exchange (DDE) is the interprocess communication mechanism that is exploited to perform remote code execution. With the help of a PowerShell script (shown in Figure 7), the next payload (Pause.ps1) is downloaded.

Figure 7: DDE technique used to download the Pause.ps1 payload

One of the unique approaches we have observed is the use of dot-less IP addresses (example: hxxp://258476380).

Figure 8 shows the network communication of the Pause.ps1 download.

Figure 8: Network communication to download the Pause.ps1 payload

Zyklon Delivery

In all these techniques, the same domain is used to download the next level payload (Pause.ps1), which is another PowerShell script that is Base64 encoded (as seen in Figure 8).

The Pause.ps1 script is responsible for resolving the APIs required for code injection. It also contains the injectable shellcode. The APIs contain VirtualAlloc(), memset(), and CreateThread(). Figure 9 shows the decoded Base64 code.

Figure 9: Base64 decoded Pause.ps1

The injected code is responsible for downloading the final payload from the server (see Figure 10). The final stage payload is a PE executable compiled with .Net framework.

Figure 10: Network traffic to download final payload (words.exe)

Once executed, the file performs the following activities:

  1. Drops a copy of itself in %AppData%\svchost.exe\svchost.exe and drops an XML file, which contains configuration information for Task Scheduler (as shown in Figure 11).
  2. Unpacks the code in memory via process hollowing. The MSIL file contains the packed core payload in its .Net resource section.
  3. The unpacked code is Zyklon.

Figure 11: XML configuration file to schedule the task

The Zyklon malware first retrieves the external IP address of the infected machine using the following:

  • api.ipify[.]org
  • ip.anysrc[.]net
  • myexternalip[.]com
  • whatsmyip[.]com

The Zyklon executable contains another encrypted file in its .Net resource section named tor. This file is decrypted and injected into an instance of InstallUtiil.exe, and functions as a Tor anonymizer.

Command & Control Communication

The C2 communication of Zyklon is proxied through the Tor network. The malware sends a POST request to the C2 server. The C2 server is appended by the gate.php, which is stored in file memory. The parameter passed to this request is getkey=y. In response to this request, the C2 server responds with a Base64-encoded RSA public key (seen in Figure 12).

Figure 12: Zyklon public RSA key

After the connection is established with the C2 server, the malware can communicate with its control server using the commands shown in Table 1.




Requests system information


Requests settings from C2 server


Uploads harvested passwords


Uploads harvested cryptocurrency wallet data


Indicates SOCKS proxy port opened


Cryptocurrency miner commands


Reports errors to C2 server


DDoS attack commands

Table 1: Zyklon accepted commands

The following figures show the initial request and subsequent server response for the “settings” (Figure 13), “sign” (Figure 14), and “ddos” (Figure 15) commands.

Figure 13: Zyklon issuing “settings” command and subsequent server response

Figure 14: Zyklon issuing “sign” command and subsequent server response

Figure 15: Zyklon issuing “ddos” command and subsequent server response

Plugin Manager

Zyklon downloads number of plugins from its C2 server. The plugin URL is stored in file in following format:

  • /plugin/index.php?plugin=<Plugin_Name>

The following plugins are found in the memory of the Zyklon malware:

  • /plugin/index.php?plugin=cuda
  • /plugin/index.php?plugin=minerd
  • /plugin/index.php?plugin=sgminer
  • /plugin/index.php?plugin=socks
  • /plugin/index.php?plugin=tor
  • /plugin/index.php?plugin=games
  • /plugin/index.php?plugin=software
  • /plugin/index.php?plugin=ftp
  • /plugin/index.php?plugin=email
  • /plugin/index.php?plugin=browser

The downloaded plugins are injected into: Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe.

Additional Features

The Zyklon malware offers the following additional capabilities (via plugins):

Browser Password Recovery

Zyklon HTTP can recover passwords from popular web browsers, including:

  • Google Chrome
  • Mozilla Firefox
  • Internet Explorer
  • Opera Browser
  • Chrome Canary/SXS
  • CoolNovo Browser
  • Apple Safari
  • Flock Browser
  • SeaMonkey Browser
  • SRWare Iron Browser
  • Comodo Dragon Browser
FTP Password Recovery

Zyklon currently supports FTP password recovery from the following FTP applications:

  • FileZilla
  • SmartFTP
  • FlashFXP
  • FTPCommander
  • Dreamweaver
  • WS_FTP
Gaming Software Key Recovery

Zyklon can recover PC Gaming software keys from the following games:

  • Battlefield
  • Call of Duty
  • FIFA
  • NFS
  • Age of Empires
  • Quake
  • The Sims
  • Half-Life
  • IGI
  • Star Wars
Email Password Recovery

Zyklon may also collect email passwords from following applications:

  • Microsoft Outlook Express
  • Microsoft Outlook 2002/XP/2003/2007/2010/2013
  • Mozilla Thunderbird
  • Windows Live Mail 2012
  • IncrediMail, Foxmail v6.x - v7.x
  • Windows Live Messenger
  • MSN Messenger
  • Google Talk
  • GMail Notifier
  • PaltalkScene IM
  • Pidgin (Formerly Gaim) Messenger
  • Miranda Messenger
  • Windows Credential Manager
License Key Recovery

The malware automatically detects and decrypts the license/serial keys of more than 200 popular pieces of software, including Office, SQL Server, Adobe, and Nero.

Socks5 Proxy

Zyklon features the ability to establish a reverse Socks5 proxy server on infected host machines.

Hijack Clipboard Bitcoin Address

Zyklon has the ability to hijack the clipboard, and replaces the user’s copied bitcoin address with an address served up by the actor’s control server.

Zyklon Pricing

Researchers identified different versions of Zyklon HTTP being advertised in a popular underground marketplace for the following prices:

  • Normal build: $75 (USD)
  • Tor-enabled build: $125 (USD)
  • Rebuild/Updates: $15 (USD)
  • Payment Method: Bitcoin (BTC)


Threat actors incorporating recently discovered vulnerabilities in popular software – Microsoft Office, in this case – only increases the potential for successful infections. These types of threats show why it is very important to ensure that all software is fully updated. Additionally, all industries should be on alert, as it is highly likely that the threat actors will eventually move outside the scope of their current targeting.

At this time of writing, FireEye Multi Vector Execution (MVX) engine is able to recognize and block this threat. Table 2 lists the current detection and blocking capabilities by product.

Detection Name

































Table 2: Current detection capabilities by FireEye products

Indicators of Compromise

The contained analysis is based on the representative sample lures shown in Table 3.













Table 3: Sample Zyklon lures

Network Indicators

Spectre and Meltdown from a CNO Perspective

Longtime readers know that I have no problem with foreign countries replacing American vendors with local alternatives. For example, see Five Reasons I Want China Running Its Own Software. This is not a universal principle, but as an American I am fine with it. Putting my computer network operations (CNO) hat on, I want to share a few thoughts about the intersection of the anti-American vendor mindset with the recent Spectre and Meltdown attacks.

There are probably non-Americans, who, for a variety of reasons, feel that it would be "safer" for them to run their cloud computing workloads on non-American infrastructure. Perhaps they feel that it puts their data beyond the reach of the American Department of Justice. (I personally feel that it's an over-reach by DoJ to try to access data beyond American borders, eg Microsoft Corp. v. United States.)

The American intelligence community and computer network operators, however, might prefer to have that data outside American borders. These agencies are still bound by American laws, but those laws generally permit exploitation overseas.

Now put this situation in the context of Spectre and Meltdown. Begin with the attack scenario mentioned by Nicole Perlroth, where an attacker rents a few minutes of time on various cloud systems, then leverages Spectre and/or Meltdown to try to gather sensitive data from other virtual machines on the same physical hardware.

No lawyer or judge would allow this sort of attack scenario if it were performed in American systems. It would be very difficult, I think, to minimize data in this kind of "fishing expedition." Most of the data returned would belong to US persons and would be subject to protection. Sure, there are conspiracy theorists out there who will never trust that the US government follows its own laws. These people are sure that the USG already knew about Spectre and Meltdown and ravaged every American cloud system already, after doing the same with the "Intel Management Engine backdoors."

In reality, US law will prevent computer network operators from running these sorts of missions on US cloud infrastructure. Overseas, it's a different story. Non US-persons do not enjoy the same sorts of privacy protections as US persons. Therefore, the more "domestic" (non-American) the foreign target, the better. For example, if the IC identified a purely Russian cloud provider, it would not be difficult for the USG to authorize a Spectre-Meltdown collection operation against that target.

I have no idea if this is happening, but this was one of my first thoughts when I first heard about this new attack vector.

Bonus: it's popular to criticize academics who research cybersecurity. They don't seem to find much that is interesting or relevant. However, academics played a big role in discovering Spectre and Meltdown. Wow!

Analyzing the Malware Analysts – Inside FireEye’s FLARE Team

At the Black Hat USA 2016 conference in Las Vegas last week, I was fortunate to sit down with Michael Sikorski, Director, FireEye Labs Advanced Reverse Engineering (FLARE) Team.

During our conversation we discussed the origin of the FLARE team, what it takes to analyze malware, Michael’s book “Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software,” and the latest open source freeware tools FLOSS and FakeNet-NG.

Listen to the full podcast here.