Microsoft’s Edge browser blocks the highest percentage of socially engineered malware (SEM) and phishing attacks compared to Google Chrome and Mozilla Firefox, newly published NSS Labs reports reveal.

The cyber security product research, testing, and advisory company conducted two global tests to measure how effective web browsers are at blocking current threats targeting Internet users, and discovered that the apps that blocked the most attacks overall also blocked URLs the fastest.

The tests were conducted between Sept. 26, 2016 and Oct. 9, 2016, with 220,918 socially engineered malware results and 78,921 phishing results recorded. For their tests, NSS Labs considered Google Chrome version 53.0.2785, Microsoft Edge 38.14393.0.0, and Mozilla Firefox version 48.0.2. The browsers were tested on Windows 10 Enterprise – Version 1607.

When it comes to SEM protection, Microsoft Edge came up on top by blocking 99.0% of the samples, followed by Google Chrome with 85.8% and Mozilla Firefox with 78.3%. While Edge uses SmartScreen URL filtering and Application Reputation (App Rep) for user protection, Chrome and Firefox use URL filtering and an application reputation system called Download Protection.

The test also revealed that Microsoft Edge could deliver a 98.7% zero-hour protection rate for malware, followed by Chrome with 92.8%, and Firefox with 78.3%. After 7 days of testing, Edge was in the lead with a 99.3% block rate, 3.6% higher than Chrome and 17.4% higher than Firefox. On average, Edge needed less than 10 minutes to block malware, Chrome needed 2 hours and 39 minutes, while Firefox needed over 3 hours and 45 minutes.

When it comes to phishing protection, Microsoft Edge had a phishing catch rate of 91.4% over the 12-day test period, followed by Chrome with 82.4% and Firefox with 81.4%. An average of 145,581 unique email phishing campaigns were reported each month this year, making a browser’s ability to block such attacks highly important. However, SEM protection is as important when assessing a browser’s security capabilities, NSS Labs notes.

The phishing protection test conducted by NSS Labs collected 78,921 results during the test period and revealed that Microsoft Edge has an initial protection rate of 92.1%, followed by Firefox at 84.0%, and Chrome with only 82.7% percent. By the seventh day, Microsoft Edge climbed to 92.9%, Chrome to 85.6%, and Firefox to 84.9% (both Chrome and Firefox rely on Google Safe Browsing API, hence the nearly identical performance).

The average time to block a phishing site is of 56.4 minutes. While Microsoft Edge was in the lead at 24 minutes, the other two browsers needed over an hour to block the offending sites: 61.2 minutes for Firefox and 84.6 minutes for Chrome.

Nearly one third of all Internet users have fallen victim to socially engineered malware, making this threat one of the most encountered today. Both individuals and organizations are at risk, because such attacks can compromise, damage, or acquire sensitive personal and corporate information. Phishing attacks represent an equally important and damaging threat, as they become more complex and sophisticated, being harder to detect and difficult to prevent.

Related Reading: DomainTools Service Eyes Potentially Dangerous Domains

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

For many of us in the Security Industry, the possibility of using Internet of Things (IoT) devices as a launchpad for an attack has been mostly theoretical. However, information obtained after the recent massive distributed denial-of-service (DDoS) attack against the services offered by DYN.com appears to show that the threat is real and immediate.

The definition of IoT is often a little vague. Generally speaking, I consider any device with an IP address associated with it to be some sort of an IoT device, though not all of them are problems. The ones that are the largest source of concern are those that have the following characteristics:

• Have a statically configured administrative account

• Users can set and forget them

• Reach out to an Internet-located service for administrative control (i.e. cloud based management)

• Have no automated patch or update management

Essentially what I am really talking about when using the term IoT are devices with IP addresses where users don’t directly interact with the Operating System on a continual basis. I would argue that even devices like an iPhone or Android-based device are also essentially IoT, even though they don’t meet some of the criteria.

In previous articles we’ve discussed a number of reasons why these devices are security challenges, such as their having no automated updated processes. While we could try and find tools, techniques, and processes to address these issues, given the vast array of devices that qualify as IoT devices, that quickly becomes a daunting, if not impossible task. In reality, that will likely result in stasis setting and nothing getting done, leaving the current gaping security hole in place.

