Sure, you can disagree. With that I would put another question on the table, which is: Are those impacted using pre-v13 installs that have been upgraded over time?
I’m asking this seriously. Why isn’t “you had an insecure setup that let them walk all over your machine” not in that list? I’m down for accepting that 1 or 2 can be possible but 3 is also entirely possible.
I guess my question wasn’t clear but you hit the nail on the head. 3 of the machines I have hit were exactly that scenario. Built in the version 12 days. A couple of others that do not have the two ports open were not. Another dozen or so that are also using webrtc that were built from version 14 forward have not been hit. This is what lead me down this path. So of the 20 something systems I run 3 have been hit and of those all have a starting point of 12 or before and had the ports in question open.
Are all your systems that are pre-v13 showing to have the same ARI password? If so that means they hit you with a 9 yo password that isn’t used anymore (if there was a common password back in v12). Pretty impressive I would say.
Here’s what I can see, we have 10 users reporting the same issue. Yes, a lot of machines are hit but they are all under the prevue of these 10 users. Of those 10, 2 or 3 admitted to having open firewalls. Others have not commented. You have pre-v13 boxes that might have a shared password. Others have reported their systems have unique passwords. Basically, we have a bunch of data points that make correlation a bit tough out side of “we all got hacked”.
I mean we are now at the point where we need real, unbiased information from each of you so we can try and get some sort of correlation on what the issue could be.
Also, this being an Asterisk bug is on the low side of possibilities as nothing has been found or reported in regards to this with pure Asterisk users. A good chunk of those users do things via ARI exclusively in Asterisk.
Of the three impacted systems, compare the password line in the file
/etc/asterisk/ari_additional.conf
I think you’ll find that the passwords are unique for each, but need confirmation of that. The Asterisk ARI service is fairly new, I don’t believe there was any support for it in FreePBX 12.
In regards to being a FreePBX exploit, a totally possible scenario is that they exploited the GUI and were able to inject code that let them parse /etc/amportal.conf allowing them to get the ARI password. That would also mean they could have any data from /etc/amportal.conf.
Any exploit against FreePBX would require access to read /etc/amportal.conf in some manner.
Also, as to why no one using pure Asterisk has reported this type of issue could be due to the fact that you would need to use plaintext mode in ARI for there to be a plaintext version of the password in the ari.conf file. Nothing in Asterisk requires the plaintext version of the ARI password to be stored anywhere when using crypt auth method. The need to store the plaintext version is a FreePBX need.
I tried that. When I run ari mkpasswd 123456 (or any same password) the crypt hash is generated differently. You can’t compare the hash and say “Oh same hash, same password”
In response to the question about system versions, I observed this issue on 2 completely separate PBXact systems last weekend, both had 8089 exposed to the internet (not 8088).
One of these systems was originally v14, then upgraded to v15 some time ago - the other has only ever been v15. I have shown the log entries relating to the initial connection on the v15 only system above.
Rightly or wrongly, 8089 is listed by Sangoma as ‘Safe to open this up to untrusted networks as the traffic is encrypted with SSL and requires username and password authentication’ & so was enabled in-line with this statement in mind (WebRTC is not actually used & so it’s port didn’t need to be open, however, this was a hangover from the initial setup which used the Sangoma documentation for port exposure guidance). These systems have been setup this way for a couple of years & have not been compromised like this previously.
Both these system are NAT’d behind Internet gateways & there were NO forwarded ports to either system that Sangoma describe as ‘Not recommended to open up to untrusted networks’. Both PBX Firewalls were also running with Responsive Firewall/Intrusion detection enabled.
If there’s a way to know for sure what port was used to gain connection & if/what credentials were used, I’m interested to expose & learn from that.
Ok they are all different. Next theory… 
Is this because a bug was found, or extra caution being added? It’s linked to the FREEI-5600 issue which is not available publicly.
Follow up question, why is this needed here when the installer for the arimanager module does the same thing?
It was a flawed theory. Asterisk won’t generate the same hash for the same exact password on two different machines. I can’t make that happen. Here’s the same command run, in a row, on the same system.
hvs01-west*CLI> ari mkpasswd 123456
; Copy the following two lines into ari.conf
password_format = crypt
password = $6$N9R85O8MzomiAWwo$6I2IFUlCAHDxru8gPlBmQa367MO8df89Mwv5LAr1FBPYPk/jcr/hzFmr4w7FDa0awEfvuo/6wT1tECz6Wg0Da.
hvs01-west*CLI> ari mkpasswd 123456
; Copy the following two lines into ari.conf
password_format = crypt
password = $6$PVemcMugmXd/sZSF$jW/f7JZqO7CEj.RzCZHM3JkNouZEwhuiemuqPMQ68yx.OyNXqHqio47BW7YFWcwfICGoHdQXdwpuL1xC3NgeP.
It didn’t generate the same hash for the same password.
This method should show the ARI password unencrypted which will allow you to compare across systems. I’m not seeing any two that match.
fwconsole setting FPBX_ARI_PASSWORD
I’ve just ran that on the two v15 PBXact systems that were compromised & they seem to be THE SAME.
Starting ‘7ff’ and ending ‘2bb’
I’ve also ran it on a v15 FreePBX server that is only internal for testing (& not compromised), it’s different.
Did you deploy them from clones / cloud images? (sorry if that seems like an obvious question)
My guess, because this account is not exposed to the users (admin GUI) and not accessible to user management. The process in arimanager will add a new user but it also stores information about said user in the database. The default freepbxuser doesn’t exist there.
One was originally a pre-installed v14 UC25 appliance - I subsequently upgraded it to v15 along the way.
The other was freshly installed from ISO as v15 - IGNORE THAT, the 2nd one was a pre-installed v14 UC40 appliance that I also upgraded to v15. The 2 systems were purchased over a year apart, but I guess Sangoma might use a common image to factory pre-install their appliances.
As both systems that were compromised are a match, maybe the attacker changed them to this as part of the process to gain control ? - Just thinking out loud, dicko has seen duplicates (below), so not just me then.
I can confirm the same password seen on a couple chosen at random, (not all)
@dicko - Do your matching ones start/end with the same characters as mine ? (I’m assuming we’re not opening the door to anything by revealing those bits)
Without sharing any plain ARI passwords publicly, can anyone who has found two or more systems using the same ARI password, can you please email it to me at “lgaetz” at “sangoma.com”. This is something we can work with.
Yep starts and stops just as that, but just one confirmed (the other was a clone of it), built to the wiki Debian 8 or 9 recipe plus some personal touches.
uname -a Linux Myurl.com 4.9.0-18-amd64 #1 SMP Debian 4.9.303-1 (2022-03-07) x86_64 GNU/Linux
Probable built 5 years ago or more, so no Sangoma firewall and 8089/8088 miniserver running but never sees traffic.
Hi Lorne, just to clarify, are you asking for the entire ARI password to be emailed to you with a count of how many systems share it ?