Support A2Billing :

provided by Star2Billing S.L.

Support A2Billing :
It is currently Tue Mar 19, 2024 8:09 am
Hosted Voice Broadcast


All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Getting Serious Hack problems
PostPosted: Sun Sep 25, 2016 12:16 pm 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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,


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Sun Sep 25, 2016 6:09 pm 
Offline

Joined: Mon Mar 02, 2009 8:56 pm
Posts: 271
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


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Sun Sep 25, 2016 6:33 pm 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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,


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Sun Sep 25, 2016 6:42 pm 
Offline

Joined: Mon Mar 02, 2009 8:56 pm
Posts: 271
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.


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Sun Sep 25, 2016 7:18 pm 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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...


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Sun Sep 25, 2016 9:14 pm 
Offline

Joined: Mon Mar 02, 2009 8:56 pm
Posts: 271
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.


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Mon Sep 26, 2016 3:14 am 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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...


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Sun Oct 16, 2016 11:16 am 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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,


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Mon Oct 17, 2016 1:25 am 
Offline

Joined: Mon Jan 08, 2007 6:56 pm
Posts: 345
Just curious, are you saying that your memcached port was open to the public? Were you storing credentials there?


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Mon Oct 17, 2016 10:19 am 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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...


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Mon Oct 17, 2016 10:29 pm 
Offline

Joined: Mon Jan 08, 2007 6:56 pm
Posts: 345
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.


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Tue Oct 18, 2016 9:31 am 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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...


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Wed Oct 19, 2016 12:56 am 
Offline

Joined: Mon Jan 08, 2007 6:56 pm
Posts: 345
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?


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Wed Oct 19, 2016 9:01 am 
Offline

Joined: Sun Nov 07, 2010 10:00 pm
Posts: 253
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...


Top
 Profile  
 
 Post subject: Re: Getting Serious Hack problems
PostPosted: Wed Oct 19, 2016 10:00 pm 
Offline

Joined: Mon Jan 08, 2007 6:56 pm
Posts: 345
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Predictive Dialer


All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group