>>Uh today we are going to speak about Apache Solr Injections and how to break into web
applications that use this technology. My name is Michael Stepankin. Um let’s see if it
works. Apparently not. Alright. So my name is Michael Stepankin. I’m a web application security
researcher. I work at Veracode. And to mostly on making our dynamic and static scanners
smarter and faster. So it actually started on the bug bounty. During the normal web
application fuzzing, I noticed that for the back slash and for the double quote they sort of
returned a very specific error. Some something like a Solr basic Solr query error. And I didn’t
even know what this Solr basic server is. So this research had been started. So turned that
Solr is a quite popular open source search database that um open source, written in Java and
used by many companies. It has a very nice web UI. That you can use to perform almost any
operation and you may think about it like a database. It just started, pull some date
into it. And this data can be in almost any format including pdf or Word or even html pages, but
here is just json. And then Solr automatically index all of these documents and it provides a very
neat API that you can search over all this data. And as you can see here uh, there is no
cookies, there is no authentications, there is no special headers at all. Which
absolutely makes this Solr Apache Solr engine a perfect victim for the SSRF or CSRF or
request modeling attacks. But uh as advised by developers, its meant to be deployed internal
only and never actually exposed to the internal, to the external users. So here is a basic simple
search query that is quite recognizable and if you can see these parameters in both
requests or response during q- the web application testing. There is a good chance that
there is a Solr is using, is used on the back end. And the more complex query uh is may
look like that, so you can basically need to specify the sentence, you need to search for
a collection name a request handler, which may be select or update or concat operation. You
can now specify a parser type, local parameters name or you can even do so- sub queries if you
want to join other data from other collections. So as you can see here the uh request may be
quite complex, but it’s based on good old http. And here you ha- here is how the basic
application that is used in Solr looks like. As you can see here, it just takes one single
parameter. From the user input and inserts it into the url. In the server, the server http
request. And the main issue here is that this parameter is not properly url encoded. So we
basically can inject additional parameters to this query and they will be smuggled to our
Solr server request from the web application to the Apache Solr database. But um and I would
call this vulnerability Apache Solr parameter injection and its basically a subset of http query
injections, but normally an http query injections you are quite limited uh in terms of impact
because you cannot control the full url, where this request will be sent to. But hopefully
Apache Solr have some sort of magic parameters that could allow us to completely rewrite a
query logic and perform some magic. This parameters are meant to to be used internal only. Um,
and basically by sending them we telling Solr not to protest this request at all, but rather to
redirect this request to the specified chart url. And in the qt parameter and the in the
stream body we can completely rewrite the request url. URI or the stream body and you may
think about it as a very powerful SSRF vulnerability. Once- when the Solr server sends
this request, it actually applies a lot of internal parameters to the request body,
but since we can fully control the request URI and request path in the qt parameter we can
overwrite almost all of them. So when we try to exploit this SSRF vulnerability we basically need
to now the internal URL that we are going to use in the short parameter. And the best target
for this uh SSRF vulnerability is the Solr by itself. Because as I mentioned before, it’s
completely stateless and it doesn’t require any authentication. So its a perfect
a- attack for SSRF. So by using this URL we can actually leak the common the current
collection name and the database name, because we ultimately need it for ex- uh for example to
update another collection or to select information from another collection and here if you
target web application expect some sort of specific fields that comes from the Solr server.
You can actually revise them in the field parameter. And you can actually even completely fake
the adjacent response that comes from the Solr to the web application by using json dot
wrf parameter which acts exactly a json p callback. Or you can just even inject additional
parameters in the Solr response but if you have a special characters in this parameters
values, they will be automatically escape by using json or xml escaping. But we can
use it in conjunction will the xml transformer in order to tell Solr that it should be a valid
xml fragment and shouldn’t be escaped at all. And this attack could lead to XSS via response
poisoning for example. But even if we cannot control additional parameters. Even if you can
control only one single key parameter, we still can use some known local parameters in the
braces. And we can specify the x, the parser type here. And this attack actually know since
2013, but nobody really knows how to exploit it until recently we figured out that we can use
an xml parser to supply the full search query in the xml format. And of course since the java it
was vulnerable to XXE and that’s how we can liberate this attack to the SSRF attack and apply the
same logic as before. Just by controlling once single key parameter. But its actually does
not make any sense unless we have a way to bop a calculator using one of these techniques.
So the main goal of this research is actually to identify some RCE vulnerabilities in the
Apache Solr and how they may be reached through the web application. So documentation
doesn’t really help here, because it’s only about how to make search requests. It’s an
Apache Solr it’s not really a web logic called Hadoop. But since it just a huge job
application for sure it should have some problems with serialization or xml parsing.
And the first vulnerability we reported was about using the config API in conjunction with a
listener parameter. So basically here we can send two post request to Solr and first
request we can use an add a new update listener and within this uh update listener we can use a
Solr dot run executable listener class that basically execute as shell comment for every update
operation. Such a convenient method. And then we need to just initiate any update using the
post request to actually trigger execution of our supplied code. And which is more cool, we
actually combine this technique with a previously mentioned magic parameters in order to
execute this attack just by using two simple get queries. So now its SSRF-able, CSRF-able and
many thanks to Olga Barniova who come up with this incredible logic. And which is more cool,
we can even combine it with the xml parser XXE issue in order to exploit this RCE vulnerability
just by controlling one single q parameter. And just look at this request. I think they’re just
beautiful. And every time you send them to the backend application, it the Solr doesn’t
actually um give you anything. You’re completely blind. You just send them and pray and then
eventually you have a DNS callback on your server. And that just such an amazing
feeling. So the next vulnerability is also connected with the config API and in this
case we need to set a special property called jmx dot service url. So and when I first saw
this I thought that it looks exactly like a jndi url. And if you heard jndi attacks it
basically could lead to remote cross loading, but not that easy. And what’s really happens
when we set this property is that Apache Solr creates a new mbean server. JMX mbean server
on the random tcp port and then it tries to register the newly created server on our rmi
registry. And basically when it does so, um, it tries to send serialized object using the rmi
protocol. So the firstway to exploit it, we is we can create a malicious RMI registry by
using a serial tool for example. And reply to the Solr server server with an exception uh and
within the exception we can use the serialized object to actually trigger remote code
execution. And but the disadvantage of this attack is that we need a proper gadget
chain. And here we can use a ROME gadget chain or either we can use a pure jdk gadget chain
if our Solr server is outdated enough. And it ultimately eventually lead to the
calculator. Another way to exploit this vulnerability is actually to create an innocent
Solr que- innocent rmiregistery and allow to Solr to actually setup this JMX server and then
just use a met exploit model or mjet uh python model to actually deploy a malicious mbean within
the Solr server. That also ultimately leads us to remote code execution. But the
disadvantage of this attack is that we actually need to a direct connection to the Solr
server. So we cannot actually perform it by SSRF. The third vulnerability we reported just
recently was about using the data import handler component. And in this request we basically
telling Apache Solr to go to this url then load the page and apply a special and t-
transformer to this page. And this Javascript is actually executed um, by the Javascript
engine which is completely on Sandbox and just by sending one simple get request we can
achieve this RCE. And when I reported this vulnerability, I found that the developers didn’t
even realize that we cannot include this script into the get query instead of just taking it
from the local config. And there is one more vulnerability how we can exploit this same data
import handler and its connected to the deserialization issue, how this xml is actually
deserialized. Because we can in the driver parameter, we can specify a class name and on the
Solr server it will be created an object with the specified class name so we can use the
well known pure jdk gadget chain as GDBC rowset implementation that requires just two setters
to be set in order to lead us to the JNDI inj- injection attack and subsequently to remote class
loading. So actually I’ve got few minutes left and just one real world example, how we can
perform this vulnerability on the search dot maven dot org website. This website actually
allows you to perform a search over all maven repository and when you type something into the
search box, your browser actually sends this request to the backend server. But this
request doesn’t go directly to the server, but instead to the backend application that
actually prohibits all other methods, apart from select. But as I previously mentioned we can
use a short parameter and when a when I tried this parameter, I actually caugh- got a DNS
callback on my server where we find that we actually can modify the query logic. But in order to
properly use short parameter, we need to know the local url. To target in this CSRF attacks. And
you know when we in the good old days when we use a single code, to try to put it everywhere and
to try to call a SQL error exception on the page, but in the modern micro service erra-
era, we can use another parameter, which is just a blank space that when inserted in the
URL in the server to server request it just it immediately creates an invalid argument
exception and in this case, Java very friendly tells that I’m trying to connect to this url
and I’m fail. So thank you Java now we know what url we need to attack in order to achieve
something. So we can just include this url in our short parameter and use an XXE in the
updated handler to actually an XXE vulnerability and subsequently it could lead to
arbitrary file read. So I reported this vulnerability as soon as I have a file read and I
wish I had I could have an RCE vulnerability on the maven website but unfortunately the
target Solr version was very old and it simply didn’t support components that needed to
achieve RCE. But anyway it was a good vulnerability and it was patched really quickly. If you
interested in more attacks against Apache Solr, you can check out our full white paper
and thank you very much for attending this talk. [applause]