 So welcome to my talk. Uh today we are going to speak about Apache Solar Injections and how to break into web applications that use this technology. My name is Michael Stipankin. Um, let's see if it works. Apparently not. So my name is Michael Stipankin. I'm a web application security researcher. I work at Veracode and mostly on making our dynamic and static scanners smarter and faster. So it's actually started on a back bounty. During the normal web application fuzzing, I noticed that for the backslash and for the double quote, the server returned a very specific error. Some, something like a solar basic server query error. And I didn't even know what the solar basic server is. So this research had been started. So it turned out that solar 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, post some data into it. And this data could be in almost any format including PDF or Word or even HTML pages. But here it's just JSON. And then solar 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, um, there is no cookies, there is no authentication, there is no special headers at all. Which absolutely makes this solar, Apache solar engine a perfect victim for the SSRF or CSRF or request modeling attacks. But, uh, as advised by developers, it's 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 request or response during the web application testing, there is a good chance that there is a solar 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 a select or update or config operation. You can also specify a parser type, local parameters name. Or you can even do sub queries if you want to join other data from other collections. So as you can see here, the request may be quite complex, but it's based on good old HTTP. And here, here is how the basic application that is using solar 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 to 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 solar server request from the web application to the Apache solar database. But, um, and I would call this vulnerability Apache solar parameter injection. And it's basically a subset of HTTP query injections. But normally in 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 solar have some sort of magic parameters that could allow us to completely rewrite the query logic and perform some magic. These parameters are meant to, to be used internal only. Um, and basically by sending them, we're telling solar not to process this request at all, but rather to redirect this request to the specified chart URL. And in the QT parameter and in the stream body, we can completely rewrite the request URL, the URI or the stream body. And you might think about it as a very powerful SSRF vulnerability. Well, when the solar 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 know the internal URL that we are going to use in the shards parameter. And the best target for this SSRF vulnerability is the solar by itself. Because as I mentioned before, it's completely stateless and it doesn't require any authentication. So it's a perfect attack for SSRF. So, by using this URL, we can actually leak the common collection name and the database name because we ultimately need it, 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 solar server, you can actually rewrite them in the field parameter. And you can actually even completely fake the JSON response that comes from the solar to the web application by using JSON.wrf parameter, which acts exactly like a JSONP callback. Or you can just even inject additional parameters in the solar response. But if you have a special character in these parameters values, they will be automatically escaped by using JSON or XML escaping. But we can use it in conjunction with the XML transformer in order to tell solar that it should be a valid XML fragment and shouldn't be escaped at all. And this attack could lead to XSS by response sponsoring, for example. But even if we can't control additional parameters, even if we can control only one single queue parameter, we still can use, so now, local parameters in the braces. And we can specify the X, the parser type here. And this attack actually now 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 Java, it was vulnerable to exceed. And that's how we can leverage this attack to the SSRF attack and apply the same logic as before, just by controlling one single queue parameter. But it actually does not make any sense unless we have a way to pop a calculator using one of these techniques. So the main goal of this research is actually to identify some RCE vulnerabilities in the Apache solar 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, and Apache solar, it's not really a web logic or head up. But since it's just a huge Java application, for sure it should have some problems with serialization or XML parsing. And the first vulnerability we reported there was about using the config API in conjunction with AdListener parameter. So basically here we can send two post requests to solar. And first request, we can use an add new update listener. And within this update listener, we can use a solar dot run executable listener class that basically executes a shell command 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 the previously mentioned magic parameters in order to execute this attack just by using two simple get queries. So now it's SSRFable, CSRFable, and many thanks to Olga Barinova who come up with this incredible logic. And which is more cool, we can even combine it with the XML parser X6E issue in order to exploit this RC vulnerability just by controlling one single queue parameter. And just look at this request. I think they're just beautiful. And every time you send them to the backend application, the solar doesn't actually give you anything. You are completely blind. You just send them and pray. And then eventually you have a DNS callback on your server. And such a, 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.server URL. So and when I first saw this, I thought that it looks exactly like a GDI URL. And if you heard about GDI attacks, it basically could lead to remote class loading, but not that easy. And what's really happens when we set this property is that Apache Solar creates a new mbin server, jmx mbin 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, it tries to send serialized object using the RMI protocol. So the first way to exploit it is we can create a malicious RMI registry by using YC serial tool, for example, and reply to the solar server with an exception. And within the exception, we can use a 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 ROM gadget chain, or either we can use a pure JDK gadget chain if our solar server is outdated enough. And it ultimately eventually leads to the calculator. Another way to exploit this vulnerability is actually to create an innocent solar, innocent RMI registry and allow to solar to actually set up this jmx server and then just use a metasploit model or empty Python module to actually deploy a malicious mbin within the solar module. And the third vulnerability we reported just recently was about using the data imper handler component. And in this request, we're basically telling Apache solar to go to the data handler component. And in this request, we're basically telling Apache solar to go to this URL, download the page and apply a special script transformer to this page. And this JavaScript is actually executed via the JavaScript engine, which is completely unsunboxed. And just by sending one simple get request, we can achieve this RCE. And when I reported this vulnerability, apparently the developers didn't even realize that we can 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 the same data imper handler and it's 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 solar server it will be created an object with this specified class name. So we can use the well-known pure GDK gadget chain as GDB zero set implementation that requires just two setters to be set in order to lead us to the GNDI injection attack and subsequently to remote class loading. So actually I've got a few minutes left and just one real word example how we can perform this vulnerability on the search.maven.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 I, when I tried this parameter I actually got a DNS callback on my server verifying 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 is the ref attacks. And you know when we, in the good old days when we use a single quote to try to put it everywhere and to try to cause a SQL error exception on the page. But in the modern microservices area error 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 immediately creates an invalid argument in section. And in this case Java very friendly tells that I'm trying to connect to this URL and I 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 X6C and the updated handler to actually trigger an X6C 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 could, I could have an RCE vulnerability on the Mavin website. But unfortunately the target solar 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're interested in more attacks against Apache solar you can check out our full white paper and thank you very much for attending this talk.