Category Archives: Vulnerabilities

NIST Floats Internet of Things Cybersecurity Standards

There are plenty of standards that can be used to help secure The Internet of Things, but not much evidence that they’re being used, according to NIST, which calls on government and industry to settle on conforming standards for IoT products in a new report.  That National Institute of Standards and Technology (NIST) has unveiled guidelines...

Read the whole entry... »

Related Stories

Dell EMC Patches Critical Flaws in VMAX Enterprise Storage Systems

Attacks include a hard-coded password vulnerability that could give attackers unauthorized access to systems.

TrendLabs Security Intelligence Blog: New AndroRAT Exploits Dated Permanent Rooting Vulnerability, Allows Privilege Escalation

by Veo Zhang, Jason Gu, and Seven Shen

Trend Micro detected a new variant of Android Remote Access Tool (AndroRAT) (identified as ANDROIDOS_ANDRORAT.HRXC) that has the ability to inject root exploits to perform malicious tasks such as silent installation, shell command execution, WiFi password collection, and screen capture. This AndroRAT targets CVE-2015-1805, a publicly disclosed vulnerability in 2016 that allows attackers to penetrate a number of older Android devices to perform its privilege escalation.

RATs have long been a common Windows threat, so it shouldn’t be a surprise that it has come to Android. A RAT has to gain root access — usually by exploiting a vulnerability — in order to have control over a system. Discovered in 2012, the original authors intended AndroRAT — initially a university project — as an open-source client/server application that can provide remote control of an Android system, which naturally attracted cybercriminals.

Figure 1. Code snippet of the malware executing the exploit

Figure 1. Code snippet of the malware executing the exploit

This new variant of AndroRAT disguises itself as a malicious utility app called TrashCleaner, which is presumably downloaded from a malicious URL. The first time TrashCleaner runs, it prompts the Android device to install a Chinese-labeled calculator app that resembles a pre-installed system calculator. Simultaneously, the TrashCleaner icon will disappear from the device’s UI and the RAT is activated in the background.

Figure 2. Icon of the malicious TrashCleaner

Figure 2. Icon of the malicious TrashCleaner

Figure 3. Icon of the Chinese-labeled calculator app

Figure 3. Icon of the Chinese-labeled calculator app

The configurable RAT service is controlled by a remote server, which could mean that commands may be issued to trigger different actions. The variant activates the embedded root exploit when executing privileged actions. It performs the following malicious actions found in the original AndroRAT:

  • Record audio
  • Take photos using the device camera
  • Theft of system information such as phone model, number, IMEI, etc.
  • Theft of WiFi names connected to the device
  • Theft of call logs including incoming and outgoing calls
  • Theft of mobile network cell location
  • Theft of GPS location
  • Theft of contacts list
  • Theft of files on the device
  • Theft of list of running apps
  • Theft of SMS from device inbox
  • Monitor incoming and outgoing SMS

Apart from the original features of the AndroRAT, it also performs new privileged actions:

  • Theft of mobile network information, storage capacity, rooted or not
  • Theft of list of installed applications
  • Theft of web browsing history from pre-installed browsers
  • Theft of calendar events
  • Record calls
  • Upload files to victim device
  • Use front camera to capture high resolution photos
  • Delete and send forged SMS
  • Screen capture
  • Shell command execution
  • Theft of WiFi passwords
  • Enabling accessibility services for a key logger silently

Targeting CVE-2015-1805

Google already patched CVE-2015-1805 in March 2016, but devices that no longer receive patches or those with a long rollout period are at risk of being compromised by this new AndroRAT variant.  Older versions of Android, which are still being used by a significant number of mobile users, may still be vulnerable.

Countermeasures

Users should refrain from downloading apps from third-party app stores to avoid being targeted by threats like AndroRAT. Downloading only from legitimate app stores can go a long way when it comes to device security. Regularly updating your device’s operating system and apps also reduce the risk of being affected by exploits for new vulnerabilities.

[Read: Secure your mobile device through these easy steps]

End users and enterprises can also benefit from multilayered mobile security solutions such as Trend Micro™ Mobile Security for Android™, which is also available on Google Play. For organizations, Trend Micro™ Mobile Security for Enterprise provides device, compliance and application management, data protection, and configuration provisioning. It also protects devices from attacks that leverage vulnerabilities, prevents unauthorized access to apps, and detects/blocks malware and fraudulent websites.

Trend Micro’s Mobile App Reputation Service (MARS) covers Android and iOS threats using leading sandbox and machine learning technologies. The service protects users against malware, zero-day and known exploits, privacy leaks, and application vulnerability.

We disclosed our findings to Google and worked with them on further analyzing the apps that carried the new AndroRAT variant. Google said that the abovementioned apps were never on Google Play, and that they already incorporated detection for CVE-2015-1805 into their compatibility tests. Ideally, any device launched or updated after April 2016 will not be vulnerable.

Indicators of Compromise (IoCs)

SHA256 App Label Package Name
2733377c14eba0ed6c3313d5aaa51171f6aef5f1d559fc255db9a03a046f0e8f TrashCleaner com.cleaner.trashcleaner
fde9f84def8925eb2796a7870e9c66aa29ffd1d5bda908b2dd1ddb176302eced TrashCleaner com.cleaner.trashcleaner
2441b5948a316ac76baeb12240ba954e200415cef808b8b0760d11bf70dd3bf7 TrashCleaner com.cleaner.trashcleaner
909f5ab547432382f34feaa5cd7d5113dc02cda1ef9162e914219c3de4f98b6e TrashCleaner com.cleaner.trashcleaner

 

Post from: Trendlabs Security Intelligence Blog - by Trend Micro

New AndroRAT Exploits Dated Permanent Rooting Vulnerability, Allows Privilege Escalation



TrendLabs Security Intelligence Blog

Lenovo Warns Critical WiFi Vulnerability Impacts Dozens of ThinkPad Models

Lenovo issued a security bulletin Friday warning customers of two previously disclosed critical Broadcom vulnerabilities impacts 25 models of its popular ThinkPad laptops.

EFF Seeks Right to Jailbreak Alexa, Voice Assistants

The Electronic Frontier Foundation (EFF) is asking the Library of Congress to give owners of voice assistant devices like Amazon’s Echo, Google Home and other voice assistants the right to “jailbreak” the devices: freeing them from content control features designed to prevent users from running unauthorized code on those...

Read the whole entry... »

Related Stories

TippingPoint Threat Intelligence and Zero-Day Coverage – Week of February 5, 2018

It was a busy week in the cyber security world, but it shouldn’t be surprising given that the 2018 Winter Olympics in Pyeongchang have begun. I shouldn’t blame just the Olympics, but it’s hard not to given the international focus, controversy around the ban of certain athletes and its proximity to a certain country. So let’s jump right in…

Adobe Flash Player

Earlier this week, Adobe released a critical security update for a pair of vulnerabilities in Flash Player, one of which has been actively exploited in phishing attacks attributed to North Korean APT actor Group 123. Both bugs are classified as use-after-free vulnerabilities that can result in remote code execution. The vulnerability that is being actively exploited (CVE-2018-4878) was found by Kr-CERT/CC, South Korea’s national computer emergency response team. The other vulnerability (CVE-2018-4877) came through our Zero Day Initiative via “bo13oy” of Qihoo 360’s Vulcan Team.

This week’s Digital Vaccine® (DV) package includes coverage for the Adobe Flash vulnerabilities. The following table maps Digital Vaccine filters to the Adobe updates:

Bulletin # CVE # Digital Vaccine Filter # Status
APSB18-03 CVE-2018-4877 30346
APSB18-03 CVE-2018-4878 30343

 

WordPress “load-script” Usage Vulnerability

On Tuesday, we released DVToolkit CSW file CVE-2018-6389.csw for the WordPress “load-script” usage vulnerability. This filter detects usage of load-scripts.php in WordPress. The load-scripts.php is a built-in script in WordPress that processes user-defined requests. Due to insufficient validation, any user can send large amounts of requests for processing which could cause system resource exhaustion and result in a denial-of-service condition. User authentication is not required to exploit this vulnerability. Customers using TippingPoint solutions should note that the CSW filter will be obsoleted by DV filter 30356.

Cisco ASA WebVPN Host Scan Memory Corruption Vulnerability

We also released DVToolkit CSW file CVE-2018-0101.csw for the Cisco ASA WebVPN Host Scan Memory Corruption Vulnerability. This filter detects an attempt to exploit a memory corruption vulnerability in the Cisco Adaptive Security Appliance (ASA). The specific flaw is due to a failure to properly allocate memory when parsing the host-scan-reply tag. An attacker can leverage this vulnerability to execute arbitrary code in the context of the process. Authentication is not required to exploit this vulnerability. Customers using TippingPoint solutions should note that the CSW filter will be obsoleted by DV filter 30369.

Zero-Day Filters

There are 11 new zero-day filters covering five vendors in this week’s Digital Vaccine (DV) package. A number of existing filters in this week’s DV package were modified to update the filter description, update specific filter deployment recommendation, increase filter accuracy and/or optimize performance. You can browse the list of published advisories and upcoming advisories on the Zero Day Initiative website. You can also follow the Zero Day Initiative on Twitter @thezdi and on their blog.

Foxit (6)

  • 30318: ZDI-CAN-5312: Zero Day Initiative Vulnerability (Foxit Reader)
  • 30319: ZDI-CAN-5370,5372: Zero Day Initiative Vulnerability (Foxit Reader)
  • 30333: ZDI-CAN-5371: Zero Day Initiative Vulnerability (Foxit Reader)
  • 30335: ZDI-CAN-5373: Zero Day Initiative Vulnerability (Foxit Reader)
  • 30337: ZDI-CAN-5374: Zero Day Initiative Vulnerability (Foxit Reader)
  • 30338: ZDI-CAN-5375: Zero Day Initiative Vulnerability (Foxit Reader)

Hewlett Packard Enterprise (2)

  • 30308: HTTP: HPE Moonshot Provisioning Manager Appliance khuploadfile.cgi Directory Traversal (ZDI-18-001)
  • 30309: HTTPS: HPE Moonshot Provisioning Manager Appliance khuploadfile.cgi Directory Traversal (ZDI-18-001)

Microsoft (1)

  • 30330: ZDI-CAN-5369: Zero Day Initiative Vulnerability (Microsoft Internet Explorer)

Quest (1)

  • 28124: HTTP: Quest NetVault Backup Multipart Request Header Buffer Overflow Vulnerability (ZDI-18-004)

Trend Micro (1)

  • 30311: HTTPS: Trend Micro Mobile Security for Enterprise SQL Injection (ZDI-17-782)

Missed Last Week’s News?

Catch up on last week’s news in my weekly recap.

The State of Internet Security: Rising Risk Despite Reputation and Regulation

According to recent research, the security of the internet at large is shaky. Menlo Security reported that 42 percent of the top 100,000 websites as ranked by Alexa are potentially compromised and risky for users. To make matters worse, typical measures to weed out bad actors, including site reputation and category regulation, make little difference when it comes to overall security.

Neighborhood Watch

Digital citizens have established trusted neighborhoods — clusters of reputable sites that handle data responsibly, leverage cutting-edge internet security measures and stay up to date with threat developments. Typically, these sites have hard-won online reputations to back up these claims.

As noted by SC Magazine, however, cybercriminals are using public and corporate perceptions of trust to launch background, phishing and typosquatting attacks. As a result, more than 40 percent of trusted sites are considered risky because they’re running vulnerable software, have been used to distribute or launch malware attacks, or suffered a security breach in the last 12 months.

One particular area of concern is the number of background sites leveraged by trusted domains for content such as video or online advertisements. According to Infosecurity Magazine, the average website uses 25 background connections to deliver this content, but most enterprise administrators don’t have the monitoring solutions in place to determine whether these connections exhibit risky or criminal behavior.

User trust is also exploited through typosquatting. According to the Menlo Security data, 19 percent of typosquatting attacks — in which fraudsters claim domain names that are almost identical to those of familiar sites but with small typos — occurred in trusted website categories. Phishers also used the cover of legitimate domains to obfuscate their intentions and convince users to click on malicious links or download infected attachments.

Filling Internet Security Gaps

According to Menlo Security CEO Amir Ben-Efraim, the company’s recent study “confirms what most CISOs already know: that a false sense of security is a dangerous thing when using the web.” But what’s driving this overconfidence in a technology landscape filled with emerging threats?

Transparency is part of the problem. Most enterprises don’t have a clear picture of the risks posed by background sites and delivered content. Companies are also getting complacent once they reach a position of consumer trust, especially if they’ve successfully avoided recent internet security threats. In other words, there’s a sense that current firewalls and antivirus tools are enough to keep sites safe.

But a the Menlo data demonstrated, the opposite is true: Trusted sites are some of the most risky. Companies can’t afford to ignore background content simply because it’s never proven problematic before, because cybercriminals will exploit anything and everything connected to their intended targets.

Employee education is equally crucial. Attacks exploiting the human element, such as failure to notice typosquatting or getting duped by phishing emails, make up the lion’s share of successful trust-hacking. Educating employees cuts these attacks off at their source and improves total security hygiene.

Despite appearances, internet security for top sites is spotty at best. Organizations need to figure out how to track exactly what’s coming, going and happening on their networks.

The post The State of Internet Security: Rising Risk Despite Reputation and Regulation appeared first on Security Intelligence.

Smartphone Users Tracked Even with GPS, WiFi Turned Off

A team of researchers from Princeton has demonstrated that they can track the location of smartphone users even when location services like GPS and WiFi are turned off. The recent military security breach involving the Strava mobile fitness app proved the persistent vulnerabilities of location-based services on mobile devices. However, turning off...

Read the whole entry... »

Related Stories

Industrial Control Systems Storm the Internet, Increase Corporate Risk

Industrial control systems (ICS) manage critical infrastructure, networks and monitoring equipment. These components form such an integral part of corporate backbones that companies are often reticent to apply fixes for fear of sudden performance loss.

But firms putting off patches may be missing the forest for the trees. According to SecurityWeek, the number of internet-accessible ICS components is up 10 percent from the previous year, even as the number of critical vulnerabilities has almost doubled.

The Shifting Foundation of Industrial Control Systems

Traditionally, ICS were separated from internet-facing devices. In some cases, this took the form of logical separation. For more critical industries, such as power generation and infrastructure control, air-gapped machines offered the best protection.

But the rise of always-connected devices has shifted the ICS foundation. Now, companies need a way to remotely monitor supervisory control and data acquisition (SCADA) and network systems and respond to real-time threats. That may explain why a Positive Technologies report recently discovered 175,632 internet-accessible ICS components, 42 percent of which were located in the U.S.

The study also found that vulnerabilities are on the rise. Major enterprises reported 197 in 2017, compared to just 115 the year before — and these aren’t minor weaknesses. Based on Common Vulnerability Scoring System (CVSS) v3 scoring, 41 percent are classified as “high vulnerability” and 20 percent are “critical.”

Vladimir Nazarov, head of ICS security at Positive Technologies, noted that “overall, industrial systems aren’t more secure than they were 10 years ago.” Instead, they’re simply more accessible.

ICS-Specific Threats on the Rise

It’s one thing to talk about generalized ICS risk, but it’s another to break down the specifics. According to TechTarget, a recent ICS malware strain known as Trisis targeted Triconex safety instrumented system (SIS) controllers made by a major manufacturer. The attack was discovered the attack in December 2017, but a week later, the targeted company posted critical parts of the malware to VirusTotal, including the code’s main executable, even though no fix was available.

The results weren’t surprising: Files were quickly copied and posted to public code repositories. As noted by Infosecurity Magazine, 14 key vulnerabilities in the Hardware Against Software Piracy (HASP) license management system put ICS systems at risk of distributed denial-of-service (DDoS) and remote access channel attacks. By simply scanning for port 1947 — which requires a USB token to access but remains open after the token has been removed — cybercriminals can compromise industrial control systems that otherwise appear secure.

Accessibility is now the hallmark of advanced technology. Devices removed from the internet at large are quickly becoming obsolete. Industrial control systems present a paradox: Companies recognize the need to keep these systems operational at any cost, but can’t ignore the demand for real-time monitoring and response. As a result, both accessible devices and critical vulnerabilities are on the rise, driving the development of ICS-specific malware.

The cat’s out of the bag: Companies need to design better ICS security or brace for systemwide compromise.

The post Industrial Control Systems Storm the Internet, Increase Corporate Risk appeared first on Security Intelligence.

Namco driver: lesson almost learned

Recently, we started receiving suspicious events from our internal sandbox Exploit Checker plugin. Our heuristics for supervisor mode code execution in the user address space were constantly being triggered, and an executable file was being flagged for further analysis. At first, it looked like we’d found a zero-day local privilege escalation vulnerability for Windows, but the sample that was triggering Exploit Checker events turned out to be the clean signed executable GundamOnline.exe, part of the multiplayer online game Mobile Suit Gundam Online from BANDAI NAMCO Online Inc.

The initial sample is packed using a custom packer and contains anti-analysis techniques that complicate static analysis. For example, it tries to detect if it’s being launched inside a virtual machine by performing a well-known VMware hypervisor detection routine. It first loads the EAX register with the hypervisor magic value VMXh, and the ECX register with the value 0x0A, which is a special command to receive the hypervisor version. Then it performs an ‘in’ command to the VMware hypervisor I\O port 0x5658. If the EBX register is overwritten with VMXh as a result of that operation, it means the executable file is running on the VMware machine.

Our sandbox execution logs showed that the user space memory page is called from the driver bandainamcoonline.sys immediately after IOCTL request 0xAA012044 to device object \\.\Htsysm7838 that is created by the driver. The driver itself is installed just before that. It is first dropped to the directory C:\Windows\SysWOW64\ by a GundamOnline executable, loaded using NtLoadDriver() and deleted immediately afterwards.

Normally, this kind of behavior should not be allowed due to SMEP (Supervisor Mode Execution Prevention). This is a security feature present on the latest Intel processors that restricts supervisor mode execution on user memory pages. Page type is determined using the User/Supervisor flag in the page table entry. If a user memory page is called while in supervisor execution mode, SMEP generates an access violation exception and, as a result, the system will trigger a bug check and halt. This is commonly referred to as a BSOD.

The dropped driver itself is a legitimate driver, signed with a certificate issued to NAMCO BANDAI Online Inc.

The certificate validity period tells us two things. First, this certificate has been valid since 2012, which could mean that the first vulnerable version of the driver was released around the same time. However, we were unable to find one; the earliest sample of bandainamcoonline.sys that we found dates back to November 2015. Secondly, because it expired more than three years ago, you could be forgiven for thinking it’s impossible to install a driver signed with this certificate in a system. Actually, there’s nothing stopping you from installing and loading a driver with an expired certificate validity period.