But what if we could actually embed security inspection right into the network itself? For any of these IoT devices to be effective as a malicious device they need to be able to communicate with other devices. The most common and simplest method of communication is via 802.11 WiFi. While that covers direct communications from the device itself, a lot of them also have some kind of configuration interface as well, more often then not located somewhere on the Internet, requiring the devices to attempt to connect to external resources.

If we step back just a little bit, the concept of internal segmentation essentially means to deploy network based security enforcement technology throughout the extended network, even into the cloud, and not just at traditional edge and chokepoints between places in the network. For example, you could deploy network-based security enforcement at the point that the device connects to the network, such as the L2/3 switching layer for traditional wired systems (like in the Data Center), or the wirelessly connected systems now predominantly used by end-users, and then direct traffic into assigned network segments that can be monitored as well as control data that moves from one network segment to another.

This sort of internal segmentation strategy is especially relevant in the virtualization technology space, where I would submit that it’s actually a larger problem than for physical networks. Deploying host-based security technologies for every VM can result in a significant drop in the number of instances that can be hosted on a single system due to all the security processing overhead required for each instance. While there are some solutions that attempt to limit this overhead, these typically only support a very small range of operating environments. The big risk in a virtualized infrastructure is the rate at which malware and other attacks can spread, and the number of systems available to be compromised.

This challenge in the virtualization space provides a ready environment to begin putting internal segmentation practices to use. This is true in part because virtualized networks are often new deployments, but also because the physical effort required to deploy internal segmentation doesn’t exist - there are no firewalls or other enforcement products to physically install, transceivers to install, cables to run, etc.

For some deployments, secure segmentation is an area of critical need since another benefit of virtualization is the ability to keep legacy systems and operating platforms running longer. The challenge is that many of these systems and platforms don’t have current host-based security tools available to them.

When you are looking at designing your virtualization infrastructure, there are multiple ways that you can build internal segmentation right into the process. In fact, these modern solutions actually allow you to pretty much automate the deployment of a security policy whenever you deploy a new VM.

Once you have developed a process for securing your virtualized deployments, you can take all those hard learned lessons and apply them to the more demanding challenges of physical deployments. When doing so, however, don’t ignore the obvious. Small offices, branch plants, retail locations, and deployments with a similar footprint are all easy candidates for the deployment of internal segmentation. Rather then deploying a router/switch/firewall combination at each location, deploy a high port density security solution and connect all the devices in that location directly. These types of deployments are now possible even when a high degree of resiliency is required, which used to be a challenge for some of these deployments.

And at the same time, don’t forget your new cloud deployments. Most cloud computing or infrastructure environments have security tools available as a service. By properly selecting and configuring tools to be compatible with your private cloud and physical security deployments, you can create seamless segmentation and consistent security policy enforcement even into your public cloud environments.

The biggest challenge with deploying internal segmentation in the modern network, and for data center in particular, are growing capacity demands, and the potential amount of new hardware that will need to be installed to meet these requirements. Thinking about this as a distributed processing challenge may help with your design, allowing you to apply only those security technologies you need, and only where they are most appropriate. While the data center tends to be reasonably static, with well defined application stacks that require very high performance, L3/L4 may be sufficient here to inspect and protect internal traffic, with L7 security only being added as a service to a transaction chain when required. There is an increasing trend to treat all IP enabled systems as if they were external, even those devices physically located within our own physical perimeter, it’s no longer sufficient to consider physical location alone to determine the security risk.

It’s unrealistic to expect any distributed deployment to be homogenous, particularly when it comes to security solutions, so consideration of how your different vendors work or integrate with other solutions (without introducing cumbersome encapsulation technologies, like ICAP/WCCP, etc.) is also critical to deploying a functional internal segmentation solution. Wouldn’t be nice if your L2 switching layer could automatically segment a highly compromised device from all other devices to prevent local propagation of malware? For this to happen, your security devices need to be able to inform your transport devices to make a forwarding path change.

