During a black-box penetration test we encountered a Java web application which presented us with a login screen. Even though we managed to bypass the authentication mechanism, there was not much we could do. The attack surface was still pretty small, there were only a few things we could tamper with.
1. Identifying the entry point
In the login page I noticed a hidden POST parameter that was being sent for every login request:
<input type="hidden" name="com.ibm.faces.PARAM" value="rO0..." />
The famous Base64 rO0 (ac ed in HEX) confirmed us that we were dealing with a Base64 encoded Java serialized object. The Java object was actually an unencrypted JSF ViewState. Since deserialization vulnerabilities are notorious for their trickiness, I started messing with it.
Later this past month, our lab welcomed a very important individual: Robi the robot (it has a camera and speakers!). We also received the honors to assemble it and make it dance. And so the journey to the fields of the unknown started. While playing with the command and control software, I could not help but wonder how secure this really is.
First of all, from the start I expected some kind of bluetooth link (blueborne *cough cough*) but I was actually greeted with it’s very own WiFi network board . It has the capability to join an existing network but by default it also comes with an open AP with a suggestive SSID. From the start, I also encountered a defense mechanism which is defined by allowing only a single C&C connection to be established with another machine.
By further inspecting the C&C mobile software, I saw the IP address which confirmed to be the gateway/WiFi manager interface. After a quick scan, the identified number of open ports:
In one of our previous posts, we noted that a popular tool – Responder – uses Basic Authentication prompts to harvest user credentials when they accidentally enter invalid domains in web browsers.
Responder’s approach is pretty good and it does some “magic” to catch and respond to DNS requests for in-existing domais, however I think that there is way more potential in using Basic Authentication for phishing purposes.
What I like (or dislike) most about basic authentication is that it is NEVER clear who is asking for your credentials and where they will end up. This type of confusion often tricks users into falling for simple phishing tricks, allowing attackers to easily gather user credentials.
There are a good number of situations when we find ourselves abusing the LLMNR and NBT-NS protocols on an infrastructure penetration test, more specifically on an Active Directory setup. These 2 protocols are enabled by default on most of the Windows operating systems. What are they doing is they facilitate the communication between network machines when searching for a DNS hostname regardless if it’s a share, a server or a web hostname.
The overview picture of the attack vector:
- the victim is looking for a non-existing hostname
- the DNS server cannot resolve the request
- we reply and resolve the hostname resolution query
- we ask the victim for authentication
In a recent penetration testing project we encountered a situation where in order to prove exploitability and possible damage we had to exfiltrate data from an isolated server using an OS command injection time based attack.
The scope of the project was an API. During the testing process we identified an interesting GET request that received 2 parameters: the first a string and the other one ID number.
By fuzzing the string parameter, at first, it looked like we had a potential SQL injection, based on the way it handled single quotes. Trying this attack vector didn’t seem successful, but when we sent the ` sleep 10` command and the HTTP response returned 10 seconds later, we knew we had something. Our first thought was that this was game over for the application, we managed to get a Remote Code Execution on the API server.