Mirai-Based Masuta Botnet Weaponizes Old Router Vulnerability

A new Internet of Things-targeting piece of malware based on Mirai’s publicly released source code has been observed at large, ensnaring devices into a botnet.

Dubbed Masuta, the botnet has at least two variants at large, and is believed to be the work of a well-known IoT threat actor, NewSky Security says. What’s also unique to the botnet is that it exploits an old router vulnerability, being the first threat known to weaponize it in a botnet campaign.

Masuta (Japanese for “master”) botnet’s source code was found on an invite only dark forum. The malware’s configuration file, the researchers discovered, uses a different seed of the cipher key compared to Mirai, having the strings in the configuration files XORed by 0x45.

Thus, the researchers discovered that it uses the domain nexusiotsolutions(dot)net, the command and control (C&C) server that Nexus Zeta, the individual involved in the recent Satori attacks, uses. The domain was registered using the [email protected](.)com email address.

Thus, NewSky Security suggests that Nexus Zeta has been involved in the creation of the Masuta botnet, in addition to building Satori, the Mirai variant that has been wreaking havoc over the past couple of months.

In fact, Masuta isn’t new either, and attacks involving it have been steadily increasing since September, and the botnet’s standard variant has been observed using several known/weak/default credentials to compromise IoT devices.

An evolved variant of Masuta, called PureMasuta, contains the most typical of Mirai style code, and a list of weak credentials to use. What makes this malware variant stand out, however, is its usage of EDB 38722 D-Link exploit.

The exploit PureMasuta uses resides in the HNAP (Home Network Administration Protocol), which is based on the SOAP protocol. It is possible to craft a SOAP query to bypass authentication by using hxxp://purenetworks.com/HNAP1/GetDeviceSettings, and improper string handling can lead to arbitrary code execution, and an attacker can abuse this combination of issues to run code on targeted devices.

What the botnet does is to download a shell script from the C&C server and run it. Thus, the malware author first bypasses authentication and then executes code on the targeted devices.

The PureMasuta variant uses the same C&C server (93.174.93.63) as the original Masuta variant, which led the researchers to believe it is the evolved creation of the same threat actor.

“Nexus Zeta is no stranger when it comes to implementing SOAP related exploits. The threat actor has already been observed in implementing two other known SOAP related exploits, CVE-2014–8361 and CVE-2017–17215 in his Satori botnet project,” NewSky Security notes.

Thus, the TR-069 bug and EDB 38722 are the third and fourth SOAP related exploits abused by IoT botnets.

“Protocol exploits are more desirable for threat actors as they usually have a wider scope. A protocol can be implemented by various vendors/models and a bug in the protocol itself can get carried on to a wider range of devices,” the researchers conclude.

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/MifPVicn-jE/mirai-based-masuta-botnet-weaponizes-old-router-vulnerability

Security and DevOps – What We Learned at DOES17

The adoption of DevOps has implications for security teams, regardless of whether the name evolves to become “DevSecOps” or some other inclusive term. Digital transformation in the business – using software services to compete – requires faster code releases, which DevOps can deliver. Security can be a bottleneck to release velocity, but leading organizations are learning how to blend DevOps and security practices. Some are sharing their experiences for us to learn from.

At the end of 2016, I wrote an article titled “What Security Teams Need to Know about DevOps,” where I shared that “DevOps is already in use among 19% of IT organizations, with another 19% in a pilot phase. Another 35% intend to implement DevOps in 2017.” These were statistics shared during a major analyst’s data center conference in December 2016.

I attended the same conference in December 2017 and the current survey indicates that 41% of enterprise organizations are using DevOps, while 40% say their organizations are piloting or planning to implement DevOps in 2018. So the numbers were a little optimistic for 2017, but we still should expect that the majority of enterprises will be using some form of DevOps by the end of this year.

DevOps Consider the following security advice delivered during the last DevOps Enterprise Summit (DOES17), November 13-15 in San Francisco.