Here are some initial recommendations for solving your IoT security challenges:

• Look for palatable starting points. Virtualization, cloud deployments, and remote office locations are good and easy places to start.

• Look for products that support a multi-vendor enforcement fabric to share, synchronize, and automatically respond to threats, even across different network environments and domains.

• If you’re nervous about beginning with enforcement on day one, then start with visualization and then turn on enforcement by degrees – like transitioning from IDS to IPS.

Related: The Connected Conundrum: Why I No Longer Trust My Toaster

*Updated with corrected title

Ken McAlpine is a 35+ year veteran of the IT industry and remembers when security was almost exclusively a physical challenge and "the Internet” was a 110 Baud Acoustic Coupler. McAlpine is currently the VP, Network Security Solutions and a member of the CTO Office for Fortinet. Prior to Fortinet, he was self employed and engaged in consulting with international customers primarily focusing on Security Technologies as well as Network and Systems Management technologies.

Previous Columns by Ken McAlpine:

Tags:

LONDON - BLACK HAT EUROPE - Researchers have discovered a new attack method that could allow malicious actors to disrupt and manipulate the physical processes managed by programmable logic controllers (PLCs) without being detected.

The attack method was detailed on Thursday at the Black Hat Europe 2016 security conference by Ali Abbasi, a Ph.D. candidate in the distributed and embedded system security group at the University of Twente in the Netherlands, and Majid Hashemi, a research and development engineer at Quarkslab in France.

PLCs are devices used to control and monitor physical processes in industrial environments. In the past years, security experts demonstrated on several occasions the risks posed by vulnerabilities in PLC software and firmware, and they even showed how attackers could develop a worm that spreads from one PLC to another.

However, Abbasi and Hashemi have come up with a new post-exploitation attack method that does not involve any modifications to the PLC firmware or logic. Instead, it involves manipulating the device’s input and output (I/O) at a low level, which allows the attacker to control the PLC without triggering any alarms.

A PLC can receive and transmit various types of electrical and electronic signals. The input, which typically comes from sensors, and the output, which can be used to control motors, valves or relays, are linked to input and output pins on an integrated circuit known as a system on chip (SoC). The SoC’s pin controller can configure the modes of a pin (i.e. they are set to serve as input or output) and configure pin multiplexing, which allows the use of a pin for different purposes via a switch.

The experts discovered that an attacker who has compromised the PLC can tamper with the input and output without being detected and without alerting the operators monitoring the process through a human-machine interface (HMI).

Abbasi and Hashemi have identified two pin control attack methods. One of them, which involves changing the pin’s configuration, allows a piece of malware that is present on the PLC to switch a pin from input to output and vice-versa. The second attack type, which involves multiplexing, is similar, but it involves changing the functionality of the same pin.

This can cause the system controlled by the PLC not to perform its intended function (e.g. not opening a valve to adjust pressure). The attacker can also take control of the system (e.g. arbitrarily close or open the valve).

However, the PLC’s operating system and the user are not alerted as the I/O pin values are normal in the virtual I/O registers. Another advantage of this attack is that it can bypass host-based intrusion detection systems such as Autoscopy Jr. and Doppelganger.

The attack can be implemented through a rootkit, which requires root access to the targeted system, but it can also be carried out without root access. In the second scenario, in which the attacker has the same privileges as the PLC runtime, the attack can be conducted via a remote code execution vulnerability.

Both attacks can be used to cause a denial-of-service (DoS) condition and to control the physical process connected to the PLC. However, the experts pointed out that the non-root variant is more efficient, especially from a performance standpoint, but it’s less precise.

“The novelty of our attack lies in the fact that to manipulate the physical process we do not modify the PLC logic instructions or firmware,” the researchers said in their paper. “Instead, we target the interaction between the firmware and the PLC I/O. This can be achieved without leveraging traditional function hooking techniques and by placing the entire malicious code in dynamic memory (in rootkit version of the attack), thus circumventing detection mechanisms such as Autoscopy Jr. and Doppelganger. Additionally, the attack causes the PLC firmware to assume that it is interacting effectively with the I/O while, in reality, the connection between the I/O and the PLC process is being manipulated.”

