asterisk2billing.org
http://forum.asterisk2billing.org/

Getting Serious Hack problems
http://forum.asterisk2billing.org/viewtopic.php?f=34&t=12571
Page 1 of 2

Author:  ubunter [ Sun Sep 25, 2016 12:16 pm ]
Post subject:  Getting Serious Hack problems

Hello,
I'm having serious hack problems, and really need a help to figure out from where and how it's being done...

I have system running A2B 2.0.1, under asterisk 11.6 cert, mysql 5.5.51-cll-lve, under Centos 6.8. Where I have three servers running the asterisk, and in an independent environment having the web portals far away from asterisk environment, and the sql.

Someone, from IP. 82.205.12.103 was sending hug calls through our end customers account, without any asterisk registration faileur, he was sending the calls correctly identified with our customer credentials through the network within huge amount of thousands of USD.

After discover that, I have suspended all the network, changed all over costumers credentials, change the servers rsa certificates, change passwords, and force iptable closing rules, and blocked that IP in host and in firewall.

Couple of days later, I'm finding that he's trying to send calls again, from other IP from the same range, with the same manner, calls are being placed into the network, just was declined via my routing, as I have placed premium calls into no-provider, so they fail in the routing, but calls was placed.

I'm trying to read all the logs in the system, but I don't find anywhere, how he's finding the way to read the DataBase... I have checked all the vulnerability notes, but noway...

Please, anyone can help, I'm open to share all logs possible to figure this out.

Regards,

Author:  bucasia [ Sun Sep 25, 2016 6:09 pm ]
Post subject:  Re: Getting Serious Hack problems

Hi

How are you authenticating the customers, by IP or by SIP details? I'm guessing by SIP details.

I have no magic solution, but a few ideas ...