Security needs to shift from being a gatekeeper to enabling security by default

The way we’ve traditionally approached security doesn’t scale in a DevOps world according to Zane Lackey, Co-Founder and Chief Security Officer for Signal Sciences, shared during his session (Video), How to use DevOps to make you more secure.

His core point is that internal security can’t see itself as a sort of third party to the organization, interjecting security policies and controls as they see fit. Rather, security needs to provide resources to help DevOps teams become “security self-sufficient,” baking security into the DevOps pipeline. His prescription is to bring security-relevant data up to become a peer to operationally-relevant data so that performance problems related to security incidents become more obvious. (The slides for this session are also available in PDF format for download on Dropbox.)

Bake security into your pipeline

How do you build a secure development pipeline that avoids the release of code with vulnerabilities? That’s the question that Shozab Naqvi of Electric Cloud asked in his session, Baking Security into your Pipeline (video).

Code vulnerability testing is frequently bolted on at the end of a software delivery lifecycle, which is often a day or two prior to a release date. This puts tremendous pressure to release the code anyway with a known vulnerability and plan to patch it later. Except that the patch sometimes doesn’t come in time to prevent the data breach. His prescription is to shift security left, meaning, include security experts in scrum teams during the coding build, test and release stages – not just during release. Watch the video for details on how to protect each of these stages.

If it ain’t broke, try harder

Aaron Rinehart, Chief Security Architect of United Health Group, indicated he was tired of being in the way of developers. His session, DevOps and the Healthcare Giant (video), describes his journey towards using chaos engineering as it relates to the field of information security.

While security has traditionally focused on preventative controls, there has been less emphasis on planning for the unknown. Chaos engineering is the discipline of experimenting on a system in order to build confidence in the system’s ability to withstand turbulent conditions. Rather than rely on security incidents as a detective measure,

Aaron is assessing his detective controls by adding misconfigurations and checking to see if they are detected.

Other specific advice includes:

– Be mean to your code

– Automation is important, but don’t be distracted by it – emphasize simplification and standardization

– Embrace failure as a friend – plan and expect failure and learn from it quickly

(Slides for this presentation in PDF format can be downloaded from Dropbox.)

As DevOps and agile development methodologies take greater root in the enterprise, the traditional tools and approaches for eliminating vulnerabilities in code will no longer be able to keep pace. If your organization is adopting DevOps, then your security practices need to evolve along with the development and operations teams to support the business objectives that are driving this digital transformation.

Travis Greene, Identity Solutions Strategist at Micro Focus, possesses a blend of IT operations and security experience, process design, organizational leadership and technical skills. After a 10-year career as a US Naval Officer, he started in IT as a Data Center Manager for a hosting company. In early 2002, Travis joined a Managed Service Provider as the leader of the service level and continuous improvement team. Today, Travis conducts research with NetIQ customers, industry analysts, and partners to understand current Identity and Access Management challenges, with a focus on provisioning, governance and user activity monitoring solutions. Travis is Expert Certified in ITIL and holds a BS in Computer Science from the US Naval Academy.

Previous Columns by Travis Greene:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/jY86ZMMEGP0/security-and-devops-what-we-learned-does17

Intel Halts Spectre, Meltdown CPU Patches Over Unstable Code

Intel on Monday said that users should stop deploying patches for the “Spectre” and “Meltdown” chip vulnerabilities disclosed by researchers earlier this month, saying the patches could cause problems in affected devices, including higher than expected reboots and other “unpredictable” system behavior.

The US chip giant recommended that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions of the patches.

“We have now identified the root cause of the reboot issue impacting Broadwell and Haswell platforms, and made good progress in developing a solution to address it,” Navin Shenoy, Intel data center group executive vice president, wrote in security update.

“We ask that our industry partners focus efforts on testing early versions of the updated solution so we can accelerate its release,” Shenoy added.

Last Wednesday, Intel shared information on the performance impact of the inital Meltdown and Spectre patches on data centers, and the company did warn customers that systems with several types of processors may experience more frequent reboots after firmware updates are installed.

