Wednesday, November 19, 2014

Security Hardening for Asterisk: Privilege Escalations with Dialplan Functions


Privilege escalations are a nasty security problem in which an attacker uses an exploit to get access to more resources on a computer system then was intended.

Digium has introduced a flag in 'asterisk.conf' that allows us to help prevent one such privilege escalation which in theory could be used as a remote exploit.

By using the Asterisk Manager Interface, (AMI) it's possible to send commands to Asterisk. This gives developers an incredible tool to make all sorts of applications that use Asterisk. This port should be firewalled if you do need the AMI and it should be completely disabled if you have no use for the AMI.  Maintaining strong passwords should also be a given and since the protocol is completely plain text, extra thought should be put into the the network topology between the Asterisk server and the application using the AMI.

If you do need to provide access to the AMI for applications in your environment, I suggest contacting the devs of those apps and seeing if the new flag, 'live_dangerously' can be set or not.

The following link contains some information on that flag:

https://wiki.asterisk.org/wiki/display/AST/Privilege+Escalations+with+Dialplan+Functions


The scariest part of this situation is that Diguim implies that someone could possibly get shell access on the server and have the ability to change any file on the filesystem.   This would be limited to the same access rights as the user that Asterisk is running as, but there is two problems with that notion. First, I would wager that  many Asterisk processes are running as root in the wild and that even if an IT team was on the ball and had Asterisk running as an unprivileged user, an attacker might make use of another exploit on the system to deploy another payload effectively just using this exploit as the beachhead in a larger more sophisticated attack.

To check the current state of this flag in your Asterisk deployments, run the following commands from the CLI:

  grep live_dangerously /etc/asterisk/asterisk.conf | grep -v ^';'

If the command does not print out any results, you are effectively running with 'live_dangerously=yes'.  To fix this potential problem add "live_dangerously = no" some where in the [options] section in asterisk.conf:

  sudo vim /etc/asterisk/asterisk.conf

Finally, restart Asterisk to make sure this change takes effect.

Tuesday, November 18, 2014

Is fail2ban redundant when a server is firewalled?

The question I was asked today is pretty straight forward, do we still need to run fail2ban on our internet facing servers if we are running a firewall?

Quite simply the answer is that you'll want to run 'fail2ban' in nearly every scenario.  'fail2ban' provides a layer of security that is not made redundant by additional layers of security such as firewalls. They actually complement each other rather nicely.

When it comes to services such as http or SIP where we have to strike a balance between easy public access and reasonable security to safe guard against abuse and denial of service attacks, fail2ban gives us a tool that can stop a would be attacker after a few failed attempts.

I would argue that even if your service is on a corporate LAN and if remote users had to VPN in to access the service, fail2ban should one of the many tools you use on your servers to harden them from attack.