Log4JShell ByteCode Detector

Andreas Dann — Thu, 16 Dec 2021 13:33:59 +0000

A remote code execution vulnerability has been recently discovered in the popular Java logging framework Log4j affecting versions 2.0-beta9 to 2.15.0, and also some versions of log4j 1.*.

The vulnerability has been officially disclosed as CVE-2021-44228 but also got some more popular names as log4Shell or log4jShell.

As one of the most popular logging frameworks, Log4j has been used in the majority of Java projects. It is important that we quickly assess which projects actually include the vulnerable log4j library, and thus are also vulnerable.
Since hackers are currently actively exploiting, we need to be fast to discover and patch all affected systems.

This may sound simpler than expected initially, but we frequently do not have access to the source code. This can have many reasons, for instance, the software includes a third-party library for which we don't know if it is affected or we have some legacy software Java systems running, which we can't easily update.

How to check if you are affected -- even if you don't have access to the source code?

To check if your jar file is affected by the critical CVE-2021-44228, we provide an open-source command line tool https://github.com/CodeShield-Security/Log4JShell-Bytecode-Detector.
The tool scans the jar file and compares the classses against a set of pre-computed hashes of the vulnerable Log4j classes.
Since our tool only uses the hash and fingerprints of bytecode classes, no source code needs to be available.

The hashes have been pre-computed for artifacts on Maven Central.

Note: The set of pre-computed artifacts may not yet be complete, we will update it continuously. Stay tuned.

Which artifacts other then log4j-core are actually affected?

We have been working on the topic of Java vulnerability detection for several years now and we are currently applying our technology to further detect more instances of the vulnerability in the wild.

Maven Central is one of the largest repositories for Java artifacts, and basically any Java program sources its third-party dependency from there. When installing a dependency, a jar file will be downloaded and included into your software.

The question arises which artifacts are actually affected by the log4jShell vulnerability?

This is not a simple question to answer, as source code repositories are not always linked and even if so, the packaging step of a typical Java build may just pack all dependencies into a single jar, a so-called fatjar. Once the vulnerability is part of the jar, the software is affected.

With our "Fingerprinting" research technology, that we also applied to detect a security vulnerability within the German Corona-Warn App, we are able to answer this question.

Additional Background and references for CVE-2021-4428

A remote code execution vulnerability has been discovered in log4j versions 2.0-beta9 to 2.14. With an injection attack, an attacker can spawn an own shell and freely access the affected system. There are many references and article out there explaining the details

Five Common Cloud Security Threats and Data Breaches

Andreas Dann — Mon, 16 Aug 2021 09:01:39 +0000

In November 2020, an outage of Amazon Web Services (AWS) in the us-east-1 region rendered Roomba vacuum cleaners, Ring doorbells, and even Christmas lights dysfunctional for thousands of people in the US.
For one full day, popular websites like Flickr, Adobe, and the Washington Post were unreachable.¹

It didn't take long for people to tweet about the issue :)

My f---ing doorbell doesn't work because AWS us-east-1 is having issues

I... can't vacuum... because us-east-1 is down

While this incident might seem funny at first, it is also a true testament of how extremely dependent we are on cloud computing nowadays.
In fact, within the last 15 years, cloud computing has become a must-have for almost every company developing or using software.

As an increasing number of organizations rely on cloud services or even start shifting to go full cloud-native, cloud security has become a hot topic in the security community.
Unfortunately, the amount of cyberattacks targeting cloud systems has also increased.

To raise awareness of the threats that lurk in the cloud world, we present in the following five common security threats in the cloud and illustrate their risks with real-world examples.
The five identified threats are based on the Cloud Security Alliance Report Top Threats to Cloud Computing - The Egregious 11², the OWASP Serverless Top 10³, and the Cloud Native Computing Foundation Security Whitepaper⁴:

Cloud-(Security)-Misconfigurations
Over-Permissioned Cloud Resources
Insufficient Credential Management
Insecure APIs
Using Components with Known Vulnerabilities
References and Material

Cloud-(Security)-Misconfigurations

A leading cause of data breaches are cloud (security) misconfigurations, enabling data breaches, or the corruption of company networks.
Cloud resources like micro-services, object and database storage solutions, or networking components are the subject of such misconfiguration.
Typical examples of misconfigurations are:

unencrypted data storage or containers
publicly accessible data storage
open SSH or database ports
using default credentials
too open firewall and security group settings
deactivated security controls

