Log4Shell persists because the Apache Log4j 2 software package it affects is one of the world’s most widely used logging libraries. Finding and fixing every instance of Log4Shell is expected to take a decade, according to the US Department of Homeland Security.
In the meantime, security teams can take some steps to speed up Log4Shell mitigation and remediation in their networks. Understanding Log4j vulnerabilities Before delving into how to detect and patch Log4Shell, it’s important to understand the nature of the vulnerability. Log4j is an open-source logger (maintained by the Apache Software Foundation) that records information and events in a program. Log4j isn’t standalone software but a package of code that developers can plug into their own Java apps. The Apache Log4j framework is used in some of the biggest services on the web, ranging from network infrastructure like Amazon Web Services (AWS) and Cisco solutions to popular apps like Twitter and Minecraft. Some versions of Log4j—specifically, Log4j 2.17.0 and below—suffer from serious vulnerabilities. The most dangerous of these is Log4Shell (CVE-2021-44228; CVSS rating: 10), a remote code execution (RCE) zero-day vulnerability found in Log4j versions 2.14.1 and earlier. Log4Shell is a result of how vulnerable versions of Log4j handle the Java Naming and Directory Interface (JNDI), an API that Java apps use to access resources hosted on external servers. Threat actors can take almost total control of vulnerable systems by sending malicious JNDI lookup commands through Log4j. These commands trick the app into running arbitrary code that can do almost anything: steal data, install ransomware, knock devices offline, and more. Log4Shell attacks A typical Log4Shell cyberattack works like this: Related Log4j vulnerabilities and how they’re exploited As Apache worked to patch Log4Shell, security researchers identified a handful of related flaws in some versions of Log4j. These include: How to detect Log4j vulnerabilities Finding every vulnerable instance of Log4j in a network can be difficult. Log4j appears in an estimated millions of apps, meaning security teams have a lot of assets to inspect. Furthermore, Log4j is often present as an indirect dependency. That means it isn’t directly contained in the source code of an asset, but it appears as a dependency of a software package or integration the asset relies on. Google reports that most vulnerable Log4j instances are more than one level deep in the chain of dependencies, and some are as many as nine levels deep. That said, security teams can detect Log4j vulnerabilities with the right tactics and tools. What to look for Every version of Log4j 2 from 2.0-beta9 through 2.17 is vulnerable to Log4Shell or a related flaw. Put another way, security teams must find and address any version of Log4j earlier than 2.17.1. Log4Shell and its related flaws are only present in “Log4j-core” files, which provide the core functionality of Log4j. The flaws are not present in “Log4j-api” files, which control the interface between apps and Log4j loggers. Log4j can appear in assets the company controls, third-party assets the company uses (e.g., cloud services), and assets used by service providers with access to the company network. While Log4j is most likely to appear in Java-based apps, it can also be present in non-Java apps through dependencies and integrations. Within Java apps, libraries like Log4j are often packaged in Java Archive files, or “JAR files.” JAR files can contain other JAR files, which in turn can contain their own JAR files, and so on. To find all vulnerable versions of Log4j, security teams must inspect all levels of JAR files, not only the top-level files. How to find it Experts recommend using a combination of techniques for finding Log4j vulnerabilities. Manual searches. Security teams can manually search for Log4j flaws. They can use development tools like Apache Maven to generate dependency trees that map all dependencies in an app, or they can use external threat intelligence to identify affected assets. For example, the Cybersecurity and Infrastructure Security Agency (CISA) compiled a list of software known to suffer from Log4Shell. The list is available on GitHub. On Linux, Microsoft Windows, and macOS operating systems, security teams can search file directories for instances of Log4j using the command line interface. Vulnerability scanning tools. Following Log4Shell’s discovery, some organizations released free tools designed to find Log4j vulnerabilities. Examples include Palantir’s Log4j-sniffer and the CERT Coordination Center’s scanner, among many others. While specialized scanners are still available, many standard security solutions like vulnerability scanners, attack surface management (ASM) platforms and endpoint detection and response (EDR) solutions can now detect Log4j vulnerabilities. Because Log4Shell can hide deep in dependency chains, security teams may supplement automated scans with more hands-on methods, like penetration tests. Threat hunting. According to CISA, attackers have been known to use Log4Shell to break into a network and then patch the asset they compromised to cover their tracks. For that reason, it’s recommended that security teams assume a breach has already happened and actively hunt for signs of Log4Shell exploitation. Cybersecurity tools like security information and event management (SIEM) solutions and extended detection and response (XDR) platforms can help detect abnormal activity associated with Log4Shell, like strange log entries or suspicious traffic patterns. Security teams should launch full incident response and investigation procedures for any possible hint of Log4Shell, given how serious the consequences of an attack can be. How to fix Log4j vulnerabilities Security teams have a few options when addressing Log4j vulnerabilities. The best case: patching vulnerable systems For complete remediation of Log4Shell and related flaws, organizations must update all instances of Log4j in their networks to the latest version (or at least to version 2.17.1). The latest versions of Log4j remove the functions attackers can exploit, and they remove support for commonly abused protocols like LDAP. There is no single, system-wide patch available, and updating Java itself does not address the issue. Security teams must update every instance of Log4j in every affected asset. Other mitigation measures Security researchers agree that patching is the ideal solution. If patching isn’t feasible, organizations can use other mitigation steps to minimize the chances of an attack. Disallowing message lookups in vulnerable apps. Attackers use a feature of Log4j called “message lookup substitutions” to send malicious commands to vulnerable apps. Security teams can manually disallow this function by changing the “Log4j2.formatMsgNoLookups” system property to “true” or setting the value of the “LOG4J_FORMAT_MSG_NO_LOOKUPS” environment variable to “true.” While removing the message lookup substitution function makes it harder for attackers to attack, it’s not foolproof. Malicious actors can still use CVE-2021-45046 to send malicious JNDI lookups to apps with non-default settings. Removing the JNDIlookup class from vulnerable apps. In Log4j, the JNDIlookup class governs how the logger handles JNDI lookups. If this class is removed from Log4j’s directory of classes, then JNDI lookups can no longer be performed. Apache notes the following command can be used to remove the JNDIlookup class from vulnerable apps: zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class While this method is more effective than disallowing message lookups, it doesn’t stop attackers from mounting other exploitation attempts, like triggering denial of service attacks through recursive lookups. Blocking potential Log4Shell attack traffic. Security teams can use web application firewalls (WAFs), intrusion detection and prevention systems (IDPS), EDRs, and other cybersecurity tools to intercept traffic to and from attacker-controlled servers by blocking commonly used protocols like LDAP or RMI. Security teams can also block IP addresses associated with attacks or the strings that attackers commonly use in malicious requests, such as “jndi,” “ldap” and “rmi.” However, attackers can get around these defenses by using new protocols and IP addresses or obfuscating malicious strings. Quarantining affected assets. If all else fails, security teams can quarantine affected assets while they wait for a patch. One way to do this is by placing vulnerable assets in an isolated network segment that cannot be accessed directly from the internet. A WAF can be placed around this network segment for extra protection. Keeping Log4Shell at bay One of the tricky things about remediating Log4Shell is that it doesn’t always stay patched. In November 2022, Tenable reported that 29% of the assets still vulnerable to Log4Shell were “recurrences,” meaning they were patched, but the flaw reappeared. Recurrences happen when developers accidentally use software libraries that contain unpatched versions of Log4j to build or update apps. While developers can scrutinize the frameworks they use more closely, it’s easy to miss vulnerable versions of Log4j when they’re several levels deep in JAR files. Implementing formal vulnerability management and patch management programs can offer security teams a more effective way to monitor assets for the return of Log4j vulnerabilities. Regular vulnerability scanning and penetration testing can help quickly catch new vulnerabilities, Log4Shell or otherwise. Patch management ensures new vulnerabilities are closed as soon as vendors release fixes. More help fighting Log4Shell and other zero-day vulnerabilities Increasingly, hackers are using automated tools to exploit zero-day vulnerabilities like Log4Shell with ease—and to launch a barrage of ransomware attacks and other cyberthreats. Security teams working with traditional endpoint security approaches face alert fatigue, complex tooling and lengthy investigations—and struggle to keep up. IBM Security® QRadar® EDR, formerly ReaQta, remediates known and unknown endpoint threats in near real time with easy-to-use intelligent automation that requires little-to-no human interaction. With QRadar EDR, analysts can make quick, informed decisions and use automated alert management to focus on the threats that matter most. Advanced continuous learning AI capabilities and a user-friendly interface put security staff back in control and help safeguard business continuity.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online