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.
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.
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.
Clickjacking, the art of tricking users into clicking on links or buttons that no sane person would ever click on. But how much damage can you do by stealing a few clicks? We are in 2015, we might think that this kind of vulnerabilities would have been solved by now. But that’s not the case.
Recently Mozilla launched Firefox Hello, their free service for video and voice conversations online. After a few tests, I noticed that hello.firefox.com website does not prevent framing.
PHP Object Injection is not a very common vulnerability, it may be difficult to exploit but it also may be really dangerous. In order to understand this vulnerability, understanding of basic PHP code is required.
If you may think this is not an important type of vulnerability, please see the list below. Researchers found PHP Object Injection vulnerabilities in very common PHP applications:
And many others. There may be a lot of other undiscovered PHP Object Injections in these or in other very common PHP applications, so maybe you can take a coffee break and try to understand it.