FYI, I would like to share these two articles hoping to encourage the community in keeping their system up to date.
In summary, attackers could use a vulnerability to access the FreePBX, steal data and install crypto mining scripts. It seems that the security hole has been patched, so it is recommended not to put off updates for long.
I love articles like these. The ones where they tell you have a huge vulnerability but then they donât tell you what that vulnerability is, what version of Asterisk/FreePBX this impacts and what version has the patch to fix it.
Despite both articles coming from the same source, one claims Asterisk/FreePBX and the other just claims Asterisk. One claims there was a patch released for this vulnerability but the other has no mention of the patch.
Articles like these are click bait as far as Iâm concerned because they do nothing but tell you that you could be exposed to being compromised but give you no actionable information on how to resolve or mitigate the issue. Very helpful.
The point is to encourage people to keep their systems up to date. When vulnerabilities are discovered the responsible parties are first to be informed before it is made public and they issue patches. So regardless of the affected Asterisk version, updating the software is important to mitigate any known or (publicly) unknown security risks.
Here is the thing about these articles. Asterisk, itself, doesnât have a GUI. That means it doesnât require or need Apache (or any web server) or PHP. So that would mean there are numerous Asterisk installs out in the world that would never be impacted by this, at all.
Conversely, FreePBX (which uses Asterisk) is GUI based and therefore uses Apache and PHP which would mean 100% of FreePBX boxes could be impacted by this. These articles fail to relate how this is being done. What attack vectors are being used? Is it a buffer overflow? Is it a SQL injection? What?!
Again, ZERO information provided. Right now FreePBX v13 and v14 are the âcurrentâ releases for FreePBX. The former uses PHP 5.3 while the latter uses PHP 5.6. What versions of FreePBX where these monitored systems running? Were they current boxes? Were they v13 or v14?
I mean come on, look at the first article. The report is based off of reporting from Feb - July of 2018! Over a year and a half ago. It even says a patch was released (but doesnât tell you what update has the patch or what versions should be patched). So honestly, if you are a year and a half behind on your updates, you deserve a quick kick in the gonads to wake you up.
Articles like this are reckless because they promote a panic with no resolution.
The ZDNet article (and this post) are meant to reach general audience with interest in FreePBX. I included the source article for people like you to contact the researches to get more details.
The article says:
@BlazeStudios I had to shutdown a PBX server because someone installed crypto miner in it. This could be related to this vulnerability or another one. How many of FreePBX users screen their server for crypto mining? I know the risk is real.
The users in this forum are mixed audience with different level of IT/PBX knowledge. My aim to bring awareness to general audience to take action by updating their systems. And for people interested in details, the second link provide the source article with the researcher names to get more information.
That is the most recent exploit but there was also one from 2014 in the long deprecated Asterisk Recordings Interface (ARI). Iâm speculating of course, because the authors have chosen not to share even the SLIGHTEST useful detail, only that it dates from 2018 and there was a fix at that time. Note the date in the wiki page, it is more than 3 years old.
As an aside, the authors donât seem to be overly knowledgeable about PBX exploits specifically, in that they seem more concerned about âespionageâ, leaking CDR records, generating outbound calls with spoofed CID, or listening to call recordings. While I suppose some organizations might be targeted for those types of activities, what we see in practice is ALWAYS traffic pumping, generating outbound calls to high cost destinations
The truth is, any server CAN be compromised, no sane person would claim that there are absolutely no problems with any http/php code, certainly there are possible dialplan intrusions.
A good suite of security tools should include all the standard things plus a root kit tool, I use
@lgaetz I love FreePBX and wish the best for the project. I believe in teamwork and shared responsibility. This is why I have shared this hear to be vetted by skilled people. The second link is an abstract in a security conference. They are usually limited to the number of characters. I believe the researchers work for Check Point Research and this is their website https://research.checkpoint.com/. In my experience, such organizations tends to responds to inquiries and questions from verifies professionals like personals with Sangoma emails. You can answer the right questions.
There are three basic vectors open to compromise Asterisk, FreePBX, which has multiple ports open via htttp and https and downline by the version of PHP you rely on.
The most obvious is ssh, simple answer just use keys and disallow passwords, move ssh to anything but 22 for quietness.
Allowing any incall DTMF WILL allow compromise, just donât allow it, that leaves the more insidious one hich is TCP 5038, which is pure asterisk, and is often left open unknowingly. If compromised, there is little evidence in any âlog filesâ but the calls still go out.
Watching the md5sums of /etc/asterisk/*.conf is a very good starting point for backstop-checking FreePBX intrusions, you would be informed everytime you or anyone else managed to change the dialplan.
But watching /etc/asterisk/bin/asterisk/astdb.sqlite3 wonât easily work as it is too busy.
Quick check from outside, check tcp connections open