Yeah, and Linode said to have handled the problem , i see how they handled it 
Write to their abuse mail each one of you please , and if you can ( i’ve tried without success ) set up an honeypot to figure out how it’s happening, nothing excludes at the moment that even SIP may be used to trigger some unknown RCE Exploit
Also because some of us had these ports closed to start with ( me included ), i’ve found them open on the firewall only after the attack
Probably some exploit, we need to set up an honeypot to figure how it is being exploited, i tried to recheck the code but with a quick look didn’t see anything obvious that can be used to exploit
I do, in my case was a single number, a mobile phone in central africa, if you need the complete number i could recover it from the logs i saved of the attack
I too have seen this issue on 2 PBX’s over the weekend. It appears I had inadvertently exposed Port 8089 (Encrypted WebRTC for UCP), so I’m assuming this is how an external connection was made.
It should be mentioned that the Sangoma Wiki (Sangoma Documentation) describes Port 8089 as;
Safe to open this up to untrusted networks as the traffic is encrypted with SSL and requires username and password authentication.
As with others in this thread, I don’t have any Users defined with the ‘Asterisk REST Interface Users’ module & only the default [freepbxuser] defined within ‘/etc/asterisk/ari_additional.conf’ with an encrypted password. Is this a publicly known PW that every FreePBX installation uses by default ?
The following commands seem to expose the malicious activity (Two connections, both attempted to dial international numbers, but luckily these are blocked by my SIP Trunk provider & they gave me a heads-up about the failed dial-out attempts);
Here’s an extract of the malicious activity during one of the above connections;
I’ve now blocked Port 8089 externally, but wasn’t sure how to remove/delete the offending ARI app (hey) via CLI, but a System Reboot seems to do it.
The users of these PBX’s require the use of the Sangoma Connect Apps while roaming, I hope this issue isn’t exploitable through one of the Ports required for those Apps to work externally.
I also hope this info will help others to determine if they have had a similar issue.
Hello Lorne,
It seems that this attack has been reproduced on serveral Freepbx systems. Has Sangoma any clue about how an external attacker can log in with ARI credentials? There will be a security patch to solve this?
Best Regards,
I am curious too if Sangoma already found something. The password for the ari user freepbxuser is in plain text in /etc/amportal.conf but I do not think the attackers were able to read this.
I think Sangoma should clarify whether the situations described in this topic are caused by;
I also think that the official Sangoma WiKi should NOT describe port 8089 (Encrypted WebRTC for UCP) as ‘Safe to open this up to untrusted networks as the traffic is encrypted with SSL and requires username and password authentication’ if any of the above potential causes are true.
I have yet been able to find any systems I have that are running this. So far I’ve checked systems behind external firewalls/NAT, so not running FreePBX firewall. I’ve also checked ones sitting in the cloud only running the FreePBX firewall. Nothing showing any ARI apps or activity like this.
Do those systems expose any WebRTC ports (8088 or 8089) to the Internet & if so, have you taken any additional measures to protect against this potential issue through WebRTC ?
No and even if they did, nothing is ever open to the public. Only specific IPs are allowed access like that into the system. I also don’t use WebRTC.
Outside of that, has anyone gone through either the Asterisk CLI or the shell CLI history? In the Asterisk CLI history is there by change ari mkpasswd <some password>? From the shell CLI it would be mkpasswd -m sha-512 now the only thing about that is, mkpasswd isn’t installed on distros by default. So if you can run/find that command on your system someone installed it.
These would generate a new encrypted password that could be updated in the air_additional.conf which can be saved and reloaded without applying configs, etc.
ok, then I guess that explains why you haven’t seen this issue (if the ports have never been exposed publicly).
The systems I referred to (along with others in this thread) seem to have had one of those ports exposed (Not ideal, but there it is), with only the default [freepbxuser] defined within ‘/etc/asterisk/ari_additional.conf’. So my suggested questions to Sangoma above remain (about if/what credentials might have been known/used by the outside party).
Is the Asterisk CLI history (or ARI command history) you’re referring to, somewhere other than the log info I exposed earlier in this thread (ie. contained in ‘var/log/asterisk/full*’), if not, then I’ve shown those entries during an outside connection & no such command was visible there - If yes, then please share with us where/how to see that ?
I guess I personally, am trying to establish if this issue relates to the built-in [freepbxuser] credentials being the same for every installation & therefore known publicly. If so, could those credentials be changed without breaking something else within Asterisk/FreePBX. This would allow that account to be made more secure (by not having a publicly known password) AND potentially allow anyone that wanted to expose WebRTC publicly (for whatever reason) to do so without a bad actor exploiting the known built-in account.
You get in the Asterisk CLI and start hitting the up arrow to go through commands in the history of the CLI. The commands you type don’t get dumped into the full log.
I get that but there is nothing in a FreePBX installation that has a plain text version of said password exposed anywhere. There is nothing in the GUI that shows the default ARI user (freepbxuser) nor does it show what the password is. In fact, when using the crypt method for ARI password you never put the plain text version of the password anywhere. You either generate it via the ARI commands in the Asterisk CLI or you generate it with the mkpasswd command I gave from the system CLI.
I don’t even know what the default freepbxuser password is for my systems. If I want to use ARI I would need to create a user just for it so I knew what the password was. Or I would have to modify the existing password.
But what I’m trying to understand here is, why was the firewall opened for these ports and why where they pointing/NATing to the FreePBX system? Also, why where these ports not only open but open to the entire world? It makes me wonder what else was opened and what other access they could have had.
I don’t think anyone is debating whether it’s a good idea to intentionally have any of these ports open to the public, despite the fact that Sangoma’s own documentation says 8089 is ‘Safe to open to untrusted networks’. There’s nothing to understand about that, it simply was the case in these instances & focusing on that point is avoiding the questions being asked.
Regardless of whether ports are open, I think its important to try & understand how these are exploited, rather than just being blindly told they shouldn’t be used in a certain way (& not understanding the how/why).
Also FYI, if you want to know what is the password for your built-in [freepbxuser] user account, Stevek1 above has suggested its visible in plain text within /etc/amportal.conf - I’m not entirely sure if/whether this is same as the encrypted one in ‘/etc/asterisk/ari_additional.conf’, but it looks like it could be.
Focusing on that has not avoided the questions being asked. Do you know what the default password is for the freepbuser ARI account? If you wanted to use ARI right now could you use that account and know the password? It’s not documented anywhere. Even when I generate the same password on two different systems, I get completely different crypt hashes for them.
@lgaetz should answer if there is a generic password being used. That is an answer I would like to know as well. Oh wait, while I was typing this I saw the edit to the post I’m replying to. So I checked a few machines. Yes, the ari password is in /etc/amportal.conf but not single system uses the same default ARI password.
Sure, I totally agree. This is why I said I was curious as to what else might have been opened for the system. The exploit, as we will call it, could very well been someone getting into the system and making changes at their whim. Much like the thnkyou exploit did. In that case, the bad actor found their way into the system and added custom dialplan along with other scripts that made calls home to keep them with access and give them the ability to inject things.
Now we know the ARI password isn’t the same default password on every system. The default ARI password is in plain text in the /etc/amportal.conf file. That password is not a default or same password on different installs.
So in order for someone to do the ARI statis app like this, they would need access to ARI on the system (port 8088 being open does that) and they would need to know the default password for the freepbxuser account. A password that isn’t the same on all systems (unless you clone from a master like one person did) that would require someone to gleam /etc/amportal.conf in order to get it.
It would be the plain text password that was used to generate the crypt password via mkpasswd. Again, these are different on each install. Whatever your ARI default password is, it isn’t the default ARI password on another system.
Right now, based on the data I’ve seen, this exploit is much like thnkyou in the fact the bad actor needed access to the system in order to facilitate their exploit. Either that or they are running password crackers that cracked the crypt’d passwords, a possibility. However, right now, I would have to question if they got access due to poor security measures.
‘I think’ we’re in agreement that we still don’t know if ARI credentials were used & if they were, how they were obtained (as the only account that appears to exist for most people here was the built-in [freepbxuser], which may or may not use a common password across installations).
I think you’re also suggesting that if ports 8088 and/or 8089 were exposed, so might others that were used to obtain access/gain ARI credentials. I see why you might make this conclusion, but we don’t actually know that was the case any in the instances revealed in this thread.
As I have pointed out, every installation I’ve checked has a different default password for the ARI account freepbxuser.
Yes. Exactly. This is why I’m asking questions about firewalls and what was actually exposed. This could be a case of poor security practices. This could also be a bug/exploit in FreePBX. I don’t know but I’m not standing on one side of the other until actual data and evidence can be shown to prove it one way or the other.
Right now based on what has been provided, poor security practices are right up there on the list of “how did this happen”.
I have another suggestion that can be sussed out pretty easily. Many of my machines are upgrades from way back in the freepbx 12 days. Is is possible that the ARI password from back in the day is still active on these machines?
Sure. That still doesn’t mean it wasn’t a unique password to your install.
FreePBX Project Lead here
I’m convalescing from some non-serious surgery, so not fully tuned in these days. Here are the facts as I currently know them, am I missing anything:
A malicious user with access the the Asterisk http/https service and ARI user credentials can create an ARI app remotely. An ARI user is generated with a very long, unique, random password on FreePBX system setup. It’s too complex a password to brute force on multiple independent systems in the same time frame which leads me to suspect one of two things:
I can’t think of a third possibility but happy to entertain discussion on that point.
After doing a review, I’m aware of a single support ticket in Sangoma support that now in retrospect was likely the issue reported here. It was before the discussion started on the forum, and no steps were taken to investigate in any depth.
The Firewall Module in it’s default configuration blocks access to the Asterisk http/https services and most other services. I have some honeypots running with no firewall up and so far nothing. We have nothing in engineering to touch showing this issue.
I disagree. Way back then it was a generic user with the same generic password across all systems. I believe this didn’t change until version 13. I could be wrong though and thinking of another generic password that was used back then. Its too early and no coffee and a dozen other fires to deal with.