Shenoy said that Intel expects to share more details on the timing of new patches later this week.

As technology firms rush out fixes to address the security risks, many of the updates have turned out to be unstable.

Red Hat has also decided to pull microcode patches for one variant of the Spectre exploit after users complained that updates had caused their systems to stop booting.

The updates initially released by Microsoft caused some systems using AMD processors to stop booting. Some systems running Ubuntu also failed to boot after Canonical’s first round of updates was installed.

Several industrial control systems (ICS) vendors have advised customers not to apply them before conducting thorough tests.

VMware also decided to delay new releases of microcode updates until Intel addresses these problems.

For more than 10 years, Mike Lennon has been closely monitoring the threat landscape and analyzing trends in the National Security and enterprise cybersecurity space. In his role at SecurityWeek, he oversees the editorial direction of the publication and is the Director of several leading security industry conferences around the world.

Previous Columns by Mike Lennon:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/QhgOf-lLZc8/intel-halts-spectre-meltdown-cpu-patches-over-unstable-code

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.

The expert analyzed approximately half of them and determined that 10-20% were misconfigured. He spent weeks manually validating the issues he discovered and notifying affected vendors.

Jenkins is an open source automation server used by software developers for continuous integration and delivery. Since the product is typically linked to a code repository such as GitHub and a cloud environment such as AWS or Azure, failure to configure the application correctly can pose a serious security risk.

Some of the misconfigured systems discovered by Tunç provided guest or administrator permissions by default, while others allowed guest or admin access to anyone who registered an account. Some Jenkins servers used a SAML/OAuth authentication system linked to Github or Bitbucket, but they allowed any GitHub or Bitbucket account to log in rather than just accounts owned by the organization.

Tunc said a vast majority of the misconfigured Jenkins servers leaked some type of sensitive information, including credentials for private source code repositories, credentials for deployment environments (e.g. usernames, passwords, private keys and AWS tokens), and job log files that included credentials and other sensitive data.

One of the exposed Jenkins instances, which leaked sensitive tokens, belonged to Google, but the tech giant quickly addressed the issue after being informed via its bug bounty program.

The researcher also named several major UK-based companies, including Transport for London, supermarkets Sainsbury’s and Tesco, credit checking company ClearScore, educational publisher Pearson, and newspaper publisher News UK. Some of these companies allegedly exposed highly sensitive data, but Tunç said he often had difficulties in responsibly disclosing his findings.

“I want to make it absolutely clear that I did not exploit any vulnerabilities to gain access to Jenkins servers – I simply walked through the front door which was visible to the world, then told the owners to close said front door,” the researcher noted in a blog post.

While Tunç received products, vouchers and thanks for his work from the companies he alerted, misconfigured Jenkins instances can be highly problematic and some vendors have paid significant bug bounties for such security holes.

A few months ago, two researchers reported earning a total of $20,000 from Snapchat after finding exposed Jenkins instances that allowed arbitrary code execution and access to sensitive data.

Eduard Kovacs is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/P7wDqtxAWPQ/misconfigured-jenkins-servers-leak-sensitive-data

Firms More Open to Receiving Vulnerability Reports: Ethical Hackers

Companies have become more open in the past year to receiving vulnerability reports from security researchers, according to ethical hackers surveyed by bug bounty platform HackerOne.

According to HackerOne’s 2018 Hacker Report, which surveyed nearly 2,000 white hat hackers across 100 countries, companies are somewhat more open (38%) or far more open (34%) to receiving vulnerability reports. Only less than 10% of respondents said firms are less open.

On the other hand, nearly a quarter of respondents said they had not reported vulnerabilities due to the fact that the affected software’s developer had not provided a channel for responsible disclosure.

When it comes to motivation, money is not the most important – as it was in the previous year. There are more researchers hacking to learn new techniques (14.7%), for fun (14%), and for the challenge (14%) than ones who do it for the money (13.1%). Nearly one-quarter of respondents said they donated money earned from bug bounties to charities.