- do you have something to capture all of the SIP traffic automatically? I use the opensource part of this (http://www.voipmonitor.org/) to capture all SIP traffic and log the details to a MySQL DB. Also a full SIP trace is captured. I then wrote a simple front end for querying this data. It gives the option of monitoring SIP traffic for patterns, and maybe automatically blocking certain types of traffic. There is also Homer, but I've not used it.

- you could also look at http://www.humbuglabs.org/ for detecting fraud calls, and maybe auto blocking

- you really need to know why a2billing is authenticating the call. The only real way is to switch on debugging (https://sysadminman.net/es/blog/2011/a2 ... gging-2417). Although this will slow down call processing on the system.

- if you've not done it you can block a large chunk of scanning with IP tables. Check out the "algo" rules here - http://www.voip-info.org/wiki/view/Aste ... wall+rules

- you could also put a SIP server in front of Asterisk to have more flexibility filtering calls. Something like Kamailio running the pike module. That's a bigger project though

- ideally if you can restrict calls by IP address

Hope some of that helps. Matt

Author:  ubunter [ Sun Sep 25, 2016 6:33 pm ]
Post subject:  Re: Getting Serious Hack problems

Thank you for your prompt Matt, your suggestions are always helpful....

I do authentication in dynamic and static hosts, they do hacked the dynamic hosts, where they have read the users credentials, and login correctly with users credentials, I don't have any authentication failed in the asterisk log, where I do very restrictive fail2ban rules to block any authentication failure... So, can't do restrict only for static IPs, as we do offer public service.

About all over your suggestions, are fine, I'll look into that, even, having Kamalio in front of the network it was a project which we wanted to do, but never took it serious to do it...now seems to be urgent...

BUT, in all cases, cashing the service, don't mean it's being secured, secured when it's insured, and unhackeabkle... so, doing all these controls don't solve there real issue, where's the bug which they got used to come in, and how they could read the SQL, my SQL server is running in independent environment, accessible only to my servers IPs, and prepared for injections.

I'm really worry about this...

Regards,

Author:  bucasia [ Sun Sep 25, 2016 6:42 pm ]
Post subject:  Re: Getting Serious Hack problems

Nothing is unhackable, especially when it's open to the public. All you can do is layer different security around it.

I did forget to say you should absolutely ensure you are running the latest version of a2billing. There have been exploits. There are likely others.

Credentials could have been obtained anywhere I guess. Maybe via the client, who knows.

Author:  ubunter [ Sun Sep 25, 2016 7:18 pm ]
Post subject:  Re: Getting Serious Hack problems

Via the client? I'd think about that if I get one single client hacked, not 1000 accounts hacked at the same time!
Can't find any error in the logs... Or don't know how to find or trace it...
really weird...

Author:  bucasia [ Sun Sep 25, 2016 9:14 pm ]
Post subject:  Re: Getting Serious Hack problems

Apologies, I missed the fact that they had all the credentials, not just a single customer.

Then I'd say the most likely cause is an exploit in the customer interface.

I would check the Apache access logs for unusual requests. I would definitely check to see if an IP from that block has access the web GUI. Maybe they have a customer account ...

Definitely upgrade A2Billing, and maybe look at something like mod_security on Apache on the customer portal servers. It's a pain to set up, but could offer some generic protection.

Author:  ubunter [ Mon Sep 26, 2016 3:14 am ]
Post subject:  Re: Getting Serious Hack problems

I'm checking the Apache, and the OS logs, no any result from all over the hacker range IP... But what I found strange is this:

Quote:
89.208.212.35 - - [25/Sep/2016:20:41:34 +0000] "GET /javascript/calonlydays.js HTTP/1.1" 200 5862



I'm sure that he has got a customer account, that he could explore the system, also, I have blocked all over the country range IPs from where it coming, yesterday, and today I see that he was trying to place calls, again using other country IP, via proxy I guess...


Quote:
Definitely upgrade A2Billing, and maybe look at something like mod_security on Apache on the customer portal servers. It's a pain to set up, but could offer some generic protection.


I already do have mod_security and mod_evasive configured in the webs server...

Author:  ubunter [ Sun Oct 16, 2016 11:16 am ]
Post subject:  Re: Getting Serious Hack problems

Hello,

Just for update!!

We have received a security alert from the German Federal Office for Information Security (BSI).

Quote:
Dear Sir or Madam,
Memcached[1] is an open-source distributed memory object caching system which is generic in nature but often used for speeding up dynamic web applications. Memcached does not support any forms of authorization. Thus, anyone who can connect to the memcached server has unrestricted access to the data stored in it. This allows attackers e.g. to steal sensitive data like login credentials for web applications or any other kind of content stored with memcached.


For now, we have removed the memcached from our system... as it's not being really possible to secure that...!

Regards,

Author:  vulcan [ Mon Oct 17, 2016 1:25 am ]
Post subject:  Re: Getting Serious Hack problems

Just curious, are you saying that your memcached port was open to the public? Were you storing credentials there?

Author:  ubunter [ Mon Oct 17, 2016 10:19 am ]
Post subject:  Re: Getting Serious Hack problems

vulcan wrote:
Just curious, are you saying that your memcached port was open to the public? Were you storing credentials there?


Not at all, as far as I know, as we have it bloked through the Iptable via:
Code:
iptables -A INPUT -p tcp --destination-port 11211 -m state --state NEW  -m iprange --src-range 172.16.1.1-172.16.1.10 -j ACCEPT
iptables -A INPUT -p udp --destination-port 11211 -m state --state NEW  -m iprange --src-range 172.16.1.1-172.16.1.10 -j ACCEPT


Or I don't know if it have further ports, or manners, from where they got through to read the memcached...

Author:  vulcan [ Mon Oct 17, 2016 10:29 pm ]
Post subject:  Re: Getting Serious Hack problems

The rules you posted are to allow an internal range of IP's not to block as stated. You must then have a rule to block everything as the last rule if your policy is to allow traffic as needed.

Author:  ubunter [ Tue Oct 18, 2016 9:31 am ]
Post subject:  Re: Getting Serious Hack problems

vulcan wrote:
The rules you posted are to allow an internal range of IP's not to block as stated. You must then have a rule to block everything as the last rule if your policy is to allow traffic as needed.


Sure, I mean, this is the unique rule which I have related to memcached, as my generic rules are closed at all as:
Code:
#!/bin/sh
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT


Don't have any other related rule to memcached which open it for outside traffic...

And, I have just suspected the memcached, as got that alert from the BSI, i maybe related to something else... but still haven't found from where they got in...

Author:  vulcan [ Wed Oct 19, 2016 12:56 am ]
Post subject:  Re: Getting Serious Hack problems

You said you cannot find his IP in the customer web portal apache logs, your MySQL server is secure and you don't think it was via memcached server. It seems it may be by injection on the web portal.

Are you using the original A2B interface?

Author:  ubunter [ Wed Oct 19, 2016 9:01 am ]
Post subject:  Re: Getting Serious Hack problems

vulcan wrote:
You said you cannot find his IP in the customer web portal apache logs, your MySQL server is secure and you don't think it was via memcached server. It seems it may be by injection on the web portal.


I have his IP through the call record, as I have modified the a2billing agi to grep the peer Ip for each call and store it in cc_call, so, I grep it from there... in the customer portal, couldn't grep his IP from anywhere, I have searched in all log for that IP, or similar range IPs, nothing in secure, apache, mysql, nothing... even, mysql I have it restricted only for my network IPs, unacceptable from outside...

For injections, not really sure if I have it secured, I have only prepared statements, and the apache mod_security and mod_responsive, and the fail2ban sql injections filters... can't really assure if it's the best or if it's enough...!

Quote:
Are you using the original A2B interface?


Yes, I use the original interface with some customizations in the customer portal, v.2.0.1. and the admin is renamed...

Author:  vulcan [ Wed Oct 19, 2016 10:00 pm ]
Post subject:  Re: Getting Serious Hack problems

If you have added any MySQL queries in the customer portal change them to use PDO.

If you are still having the problem, you can temporarily turn on BINARY Logging in MySQL to log queries. This can impact a busy server negatively noting the files are huge and need to be pruned regularly. These are not text files but tools are available to access them. You can "binlog ignore" tables you don't need.

If access was by injection, it is hard to find the bug. The hacker after discovering the vulnerability may keep it a secret for himself or otherwise sells it. Curious how he has so much traffic to send.

The admin should not be exposed anyway, that can be easily blocked in apache. He does not need to login as customer to inject queries. All that is needed is the normal query to the database anywhere in the application using certain url's.

Page 1 of 2 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/