A coworker (@breenmachine) and I recently performed a penetration test to simulate the risk of an attacker who is able to connect to a network jack inside of a hospital. The objective was essentially to see if we could gain access to specific VLANs. One of the ACLs prevented us from being able to SSH into the hosts on the target networks.
The assessment started with us performing some standard fast scans against the scope to get an idea of what we were dealing with. There were two promising targets in scope, a Citrix gateway, and a custom application that runs as a thick client to access the application server; we decided to focus on the custom application.
Loading up the thick client we were prompted for a username and password, unfortunately we weren’t able to guess using some standards (admin/admin, admin/password, administrator/administrator, root/root, etc….). At this point we decided to look more at the application itself so we grabbed the jar files referenced in the jnlp file (there were quite a few so parallel –gnu “wget {}” was used)
We extracted the files from the jars using 7z but for some reason we were having issues decompiling the class files using jd-gui (not sure why) so we decided to use jad instead which worked great. Using find and xargs we were quickly able to decompile the class files. One of the first things we came across when going through the source was the location of a couple WSDLs so we immediately opened up SoapUI and had it proxy through Burp (which was already open… because it usually is).
Sending the requests coming from SoapUI to repeater we were able to easily find XXE:
Unfortunately, unlike some other applications we’ve seen, this application was not running with root level privileges. Though luckily for us we were able to read both files and directories so we weren’t shooting completely blind which was great.
At this point it was time to start looking through the filesystem to see if we could find anything interesting. One of the files that we came across in our exploration was a shell script to add users, including a standardized password (which I will not post here because it was based on the client’s name).
At some point shortly after we found that we were able to login to the application as the Administrator with the previously mentioned bad password. Looking through the application we found that it was possible to run reports; even better, we found it was possible to create custom reports that could be run, customized by SQL queries. Simultaneously we had been going through the application’s documentation (protip: search the docs for ‘command’ to find the good stuff) and found references to perl in postgres. Putting two and two together, we were able to create a custom report with the following SQL query (we know we don’t need all the extra garbage, it was taken right from the docs):
And sure enough, with a netcat listener on the other side, we got a shell.
No comments:
Post a Comment