A majority of HackerOne users named websites as their favorite target (70%), followed by APIs (7.5%), Android apps (4.2%), operating systems (3.1%), and IoT systems (2.6%).

How white hats choose who to hack

Burp Suite is the favorite tool of nearly one-third of hackers, but more than 15% claim they use their own tools to find vulnerabilities. Other popular tools include web proxies and scanners, network scanners, fuzzers, and debuggers.

A vast majority of the white hats who have signed up on the HackerOne platform, which hosts the bug bounty programs of more than 1,000 organizations, are under the age of 35, and many of them learned how to hack on their own. Most of them either work in IT (software or hardware), consulting, or they are students.

Roughly 66% spend less than 20 hours per week hacking, and only 13% spend 40 hours or more. More than 71% have less than 5 years experience, and only 10% have been hacking for more than 10 years.

Over $23 million have been paid out through HackerOne, with more than $4 million paid to researchers in the U.S., $3 million to India, and $1.3 million each to Australia and Russia. The largest chunk came from companies in the United States ($16 million) and Canada ($1.2 million).

In some places, bug bounty hunters earn far more than they would as a software engineer in their country. For example, in India and Argentina they earn roughly 16 times more than the median annual wage of a software engineer, while in Hong Kong and Egypt they earn 8 times more.

A quarter of respondents said bug bounties represent at least half of their annual income and 14% said they represent 90-100% of their income. Three percent reported making more than $100,000 per year from bug bounty programs, and 1% make more than $350,000.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/kygMaihSFUA/firms-more-open-receiving-vulnerability-reports-ethical-hackers

AMD, Apple Sued Over CPU Vulnerabilities

Apple and Advanced Micro Devices (AMD) are also facing class action lawsuits following the disclosure of critical CPU vulnerabilities that affect billions of devices.

The Meltdown and Spectre attack methods, which rely on vulnerabilities that have been around for roughly two decades, allow malicious applications to bypass memory isolation mechanisms and access passwords, photos, documents, emails, and other sensitive data. Attacks can be launched against systems using processors from Intel, AMD, ARM, and others.

Intel was hit the hardest – a majority of its processors are affected and they are the most likely to be targeted in attacks – so it came as no surprise when several class action lawsuits were filed against the company. However, lawsuits were also filed recently against AMD and Apple.

In the case of AMD, the lawsuits focus on the fact that, shortly after the existence of Meltdown and Spectre came to light, the company claimed that the risk of attacks against its customers was “near zero” due to the architecture of its processors. The company later admitted that the two vulnerabilities that allow Spectre attacks do affect its CPUs.

Lawsuits announced by law firms Pomerantz and Rosen allege that AMD “made materially false and/or misleading statements and/or failed to disclose that: (1) a fundamental security flaw in Advanced Micro’s processor chips renders them susceptible to hacking; and (2) as a result, Advanced Micro’s public statements were materially false and misleading at all relevant times.”

The value of AMD shares went up after the company claimed that its products were not affected, but fell by $0.12, or nearly 1%, after the company confirmed on January 11 that its CPUs are in fact vulnerable to Spectre attacks.

Anyone who purchased AMD shares between February 21, 2017, when the company filed an annual report with the SEC, and January 11, 2018, can join the lawsuits.

The complaints point to several SEC filings from this period that allegedly led to AMD shares being artificially and falsely inflated. Plaintiffs claim they would not have acquired AMD stock at prices inflated by misleading statements and withholding information about the vulnerabilities. Google informed vendors of the flaws in June and July 2017.

In the case of Apple, whose processors rely on ARM technology, the complaint says “all Apple processors are defective because they were designed by Defendant Apple in a way that allows hackers and malicious programs potential access to highly secure information stored on iDevices.”