The researchers have not disclosed the names of any vendors, but based on the analysis of several CPU architectures commonly used in PLCs, they believe a majority of them are affected. Vendors have been made aware of the attack method, but it’s unclear if they plan on addressing these issues in the near future, the researchers told SecurityWeek in an interview.

Abbasi and Hashemi pointed out that PLCs have many vulnerabilities that are more easy to exploit compared to the weaknesses they disclosed, especially when an attacker has root access to a device. However, the easy-to-exploit flaws are also easier to address, which could lead to malicious actors turning to less obvious security holes in the future, such as the one found by Abbasi and Hashemi.

The experts said their goal is to raise awareness and convince vendors to design products that are even more secure. Their paper also includes a series of recommendations on how these types of attacks can be detected.

Previous Columns by Eduard Kovacs:

Tags:

Mirai, the Internet of Things (IoT) botnet that has recently fueled multiple large distributed denial of service (DDoS) attacks, is now targeting the Liberian infrastructure, taking down the Internet for the entire country, researchers warn.

The Mirai botnet made it to the headlines in September, after it was used in a 665 Gbps DDoS attack against Brian Krebs’ blog, along with at least one other botnet. Mirai’s source code was released online in early October, which resulted in the botnet being increasingly used in DDoS attacks, including a massive atttack against Dyn’s DNS infrastructure.

Mirai has already infected devices in 164 countries, which doesn’t come as a surprise, since hundreds of thousands of IoT products were found vulnerable to it, mainly because they use default, easy-to-guess login credentials. 

With Mirai’s source code available online, anybody can download it and launch attacks, and it seems that this is exactly what is happening right now, although few of the many new Mirai botnets are indeed noteworthy. One of them, security researcher Kevin Beaumont says, is a botnet dubbed #14, which is attacking significantly bigger targets than just Minecraft servers and websites.

One of the large targets this botnet is going after is the infrastructure in the nation of Liberia. The West African country has a single Internet cable, installed in 2011, co-owned by two companies, and serving around 6% of the population.

Because of this setup, there is a single point of failure for Internet access, and the DDoS attacks from the botnet managed to disrupt not only the availability of websites hosted in the country, but also Internet access for users there.

“The attacks are extremely worrying because they suggest a Mirai operator who has enough capacity to seriously impact systems in a nation state,” Beaumont notes.

The security researcher calls the botnet “Shadows Kill”, because it is capable of sending messages, as revealed by the Mirai Attacks Twitter account, which delivers real-time reports on monitored attacks. Beaumont also says that the botnet’s operators appear to be merely testing DDoS techniques, while continuing to target Liberia.

In an emailed commentary, Thomas Pore, Director of IT and Services for Plixer, told SecurityWeek that, if the botnet is merely testing its capacity by taking down the Internet in Liberia, then attacks against larger countries such as the United States might emerge before the end of the year.

“Weapon testing is defined as experimentation of conceptualization for validity. Historically, weapon testing has been used as a scare tactic to prevent war, but also to correct any design flaws. The recent report of “Botnet #14”, a Mirai botnet, potentially sharping its weapon by issuing large scale volumetric attacks for short durations against Liberia could indicate that it is weapon testing and made an attempt to go unnoticed, because “why Liberia, for only 1 second?”.

It was reported that Liberia was seeing short attacks up to 500 Gbps, and it’s hypothesized that it is the same operator that took Dyn down recently. An attack of that size could definitely take a small country down and perhaps Liberia is just the testing ground for something larger. If Botnet #14 is “weapons testing” with Liberia, it’s possible that the USA will see a massive sustained outage of over 4 hours before the end of the year,” Pore said.

Jeremiah Grossman, Chief of Security Strategy, SentinelOne, also told SecurityWeek that the attacks on Liberia appear to be part of a testing process.