Such issues are a concern in cloud environments as in any other architecture.
Nevertheless, the fast pace at which cloud infrastructure regularly changes, makes it difficult to find and control these issues.
Whereas in traditional applications changes in the infrastructure and assets involved multiple roles and approvals to reach production, the cloud infrastructure is much more flexible and dynamic.
Modern technologies and tools for provisioning, maintaining, and changing an infrastructure like Infrastructure-as-Code enable rapid changes in the infrastructure.

The use of multiple cloud providers and the combination of private and public clouds, surely does not make tracking down misconfigurations easy.

Since misconfigurations are easy to make but difficult to spot in complex cloud environments, they are the root cause of several recent and massive data breaches.
In the following, we can only present a small subset of data breaches showing the impact of misconfigurations.

In 2018, an unsecured Elasticsearch database of the marketing company Exactis exposed nearly 340 million individual records containing personal information of American adults as well as millions of businesses.
The database server was erroneously configured to be publicly accessible. ⁵
In 2019, the personal information of thousands of hotel guests including members of the US government and military was publicly exposed due to an open Elasticsearch database of AutClerk, which is a combined reservations system for hotels, accommodation providers, travel agencies.
⁶
In 2020, the personal and payment information of 7 million users of the mobile payment app Bharat Interface Money (BHIM) was exposed.
The breach was caused by a misconfigured AWS S3 bucket. In fact, user data was stored unencrypted on a publicly accessible S3 bucket, making it vulnerable to misuse for frauds and theft. ⁷
In 2020, the companies Advantage Capital Funding and Argus Capital Funding didn’t set up encryption, authentication, or access credentials for their database, which contained highly sensitive financial and personal data.
As a result, almost half a million gigabytes of confidential legal and financial documents were leaked.⁸

Over-Permissioned Cloud Resources

Even a simple cloud-native application can consist of dozens or hundreds of micro-services.
Each reading, writing, and updating different databases, object storages, data streams, and APIs.
A secure orchestration of the micro-services and assets requires a careful access control configuration for each of the resources, which is tedious.
However, attackers target over-permissioned cloud resources to escalate their privileges and to gain unauthorized access to other resources in the account rather than having control over these resources directly.
Unnecessary cloud resources or excessive permissions on resources are a potential backdoor that can lead to data leakage from not only the over-permissioned resources themselves but also from their related resources.
And, in the worst-case, may even give an attacker full control over cloud resources or the whole account.

An example in which an over-permissioned cloud resource caused a massive data breach is the Capital One hack.
In 2019, an attacker gained access to 80,000 account numbers, 140,000 Social Security numbers, 1 million Canadian Social Insurance Numbers by abusing an over-permissioned web application firewall (WAF).

By abusing the over-permissioned WAF the attacker could craft a Server-Side-Request Forgery (SSRF) attack to steal the data.

The attack involved multiple steps visualized in the figure and described in a report of the MIT ⁹, which we cite here:

