iptablex trojan experiences?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

iptablex trojan experiences?

ElasticSearch Users mailing list
Hi, I had a couple of exploits in the last 2 weeks in my CentOS 5.7 with a trojan iptablex. Apparently it does a DDoS and, after, opens connections somewhere else. There are reported cases of connections open to someone at China Telecom.

If you look processes in your server, you will find something as: 

root 4252 632 0 18:44 ? 00:00:00 /boot/.IptabLex
root 4260 624 0 18:45 ? 00:00:00 /boot/.IptabLes

This is the second time happening to me and in both cases root is compromised so it requires a full server reinstall. In the first case, I though the problem could come from Tomcat 7 which is having quite a few vulnerabilities last months (http://tomcat.apache.org/security-7.html) so I upgraded to Tomcat 8.0.8, latest release.

However, problem reproduced again after fully reinstalling the server. In this second time I have found that ports 9200 and 9300 are open in my VPS by my hosting provider and I found some other cases of iptablex trojan attacking machines though Elastic Search ports. I know, they should not be open.

You can find an increasingly number of reported cases on internet pointing to ES (and also Tomcat/struts)

http://nerdanswer.com/answer.php?q=524925
http://security.stackexchange.com/questions/58862/logging-server-compromised-iptables-and-iptablex

So, has any other user in this group experienced the same?

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f96fa6c7-a722-4bc3-9a4e-84385ceb11ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

ElasticSearch Users mailing list
probably related 

http://bouk.co/blog/elasticsearch-rce/

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b6207d97-8baa-4c27-9ecd-7da9933503ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

Mark Walkom
In reply to this post by ElasticSearch Users mailing list
There has been a few comments in IRC about similar things happening, all due to ports 9200 and/or 9300 being open to the internet.

However, as you mentioned, you really shouldn't have ES directly accessible to the outside world

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: [hidden email]
web: www.campaignmonitor.com


On 4 June 2014 05:38, 'Adolfo Rodriguez' via elasticsearch <[hidden email]> wrote:
Hi, I had a couple of exploits in the last 2 weeks in my CentOS 5.7 with a trojan iptablex. Apparently it does a DDoS and, after, opens connections somewhere else. There are reported cases of connections open to someone at China Telecom.

If you look processes in your server, you will find something as: 

root <a href="tel:4252%20632%200%2018" value="+14252632018" target="_blank">4252 632 0 18:44 ? 00:00:00 /boot/.IptabLex
root 4260 624 0 18:45 ? 00:00:00 /boot/.IptabLes

This is the second time happening to me and in both cases root is compromised so it requires a full server reinstall. In the first case, I though the problem could come from Tomcat 7 which is having quite a few vulnerabilities last months (http://tomcat.apache.org/security-7.html) so I upgraded to Tomcat 8.0.8, latest release.

However, problem reproduced again after fully reinstalling the server. In this second time I have found that ports 9200 and 9300 are open in my VPS by my hosting provider and I found some other cases of iptablex trojan attacking machines though Elastic Search ports. I know, they should not be open.

You can find an increasingly number of reported cases on internet pointing to ES (and also Tomcat/struts)


So, has any other user in this group experienced the same?

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f96fa6c7-a722-4bc3-9a4e-84385ceb11ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624aU%3DGZ6fH3fUVuD4eo5g%2BsFVFuCUTKeWhP4AYRA8Pd%3D0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

ElasticSearch Users mailing list
In reply to this post by ElasticSearch Users mailing list
i was using release elasticsearch-0.90.5 in my exploited server, so maybe this is already fixed in current release by disabling script.disable_dynamic by default

https://github.com/elasticsearch/elasticsearch/issues/5853

(besides not exposing port 9200 outside)

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3772e3b3-9b82-4018-8468-392ee2f1c4b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

Hassan Schroeder
On Tue, Jun 3, 2014 at 3:33 PM, 'Adolfo Rodriguez' via elasticsearch
<[hidden email]> wrote:
> i was using release elasticsearch-0.90.5 in my exploited server, so maybe
> this is already fixed in current release by disabling script.disable_dynamic
> by default

I got caught by this a week ago using 1.1.0 on Ubuntu 12.04. Had
not even thought about a high port like 9200 being open by default.
(And no, there's no Tomcat or Struts app on that box.)

Luckily NewRelic tipped me off right away and I was able to put it
into rescue mode while I provisioned a new server.

One more item for the checklist :-)

--
Hassan Schroeder ------------------------ [hidden email]
http://about.me/hassanschroeder
twitter: @hassan

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CACmC4yC%3D24X-0OBT3weju9s_9v--RJ4yLBahPn6dSuKwBho2ig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

Mark Walkom
The script.disable_dynamic is an important one for anyone running <1.2.0.

You can also look at setting http.enabled for all your nodes, then use a front end client with authentication.

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: [hidden email]
web: www.campaignmonitor.com


On 4 June 2014 08:49, Hassan Schroeder <[hidden email]> wrote:
On Tue, Jun 3, 2014 at 3:33 PM, 'Adolfo Rodriguez' via elasticsearch
<[hidden email]> wrote:
> i was using release elasticsearch-0.90.5 in my exploited server, so maybe
> this is already fixed in current release by disabling script.disable_dynamic
> by default

I got caught by this a week ago using 1.1.0 on Ubuntu 12.04. Had
not even thought about a high port like 9200 being open by default.
(And no, there's no Tomcat or Struts app on that box.)

Luckily NewRelic tipped me off right away and I was able to put it
into rescue mode while I provisioned a new server.

One more item for the checklist :-)

--
Hassan Schroeder ------------------------ [hidden email]
http://about.me/hassanschroeder
twitter: @hassan

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CACmC4yC%3D24X-0OBT3weju9s_9v--RJ4yLBahPn6dSuKwBho2ig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624a75uoa4PXU6WW0_RHDBozFUE9-xO8wNCDsqN4w5%2BZuRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

ElasticSearch Users mailing list
Thanks for sharing your experiences

here is some sample code on how to exploit the system for version <1.2.0, port 9200 exposed to internet and flag setting script.disable_dynamic=false as is by default 

http://bouk.co/blog/elasticsearch-rce/#how_to_secure_against_this_vulnerability

regards

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3a54a472-27ac-4c91-9494-b2cfd07dad30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

Patrick Proniewski
On 04 juin 2014, at 05:38, 'Adolfo Rodriguez' via elasticsearch wrote:

> here is some sample code on how to exploit the system for version <1.2.0, port 9200 exposed to internet and flag setting script.disable_dynamic=false as is by default
>
> http://bouk.co/blog/elasticsearch-rce/#how_to_secure_against_this_vulnerability


I've had a great deal of fun reading this. And I'm really concerned that in 2014 people are still developing products like ES with absolutely no security features.
This blogger should have added a word of warning about running ES as root/admin, I'm pretty sure most developers are running ES with their admin account, or even with root. Use a dedicated user account for the ES process, with very limited permissions and powers. Always think about privilege separation before you install a new software.
ES should really be quarantined. On FreeBSD, one can use a jail (very easy nowadays with ZFS and ezjail). I'm pretty sure similar things exist for Linux.
If you have the guts, go with SELinux. Requires some work, but it's rewarding and it has some pretty dam' cool things inside.

Patrick

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/8C53A03A-BBB9-4450-86CF-562BC1E45CD1%40patpro.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

ElasticSearch Users mailing list
This is exactly the kind of things I was planning for my next deployment: a jail and finer permission tuning (besides closing the port and changing flag configuration). Exactly I was running ES libraries as root embedded in a Tomcat app.

However, I think software should fit for purpose and delegate security in other specialized programs. Making the specific warnings, this policy looks ok to me.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/d92b6677-35a3-4fec-b19f-813e854fce86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

ElasticSearch Users mailing list
>>>>> ES with absolutely no security features
 
However, I think software should fit for purpose and delegate security in other specialized programs.

just to clarify, I think there is not need of any additional security modules but, I agree that, any configuration option must be safe by default. And if any additional module is provided, make it optional to prevent unnecessary burden

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

joergprante@gmail.com
One very essential feature, from the very beginning, is that Elasticsearch instances, when started, automatically form a cluster over the network.

This is only possible in an open network environment and by having multicast enabled.

Are you aware, that by talking about "safe" configuration options "by default", you no longer can expect Elasticsearch to form a cluster? And that others would have to suffer from that?

If you want security, you can not do this simply by adding "security modules" or by "safe" configuration options: it's always the responsibility and the awareness of the admin in person to run and maintain the software in a protected environment.

It is just ridiculous to read that running applications under superuser privileges and allowing world-wide access over the internet to a host with user applications need "safe configuration options by default" and "unnecessary burden must be prevented".

This is open source. Use the power of it. But do not blame others for your personal mistakes.

Jörg




On Wed, Jun 4, 2014 at 11:34 AM, 'Adolfo Rodriguez' via elasticsearch <[hidden email]> wrote:
>>>>> ES with absolutely no security features
 
However, I think software should fit for purpose and delegate security in other specialized programs.

just to clarify, I think there is not need of any additional security modules but, I agree that, any configuration option must be safe by default. And if any additional module is provided, make it optional to prevent unnecessary burden

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHhDcwQxuhMpjO%2BX0sGe9wkmRRhkqQDwWo5nZ-WWvh_-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

Mark Walkom
Containers, or VMs are also a valid approach to limiting access and potential breaches.

Like all security, it's a multi-layered approach.

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: [hidden email]
web: www.campaignmonitor.com


On 4 June 2014 19:57, [hidden email] <[hidden email]> wrote:
One very essential feature, from the very beginning, is that Elasticsearch instances, when started, automatically form a cluster over the network.

This is only possible in an open network environment and by having multicast enabled.

Are you aware, that by talking about "safe" configuration options "by default", you no longer can expect Elasticsearch to form a cluster? And that others would have to suffer from that?

If you want security, you can not do this simply by adding "security modules" or by "safe" configuration options: it's always the responsibility and the awareness of the admin in person to run and maintain the software in a protected environment.

It is just ridiculous to read that running applications under superuser privileges and allowing world-wide access over the internet to a host with user applications need "safe configuration options by default" and "unnecessary burden must be prevented".

This is open source. Use the power of it. But do not blame others for your personal mistakes.

Jörg




On Wed, Jun 4, 2014 at 11:34 AM, 'Adolfo Rodriguez' via elasticsearch <[hidden email]> wrote:
>>>>> ES with absolutely no security features
 
However, I think software should fit for purpose and delegate security in other specialized programs.

just to clarify, I think there is not need of any additional security modules but, I agree that, any configuration option must be safe by default. And if any additional module is provided, make it optional to prevent unnecessary burden

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHhDcwQxuhMpjO%2BX0sGe9wkmRRhkqQDwWo5nZ-WWvh_-A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624YjRikoQ4xdo05X1LNy3BSAiRbUmL1Mg5xw3qQTZJ%2Bcwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: iptablex trojan experiences?

ElasticSearch Users mailing list
In reply to this post by joergprante@gmail.com
sorry if you took the message personally. Is your problem, not mine. I was not attacking you at all, rather saying that, in my opinion, software should fit for purpose and either prevent (when feasible) or warn about possible security holes. Just that. But not building additional security features beyond purpose (as I understood Richard was suggesting). So, basically the same that you are stating.
 
It is just ridiculous to read that running applications under superuser privileges and allowing world-wide access over the internet to a host with user applications need "safe configuration options by default" and "unnecessary burden must be prevented".

well, is ridiculous if you are google and have 2000 employees to create a couple of servlets. But if you have limited resources, and you are paying attention to other functionalities and working on beta, is not ridiculous. Is an assumed and controlled risk.

But do not blame others for your personal mistakes.

Can you please show me where I did that? I totally agree what you did here. No more question here. Sorry, you have blamed yourself, I did not.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a72a0161-91c5-47b3-a989-7dd8548f996a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.