“The DDoS attack on Liberia seems to match earlier predictions about Mirai’s (or its owners’) intentions. Start small, experiment, and continue testing capabilities on increasingly large and more interesting targets: First a blog, then a hosting provider, then a DNS provider, and now a small country.  As for future likely targets, I can imagine other smaller and more notable countries – North Korea, for example – getting their Internet connections ‘stress’ tested. Perhaps even a resurgence of extortion-based DDoS attacks on smaller retailers and other online businesses,” Grossman said.

He also noted that Mirai continues to get stronger, because the vast majority of the IoT-devices owners that make up the botnet have no idea that they are infected and that they should apply patches. Some might not even care, while a manufacturer recall would not have a real impact on the situation, Grossman points out.

“As far as what to do about Mirai, if anyone would ‘strike back’ at the botnet and had the capability to do so, in order to disable it in self-defense, a small country like Liberia that’s under attack would not be at all surprising. And should Liberia, or anyone else do so outside of law enforcement, it would be large precedence,” he concluded.

As Cigital’s Jim Ivers points in a recent SecurityWeek column, the issue of having large numbers of poorly secured devices with computing power connected to the Internet has been theorized before. A rough translation of “Mirai” from Japanese would be “future,” and the botnet has shown what that future could be.

“If Mirai means “future,” then its arrival certainly leads us to ask what the future holds. I foresee lots of experimentation with evolving attacks using IoT devices as new devices are infiltrated. I predict lots of knee-jerk reactions in the form of poorly conceived legislation as the government tries to run in front of the avalanche. I see a call toward sanity, building some basic security hygiene into devices and the testing of associated software,” Ivers says.

Just last week, a newly discovered attack vector against the Lightweight Directory Access Protocol (LDAP) protocol was disclosed, which could result in terabit-scale DDoS attacks. 

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

Domain name and DNS-based cyber threat intelligence firm DomainTools has launched a new security solution for preventing phishing attacks by idenitfying potentially dangerous domain names.

Dubbed PhishEye, the new solution was designed to automate the process of identifying look-alike domains meant to spoof brand, product, or organization names. Powered by DomainTools' domain name discovery and profiling systems, PhishEye should help security teams identify potential domain-based threats and proactively defend networks against future phishing attacks.

Phishing leverages deceptive domain names that have been created in such a way that the intended victims don’t immediately notice they are not legitimate. PhishEye was meant to help organizations easily fight malicious domains, a task usually performed by means of custom tools built by security teams themselves, DomainTools says.

PhishEye uses a typo and substring matching algorithm that is compounded with DomainTools' proprietary Domain Reputation Engine for the automation of discovery of potentially malicious domains. The solution attempts to find and alert on these domains soon after they are registered.

The discovered domains, DomainTools says, can be entered into spam filters, firewalls, and other security systems meant to deliver protection against phishing attacks. They can also be sent to DomainTools Iris for additional investigation and attribution, the company explains.

The new anti-phishing solution should fuel proactive protection by identifying nefarious domains before they cause harm, and is also expected to disrupt spear-phishing and business email compromise attacks. Additionally, it should help companies mitigate or prevent brand damage caused by illegitimate domains and identify registrants of spoofing domains to monitor or initiate legal action against them.

Because cybercriminals can spoof email addresses and can create deceptive links for the victim to click on, they incur average losses of millions of dollars per year for the average-sized organization. What’s more, the Anti-Phishing Working Group (APWG) reports that the number of unique phishing sites in the second quarter of 2016 went up 61% on quarter and was three times higher compared to the fourth quarter of 2015.

“Phishing campaigns are fundamentally trying to trick your employees or customers, and the 'trick' often involves a look-alike domain and website. To build an effective phishing prevention product it helps to have a very thorough mapping of domains in DNS today as well as highly effective and timely domain discovery systems, two things DomainTools is exceedingly good at. We created PhishEye for enterprises looking for a simple and effective way to automate the process of discovering phishing threats lurking on the internet well before they are activated,” Tim Chen, CEO, DomainTools, says.

Related: Phishing Attacks Hit the C-Suite With High Value Scams

Related: Losses From Business Email Compromise Scams Top $3.1 Billion: FBI

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