The FBI and Capital One identified several accesses through anonymizing services such as TOR Network and VPN service provider IPredator, both used to hide the source IP address of the malicious accesses;
1. The SSRF attack allowed the criminal to trick the server into executing commands as a remote user, which gave the attacker access to a private server.
2. The WAF misconfiguration allowed the intruder to trick the firewall into relaying commands to a default back-end resource on the AWS platform, known as the metadata service with temporary credentials for such environment (accessed through the URL http://169.254.169.254);
3. By combining the SSRF attack and the WAF misconfiguration, the attacker used the URL “http://169.254.169.254/iam/security-credentials” to obtain the AccessKeyId and SecretAccessKey credentials from a role described in the FBI indictment as “*****-WAF-Role” (name was partially redacted). The resulting temporary credentials allowed the criminal to run commands in AWS environment via API, CLI or SDK;
4. By using the credentials, the attacker ran the “ls” command7 multiple times, which returned a complete list of all AWS S3 Buckets of the compromised Capital One account ("$ aws s3 ls");
5. Lastly, the attacker used the AWS “sync” command8 to copy nearly 30 GB of Capital One credit application data from these buckets to the local machine of the attacker ("$ aws s3 sync s3://bucketone."). This command gave the attacker access to more than 700 buckets, according to the FBI report.⁹

Insufficient Credential Management

One of the biggest threats to cloud security is human error when handling credentials or sensitive information.
Sensitive data like secrets, access tokens, and passwords can be accidentally uploaded to a Git repo, put on a public bucket, or even hardcoded in application code.
Since cloud systems are often globally and publicly available, stolen credentials can be easily abused by attackers.
Typical examples are:

Insufficient protection of credentials, like encryption
Use of weak passwords
No automatic rotation of keys, passwords, and certificates
No use of multi-factor authentication
Storing credentials in Version Control Systems, Source-Code, or Environment Variables

In 2014, attackers scraped public GitHub repositories for cloud service credentials and hijacked accounts to mine cryptocurrency at other people's expense.
The attackers were able to discover and misuse the cloud service provider credentials within 36 hours of the credentials being pushed to GitHub accidentally.¹⁰

Insecure APIs

Almost every cloud application exposes its services in the form of APIs or UIs.
Since they act as the front door of the system, they are attacked and scanned continuously.
Thus, the API of each system must follow established security guidelines and all APIs must be protected by adequate means of authentication and authorization.

In 2018, Facebook experienced a breach that affected more than 50 million accounts that was the result of a credential theft vulnerability introduced as a feature back in 2017.
Facebook admitted that it didn’t know what information was stolen, nor how many user accounts were compromised.

Using Components with Known Vulnerabilities

This threat is neither bound to cloud applications nor cloud environments, but a general threat every application developer and security expert should be aware of.
Nowadays, applications are not re-written from scratch but contain a sustainable amount of third-party/open-source libraries and frameworks to execute the desired tasks.
Even for commercial applications easily as much as 75% of the code comes from open-source libraries and frameworks.¹¹
Vulnerabilities in the used (open-source) components are a common risk these days and attackers will target applications that make use of vulnerabilities in included open-source components,
as they are easy to exploit - often even publicly accessible exploits exist.

An (in)famous example, which shows the impact of vulnerable libraries, is the data breach of the largest consumer credit reporting agency Equifax in 2017 ¹²¹³.
Attackers exploited a vulnerability (CVE-2017-5638) in the open-source framework Apache Struts2 - which had already been patched but which Equifax had not updated on their server, to gain access to the corporate network.
The attackers pulled personal data including Social Security numbers, birth dates, and residential addresses of an estimated 152 million American, 44 million British, and 8000 Canadian residents.
In the end, the data breach cost Equifax more than 1.7 billion US dollar and Equifax's Chief Security Officer (CSO) and Chief Information Officer (CIO) resigned.

About the Author

Andreas Dann is a co-founder of CodeShield, a context-aware cloud-native security tool. Before, Andreas worked as a researcher software composition analysis to detect, assess, and mitigate vulnerabilities in included open-source libraries at the Secure Software Engineering group at Paderborn University. Andreas is one of the main contributors of Soot, an open-source static program analysis framework for Java.

References and Material

https://www.dailymail.co.uk/sciencetech/article-8994907/Widespread-Amazon-cloud-service-outage-disables-Roombas-Ring-doorbells-Christmas-lights.html ↩
Cloud Security Alliance (CSA), Report 2020, Top Threats to Cloud Computing - The Egregious 11 ↩
https://owasp.org/www-project-serverless-top-10/ ↩
Cloud Native Computing Foundation (CNCF), Report 2020, Security Whitepaper ↩
https://www.wired.com/story/exactis-database-leak-340-million-records/ ↩
https://www.itpro.co.uk/security/34671/us-military-data-exposed-in-179gb-autoclerk-leak ↩
https://www.newindianexpress.com/nation/2020/jun/01/hackers-claim-to-have-found-vulnerability-in-bhim-app-npci-denies-data-compromise-2150840.html ↩
https://www.zdnet.com/article/financial-apps-leak-425gb-in-company-data-through-open-database/ ↩
MIT, A Case Study of the Capital One Data Breach, http://web.mit.edu/smadnick/www/wp/2020-16.pdf ↩
https://www.forbes.com/sites/runasandvik/2014/01/14/attackers-scrape-github-for-cloud-service-credentials-hijack-account-to-mine-virtual-currency/ ↩
L. Heinemann et al. On the extent and nature of software reuse in open source java projects ↩
https://krebsonsecurity.com/tag/equifax-breach/ ↩
https://medium.com/cloud-security/cves-security-vulnerabilities-1830aee64904 ↩

DEV Community: Andreas Dann