ALERT FreePBX ARI Exploit

[wardmundy]

Reposted from FreePBX Forum:



You can check whether ports 8088 and 8089 are exposed on your server like this:

iptables -nL | grep 8088
iptables -nL | grep 8089

If you get an ACCEPT match, post your version of Incredible PBX and the operating system platform and Asterisk version, and we will push out a fix. There shouldn't be ANY exposure on ANY Incredible PBX platform.

 

[dicko]

And now apparently personally involving Lorne.

I would comment that any penetration that might get root access in any way (buffer overrun perhaps, maybe 8088 or 8089 cos they are 'mini webservers' or unprotected 443) , might have brief opportunistic access to mysql if there was no password needed to the 'root' account at 127.0.0.1, none in some distros but maybe passw0rd is also 'well known'

 

[mainenotarynet]

Checked -- iptables and 8089 came up accept

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8089 ctstate NEW,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8089

Incredible PBX 2021.01-PUB for Debian 10.13 Buster
Asterisk 18.13.0
Incredible GUI 15.0.22.25 (this is what PBX Status shows) -- But the Dashboard on Browser shows 15.0.29
FreePBX version -- I cannot find this in GUI or SSH maybe what I gave you here is enough.

The IP tables are the ones that came with IncrediblePBX 2021 I did bot add these (other stuff yes but not 8088 (not present) or 8089

 

[Samot]

I know this thread is titled ARI exploit but the bottom line is that ARI, itself, has not been exploited. There is still some debate on what the actual cause is such as a shared password among systems or something else but ARI is not the actual cause of the exploit. At all.

The fact that the bad actor may have gotten the ARI password is due to the fact that FreePBX stores that password, in plain text, in .conf files they use. Because ARI in Asterisk when using the default crypt method for passwords stores the passwords in ari.conf in a crypted hash. There's no need to have the plain text version sitting around on the machine.

The reality is, a small amount of users got compromised and the bad actor was using ARI to send fraud calls. In order for them to do that they need the ARI username and password. ARI won't accept connections without it, it's been tested and confirmed already. In fact, one of the first reporters of this issue is now having his system torn apart from the inside out.

It also seems the bad actors are watching what is happening as the hackers are dropping files named lgeatz.php in systems and mentioning the name in the code.

 

[billsimon]

ARI, itself, has not been exploited

I know you really want to make this assertion but it can't be confirmed yet.

On the FreePBX community thread there is no doubt that at least some of the folks who are dealing with problems have had several layers of malware put on their systems and the ARI issues are just symptoms of that. My guess is they were hit in the past during e.g. the restapps vulnerability and the attacker(s) kept record of the credentials and started using them again recently.

BUT, there are other cases where what appear to be clean systems are getting entered through ARI and there is no other evidence of a point of entry. Could it be a separate breach that is yet undetected, sure. Can you say with certainty that it's not ARI, no.

 

[Samot]

I know you really want to make this assertion but it can't be confirmed yet.

The Asterisk team already investigated, unable to find issues or replicate the claim. Lorne said this wasn't an Asterisk issue. No one using just Asterisk doing pure ARI/Statis (ie dialplanless) deployments are reporting this issue.

Have you been able to replicate an ARI session with no creds? I haven't been able to.

 

[progs_00]

Checked -- iptables and 8089 came up accept

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8089 ctstate NEW,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8089

Incredible PBX 2021.01-PUB for Debian 10.13 Buster
Asterisk 18.13.0
Incredible GUI 15.0.22.25 (this is what PBX Status shows) -- But the Dashboard on Browser shows 15.0.29
FreePBX version -- I cannot find this in GUI or SSH maybe what I gave you here is enough.

The IP tables are the ones that came with IncrediblePBX 2021 I did bot add these (other stuff yes but not 8088 (not present) or 8089

Incredible PBX 2021.01 for Debian 10.8 Buster with Asterisk 18.16 and Incredible GUI 15.0.22.25 here so very similar to yours @mainenotarynet
Run the iptables grep and nothing came up
To my iptables the only thing I've done is rem out the sip providers included as I don't use any of them.

 

[kenn10]

Incredible PBX 2021.01 for Debian 10.8 Buster with Asterisk 18.16 and Incredible GUI 15.0.22.25 here so very similar to yours @mainenotarynet
Run the iptables grep and nothing came up
To my iptables the only thing I've done is rem out the sip providers included as I don't use any of them.

I believe the difference is that @mainenotarynet is running the Public version which opens up a lot of things. I suspect anyone who has used the "Go Public" script has those ports open. @wardmundy will need to comment if that is the case.

 

[wardmundy]

Checked -- iptables and 8089 came up accept

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8089 ctstate NEW,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8089

Incredible PBX 2021.01-PUB for Debian 10.13 Buster
Asterisk 18.13.0
Incredible GUI 15.0.22.25 (this is what PBX Status shows) -- But the Dashboard on Browser shows 15.0.29
FreePBX version -- I cannot find this in GUI or SSH maybe what I gave you here is enough.

The IP tables are the ones that came with IncrediblePBX 2021 I did bot add these (other stuff yes but not 8088 (not present) or 8089

Also @progs_00:

All I can think of is these must be very old servers. We have over 3 dozen honeypots running Debian 10 and none of them had these lines in their IPtables rules. Please email me a copy of your rules.v4 file BEFORE you apply the following patch: send it to support [at] incrediblepbx.com. We will work up a patch. Thanks.

Edit /etc/iptables/rules.v4 and find BOTH lines by searching for 8089. Change ACCEPT to DROP. Save file and then iptables-restart.

 

[thejames]

From what I have seen these are all pbxact servers. you can likely edit your /etc/asterisk/http.conf and make sure
bindaddr=127.0.0.1 rather than 0.0.0.0 with any luck that won't break anything unless you actually have something accessing from the outside. If you have a comprimised system I would probably do a clean install. I haven't seen a compromised system so I am unsure of the cleanup efforts.

 

[wardmundy]

Thanks, @thejames. 127.0.0.1 is the bindaddr in /etc/asterisk/http_additional.conf on all Incredible PBX platforms so we should be OK.

 

[mainenotarynet]

The 8089 was commented out in rules.v4

The ones that are used are in /usr/local/sbin/iptables custom -- in a section I titled #My Custom Stuff

I do ham radio and have 8100 for a special proxy for a program but do not know why I added 8089 - so maybe I can just comment those two lines out with no harm.

 

[progs_00]

Also @progs_00:

All I can think of is these must be very old servers. We have over 3 dozen honeypots running Debina 10 and none of them had these lines in their IPtables rules. Please email me a copy of your rules.v4 file BEFORE you apply the following patch: send it to support [at] incrediblepbx.com. We will work up a patch. Thanks.

Edit /etc/iptables/rules.v4 and find BOTH lines by searching for 8089. Change ACCEPT to DROP. Save file and then iptables-restart.

No issues for me Ward. The command came back negative so my system is unaffected and from what I see the ports are closed by default so I guess no need to worry thank God

 

[wardmundy]

The 8089 was commented out in rules.v4

The ones that are used are in /usr/local/sbin/iptables custom -- in a section I titled #My Custom Stuff

I do ham radio and have 8100 for a special proxy for a program but do not know why I added 8089 - so maybe I can just comment those two lines out with no harm.

Thanks. I've confirmed that those ports are not opened in the default PUBLIC setup.

 

[redstonemason]

Seems I am forever a Newbie...

This thread is very comprehensive. Glad I found it.
Took the precautions of changing the FPBX_ARI_USER and FPBX_ARI_PASSWORD.

But got...
fwconsole reload Reload Started In Cron.class.php line 281: proc_open(/tmp/cron.error): failed to open stream: Permission denied reload [--json] [--dry-run] [--skip-registry-checks] [--dont-reload-asterisk]

 

[wardmundy]

Seems I am forever a Newbie...

This thread is very comprehensive. Glad I found it.
Took the precautions of changing the FPBX_ARI_USER and FPBX_ARI_PASSWORD.

But got...
fwconsole reload Reload Started In Cron.class.php line 281: proc_open(/tmp/cron.error): failed to open stream: Permission denied reload [--json] [--dry-run] [--skip-registry-checks] [--dont-reload-asterisk]

rm /tmp/*
fwconsole reload

 

[redstonemason]

Interesting. The cron.error file in /tmp owned by asterisk:asterisk. You are a wizard!

 

[wardmundy]

Lots more to read unfortunately. Probably not the best time to own a PBXact server.

Inactive Stasis app 'hey' missed message

I’m seeing this on two of my servers after the latest updates to core and framework. Oddly though I don’t see this on other servers. The two in question are both running Zulu, Sangoma connect and phone apps. These are also the only ones running VPN for remote phones. I do have a couple...

community.freepbx.org

 

[krzykat]

what a S*&show read. I think the best thing to do is to get things secure. Then find out why. Then figure out why it won't happen again. But to mess around with "this can't happen" when several people HAVE had it happen doesn't help anything. Call it user error all day long if you want, but CLOSE that hole. If people end up with one of those 10K phone bills and they are successful in pointing blame to Sangoma .... not good.

 

[billsimon]

Lots more to read unfortunately. Probably not the best time to own a PBXact server.

There are so many different things going on in that thread.

There seem to be some deployments in that thread where the server was had several times over and the malware-planters are using ARI for mischief. They were probably broken during the restapps exploit from 2021 or even further back.

Some, including a few servers I personally investigated for an associate, seem clean of malware and the ARI abuse is the only symptom. I'm suspicious though that the ARI credentials were leaked some other way.

Still others have a shared ARI credential of unknown origin. Maybe they got them from a cloning operation. This is where PBXact might come in to play, since these are often appliances with, I assume, cloned hard drives.

What's frustrating about this is that there is a legitimate reason to open the asterisk HTTP server, namely for webrtc clients, and documentation assured people that this was safe to do. A better practice would be to have ARI and webrtc listening on different ports since they are completely different functions/purposes.