The recently disclosed "Trident" 0-day vulnerabilities that put owners of iOS devices at risk were patched in August, but the full technical details on them have been released only this week.

The three critical flaws that Citizen Lab and Lookout security researchers disclosed in August were being exploited by a piece of high-end surveillance software dubbed Pegasus to silently compromise iOS devices. Sold by NSO Group Technologies Ltd, a Herzelia, Israel-based firm, the software was referred to as “the most sophisticated attack seen on any endpoint.”

The vulnerabilities put owners of iPhone 4s and later, iPad 2 and later, and iPod touch (5th generation) and later at risk.

On August 25, Apple released iOS 9.3.5 to address these vulnerabilities, but revealed only a few details on each of them. More interesting at that time was the Pegasus software, which was being sold to governmental agencies and used against journalists, activists, government opposition, and other targets of interest worldwide.

In fact, soon after the news on Trident broke, Israel's secretive surveillance industry came into spotlight. A British NGO Privacy International report revealed that 27 surveillance firms are headquartered in Israel, all of which should design technology for fighting crime and terrorism through legal means. However, many question whether attention is paid to the potential abuse of this technology.

Tracked as CVE-2016-4655, CVE-2016-4656, and CVE-2016-4657, the three security flaws were patched in OS X and Safari too, soon after the iOS emergency fix was released.

Now, Lookout has decided to publish the full technical details (PDF) on these vulnerabilities and to explain how exactly the exploitation chain (and infection with Pegasus) works: it all starts with a vulnerability in Safari WebKit, continues with a kernel base mapping flaw, and ends with a kernel memory corruption that leads to jailbreak. To these steps, however, Pegasus spyware’s persistence mechanism is added.

Affecting WebKit’s JavaScriptCore library, the first vulnerability (CVE­2016­4657) can be exploited when the user clicks on a spear-phishing link that opens the Safari browser. By running a JavaScript payload in the browser, the attacker can gain arbitrary code execution in the context of the Safari WebContent process, Lookout explains.

The Pegasus spyware exploited the vulnerability by passing a specifically crafted sequence of properties to the defineProperties() method. The software would make multiple attempts (up to a total of 10) to trigger the flaw and check whether a stale reference has been successfully acquired, after which it would set up the tools for arbitrary native code execution and then move to create an executable mapping containing the native code payload.

After the first stage of the attack has been completed, the second stage is triggered in an attempt to exploit a kernel information leak (CVE­2016­4655). This is when the malicious software tries to escalate privileges on the victim’s iPhone and make the necessary preparations for the final stage, which results in jailbreak.

The security researchers discovered that Pegasus uses the stage 2 binary in two different contexts: as a complete iOS kernel exploit or to check for existing jailbreak and install Pegasus specific kernel patches. For that, however, it needs to “determine the location of the kernel in memory, escalate its own privileges, disable safeguards, and then install the necessary tools for jailbreaking a device,” Lookout explains.

The binary was created in both 32­bit and 64­bit versions, which allows it to target no less than 199 iPhone combinations. Lookout has detailed them separately, because they “deviate enough in their approach,” although they pack a lot of similarities.

Finally, the spyware exploits a kernel memory corruption vulnerability (CVE­2016­4656) to jailbreak the compromised device and involves a series of operations that Lookout refers to as “the final steps carried out in Stage 2.” They are meant to gain root access, to disable code signing, and then to drop and activate the jailbreak binary.

“Stage 2 is activated as the result of a bug in Safari that allows for arbitrary code execution. As one of the last activities Stage 2 performs prior to dropping and activating the jailbreak binary, Stage 2 attempts to cover its infection vector by cleaning up the history and cache files from Safari,” the security researchers explain.

Next, the Pegasus software attempts to achieve persistence on the compromised device, and relies on two distinct issues for that: the presence of the rtbuddyd service within a plist and a vulnerability within the JavaScriptCore binary. The first issue allows the spyware to execute code at boot, and leverages the second to execute the jsc binary and run unsigned code to re­exploit the kernel.

Related: Apple Issues Emergency Fix for iOS Zero-Days: What You Need to Know

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags: