Exploit script steals SIP information and configs:
ls -la
ps -aux --forest
asterisk -rx ‘core show channels’
asterisk -rx ‘sip show peers’
cat /etc/elastix.conf
cat /etc/asterisk/sip_additional.conf
cat /etc/asterisk/extensions_custom.conf
cat /etc/amportal.conf
So after clean you need to change all passwords in internal and external SIP accounts
In my case exploit modify some ajax.php, config.php, .htaccess and create self scripts.
So I deleted them and reinstall modules for original scripts versions.
getting failed to authenticate as ‘admin’ in the asterisk logs after changing the asterisk manager password in Settings > advanced settings
UPDATE: had to change the AMPMGRPASS entry in /etc/asterisk/extensions_additional.conf to match the setting that was changed in the UI Advanced settings ‘manager password’
Thanks for this info. I’m new to freepbx, and only somewhat familiar with debugging this sort of thing. I think I’m fine, here, there is no evidence as far as these tips go.
My question:
I’ve looked through the wiki and cve, and these forums, but I can’t quite understand how this exploit might reach the system.
I don’t have any external users, I’m set up at the moment with a hardware server natted behind a firewall, with only port 80 TCP for letsencrypt and udp 10000:20000 forwarded to the server, and responsive firewall enabled for let’s encrypt, and with networks and interfaces tight, and intrusion dectection enabled on the server
Would this setup prevent the vector for this particular attack?
Meaning, you have the GUI running on a different port?
Then I believe you should be good. The exploit is in RestApps. If you can browse to pbx.domain/restapps then you are/were at risk.
when I browse to pbx.domain/restapps on a “cleaned” system I get this…
{“application_name”:null,“application_display”:null,“page_name”:null,“type”:“display”,“exitPath”:null,“layout”:,“action”:,“error”:[{“reason”:400,“display”:“Phone Apps module not licensed.”}]}
if I use pbx.domain/RestApps I get a 404 not found
there seems to be no difference in machines that were compromised or not. Although all have long had the restapps updated to the patched version…
My response was to @cleftstone’s post, to which I assume that he has port 80 set only for LE verification (can be set in System Admin)
I am not sure if that exposes RestApps. If it doesn’t then he’s good.
latest fun… Have one system with all D series phones using OpenVPN. After cleaning out the hacked files the phones will not connect using OpenVPN. Just sit there contacting sip:[email protected]…
also, anytime I make a change now and hit the apply button in the UI, it pops up an error message
There was an error during reload: Unknown Error. Please Run: fwconsole reload --verbose
if I run the fwconsole reload it does apply the settings. which module needs to be re-installed to fix this?
UPDATE: Deleted all the profiles under the system admin > VPN Server and then enabled VPN in user manager again to re-create them. Apply button issue went away. VPN Still not working with phones however.
I was able to get the Phone’s connecting via OpenVPN again. I had to turn off the OpenVPN server, delete all the existing profiles in the OpenVPN server. Then go into user manager, click to edit every user individually, then simply save and apply without making any changes.
Then turn on the VPN server again and ensure that “routing” was off and “auto renew” was off.
Then I went into each VPN profile and hard coded the IP’s. (Prob not necessary but it’s always worked better for me this way).
then rebuilt the phone configs in EPM
Thanks, for the help. I’m almost totally sure I’m ok.
I have gui/admin forced to port 443, only let’s encrypt on port 80, with the responsive fw and responsive letsencrypt rules set, which if I understand correctly should only allow writing to .well-known while credential renewals are underway.
I have force port 4443 in sysadmin portmgnt for rest apps
I’m getting “403 forbidden” on restapps from outside the firewall on http://pbx.xxx.xxx/restapps, and forbidden from inside with http, and {“application_name”:null,“application_display”:null,“page_name”:null,“type”:“display”,“exitPath”:null,“layout”:[],“action”:[],“error”:[{“reason”:400,“display”:“Phone Apps module not licensed.”}]} from inside on https.
that’s the biotch of this whole situation, have to change all the extension passwords, system passwords, root passwords it’s been a fun 24+ hours so far…
For those who need it, this pretty much cleans it all up and blocks connection to the known IP. Copy and paste the below into your command line in an ssh session. I’d also suggest changing roots password and then changing all extension passwords and web interface account passwords as they’ve collected all that info it looks like.
My guess is that FreePBX distros will fight 'tooth and nails ’ your
iptables -A OUTPUT -d 37.49.230.74 -j DROP
/sbin/service iptables save
But I will guarantee the next vector will not be from 37.49.230.74
whois -h v4.whois.cymru.com ' -v -f 37.49.230.74'
gives the ASN of the ‘careless provider’. “ABC Consultancy”
If you go through your logs you will see these SQUITTER/ABC SQUATTERS have been probing FreePBX deployments for months, likely yours included (FYI, the real blackhats are not Dutch, nor Icelandic )
I understand
) , and likely have long memories.