Malware RSS Feed
Industrial control systems (ICS) surround us: they are used in electric, water and wastewater, oil and natural gas, transportation, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods). Smart cities, smart houses and cars, medical equipment – all of that is driven by ICS.
Expansion of the Internet makes ICS easier prey to attackers. The number of ICS components available over the Internet increases every year. Taking into account that initially many ICS solutions and protocols were designed for isolated environments, such availability often provides a malicious user with multiple capabilities to cause impact to the infrastructure behind the ICS due to lack of security controls. Moreover, some components are vulnerable themselves. The first available information about vulnerabilities in ICS components is related to 1997, only two vulnerabilities were published that year. Since then the number of vulnerabilities significantly increased. Over the past five years this index has increased from 19 vulnerabilities in 2010 to 189 vulnerabilities in 2015.
Sophisticated attacks on ICS systems are not somewhat new anymore. It is worth remembering an incident in 2015 in Ivano-Frankivsk, Ukraine where around a half of houses were left without electricity because of a cyber-attack against the Prykarpattyaoblenergo power company, and it was only one of multiple victims of the BlackEnergy APT campaign.
Another notable incident, happened in 2015 and described in Verizon Data Breach Digest, is an attack on Kemuri Water Company’s ICS infrastructure, when intruders infiltrated a water utility’s control system and changed the levels of chemicals being used to treat tap water. The intrusion was performed through a vulnerable externally available system, that managed programmable logic controllers (PLCs) regulating valves and ducts that controlled the flow of water and chemicals used to treat it through the system.
Also in 2015 there were other ICS-related incidents, such as attacks on a steel mill in Germany and on the Frederic Chopin Airport in Warsaw.
In this research we provide an overview of the current situation with ICS security worldwide from the point of view of vulnerabilities, and vulnerable ICS components exposed to the Internet.Analysis Approach
The research is focused on two areas: Vulnerabilities and ICS Availability over the Internet. Vulnerabilities information gathering was carried out based on open sources, such as Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) advisories, NVD/CVE, SCADA Strangelove, Siemens Product CERT and other information available online. Severity levels for the vulnerabilities were assessed based on a Common Vulnerability Scoring System (CVSS) of the versions 2 and 3. CVSS v2 was used to compare vulnerability statistics in the years 2014 and 2015, and it was also used for any vulnerabilities that didn’t have CVSS v3 score assigned.
In the second part of research results (ICS Availability over the Internet) we used a passive approach for analysis based on information from the Shodan search engine. To identify ICS systems in Shodan search we used a fingerprint knowledgebase, containing about 2000 records and allowing to identify product vendors and versions by banners.Main Findings
- The number of vulnerabilities in ICS components keeps growing. With increased attention to ICS security over the last several years, more and more information about vulnerabilities in these systems is becoming public. However, vulnerabilities themselves could be present in these products for years before they are revealed. In total, 189 vulnerabilities in ICS components were published in 2015, and most of them are critical (49%) or have medium severity (42%).
- Vulnerabilities are exploitable. For 26 of the vulnerabilities published in 2015, exploits are available. Besides, for many vulnerabilities (such as hard-coded credentials) an exploit code is not needed at all to obtain unauthorized access to the vulnerable system. Moreover, our ICS security assessment projects show that ICS are often considered by their owners as a “black box”, so default credentials in ICS componenets are often not changed and could be used to gain remote control over the system. The SCADAPASS project of the SCADA Strangelove team provides a representation of known default ICS credentials. Currently information on 134 ICS components of 50 vendors is available.
- ICS vulnerabilities are widely diversified. New vulnerabilities were found in 2015 in the ICS components of different vendors (55 different manufacturers) and types (HMI, electric devices, SCADA, industrial network devices, PLCs and multiple others). The largest amount of vulnerabilities were found in Siemens, Schneider Electric and Hospira devices. Vulnerabilities in ICS components have a different nature. The most widespread types are buffer overflows (9% of all detected vulnerabilities), use of hard-coded credentials (7%) and cross-site scripting (7%).
- Not all of the vulnerabilities found in 2015 are fixed. Patches and new firmware are available for 85% of the published vulnerabilities, the rest are not fixed or are only partially fixed for different reasons. Most of the unpatched vulnerabilities (14 out of 19) are of high level risk. These unpatched vulnerabilities pose significant risk to the owners of the corresponding systems, especially for those who, due to inappropriate network configuration management, have their vulnerable ICS systems exposed to the Internet. Examples include the 11,904 remotely available SMA Solar Sunny WebBox interfaces that are under risk of compromise though hard-coded passwords. Although for Sunny WebBox this number has significantly reduced since 2014 (when over 80 thousand available components were found), the amount is still high, and the unfixed hardcoded credentials issue (published in 2015) is now putting these systems under a much higher risk than was previously thought.
- Numerous ICS components are available via the Internet. 220,668 ICS components were discovered by the Shodan search engine. They are located on 188,019 hosts in 170 countries. Most of the remotely available hosts with ICS components are located in the United States (30.5%) and Europe. Among European countries Germany has a leading position (13.9%) followed by Spain (5.9%). The available systems are of 133 different vendors. The most widespread ones are Tridium (11.1%), Sierra Wireless (8.1%), and Beck IPC (6.7%).
- Insecure protocols are widely used by remotely available ICS components. There is a number of protocols, which are open and insecure by design, such as HTTP, Niagara Fox, Telnet, EtherNet/IP, Modbus, BACnet, FTP, Omron FINS, Siemens S7 and many others. They are used on 172,338 different hosts, which corresponds to 91.6% of all the externally available ICS devices found. This provides an attacker with additional ways to compromise the devices by performing man-in-the-middle attacks.
- Multiple vulnerable ICS components are externally available. We found 13,033 vulnerabilities on 11,882 hosts (6.3% of all hosts with externally available components). The most widespread revealed vulnerabilities are Sunny WebBox Hard-Coded Credentials (CVE-2015-3964), and critical vulnerabilities CVE-2015-1015 and CVE-2015-0987 in Omron CJ2M PLC. Combining these results with statistics of usage of insecure protocols, we were able to estimate the total number of vulnerable ICS hosts as 172,982 (92%).
- Multiple industries are affected. We found that at least 17,042 ICS components on 13,698 different hosts in 104 countries likely belong to large companies, and availability of these components from the Internet is likely related with significant risks. Among owners we were able to identify 1,433 large organizations, including ones belonging to the following industries: electricity, aerospace, transportation (including airports), oil and gas, metallurgy, chemical, agriculture, automotive, utilities, drinks and food manufacturing, construction, liquid storage tanks, smart cities, and ICS vendors. There are also research and education entities, government institutions (including police), medical centers, financial organizations, resorts, hotels, museums, libraries, churches and multiple small businesses among identified owners of remotely available ICS. The number of vulnerable externally available ICS hosts, which likely belong to large organizations, is 12,483 (91.1%), where 453 hosts (3.3%), including hosts belonging to energy, transportation, gas, engineering and manufacturing organizations, drink and foods manufacturing, energy and transportation organizations, contain critical vulnerabilities.
ICS vulnerabilities by year
ICS vulnerabilities in 2015 by risk level (CVSS v.2 and CVSS v.3)
TOP 20 countries by ICS availability
TOP 15 protocols used by externally available ICS components
TOP 5 vulnerabilities on ICS components
ICS availability by vendor
The above results are only lower bound estimations, and real number of available ICS components associated with significant risks could be much higher.Conclusion
Where protection is concerned, the isolation of critical environments can no longer be regarded as a sufficient security control for ICS. The business requirements of the 21st century often make it necessity to integrate ICS with external systems and networks. In addition, the capabilities, motivations and number of threat actors focusing on ICS environments are increasing. From infected hard drives or USB sticks, to unauthorized connections from ICS networks to the Internet through personnel smart phones or modems, and from infected distributive kits obtained from vendors, to a hired insider – all of these methods are available to highly-skilled intruders planning an attack on a physically and logically isolated ICS network.
Nowadays, ICS owners should be aware of modern vulnerabilities and threats, and actively improve the security of their ICS environments based on this knowledge. Here, active vendor support is crucial for the prompt identification and remediation of vulnerabilities in ICS products, as well as for sharing workarounds to protect systems before patches are released.
The specifics of ICS – that its cybersecurity is closely tied with physical safety – often receives an attitude opposite to the demandable treatment in such conditions. Small and medium businesses, as well as individuals, completely rely on vendors when it comes to security of the Internet of Things. The consumers don’t go beyond simple basic steps from device manuals, thus obtaining ready-to-work and easily accessible, but also vulnerable devices. On the contrary, in the enterprise area, companies understand the high risks, which are related with incorrect configuration of ICS environment. However, because of that system owners often consider ICS devices as “black-boxes”, and have a dread to make changes in the environment, including cybersecurity enhancement.
The findings of this research are an additional reminding that the “Security through Obscurity” principle cannot serve as a good basis to achieve effective protection from modern attacks, and that industrial control systems security should not be treated superficially in favor of safety, especially because the security and safety in this area are inextricably connected.
Dropping Elephant (also known as “Chinastrats”) is a relatively new actor targeting a variety of high profile diplomatic and economic targets using a custom set of attack tools. Its victims are all involved with China’s foreign relations in some way, and are generally caught through spear-phishing or watering hole attacks.
Overall, the activities of this actor show that low investment and ready-made offensive toolsets can be very effective when combined with high quality social engineering. We have seen more such open source toolset dependency with meterpreter and BeEF, and expect to see this trend continue.The Attack Method: Infection Vector
Dropping Elephant uses two main infection vectors that share a common, and fairly elaborately maintained, social engineering theme – foreign relations with China.
The first approach involves spear-phishing targets using a document with remote content. As soon as the user opens the document, a “ping” request is sent to the attackers’ server. At this point, the attackers know the user has opened the document and send another spear-phishing email, this time containing an MS Word document with an embedded executable. The Word document usually exploits CVE-2012-0158. Sometimes the attackers send an MS PowerPoint document instead, which exploits CVE-2014-6352.
Once the payload is executed, an UPX packed AutoIT executable is dropped. Upon execution, this downloads additional components from the attackers’ servers. Then the stealing of documents and data begins.
The second approach involves capturing victims through watering hole attacks. The actor created a website that downloads genuine news articles from other websites. If a website visitor wants to view the whole article they would need to download a PowerPoint document. This reveals the rest of the article, but also asks the visitor to download a malicious artifact.
The two main infection vectors are supported by other approaches. Sometimes, the attackers email out links to their watering hole websites. They also maintain Google+, Facebook and twitter accounts to develop relevant SEO and to reach out to wider targets. Occasionally, these links get retweeted, indiscriminately bringing more potential victims to their watering holes.The Attack Tools 1. Malware Analysis
The backdoor is usually UPX packed but still quite large in size. The reason for this is that most of the file comprises meaningless overlay data, since the file is an automatically generated AutoIT executable with an AutoIT3 script embedded inside. Once started, it downloads additional malware from the C2 and also uploads some basic system information, stealing, among other things, the user’s Google Chrome credentials. The backdoor also pings the C2 server at regular intervals. A good security analyst can spot this while analyzing firewall log files and thereby find out that something suspicious might be going on in the network.
Generally speaking, backdoors download additional malware in the form of encrypted or packed executables/libraries. But, in the case of Dropping Elephant, the backdoor downloads encoded blobs that are then decoded to powershell command line “scripts”. These scripts are run and, in turn download the additional malware.
One of the more interesting malware samples downloaded is the file-stealer module. When this file-stealer is executed, it makes another callback to the C2 server, downloading and executing yet another malware sample. It repeatedly attempts to iterate through directories and to collect files with the following extensions: doc, docx, ppt, pptx, pps, ppsx, xls, xlsx, and pdf. These files are then uploaded to the C2 server.
Also interesting are the resilient communications used by this group. Much like the known actors Miniduke or CommentCrew, it hides base64 encoded and encrypted control server locations in comments on legitimate web sites. However, unlike the previous actors, the encrypted data provides information about the next hop, or the true C2 for the backdoor, instead of initial commands.2. C2 Analysis
In many cases it was very difficult to get a good overview of the campaign and to find out how successful it is. By combining KSN data with partner-provided C2 server data, we were able to obtain a much fuller picture of the incident.
We examined connections and attack logins to this particular C2. As it turned out, the attackers often logged in via a VPN, but sometimes via IPs belonging to an ordinary ISP in India. We then looked at the time the attackers were active, of which you can find an image below.
We also wanted to get a better idea of the geolocation of most visitors. Analysis of the image provided access counts and times, along with the IP of the visiting system.
Noteworthy are the many IPs located in China. This focus on China-related foreign relations was apparent from the ongoing social engineering themes that were constant throughout the attacks. The concentration of visits from CN (People’s Republic of China) could be for a variety of reasons – diplomatic staff are visiting these sites from their CN offices, CN academics and analysts are very interested in researching what they believe to be CN-focused think tanks, or some of the IPs are unknown and not self-identifying as bots or scrapers. Regardless, because we were able to determine that multiple targets are diplomatic and governmental entities, these foreign relations efforts are likely to represent the main interest of the attackers.Conclusion
Campaigns do not always need to be technically advanced to be successful. In this case, a small group reusing exploit code, some powershell-based malware and mostly social engineering has been able to steal sensitive documents and data from victims since at least November 2015.
Our analysis of the C2 server confirmed the high profile of most victims, mainly based in the Asian region and specially focused on Chinese interests. Actually, some hints suggest the group has been successful enough to have recently expanded its operations, perhaps after proving its effectiveness and the value of the data stolen.
This is quite worrying, especially given the fact that no 0 days or advanced techniques were used against such high profile targets. Simply applying software patches will prevent attacks based on old exploits, as well as training in the most basic social engineering attacks.
However, it should be noted that in this case Microsoft´s patch for exploit CVE-2014-1761 just warns the user not to allow the execution of the suspicious file.
Dropping Elephant artifacts are detected by Kaspersky Lab products as:
As usual Kaspersky Lab actively collaborates with CERTs and LEAs to notify victims and help to mitigate the threat. If you need more information about this actor, please contact firstname.lastname@example.org
More information on how Kaspersky Lab technologies protect against such cyberespionage attacks is available on Kaspersky Business blog.Indicators of Compromise Backdoors
Virtualization marches victoriously across the globe, adding to its list of champions not only individual IT-specialists and businesses, but even whole sections of the IT industry. In fact, it’s barely possible to find a data center with only physical servers on board: both electricity and physical space are far too expensive nowadays to be used so inefficiently.
Meanwhile, the possibility of hosting multiple servers on a single physical machine is just one benefit among all those offered by virtualization.
Second only to servers, the most important application of today’s virtualization technologies is probably Virtual Desktop Infrastructure, or VDI. While using the same concept of multiple computers hosted inside a single physical ‘body’, its purpose is entirely different from server virtualization: to substitute a heterogeneous and cumbersome ‘zoo’ of physical desktops with homogenous and easily controlled virtual environment.
As opposed to familiar – and age-old – Terminal Services infrastructure, offering shared access to the same machine running a single instance of an operating system, VDI is about ‘genuine’ virtualization. Every single virtualized workstation has its own set of virtual hardware, OS and applications – and its own range of potential security issues. There tends to be a much higher probability, too, of encountering security issues with VDI than with virtualized servers. This is especially true in scenarios which include access to the ‘Big Internet’, with its landscape of threats and hordes of marauding cyber-predators, always hungry for other people’s data and money. And God help you, if you buy into the myth about virtual environments being inherently more secure than physical ones! The exact opposite is true: not only they are similar in terms of threat levels; virtual environments possess some specifics that actually make the task of securing them even more complex.
This is what we are going to talk about here: about VDI myths, specifics – and how to provide proper security for corporate VDI, without compromising any of its many benefits.VDI: Pros and Cons The Pros
Before plunging deep into problems associated with VDI, it might be useful to remind ourselves of the benefits that have earned the technology the undying love of both sysadmins and ITSec specialists.
- VDI is effectively agnostic of the end-user’s hardware and software. The only requirement for any client device, be it a regular PC, a smartphone or a thin station, is the ability to run a client application (in some cases, even a simple web browser will do).
- VDI offers a considerably higher level of data security. With all the valuable information stored deep inside the corporate infrastructure or in a datacenter, many data loss scenarios, like device theft or physical loss, are ruled out.
- VDI environments are highly flexible in management terms: every virtualized workstation and application can be deployed and controlled with an ease and speed that’s unattainable for purely physical infrastructures. With finely tuned working practices, it may not even be necessary to solve any problems associated with a given virtual machine: just killing the VM and spawning it back from the template can be enough. All user data can then be re-accessed from centralized storage once the user logs back in.
This list of VDI benefits is clearly incomplete. But even these key points are enough for some businesses requiring high mobility accompanied by strong data security to embrace the concept with eagerness. Typical examples are healthcare, insurance and, in some regions, banking; business processes taking place in these industries are highly regulated and easily formalized, which greatly simplifies the task of VDI implementation.The Cons
Unfortunately, no solution consists entirely of benefits – and VDI has its range of nuances and limitations to be mindful of.
- VDI is highly sensitive to resource consumption. Virtual environments are designed so that users can perform tasks in a way that’s very similar to using regular PCs. But, even when a limited number of software titles are used for a limited number of tasks, some can not only be resource-hungry, but can have a considerable adverse impact on VDI performance in particular. Few things are more demotivating to a workforce than system lags and general unresponsiveness; as well as unnerving and irritating people, this can easily kill off all the efficiency gains delivered by VDI deployment. So it’s necessary to consider and to constantly monitor all the influences on system responsiveness – including the impact of security solutions.
- VDI works better with formalized business processes. VDI is most easily justified when business processes are predictable, and all the applications used are known. If this is not the case, resource consumption and overall performance calculations can suddenly prove misleading or just plain wrong. The threat to corporate security posed by the unrestricted use of unknown applications, or course, presents a threat to corporate security, as well as compromising the accuracy of performance predictions.
- VDI presents complex requirements for deployed security solutions. As opposed to attacks on data-storing servers and similar scenarios where the main target is remotely accessible data, virtualized workstations are subject to practically the same spectrum of threats as those targeting physical machines. These threats can include, for example, ‘bodiless’ malware using exploits to inject malicious code into legitimate processes and running entirely in the system’s volatile memory. Unfortunately, the majority of well-known specialized solutions claiming to cater for the specific requirements of virtualized environments offer protection at file system level only, which is far from adequate for VDI defense.
Of course, installing a security solution designed for physical desktops, perhaps modified to be ‘virtualization-friendly’, is an option. But this may well result in considerable increases in resource consumption, drastically reducing VDI efficiency. These solutions involve each virtual machine (VM) carrying its own set of engines and databases, each updating independently from its neighbors. In a worst case scenario, a solution’s failure to demonstrate sufficient ‘virtualization awareness’, can result in ‘activity storms’, where multiple simultaneous updates or scanning processes create an avalanche of increased resource consumption, bringing the entire host to a grinding halt.Myths and Threats
Despite virtual desktops being very similar to their physical counterparts in terms of functionality, the misconception that they are less susceptible to infection is quite widespread amongst users and even IT professionals. Some of the arguments used may look like these:
- Malware itself is afraid of virtual machines, suspecting them of being sandbox systems or researchers’ machines. So, when the malware detects that it’s being launched in a VM, it won’t activate.
- In a properly configured VDI, the VM itself is of no value. If an infection strikes, it’s just a matter of killing off the infected machine, with no need to bother about the malware itself.
Let’s see what stands behind these assertions, and how safe it is to base your approach to VDI security on them.VM as Malware’s Scarecrow
This argument is based on something that’s actually quite true: many malware specimens do check for signs that they’re being launched inside a VM. But what happens next is not so predictable. Malware creators are keenly aware that these VMs are usually NOT sandboxes and can contain valuable data – or can serve as entry points to entire IT networks. So they’re rapidly learning to tell sandboxes from less sophisticated VMs. For this, an extensive range of indicators can be used: previously investigated IP addresses of researchers’ systems, typical user and computer names, unnecessary system components missing or removed to reduce resource usage – and so on. There are also more advanced tricks and indicators to detect sandboxes, such as leaving some kind of token in the file system or repeated communications with C&C throughout the whole attack cycle (which won’t happen during sandboxing) etc. And there are also directly controlled targeted attacks, during which the command for proceeding (or withdrawing) is issued by living people, based on acquired intelligence.
The bottom line is this: some malware, and only some, may refuse to start in a VM. It would be extremely foolish to rely on this when building a security system for corporate VDI (which is even more susceptible to infection than server VMs).No machine – no infection?
The main flaw in this argument lies in the perception of the infected machine as an isolated instance. Any infection can involve multiple VMs residing in the same network segment: if just one contracts malware, especially given the lightning-fast speed of a virtualized network, the contagion can spread like wildfire. It doesn’t matter if the original infected machine is killed – the process of cross-infection within a network segment with sufficient vulnerable nodes can theoretically go on forever. Or, more precisely, it can go on until the moment when the whole network segment shuts down entirely.
And another thing. With the initial infected machine consigned to oblivion, traces of the initial infection – all too precious for restoring a full picture of the attack during investigations – will be lost forever.
It’s also worth bearing in mind that some more advanced malware specimens can be remarkably adept at evading detection. Specialized security solutions working only at file system level, without the capability to watch over processes in memory, can give the malware plenty of time to do its job (e.g. syphoning away the data it has found) before the VM is deleted.
Obviously, if the infection is spotted after any malicious files may have been dropped into the file system, mercilessly killing off the affected VM is no guarantee that you have stopped the infection in its tracks.The Boundless Sea of Threats
We have said that virtual desktops are susceptible to almost the same spectrum of threats as are physical machines. But what about specialized attacks, targeting the specific vulnerabilities of virtualized environments?
Well, there is no shortage of Proof-of-Concept demonstrations, as shown during security conferences and described on the internet. Potentially, such malware could do considerable harm, but… there are as yet no officially registered cases of such attacks being spotted in the wild. Still, there’s no reason to be over-optimistic. The most important driver to innovation in any area – including the creation of malware – is the existence of an obvious demand. Once the penetration rate of virtualized assets reaches a critical point, the in-lab theoretical threat could become a reality in no time. And here we’re talking about the more common threats; if there’s a requirement to attack a particular VDI in order to get to a particularly valuable piece of data (and the money to sponsor such a complex attack)… well, any kind of technology can be put to use, including fully customized designs that are completely unknown to the general public.
Even without the attack scenarios we anticipate in the immediate future, there is enough malware right now to provide VDI owners with the same problems that physical IT network owners already experience.VDI Defense: Strategy and Tactics
Protecting VDIs is mandatory, and no mythical inherent resilience offers a legitimate defense against the existing threat landscape. So, how do we approach this task appropriately – and what stratagems can be used to best preserve all the beneficial effects of VDI deployment?Configure Safely!
As we all know, the most dangerous vulnerability in any system is people. And we’re not only talking about careless office staff, mindlessly clicking on links and opening files received from strangers. This also applies to those equally careless IT specialists who configure their systems in ways that leave gaps for intruders to abuse.
So, what screws can be tightened to make the conditions as uncomfortable as possible for any attacker? Here are several examples which, theoretically, are applicable to both physical and virtualized networks.
- Forbid any type of local authorization using domain policies. This can be especially useful for ‘disposable’ VMs, which are created and deleted on demand: the task of fixing a faulty machine, which could require a local login procedure, is not a viable option.
- Whenever the business process allows this, reduce the user’s capability to run unsolicited programs to a minimum, perhaps going as far as deploying a Default Deny scenario. Given the known specifics of particular industries where VDI technology is most popular (like healthcare or insurance), the implementation of such a scenario can be undertaken without much hassle.
- Rule out the use of Java and other command interpreters, including Powershell and even CMD.EXE, if business processes don’t explicitly rely on them. Java remains one of the most exploited components of any system, and script chains are gaining in popularity as a ‘legit’ way of circumventing detection and even application control mechanisms.
- If the network configuration permits, use Private VLANs to isolate VMs from one another. In the majority of business scenarios, there’s no need for VMs to see one another on the network: they only need access to particular servers and network services – and to the internet if required. Such a configuration can considerably reduce the possibility of infection spreading. Though it’s worth bearing in mind that, in some cases, this would require the physical switchers to support PVLANs as well. But even then, as part of a Software-Defined Networks paradigm, there are virtual switches which prevent the flooding of physical switches without PVLAN support residing in the same IT network.
Private VLANs provide a simple way of selectively isolating VMs without exhausting IP subnets.
Taking into account the rapidly changing threat landscape, VDI protection should not be in any way inferior to defenses used for regular machines, especially if work undertaken includes accessing the big internet.
This means that, besides traditional signature-based protection or even advanced file-level protection based on heuristic algorithms, any solution should be armed with behavioral detection technologies and some means of exploit mitigation. And this can only be considered a bare minimum; ideally, the solution should possess additional proactive security layers such as application control, web control and device control.The Conventional Approach
This can readily be achieved by installing regular security solutions using full-weight agents, initially designed for the protection of physical workstations. However, as discussed earlier, even if adjustments have been made to cope with specific aspects of virtual environments, the issue of excessive resource consumption requires a fundamentally different approach.The Agentless Approach
One such approach leverages VMware’s vShield (and now NSX) technology, and so can only be adopted for VMware based environments. The ‘Agentless’ approach conducts all security activity in a single Security Virtual Machine (or SVM) on the virtual host, using VMware’s own technologies to communicate with and protect the individual VMs.
With signature updates and scanning engines held on just one SVM per host, instead of on every VM that the host is servicing, the resource savings compared with full-agent protection, in terms of both space and processing power, are considerable. And with just one SVM being updated, instead of all those individual machines, traffic is drastically reduced and ‘AV storms’, where lots of machines all try to update or perform malware scanning simultaneously, are eliminated.
For IT environments with no direct external exposure, particularly where foreign agents are not permitted onto clients’ machines – in a data centers for example – the agentless approach is an excellent solution. But, for VDI environments, such as VMware’s own Horizon, where individual machines are so much more exposed, this approach is definitely not sufficient in terms of security. This is primarily because an agentless approach does not allow the security solution any direct access to or control of processes in the individual machine’s memory.The Lightweight Agent Approach
But there are specialized solutions providing high levels of security AND also operating as an organic element of the virtualized infrastructure, without duplication and resource wastage. The answer lies in solutions using lightweight agents.
Like agentless solutions, this approach also employs a dedicated ‘Security Virtual Machine’ (SVM), which does away with duplicated copies of scanning engines and databases residing on every single protected VM. Instead of relying on the vShield or NSX technology layer, however, this approach employs lightweight program agents, so that the solution can not only reach into the individual VMs’ systems on behalf of the SVM, but can also control processes in the machines’ memory, allowing for behavioral detection by other advanced technologies. And, of course, this approach is not tied to VMware technology, but can be applied to other platforms, including Citrix, Microsoft and KVM.
Solutions built using this principle also allow for the provision of additional security layers.
For example, in our Kaspersky Security for Virtualization | Light Agent, the following technologies are implemented:
- Application Control (powered by cloud-based Dynamic Whitelisting)
- Web Control (with cloud-supported Web Resource Categories)
- Device Control
- Network Attack Blocker (a network IDS/IPS protecting from network-based attacks and exploits)
- HIPS (Host-Based Intrusion Prevention System)
- Firewall (working on multiple OSI levels including Application)
- Anti-phishing (backed by cloud-based reputational service and autonomous heuristics)
(More details about Kaspersky Security for Virtualization | Light Agent can be found here.)
All these protective layers provide much greater levels of security in defense of endpoints which, virtualized or not, remain the primary targets for attackers. Of course, every further security layer requires additional resources, but, with the majority of resource-heavy processes being relocated to the SVM, the deployed lightweight agents can easily remain quite slim.
Such architectures also ensure higher fault tolerance. Should an SVM become unavailable for a period of time, additional security layers won’t leave the machines completely unprotected. In addition, the system event data obtained can be stored locally for later analysis after re-establishing connection with the SVM – or being temporarily rerouted to another SVM on the same network.
Such solutions are initially designed to be fully aware of all virtualization’s unique requirements – and the specifics of VDI in particular, including mechanisms like machine migration or Linked Clones. Properly designed lightweight agents can also be easily embedded into VM templates, allowing instant protection immediately after machine activation.
All these mechanisms and their outcomes and benefits have been tested, in the case of Kaspersky Security for Virtualization | Light Agent, with popular VDI systems including VMware Horizon and Citrix XenDesktop in ‘real life’ conditions.Heterogeneous environments
Since the connection between the agents and the SVM doesn’t require any platform-dependent intermediate layers, it’s possible not only to protect different virtualization platforms with ease, but also to cover heterogeneous environments with a single solution. This removes the necessity of having different management consoles for each platform solution, and considerably simplifies the management process for IT security specialists, saving time and reducing the probability of human error.Conclusion
The global transition into virtualized space is still ongoing, and the number of VDI scenarios is growing every day. Even complex, resource-hungry tasks like graphic processing or software development, which were only recently being described as ‘future tech’, are a current reality. Unfortunately, it’s often impossible to formalize complex business processes using strict policies – so there are always ‘soft spots’ in any given system. These soft spots in virtual infrastructure need to be hardened using specialized security solutions combining both traditional and innovative, proactive protection methods. This combination is most commonly found in solutions using lightweight agents – which, given the existing threat model, become a natural choice for VDI protection.
Whilst sitting and working in the South African office I receive an email from my Swedish ISP. I quickly look at it and there is something that doesn’t add up. The email states that I need to pay my invoice, but I never receive electronic invoices from this company.
Like everyone else I receive a lot of spam and phishing emails, but this one is different from any other phishing email I have ever seen before. To be honest, it’s probably the most sophisticated phishing campaign that I’ve ever encountered. It’s not the technical setup that makes it sophisticated it is a very simple factor that has been added to the email that just makes the email look very authentic.
The phishing campaign has the usual mistakes, the sender of the email is not related to the company, and the domains used in the links don’t point to a domain that is registered by the ISP.
There has been a huge increase in these kind of phishing emails lately but it’s the first time I have seen these emails. What makes this campaign so interesting is that they have not just addressed the email to me, but also included my child’s name. This is something I have never seen before. How they got access to my child´s name is not sure, one speculation is that they compromised a Swedish governmental agency, but this has to be left unconfirmed.
What happens when you click on the link is it will redirect you to a website. This website will enumerate from your country of residence to make sure that you are actually a Swedish victim. Additional to this, it will enumerate your browser by analysing the User-Agent string.
Why they check the Operating System is because the next step in the campaign is to trick you into downloading a Windows executable. We are currently investigating what the malware is doing, but from our previous research it seems that it’s some kind of Cryptolocker.
The download page looks very authentic, it even uses the domain teliafakturor.net (translated to teliainvoices.net), with a little captcha. When you click on the download button you will be offered a ZIP-file.
When analysing the landing pages and the source code i found something that was quite interesting. The language of the HTML editor that was used is Russian, and some of the domains are registered to an email address, which has registered other domains in Russia. This might be an indicator that the persons behind this scam has Russian origin.
Recently, our colleagues questioned the security of charging mobile devices via USB ports. They discovered that if there were a computer behind the port, there would be a data exchange, even when the mobile is blocked. We became curious – is it possible to measure the energy consumption of the “host + mobile” system during handshakes? Also, is it possible to estimate the impact on energy consumption when we separate the charging process from data exchange using the Pure.Charger device?
As it turned out, it wasn’t too hard to measure energy consumption – all it takes is a commercially available multimeter, preferably, with serial connection to a computer, which would allow you to analyze logs in a convenient manner. It was possible to provide a rough estimate of how much energy is dissipated during handshakes and to estimate to a known degree of certainty the amount of energy required to send one bit of data over the USB connection.A little bit of theory
Dissipation of electrical energy into heat is due to two key reasons, the first being the imperfection of even the most modern computers and the second being the irreversibility of classic (non-quantum) computing.
The fundamental limit on energy consumption can be estimated using Landauer’s principle, first introduced in 1961: ∂Q = dS · T = kTln(2), which is equal to roughly 3×10-21 Joules (J) at room temperature. In reality, computation and, especially, data transfer is much more energy-hungry. We learned from a 2014 review by Coroama and Hilty, published in Environmental Impact Assessment Review, that it takes approximately 4×10-7 Joules per bit to transfer data over the Internet. That is 14 orders of magnitude above the fundamental limit.
Unfortunately, we haven’t been able to find similarly thorough and high-quality reports on energy consumption during USB data transfer. So, we decided to perform our own experiment.Experiment
We have used various combinations of host systems and mobiles.Notebooks Operating System Apple MacBook Pro OS X 10.10.5 Dell Latitude E6320 Windows 7 64-bit Enterprise Edition
To which we’ve been connecting these mobile phones:Mobile device Platform Samsung GT-i9300 (Galaxy S3) Android 4.4 LG Nexus 6X Android 6.0.1 Apple iPhone 4s iOS 9.2.1
The choice of mobiles was dictated by the fact that Android 6 mobiles behave themselves differently than smartphones on earlier versions of Android. They have a built-in protection from USB data transfer, enabling “charge-only” mode by default upon connection to a USB port. However, since we already knew from the previous research that a handshake, nonetheless, occurs in this setting, too, we wanted to check the energy consumption of phones during handshakes. We also wanted to discover the difference in behavior of mobiles based on different versions of Android and iOS.
Diagram of the experiment set-up in the MacBook Pro experiment
Experimental set-up in the Dell Latitude E6320 experiment
Our simple experiment, in essence, was to measure the current flowing through the wire that connects the system, which comprises a host, a connected mobile, and a power outlet. We designed this experiment in such a way, on one hand, to ensure the reproducibility of its results and, on the other hand, to avoid damaging the computer’s power adapter. Thus, we also tested the stability of the frequency and voltage of the alternating current and saw no dependence of these two parameters from the data exchange.
Since the multimeter provided us with RMS (root mean square) values of the alternating current within finite time intervals, the amount of consumed energy can be approximated by a sum of products of current IRMS average value of voltage URMS and time interval duration δt. We have used the RMS values of current in all our calculations instead of amplitude (I0 = IRMS *√2), because, by definition, the RMS value is equivalent to a value of DC current that dissipates the same amount of heat on the same resistive load.Results Handshakes
In order to exclude the charging current’s influence on multimeter readings, the mobiles and laptops which we used as host computers, were fully charged. Furthermore, we used a Pure.Charger device, which allows us to turn the USB data lines on and off as desired. The sequence was the following: first we connected the Pure.Charger to the host computer’s USB port and then we introduced the mobile device to Pure.Charger’s output USB port. By doing so, we effectively separated the moment of connection to the USB port and the moment when data lines were enabled.
In the graph below you can see the consumption current dynamics (in mA) when a Nexus 5X was connected to a MacBook Pro host:
Here we see two distinct peaks of current, first when the phone is connected to a data line in “charge-only” mode, and second – when the MTP mode is enabled.
Current consumption dynamics for the connection of an unblocked Samsung S3 looks like this:
Here we see a single large consumption peak – because the phone is not blocked, it starts an MTP session right after it’s connected to the port.
The graph below we obtained with an iPhone 4S and a Latitude E6320 with the same settings:
The main consumption peak, due to the handshake between the Latitude E6320 and iPhone 4S, is preceded by a smaller spike, which corresponds to a handshake between the Latitude E6320 and Pure.Charger. As the amount of energy consumed during the handshake is proportional to the area below the curve, it can be seen that the amount of energy consumed due to the handshake of the host with Pure.Charger is significantly lower that the amount consumed due to the handshake with the iPhone 4S.
The experiment with the Latitude E6320 and iPhone 4S is the only one where Pure.Charger’s handshake is clearly seen – it is not distinctly observed in other experiments. The Pure.Charger’s consumption current, as obtained in the series of the experiments, does not exceed the idle current standard deviation for both the MacBook and the Latitude E6320.
The value of current fluctuations in the Latitude E6320 experiment (standard deviation was equal to 7-8 mA) was greater than current fluctuations in the MacBook experiment (standard deviation was equal to 4 mA). There are two reasons for this. Firstly, the Latitude E6320 was built using HDD and the MacBook Pro that we used was built using SSD. Secondly, in the corresponding experiment the Latitude E6320 was used both as a host and as a logging system.Data transfer
In order to learn more about how much energy is required to send a unit of data over a USB connection, we had the hosts and the mobiles transfer files of a specified size to one another.Fixed amount of data
The dynamics of the consumption current, in mA, for the Nexus 5X that was tasked with transferring 391 MB of data to the MacBook host, looked like this:
Here we observe the same two consumption peaks specific to an Android 6-based device, and an increase in the average consumption current during data transfer.
This is how the consumption current depends on time in an experiment where the MacBook Pro was reading 188 MB of data from Samsung S3:
Here we see a sharp single peak corresponding to a handshake with Samsung S3, a distinct start and finish of file transfer with increased consumption current, and a small spike in the current when the phone is disconnected, which is due to the system closing processes and windows which were active when the phone was connected.
We have carried out multiple similar experiments. As expected, the time interval elapsed for file transfer, was dependant on the file size – the larger the file, the longer it takes to send it through the USB channel.Energy consumption dependence on the direction of data transfer
Does energy consumption depend on the direction of data transfer? We set up an experiment during which a group of files of the same size was sent to the host from the mobile, and vice versa, and measured the system’s consumption current. Because it’s impossible to send the files directly to an iOS-based mobile, this experiment was performed only with Android-based systems.
The left-hand graph shows the consumption current dynamics (in mA) when the Latitude E6320 is connected to the Samsung S3 and reads 808 MB of data. The graph on the right shows the current consumption when the Latitude E6320 sends the same amount of information to the Samsung S3. Despite the noise specific to the Latitude E6320 series of experiments, the moments of file transfer start and finish are seen clearly.
We carried out six similar experiments and came to the following conclusions:
- The average value of consumption current while sending data from the host to the mobile is lower, and this decrease is greater than the standard error.
- Meanwhile, the time elapsed for sending the file from a host to a mobile is longer than the time elapsed for receiving the same-sized file by a host from a mobile. This time interval increase is roughly the same as the decrease in average consumption current.
Taking into account that the voltage was the same, the energy consumption can be estimated as a product of voltage times average current and times the length of the time interval. The estimated values of energy consumption for data transfer from mobile to host and from host to mobile were effectively in the same confidence interval.Energy consumption per unit of information
In order to approximate the dependence of consumed energy on the size of data we made two assumptions:
- The amount of energy required to transfer a unit of data depends only on the type of host and mobile.
- The amount of energy required to transfer a known amount of data is directly proportional to the size of data sent. This assumptions is probably not correct, because communication systems, and USB in particular, are optimized for sending data in bulk, thus the smaller the amount, the less energy is required to transfer it. However, there are accompanying computational processes that don’t go away. Therefore, it would be more accurate to approximate this dependence with a power function with fractional index. But the difference between linear approximation and such a power function would be significant for smaller amounts of data.
Under these assumptions, we have estimated that the most energy-efficient pair is the MacBook Pro connected with the Samsung S3 – they dissipate only (3.3±0.2)x10-8 Joules per bit, and the most power-hungry combination was the Latitude E6320 with the iPhone 4S, which dissipated (9.8±0.6)x10-8 Joules per bit.
The amount of energy required to transfer a unit of information through the USB channel is within the range of 3.1×10-8 to 1.4×10-7 Joules per bit. Remember the article we cited in the beginning? Their assessment (for transfer of Internet data) was 4×10-7 Joules per bit, which means that our assessment for USB connections is within the same order of magnitude.
Still, there are two more things to consider for further research. First, data transfer during handshakes is different from file transfer as it involves more computational processes and thus leads to greater consumption of system energy. Second, the dependence of energy consumption on the size of transferred data is presumably not quite linear, and for better accuracy should be approximated with a convex function. A better approximation requires more data points and more pairs of hosts and mobiles to be investigated.Economy of scale
To sum it all up, I’d like to estimate the ratio of energy consumption caused by handshakes to the energy that is consumed while charging a mobile device. A typical charge on a 2 A current would last 20 to 40 minutes, which means that a mobile receives anywhere from 12 to 24 kJ of energy when charging. Therefore, blocking the handshakes that waste a few to dozens of Joules, allows for saving tenths to hundredths of a percent of this energy. A single user would not even notice this effect, but if all the folks living in New York used a Pure.Charger, they would save a whopping 33 Kilowatt-hours of electricity every day! To give you an idea of how much this is – Tesla electric cars can drive over 100 miles on this charge. This may not look like a big deal for a mega polis, but it’s a noticeable effect, isn’t it?
We will continue to research the physical characteristics of mobile devices during data exchange, both from a security perspective and in search of more data points. We welcome readers to reproduce this experiment themselves and report their findings!
This material uses experimental results submitted for publication in IEEE Transactions on Mobile Computing. The preprint is available here.