In order to find the cause of the heuristics trigger, we need to do a static analysis of the driver itself. In the DriverEntry function it first decodes the device object name string in memory, and then creates the device \\.\Htsysm7838. The other two encoded strings – bandainamcoonline and bandainamcoonline.sys – are not used in the driver.

The driver itself is very small and contains only three registered major functions. Function IRP_MJ_DEVICE_CONTROL, which handles requests, accepts only two IOCTLs: 0xAA012044 and 0xAA013044. When called, it checks the size of the input and output buffers and eventually calls the ExecuteUserspaceCode function, passing on the contents of the input buffer to it.

The function ExecuteUserspaceCode performs a single check on the input buffer, which contains a pointer to a user space function or a shellcode, and disables SMEP while saving old CR4 register values. It then calls that function, passing it a pointer to the MmGetSystemRoutineAddress as an argument. After that it restores the original register state, re-enabling SMEP.

To be able to directly call the user function from the provided pointer driver it is necessary to remove a specific bit in the CR4 register first to temporarily stop SMEP, which is what the DisableSMEP function does. The original CR4 values are then restored by the EnableSMEP function.

The vulnerability in this case is that other than the basic checks on the format of the input buffer, no additional checks are done. Therefore, any user on the system can use this driver to elevate their privileges and execute arbitrary code in the Ring 0 of the OS. Even if the driver is not present in the system, an attacker can register it with Windows API functions and exploit the flaw.

We realized that this vulnerability looks exactly like the one found in Capcom’s driver last year.

Binary diffing bandainamcoonline.sys and capcom.sys proves exactly that, showing there are almost no differences between the two drivers. The only slight variations are the encoded strings and digital signatures. Because the earliest sample of the vulnerable driver that we’ve been able to find dates to November 2015, it can be assumed that this vulnerability first appeared in the bandainamcoonline.sys driver – almost a year before a similar driver was used by Capcom.

We believe both drivers were almost certainly compiled from the same source code, as a part of an anti-hacking solution to prevent users from cheating in the game. The presence of functions that implicitly disable and re-enable SMEP show that this design decision was intentional. But because the driver makes no additional security checks, any user can call and exploit the vulnerable IO control code by using Windows APIs such as DeviceIoControl(). This essentially makes the driver a rootkit, allowing anyone to interact with the operating system at the highest privilege level. In fact, we found multiple malware samples (already detected by our products) using a previously known vulnerability in capcom.sys to elevate their privileges to System level.

After finding the vulnerability we contacted BANDAI NAMCO Online Inc. The vendor responded promptly and released a patch three days later. They removed the driver altogether, and it is no longer loaded by the game executable. This is very similar to what Capcom did, and is perfectly acceptable in this case.

Finding this vulnerability wouldn’t have been possible without our Exploit Checker technology, which is a plugin for our sandbox, and can be also found in KATA (Kaspersky Anti Targeted Attack Platform). The technology was designed to monitor suspicious events that occur at the earliest post-exploitation phases and can detect common techniques used in exploits, such as ROP, Heap Spray, Stack Pivot, and so on. In this particular case, multiple heuristics for executing code in supervisor mode in the user address space were triggered, and the sample was flagged for further analysis. If a token-swapping attempt was performed to elevate process privileges, a technique that’s widely used in LPE exploits, it would have been automatically detected by Exploit Checker heuristics.

Kaspersky Lab solutions detect the vulnerable drivers mentioned in this article as HEUR:HackTool.Win32.Banco.a and HEUR:HackTool.Win32.Capco.a.

Securelist – Information about Viruses, Hackers and Spam: Namco driver: lesson almost learned

Recently, we started receiving suspicious events from our internal sandbox Exploit Checker plugin. Our heuristics for supervisor mode code execution in the user address space were constantly being triggered, and an executable file was being flagged for further analysis. At first, it looked like we’d found a zero-day local privilege escalation vulnerability for Windows, but the sample that was triggering Exploit Checker events turned out to be the clean signed executable GundamOnline.exe, part of the multiplayer online game Mobile Suit Gundam Online from BANDAI NAMCO Online Inc.

The initial sample is packed using a custom packer and contains anti-analysis techniques that complicate static analysis. For example, it tries to detect if it’s being launched inside a virtual machine by performing a well-known VMware hypervisor detection routine. It first loads the EAX register with the hypervisor magic value VMXh, and the ECX register with the value 0x0A, which is a special command to receive the hypervisor version. Then it performs an ‘in’ command to the VMware hypervisor I\O port 0x5658. If the EBX register is overwritten with VMXh as a result of that operation, it means the executable file is running on the VMware machine.

Our sandbox execution logs showed that the user space memory page is called from the driver bandainamcoonline.sys immediately after IOCTL request 0xAA012044 to device object \\.\Htsysm7838 that is created by the driver. The driver itself is installed just before that. It is first dropped to the directory C:\Windows\SysWOW64\ by a GundamOnline executable, loaded using NtLoadDriver() and deleted immediately afterwards.

Normally, this kind of behavior should not be allowed due to SMEP (Supervisor Mode Execution Prevention). This is a security feature present on the latest Intel processors that restricts supervisor mode execution on user memory pages. Page type is determined using the User/Supervisor flag in the page table entry. If a user memory page is called while in supervisor execution mode, SMEP generates an access violation exception and, as a result, the system will trigger a bug check and halt. This is commonly referred to as a BSOD.

The dropped driver itself is a legitimate driver, signed with a certificate issued to NAMCO BANDAI Online Inc.

The certificate validity period tells us two things. First, this certificate has been valid since 2012, which could mean that the first vulnerable version of the driver was released around the same time. However, we were unable to find one; the earliest sample of bandainamcoonline.sys that we found dates back to November 2015. Secondly, because it expired more than three years ago, you could be forgiven for thinking it’s impossible to install a driver signed with this certificate in a system. Actually, there’s nothing stopping you from installing and loading a driver with an expired certificate validity period.

In order to find the cause of the heuristics trigger, we need to do a static analysis of the driver itself. In the DriverEntry function it first decodes the device object name string in memory, and then creates the device \\.\Htsysm7838. The other two encoded strings – bandainamcoonline and bandainamcoonline.sys – are not used in the driver.

The driver itself is very small and contains only three registered major functions. Function IRP_MJ_DEVICE_CONTROL, which handles requests, accepts only two IOCTLs: 0xAA012044 and 0xAA013044. When called, it checks the size of the input and output buffers and eventually calls the ExecuteUserspaceCode function, passing on the contents of the input buffer to it.

The function ExecuteUserspaceCode performs a single check on the input buffer, which contains a pointer to a user space function or a shellcode, and disables SMEP while saving old CR4 register values. It then calls that function, passing it a pointer to the MmGetSystemRoutineAddress as an argument. After that it restores the original register state, re-enabling SMEP.

To be able to directly call the user function from the provided pointer driver it is necessary to remove a specific bit in the CR4 register first to temporarily stop SMEP, which is what the DisableSMEP function does. The original CR4 values are then restored by the EnableSMEP function.

The vulnerability in this case is that other than the basic checks on the format of the input buffer, no additional checks are done. Therefore, any user on the system can use this driver to elevate their privileges and execute arbitrary code in the Ring 0 of the OS. Even if the driver is not present in the system, an attacker can register it with Windows API functions and exploit the flaw.

We realized that this vulnerability looks exactly like the one found in Capcom’s driver last year.

Binary diffing bandainamcoonline.sys and capcom.sys proves exactly that, showing there are almost no differences between the two drivers. The only slight variations are the encoded strings and digital signatures. Because the earliest sample of the vulnerable driver that we’ve been able to find dates to November 2015, it can be assumed that this vulnerability first appeared in the bandainamcoonline.sys driver – almost a year before a similar driver was used by Capcom.

We believe both drivers were almost certainly compiled from the same source code, as a part of an anti-hacking solution to prevent users from cheating in the game. The presence of functions that implicitly disable and re-enable SMEP show that this design decision was intentional. But because the driver makes no additional security checks, any user can call and exploit the vulnerable IO control code by using Windows APIs such as DeviceIoControl(). This essentially makes the driver a rootkit, allowing anyone to interact with the operating system at the highest privilege level. In fact, we found multiple malware samples (already detected by our products) using a previously known vulnerability in capcom.sys to elevate their privileges to System level.

After finding the vulnerability we contacted BANDAI NAMCO Online Inc. The vendor responded promptly and released a patch three days later. They removed the driver altogether, and it is no longer loaded by the game executable. This is very similar to what Capcom did, and is perfectly acceptable in this case.

Finding this vulnerability wouldn’t have been possible without our Exploit Checker technology, which is a plugin for our sandbox, and can be also found in KATA (Kaspersky Anti Targeted Attack Platform). The technology was designed to monitor suspicious events that occur at the earliest post-exploitation phases and can detect common techniques used in exploits, such as ROP, Heap Spray, Stack Pivot, and so on. In this particular case, multiple heuristics for executing code in supervisor mode in the user address space were triggered, and the sample was flagged for further analysis. If a token-swapping attempt was performed to elevate process privileges, a technique that’s widely used in LPE exploits, it would have been automatically detected by Exploit Checker heuristics.

Kaspersky Lab solutions detect the vulnerable drivers mentioned in this article as HEUR:HackTool.Win32.Banco.a and HEUR:HackTool.Win32.Capco.a.



Securelist - Information about Viruses, Hackers and Spam

Researchers Find More Connected Sex Toys Face Hacking Risk

Researchers have found that Vibratissimo sex toys manufactured by a German company are vulnerable to attacks that could expose sensitive user information and allow hackers to take remote control of someone’s sex toy. Most people using smart sex toys might like to think their activities are private, but security researchers have proven once...

Read the whole entry... »

Related Stories

For YouTube Stars, Influencers: More Risk of Hacks after Octoly Breach

Octoly, the Paris-based agency for online “influencers” apologized following the leak of sensitive and personally identifying information on 12,000 clients. But clients were furious they were not informed by the company first and researchers warn that those exposed could face increased risks of both online and offline harm.  The firm...

Read the whole entry... »

Related Stories

Why Endpoint Management Is Critical to Security Strategy

Endpoint management is typically the responsibility of the IT operations or infrastructure teams, not the security team. So why should security care about endpoint hygiene?

Pervasive Endpoint Vulnerabilities

Attacks come from all directions, and many of them originate on endpoints. In fact, according to IDC, 70 percent of successful breaches begin at the endpoint. As of this writing, the National Institute of Standards and Technology (NIST) is tracking 100,311 known CVE vulnerabilities in its National Vulnerability Database (NVD). Of these, 15 percent were new vulnerabilities identified in 2017.

The Ponemon Institute’s “2017 State of Endpoint Security Risk” report found that 69 percent of companies believe that endpoint security risk to their organizations has significantly increased over the past 12 months, yet only 36 percent have adequate resources to address the risk. Most companies take an average of 100 to 120 days to patch vulnerabilities. In addition, many companies have critical vulnerabilities that go unpatched altogether.

Further complicating matters, up to 67 percent of systems administrators have trouble determining which patches need to be apply to which systems. A Gartner report titled “It’s Time to Align Your Vulnerability Management Priorities With the Biggest Threats” revealed that many security teams struggle to prioritize the most important threats. It’s no surprise, then, that vulnerability management is one of the most significant problems facing the security industry. Without adequate visibility into potentially infected endpoints across the enterprise, teams often patch these vulnerabilities in a non-directed, broad-based manner, which can leave endpoints vulnerable to the most damaging attack vectors.

Eight Steps to Improve Endpoint Management and Security

When new vulnerabilities are announced, IT teams must quickly query endpoints to understand which devices are at risk and determine their level of exposure. Once a remediation path is determined, security personnel must collaborate closely with infrastructure teams to ensure that the highest-priority patches are rolled out as quickly as possible to prevent exploitation of these new vulnerabilities. But this can get tricky, especially for organizations with remote locations and low bandwidth, or locations that only occasionally connect to the corporate network.

Below are eight best practices to help security professionals improve endpoint management:

  1. Use an endpoint management solution that supports bandwidth throttling so that remote endpoints can be continuously patched and secured rather than having to sporadically send IT resources to remote locations. (Hint: Check to see if bandwidth consumption can be set to less than 5 percent. This will ensure that remote productivity is not impacted while reducing IT time spent on patching and minimizing operational expenditures.)
  2. Consider an endpoint management that that delivers patches via the internet – without requiring corporate network access. This ensures that internet-facing systems are patched in a proactive, timely manner rather than IT having to wait for these devices to visit the corporate network before they can be scanned and remediated. (Hint: Look for cloud based content creation capabilities – This saves significant IT staff time that would have been spent creating patch packages.)
  3. Evaluate the scalability and administrative overhead of endpoint management solutions to accommodate tight budgets and future growth. Look for solutions that can support many endpoints using a single management server and make sure to understand how many IT resources will be needed to manage the solution on a daily basis. (Hint: Many companies can manage up to 250,000 endpoints using a single management console with one or two administrators.)
  4. Consolidate endpoint management tools. Use a single tool to patch systems across Windows, Mac and variations of Unix operating systems to simplify administration, minimize the number of open network ports, and reduce the number of active agents on endpoints. (Hint: Look for solutions that require only a single open network port to minimize risk.)
  5. Validate that the endpoint management solution provides accurate, real-time endpoint data and reports. End users make changes to endpoints all the time and information that is hours or days old may not reflect a current attack surface. (Hint: Seconds matter when under attack and real-time querying and reporting enables security teams to better prioritize patches based on actual risk.)
  6. Apply patches that address the highest levels of risk first based on current endpoint status. This gives the biggest impact from remediation efforts. (Hint: Aligning patching order to descending risk levels addresses the biggest and most serious vulnerabilities faster to better reduce overall attack surface.)
  7. Make sure the endpoint management solution enforces regulatory and corporate compliance policies on all endpoints constantly to avoid unintended drift and introduction of new vulnerabilities. (Hint: Not only does this reduce risk, it makes passing security and regulatory audits faster and easier saving IT organizations time and money.)
  8. Finally, check to see what other applications integrate with the endpoint management solution. (Hint: Look for tools that enable security teams to see endpoint data within existing security information and event management (SIEM), incident response and endpoint detection and response (EDR) tools to streamline remediation prioritization.)

Read the report: CISOs Investigate — Endpoint Security Peer-Authored Research

Endpoint Security Is a Daily Battle

Endpoint landscapes change constantly, and keeping up with these changes can be challenging. End users download unapproved applications all the time, some of which can contain malware. Operating system and application patches are difficult to prioritize and are not always successfully applied the first time, especially on remote or roaming endpoints with low bandwidth or inconsistent corporate network connectivity.

Visibility into endpoint status can be inaccurate, incomplete and ineffective. This increases the time and effort IT must spend on endpoint management and can impact your budget — as well as your weekends, credibility and even job security. Together, these things make passing regulatory and security audits difficult. What’s worse, it increases your attack surface and risk.

Let’s face it: Endpoint management and security is a daily battle. That’s why you need a solution that helps you discover, manage and secure your endpoints faster, more easily and more consistently.

The post Why Endpoint Management Is Critical to Security Strategy appeared first on Security Intelligence.

Massive Smominru Cryptocurrency Botnet Rakes In Millions

Researchers say Smominru threat actors are in control of 500,000 node botnet and earning $8,500 daily mining for Monero cryptocurrency.

Privacy Meltdown: Strava tricked into Revealing Soldiers’ Names

Days after Strava fitness heatmaps were shown to reveal the location of military bases, a Norwegian journalist  fooled Strava into revealing the names of some of soldiers and other personnel on those bases.  Strava’s decision to release a heat map visualization of billions of data points recorded from its millions of users is generating...

Read the whole entry... »

Related Stories

Cisco Patches Critical VPN Vulnerability

Cisco Systems released a patch Monday to fix a critical security vulnerability, with a CVSS rating of 10, in its Secure Sockets Layer VPN solution called Adaptive Security Appliance.

No Rest for the Weary: Applying Security Lessons From 2017 in the New Year

How can it be that we are already through January and moving into February of the new year? I don’t know about you, but I still have a long list of resolutions to accomplish and I need to focus on what I can realistically get done in 2018.

This makes me think about how everyone in the security industry has been talking about new initiatives and goals for 2018. However, we would be remiss not to look back at the security lessons we learned and the goals we collectively accomplished in 2017. To get a head start on the new year, we should reflect on these insights and apply them to the work we need to complete in 2018.

Taking Stock of Security Lessons From 2017

So what happened in 2017 that required us to work harder and be more diligent than we thought possible? As an esteemed colleague of mine kindly reminded me, these “exercises” are simply “opportunities” to better our cybersecurity skills.

As we in IBM Security, specifically the X-Force Exchange team, take the time to look back, we can appreciate the hard work and collaboration that transpired to help make the world a safer place. Below are a few highlights and accomplishments we were proud to bring to the security industry last year.

  • We worked together to address data breaches and vulnerabilities that kept us all on our toes. A few of the big ones, such as WannaCry, NotPetya and Bad Rabbit, come to mind.
  • IBM produced the “X-Force 2017 Data Breach Review,” which revealed that:
    • Computer services and government agencies were hardest hit by breaches in terms of number of records and incidents;
    • Misconfigurations accounted for the largest number of records breached; and
    • The U.S. was the largest bull’s-eye for breaches in terms of number of incidents.
  • We grew our user base to over 50,000 security professionals around the globe representing all major industries, and provided a go-to resource to research and share threat intelligence, including both indicators of compromise and higher-order insights.
  • Our team supported the Quad9 initiative with the Packet Clearing House (PCH) and Global Cyber Alliance (GCA). We even offered a domain for anyone to use to enhance security and privacy while traversing the web.
  • We listened to our users’ feedback to further improve the user experience of the X-Force Exchange. We incorporated numerous innovations to the platform, including more robust notifications, a customizable experience and more X-Force research on current threats and vulnerabilities.

Don’t Let Your Guard Down in 2018

Even though we are proud of all the progress we made and security lessons we learned in 2017, we can’t afford to slack on our goals and resolutions for 2018. Bad actors will continue to attack our networks and exploit both known and unknown vulnerabilities. That’s why it is good to set achievable goals to ensure that we are doing everything we can to protect what is most important within our companies. It also means that, as a community of security professionals, we need to keep working together to spread security awareness and deal with whatever threats come our way.

To learn more about how you can get ahead of the next cybercriminal trend, check out the X-Force Exchange and start using it today.

