Simple Authentication and Security Layer (SASL) is an authentication layer used in Internet protocols. SASL is not a protocol, but rather a framework that provides developers of applications and shared libraries with mechanisms for authentication, data integrity–checking, and encryption.
Within the framework and a few of its plugins, there are a couple of known vulnerabilities that we want to make you aware of. Although patches have been issued, not everyone has implemented them.
Why would I need to know about SASL?Most server administrators will recognize the acronym from this type of error message or report:
“SASL LOGIN authentication failed: authentication failure”
Usually the message will contain more details about the failure, depending on the specific software and plugins that you are using. While receiving such a message in itself is not a reason for alarm, if you see it repeatedly and originating from the same IP address, then there is reason to investigate further. Possibly someone is trying to gain access to your server and planning to use it as a spam-box. They might be looking for a way to use your server and your resources to send out a spam campaign.
Countermeasures against brute force attacksSASL attacks usually turn out to be brute force attacks, meaning an automated script or a bot is trying over and over to log into an existing email account on your server, trying many combinations of credentials to find a valid username and password pair. Thankfully, there are some countermeasures you can take against these attacks.
- If you have the option to make your server listen on a different port, doing so might make you a less likely target for new attacks.
- If the SASL message is from the same IP all the time, block that IP in your firewall.
- If the attackers keep coming at you from different IPs, there are software solutions that use machine learning to automatically block any new assailant. One caveat to this solution: Be vigilant about false positives so that you don’t shut out legitimate users, such as remote employees.
SASL frameworkSASL is a framework for application protocols, such as SMTP or IMAP, that adds authentication support. It checks whether the user has the proper permissions to use the server in the way they request. It also offers a framework for data integrity–checking and encryption.
For a better understanding of how the framework actually works and where the vulnerabilities throw a wrench in the process, we want to give you some background about the flow of information between server and clients.
The following figure shows the basic SASL architecture:
Client and server applications make calls to their local copies of the SASL library, or libsasl, through the SASL API. The libsasl then communicates with the SASL mechanisms through the SASL service provider interface (SPI).
The following diagram shows steps in the SASL life cycle. The client actions are shown on the left and the server actions on the right. The arrows in the middle show interactions between the client and server over an external connection.
Memcached vulnerabilityMemcached is a software package that implements a high-performance caching server for storing chunks of data obtained from database and API calls in RAM. This helps speed up dynamic web applications, making it well suited for large websites and big-data projects.
In 2016, security researchers from Cisco’s Talos found three remote code execution vulnerabilities. All of these flaws affected memcached’s binary protocol for storing and retrieving data, and one of them was in the Simple Authentication and Security Layer (SASL) implementation. These vulnerabilities were fixed by Memcached later that year, but there has been a bad adoption rate.
Dovecot server vulnerabilitiesA Denial of Service vulnerability was found in the SASL authentication component of the Dovecot server. Remote attackers can crash vulnerable systems due to a validation error when the vulnerable software handles a crafted username when processing SASL authentication if the auth-policy component has been activated. The vulnerable versions were 2.2.25 through 126.96.36.199, and unfortunately some of these are still in active use.
Another flaw was found in Dovecot 2.0 up to 2.2.33 and 2.3.0. An abort of SASL authentication results in a memory leak in the Dovecot auth client used by login processes. The leak has an impact on high-performance configurations where the same login processes are reused and can cause the process to crash due to memory exhaustion.
More recent vulnerabilitiesA more recent vulnerability was found in Apache Qpid Broker. Both the Qpid broker and Qpid clients use the Cyrus SASL library, a full-featured authentication framework, which offers many configuration options. An authentication of incoming AMQP connections in Apache Qpid Broker-J is performed by special entities called "Authentication Providers." Each Authentication Provider can support several SASL mechanisms, which are offered to the connecting clients as part of SASL negotiation process.
The vulnerability that was discovered is a Denial of Service vulnerability, and it was found in Apache Qpid Broker-J 7.0.0 in the functionality for authentication of connections for AMQP protocols 0-8, 0-9, 0-91, and 0-10 when either PLAIN or XOAUTH2 SASL mechanism is used. The vulnerability allows an unauthenticated attacker to crash the Broker instance.
Update your softwareAs you can see, there are quite a few of these vulnerabilities still active, and I didn’t even touch on the older ones. In fact, there are a lot more older vulnerabilities than new ones, and I’m afraid that not all of them have been patched.
So we can’t say this enough, and we won’t stop telling you, either: Always make sure you are running the latest and patched version of the software you are using. This is especially true when talking about Internet-facing servers, and absolutely vital if one of their jobs is to keep your resources safe and secure. SASL is a vital authentication mechanism, in particular where many email servers are concerned.
Stay safe, everyone!
The figures in this article are courtesy of Oracle.