Wanna Laugh. . .?

So, this last week was hustling and bustling with stories of a malware outbreak, only this time it was a ransomware(WannaCry). There seemed to be red screens everywhere especially in UK, Germany, some in India, Russia too. Like any other ransomware this code used a (now) known exploit in Windows to takeover and finally encrypt user files. This was typically followed by a demand for bitcoins for decrypting the files back. Let's ignore the 'Killswitch' story here.

Looking at the bigger picture. Were these countries targeted? May be not. Despite so much loss and chaos, I am compelled to ask if this a Good thing...? May be not but you know May Be it is. I will come to that shortly.

One of the most important observations here is that the it was possible since the attackers used a recent critical vulnerability in Microsoft OS - Windows which affects many versions of the OS. There are multitude of issues reported for Windows and patched weekly by Microsoft but this was a special one. This was disclosed by a hacker group from the 'data they stole from the NSA’. What does this mean. It is a fact now that governments are researching to find such vulnerabilities for the purpose of warfare, espionage, snooping, etc and using the exploits as powerful tools for similar purposes. This is where the problem arises.

While I am against adhoc disclosure of vulnerabilities, this has happened often that security researchers and hackers do a 'Responsible Disclosure' for issues after a follow up that involves several months of notifying the vendors involved. And in return are neither acknowledged nor paid and even have to take the blame for it sometimes. Yes, they do it for free! However, when respectable governments do the same thing ('irresponsible non-disclosure'), they somehow are above all ethics. Yes, we all know they can change their laws that govern the system.

The good part about a ransomware is you can quantify the loss (forget the chaos and mental agony, that’s priceless :)). This ransomware is known to have costed the world around $4 Billion by now.  It's time we honored the researchers who save us billions of dollars and immense trouble, by sharing issues in advance every year.

Coming to my first question and hence answer, it may be a good thing after all. The incidence has made us think about security. That it’s not just server admins or corporates but as people we need to be aware and be inclined towards a bit of critical thinking specially before sharing data or clicking on links and malware. As identities grow faster in the virtual world of internet, we need to protect ourselves as responsible citizens. Remember, there are no boundaries in the internet. And unlike typical wars fought on the ground, attacks in this space can be from anywhere. It may not always be what it seems like.

Of course, there is no reason for paranoia. If governments become irresponsible, people will need to be more responsible. In general, do some housekeeping. Keep Calm and Patch your OS and software. You can automate this, if it’s too much of a task. Be careful with what you are clicking (avoid if not necessary). And, simply put be a 'minimalist' when it comes to your data. Play Safe and have fun responsibly.

Note: For those interested in technical analysis of the ransomware, more details can be found in Endgame's blog here.

Exploit CSRF via Non Standard HTTP Methods

CSRF in Non-Standard Methods

If you are into web application security or provide pen testing services, you would be aware of what CSRF is. As the name suggests, it is a vulnerability in applications where an application is not able to differentiate between a request from a legitimate user and a forged request from the attacker. Hence, the attacker can trick the victim (application user) while they are still logged into the application (i.e. during an active session), into submitting attacker specified request unknowingly to the application. The result is that the attacker can carry out unwanted transactions or events with the privilege of the victim.

Then are many ways of carrying out a cross site request forgery attack depending on the method used to send the request to the server.  The most common ones are generally those that use the GET and the POST HTTP methods respectively. Details around these are widely available. I will leave you to check this out using link below:

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

However, a site using other HTTP methods and can be affected by the CSRF as well. I carried out this interesting form of CSRF using PUT method in a vulnerable application that extensively used all kinds of HTTP methods.

In this article we’re going to evaluate how to exploit a CSRF vulnerability when the such unusual methods are involved.

 A standard CSRF via POST request:

Pre-requisites: The attacker should be familiar with the request structure and correct values, if any, to carry out the attack. The victim should be logged in with an active session for the attack to process successfully.

Below is the form that the attacker would put together to carry out CSRF if POST method was involved:

<html> <body onload='document.DEMO.submit()'> <form action='https://victim-site.com/api/add/billers' method='POST' name=’DEMO’>        <input type='hidden' name='name' value='csrftest'>        <input type='hidden' name='biller_ip' value='192.168.4.5'> </form> <b>Biller Added Successfully</b> </body> </html>

We are familiar with such requests. The above request form adds a biller to the user account.  In a real scenario, the attacker would hide all form elements from the victim behind another distracting page carrying out some unrelated function. However, she needs to provide correct Biller Name (e.g her billing agency) and Biller’s exact IP address.

Impact: In case of a banking application for example, the attacker could add her own biller name, Id/biller number and set Auto-pay to True, to add her bills to the victim’s account and let him pay the bills.

Nonstandard attack scenario: Using PUT and DELETE methods

Many applications these days make API calls and use specific web services which use methods such as PUT and DELETE and thus there is less chance of finding form based POSTS or GETS in a traditional way. Hence, for such JSON rich applications, the method of attack needs to be slightly different.

CSRF using PUT Request

Pre-requisite: To carry out CSRF via PUT requests, the website should allow cross origin resource sharing. (Otherwise, recent browsers would block these requests due to same origin policy rules). A simple way of identify requests/URLs that are attackable is when you get the below response to a normal request:

Access-Control-Allow-Origin: *      //CORS

Since most of the action events for my target used PUT/DELETE methods, I went ahead and found those of them vulnerable to CORS. Once that was done, it was a matter of formulating the attack request:

Below is a simple example I used to carry out CSRF for the add biller function discussed above that was originally submitted using PUT in the application:

<html> <script> function put() {        var x = new XMLHttpRequest();        x.open("PUT","https://victim-site.com/api/add/billers",true);        x.setRequestHeader("Content-Type", "application/json");        x.send(JSON.stringify({"name":"csrftest","regex":"192.168.8.34”})); } </script> <body onload="put()"> IP Added to Billers </body> </html>

Figure below shows the above form as loaded in the victim browser while he was still logged into the application:

 The application responds with the message that request was successfully processed and biller added.

 I verified the Billers list to confirm that the test biller had indeed been added.

 

A common mistake that happens when porting JSON requests that use PUT method to traditional form format is that JSON can involve extensive parameters nested in a complex way. However, errors such as below can guide your way to correcting the request sequence for the attack:

 

These must be represented in the correct order and grouping for the attack to happen. Also, for other similar methods such as DELETE, minor tweak in above request should work. I would like to know if you have carried out CSRF for DELETE requests in your experience. If yes, please leave them in the comments below.