Explore the IBM X-Force Exchange Now

The post No Rest for the Weary: Applying Security Lessons From 2017 in the New Year appeared first on Security Intelligence.

Episode 81: Hacking IoT with Physics, Poor Grades for Safety Wearables and Peak Ransomware

In this week’s podcast: researcher Kevin Fu of University of Michigan discusses his work on attacks that use physics to manipulate connected devices. Also: Mark Loveless of DUO discusses his research into how poor implementation of wireless protocols make personal security trackers a privacy risk. And have we seen peak ransomware? Adam Kujawa of...

Read the whole entry... »

Related Stories

Meltdown and Spectre: the Situation as it Stands Today

It’s been more two weeks already since the vulnerabilities were announced that would affect microprocessors, mainly those of Intel and, to a lesser degree, AMD, as well as those based on ARM architecture. Here, we told you a bit about what’s been going on, but if you don’t feel like reading the whole thing, one of the best summaries we’ve seen on the differences between the two vulnerabilities and their effects can be found at Daniel Miessler’s blog.

What can be done if these vulnerabilities are exploited?

An attacker could have access to sensitive information in the system’s memory, even if the user who is on the device doesn’t have any permissions. And an attack could be launched simply by visiting a compromised webpage.

What needs to be updated to be protected?

The normal thing would be for the manufacturer to resolve your product’s vulnerability (in this case Intel, AMD, Apple, etc.) by means of an update. However, in this case it is not a simple update operation, and although manufacturers are still working on different patches that can be applied to their processors (in any case it does not seem that they can get a definitive solution, rather corrections than actual solutions to the problem), it is still something that is causing problems.

Intel, for example, has provided microinstruction updates for PC assemblers to apply to their processors, but they seem to be causing mysterious reboots on those machines, something Intel is still studying to see what causes it. The latest update we’ve had is this statement from Intel, in which they directly ask everyone to stop applying the patches they have published until they solve it:

“We recommend that OEMs, cloud service providers, system manufacturers, software vendors, and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior”.

 

Because of all this, processor manufacturers went to the developers of different operating systems (Windows, iOS, Chrome OS, etc.) to find a solution that covers the gap created by these vulnerabilities. Moreover, browser manufacturers are working on solutions to mitigate the problem, or at least the risk that the attack can be carried out from the browser through a malicious or compromised page.

Here you have the links to these manufacturers’ pages indicating the updates and measures that have been taken:

Google

Microsoft (*) Estaciones y Servidores

Apple

Amazon

(*) Microsoft discovered that its update causes blue screens on some computers with AMD processors. They have released specific updates for these issues that must be installed manually here and here.

And what about security solutions?

In the case of Windows, it turns out that when developing the solution Microsoft realized that some antivirus manufacturers showed blue screenshots if the update was applied, which is why it decided that the update would not be applied until the manufacturer added an entry in the Windows registry giving  the “green light” for the update.

While Panda’s solutions did not cause these blue screenshots, Microsoft only updates the operating system with the security patch if the registry entry is present. We proceeded to apply this registry entry to our customers. Here are the details: https://www.pandasecurity.com/uk/support/card?id=100059

If in addition to Panda you use some other security solution and you need to know their status, Kevin Beaumont has a table with the information from all the manufacturers here.

Are there real attacks that use Meltdown or Specter?

Not yet. But the keyword is “yet.” It is only a matter of time before these vulnerabilities are incorporated into attacks to gain access to sensitive information. We’ve said it before and we’ll say it again: it is very, very important to update.

The post Meltdown and Spectre: the Situation as it Stands Today appeared first on Panda Security Mediacenter.

The Effects of the Spectre and Meltdown Vulnerabilities

On January 3, the world learned about a series of major security vulnerabilities in modern microprocessors. Called Spectre and Meltdown, these vulnerabilities were discovered by several different researchers last summer, disclosed to the microprocessors' manufacturers, and patched­ -- at least to the extent possible.

This news isn't really any different from the usual endless stream of security vulnerabilities and patches, but it's also a harbinger of the sorts of security problems we're going to be seeing in the coming years. These are vulnerabilities in computer hardware, not software. They affect virtually all high-end microprocessors produced in the last 20 years. Patching them requires large-scale coordination across the industry, and in some cases drastically affects the performance of the computers. And sometimes patching isn't possible; the vulnerability will remain until the computer is discarded.

Spectre and Meltdown aren't anomalies. They represent a new area to look for vulnerabilities and a new avenue of attack. They're the future of security­ -- and it doesn't look good for the defenders.

Modern computers do lots of things at the same time. Your computer and your phone simultaneously run several applications -- ­or apps. Your browser has several windows open. A cloud computer runs applications for many different computers. All of those applications need to be isolated from each other. For security, one application isn't supposed to be able to peek at what another one is doing, except in very controlled circumstances. Otherwise, a malicious advertisement on a website you're visiting could eavesdrop on your banking details, or the cloud service purchased by some foreign intelligence organization could eavesdrop on every other cloud customer, and so on. The companies that write browsers, operating systems, and cloud infrastructure spend a lot of time making sure this isolation works.

Both Spectre and Meltdown break that isolation, deep down at the microprocessor level, by exploiting performance optimizations that have been implemented for the past decade or so. Basically, microprocessors have become so fast that they spend a lot of time waiting for data to move in and out of memory. To increase performance, these processors guess what data they're going to receive and execute instructions based on that. If the guess turns out to be correct, it's a performance win. If it's wrong, the microprocessors throw away what they've done without losing any time. This feature is called speculative execution.

Spectre and Meltdown attack speculative execution in different ways. Meltdown is more of a conventional vulnerability; the designers of the speculative-execution process made a mistake, so they just needed to fix it. Spectre is worse; it's a flaw in the very concept of speculative execution. There's no way to patch that vulnerability; the chips need to be redesigned in such a way as to eliminate it.

Since the announcement, manufacturers have been rolling out patches to these vulnerabilities to the extent possible. Operating systems have been patched so that attackers can't make use of the vulnerabilities. Web browsers have been patched. Chips have been patched. From the user's perspective, these are routine fixes. But several aspects of these vulnerabilities illustrate the sorts of security problems we're only going to be seeing more of.

First, attacks against hardware, as opposed to software, will become more common. Last fall, vulnerabilities were discovered in Intel's Management Engine, a remote-administration feature on its microprocessors. Like Spectre and Meltdown, they affected how the chips operate. Looking for vulnerabilities on computer chips is new. Now that researchers know this is a fruitful area to explore, security researchers, foreign intelligence agencies, and criminals will be on the hunt.

Second, because microprocessors are fundamental parts of computers, patching requires coordination between many companies. Even when manufacturers like Intel and AMD can write a patch for a vulnerability, computer makers and application vendors still have to customize and push the patch out to the users. This makes it much harder to keep vulnerabilities secret while patches are being written. Spectre and Meltdown were announced prematurely because details were leaking and rumors were swirling. Situations like this give malicious actors more opportunity to attack systems before they're guarded.

Third, these vulnerabilities will affect computers' functionality. In some cases, the patches for Spectre and Meltdown result in significant reductions in speed. The press initially reported 30%, but that only seems true for certain servers running in the cloud. For your personal computer or phone, the performance hit from the patch is minimal. But as more vulnerabilities are discovered in hardware, patches will affect performance in noticeable ways.

And then there are the unpatchable vulnerabilities. For decades, the computer industry has kept things secure by finding vulnerabilities in fielded products and quickly patching them. Now there are cases where that doesn't work. Sometimes it's because computers are in cheap products that don't have a patch mechanism, like many of the DVRs and webcams that are vulnerable to the Mirai (and other) botnets -- ­groups of Internet-connected devices sabotaged for coordinated digital attacks. Sometimes it's because a computer chip's functionality is so core to a computer's design that patching it effectively means turning the computer off. This, too, is becoming more common.

Increasingly, everything is a computer: not just your laptop and phone, but your car, your appliances, your medical devices, and global infrastructure. These computers are and always will be vulnerable, but Spectre and Meltdown represent a new class of vulnerability. Unpatchable vulnerabilities in the deepest recesses of the world's computer hardware is the new normal. It's going to leave us all much more vulnerable in the future.

This essay previously appeared on TheAtlantic.com.

WhatsApp Vulnerability

A new vulnerability in WhatsApp has been discovered:

...the researchers unearthed far more significant gaps in WhatsApp's security: They say that anyone who controls WhatsApp's servers could effortlessly insert new people into an otherwise private group, even without the permission of the administrator who ostensibly controls access to that conversation.

Matthew Green has a good description:

If all you want is the TL;DR, here's the headline finding: due to flaws in both Signal and WhatsApp (which I single out because I use them), it's theoretically possible for strangers to add themselves to an encrypted group chat. However, the caveat is that these attacks are extremely difficult to pull off in practice, so nobody needs to panic. But both issues are very avoidable, and tend to undermine the logic of having an end-to-end encryption protocol in the first place.

Here's the research paper.

New Rapidly-Spreading Hide and Seek IoT Botnet Identified by Bitdefender

BitDefender has identified a new fast-spreading IoT botnet called Hide and Seek that has the potential to perform information theft for espionage or extortion. Bitdefender security researchers have spotted a fast-spreading, shape-shifting new botnet that can hack IoT devices and potentially perform widespread information theft for espionage or...

Read the whole entry... »

Related Stories

Blog – Anitian: What You Need to Know About Meltdown and Spectre

Meltdown and Spectre

It has been a few weeks since security researchers discovered that nearly every processor on earth is vulnerable to Meltdown and Spectre vulnerabilities. Panic is spreading.

We agree, this is a serious set of vulnerabilities.  But, no need to panic. We got this.

No Immediate Danger

The first thing to remember is, these vulnerabilities are still theoretical. There are no real world applications of these exploits (yet). The difficulty of actually exploiting these vulnerabilities remains well beyond the skill level of most hackers.  While there is intense focus on this vulnerability due to the number of affected hosts, there is no reason to panic. Use this vulnerability as a chance to keep working toward better security maturity across your entire organization.

What is Meltdown and Spectre?

Rather than just repeat what others have said, here are some great articles on these two vulnerabilities:

In short: both of these vulnerabilities affect Intel and AMD processors and how data is stored in memory.  Since processors are inside everything, from smartphones to cloud infrastructure, these vulnerabilities affect, almost everything.  The flaw allows an attacker to gain access to memory or files based on predictable storage patterns.

That is bad.

How Bad?

Let’s say you host your applications in a cloud environment that does not patch for the Spectre vulnerability.  Theoretically, a hacker could manipulate the memory in the cloud environment to see secret data from your environment, without having any access to your environment.  That memory might contain anything, like passwords or encryption data.

That is really bad.

In comparison, when the Meltdown vulnerability is exploited, the hacker could then access restricted files. Even files with strict access controls, such as between different users, and even administrator files could be open to anyone. In other words, the security protections you put in place to protect your files could be entirely bypassed.

That is super bad.

What Do I Do?

  1. Patch your stuff
  2. Double check all those network and system level controls to keep unwanted malware out
  3. See step one

To be blunt, there is simply no reason you cannot patch your environment. If you have software that is so fragile that OS patching will break it, then you need to get new software (or hire better developers.)

What routinely amazes us is how few organizations regularly patch. In fact, a recent report showed that patching remains one of the top ten fundamental security tasks that organizations still do not do.

I Heard the Patches Are More Trouble

Ugh….yes.

Some of the initial, emergency patches for these vulnerabilities created performance issues. One report said that older Windows 7 and 8 machines are really hit hard, with degraded processor performance as much as 35%! That is, obviously, unacceptable for high performance environments (like cloud environments.)

However, new patches are being released that (allegedly) will reduce this performance impact.  Unfortunately, because this is a flaw at the processor and firmware level, it is difficult to patch this vulnerability in the OS. At best, these are band-aids. The real changes must be made at the BIOS or processor architecture level.

In light of the patch problems, this underscores the need for all the other important security controls, namely network and system level access controls.

We Must Be Safe Because We Have a Next Generation…

Honestly, none of the “next generation” stuff can detect or block this attack at this time. Theoretically, antivirus products will detect this, but antivirus products are notoriously easy to bypass.  The same goes for NGFWs and IDS/IPS products.

This is Bad for the Cloud

Meltdown and Spectre vulnerabilities are uniquely damaging to cloud security due to how they allow accessibility to confidential data as well as the performance degradation. Since cloud providers run multiple customers on a single host, there is a possibility of data crossing over from one environment to another.

That is catastrophically bad. But, again, nobody has done this in the wild…yet.

Cloud providers are patching their systems.  AWS and Google have already patched their environments. (More information on AWS updates).

If you run a private cloud or virtualized on-premise environment, then you must patch your own systems. All of the virtualization providers have released patches.

How Serious is the Threat?

While everything we have said sounds awful, the threat here is not as dire as it may appear.

It is a forgone conclusion that organized crime and nation state hackers are already working on exploit kits for these vulnerabilities. Considering the extensive resources these groups possess, it is only a matter of time before they release something (they may have already.)  Moreover, when they do release an attack, most of us will not know about it until the exploits spread, are discovered, and analyzed.

However, cloud providers are getting ahead of this threat. Nevertheless, this is why you must be vigilant on patching, as well as all the other recommended security best practices.  Hackers feed on poorly managed, maintained, and secured environments. If you want to stay ahead of the threat,

Lastly, do not become distracted with news that doomsday is here and there is no hope. Solutions do exist. This meltdown will pass and you can return to the normal chaos of life.

The post What You Need to Know About Meltdown and Spectre appeared first on Anitian.



Blog – Anitian

Intel: Don’t Install Faulty Spectre, Meltdown Patches

In-brief: Intel has warned users not to install patches it released for the Spectre and Meltdown vulnerabilities in its processors, asking them to wait until it issues new software, which it’s working on now. Finding out your device has vulnerabilities is bad enough, but finding out the patched issued to fix them are “complete and utter...

Read the whole entry... »

Related Stories

Google security researcher has discovered a critical vulnerability in Blizzard games that put millions of PCs at risk

Tavis Ormandy (Google security researcher) has discovered a critical vulnerability in Blizzard games that could enable remote attackers to run

The post Google security researcher has discovered a critical vulnerability in Blizzard games that put millions of PCs at risk appeared first on Latest Hacking News.

SecurityWeek RSS Feed: Seagate Patches Flaws in Personal Cloud, GoFlex Products

Seagate recently patched several vulnerabilities discovered by researchers in the company’s Personal Cloud and GoFlex products, but some weaknesses impacting the latter remain unfixed.

GoFlex Home vulnerabilities

read more



SecurityWeek RSS Feed

Episode 80: APT Three Ways

In this week’s Security Ledger Podcast, Episode – number 80 – we look at Advanced Persistent Threat (or APT) actors three ways with three different experts offering their take on the world’s most sophisticated hacking groups in Russia, North Korea and the Middle East.  Advanced Persistent Threats (APTs) are the most dreaded of...

Read the whole entry... »

Related Stories

A silver bullet for the attacker

In the past years, the problem of vulnerabilities in industrial automation systems has been becoming increasingly important. The fact that industrial control systems have been developing in parallel with IT systems, relatively independently and often without regard for modern secure coding practices is probably the main source of ICS security problems. As a result of this, numerous custom solutions have appeared, including proprietary network protocols and algorithms for authentication and encryption. It is these solutions that were the main source of threats discovered by ICS IT security researchers. At the same time, we can see that industrial automation systems derive some of their problems from common technologies (examples include CodeSys Runtime, Microsoft Windows vulnerabilities, etc.).

Companies attach different priority levels to such problems and the risks associated with them. It is obvious for everybody that vulnerability information should never be disclosed until a patch is released. However, many companies believe that this information should not be published even when a patch is available. For software developers, this is always a blow to their reputation. And companies that use vulnerable systems are not always physically able to install a patch or this installation may involve significant costs (interrupted operation of the systems to be updated, the cost of work related to installing updates, etc.).

We assess risks based on our experience of a security system developer and supplier. We are convinced that it is absolutely essential to inform users of vulnerable software about the new threat and the need to update their software as soon as possible. This certainly does not guarantee that all users of vulnerable systems will promptly update them and the threat will go away. However, in our experience, if this is not done very few users update their systems in a timely manner, even if patches are available. We confront hundreds of thousands of new threats every day and we can see that threat actors are on a constant lookout for new attack opportunities. And we realize that by keeping silent about problems we give those threat actors a chance.

This is why we decided to share information on one of our discoveries: according to our research, connecting a software license management token to a computer may open a hidden remote access channel for an attacker.

Why we decided to analyze SafeNet Sentinel

While performing various penetration tests, Kaspersky Lab ICS CERT experts repeatedly encountered the same service on the computers of customers who used software and hardware solutions by different industrial vendors. The experts didn’t attach much importance to it until it was found to be vulnerable. The service was hasplms.exe, which is part of the SafeNet Sentinel hardware-based solution by Gemalto. The solution provides license control for software used by customers and is widely used in ICS and IT systems.

The solution’s software part consists of a driver, a web application and a set of other software components. The hardware part is a USB token. The token needs to be connected to a PC or server on which a software license is required. Some of the USB token models are listed in the table below.

License control solutions of this type are based on the following operating principles: a software product requires a license to operate properly; when a USB token is plugged into the computer, the software “sees” the license and becomes fully functional. The token must be plugged in every time the software is started and remain connected while it is in use. The software part of the Gemalto solution is installed once and remains functional regardless of the life cycle of the software requiring a token.

This Gemalto solution is used in products by other software vendors, including such companies as ABB, General Electric, HP, Cadac Group, Zemax and many other organizations, the number of which, according to some estimates, reaches 40 thousand.

According to the results of independent research conducted by Frost and Sullivan in 2011, SafeNet Sentinel, which is currently owned by Gemalto, has a 40% market share for license control solutions in North America and over 60% in Europe.

The number of end users who use Gemalto solutions is not known. However, if each company has 100 clients, the number of users is in the millions. Unfortunately, few people realize that connecting a token to a computer to control licenses may not be a safe thing to do.

Vulnerabilities and attack vectors

From researchers’ viewpoint, hasplms.exe exhibited a rather curious behavior in the system: it could be remotely accessed and communicated with on open port 1947. The protocol type was defined by the network packet header – either HTTP or a proprietary binary protocol was used. The service also had an API of its own, which was based on the HTTP protocol.

Analyzing the service was made more difficult by the fact that the binary file used a VMProtect-type protector and generated its bytecode from the original Gemalto code. Due to this, it was decided to use fuzzing as the main tool for analyzing the vulnerable service’s behavior.