Plaintiffs claim Apple had known about the flaws for a long time, but did not take action until recently. The complaint, filed on January 8, said Apple had not provided any mitigations against Spectre attacks, but the tech giant did release software updates on the same day.

The complaint claims plaintiffs would not have purchased Apple devices or they would not have paid the price they paid had they known about the vulnerabilities.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/twuDgVFZ5xA/amd-apple-sued-over-cpu-vulnerabilities

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.

The malware, designed to target industrial control systems (ICS), was discovered after it caused a shutdown at an organization in the Middle East. Both FireEye and Dragos published detailed reports on the threat.

Triton is designed to target Schneider Electric Triconex SIS devices, which are used to monitor the state of a process and restore it to a safe state or safely shut it down if parameters indicate a potentially dangerous situation. The malware uses the TriStation proprietary protocol to interact with SIS controllers, including read and write programs and functions.

Schneider initially believed that the malware had not leveraged any vulnerabilities in its product, but the company has now informed customers that Triton did in fact exploit a flaw in older versions of the Triconex Tricon system.

The company says the flaw affects only a small number of older versions and a patch will be released in the coming weeks. Schneider is also working on a tool – expected to become available next month – that detects the presence of the malware on a controller and removes it.

Schneider has highlighted, however, that despite the existence of the vulnerability, the Triton malware would not have worked had the targeted organization followed best practices and implemented security procedures.

Specifically, the Triton malware can only compromise a SIS device if it’s set to PROGRAM mode. The vendor recommends against keeping the controller in this mode when it’s not actively configured. Had the targeted critical infrastructure organization applied this recommendation, the malware could not have compromised the device, even with the existence of the vulnerability, which Schneider has described as only one element in a complex attack scenario.

The company noted that its product worked as designed – it shut down systems when it detected a potentially dangerous situation – and no harm was incurred by the customer or their environment.

In its advisory, Schneider also told customers that the malware is capable of scanning and mapping systems.

“The malware has the capability to scan and map the industrial control system to provide reconnaissance and issue commands to Tricon controllers. Once deployed, this type of malware, known as a Remotely Accessible Trojan (RAT), controls a system via a remote network connection as if by physical access,” Schneider said.

The industrial giant has advised customers to always implement the instructions in the “Security Considerations” section of the Triconex documentation. The guide recommends keeping the controllers in locked cabinets and even displaying an alarm whenever they are set to “PROGRAM” mode.

While it’s unclear who is behind the Triton/Trisis attack, researchers agree that the level of sophistication suggests the involvement of a state-sponsored actor. Industrial cybersecurity and threat intelligence firm CyberX believes, based on its analysis of Triton, that the malware was developed by Iran and the targeted organization was in Saudi Arabia.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/RSRZJkHbaOc/triton-malware-exploited-zero-day-schneider-electric-devices

Common Approaches to Automated Application Security Testing – SAST and DAST

Not All Automated Software Security Assessment Approaches Are Created Equal

When planning a testing strategy for an application, it is important to evaluate the applicability and likely effectiveness of the various testing approach options. The two most common approaches to automated application security testing are static application security testing (SAST) and dynamic application security testing (DAST).

SAST involves testing application artifacts – such as source code or application binaries – at rest. The testing tool reviews the application source or binary to build a model, and then performs various types of analyses such as semantic, data flow, or control flow to identify potential vulnerabilities based on a set of rules tuned for the type of application, language, and application framework in use. DAST involves testing a running application by sending inputs and analyzing the application’s responses to see if those request/response patterns indicate the presence of security vulnerabilities.

Dynamic and Static Application Security Testing

There are several concerns to take into account when evaluating SAST. The first potential roadblock would be not having access to the application source code. Often, this is available for software that has been developed in-house however, in some cases internal security controls or organizational politics will make it difficult, if not impossible, for you to get access to the source code. Additionally, if you are planning to test third party software it is likely that you will not have access to source code unless you have negotiated this access. With no source code access, static analysis is likely off the table. While there are some tools and providers that enable security static analysis based on an application binary, they often require binaries compiled with debug symbols or other compiler settings, which might be similarly difficult to acquire for third party software.

