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.
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
JSONP injection is a lesser known but quite widespread and dangerous vulnerability and it surfaced in the last years due to the high rate of adoption of JSON, web APIs and the urging need for cross-domain communications.
What is JSONP?
Assuming everybody knows what JSON is, let’s talk a little about JSONP. JSONP comes from JSON with Padding and it was created in order to bypass common restrictions such as Same-origin Policy which is enforced for XMLHttpRequest (AJAX requests).
Let’s take an example. Our online banking application, http://verysecurebank.ro, has implemented an API call that returns the current user’s transactions.
An HTTP request to the http://verysecurebank.ro/getAccountTransactions endpoint presents us with the transactions, JSON formatted:
If our reports application, accessible at http://reports.verysecurebank.ro wants to get the transaction details, an AJAX call to the page won’t be possible, due to Same-origin Policy being in effect (different host).
Note: even if it might be obvious, it’s worth mentioning that when including a script cross-domain, it will run in the context of the including application, not in the source’s context.
Adding a callback to the API response, wrapped around the JSON formatted data, allows us to load the API response between script tags and get its content by defining our own callback function to handle it.
If you missed the first two parts of this article, you can find in Part I what is a shellcode, how it works and which are its limitations and in Part II you can read about the PEB (Process Environment Block) structure, the PE (.exe, .dll) file format and you can go through a short ASM introduction. You’ll need this information in order to properly understand Windows shellcodes.
In this last part of the shellcode development introduction, we will write a simple “SwapMouseButton” shellcode, a shellcode that will swap left and right mouse buttons. We will start from an existing shellcode: “Allwin URLDownloadToFile + WinExec + ExitProcess Shellcode“. The shellcode name tells us a few things, such like it uses:
- URLDownloadToFile Windows API function to download a file
- WinExec to execute the file (executable file: .exe)
- ExitProcess will terminate the process running the shellcode