First of all, we looked at the localization function – the user could download language packs consisting of two files, one of which was localize.xml. The second file, in HTML format, had parameters, one of which turned out to be vulnerable to buffer overflow. It would have been a simple vulnerability, if it wasn’t for one curious detail: although, as mentioned above, a protector was used, for some reason the developers did not use any of the classical mechanisms providing protection from such binary vulnerabilities (such as Stack Canary, Stack Cookie, ASLR, etc.). As a result, a simple buffer overflow could allow an attacker to execute arbitrary code on the remote system.

Note that such software development flaws are very rare in modern solutions. As a rule, secure coding practices are implemented when developing serious commercial products (such as SDL – security development lifecycle), which means that security is designed into applications at the development stage, rather than being implemented as an additional option.

This attack vector can be used without LPE (local privilege escalation) – the vulnerable process runs with SYSTEM privileges, enabling malicious code to run with the highest privileges.

Sample script loading a language pack file

Result of Buffer Overflow exploitation, leading to RCE

The vulnerability was assigned the number CVE-2017-11496.

This was just one of the vulnerabilities we found. And the overall result of our research was disquieting.

In late 2016 – early 2017, 11 vulnerabilities were identified: two allowed remote code execution if exploited and nine were denial-of-service vulnerabilities.

By June 2017, Kaspersky Lab ICS CERT had identified three more vulnerabilities: an XML bomb and two denial-of-service flaws, one of which could potentially lead to remote execution of arbitrary code.

In total, 14 vulnerabilities have been identified, all quite dangerous (for example, exploitation of each of the Remote Execution of Arbitrary Code type vulnerabilities is automatically performed with SYSTEM privileges, i.e., the highest privilege level in Windows).

All attack vectors affecting the vulnerable service were multi-stage.

We promptly sent all information on the vulnerabilities identified to Gemalto. The vulnerabilities were assigned the following respective CVE numbers:

In addition to vulnerability descriptions, we sent a description of peculiar functionality to Gemalto.

Peculiar functionality

Kaspersky Lab ICS CERT experts have found that hasplms.exe has some rather unusual functionality:

  • When a Gemalto USB token is first connected to a computer (even if the active session is blocked), a driver and service that accepts network connections on port 1947 are installed if the Internet access is available.
  • If a driver is manually downloaded from the Gemalto website and installed, a driver and service that accept network connections on port 1947 are installed and port 1947 is added to Windows firewall exceptions.
  • If Gemalto software is installed as part of a third-party installation file, port 1947 is also added to Windows firewall exceptions.
  • There is an API function which enables or disables the administrative panel in the web interface, making it possible to modify the settings of the program part of the SafeNet Sentinel hardware-based solution. The panel is available by default on the localhost IP address – 127.0.0.1.
  • The API can be used to change the internal proxy settings for updating language packs.
  • After changing the proxy server, the service’s internal logic can be used to obtain the NTLM hash of the user account under which the hasplms.exe process is running (i.e., SYSTEM).

This appears to be an undocumented feature and can be used for stealthy remote access. This means that remote attackers can use these capabilities to gain access to the administrative panel of the Gemalto software, carry out attacks with system user privileges and conceal their presence after completing these attacks.

As mentioned above, Gemalto representatives were informed of this attack vector.

Non-transparent security

Solutions, technologies or individual software modules used by many third-party vendors often do not undergo proper security testing. This potentially opens up new attack vectors. At the same time, closing vulnerabilities in such products, which are often used, among other applications, in banking and industrial control systems, is not always a smooth process: for some reason, vendors of such systems are in no hurry to notify their users of problems identified in their products.

In early 2017, we sent information about 11 vulnerabilities we had identified to Gemalto. It was only in late June that, in response to our repeated requests, the vendor informed us that a patch had been released and information about the vulnerabilities that had been closed, as well as a new version of the driver, could be found on the company’s internal user portal.

On June 26, we informed Gemalto of the suspicious functionality and of three more vulnerabilities. This time, things went quicker: on July 21 the vendor released a private notice on a new driver version – without any mention of the vulnerabilities closed.

According to Gemalto, the company has notified all of its customers of the need to update the driver via their account dashboards. However, this was apparently not sufficient: after we published information about the vulnerabilities identified, we were contacted by several developers of software which uses hasplms. It became clear from our communication with them that they were not aware of the problem and continued to use versions of the product with multiple vulnerabilities.

Update software to the current version (7.6) ASAP

We urge those users and companies that use Gemalto’s SafeNet Sentinel to install the latest (secure) version of the driver as soon as possible or contact Gemalto for instructions on updating the driver. We also recommend closing port 1947, at least on the external firewall (on the network perimeter) – but only as long as this does not interfere with business processes.

In the case of installing the driver via Microsoft Windows Update servers, we recommend checking hasplms.exe to make sure it is the latest version. If an obsolete version is used, it is crucial to install the latest (secure) version of the driver from the vendor’s website or contact Gemalto for instructions on updating the driver.

We also recommend closing port 1947, at least on the external firewall (on the network perimeter) – but only as long as this does not interfere with business processes. This will help to reduce the risk of the vulnerabilities being exploited.

Some software vendors who use third-party solutions as part of their products may be very thorough about the security of their own code, while leaving the security of third-party solutions to other companies (the vendors of these solutions). We very much hope that most companies act responsibly both with respect to their own solutions and with respect to third-party solutions used in their products.

Securelist – Information about Viruses, Hackers and Spam: A silver bullet for the attacker

In the past years, the problem of vulnerabilities in industrial automation systems has been becoming increasingly important. The fact that industrial control systems have been developing in parallel with IT systems, relatively independently and often without regard for modern secure coding practices is probably the main source of ICS security problems. As a result of this, numerous custom solutions have appeared, including proprietary network protocols and algorithms for authentication and encryption. It is these solutions that were the main source of threats discovered by ICS IT security researchers. At the same time, we can see that industrial automation systems derive some of their problems from common technologies (examples include CodeSys Runtime, Microsoft Windows vulnerabilities, etc.).

Companies attach different priority levels to such problems and the risks associated with them. It is obvious for everybody that vulnerability information should never be disclosed until a patch is released. However, many companies believe that this information should not be published even when a patch is available. For software developers, this is always a blow to their reputation. And companies that use vulnerable systems are not always physically able to install a patch or this installation may involve significant costs (interrupted operation of the systems to be updated, the cost of work related to installing updates, etc.).

We assess risks based on our experience of a security system developer and supplier. We are convinced that it is absolutely essential to inform users of vulnerable software about the new threat and the need to update their software as soon as possible. This certainly does not guarantee that all users of vulnerable systems will promptly update them and the threat will go away. However, in our experience, if this is not done very few users update their systems in a timely manner, even if patches are available. We confront hundreds of thousands of new threats every day and we can see that threat actors are on a constant lookout for new attack opportunities. And we realize that by keeping silent about problems we give those threat actors a chance.

This is why we decided to share information on one of our discoveries: according to our research, connecting a software license management token to a computer may open a hidden remote access channel for an attacker.

Why we decided to analyze SafeNet Sentinel

While performing various penetration tests, Kaspersky Lab ICS CERT experts repeatedly encountered the same service on the computers of customers who used software and hardware solutions by different industrial vendors. The experts didn’t attach much importance to it until it was found to be vulnerable. The service was hasplms.exe, which is part of the SafeNet Sentinel hardware-based solution by Gemalto. The solution provides license control for software used by customers and is widely used in ICS and IT systems.

The solution’s software part consists of a driver, a web application and a set of other software components. The hardware part is a USB token. The token needs to be connected to a PC or server on which a software license is required. Some of the USB token models are listed in the table below.

License control solutions of this type are based on the following operating principles: a software product requires a license to operate properly; when a USB token is plugged into the computer, the software “sees” the license and becomes fully functional. The token must be plugged in every time the software is started and remain connected while it is in use. The software part of the Gemalto solution is installed once and remains functional regardless of the life cycle of the software requiring a token.

This Gemalto solution is used in products by other software vendors, including such companies as ABB, General Electric, HP, Cadac Group, Zemax and many other organizations, the number of which, according to some estimates, reaches 40 thousand.

According to the results of independent research conducted by Frost and Sullivan in 2011, SafeNet Sentinel, which is currently owned by Gemalto, has a 40% market share for license control solutions in North America and over 60% in Europe.

The number of end users who use Gemalto solutions is not known. However, if each company has 100 clients, the number of users is in the millions. Unfortunately, few people realize that connecting a token to a computer to control licenses may not be a safe thing to do.

Vulnerabilities and attack vectors

From researchers’ viewpoint, hasplms.exe exhibited a rather curious behavior in the system: it could be remotely accessed and communicated with on open port 1947. The protocol type was defined by the network packet header – either HTTP or a proprietary binary protocol was used. The service also had an API of its own, which was based on the HTTP protocol.

Analyzing the service was made more difficult by the fact that the binary file used a VMProtect-type protector and generated its bytecode from the original Gemalto code. Due to this, it was decided to use fuzzing as the main tool for analyzing the vulnerable service’s behavior.

First of all, we looked at the localization function – the user could download language packs consisting of two files, one of which was localize.xml. The second file, in HTML format, had parameters, one of which turned out to be vulnerable to buffer overflow. It would have been a simple vulnerability, if it wasn’t for one curious detail: although, as mentioned above, a protector was used, for some reason the developers did not use any of the classical mechanisms providing protection from such binary vulnerabilities (such as Stack Canary, Stack Cookie, ASLR, etc.). As a result, a simple buffer overflow could allow an attacker to execute arbitrary code on the remote system.

Note that such software development flaws are very rare in modern solutions. As a rule, secure coding practices are implemented when developing serious commercial products (such as SDL – security development lifecycle), which means that security is designed into applications at the development stage, rather than being implemented as an additional option.

This attack vector can be used without LPE (local privilege escalation) – the vulnerable process runs with SYSTEM privileges, enabling malicious code to run with the highest privileges.

Sample script loading a language pack file

Result of Buffer Overflow exploitation, leading to RCE

The vulnerability was assigned the number CVE-2017-11496.

This was just one of the vulnerabilities we found. And the overall result of our research was disquieting.

In late 2016 – early 2017, 11 vulnerabilities were identified: two allowed remote code execution if exploited and nine were denial-of-service vulnerabilities.

By June 2017, Kaspersky Lab ICS CERT had identified three more vulnerabilities: an XML bomb and two denial-of-service flaws, one of which could potentially lead to remote execution of arbitrary code.

In total, 14 vulnerabilities have been identified, all quite dangerous (for example, exploitation of each of the Remote Execution of Arbitrary Code type vulnerabilities is automatically performed with SYSTEM privileges, i.e., the highest privilege level in Windows).

All attack vectors affecting the vulnerable service were multi-stage.

We promptly sent all information on the vulnerabilities identified to Gemalto. The vulnerabilities were assigned the following respective CVE numbers:

In addition to vulnerability descriptions, we sent a description of peculiar functionality to Gemalto.

Peculiar functionality

Kaspersky Lab ICS CERT experts have found that hasplms.exe has some rather unusual functionality:

  • When a Gemalto USB token is first connected to a computer (even if the active session is blocked), a driver and service that accepts network connections on port 1947 are installed if the Internet access is available.
  • If a driver is manually downloaded from the Gemalto website and installed, a driver and service that accept network connections on port 1947 are installed and port 1947 is added to Windows firewall exceptions.
  • If Gemalto software is installed as part of a third-party installation file, port 1947 is also added to Windows firewall exceptions.
  • There is an API function which enables or disables the administrative panel in the web interface, making it possible to modify the settings of the program part of the SafeNet Sentinel hardware-based solution. The panel is available by default on the localhost IP address – 127.0.0.1.
  • The API can be used to change the internal proxy settings for updating language packs.
  • After changing the proxy server, the service’s internal logic can be used to obtain the NTLM hash of the user account under which the hasplms.exe process is running (i.e., SYSTEM).

This appears to be an undocumented feature and can be used for stealthy remote access. This means that remote attackers can use these capabilities to gain access to the administrative panel of the Gemalto software, carry out attacks with system user privileges and conceal their presence after completing these attacks.

As mentioned above, Gemalto representatives were informed of this attack vector.

Non-transparent security

Solutions, technologies or individual software modules used by many third-party vendors often do not undergo proper security testing. This potentially opens up new attack vectors. At the same time, closing vulnerabilities in such products, which are often used, among other applications, in banking and industrial control systems, is not always a smooth process: for some reason, vendors of such systems are in no hurry to notify their users of problems identified in their products.

In early 2017, we sent information about 11 vulnerabilities we had identified to Gemalto. It was only in late June that, in response to our repeated requests, the vendor informed us that a patch had been released and information about the vulnerabilities that had been closed, as well as a new version of the driver, could be found on the company’s internal user portal.

On June 26, we informed Gemalto of the suspicious functionality and of three more vulnerabilities. This time, things went quicker: on July 21 the vendor released a private notice on a new driver version – without any mention of the vulnerabilities closed.

According to Gemalto, the company has notified all of its customers of the need to update the driver via their account dashboards. However, this was apparently not sufficient: after we published information about the vulnerabilities identified, we were contacted by several developers of software which uses hasplms. It became clear from our communication with them that they were not aware of the problem and continued to use versions of the product with multiple vulnerabilities.

Update software to the current version (7.6) ASAP

We urge those users and companies that use Gemalto’s SafeNet Sentinel to install the latest (secure) version of the driver as soon as possible or contact Gemalto for instructions on updating the driver. We also recommend closing port 1947, at least on the external firewall (on the network perimeter) – but only as long as this does not interfere with business processes.

In the case of installing the driver via Microsoft Windows Update servers, we recommend checking hasplms.exe to make sure it is the latest version. If an obsolete version is used, it is crucial to install the latest (secure) version of the driver from the vendor’s website or contact Gemalto for instructions on updating the driver.

We also recommend closing port 1947, at least on the external firewall (on the network perimeter) – but only as long as this does not interfere with business processes. This will help to reduce the risk of the vulnerabilities being exploited.

Some software vendors who use third-party solutions as part of their products may be very thorough about the security of their own code, while leaving the security of third-party solutions to other companies (the vendors of these solutions). We very much hope that most companies act responsibly both with respect to their own solutions and with respect to third-party solutions used in their products.



Securelist - Information about Viruses, Hackers and Spam

Migrating to SAP HANA? How Can You Ensure Security of Your Business-Critical Data?

If your company runs SAP, there is a chance that you might be planning to adopt SAP HANA this year. Due to the speed with which the platform is being deployed in hybrid models, security might be overlooked, and any misconfigurations or vulnerabilities can result in millions of dollars in compliance costs if exploited by attackers or rogue insiders. In fact, the Ponemon Institute recently placed the average cost of data breaches impacting SAP systems at $4.5 million and revealed that 65 percent of companies had experienced one or more SAP breach within the last two years.

Business-Critical Data Under Attack

Cybercriminals are increasingly targeting SAP systems, and with good reason. According to an Onapsis report titled “The Tip of the Iceberg: Wild Exploitation and Cyberattacks on SAP Business Applications,” 87 percent of Forbes 2000 companies use SAP, and 76 percent of the world’s transaction revenue is processed by SAP systems.

SAP stores crown jewels such as critical business, personal and financial data, which requires managing myriad regulatory and compliance requirements. It also runs the most business-sensitive processes in the organization. According to Dark Reading, cybercriminals have demonstrated how SAP applications can be used as a steppingstone to sabotage oil and gas processes.

It stands to reason that you’ll need a security impact assessment and strategy for the move to SAP Business Suite 4 SAP HANA (SAP S/4HANA). That strategy must address external threats as well as governance, risk management and compliance in specific SAP components, such as segregation of duties and sensitive access, to reduce the overall risk. Plus, you’ll need to focus on protecting new capabilities enabled by SAP HANA.

Learn How to Manage a Successful SAP HANA Migration

On Jan. 25 at noon EST, Britta Simms, global SAP competency lead with IBM Security, will co-host a joint webinar with ERP Maestro, our SAP risk reporting and controls automation partner. In this webinar, Simms will walk through IBM’s HANA Assessment Tool approach to evaluating enterprise systems for the move to SAP HANA. She will cover threats both external and internal, including an analysis of security roles and authorizations, which are likely to change during a migration.

Join the Jan. 25 webinar: When moving to HANA, don’t leave security behind

IBM Security services can help reduce the vulnerabilities in the SAP systems that house your organization’s most valuable information. With the right combination of SAP monitoring, automated alerts and rapid responses, attacks can be disrupted in real time.

IBM offers flexible services for the full range of SAP systems to help you:

  • Assess SAP systems for vulnerabilities and compliance risks, tying business context into remediation planning processes.
  • Align your SAP security policies with the latest industry standards.
  • Help protect against known-but-unpublished vulnerabilities.
  • Leverage continuous monitoring and advanced threat protection against zero-day attacks.
  • Streamline auditing and compliance management.

Join us for Thursday’s webinar if your organization is planning or considering a move to SAP HANA. You’ll get real guidance on how to start the process to assess the impact the project would have on your business — not to mention your current SAP security design.

The post Migrating to SAP HANA? How Can You Ensure Security of Your Business-Critical Data? appeared first on Security Intelligence.

SecurityWeek RSS Feed: Gemalto Licensing Tool Exposes ICS, Corporate Systems to Attacks

A significant number of industrial and corporate systems may be exposed to remote attacks due to the existence of more than a dozen vulnerabilities in a protection and licensing product from Gemalto.

read more



SecurityWeek RSS Feed

Misconfigured Jenkins Servers Leak Sensitive Data

A researcher has conducted an analysis of Jenkins servers and found that many of them leak sensitive information, including ones belonging to high-profile companies.

London-based researcher Mikail Tunç used the Shodan search engine to find Jenkins servers accessible from the Internet and discovered roughly 25,000 instances.

read more

SecurityWeek RSS Feed: Triton Malware Exploited Zero-Day in Schneider Electric Devices

The recently discovered malware known as Triton and Trisis exploited a zero-day vulnerability in Schneider Electric’s Triconex Safety Instrumented System (SIS) controllers in an attack aimed at a critical infrastructure organization.

read more



SecurityWeek RSS Feed

Triton Malware Exploited Zero-Day in Schneider Electric Devices

The recently discovered malware known as Triton and Trisis exploited a zero-day vulnerability in Schneider Electric’s Triconex Safety Instrumented System (SIS) controllers in an attack aimed at a critical infrastructure organization.

read more

Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware in Recent Campaign

Introduction

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

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

Infection Vector

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

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

  • Telecommunications
  • Insurance
  • Financial Services


