Cisco Releases Security Updates

Original release date: March 23, 2016

Cisco has released security updates to address vulnerabilities in multiple products. Exploitation of these vulnerabilities could allow a remote attacker to create a denial-of-service condition.

US-CERT encourages users and administrators to review the following Cisco Security Advisories and apply the necessary updates:

  • cisco-sa-20160323-sip: Cisco IOS, IOS XE, Unified Communications Manager software session initiation protocol memory leak vulnerability 
  • cisco-sa-20160323-lisp: Cisco IOS and NX-OS software locator/ID separation protocol packet denial-of-service vulnerability   
  • cisco-sa-20160323-ios-ikev2: Cisco IOS and IOS XE software Internet Key Exchange v2 fragmentation denial-of-service vulnerability
  • cisco-sa-20160323-dhcpv6: Cisco IOS and IOS XE software DHCPv6 relay denial-of-service vulnerability
  • cisco-sa-20160323-smi: Cisco IOS and IOS XE software Smart Install denial-of-service vulnerability
  • cisco-sa-20160323-l4f: Cisco IOS software wide area application services express denial-of-service vulnerability

This product is provided subject to this Notification and this Privacy & Use policy.

Secure Your Instance of Amazon’s Elastic Compute Cloud

It is absolutely necessary to secure resources in the cloud. Moving your resources to the cloud does not make your data 100% secure. You are actually moving to a shared security responsibility model in which you share responsibilities with the service provider, such as Amazon, and not abandoning your cares. This model reduces the operational burden for securing the infrastructure that supports the cloud, but we are still responsible for securing whatever we put in the cloud.

Moving applications to the cloud changes the attack surface, but the vulnerabilities at application, database, and network level still persist. To address these issues, setting up the perimeter is critical. You might have plenty of experience with on-premises data centers but the cloud is different. Let’s dive deeper into securing your cloud with an instance of Amazon’s Elastic Compute Cloud (EC2):

Reduce the attack surface

The basic principles don’t change. Run a port scan using a tool such as Nmap specific to an instance IP and lock down all the unnecessary open ports. This is the first step in the defense-in-depth approach. For example, to scan all the TCP ports open on a host:

nmap -p 1-65535 –t4 –A –v

All the traffic to an instance can be controlled by a security group, a virtual firewall that controls the inbound and outbound traffic. It can be configured from an EC2 dashboard. By default, the security group attached has limited protocols/ports open to allow traffic from the Internet. However, these can be modified depending on user requirements that could make them vulnerable. To edit a security group, follow these steps:

Running instances -> select any instance -> security groups from description

20160323 EC2 instance 1

Private subnet instances are accessible only internally. So creating security group rules that allow inbound connections publicly ( doesn’t make sense. Identify those settings and get rid of those rules.


Remove password-based authentication

To secure the authentication mechanism, disable password-based authentication. Amazon disabled this option by default for Ubuntu/Linux instances. We recommend leaving those default settings for added security. Public/private key–based authentication should be used to log into an application via SSH. Amazon provides a good reference on how to create key pairs. If you are using customized Amazon Machine Images (AMIs), make sure to disable the password-based authentication from the SSH daemon configuration file. For critical systems, allowing SSH ports to the entire Internet is not a good practice; restrict them to specific IPs through whitelisting.


Meta and user data: lock it down

Instance metadata is information about your EC2 instance that can be used to configure or manage a running instance. You can attach scripts to configure AMIs during launch to make more generic instances. This instance metadata can be available from your running instance in multiple ways. To view all categories of instance metadata from a running instance, use the following URI:

Amazon Web Services (AWS) attaches a metadata server to each running instance and the preceding server IP address is common for any instance. This advice just touches the surface; there are many resources available online on how to add and retrieve metadata. You can use a tool such as cURL to retrieve the metadata of an instance:


20160323 EC2 instance 2

The metadata contains sensitive information such as private IPs, instance IDs, host names, etc. Similarly, user data can be accessed from a running instance. That data can be exploited if an application sitting on EC2 is vulnerable to HTTP request proxying. (A paper from Andres Riancho explains this attack surface in great detail.) Because data theft can cause a severe impact, let’s look at securing meta and user data.

Tighten the security to access the metadata/userdata folder to only root-owned processes with permissions set to 400 upon launching an instance. The routing service can be turned off once data has been collected, with the following command:

route add –host reject

20160323 EC2 instance 3

This step will prevent nonroot users from accessing the data. To access the data, the root account would have to be compromised and the preceding configured route settings deleted.

Alternatively, configure the iptables that predefine the firewall rules to allow connections only to root.

iptables –A OUTPUT –m owner ! –uid-owner root –d –j DROP



The default setup of EC2 is always insecure. Configure AWS settings to industry standards to better secure your instance. At any cost you should protect user data. The security of an API is such that it checks only the origin of calls. If somehow, an attacker gets control over that data or your application allows code execution on your instance, you need to be prepared to block that access.

The post Secure Your Instance of Amazon’s Elastic Compute Cloud appeared first on McAfee.

iOS forensics expert’s theory: FBI will hack shooter’s phone by mirroring storage

Jonathan Zdziarski, a leading independent Apple iOS security researcher and forensics expert, has a theory about the FBI's newly discovered potential route into the iPhone 5C used by San Bernardino shooter Syed Farook. In a blog post, Zdziarski wrote that the technique the FBI is planning to use to get around having to compel Apple to help bypass the phone's security is likely a method called NAND mirroring—a hardware-based approach that, while effective, is far from the "golden key" software the FBI had sought.

The FBI reported in its filing to delay a hearing on its dispute with Apple, originally scheduled for March 22, that an outside company had approached the FBI with a solution to the "self-destruct" issue preventing the FBI from repeatedly guessing the device's four-digit PIN. In that filing, FBI officials said that they needed just two weeks to certify that they could use the alternative approach to gain access to the phone.

Based on a number of factors, Zdziarski said that the company in question was likely one of the FBI's external forensics contractors and that it was unlikely that it had found a "zero day" software technique to bypass the password. "Whatever technique is being used likely isn't highly experimental (or it'd take more time)," Zdziarski noted. "Chances are the technique has been developed over the past several weeks that this case has been going on."

Read 4 remaining paragraphs | Comments

Kentucky hospital hit by ransomware attack

Methodist Hospital in Henderson, Kentucky, initiated an "internal state of emergency" after discovering a Locky crypto-ransomware infection of its network. (credit: Methodist Hospital)

A month after a Los Angeles hospital was crippled by crypto-ransomware, another hospital is in an "internal state of emergency" for the same reason. Brian Krebs reports that Methodist Hospital in Henderson, Kentucky, shut down its desktop computers and Web-based systems in an effort to fight the spread of the Locky crypto-ransomware on the hospital's network.

Yesterday, the hospital's IT staff posted a scrolling message at the top of Methodist's website, announcing that "Methodist Hospital is currently working in an Internal State of Emergency due to a Computer Virus that has limited our use of electronic web-based services. We are currently working to resolve this issue, until then we will have limited access to web-based services and electronic communications." As of this morning, the message has been taken down from the site.

Methodist Hospital's information systems director told Krebs that the Locky malware, which came in as an attachment to a spam e-mail, attempted to spread across the network after it had infected the computer it was triggered on. Locky has been known to use malicious scripts in Microsoft Office documents as a means of infecting victims' computers. The malware succeeded in infecting several other systems, prompting the hospital staff to shut down all the hospital's computers. Each PC is brought back online individually after being scanned for telltale signs of Locky while off the network.

Read 2 remaining paragraphs | Comments