A second potential roadblock could be if your static analysis tool doesn’t have support for the application’s language. If you have an application written in the Go language, but your static analysis tool only supports Java and .NET, then that tool is not going to be useful for testing the target application. Most static analysis tools have solid support for common enterprise development languages such as Java and .NET, but are either missing support or have less mature support for other languages. Similarly, you must also consider if your static analysis tool has support for the application type. Typically, these tools have two major components – analyzers that build a model of the application to test, and rules that are applied to the model during testing. Most commercial static analysis tools have support for web applications, and many have support for mobile applications, but if you are looking to test IoT applications you need to consider how mature the rule set is for the application in question. Missing or less mature rule sets will result in less effective testing.

The final potential roadblock will be if your static analysis tool doesn’t have support for any application frameworks in use. This is most frequently an issue for web applications but it can be applied for other application types as well. If you have a web application that is written in Java using the Spring framework, it is also important to understand if the static analysis tool has the ability to detect the use of important Spring constructs, as well as rules for detecting security issues based on the way that Spring handles user requests.

Just as the evaluation of SAST tools can uncover potential issues in testing, looking at dynamic application security testing (DAST) can present roadblocks as well. Most commercial DAST tools are intended to be used to test web applications, thus, you must confirm that the application in question is in fact a web application. There are both open source and commercial fuzzing tools and frameworks that can be used to test other types of applications – such as server daemons – but the applicability of these techniques and the level of expertise required to take advantage of them may make them less attractive options when starting to craft a testing program.

Assuming the application is web-based, you must ask if your DAST tool supports testing the target application. Not all DAST tools are capable of testing APIs or web applications written using different web application development approaches such as single page applications (SPAs). Critically, you must also determine if you have permission to test the system in question. For software developed in-house this is hopefully straightforward. You can either use a production instance or – often better – a pre-production version of the application for security testing. However, for software developed or hosted by suppliers, partners, or other third parties, testing access can be more complicated. It is best to negotiate rights for security testing, as well as requirements for remediation, during the application acquisition process as this can be hard to do after the fact. Understanding your ability to test these systems will be critical in determining what, if any, testing approach can be taken.

Not all automated assessment approaches are created equal. When developing an automated testing strategy for an application, it is critical to match the testing approach and testing tool to the characteristics of the target application. A failure to do this properly will result in ineffective or less effective testing, but properly matching automated testing tools to applications can provide you valuable insight into the applications’ security.

As Chief Technology Officer and Principal at Denim Group, Dan Cornell leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. Prior to Denim Group, he served as the CTO of BrandDefense, architecting and developing their cutting-edge intellectual property protection technologies. Additionally, he previously served as the Vice President, Global Competency Leader for Rare Medium’s Java and UNIX competency center, was a founder and VP of Engineering for Atension, Inc. and developed simulation applications for the Air Force with Southwest Research Institute.

Previous Columns by Dan Cornell:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/BZZpr5tE8iU/common-approaches-automated-application-security-testing-sast-and-dast

Intel Tests Performance Impact of CPU Patches on Data Centers

Intel Patches for Meltdown and Spectre Cause More Frequent Reboots

Intel on Wednesday shared information on the performance impact of the Meltdown and Spectre patches on data centers, and the company told customers that systems with several types of processors may experience more frequent reboots after firmware updates are installed.

Performance impact on data centers

Roughly one week ago, Intel informed customers that the mitigations for the recently disclosed CPU flaws should have a negligible performance impact for operations typically conducted on home and business PCs. The company reported seeing performance penalties ranging from 2-14% on these types of systems.

Intel has also conducted some performance tests on data centers and the initial results show that, as expected, impact depends on the type of workload and the configuration of the system.

Tests conducted on Intel Xeon Scalable (Skylake) systems showed that impact on integer and floating point throughput, Linpack, STREAM, server-side Java, and energy efficiency, which are typical for enterprise and cloud customers, was 0-2%.