Figure 1: Sample lure documents

Attack Flow

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

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


Figure 2: Zyklon attack flow

Infection Techniques

CVE-2017-8759

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

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


Figure 3: Embedded URL in OLE object

CVE-2017-11882

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


Figure 4: Embedded URL in OLE object


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

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


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

Dynamic Data Exchange (DDE)

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


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

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

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


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

Zyklon Delivery

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

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


Figure 9: Base64 decoded Pause.ps1

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


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

Once executed, the file performs the following activities:

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


Figure 11: XML configuration file to schedule the task

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

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

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

Command & Control Communication

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


Figure 12: Zyklon public RSA key

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

Command

Action

sign

Requests system information

settings

Requests settings from C2 server

logs

Uploads harvested passwords

wallet

Uploads harvested cryptocurrency wallet data

proxy

Indicates SOCKS proxy port opened

miner

Cryptocurrency miner commands

error

Reports errors to C2 server

ddos

DDoS attack commands

Table 1: Zyklon accepted commands

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


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


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


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

Plugin Manager

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

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

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

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

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

Additional Features

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

Browser Password Recovery

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

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

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

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

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

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

Zyklon may also collect email passwords from following applications:

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

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

Socks5 Proxy

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

Hijack Clipboard Bitcoin Address

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

Zyklon Pricing

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

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

Conclusion

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

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

Detection Name

Product

Action

POWERSHELL DOWNLOADER D (METHODOLOGY)

HX

Detect

SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)

HX

Detect

POWERSHELL DOWNLOADER (METHODOLOGY)

HX

Detect

SUSPICIOUS EQNEDT USAGE (METHODOLOGY)

HX

Detect

TOR (TUNNELER)

HX

Detect

SUSPICIOUS SVCHOST.EXE (METHODOLOGY)

HX

Detect

Malware.Binary.rtf

EX/ETP/NX

Block

Malware.Binary

EX/ETP/NX

Block

FE_Exploit_RTF_CVE_2017_8759

EX/ETP/NX

Block

FE_Exploit_RTF_CVE201711882_1

EX/ETP/NX

Block

Table 2: Current detection capabilities by FireEye products

Indicators of Compromise

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

MD5

Name

76011037410d031aa41e5d381909f9ce

accounts.doc

4bae7fb819761a7ac8326baf8d8eb6ab

Courrier.doc

eb5fa454ab42c8aec443ba8b8c97339b

doc.doc

886a4da306e019aa0ad3a03524b02a1c

Pause.ps1

04077ecbdc412d6d87fc21e4b3a4d088

words.exe

Table 3: Sample Zyklon lures

Network Indicators
  • 154.16.93.182
  • 85.214.136.179
  • 178.254.21.218
  • 159.203.42.107
  • 217.12.223.216
  • 138.201.143.186
  • 216.244.85.211
  • 51.15.78.0
  • 213.251.226.175
  • 93.95.100.202
  • warnono.punkdns.top

Google Chrome Once Again Target of Malicious Extensions

Researchers at network security vendor ICEBRG recently discovered four malicious extensions in the official Google Chrome Web Store with a combined user count of more than 500,000, and as with past incidents, the implications are serious for both consumers and enterprises. ICEBRG notified Google and three of the extensions have since been removed from the […]

Cryptocurrency Exchanges, Students Targets of North Korea Hackers

A late-2017 state-sponsored cyber attacks by North Korea against South Korea not only targeted cryptocurrency users and exchanges, but also college students interested in foreign affairs, new research from Recorded Future has found. North Korea shows no signs of letting up on its cyber war against South Korea with state-sponsored attacks against...

Read the whole entry... »

Related Stories

Shared Accounts Increasingly Problematic for Critical Infrastructure: ICS-CERT

Assessments conducted last year by the U.S. Department of Homeland Security’s Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) showed that boundary protection remains the biggest problem in critical infrastructure organizations, but identification and authentication issues have become increasingly common.

read more

Episode 79: Hackable Nukes, Dissecting Naughty Toys and APTs IRL

In this week’s Security Ledger Podcast episode, sponsored by the firm Flashpoint, the UK -based policy think tank Chatham House warned last week that aging nuclear weapons systems in the U.S., the U.K. and other nations are vulnerable to cyber attacks that could be used to start a global conflagration. We talk with Eddie Habbibi of PAS Global...

Read the whole entry... »

Related Stories

Adult Themed Virtual Reality App spills Names, Emails of Thousands

Thousands of users of an adult virtual reality application risk having their personal information, including names and email addresses exposed, according to researchers in the UK. Thousands of Internet denizens who wanted to explore their virtual naughty side are in for an unpleasant surprise after a firm offering an adult virtual reality game,...

Read the whole entry... »

Related Stories

Updated Security Protocol Boosts Wi-Fi Protected Access

The Wi-Fi Alliance has announced that it will launch Wi-Fi Protected Access (WPA3) later this year. This updated version of the globally used wireless security protocol aims to boost network defenses. WPA3 will replace WPA2, the current network security protocol that has been in use for over a decade, according to the official press release.

In the intervening period, the Wi-Fi Alliance will enhance WPA2 to ensure that it provides strong security protection. IT decision-makers should consider the imminent introduction of WPA3 as an important development in an evolving security landscape.

Enhancing the Current Standard

Wi-Fi Protected Access is used by billions of wireless devices around the globe, including smartphones, tablets and connected devices associated with the Internet of Things (IoT). The Wi-Fi Alliance has certified more than 35,000 Wi-Fi products since the turn of the millennium.

The association, which includes some of the technology industry’s most powerful companies, announced it will use the widespread adoption of WPA2 as a platform to deliver new security configurations. Most of these capabilities will emerge later this year during the introduction of WPA3.

For now, WPA2 will still be deployed in Wi-Fi devices — with some improvements to help guarantee strong security protection for users. The industry body claimed that “testing enhancements will also reduce the potential for vulnerabilities due to network misconfiguration and further safeguard managed networks with centralized authentication services,” according to the press release.

Wi-Fi Protected Access Strengthens Security

The new WPA3 protocol will be available for consumer and business wireless devices later this year. Because the Wi-Fi Protected Alliance must certify hardware before it can use the WPA3 protocol, it could take several months before companies can support the new security protocol.

While full specifications of the WPA3 program are not yet available, the Wi-Fi Alliance believes the updated standard will:

  • Strengthen the privacy of users in open networks via individualized data encryption.
  • Provide protection and prevent cybercriminals from undertaking multiple login attempts via commonly used passwords.
  • Simplify security configuration for technology that does not include a display, such as IoT devices.
  • Use 192-bit security, aligned with the Commercial National Security Algorithm, to protect critical networks.

Beware of Network Intrusion

IT decision-makers should welcome the enhancements to WPA2 and the emergence of WPA3 later this year. Security experts have long warned of the potential impact of network intrusion at the corporate level, and vulnerabilities in WPA2 left the door open for cybercriminals to take advantage of lax Wi-Fi security.

To enhance security, security leaders must use a range of technologies, including tools for the detection, investigation and remediation phases of breaches. Increased attention on the network will be crucial in the age of connectivity, especially as the number of connected devices increases.

The post Updated Security Protocol Boosts Wi-Fi Protected Access appeared first on Security Intelligence.

Meltdown and Spectre fallout: patching problems persist

Last week, the disclosure by multiple teams from Graz and Pennsylvania University, Rambus, Data61, Cyberus Technology, and Google Project Zero of vulnerabilities under the aliases Meltdown and Spectre rocked the security world, sending vendors scurrying to create patches, if at all possible, and laying bare a design flaw in nearly all modern processors.

The fallout from these revelations continues to take shape, as new information on the vulnerabilities and the difficulties with patching them comes to light daily. In the days since Meltdown and Spectre have been made public, we’ve tracked which elements of the design flaw, known as speculative execution, are vulnerable and how different vendors are handling the patching process. By examining the applied patches’ impact against one of our own products, Adwcleaner, we found that they are, indeed, causing increases in CPU usage, which could result in higher costs for individuals billed by Cloud providers accordingly.

What is speculative execution?

Speculative execution is an effective optimization technique used by most modern processors to determine where code is likely to go next. Hence, when it encounters a conditional branch instruction, the processor makes a guess for which branch might be executed based on the previous branches’ processing history. It then speculatively executes instructions until the original condition is known to be true or false. If the latter, the pending instructions are abandoned, and the processor reloads its state based on what it determines to be the correct execution path.

The issue with this behaviour and the way it’s currently implemented in numerous chips is that when the processor makes a wrong guess, it has already speculatively executed a few instructions. These are saved in cache, even if they are from the invalid branch. Spectre and Meltdown take advantage of this situation by comparing the loading time of two variables, determining if one has been loaded during the speculative execution, and deducing its value.

As explained in our post last week, the potential danger of an attack using these vulnerabilities includes being able to read “secured” memory belonging to a process. This can do things like reveal personally identifiable information, banking information, and of course usernames and passwords. On cloud environment, these vulnerabilities allow extracting data from the host and other VMs.

Example of speculative execution

Using the Project Zero example below, the process will evaluate the condition if(untrusted_offset_from_caller < arr1->length) at a later time, and start a speculative execution of both branches, leading to two different index2 values. This example corresponds to variant 1 of Spectre (CVE-2017-5753) and works on most Intel, AMD, ARM, and IBM CPUs.

