3 Tips to Safeguard Your Digital Future

The ongoing COVID-19 crisis has proven that applications are the driving force of the world economy. With a massive shift from brick-and-mortar locations to online operations across all industries during lockdowns, companies will likely continue to en… Continue reading 3 Tips to Safeguard Your Digital Future

Black Hat Sneak Preview: New Vulnerabilities Exposed in Docker Hub

Community ecosystems with vibrant member support have been the catalyst for faster innovation and shorter software development lifecycles in DevOps. Whether it is downloading code or contributing back to the community, organizations today rely heavily on open source software to drive their business. In fact, modern application development is more about assembling existing packages than writing new code. Developing new code takes time, and in the high-velocity world of DevOps it’s much easier and faster to download open source software and frameworks to get up and running quickly. As the adage goes, it’s better to “stand on the shoulders of giants” than to “reinvent the wheel.”

But this adds tremendous security blind spots if security pros are not working closely with their DevOps counterparts. According to a study conducted by Sonatype, 20 percent of organizations suspected or confirmed breaches related to open source components, which was a 50 percent increase since 2014. In addition, a staggering 50 percent of organizations are not satisfied with their ability to understand known security vulnerabilities in open-source components. Security needs to be embedded early in the software development lifecycle (SDLC) in a non-intrusive way that avoids slowing down developers. Organizations should start thinking of security as another critical test in the build phase.

So how does this relate to application containers?

Containers are the hottest topic in the world of DevOps infrastructure. A container is a self-contained package that has everything required to run an application: libraries, binaries, configuration files and just enough operating system to make it lightweight. Containers allow developers to rapidly progress from build to test to production without any changes to the application across the SDLC. If you haven’t heard of containers before, you probably have heard of Docker, the most popular container image format. 451 Research estimates that 25 percent of enterprises are already using containers today, and Docker adoption is up 40 percent since last year.

Not only have containers become an essential enabling technology for modern application development, but the technology itself relies on open source software for distribution among DevOps teams to build solutions. The most common container distribution today is through Docker Hub, a cloud-based container registry for pre-built, third-party container images. Docker Hub has tremendous community support with over 500,000 Docker container images that have been downloaded over 8 billion times. This community is so pervasive that customers often believe they are building all of their container images in-house when, in reality, the base layers are coming from Docker Hub. With so many developers relying on open source to build containers, how has that affected their organization’s security posture? What is the security exposure caused by downloading Docker Community images and Docker Official images? What can you do to mitigate this risk and secure containers before deployment?

Join me at Black Hat to find out!

On Wednesday, July 26 at 10:20 a.m. PT, I’ll be unveiling new, groundbreaking research analyzing the top 5,000 Docker Community images and all Docker Official images in Docker Hub for vulnerabilities and malware. The research team used Tenable.io Container Security to conduct the analysis, and the results are extremely surprising. The bottom-line is that known vulnerabilities are widespread on Docker Hub. All container registries, images and hosts need to be tested continuously and automatically to eliminate blind spots and reduce exposure risk.

If you’re attending Black Hat, I hope you will join me in the Business Hall Theater A on Level 1 on Wednesday. If you’re looking to seamlessly and securely enable DevOps processes by providing visibility into the security of container images, we invite you to try Tenable.io Container Security for a 60-day free trial.

Continue reading Black Hat Sneak Preview: New Vulnerabilities Exposed in Docker Hub

Posted in SBN

Rediscovering the Intel AMT Vulnerability

No PoC, No Patch, No Problem!

On May 1, 2017 Intel disclosed the AMT vulnerability (INTEL-SA-00075), but details of that vulnerability were not made public. However, Tenable researchers were able to overcome this challenge and make Tenable the first to deliver Intel AMT vulnerability detection capabilities to customers, just minutes after Intel’s announcement yesterday. This is the story of how we did it.

The hunt

The first thing our research team tried was to set up a known vulnerable target. After some searching, we found a Dell computer that had Intel AMT support but there was a problem. It was not configured/provisioned for what we needed.

The Intel Management Engine Interface (MEI) driver was installed but the Local Management Service (LMS) was not. Intel AMT documentation says the AMT configuration tool ACUWizard.exe requires LMS to be running.

So we searched and found a software package for installing LMS on the vendor’s website. After LMS was installed, we were able to configure/provision AMT on the computer, giving us access to AMT via the web interface.

AMT login screen

Next, we logged in to the web interface and browsed the menu items:

AMT web interface

A logical vulnerability

During this process, we found out that the HTTP Digest authentication method was used to access the web interface. In a blog post written by Embedi (the company of the researcher who discovered the vulnerability) a bullet point stood out:

With 100 percent certainty it is not an RCE but rather a logical vulnerability.

One hypothesis we had was that this logical vulnerability may be related to authentication. After all, a logical vulnerability that seems to involve decision-making and authentication certainly falls into this category (i.e., deciding whether a login credential is right or wrong). If correct, this would give a remote attacker access, as suggested by the Intel advisory.

Drawing on past experience when we reported an authentication-related vulnerability in which the length of credential comparison is controlled by the attacker (memcmp(attacker_passwd, correct_passwd, attacker_pwd_len)), we tested out a case in which only a portion of the correct response hash is sent to the AMT web server. To our surprise, authentication succeeded!

Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response=“” in the HTTP Authorization header).

Authentication still worked. We had discovered a complete bypass of the authentication scheme.