In the case of online transaction processing (OLTP), Intel saw a performance impact of roughly 4%. The company is in the process of conducting more tests and believes the results will depend on system configuration and other factors.

In the case of FlexibleIO, which simulates various I/O workloads, throughput performance decreased by 18% when the CPU was stressed, but there was no impact when CPU usage was low.

Intel saw the most significant performance penalties during Storage Performance Development Kit (SPDK) tests, specifically using iSCSI, reaching 25% when only a single core was used. However, there was no impact on performance when SPDK vHost was used.

Performance penalties of Intel patches on data centers

Microsoft, AWS, Red Hat and others have also shared information on the impact of the Spectre and Meltdown mitigations on performance.

Firmware updates cause reboots

Intel has released firmware updates for 90% of the CPUs released in the last five years. While the company claims that the updates are effective at mitigating the Spectre and Meltdown attacks, users have reported seeing more frequent reboots after applying patches.

Intel initially said only systems running Broadwell and Haswell CPUs experienced more frequent reboots, but similar behavior has also been reported on Ivy Bridge-, Sandy Bridge-, Skylake-, and Kaby Lake-based platforms.

“We have reproduced these issues internally and are making progress toward identifying the root cause. In parallel, we will be providing beta microcode to vendors for validation by next week,” said Navin Shenoy, executive vice president and general manager of Intel’s Data Center Group.

Many affected vendors, including system manufacturers, have already released patches and workarounds for the Spectre and Meltdown vulnerabilities, but installing them has been known to cause serious problems.

Microsoft’s initial patches prevented systems with some AMD processors from booting, and Canonical’s Meltdown fix broke some devices running Ubuntu. Industrial control systems (ICS) vendors have warned customers that the patches for the CPU vulnerabilities should be thoroughly tested before being installed in order to prevent any disruptions.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/Qf0NgLE25ps/intel-tests-performance-impact-cpu-patches-data-centers

Cisco Patches Flaws in Email Security, Other Products

Cisco has patched several high severity vulnerabilities, including ones that allow privilege escalation and denial-of-service (DoS) attacks, in its Unified Customer Voice Portal (CVP), Email Security, and NX-OS products.

Software updates released by the company for its Email Security product address a privilege escalation vulnerability (CVE-2018-0095) that allows a local attacker with guest user permissions to gain root access.

The flaw affects the administrative shell of the Email Security Appliance (ESA) and the Content Security Management Appliance (SMA), and it’s caused by an incorrect networking configuration.

“An attacker could exploit this vulnerability by authenticating to the targeted device and issuing a set of crafted, malicious commands at the administrative shell. An exploit could allow the attacker to gain root access on the device,” Cisco said.

A different high severity vulnerability (CVE-2018-0086) was patched by Cisco in its CVP product. The security hole allows a remote, unauthenticated attacker to cause a DoS condition on the device by sending specially crafted SIP invite traffic to the targeted appliance.

A high severity DoS bug (CVE-2018-0102) has also been patched in the NX-OS network operating system. An unauthenticated attacker with access to the network can leverage the flaw to cause vulnerable devices to reload.

“An attacker could exploit this vulnerability by sending a pong request to an affected device from a location on the network that causes the pong reply packet to egress both a FabricPath port and a non-FabricPath port. An exploit could allow the attacker to cause a dual or quad supervisor virtual port-channel (vPC) to reload,” Cisco said in its advisory.

Cisco has also informed customers of two other vulnerabilities affecting NX-OS, including a DoS and a user account deletion issue, but these have been classified as medium severity and they have yet to be patched.

All of these vulnerabilities have been discovered by Cisco itself and there is no evidence of exploitation for malicious purposes.

Cisco released more than 20 advisories on Wednesday, but a majority describe medium severity flaws for which the company has yet to release any patches.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/T36tO4s-TII/cisco-patches-flaws-email-security-other-products