struct array {
    unsigned long length;
    unsigned char data[];
};
struct array *arr1 = ...; /* small array */
struct array *arr2 = ...; /* array of size 0x400 */
/* >0x400 (OUT OF BOUNDS!) */
unsigned long untrusted_offset_from_caller = ...;
if (untrusted_offset_from_caller < arr1->length) {
    unsigned char value = arr1->data[untrusted_offset_from_caller];
    unsigned long index2 = ((value&1)*0x100)+0x200;
if (index2 < arr2->length) {
    unsigned char value2 = arr2->data[index2];
}

If the processor predicts that the condition is true, value will load:

unsigned char value = arr1->data[untrusted_offset_from_caller];

Based on value, it’s possible to load index2, which can be 0x200 or 0x300 due to the bitwise operation:

unsigned long index2 = ((value&1)*0x100)+0x200;

The second condition is then executed and the last instruction loads value2 as arr2->data[0x200] or arr2->data[0x300].

Once the initial condition has been evaluated and the processor notices that the execution flow above is wrong, the value of value2 stays in the L1 cache. It’s then possible to compare the loading time of arr2->data[0x200] and arr2->data[0x300], and deduce which one has been evaluated during the speculative execution. From there, it’s easy to figure out related variables: Here the value of arr1->data[untrusted_offset_from_caller] is a value that shouldn’t be possible to retrieve according to the expected code flow, since it allows to leak out-of-bound memory.

In order to exploit this behaviour, the code pattern above has to be present on the victim’s machine. As detailed in Jann Horn’s writeup, a locally installed software, a JIT (Javascript is a particularly interesting candidate), or an interpreter (he used eBPF) meet the requirements.

Four variants

While it was initially reported that Spectre and Meltdown correspond to three vulnerabilities, four variants actually exist:

Variants 1 and 2 of Spectre impact Intel, IBM, ARM, and AMD CPUs. Meltdown appears to be exclusive to Intel CPUs, and allows attackers to read privileged memory from an unprivileged context, still using the speculative execution feature. Its variant 3a is exploitable on a few ARM CPUs only.

The fact that these vulnerabilities impact the CPUs themselves make them difficult to patch. A software-only solution may bring important performance issues, as would a hardware-only fix. Thus, various hardware vendors have been working together in the past months working on fixes. However, while major players like Amazon and Microsoft got early access to the vulnerabilities reports, other providers did not. They discovered the vulnerabilities at the same time as the disclosure on January 3.

Vendors band together

Those who weren’t in on the secret formed a task group with other providers in order to exchange information and to pressure hardware manufacturers. Scaleway, OVH, Linode, Packet, Digital Ocean, Vultr, Nexcess, and prgmr.com have been part of it, later joined by Amazon, Tata Communications, and also parts of the RedHat and Ubuntu teams. On January 9, part of the researchers (Moritz Lipp, Daniel Gruss, Michael Schwarz from the Graz University of Technology) who discovered the vulnerabilities also joined in.

Some Open-Source developers also explained that they had not received any information prior the public disclosure, but were actively working on providing patches.

We have received *no* non-public information. I’ve seen posts elsewhere by
other *BSD people implying that they receive little or no prior warning, so
I have no reason to believe this was specific to OpenBSD and/or our
philosophy.

Mitigations began to land upstream in the Linux kernel shortly after the public disclosure to address the vulnerabilities separately. Some require a hardware-vendor-issued microcode to be applied to the processor in order to make the software patch effective. Most of these patches are simply workarounds, however, to avoid making the CPU behave as explained above. We may expect some hardware change in future generations of processors at some point, but there’s no easy, quick fix for now.

Available patches for hardware and OSes

The upstream Linux patch for Meltdown (variants 3 and 3a) takes advantage of KPTI (Kernel Page Table Isolation) and has been backported to Linux 4.14, 4.9 and 4.4. It’s is available in most distribution’s official kernels. Debian has shipped it in most releases, as RedHat has done. Ubuntu published theirs a few hours ago, although some critical issues have been discovered and quickly addressed. Tails published an update, too. The patches for ARM64 haven’t been merged yet but are expected to be merged later.

Variant 1 (Spectre) requires changes to compilers behaviour and Intel suggests adding LFENCE (see 3.1 Bounds Check Bypass Mitigation; other vendors have other suggestions) as a barrier to stop speculation in specific places. This means that the kernel and software has to be recompiled in order to avoid making the processor use the speculative execution when it’s problematic. Again, although we may expect hardware changes in future generations of Intel chips, we can’t expect this to happen for a long time.

Variant 2 (also Spectre) requires both a microcode patch from CPU vendors and a patch from the kernel to leverage IBRS (Indirect Branch Speculation Feature), STIBP, and IBPB. Another suggestion called “retpoline” has been introduced by Paul Turner from Google and is also being implemented in various compilers, including GCC and LLVM, even though some questions still remain about its efficiency on certain CPU models.

Vulnerability (Linux) Software mitigation Hardware mitigation
Meltdown (3 & 3a)
KPTI Not needed
Spectre 1 n/a n/a
Spectre 2 IBRS / Retpoline Microcode

Proprietary vendors have also published several updates:

  • Apple addressed the two Meltdown variants in iOS 11.2, macOS 10.13.2, and tvOS 11.2. Spectre is being mitigated in iOS 11.2.2 and the macOS 10.13.2 Supplemental Update, even though only recompiled software are an effective mitigation for variant 1.
  • Google has included some mitigations for the three variants in its Android Security Bulletin on January 5. Note that further mitigations are expected in next month’s updates, especially a kernel with KPTI.

Regarding Microsoft, the process has been bumpier. They’ve released various fixes for the platform, but made several requirements for the patches for Spectre and Meltdown to be effective:

  1. If an antivirus solution is registered in the Windows Security Center, it needs to set the following registry key:

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”
Data="0x00000000”

Only then can the January Patch Tuesday patch be applied. Note that Malwarebytes users have been able to successfully receive the patch since its publication.

2. As pointed out by Kevin Beaumont, a specific manipulation must be done on Windows Server to apply the patch and enable it. After creating the following keys and restarting the host, the mitigation should be in place:

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization” /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d “1.0” /f

A few moments later, users began to report computers running with AMD processors becoming unbootable after applying the patch. Microsoft has stopped delivering the patch to those configurations while working with AMD to find a solution.

Available software patches

Apart from hardware manufacturers and OS vendors, software editors have also been quick to mitigate the exploitation of Spectre. Browser vendors and virtualization solutions are particularly exposed to these vulnerabilities and have been the fastest to respond.

  • Xen published an advisory sharing details about the vulnerabilities in its hypervisor’s scope alongside a documentation page explaining how to mitigate.
  • Mozilla released Firefox 57.0.4 soon after publishing an article explaining how they managed to exploit Spectre remotely using Javascript and WebAssembly. This update makes time source less precise, thus making the exploitation a lot more unreliable while more in-depth fixes are engineered.
  • Google Chrome followed shortly after with an explanatory article about how Spectre could be exploited using WebKit’s JavascriptCore and listing the upcoming mitigations in Webkit.

Numerous Proof of Concepts have been published to demonstrate the exploitation of the different variants, from reconstructing an image to applying it against a specifically-crafted Intel SGX enclave. It’s also possible to test if mitigations are in place: Microsoft released a solution that can be used remotely based on the new PowerShell SpeculationControl module, and several solutions are available on Linux-based OSes.

Patches impact on AdwCleaner’s infrastructure

Disclaimer: The following is not a benchmark, but feedback based on what we have observed in our hardware environment and software stack. The observed behaviour is highly dependent on the workload, and there may be no changes observed in yours.

As part of our security process, we’ve applied fixes as soon as they were made available by our distributions and hosting providers. We were expecting some performance increase, especially on AdwCleaner storage backend, but it was hard to quantify.

CPU load before and after KPTI patch on AdwCleaner storage backend.

CPU load before and after KPTI patch on AdwCleaner storage backend.

After applying the new Linux kernel with the KPTI backport, we’ve observed a 10 to 15 percent increase of CPU usage. (We applied the patch slightly before 00:00 UTC on January 6). These servers do not take advantage of PCID, which could make the difference in performance less visible. As this usage increase appears to be the new baseline for some time, this is likely to at least temporary lead to important cost increases for users of providers billing based on CPU usage, although some providers are reported working with severely impacted customers.

As the situation still evolves quickly every day, some updates may be added to both the original story and this blogpost.

Particularly interesting literature:

The post Meltdown and Spectre fallout: patching problems persist appeared first on Malwarebytes Labs.

Yet Another FBI Proposal for Insecure Communications

Deputy Attorney General Rosenstein has given talks where he proposes that tech companies decrease their communications and device security for the benefit of the FBI. In a recent talk, his idea is that tech companies just save a copy of the plaintext:

Law enforcement can also partner with private industry to address a problem we call "Going Dark." Technology increasingly frustrates traditional law enforcement efforts to collect evidence needed to protect public safety and solve crime. For example, many instant-messaging services now encrypt messages by default. The prevent the police from reading those messages, even if an impartial judge approves their interception.

The problem is especially critical because electronic evidence is necessary for both the investigation of a cyber incident and the prosecution of the perpetrator. If we cannot access data even with lawful process, we are unable to do our job. Our ability to secure systems and prosecute criminals depends on our ability to gather evidence.

I encourage you to carefully consider your company's interests and how you can work cooperatively with us. Although encryption can help secure your data, it may also prevent law enforcement agencies from protecting your data.

Encryption serves a valuable purpose. It is a foundational element of data security and essential to safeguarding data against cyber-attacks. It is critical to the growth and flourishing of the digital economy, and we support it. I support strong and responsible encryption.

I simply maintain that companies should retain the capability to provide the government unencrypted copies of communications and data stored on devices, when a court orders them to do so.

Responsible encryption is effective secure encryption, coupled with access capabilities. We know encryption can include safeguards. For example, there are systems that include central management of security keys and operating system updates; scanning of content, like your e-mails, for advertising purposes; simulcast of messages to multiple destinations at once; and key recovery when a user forgets the password to decrypt a laptop. No one calls any of those functions a "backdoor." In fact, those very capabilities are marketed and sought out.

I do not believe that the government should mandate a specific means of ensuring access. The government does not need to micromanage the engineering.

The question is whether to require a particular goal: When a court issues a search warrant or wiretap order to collect evidence of crime, the company should be able to help. The government does not need to hold the key.

Rosenstein is right that many services like Gmail naturally keep plaintext in the cloud. This is something we pointed out in our 2016 paper: "Don't Panic." But forcing companies to build an alternate means to access the plaintext that the user can't control is an enormous vulnerability.

Researchers: SCADA Mobile Apps Continue to Have ‘Shocking’ Number of Vulnerabilities

Despite their availability on mobile networks and thus increased exposure to outside security threats, SCADA apps remain highly insecure and vulnerable to attack, putting critical industrial control systems at immediate and increased risk, researchers at IOActive and Embedi have found. While it might be good news for industrial control system...

Read the whole entry... »

Related Stories

Five Essential Reads to Understand the Meltdown and Spectre Processor Flaws

There has been plenty of (digital) ink spilled in recent days about widespread processor flaws known as “Meltdown” and “Spectre.” We round up five articles that will help you understand these security vulnerabilities, how they were discovered and their likely impact.  The flaws, which affect processors by Intel, AMD, ARM...

Read the whole entry... »

Related Stories

Survey: Most Security Pros Aim to Patch Vulnerabilities within 30 Days

High-profile cybersecurity incidents continue to result from the simple mistake of leaving a known vulnerability unpatched. To understand how organizations are keeping up with vulnerabilities, Tripwire partnered with Dimensional Research to survey 406 IT security professionals about their patching processes. Findings revealed that the majority (78 percent) fix all vulnerabilities detected on their network within […]… Read More

The post Survey: Most Security Pros Aim to Patch Vulnerabilities within 30 Days appeared first on The State of Security.

Meltdown and Spectre

Cisco Talos is aware of three new vulnerabilities impacting Intel, AMD, Qualcomm and ARM processors used by almost all computers. We are investigating these issues and although we have not observed exploitation of these vulnerabilities in the wild, that does not mean that it has not occurred. We have observed publicly available proof of concept exploit code being developed to exploit these vulnerabilities.

These issues have been assigned the following CVE entries:

    Meltdown: An attacker can access kernel memory from user space
        Spectre: An attacker can read memory contents from other users' running programs

            These issues involve side channel and cache attacks that enable an attacker to steal sensitive information from memory space they should not be able to normally access. Google Project Zero published a blog providing technical details regarding these vulnerabilities. An example attack scenario would be an attacker stealing credentials from the memory space of another process. Two criteria must be met in order for these vulnerabilities to be exploited.
              1. The device being targeted must utilize an affected Intel, AMD, Qualcomm, or ARM processor (most processors from the last 10+ years fall into the category of "vulnerable").
              2. An attacker must be able to execute their own code (this includes Javascript) on the device. Depending on the vulnerability, the code may be executed as unprivileged code, or in others, as privileged ("root" or "SYSTEM") code.
                 There are three likely scenarios where attackers may attempt to leverage these vulnerabilities.
                1. Spectre could be leveraged to launch attacks against virtualized hosting environments. Given that it is possible to read host memory from within a guest, this could result in an attacker gaining access to the host OS. This sort of attack scenario mainly impacts cloud hosting providers such as Amazon, Azure, Google, etc. These providers are working to ensure customers are not impacted by these vulnerabilities. Check with your specific hosting provider for additional details. It is important to note that successfully exploiting these vulnerabilities in this scenario is not trivial.
                2. It is important to note that Spectre is accessible from within the web browser on affected devices which could allow malicious web sites to read arbitrary data from other browser tabs. Mozilla has confirmed this on their blog here. This could allow a remote attacker to obtain sensitive information, such as session or cookie data for other active sessions. It is important to note that this sort of an attack would likely only work under specific conditions. This attack would also require an attacker to convince a user to visit a malicious website in order to execute the code required to steal data.
                3. Meltdown could enable attackers to exploit additional vulnerabilities more easily. Meltdown allows for the defeating of Kernel Address Space Randomization (KASLR). This means that any vulnerability that wasn't previously exploitable due to KASLR is now potentially exploitable if chained together with Meltdown. This would be specific to the vulnerability the attacker is attempting to leverage, but from an attacker perspective it does remove some of the hurdles and problems encountered during the creation of their exploits.
                  As with all vulnerabilities, applying published patches is a crucial step to preventing an attacker from successfully exploiting these vulnerabilities. Microsoft, Linux and Apple have released patches for Meltdown. Other affected products are listed here. Applying the Microsoft patch may result in incompatibility issues with existing security software running on your system. To verify your patch status you can use the PowerShell modules provided by Microsoft. For affected Cisco devices please refer to the PSIRT advisory. Currently no patches are available for Spectre. As soon as Operating System patches are available for Spectre, we recommend that you apply them to your system as soon as possible.

                  As with all attacks, it is also critical that the initial infection vector be blocked whenever possible as each of these vulnerabilities require an attacker to be able to execute code on an affected system.

                  Some examples of blocking the initial vector include:

                  1. Using ad blocking and script disabling software can minimize the risk of Javascript-based browser attacks.
                  2. Cisco Umbrella can be used to block access to known malicious sites that may be launching attacks targeting these vulnerabilities.
                  3. Web Security Appliance (WSA) can be used to block access to known malicious sites.
                  4. FirePower NGFW can be used to block network based attacks leveraging these vulnerabilities.
                  5. AMP for Endpoints and Networks can be used to block known droppers that may be used to infect systems with malware that leverages these vulnerabilities.
                  6. AMP's exploit prevention engine covers multiple techniques that would be used after a successful Meltdown or Spectre memory read, that would be necessary for gaining code execution.

                  Coverage


                  Snort SIDs: 45357-45368

                  AMP Compatibility is documented here. AMP's exploit prevention system is documented here.

                  These signatures cover the specific PoC's and sample code outlined in the Spectre and Meltdown whitepapers. While these signatures have the potential to detect variants, they may not work for all cases. We still recommended that affected organizations install the OS and firmware patches to protect against this class of attacks. Talos is continuing to monitor the situation and will provide updated information as soon as it is available.

                  Episode 78: Meltdown and Spectre with Joe Unsworth of Gartner and will GDPR spark a Data War in 2018?

                  In this week’s Security Ledger podcast, Joe Unsworth has been covering the semiconductor space for Gartner for 15 years, but he’s never seen anything like Meltdown and Spectre, the two vulnerabilities that Google researchers identified in a wide range of microprocessors. In this podcast, Joe comes in to talk with us about what the flaws...

                  Read the whole entry... »

                  Related Stories

                  VERT Threat Alert: CPU Vulnerabilities – Meltdown and Spectre

                  Vulnerability Description Meltdown and Spectre are hardware design vulnerabilities in CPUs utilizing speculative execution. While the defect exists in the hardware, mitigations in operating systems are possible and are currently available. CPU hardware implementations are vulnerable to side-channel attacks referred to as Meltdown and Spectre. The issues are organized into three variants: CVE-2017-5753, Spectre Variant […]… Read More

                  The post VERT Threat Alert: CPU Vulnerabilities – Meltdown and Spectre appeared first on The State of Security.

                  Spectre and Meltdown from a CNO Perspective

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

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

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

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

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

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

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

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

                  Meltdown and Spectre vulnerability guidance

                  On January 3rd 2018, researchers at Google’s Project Zero team announced vulnerabilities, dubbed Spectre and Meltdown, in modern computer processors (CPUs) which could allow an attacker to access sensitive data.

                  This issue is an inherent design issue in the computer processors and as such the ultimate remediation is to replace the affected CPUs.

                  AVAILABLE GUIDANCE
                  Details of the vulnerabilities are available from Google Project Zero at their site.

                  The UK’s National Cyber Security Centre has released guidance on how to handle the vulnerabilities and the US CERT provides a listing of all the vendor updates.

                  There are two websites dedicated to the vulnerabilities, Meltdown Attack and Spectre Attack.

                  VENDOR UPDATES AND PATCHES
                  A number of software vendors have released information updates and/or provided patches to their platforms to mitigate the risk posed by this vulnerability. Note some vendors have warned that applying their patches may result in a performance degradation on the patched systems due to how the patch changes how the CPU manages processes.

                  Microsoft
                  Microsoft has provided guidance to protect against the vulnerabilities and have also issued their monthly patch earlier than expected.

                  Please note that various anti-virus vendors have announced they do not yet support the above patch so before applying the patch check with your anti-virus vendor. This is a good list that you can also refer to in order to determine if you anti-virus vendor supports the patch

                  Linux Operating Systems

                  VMWare

                  Citrix

                  • Citrix has released information for their Citrix and Xen platforms

                  CLOUD COMPUTING PROVIDERS
                  Details of updates to the issue from various cloud providers are available as follows:

                  Amazon
                  Microsoft Azure
                  Google

                  You should also contact your own hosting provider to ensure they have applied patches to any platforms that your systems may be hosted on.

                  RECOMMENDATIONS
                  Until affected hardware can be replaced, we recommend that you make yourself familiar with the vulnerabilities and their potential impact on your systems.  You should make contact with your vendors to get their guidance and any available patches.

                  All patches should be thoroughly tested to determine if they impact on performance or if there are any third party compatibility issues, such as conflicts as outlined earlier with anti-virus software. Based on the results of that testing and a comprehensive risk assessment we recommend strongly that the patches are applied.

                  Keep in mind that you may not be able to patch all affected systems in a timely fashion so ensure you run regular reviews to detect any unpatched systems and to then apply the patches.

                  You should also configure your IDS/IPS systems to detect any suspicious traffic, some IDS/IPS vendors have issued updates to detect attacks against these vulnerabilities.

                  Regularly monitoring of your systems for suspicious activity should be in place to detect a potential breach, and finally you should review your incident response processes to be prepared in the event of a breach resulting from these vulnerabilities.

                  The post Meltdown and Spectre vulnerability guidance appeared first on BH Consulting.

                  Google details CPU flaws, claims AMD, ARM and Intel all affected

                  Google has come forward to claim responsibility for discovering a pair of serious security holes in Intel processors that run almost 9 in 10 computers in the world. And worse: the company has echoed a statement by Intel yesterday that the flaws are not specific to that company’s chips. Contrary to published reports, a blog post on the Google...

                  Read the whole entry... »

                  Related Stories

                  Update: Two Years After Discovery Dangerous Security Hole Lingers in GPS Services

                  Security researchers warned of a serious vulnerability in a GPS service by the China-based firm ThinkRace exposes sensitive data in scores of GPS services, more than two years after the hole was discovered and reported to the firm. (Update: added comment from John van den Oever, the CEO of one2track B.V – PFR 1/3/2018) Data including a GPS...

                  Read the whole entry... »

                  Related Stories

                  IoT lottery: finding a perfectly secure connected device

                  Black Friday and Cyber Monday are great for shopping. Vendors flood the market with all kinds of goods, including lots of exciting connected devices that promise to make our life easier, happier and more comfortable. Being enthusiastic shoppers just like many other people around the world, at Kaspersky Lab we are, however paranoid enough to look at any Internet of Things (IoT)-device with some concern, even when the price is favorable. All because there is little fun in buying a coffeemaker that would give up your home or corporate Wi-Fi password to an anonymous hacker, or a baby-monitor that could livestream your family moments to someone you most definitely don’t want it livestreamed to.

                  It is no secret that the current state of security of the IoT is far from perfect, and in buying one of those devices you are potentially buying a digital backdoor to your house. So, while preparing for IoT-shopping this year, we asked ourselves: what are our chances of buying a perfectly secure connected device? To find the answer, we conducted a small experiment: we randomly took several different connected devices and reviewed their security set up. It would be an exaggeration to say that we conducted a deep investigation. This exercise was more about what you’d be able to see at first glance if you had a clue about how these things should and shouldn’t work. As a result we found some rather worrying security issues and a few, less serious, but unnecessary ones.

                  We looked at the following devices: a smart battery charger, an app-controlled toy car, an app-controlled smart set of scales, a smart vacuum cleaner, a smart iron, an IP camera, a smart watch, and a smart home hub.

                  Smart Charger

                  The first device we checked was the smart charger that attracted us with its built-in Wi-Fi connectivity. You may ask yourself: who would need a remotely controlled battery charger, especially when you need to manually set the battery to charge? Nevertheless, it exists and it allows you not only to charge the battery, but to manage the way you charge it. Like a boss.

                  The device we tested charges and restores most types of batteries with a nominal voltage from 3 to 12 volts. It has a Wi-Fi module, which allows the device owner to connect remotely to control the charging process, to change the charging settings and to check how much electricity the battery is storing at any time.

                  Once turned on, the device switches by default to ‘access point’ mode. The user should then connect to the device and open the management interface web page. The connection between the charger and the device you use to access the management panel uses the outdated and vulnerable WEP algorithm instead of WPA2. However it is password protected. Having said that, the predefined password is ‘11111’ and it is actually written in the official documentation that comes with the device and is searchable online. However, you can change the password to a more secure one. Having said that, the length of the password is limited, for some reason, to five symbols. Based on the information available here, it would take four minutes to crack such a password. In addition to that the web interface of the device itself has no password protection at all. It is available as is, once it is connected to your home Wi-Fi network.

                  Who would attack a smart charger anyway, you may well ask, and you would probably be right as there are likely few black hat hackers in the world who would want to do that. Especially when it requires the attacker to be within range of the Wi-Fi signal or have access to your Wi-Fi router (which, by the way, is a much bigger problem). On the other hand, the ability to interfere with how the battery is charging, or randomly switching the parameters could be considered as worth a try by a wicked person. The probability of real damage, like setting fire to the battery or just ruining it is heavily dependent on the type of battery, however the attack can be performed just for lulz. Just because they can.

                  To sum up: most likely when using this device, you won’t be in constant danger of a devastating remote cyberattack. However, if your battery eventually catches fire while charging, it could be a sign that you have a hacker in your neighborhood, and you have to change the password for the device. Or it could be the work of a remote hacker, which probably means that your Wi-Fi router needs a firmware update or a password change.

                  Smart App-Controlled Wireless Spy Vehicle

                  While some people are looking for useful IoT features, other seek entertainment and fun. After all, who didn’t dream of their own spying toolset when they were young? Well, a Smart App-Controlled Wireless Spy Vehicle would have seemed a dream come true.

                  This smart device is actually a spy camera on wheels, connected via Wi-Fi and managed via an application. The spy vehicle, sold in toy stores, has Wi-Fi as the only connection interface. For management there are two official applications, for iOS and Android. We assumed that there could be a weakness in the Wi-Fi connections – and we turned out to be right.

                  The device is able to execute the following commands:

                  • Move across the area (with multiple riding modes, it is possible to control speed and direction)
                  • View an image from the navigation camera during movement, for ease of navigation
                  • View an image from the main camera, which can also be rotated in different directions (there is even a night vision mode)
                  • Record photos and videos that are stored in the phone’s memory
                  • Play audio remotely via a built-in speaker

                  Once connected to a phone, it becomes a Wi-Fi access point without password requirements. In other words, any person connected to it can send remote commands to the vehicle – you’d just need to know which commands to send. And if you – being a bit concerned about the lack of password protection in a child’s toy that has spying capabilities – decided to set one up, you’d find there was no opportunity to do so. And if you have basic network sniffing software on your laptop, and decided you’d like to see what the vehicle was currently filming, you’d be able to intercept the traffic between the vehicle and the controlling device.

                  That said, a remote attack is not possible with this device, and an offensive third-party would have to be within the range of the toy’s Wi-Fi signal which should be enabled. But on the other hand, nothing prevents an attacker from listening to your traffic in a passive mode and catching the moment when the device is used. So if you have seen someone with a Wi-Fi antenna near your house recently, chances are they’re curious about your private life, and have the means to look into it.

                  Smart Robo Vacuum Cleaner. With camera

                  Speaking of other devices with cameras that are around you, we spent some time trying to figure out why a smart vacuum cleaner would need to have a web-cam – is it for the macro filming of dust? Or to explore the exciting under-bed world? Joking aside, this function was made specifically for the cleaning enthusiast: if you find it exciting to control the vacuum cleaner manually while checking exactly what it’s doing, this is the gadget for you. Just keep in mind that it is not quite secure.

                  The device is managed via a specific application – you can control the cleaner’s movement, get video live-streaming while it’s cleaning, take pictures, etc. The video will disappear after streaming, while photos are stored in the application.

                  There are two ways to connect to the device via Wi-Fi:

                  • With the cleaner as access point. If you don’t have a Wi-Fi network in your home, the device will provide the connection itself. You simply connect to the cleaner via the mobile application – and off you go!
                  • The cleaner can also work as a Wi-Fi adapter, connected to an existing access point. After connecting to the cleaner-as-access-point you can then connect the device to your home Wi-Fi network for better connection and operation radius.

                  As the device is managed via a mobile phone application, the user should first go through some kind of authorization. Interestingly enough, for this they only need to enter a weak default password – and that’s it. Thus, an attacker just needs to connect to cleaner’s access point, type in the default password to authorize themselves in the application for pairing the mobile phone and the cleaner. After the pairing is completed, they can control the device. Also, after connection to a local network, the robot vacuum cleaner will be visible in the local network and available via a telnet protocol to anyone who is also connected to this network. Yes, the connection is password protected, which can be changed by the owner of the device (but really, who does that?!), and no, there is no brute force protection in place.

                  Also the traffic between the app and the device is encrypted, but the key is hard-coded into the app. We are still examining the device, and the following statement should be taken with a big grain of salt, but potentially a third-party could download the app from Google Play, find the key and use it in a Man-in-the-Middle attack against the protocol.

                  And, of course, like any other Android-app controlled connected device, the robot vacuum cleaner is a subject to attack via rooting malware: upon gaining super user rights, it can access the information coming from the cleaner’s camera and its controls. During the research, we also noticed that the device itself runs on a very old version of Linux OS, which potentially makes it subject to a range of other attacks through unpatched vulnerabilities. This, however, is the subject of ongoing research.

                  Smart Camera

                  IP cameras are the devices targeted most often by IoT-hackers. History shows that, besides the obvious unauthorized surveillance, this kind of device can be used for devastating DDoS-attacks. Not surprisingly, today almost any vendor producing such cameras is in the cross-hairs of hackers.

                  In 2015, our attempt to evaluate the state of security of consumer IoT took a look at baby monitor; this year we’ve focused on a rather different kind of camera: the ones used for outside surveillance – for example the ones you’ve put up in your yard to make sure neighbors don’t steal apples from your trees.

                  Originally, the device and its relatives from the same vendor were insecure due to a lack of vendor attention to the problem. But the issue of camera protection changed dramatically around 2016 after reports of unauthorized access to cameras became publicly known through a number of publications like here or here.

                  Previously, all the cameras sold by this vendor were supplied with a factory default account and default password ‘12345’. Of course, users tended not to change the password. In 2016, the picture changed radically when the vendor became an industry pioneer in security issues, and started to supply cameras in ‘not activated’ mode. Thus, there was no access to the camera before activation. Activation required the creation of a password and some network settings. Moreover, the password was validated in terms of basic complexity requirements (length, variety of characters, numbers and special characters). Activation of the camera could be performed from any PC with access to the camera over the local network.

                  Since this reform, updating the firmware on a camera with a default password leads to the camera demanding a password change and warning the user about security issues every time they connect. The password requirements are quite solid:

                  Additionally, protection from password brute forcing has been implemented:


                  Moreover, the vendor added a new security feature to the firmware in 2016. This involves protection against brute forcing, by automatically blocking access for an IP address after five to seven attempts to enter the wrong password. The lock is automatically removed after 30 minutes. The feature, which is enabled by default, significantly increases the level of security.

                  Nevertheless, not everything is perfect in the camera. For instance, the exchange of data with the cloud is performed via HTTP, with the camera’s serial number as its ID. This obviously makes Man-in-the-Middle attacks more realistic.

                  In addition to a standard WEB interface for such devices, there is a specialized tool for camera configuration, which can search for cameras on the network, display data on the cameras, and perform basic settings including activation, password changes, and the implementation of password resets for network settings. When triggering the device search the PC sends a single Ethernet frame.

                  The camera’s response is not encrypted, and contains model information such as the firmware, date reset and network settings. Since this data is transmitted in a non-encrypted way and the request does not have authorization, this one Ethernet package can detect all cameras on the network and obtain detailed information about them. The algorithm has one more weakness: when forming a response, time delays are not considered. As a consequence, it is easy to organize a DDoS attack in the network, sending such requests to all cameras within the presented Ethernet network .

                  Apart from the described specific protocol, cameras support a standard SSDP protocol for sending notifications, and this allows any software or hardware to automatically detect the cameras. This SSDP data also contains information about the model and serial number of the camera.

                  One more attack vector lies in the remote password reset, which is supported by a technical support service. Anyone with access to the camera’s network can select a camera through the specialized tool for camera configuration and request the reset procedure. As a result, a small file containing the serial number of the camera is created. The file is sent to the technical support service, which then either refuses the request or sends a special code to enter a new password. Interestingly enough, the service doesn’t even try to check whether the user is the owner of the camera – outdoor surveillance assumes that the camera is located out of reach, and it is almost impossible to identify remotely the author of the request. In this scenario, an insider cybercriminal attack is the most probable vector.

                  To sum up: luckily this is not the worst camera we’ve ever seen when it comes to cybersecurity; however, some unnecessary issues are still there to be exploited by an offensive user.

                  Smart Bathroom Scales

                  Remember that picture from the internet, where hacked smart scales threaten to post their owner’s weight online if they don’t pay a ransom? Well, joking aside we’ve proved this may be possible!

                  This is a smart device, interacting with a smartphone app via Bluetooth, but it is also equipped with a Wi-Fi module. This connectivity provides the owner with a number of additional features, from weight monitoring on a private website secured by a password to body analysis and integration with various healthcare apps. Interestingly enough, the only Wi-Fi-enabled feature is the receiving of weather updates.

                  We decided to test the possibility of arbitrary updates\software installation on the specified device in LAN using ARP spoofing and the implementation of Man-in-the-Middle attacks. Here’s what we found.

                  The mobile phone interacts with the main server via HTTPS, in a series of queries. The scales themselves are connected to the mobile phone via Bluetooth. The process of pairing is simple: you request connection via the application, and then turn the scales’ Bluetooth connection on. Given the very limited time for this stage, it is very unlikely that someone will be able to pair the devices without the user’s knowledge.

                  Among other things, the device transmits via Bluetooth various user data – mail, indication of weight, etc. The device receives updates via the application. The latter sends the current version of updates and a number of other parameters to the server – the server, in turn, passes to the application a link to the downloaded file and its checksum.

                  However the updates are provided as is, on the HTTP channel, without encryption, and the updates themselves are also not encrypted. Thus, if you are able to listen to the network to which the device is connected you would be able to spoof the server response or the update itself.

                  This enabled us to, firstly, ‘roll back’ the version of the updates, and then install a modified version that does not match the one retrieved from the server. In this scenario, the further development of attacks is possible, like installing arbitrary software on the device.

                  The good news is that this device has no camera, so even if any other severe vulnerabilities are found, you are safe. Besides that, who would want to spend time on hacking smart scales? Well, the concern is a valid one. First of all, see the picture at the beginning of this text, and secondly: as we already mentioned above, sometimes hackers do things just because they can, because certain things are just fun to crack.

                  Smart Iron

                  Fun to crack – that is something you can definitely say about a smart iron. The very existence of such a device made us very curious. The list of things you could potentially do should a severe vulnerability be found and exploited looked promising. However, the reality turned out to be rather less amusing. Spoiler: based on our research it is impossible to set fire to the house by hacking the iron. However, there are some other rather interesting issues with this device.

                  The iron has a Bluetooth connection that enables a number of remote management options through a mobile app. We assumed that communication with the server would be insecure, allowing someone to take control of the device and its sensitive data, as manufacturers would not be paying enough attention to the protection of this channel, believing that a smart iron would be of little value to an attacker.

                  Once it is connected to the user’s mobile phone, the iron is managed via the application, which exists in versions for both iOS and Android. The app allows you to:

                  • View the orientation of the iron (whether it is lying flat, standing, or hanging by its cable)
                  • Disable (but – sadly – not enable) the iron
                  • Activate ‘safe mode’ (in which iron does not react to a mechanical switch on. To turn the iron on when it is in that mode you need to turn off safe mode in the app).

                  In terms of on/off safety the iron automatically switches off if it is stationary for five seconds in a ‘lying’ position, or for eight minutes in a ‘standing’ position.

                  The iron can also be controlled via the internet. For this, it is necessary to have a gateway near the device, like a separate smartphone or tablet with internet access and a special app.

                  Given all that, we decided to take a closer look at the applications for the device. There are three of them – one for iOS and two for Android. The first Android app is for when you manage the device via Bluetooth and are standing nearby, and the other one is for the gateway, which serves as an online door to your iron when you are not at home. The iOS app is for Bluetooth management. Speaking about the security of all applications, it is worth mentioning that the vendor’s code is not obfuscated at all.

                  When viewing online traffic, we found out that the Android Bluetooth application uses HTTPS, which is a sensible solution. The corresponding app for iOS does not and neither does the gateway app for Android. We decided to test the traffic for the iOS application.

                  Example of phishing attack via the application

                  Once it is enabled, the application offers the user the chance to register, and then sends the data without encryption via HTTP. This gives us a very simple attack vector based on the interception of traffic between the mobile application and the vendor’s server within the local network.

                  As already mentioned, the phone also communicates with the iron using BLE. The BLE traffic is also not encrypted. After deeper investigation of the applications, we were able to control the iron by creating specific commands just from looking into what is transmitted between the devices.

                  So, if you were a hacker, what could you do with all this knowledge? First of all if you would be able to capture the user’s credentials, to pass the authorization stage in an official application and to switch off the iron or set it to ‘safe mode’. It is important to note here that these applications are used for all of the vendor’s smart devices, and there are quite a few. This significantly enlarges the attack surface.

                  No need to worry if you miss the chance to intercept the authentication data. Given that the data exchange between the app and the device is not encrypted, you would be able to intercept a token transmitted from the server to the application and then create your own commands to the iron.

                  As a result, within the local network an attacker can perform:

                  • Identity theft (steal personal email address, username, password)
                  • Extortion (take advantage of the ignorance of the user to enable ‘safe mode’ so that the user could not mechanically turn on the iron, and to demand money for disabling ‘safe mode’)

                  Of course both these vectors are highly unlikely to be extensively performed in the wild, but they are still possible. Just imagine how embarrassing it would be if your private information was compromised, not as a result of an attack by a sophisticated hackers, but because of the poor security of your smart iron.

                  Smart home hub

                  The biggest problem with the vast majority of connected devices currently available is that most of them work with your smartphone as a separate, independent device, and are not integrated into a larger smart ecosystem. The problem is partly solved by so called smart hubs – nodes that unite in one place the data exchange between multiple separate smart devices. Although prior art in finding a secure smart hub, conducted by multiple other researchers, leaves little room for hope, we tried anyway and took a fancy smart hub with a touch screen and the ability to work with different IoT-protocols. It is universally compatible, works with ZigBee и ZWave home automation standards, and very easy to handle: according to the manufacturer, it can be set up within three minutes, using the touchscreen.

                  In addition the hub serves as a wireless Wi-Fi router.

                  Given all the features this multi-purpose device has, being a router, range extender, access point or wireless bridge, we decided to check one of the most common and most dangerous risks related to unauthorized external access to the router. Because, if successful, it would possibly lead to full control of a user’s smart home, including all connected devices.

                  And, no surprise, our research has shown there is such a possibility.

                  To check our assumption we created a local network, by connecting a PC, the device and one more router to each other. All network devices received their IP addresses, and we successfully scanned available ports. Our initial research has shown that, by default, there are two opened ports over WAN. The first one, port 80, is one of the most commonly used and assigned to protocol HTTP. It is the port from which a computer sends and receives web client-based communication and messages from a web server, and which is used to send and receive HTML pages or data. If opened, it means that any user can connect to port 80 and thus have access to the user’s device via the HTTP protocol.

                  The second one, port 22 for contacting SSH (Secure Shell) servers is used for remote control of the device. Attackers can gain access to a device if they obtain or successfully brute force a root password. Usually it’s not an easy task to do. However, in our research we explored another interesting risky thing with the smart hub that makes this much easier.

                  While analyzing the router, we discovered it might have problems with a very common threat risk – weak password generation. In the router system we found ELF (Executable and Linkable Format) file ‘rname’ with a list of names. By looking at this list and the password displayed on the screen, it became clear that device’s password is generated based on the names from this file and, thus, it doesn’t take long for brute force cracking.

                  After a hard reset, the source line for passwords remained, with slightly changed symbols. However, the main password base remained the same, and that still leaves a chance to generate a password.

                  In addition, we found that for device access a root account is constantly used. Thus, offensive users will know the login and a base part of the password, which will significantly facilitate a hacker attack.

                  In case the device has a public IP address and the ports described above are opened, the router can be available for external access from the internet. Or, in other case, if a provider or an ISP (Internet Service Provider) improperly configures the visibility of neighboring hosts of the local network, these devices will be available to the entire local network within the same ISP.

                  In all, we weren’t surprised; just like most any other smart hubs on the market, this one provides a really vast attack surface for an intruder. And this surface covers not only the device itself, but the network it works on. And here are the conclusions which the results of our experiment have brought us to.

                  Conclusions

                  Based on what we’ve seen while doing this exercise, the vendors of many IoT-devices developing their products assume that:

                  1. They won’t be attacked due to limited device functionality and a lack of serious consequences in the case of a successful attack.
                  2. The appropriate level of security for an IoT-device is when there is no easy way to communicate with the wider internet and the attacker needs to have access to the local network the device is connected to.

                  We have to say that these assumptions are reasonable, but only until the moment when a vulnerable router or multifunctional smart hub, like the one described above, appears in the network to which all other devices are connected. From that moment, all the other devices, no matter how severe or trivial their security issues, are exposed to interference. It is easy to imagine a house, apartment or office populated with all these devices simultaneously, and also easy to imagine what a nightmare it would be if someone tried each of described threat vectors.

                  So in answer to the question we asked ourselves at the beginning of this experiment, we can say that, based on our results at least, it is still hard to find a perfectly secure IoT-device.

                  On the other hand, no matter which device you purchase, most likely it won’t carry really severe security issues, but again, only until you connect them to a vulnerable router or smart hub.

                  Keeping that and the ongoing high sales holiday season in mind we’d like to share the following advice on how to choose IoT devices:

                  1. When choosing what part of your life you’re going to make a little bit smarter, consider the security risks. Think twice if you really need a camera-equipped robo vacuum cleaner or a smart iron, which can potentially spill some of your personal data to an unknown third-party.
                  2. Before buying an IoT device, search the internet for news of any vulnerability. The Internet of Things is a very hot topic now, and a lot of researchers are doing a great job of finding security issues in products of this kind: from baby monitors to app controlled rifles. It is likely that the device you are going to purchase has already been examined by security researchers and it is possible to find out whether the issues found in the device have been patched.
                  3. It is not always a great idea to buy the most recent products released on the market. Along with the standard bugs you get in new products, recently-launched devices might contain security issues that haven’t yet been discovered by security researchers. The best choice is to buy products that have already experienced several software updates.
                  4. To overcome challenges of smart devices’ cybersecurity, Kaspersky Lab has released a beta version of its solution for the ‘smart’ home and the Internet of Things – the Kaspersky IoT Scanner. This free application for the Android platform scans the home Wi-Fi network, informing the user about devices connected to it and their level of security.

                  When it comes to the vendors of IoT-devices, the advice is simple: collaborate with the security vendors and community when developing new devices and improving old ones.

                  P.S. 1 out of 8

                  There was one random device in our research, which showed strong enough security for us at least not to be worried about private data leakage or any other devastating consequences. It was a smart watch. Like most other similar devices, these watches require an app to pair them with the smartphone and use. From that moment, most of data exchange between the device and the smartphone, the app and the vendors’ cloud service are reliably encrypted and, without a really deep dive into encryption protocol features or the vendor’s cloud services it is really hard to do anything malicious with the device.

                  For the pairing the owner should use the pin code displayed on the clock for successful authorization. The pin is randomly generated and is not transmitted from the clock. After entering the pin code in the app, the phone and clock create the key for encryption, and all subsequent communication is encrypted. Thus, in the case of BLE traffic interception an attacker will have to decrypt it as well. For this, an attacker will need to intercept traffic at the stage of generating the encryption key.

                  It is apparently impossible to get user data (steps, heart rate etc.) directly from the device. Data synchronization from the clock on the phone is encrypted and, in the same form is sent to the server. Thus, data on the phone is not decrypted, so the encryption algorithm and the key are unknown.

                  From our perspective this is an example of a really responsible approach to the product, because, by default the vendor of this device could also easily limit their security efforts to assuming that no one will try to hack their watches, as, even if successful, nothing serious happens. This is probably true: it is hard to imagine a hacker who would pursue an opportunity to steal information about how many steps you made or how fast your heart beats at any given moment of the day. Nevertheless, the vendor did their best to eliminate even that small possibility. And this is good, because cybersecurity is not all those boring and costly procedures which you have to implement because some hackers found some errors in your products, we think cybersecurity is an important and valuable feature of an IoT-product, just like its usability, design and list of useful functions. We are sure that as soon as IoT-vendors understand this fact clearly, the whole connected ecosystem will become much more secure than it is now.

                  This Holiday Season – Buy One IoT Device, Get Free CVEs

                  As the Internet of Things gains steam and continues to develop, so are adversaries and the threats affecting these systems. Companies throughout the world are busy deploying low cost Internet-connected computing devices (aka the Internet of Things) to solve business problems and improve our lives. In tandem, criminals are developing their methods for abusing and compromising vulnerable and poorly defended IoT devices.

                  In the past year, we have seen criminals recruit vulnerable IoT devices to form the Mirai botnet, capable of launching the largest denial of service attack in history, and more recently witnessed the emergence of further IoT botnets, which consist of many thousands of infected devices performing the bidding of a criminal owner. These networks of devices can be instructed to simultaneously bombard websites with network traffic bringing down systems under the strain of the coordinated denial of service attack.

                  Talos researches and monitors the threat environment in order to protect Cisco customers against emerging threats. We strive to make the wider community aware of the issues of poorly secured IoT devices, and actively hunt for vulnerabilities. In recent weeks, Talos has published reports on vulnerabilities which we have resolved in home security cameras, a Disney branded home IoT device designed to increase security, and in software designed to run on embedded systems, such as those used in IoT systems.

                  Many of these vulnerabilities allow attackers to execute unauthorised computer code on devices, permitting attackers to read data, launch attacks at other systems, or render the compromised device inoperable. Not only may an unsecure device leak information that should never be released, but an unprotected vulnerable device is at the mercy of attackers.

                  As with all vulnerabilities discovered by Talos, we follow our published responsible disclosure policy to ensure that vendors have the time to release patches to fix the vulnerabilities. We understand that in the field applying patches to a vulnerable system is not always easy, or even possible. This is why when we disclose the presence of a vulnerability, we release open-source Snort signatures to detect and block attempted exploitation of the vulnerability.

                  Protecting potentially vulnerable IoT devices with Intrusion Prevention System (IPS) network security defenses forms only part of the full suite of IoT protection available from Cisco. Cisco also offers cybersecurity and Internet of Things training courses through the Cisco Networking Academy. The goal of these programs is to increase skill levels among current workers, and enable new employees to enter the workforce with the knowledge necessary to succeed.

                  Securing the Internet of Things begins with an awareness of the problem. Awareness of the issues and the risks, as well as the solutions to the problem, are vital first steps to resolving the issue. We are committed in our research to identify the vulnerabilities and the techniques that may be used by criminals to subvert the Internet of Things, and committed to ensuring that everyone can reap the benefits that this new frontier offers.

                  Back That App Up: Gaining Root on the Lenovo Vibe

                  In May of 2016, Mandiant’s Red Team discovered a series of vulnerabilities present on Lenovo’s Vibe P1 Android-based mobile device that allow local privilege escalation to the user “root”. Mandiant disclosed these vulnerabilities to Lenovo in May of 2016. Lenovo advised Mandiant that it should work with Motorola, who it had acquired and was now responsible for Lenovo’s mobile product portfolio. Mandiant then disclosed the vulnerabilities to Motorola for correction. The vulnerabilities discovered by Mandiant’s Red Team were as follows:

                  • Local backups enabled in Lenovo “Security” application (CVE-2017-3750)
                  • Local backups enabled in Lenovo “Idea Friend” application (CVE-2017-3749)
                  • Improper access controls in “nac_server” binary (CVE-2017-3748)

                  The official Lenovo advisory that includes the affected devices and software versions can be found on Motorola’s website. Motorola has indicated that these vulnerabilities have since been patched, and the company supported Mandiant regarding the release of this post.

                  We have provided general details in an FAQ, and a technical analysis of the vulnerabilities follows.

                  FAQ

                  What devices are affected and (potentially) how many devices are affected?

                  The vulnerabilities described in this post affect a subset of Lenovo-branded devices. A full list of the affected devices can be found within Motorola’s official advisory. Note that the vulnerabilities described in this post do not affect the Android Open Source Project (“AOSP”) developed by Google.

                  How is the issue being addressed?

                  Motorola has redesigned the affected mechanism to use a more secure process.

                  How would an attacker exploit these vulnerabilities?

                  The described exploit chain requires local, physical access to a device. Therefore, is very unlikely to see this exploit “in the wild”. Users are recommended to update their devices to the most recent software package provided by Lenovo, and protect their devices using strong lock screen settings.

                  Who discovered these vulnerabilities?

                  Jake Valletta (@jake_valletta)

                  Technical Analysis

                  Now we will walk through the exploitation process Mandiant’s Red Team used to obtain code execution as the user “root” by chaining the disclosed vulnerabilities together in a unique way.

                  Identifying Our Target: “nac_server”

                  A popular process for escalating privileges on Android devices is to enumerate locally listening sockets. While AF_INET sockets (think IP addresses and TCP/UDP ports) listening locally are rare on Android devices, AF_UNIX sockets (hereforth refered to as “UNIX sockets”) are used frequently by native Android daemons, including “netd”, “installd”, and “vold”, most of which run with elevated privileges. UNIX sockets are represented as files on the filesystem, and are typically bound to socket-type files in the “/dev/socket/” directory. A specific subset of UNIX sockets bind to the abstract namespace (which are not bound to a filesystem-backed file), and are denoted with a leading ‘@’ character, such as “@android:debuggerd32” and “@jdwp-control”.

                  Using the “netstat” module of the “busybox” utility on a test Vibe, we can note interesting abstract sockets that do not appear to be part of the Android Open Source Project (“AOSP”), as highlighted in Figure 1. Note that we’ll be using the Android Debug Bridge (“adb”) to interface with a test Lenovo Vibe throughout the post.


                  Figure 1: Abstract sockets on test Lenovo Vibe device

                  To find the binary that may be responsible for these UNIX sockets, a string search across all DEX bytecode and binaries on the device can be useful. A string search across system binaries (located on the device in the directories “/system/bin/”, “/vendor/bin/”, and “/system/xbin/”) indicated that the strings “nac_server”, “nac_safe_server”, and “supercmdlocalsocket” were all present in the binary file “/system/bin/nac_server”, a non-AOSP binary.

                  To confirm this, we can extract and view the “/init.rc” file present on the Vibe. In this file, we can see that Lenovo added an init service called “nac_server”, shown in Figure 2.


                  Figure 2: “nac_server” service defined in “/init.rc” file

                  The “init” process registers the “nac_server” service and runs as the user “root” at system boot. We can confirm this by checking the “init.svc.nac_server” system property and by viewing the running processes on a test device, shown in Figure 3 and Figure 4 respectively. It is also important to note that the “nac_server” binary was running under the SE for Android (“SEAndroid”) context “nac_server”.


                  Figure 3: Checking “init.svc.nac_server” system property


                  Figure 4: “nac_server” process running as “root” user and “nac_server” SEAndroid context

                  Since we know this process runs as a privileged process and listens on UNIX sockets, we shifted our analysis to the “nac_server” binary to understand its full capabilities.

                  Binary Analysis of the “nac_server”

                  To map out the capabilities of the “nac_server” binary, Mandiant’s Red Team worked along side FireEye Labs Advanced Reverse Engineers (“FLARE”) (shoutout to @m_r_tz). As stated above, the “init” process starts “/system/bin/nac_server” at system boot as the user “root”. Once started, “nac_server” spawns three threads, each bound to an abstract UNIX socket: “nac_server”, “nac_safe_server”, and “supercmdlocalsocket”. Each of these threads expects to receive a file path from a client across the socket. “nac_server” then performs the following security checks based on the file path:

                  • Tokenizes the file path based on “/”, and assumes the third element is the calling package name, and the fourth argument the file to execute. The package name is then checked against a whitelist, shown in Figure 5.


                  Figure 5: Whitelisted Lenovo-branded applications in “nac_server”

                  • Parses the “/data/system/packages.xml” file to check if the calling package name is installed and the signature matches a list of internal signatures. One of the allowed signatures is depicted in Figure 6.


                  Figure 6: Hardcoded package signature in “nac_server”

                  After validating the file path, “nac_server” copies the file from the fourth argument to the directory “/data/local/root_channel/[package_name]”, sets the SEAndroid context to “root_channel”, and then executes the file using the “system(..)” function as the user “root”. We’ll be exploring the significance and capabilities of the “root_channel” SEAndroid context in the following section.

                  In short, the “nac_server” binary provides a mechanism for applications signed by Lenovo to execute files as a privileged process and context. There are obvious malicious reasons to include this functionality; however, Mandiant’s research suggests that Lenovo used this functionality to create custom “iptables” firewall rules from the Android runtime.

                  Because the “nac_server” falsely assumes the caller is the third token of the file path, we are able to confuse the service and feed it a file that we control (CVE-2017-3748).

                  Understanding SEAndroid Contexts

                  SEAndroid is a security feature added to Android devices starting in Android 4.3 (“Jelly Bean”). One of the key reasons for adopting SEAndroid was to provide granular security control of powerful UIDs such as those associated with “system”, “radio”, and “root”. Note that this section will not be a complete tutorial on SEAndroid (a more comprehensive description of SEAndroid can be found here). The SEAndroid-related files for our analysis are as follows:

                  • /sepolicy – Binary kernel policy file loaded at system boot
                  • /seapp_contexts – Rules for determining the SEAndroid domain and type of Android applications
                  • /etc/security/mac_permissions.xml – x.509 certificate information to determine the correct domain to apply when the Zygote process spawns a new application (more information on the Zygote process can be found here)
                  “nac_server” UNIX Socket Analysis

                  Unfortunately for us, attempting to connect to any of the three aforementioned UNIX sockets as the built-in “shell” user results in SEAndroid policy violation. Figure 7 shows a “Permission denied” error when we attempted to connect to the UNIX socket “supercmdlocalsocket” using the “socat” utility.


                  Figure 7: Attempting to connect to “supercmdlocalsocket” abstract socket using “socat”

                  Figure 8 shows the SEAndroid policy violation captured in the Android log buffers.


                  Figure 8: Policy violation included in Android log buffers

                  In Figure 8, we see that the operating system denied the source context “shell”, the “connectto” permission of the “unix_stream_socket” class for the “nac_server” type. As a researcher, we now want to know: who can access this permission? To answer this, we can use the “sesearch” utility as follows:


                  Figure 9: Performing lookup for “connectto” permission using “sesearch”

                  Running this tool indicates that three SEAndroid domains possess the correct permission: “system_app”, “platform_app”, and “unconfineddomain”. Fortunately, there are over 100 applications running in either the “platform_app” or “system_app” security domain. Based on this, our next goal is to achieve code execution in either the “system_app” or the “platform_app” domains so that we can connect to the “nac_server” UNIX sockets.

                  “root_channel” Analysis

                  It is also worth exploring the capabilities of the “root_channel” SEAndroid context that the “nac_server” binary applies just prior to executing the command. On the Lenovo Vibe, the “root_channel” context is quite powerful, and includes full access to application data and Android runtime and write access to the “/data/” filesystem. What this context lacks is the ability to mount or remount filesystems and disable SEAndroid (we will leave this as an exercise for the reader).

                  Triggering the “nac_server” Bug via Local Backups

                  Android introduced local backups in Android 2.2 (“Froyo”). Local backups allow a user with physical access to a device with USB debugging enabled to download application data for specific applications and restore this data back to the device. Determination of whether an application can be backed up is controlled by the “android:backupAllowed” attribute within an application’s “AndroidManifest.xml” file. By default, this value is set to “true” for all applications except applications running as the shared UID “android.uid.system”.

                  To create a backup of an application locally, we can use the “adb” command “backup” shown in Figure 10.


                  Figure 10: Creating a local backup for the “com.some.app” application using “adb”

                  These local backups can then be unpacked using the open-source Android Backup Extractor (“abe”) and the “tar” utility. Since these backups are not signed, we are free to make changes to the backup, such as edit configuration files or even add new files entirely. To repackage the backup, we can reverse the steps and use “tar” (or the “pax” utility), “abe”, and finally the “adb” command “restore” to restore the backup on our device. Figure 11 shows the command to restore a backup.


                  Figure 11: Restoring new local backup using “adb”

                  Abusing Backups Part 1: Code Execution (CVE-2017-3749)

                  One particularly dangerous side effect of allowing local backups is that a malicious user can modify an application’s private files without the application knowing. This typically includes modifying configuration files to alter the behavior of the application (like changing your Angry Bird high score data), but in more rare cases, an attacker can modify supplemental DEX bytecode included as part of an application to take full control of an application. Note that an application’s primary DEX bytecode is processed upon installation and stored outside of the application’s data directory, so it is not a target.

                  This is the case for the Idea Friend application (“com.lenovo.ideafriend”), which is the Lenovo-branded contact manager application. This application did not run as a privileged UID, but it did run in the “platform_app” SEAndroid domain, shown in Figure 12.


                  Figure 12: “com.lenovo.ideafriend” application running in “platform_app” security context

                  Identifying and Modifying Supplemental Bytecode

                  If we create a local backup for the Idea Friend application using the aforementioned process, we will notice the directory “f/parse/” (which corresponds to “/data/data/com.lenovo.ideafriend/files/parse/” on a test device) contains 14 signed Java JAR archives, each containing DEX bytecode, as shown in Figure 13.


                  Figure 13: JAR archives included in “f/parse/” directory of Idea Friend backup

                  The DEX code included in the JAR files “ParseUtilBubble_8.jar” and “parseUtilMain_8.jar” is loaded dynamically by the Idea Friend application when launched, which means that if we can modify these JAR files, we can execute arbitrary code as the Idea Friend application. These JAR files are signed, which does not permit us to modify the contents of the archives; however, because our test device utilizes the Android Runtime (“ART”), the operating system automatically optimizes DEX bytecode using “dex2oat” to produce an unsigned ELF binary. To confirm this behavior, we can see two OAT files in the directory “r/app_outdex” (which corresponds to “/data/data/com.lenovo.ideafriend/app_outdex/” on a test device). Figure 14 shows the OAT binaries optimized from the JAR files “ParseUtilBubble_8.jar” and “parseUtilMain_8.jar” found in the directory “r/app_outdex/”, and Figure 15 confirms that these are ELF binaries (the file format used by ART).


                  Figure 14: Optimized OAT binaries in Idea Friend backup


                  Figure 15: Determining file type of ART binaries

                  Using techniques described in the Black Hat Asia 2014 white paper “Hiding Behind ART”, it is possible to create our own OAT ELF binaries given the original DEX bytecode. The process is summarized as follows:

                  1. Disassemble the existing DEX bytecode. For this, we can use “baksmali”.
                  2. Modify the disassembled DEX bytecode. In our case, we are going to add a LocalSocket client to connect to the UNIX socket “supercmdlocalsocket” within a method we know will be called by the Idea Friend application (keep reading for more on this).
                  3. Reassemble the new DEX. We can use “smali” for this.
                  4. Push the new DEX bytecode to our device with a filename that matches the exact length of the destination filename. For example, if our destination filename is “/data/data/com.lenovo.ideafriend/app_outdex/parseUtilMain_8.dex”, we need to push a file with the exact filename size of 63, or “/data/local/tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.jar”. This is important for a later step.
                  5. Manually invoke the “dex2oat” utility on our test device against the DEX bytecode to generate an optimized OAT file.
                  6. Pull the new OAT binary from the test device.
                  7. Replace the padded filename (which corresponds to the “dex_file_location_data” field) in the OAT DEX file header with the original file path. Note that because we padded it to the proper length, this will not affect any offsets in the binary. A text editor such as vim or 010 works here.
                  8. Reset the “dex_file_location_checksum” CRC32 checksum in the DEX header to be that of the original OAT binary. For this, we can use “dexdump” to obtain the checksum, and “dd” to replace it.

                  We will use this process in conjunction with a local backup for the Idea Friend application to connect to one of the UNIX sockets exposed by the “nac_server” binary. First, we will need to modify one of the JAR files and insert our malicious code.

                  Creating the Socket Client

                  Our first step is to generate the bytecode to connect to one of the “nac_server”’s abstract UNIX socket. For this example, we have chosen to use the “supercmdlocalsocket” UNIX socket. We start by creating a Java class similar to Figure 16.


                  Figure 16: “run()” method written in Java to connect to “supercmdlocalsocket” abstract UNIX socket

                  We can then compile this class, convert the class to DEX bytecode, and then disassemble using “smali”. Next, we find an opportune location to place this function.

                  Inserting the Hook

                  By performing static and dynamic analysis on the Idea Friend application, we determined that the Idea Friend application executed the method “getBubbleViewVersion(..)” of the class “cn.com.xy.sms.sdk.Iservice.ParseUtilBubble” contained in the JAR “parseUtilBubble_8.jar” when the application was launched. Knowing this, we add our malicious code to this class, and insert our hook in the “getBubbleViewVersion(..)” method, as shown in Figure 17 and Figure 18.


                  Figure 17: Hook in “getBubbleViewVersion(..)” to call malicious code


                  Figure 18: “run()” method written in disassembled Dalvik to connect to “supercmdlocalsocket”

                  We can then perform steps 3-8 in the previously described process to generate our new ELF and restore our modified backup. All that remains now is to stage our malicious payload to be executed by the “nac_server” binary.

                  Abusing Backups Part 2: Staging a Payload (CVE-2017-3750)

                  We know that the Idea Friend application can communicate with the “nac_server” UNIX sockets, but unfortunately, the Idea Friend application is not in the whitelist checked by the “nac_server” binary. This means we will need to find a second application to stage our payload. By comparing the list of applications in the whitelist of “nac_server” (Figure 5) against applications that allow local backups, we can determine a few potential targets. We will use the Lenovo Security application (“com.lenovo.security”) as our target.

                  We will first follow the process outlined in the section “Abusing Backups Part 1: Code Execution” to generate a local backup for the Lenovo Security application. We then modify the backup to include the “go.sh” shell script depicted in Figure 19. The “go.sh” script will simply start a telnet server on TCP port 1234 when executed.


                  Figure 19: Contents of “go.sh”

                  After re-packaging and restoring the backup, we can confirm that the file has been pushed to the device successfully using “ls”:


                  Figure 20: Successfully pushed “go.sh” to Lenovo Security application

                  Chaining the Vulnerabilities

                  With our chain of vulnerabilities mapped out, we can now trigger the exploit with the following steps:

                  1. Launch the Settings application and clear the application data for the Idea Friend application. This removes any legitimate OAT binaries that may already exist.
                  2. Create a local backup of the Lenovo Security application.
                  3. Modify the local backup to contain the “go.sh” payload.
                  4. Restore the modified backup to the device.
                  5. Create a local backup of the Idea Friend application.
                  6. Modify the local backup to include our malicious OAT binary.
                  7. Restore the modified backup to the device.
                  8. Launch the Idea Friend application. Since the OAT binaries already exist (and appear valid), the application will execute our code. This will cause the Idea Friend application to connect to the UNIX sockets exposed by “nac_server” and pass the file path of our staged payload, “go.sh”. The “nac_server” will then execute our payload, starting the telnetd server.
                  9. Connect to the device using a telnet connection.

                  Figure 21 depicts this process, and shows the output of the command “id”, indicating that we have code execution as the user “root”, with SEAndroid context of “root_channel”.


                  Figure 21: Running as UID “root” and “root_channel” SEAndroid context

                  Conclusions

                  Platform developers should exercise caution when exposing sensitive functionality using abstract UNIX sockets. Instead, use file-based UNIX sockets with the proper filesystem permissions and SEAndroid policy in conjunction with a privileged Android System Services to create a more structured and secure model. Based on follow up analysis, this is the model that Motorola has decided to use.

                  In addition, allowing backups on privileged applications can also be detrimental and should be disallowed. Just because an application is not running as a privileged Android user ID such as “android.uid.system”, does not mean that it cannot introduce vulnerabilities and be used to escalate privileges. Finally, applications should never allow executable code (Java classes, ELF binaries, or shared objects) within backups. This can be limited using a BackupAgent.

                  Overload: Critical Lessons from 15 Years of ICS Vulnerabilities

                  In the past several years, a flood of vulnerabilities has hit industrial control systems (ICS) – the technological backbone of electric grids, water supplies, and production lines. These vulnerabilities affect the reliable operation of sensors, programmable controllers, software and networking equipment used to automate and monitor the physical processes that keep our modern world running.

                  FireEye iSIGHT Intelligence has identified nearly 1,600 publicly disclosed ICS vulnerabilities since 2000. We go more in depth on these issues in our latest report, Overload: Critical Lessons from 15 Years of ICS Vulnerabilities, which highlights trends in total ICS vulnerability disclosures, patch availability, vulnerable device type and vulnerabilities exploited in the wild.

                  FireEye’s acquisition of iSIGHT provided tremendous visibility into the depth and breadth of vulnerabilities in the ICS landscape and how threat actors try to exploit them. To make matters worse, many of these vulnerabilities are left unpatched and some are simply unpatchable due to outdated technology, thus increasing the attack surface for potential adversaries. In fact, nation-state cyber threat actors have exploited five of these vulnerabilities in attacks since 2009.

                  Unfortunately, security personnel from manufacturing, energy, water and other industries are often unaware of their own control system assets, not to mention the vulnerabilities that affect them. As a result, organizations operating these systems are missing the warnings and leaving their industrial environments exposed to potential threats.

                  Click here to download the report and learn more.