FreePBX Security Vulnerability SEC-2019-001

[jsmith (Jared K Smith)]

Sangoma was recently made aware of a significant security vulnerability affecting the administrator web interface for current versions of FreePBX and PBXact. Sangoma has published updated FreePBX and PBXact modules (for the “framework” module) to our mirror servers, and they should be available to you now. Many modern FreePBX systems are set to automatically apply security updates, but we STRONGLY encourage you to check all of your FreePBX systems to make sure that they have updated to the new version. To do this, please go to Admin -> Module Admin and make sure the “FreePBX Framework” is greater than or equal to one of the following versions:

For FreePBX/PBXact 13: v13.0.197.14
For FreePBX/PBXact 14: v14.0.13.12
For FreePBX/PBXact 15: v15.0.16.27

You may also check the version of the modules from the Linux command-line on your FreePBX/PBXact system by running “fwconsole ma list” and looking at the version of the “framework” module.

While keeping your system up to date is critical in preventing security issues, we also encourage all FreePBX and PBXAct users to follow strong security practices, such as limiting exposure of your FreePBX or PBXact Admin GUI whenever possible.

We would like to publicly thank those who reported this issue to us in a responsible manner. This responsible disclosure allowed us to prepare updates and make them available before public disclosure of the vulnerability, so that FreePBX users can secure their systems.

More details on the vulnerability are available on the FreePBX wiki at https://wiki.freepbx.org/display/FOP/2019-11-20+Remote+Admin+Authentication+Bypass

[billsimon]

Under what circumstances can intrusion take place, and how can FreePBX administrators tell if their system has already been had?

I’m not asking for public description of the specific attack vector, but the “More details” link lacks actual details.

[mattf (Matthew Fredrickson)]

Hey Bill,

Due to the concerning nature of the exploit, we’re trying to keep the details of the attack vector from getting leaked. It’s safe to say that if you have a system that has the admin portal exposed to the open internet, you should take precautions to verify that nothing is amiss, such as auditing admin and user accounts and verifying that they are in order (no suspicious new accounts, etc). Also, it never hurts to reset your upstream SIP provider credentials/password in case you’re using username/password auth with them.

Finally, it might not hurt to clear the php session tokens and force a login from all users again (depending on how deeply you’d like to go through this process).

