Iptablex trojan experiences?

Elastic Stack Elasticsearch
1

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

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 elasticsearch+unsubscribe@googlegroups.com.
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.

2

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 elasticsearch+unsubscribe@googlegroups.com.
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.

3

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: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 4 June 2014 05:38, 'Adolfo Rodriguez' via elasticsearch <
elasticsearch@googlegroups.com> 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 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 (Apache Tomcat® - Apache Tomcat 7 vulnerabilities) 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

Logging server compromised (IptabLes and IptabLex) - Information Security Stack Exchange

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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/f96fa6c7-a722-4bc3-9a4e-84385ceb11ac%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/f96fa6c7-a722-4bc3-9a4e-84385ceb11ac%40googlegroups.com?utm_medium=email&utm_source=footer
.
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 elasticsearch+unsubscribe@googlegroups.com.
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.

4

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

(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 elasticsearch+unsubscribe@googlegroups.com.
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.

5

On Tue, Jun 3, 2014 at 3:33 PM, 'Adolfo Rodriguez' via elasticsearch
elasticsearch@googlegroups.com 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 :slight_smile:

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
Hassan Schroeder | about.me
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 elasticsearch+unsubscribe@googlegroups.com.
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.

6

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: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 4 June 2014 08:49, Hassan Schroeder hassan.schroeder@gmail.com wrote:

On Tue, Jun 3, 2014 at 3:33 PM, 'Adolfo Rodriguez' via elasticsearch
elasticsearch@googlegroups.com 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 :slight_smile:

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
Hassan Schroeder | about.me
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 elasticsearch+unsubscribe@googlegroups.com.
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 elasticsearch+unsubscribe@googlegroups.com.
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.

7

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 elasticsearch+unsubscribe@googlegroups.com.
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.

8

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 elasticsearch+unsubscribe@googlegroups.com.
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.

9

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 elasticsearch+unsubscribe@googlegroups.com.
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.

10

>>>>> 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 elasticsearch+unsubscribe@googlegroups.com.
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.

11

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 <
elasticsearch@googlegroups.com> 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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com?utm_medium=email&utm_source=footer
.

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 elasticsearch+unsubscribe@googlegroups.com.
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.

12

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: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 4 June 2014 19:57, joergprante@gmail.com joergprante@gmail.com 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 <
elasticsearch@googlegroups.com> 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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com?utm_medium=email&utm_source=footer
.

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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHhDcwQxuhMpjO%2BX0sGe9wkmRRhkqQDwWo5nZ-WWvh_-A%40mail.gmail.com
https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHhDcwQxuhMpjO%2BX0sGe9wkmRRhkqQDwWo5nZ-WWvh_-A%40mail.gmail.com?utm_medium=email&utm_source=footer
.

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 elasticsearch+unsubscribe@googlegroups.com.
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.

13

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
https://github.com/elasticsearch/elasticsearch/issues/5853. 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 elasticsearch+unsubscribe@googlegroups.com.
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.