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
If you missed the first part of this series, where you can read about what is a shellcode and how it works, you can find it here: Part I. In this part, I will cover required information in order to be able to properly write a shellcode for Windows platform: the Process Environment Block, the format of Portable Executable files and a short introduction to x86 Assembly. This article will not cover all the aspects of these concepts, but it should be enough in order to properly understand shellcodes.
Process Environment Block
Within Windows operating system, PEB is a structure available for every process at a fixed address in memory. This structure contains useful information about the process such as: the address where the executable is loaded into memory, the list of modules (DLL), a flag specifying if the process is being debugged and many others.
It is important to understand that the structure is intended to be used by the operating system. It is not consistent across different Windows system versions, so it may change with each new Windows release, but some common information has been kept.