You can do that at an ssh console with the following command:
rm -f /var/lib/php/session/*

Hope that helps a bit, and sorry to have to break the bad news.

Matthew Fredrickson

[ausip (Paul Mitchener)]

HI @mattf

I wasn’t after specifics, just an idea of what the exploit relates to, which you have explained well enough.

Based on the timing, It sounds like we have fell victim to this exploit. The extension that was compromised had a random password on it that I would not have used. This was a red flag for me. Luckily we caught the exploit before they spent too much on calls to Morroco.

We had already blocked web access to the admin portal. As all extension secrets are visible from the admin UI, I am guessing it’s probably best that we go and reset all the passwords.

I will also have a look for any new users in the Admin Panel.

Thanks for the explanation.

[FreerPBXer]

Is there a way to have the UCP accessible and not the admin portal? If so, can someone post a link with directions?

[jgiebler (Jameson G)]

Thanks @mattf

Just to confirm…

If we did not have the Admin Portal (Port 443 on the FreePBX servers in our case) accessible to the open web, we probably didn’t have anything malicious happen… unless it came from an inside device with access to port 443 on the FreePBX Servers.

Can you confirm that is a correct understanding?

For us, we only have the Standard SIP ports and the Media Ports Open to the web. The SIP ports are limited to inbound access only from our specific Provider IPs.
Thank you

[mattf (Matthew Fredrickson)]

That is correct. If you didn’t have the admin portal accessible on the open web, the only attacker that might be of concern is someone operating inside your network, and for most people that means you’re safe

Matthew Fredrickson

[jgiebler (Jameson G)]

Thanks for the quick response @mattf

That is very helpful to have confirmed.

[moussa854 (Moussa)]

Do you have sensitive information that can be leaked from the UCP? Have you notice any change in passwords? unusual call destinations?

[cyberdocwi]

Thank you Sangoma for jumping on this right away. I can also appreciate the desire to also keep the attack methodology under wraps.

I have taken a look at the Linux side of the logging: secure, messages, that sort of thing, but am wondering if an audit trail exists to tell who accessed and who was denied the login screen. Is there a simple log file somewhere that I am missing that would show if anyone was able to access via the fault?

Thanks,

Christian

[moussa854 (Moussa)]

I wrote few scripts that pulls the information from the logs. The logs get rotated and the scripts will not help with old incidents.
This one will pull all IPs that accessed the server

sudo cat /var/log/httpd/access_log | awk ‘{print $1}’ | sort -n | uniq | sort -nr | head -20

This one will pull the IPs that get denied

sudo cat /var/log/httpd/error_log | grep denied |cut -f 10 -d ’ '| sed ‘s/.{7}$//’ | sort | uniq | sort -nr | more
sudo cat /var/log/secure | grep “Failed password” | grep -E -o “([0-9]{1,3}[.]){3}[0-9]{1,3}” | cut -f 11 -d ’ '| sort | uniq | tr ‘\n’ ’ ’ | sort -nr
sudo cat /var/log/secure | grep “authentication failures” |cut -f 16 -d ’ ’ |cut -f 2 -d = | sort | uniq | tr ‘\n’ ’ ’ | sort -nr

This one will pull the IPs for the endpoints that registered to your server

sudo cat /var/log/asterisk/full | grep “@” | grep -E -o “([0-9]{1,3}[.]){3}[0-9]{1,3}” | sort | uniq | sort -nr

This is how I put them to work. If there is an unusual activity I get an email and I act on it.

[HOW-TO] Monitor and Set Email Alert For Unauthorized Access to FreePBX (Centos) Server

dicko mentioned in a post that the access_log has the information of who access what and when. Looking around I was able to write this script that will do the purpose of monitoring users’ access by IP. In my situation, I have limited IP that I access the FreePBX from. Hence, this script should do it for me. #!/bin/bash email="[email protected]" myips=("IP1" "IP2" "IP3" "IP4") accessip=`sudo cat /var/log/httpd/access_log | awk '{print $1}' | sort -n | uniq | sort -nr | head -20` deniedip=`sudo…

logwatch is another way to look at who accessed your server and from where

Logwatch

[VoIPTek]

While we are getting a little off-topic with this post, I wanted to share my approach to the notification aspect since it was a part of the conversation here.

I use this from within .bashrc and I populate the file ssh_known_ips with you guessed it, the IP’s we know about, in order to reduce the amount of email. The server name will get auto-populated.

SSERVER=hostname | perl -p -e 's/(.*?)\..*/$1/'
SUBJECT=“Root Login Alert: $SSERVER”
NOTIFY_EMAIL="[email protected]"

[ -f /ibin/conf/ssh_known_ips ] && source /ibin/conf/ssh_known_ips

loginip=echo $SSH_CLIENT | awk '{print $1}'
authorized=false;
function message {
echo “${msgheader}hostname”
echo “----------------------------------------------”
echo “Login IP: $loginip”
echo "Login User: whoami"
echo "Date-Time: date"
echo “----------------------------------------------”
}
for ip in $KNOWN_IPS; do
if [ “$loginip” == “$ip” ]; then
authorized=true;
msgheader=“Authorized Login to Server:”
fi
done

if [ ! “$authorized” == “true” ];then
msgheader=“Unauthorized Login to Server:”
message|mail -s “$SUBJECT” “$NOTIFY_EMAIL” #Unauthorized
#person logged in…
fi

My IP file format is like this:

KNOWN_IPS="
38.38.38.1 #-- My House
48.48.48.2 #-- Server XYZ
50.51.52.53 #-- Some other IP
"