With a simple find_and_replace regex (find: response\s*="[0-9a-f]+", replace: response="") in Burp Suite, we could fire up a web browser configured to use the proxy, and log in to the AMT web interface with the user admin and any password.

Null response

Coordinated disclosure

With our findings confirmed, the next question was whether the authentication bypass vulnerability that the Tenable Research team had just discovered was the same one described in the Intel AMT advisory, or if was in fact another critical vulnerability.

As any good researcher knows, it is important to get this disclosure part right – the discovery of a possible zero-day in widely distributed firmware isn’t something you take lightly.

Tenable reached out to Intel on May 3 with our proof-of-concept, asking if this was the same vulnerability previously disclosed by Intel on May 1. On May 4, Intel responded confirming that it was the same vulnerability and requested we wait to share our findings until 12:00 p.m Pacific time that day.

That meant that within minutes of the Intel deadline, Tenable was able to give customers a detection plugin (Nessus plugin 97999) to help them know exactly where they are exposed to the Intel AMT vulnerability so they can continue to confidently manage cyber risk to the business.

Continue reading Rediscovering the Intel AMT Vulnerability

Posted in SBN

Containerization and Security

Containerization is not only an exciting foundation of DevOps; it is also an answer to several critical operational issues.

For developers, building software once, packaging it and running it anywhere regardless of library versions, dependencies, or underlying hardware and operating system has been a challenge.

For operations staff, setting up an environment that can run any new application consistently is reassuring, so that when the application goes into production, the system is reliable and can be trusted to run smoothly.

For production staff, implementing a new package easily is a huge time saver.

For all these professionals, containers are helping a dream become a reality.

What are containers?

Containers are lightweight, portable software packages with everything needed at runtime

While containers are a hot topic, they are not new. Docker is arguably the company that launched the current container market. But container technology has been with us for several years, principally in Linux as LXC. Containers are lightweight, portable software packages with everything needed at runtime: code, system tools, and libraries. While containers are similar to virtual machines (VMs), they are much smaller and more efficient. Along with the application itself, a VM includes the overhead of the entire guest operating system, binaries and libraries, and it requires a hypervisor for management on a server. A container is a much lighter weight package (think of twenty megabytes instead of twenty gigabytes); it shares the operating system kernel via API calls with other containers on a host. Containers are a means of consistently moving and deploying applications into different environments, because a container includes the entire runtime environment needed for the application – libraries, dependencies, configuration files, etc. – eliminating the differences in OS distributions and guaranteeing that the software will always run the same, regardless of the environment.

The benefits of containers

Not only are containers small and efficient, but they are also highly dynamic. They can start up or shut down quickly. They can run for just hours or for days. They can be deleted and replaced.

Containers are increasingly being used for web services, such as Google Apps. Containers make it easy to develop web apps that are composed of hundreds of microservices, replacing a monolithic backend. Microservices accelerate development by separating functionality for efficiency and maintainability.

Containerization provides isolation for microservices from other processes, a lightweight deployment mechanism, a stateless package, and the ability to build and rebuild services on the fly. Containers contribute to easier and quicker application delivery, and faster and more reliable deployment. Hundreds of containers can be run on just one server, saving valuable data center budget. Docker containers can run on virtually any computer, infrastructure, or cloud. Container management is therefore much less painful for operators.

Container security

Infosec professionals generally consider containers less secure than VMs

But because containers are not isolated from one another to the same degree that virtual machines on a shared host are, and because containers are usually not scanned for vulnerabilities before or after being deployed to production, infosec professionals generally consider containers less secure than VMs. A vulnerability in a shared OS kernel can potentially provide a way into a container. Active scans can miss most of them. Containers also typically don’t include the SSH daemon, so credentialed scans don’t work with most containers. Microservices and containers can introduce hundreds of endpoints and erode the visibility of security risks.

Tenable has been addressing container security since early 2016, with Nessus offering the ability to detect running Docker hosts and the containers running on them. Nessus can also audit Docker hosts against the CIS Docker v1.6+ benchmark to help harden container hosts. Discovering and securing Docker hosts is an important first step, but it’s not enough. Without comprehensive, continuous monitoring, you may not be able to see and assess all container configurations and instances. A new kind of security solution is needed.

Tenable now offers a better approach to container security

Because containers are rebuilt on the fly and exist for short periods of time, organizations have struggled to continuously assess Docker containers and similar environments for vulnerabilities. Tenable now offers a better approach to container security – a solution that monitors container images for vulnerabilities during the development lifecycle, before deployment, to ensure containers are vulnerability-free in production.

The recent acquisition of FlawCheck, the leader in container security, enables Tenable to deliver innovative technology to organizations that want to integrate security into their build pipeline. This helps provide a real-time view of their CI/CD (continuous integration and continuous deployment) environments for vulnerability and malware detection in Docker container images.

Flawcheck in the devops pipeline
FlawCheck scans container images in the Test phase of the DevOps pipeline

FlawCheck scans container images for vulnerabilities and provides continuous monitoring early in the DevOps lifecycle. An application need not be running to be discovered and scanned; the container image for that app is stored and scanned, providing timely security assurance before an application or service is launched.

FlawCheck revolutionizes DevOps security

For organizations with large development teams, FlawCheck revolutionizes DevOps security, moving security into the development pipeline for real-time on-the-fly security auditing. Security is baked into containers before they are ever deployed onto networks.

For more information

Continue reading Containerization and Security

Posted in SBN