Check your Elastic Search installation - AVForums was hacked Saturday 7th March

[TheBigK]

I wasn't aware of the security issue so thanks for the heads-up; mine is now pointing to localhost [127.0.0.1] - it had defaulted to using my server's external IP address.

Could you please let me know how to find that out? I got my installation checked but want to be absolutely sure.

 

[MattW]

Could you please let me know how to find that out? I got my installation checked but want to be absolutely sure.

grep -i network.host /etc/elasticsearch/elasticsearch.yml

 

[HWS]

So was your elasticsearch bound to a public facing ip address?

I would never ever open an elastic search port (or any other port beside 80/443) to the public.
This was the main reason for the hack. You should ask the person responsible about why this has not been taken care of at your last security audit..

 

[Mike Edge]

grep -i network.host /etc/elasticsearch/elasticsearch.yml

Also after running that as Matt said, if you are on a public IP, you can check your processes running for something running with iptables in the name with an extra letter. The most common exploit version for this was run as ./boot/iptablesb making someone without a lot of Linux knowledge think it was just something common that iptables ran from boot. You will also notice your server getting more and more laggy over a short period of time as the script run outbound DDoS commands and flood time increases the longer the script runs undetected.

 

[eva2000]

Also after running that as Matt said, if you are on a public IP, you can check your processes running for something running with iptables in the name with an extra letter. The most common exploit version for this was run as ./boot/iptablesb making someone without a lot of Linux knowledge think it was just something common that iptables ran from boot. You will also notice your server getting more and more laggy over a short period of time as the script run outbound DDoS commands and flood time increases the longer the script runs undetected.

interesting what does ./boot/iptablesb do exactly ? open up a iptables on compromised server to allow them to do outbound DDOS attacks ?

if ./boot/iptablesb is malware of some form, then having linux malware detect (maldet) and clamav installed too would help I suppose.

edit: I see http://security.stackexchange.com/questions/58862/logging-server-compromised-iptables-and-iptablex

 

[Mike Edge]

edit: I see http://security.stackexchange.com/questions/58862/logging-server-compromised-iptables-and-iptablex

Yeap, that's it.

 

[eva2000]

Yeap, that's it.

ah did some more googling and seems the malware can be placed at either

/boot/.IptabLes
/boot/.IptabLex

or

/usr/.IptabLes
/usr/.IptabLex

with accompanying start up scripts

IptabLes -> /etc/rc.d/init.d/IptabLes
IptabLex -> /etc/rc.d/init.d/IptabLex

https://www.virustotal.com/en/file/...1ac229fb4554276ba89762f3/analysis/1403520228/

 

[x3sphere]

I would never ever open an elastic search port (or any other port beside 80/443) to the public.
This was the main reason for the hack. You should ask the person responsible about why this has not been taken care of at your last security audit..

Bingo. Anyone that got hit by this means their security was flawed to begin with. First thing to do when setting up a server is block all ports and then only open those that require public access.

Leaving services exposed that don't need to be is really dangerous.

 

[Mike Edge]

@Stuart Wright did you ever get to the bottom of how this all happened and how ES running on a public IP was overlooked in the security audits ?