Hi all,
A few days ago I noticed strange entries in CDR:
This was making calls through an external app - AppDial2
Unfortunately Asterisk REST Interface was enabled even though I don’t use it.
I can’t understand just one thing, how did an external application gain access without using a login and password? Or am I missing something?
I also went through a similar post in detail - App2 to Dial - Hacked?
Maybe someone will have ideas?
Thanks!
Question to the both of you, is your firewall opened? How did random people even get connected to your PBX to do this?
This response is like “why didn’t you lock the door?” when someone says they were robbed… not really a helpful question.
I’m also a little concerned with responses (not specifically yours) in other threads that say that the ultimate answer is a firewall.
OK, you should have a firewall, but shouldn’t we also be fixing these exploitable bugs in FreePBX and/or Asterisk?
I am kind of betting on the instances in this thread being old exploits that have since been fixed. What versions are you running, @maxyca and @snaggy ? (fwconsole ma list)
Actually it is. Because if there is no firewall in place, right now, they are exposed to even more trouble.
Well, who said this was a bug or an exploit? This goes back to “do you have a firewall in place” because if the answer, again, is no then that means the bad actor could have actually gotten into the system another way and exposed this. Much like how the age old “thankyou” attack happened. They got into an open system and modified the extensions_custom.conf file.
I mean on every system I’ve looked at, the ARI (which is how Statis is being called) password is around a 64 character password. It’s not like it was set to 123456.
I asked if there is an active firewall because that actually matters on how this could have happened. You are just assuming a bug did this without any sort of data to back up your claim.
The only assumption I’m making is that they did not set their passwords to 12345 or password.
A system with passwords is not “open” just because it doesn’t have a firewall.
If there are non-trivial passwords and someone manages to get through then it’s a bug.
accountcodepreserve | 16.0.0.1 | Enabled | GPLv2 | Sangoma |
| adv_recovery | 16.0.41 | Enabled | Commercial | Sangoma |
| allowlist | 16.0.2 | Enabled | GPLv3+ | Sangoma |
| amd | 16.0.3 | Enabled | GPLv3+ | Sangoma |
| announcement | 16.0.6 | Enabled | GPLv3+ | Sangoma |
| api | 16.0.11 | Enabled | AGPLv3+ | Sangoma |
| areminder | 16.0.15 | Enabled | Commercial | Sangoma |
| arimanager | 16.0.5 | Enabled | GPLv3+ | Sangoma |
| asterisk-cli | 16.0.8 | Enabled | GPLv3+ | Sangoma |
| asteriskinfo | 16.0.5 | Enabled | GPLv3+ | Sangoma |
| backup | 16.0.62.7 | Enabled | GPLv3+ | Sangoma |
| blacklist | 16.0.15 | Enabled | GPLv3+ | Sangoma |
| broadcast | 16.0.18 | Enabled | Commercial | Sangoma |
| builtin | | Enabled | | Unsigned |
| bulkhandler | 16.0.15 | Enabled | GPLv3+ | Sangoma |
| calendar | 16.0.13 | Enabled | GPLv3+ | Sangoma |
| callaccounting | 16.0.10 | Enabled | Commercial+ | Sangoma |
| callback | 16.0.4 | Enabled | GPLv3+ | Sangoma |
| callerid | 16.0.5 | Enabled | Commercial | Sangoma |
| callforward | 16.0.5 | Enabled | AGPLv3+ | Sangoma |
| calllimit | 16.0.6 | Enabled | Commercial | Sangoma |
| callrecording | 16.0.19 | Enabled | AGPLv3+ | Sangoma |
| callwaiting | 16.0.5 | Enabled | GPLv3+ | Sangoma |
| cdr | 16.0.30 | Enabled | GPLv3+ | Sangoma |
| cel | 16.0.13 | Enabled | GPLv3+ | Sangoma |
| certman | 16.0.22 | Enabled | AGPLv3+ | Sangoma |
| cidlookup | 16.0.12 | Enabled | GPLv3+ | Sangoma |
| conferences | 16.0.8 | Enabled | GPLv3+ | Sangoma |
| conferencespro | 16.0.9 | Enabled | Commercial | Sangoma |
| configedit | 16.0.5 | Enabled | AGPLv3+ | Sangoma |
| contactmanager | 16.0.18.17 | Enabled | GPLv3+ | Sangoma |
| core | 16.0.68.2 | Enabled | GPLv3+ | Sangoma |
| cos | 16.0.7 | Enabled | Commercial | Sangoma |
| customappsreg | 16.0.5 | Enabled | GPLv3+ | Sangoma |
| customcontexts | 13.0.3.2 | Enabled | GPLv2+ | Sangoma |
| cxpanel | 16.0.2 | Enabled | GPLv3 | Sangoma |
| dahdiconfig | 16.0.8 | Enabled | GPLv3+ | Sangoma |
| dashboard | 16.0.15 | Enabled | AGPLv3+ | Sangoma |
| daynight | 16.0.3 | Enabled | GPLv3+ | Sangoma |
| dictate | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| directory | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| disa | 16.0.4 | Enabled | AGPLv3+ | Sangoma |
| donotdisturb | 16.0.3 | Enabled | GPLv3+ | Sangoma |
| dynroute | 16.0.4 | Enabled | GPLv3+ | Sangoma |
| endpoint | 16.0.73 | Enabled | Commercial | Sangoma |
| extensionroutes | 16.0.7 | Enabled | Commercial | Sangoma |
| extensionsettings | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| fax | 16.0.10 | Enabled | GPLv3+ | Sangoma |
| faxpro | 16.0.10 | Enabled | Commercial | Sangoma |
| featurecodeadmin | 16.0.5 | Enabled | GPLv3+ | Sangoma |
| filestore | 16.0.14 | Enabled | AGPLv3 | Sangoma |
| findmefollow | 16.0.19 | Enabled | GPLv3+ | Sangoma |
| firewall | 16.0.57.4 | Enabled | AGPLv3+ | Sangoma |
| framework | 16.0.30 | Enabled | GPLv2+ | Sangoma |
| fw_langpacks | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| hotelwakeup | 16.0.5 | Enabled | GPLv2 | Sangoma |
| iaxsettings | 16.0.3 | Enabled | AGPLv3 | Sangoma |
| infoservices | 16.0.2 | Enabled | GPLv2+ | Sangoma |
| iotserver | 15.0.4.1 | Disabled | Commercial | Sangoma |
| irc | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| ivr | 16.0.5 | Enabled | GPLv3+ | Sangoma |
| languages | 16.0.4 | Enabled | GPLv3+ | Sangoma |
| logfiles | 16.0.7 | Enabled | GPLv3+ | Sangoma |
| manager | 16.0.15 | Enabled | GPLv2+ | Sangoma |
| miscapps | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| miscdests | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| music | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| oracle_connector | 16.0.16 | Enabled | Commercial | Sangoma |
| outroutemsg | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| paging | 16.0.11 | Enabled | GPLv3+ | Sangoma |
| pagingpro | 16.0.10 | Enabled | Commercial | Sangoma |
| parking | 16.0.4 | Enabled | GPLv3+ | Sangoma |
| parkpro | 16.0.5 | Enabled | Commercial | Sangoma |
| phonebook | 16.0.3 | Enabled | GPLv3+ | Sangoma |
| phpinfo | 16.0.1 | Enabled | GPLv2+ | Sangoma |
| pinsets | 16.0.8 | Enabled | GPLv3+ | Sangoma |
| pinsetspro | 16.0.4 | Enabled | Commercial | Sangoma |
| pm2 | 16.0.8 | Enabled | AGPLv3+ | Sangoma |
| pms | 16.0.20 | Enabled | Commercial | Sangoma |
| presencestate | 16.0.4 | Enabled | GPLv3+ | Sangoma |
| printextensions | 16.0.8 | Enabled | GPLv3+ | Sangoma |
| queueprio | 16.0.2 | Enabled | GPLv3+ | Sangoma |
| queues | 16.0.19 | Enabled | GPLv2+ | Sangoma |
| queuestats | 16.0.22 | Enabled | Commercial | Sangoma |
| qxact_reports | 16.0.25 | Enabled | Commercial | Sangoma |
| recording_report | 16.0.25 | Enabled | Commercial | Sangoma |
| recordings | 16.0.11 | Enabled | GPLv3+ | Sangoma |
| restapps | 16.0.32.13 | Enabled | Commercial | Sangoma |
| ringgroups | 16.0.9 | Enabled | GPLv3+ | Sangoma |
| sangomacrm | 16.0.10.19 | Enabled | Commercial | Sangoma |
| sangomartapi | 16.0.44.1 | Enabled | Commercial | Sangoma |
| setcid | 16.0.3 | Enabled | GPLv3+ | Sangoma |
| sipsettings | 16.0.26 | Enabled | AGPLv3+ | Sangoma |
| sipstation | 16.0.22 | Enabled | Commercial | Sangoma |
| sms | 16.0.22 | Enabled | Commercial | Sangoma |
| soundlang | 16.0.9 | Enabled | GPLv3+ | Sangoma |
| superfecta | 16.0.19 | Enabled | GPLv2+ | Sangoma |
| sysadmin | 16.0.28 | Enabled | Commercial | Sangoma |
| timeconditions | 16.0.9 | Enabled | GPLv3+ | Sangoma |
| tts | 16.0.3 | Enabled | GPLv3+ | Sangoma |
| ttsengines | 16.0.3 | Enabled | AGPLv3 | Sangoma |
| ucp | 16.0.30 | Enabled | AGPLv3+ | Sangoma |
| userman | 16.0.35.5 | Enabled | AGPLv3+ | Sangoma |
| vega | 16.0.6 | Enabled | Commercial+ | Sangoma |
| vmblast | 16.0.4 | Enabled | GPLv3+ | Sangoma |
| vmnotify | 16.0.6 | Enabled | Commercial | Sangoma |
| voicemail | 16.0.48 | Enabled | GPLv3+ | Sangoma |
| voicemail_report | 16.0.3 | Enabled | Commercial | Sangoma |
| voipinnovations | 16.0.26 | Enabled | Commercial | Sangoma |
| vqplus | 16.0.18 | Enabled | Commercial | Sangoma |
| weakpasswords | 16.0.1 | Enabled | GPLv3+ | Sangoma |
| webcallback | 16.0.3 | Enabled | Commercial | Sangoma |
| webrtc | 16.0.17 | Enabled | GPLv3+ | Sangoma |
| xmpp | 16.0.7 | Enabled | AGPLv3 | Sangoma |
| zulu | 16.0.19 | Enabled | Commercial | Sangoma |
The asterisk is installed behind the firewall. Only ports for TLS (all), WebRTC (all), SIP 5060 (only on trusted networks).
The only one thing - active API REST interface.
All passwords are 32 characters with special characters.
I have no idea how an external application could connect. I also wrote to Sangoma, but unfortunately I still have not received a response.
The firewall on FreePBX is turned off because it’s behind another firewall.
Any ideas?
We need to see logs of this happening. See if the /var/logs/asterisk/full.* logs have any data of these calls.
I kinda agree with @BlazeStudios , would like to see some logs . I have seen a few of these “Stasis” intrusion posts now, and most of them admitted their ports have been wide open to the world. Particularly port 8088.
Unfortunately the log file has been cleared. I don’t know why, I decided to clean it up after the invasion. To watch again.
Now I just open 8089 port for WebRTC. So far so good.
you were right, port 8088 was open on our client’s router
but the password was not standard, how could it be cracked?
part of the logs Untitled - FreePBX Pastebin
Where do I set the password? Is it like for admin?
I think this is the same issue that is being discussed in Inactive Stasis app 'hey' missed message
Thanks for you link…
I think that in my case there was a problem with the open port 8088 through which an external application stasis was connected.
Now I have closed it. I have only 8089 port (open for everyone) for WebRTC calls from the browser. As long as it’s okay…
FYI, I had 2 systems that had this stasis app abuse & they ONLY had port 8089 open to the public (not 8088), so I suggest you still might be vulnerable.
We use several WebRTC call buttons (call from the website) that use port 8089.
Unfortunately, it must be open to all networks. Any ideas how to protect yourself?
Before FreePBX we use a pfSense firewall with pfBlocker packege which blocks questionable IP addresses.
I personally don’t know how to protect 8089 against being vulnerable to this attack, Sangoma’s own Wiki page says 8089 is ‘Safe to open this up to untrusted networks as the traffic is encrypted with SSL and requires username and password authentication’, however, it wasn’t safe for me on 2 systems & so I’ve had to block it from the outside world (I wasn’t using WebRTC & so it being blocked is not such a deal-breaker for me).
Trying to establish how this attack happened & whether 8089 should be safe to open to the public (like the Wiki suggests) is kinda what the other thread is all about. At the moment its unclear whether the attacker knew/was able to get the default [freepbxuser] password -OR- did they somehow manage to connect without credentials.
I will say this again just in case anyone missed it. Outside of the FreePBX community no one running a pure Asterisk install (or non-FreePBX based projects) has reported or seen any issues with ARI/WebRTC and bypassing any authentication.
And yet this IS the FreePBX community, as yet , no substantive answer . . .
And yet it is an ARI hack. So if putting on the table ARI allowed no auth access, which it shouldn’t and thus would be a bug, then Asterisk not hearing about this for the last 3 weeks (since this was reported) is kind of relevant. This would fall under a security flaw and a security release of the current version (ala 18.16.1 or 20.0.1) would be released to fix it.
In other words, Asterisk bugs impact all users of Asterisk, including FreePBX users. FreePBX bugs only impact FreePBX users or those deriving from FreePBX.