Security Tip (ST17-001): Securing the Internet of Things
The Internet of Things is becoming an important part of everyday life. Being aware of the associated risks is a key part of keeping your information and devices secure. The Internet of Things refers to any object or device that sends and receives data automatically through the Internet. This rapidly expanding set of “things” includes tags (also known as labels or chips that automatically track objects), sensors, and devices that interact with people and share information machine to machine.[…]
Intrusions Affecting Multiple Victims Across Multiple Sectors
Original release date: April 27, 2017 | Last revised: May 02, 2017
The National Cybersecurity and Communications Integration Center (NCCIC) has become aware of an emerging sophisticated campaign, occurring since at least May 2016, that uses multiple malware implants. Initial victims have been identified in several sectors, including Information Technology, Energy, Healthcare and Public Health, Communications, and Critical Manufacturing. According to preliminary analysis, threat actors appear to be leveraging stolen administrative credentials (local and domain) and certificates, along with placing sophisticated malware implants on critical systems. Some of the campaign victims have been IT service providers, where credential compromises could potentially be leveraged to access customer environments. Depending on the defensive mitigations in place, the threat actor could possibly gain full access to networks and data in a way that appears legitimate to existing monitoring tools. Although this activity is still under investigation, NCCIC is sharing this information to provide organizations information for the detection of potential compromises within their organizations.[…]
US-CERT has issued a new thread advisory, on network infrastructure, including some emphasis on hardware/firmware security advice. I’m excerpting their recommendations on on hardware validation:
6. Validate Integrity of Hardware and Software
Products purchased through unauthorized channels are often known as “counterfeit,” “secondary,” or “grey market” devices. There have been numerous reports in the press regarding grey market hardware and software being introduced into the marketplace. Grey market products have not been thoroughly tested to meet quality standards and can introduce risks to the network. Lack of awareness or validation of the legitimacy of hardware and software presents a serious risk to users’ information and the overall integrity of the network environment. Products purchased from the secondary market run the risk of having the supply chain breached, which can result in the introduction of counterfeit, stolen, or second-hand devices. This could affect network performance and compromise the confidentiality, integrity, or availability of network assets. Furthermore, breaches in the supply chain provide an opportunity for malicious software or hardware to be installed on the equipment. In addition, unauthorized or malicious software can be loaded onto a device after it is in operational use, so integrity checking of software should be done on a regular basis.
* Maintain strict control of the supply chain; purchase only from authorized resellers.
* Require resellers to implement a supply chain integrity check to validate hardware and software authenticity.
* Inspect the device for signs of tampering.
* Validate serial numbers from multiple sources.
* Download software, updates, patches, and upgrades from validated sources.
* Perform hash verification and compare values against the vendor’s database to detect unauthorized modification to the firmware.
* Monitor and log devices, verifying network configurations of devices on a regular schedule.
* Train network owners, administrators, and procurement personnel to increase awareness of grey market devices.
Apparently “Linux KVM”, Parallels, and “Red Hat” are affected. Microsoft and Xen are not affected. “Oracle”, QEMU, and VMware are unknown. CERT excerpt below, for more information, see full CERT Vulnerability Note and CAIN paper, including a list of other mitigations.
Virtual Machine Monitors (VMM) contain a memory deduplication vulnerability
Vulnerability Note VU#935424
CVE IDs: CVE-2015-2877
Date First Published: 20 Oct 2015
Multiple vendors’ implementations of Virtual Machine Monitors (VMM) are vulnerable to a memory deduplication attack. As reported in the “Cross-VM ASL INtrospection (CAIN)” paper, an attacker with basic user rights within the attacking Virtual Machine (VM) can leverage memory deduplication within Virtual Machine Monitors (VMM). This effectively leaks the randomized base addresses of libraries and executables in the processes of neighboring VMs. Granting the attacker the ability to leak the Address-Space Layout of a process within a neighboring VM results in the potential to bypass ASLR. Impact: A malicious attacker with only user rights within the attacking VM can reliably determine the base address of a process within a neighboring VM. This information can be used to develop a code-reuse or return oriented programming exploit for a known vulnerability in a target process. Attacking the target process is outside the scope of the CAIN attack. Solution: Deactivation of memory deduplication is the only known way to completely defend against the CAIN attack.
CAIN: Silently Breaking ASLR in the Cloud
Antonio Barresi, Kaveh Razavi, Mathias Payer, Thomas R. Gross
Modern systems rely on Address-Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) to protect software against memory corruption vulnerabilities. The security of ASLR depends on randomizing regions in memory which can be broken by leaking addresses. While information leaks are common for client applications, server software has been hardened to reduce such information leaks. Memory deduplication is a common feature of Virtual Machine Monitors (VMMs) that reduces the memory footprint and increases the cost-effectiveness of virtual machines (VMs) running on the same host. Memory pages with the same content are merged into one read-only memory page. Writing to these pages is expensive due to page faults caused by the memory protection, and this cost can be used by an attacker as a side-channel to detect whether a page has been shared. Leveraging this memory side-channel, we craft an attack that leaks the address space layouts of the neighboring VMs, and hence, defeats ASLR. Our proof-of-concept exploit, CAIN (Cross-VM ASL INtrospection) defeats ASLR of a 64-bit Windows Server 2012 victim VM in less than 5 hours (for 64-bit Linux victims the attack takes several days). Further, we show that CAIN reliably defeats ASLR, regardless of the number of victim VMs or the system load.
US-CERT has issued a Vulnerability Note (VU#950576) for some DSL routers, excerpted below, see US-CERT note for full details:
DSL routers contain hard-coded “XXXXairocon” credentials
DSL routers by ASUS, DIGICOM, Observa Telecom, Philippine Long Distance Telephone (PLDT), and ZTE contain hard-coded “XXXXairocon” credentials
CWE-798: Use of Hard-coded Credentials
DSL routers, including the ASUS DSL-N12E, DIGICOM DG-5524T, Observa Telecom RTA01N, Philippine Long Distance Telephone (PLDT) SpeedSurf 504AN, and ZTE ZXV10 W300 contain hard-coded credentials that are useable in the telnet service on the device. In the ASUS, DIGICOM, Observa Telecom, and ZTE devices, the username is “admin,” in the PLDT device, the user name is “adminpldt,” and in all affected devices, the password is “XXXXairocon” where “XXXX” is the last four characters of the device’s MAC address. The MAC address may be obtainable over SNMP with community string public. The vulnerability was previously disclosed in VU#228886 and assigned CVE-2014-0329 for ZTE ZXV10 W300, but it was not known at the time that the same vulnerability affected products published by other vendors. The Observa Telecom RTA01N was previously disclosed on the Full Disclosure mailing list.
Impact: A remote attacker may utilize these credentials to gain administrator access to the device.
Solution: The CERT/CC is currently unaware of a practical solution to this problem and recommends the following workaround: Restrict access: Enable firewall rules so the telnet service of the device is not accessible to untrusted sources. Enable firewall rules that block SNMP on the device.
Vendors impacted include: AsusTek, DIGICOM, Observa Telecom, Philippine Long Distance Telephone, and ZTE Corporation.
See CERT VU for full information:
Today, US CERT released a Vulernability Notice for UEFI firmware:
Vulnerability Note VU#577140
BIOS implementations fail to properly set UEFI write protections after waking from sleep mode
Multiple BIOS implementations fail to properly set write protections after waking from sleep, leading to the possibility of an arbitrary BIOS image reflash.
According to Cornwell, Butterworth, Kovah, and Kallenberg, who reported the issue affecting certain Dell client systems (CVE-2015-2890):
There are a number of chipset mechanisms on Intel x86-based computers that provide protection of the BIOS from arbitrary reflash with attacker-controlled data. One of these is the BIOSLE and BIOSWE pair of bits found in the BIOS_CNTL register in the chipset. When the BIOSLE bit is set, the protection mechanism is enabled. The BIOS_CNTL is reset to its default value after a system reset. By default, the BIOSLE bit of the BIOS_CNTL register is cleared (disabled). The BIOS is responsible for re-enabling it after a reset. When a system goes to sleep and then wakes up, this is considered a reset from the hardware’s point of view.
Therefore, the BIOS_CNTL register must be reconfigured after waking from sleep. In a normal boot, the BIOS_CNTL is properly configured. However, in some instances BIOS makers do not properly re-set BIOS_CNTL bits upon wakeup. Therefore, an attacker is free to reflash the BIOS with an arbitrary image simply by forcing the system to go to sleep and wakes again. This bypasses the enforcement of signed updates or any other vendor mechanisms for protecting the BIOS from an arbitary reflash.
A similar issue affecting Apple systems (CVE-2015-3692) involves the FLOCKDN bit remaining unset after waking from sleep. For more information, refer to Pedro Vilaça’s blog disclosure.
See URL for full Notice.