Tag Archives: Attack

Cross-Site Request…Framing?

I admit, the title of this post is deliberately misleading. It’s really about Cross-Site Request Forgery (CSRF), but it does involve framing − just not the kind that you might be expecting.

Before jumping into the meat of things, let’s start off with an appetizer: What is Cross-Site Request Forgery? Rather than give you the “textbook” definition, I’ll just dive right into a real-world example.

Let’s say you visit http://www.news.test, and there is a logo on the homepage. Let’s also say that the logo is hosted at this address: http://images.example.com/newsLogo.jpg

When your browser loads the page at http://www.news.test, it’s likely you’ll see an image tag similar to the following: <img src=”http://images.example.com/newsLogo.jpg” />. When your browser renders that image, it must first place a request to images.example.com in order to retrieve the newsLogo.jpg resource. There’s certainly no harm in this, but for the sake of argument, we can confidently conclude that the www.news.test website forced your browser to place a request to images.example.com without your knowledge or explicit consent. Right?

Now, let’s suppose you visit http://www.news.test again, but this time there is an image tag that looks like this: <img src=”http://yourbanksite.example.org/transferMoney.php?toEmail=attacker@attacker.example.net&amount=99999.00″ />. As in the example above, when your browser loads the page at www.news.test and attempts to render the image tag, it is going to place a request to http://yourbanksite.example.org/transferMoney.php?toEmail=attacker@attacker.example.net&amount=99999.00. Your browser will place the malicious request without your knowledge, and if you are authenticated to yourbanksite.example.org when you visit www.news.test − assuming the yourbanksite.example.org web application is not protecting against a CSRF attack − your life savings and kid’s college fund will be gone in a flash.

This kind of attack succeeds because of a flaw in how the Internet inherently works. When your browser places a request to another site, any cookies that exist for that site are sent along with that request. Since authentication is typically handled through cookies, and your cookies are sent along with the malicious yourbanksite.example.org request, the yourbanksite.example.org application is going to see the request, recognize it as coming from an authenticated user (you), and thus honor/process the request.

There are more things to consider in this type of attack, but for the scope of this post, that’s all you really need to know now. While a CSRF attack is typically used to exploit an application that the victim is authenticated to, for the sake of what I’ll be discussing below, I’m more interested in the fact that a CSRF attack can be leveraged to force a victim’s browser to place arbitrary requests.

For additional reading material on CSRF, see this post on WhiteHat’s stance on CSRF, and the Web Application Security Consortium’s page on CSRF.

Ok… appetizer digested? Now for the main course…

Information is everything. It’s power. Privacy within Web applications, especially social media applications, is a war zone because information is such a profitable and appealing target. The smallest pieces of information − or *mis*information − in the wrong hands can cost you your identity, your job, or even your freedom.

Wherever there is a massive data flow of information, there is inevitably going to be monitoring and tracking. From advertising networks, to law enforcement organizations, to intelligence agencies, there is no shortage of people who are interested in obtaining information about you. I’m not just talking about your personal information, such as name, address, and phone number; I’m also referring to your browsing history, your social network engagements, and the kind of content you publish to, and consume from, “the cloud”.

Imagine your spouse or your boss opening up your browser’s history. Would you be concerned about what he/she sees?  Or perhaps the FBI confiscates your computer without warning.  Would you be worried about what they’d find?  Hopefully, the answer to both of those questions is “No”. But what if there was enough incriminating browser activity that you lose your job? Or a warrant is issued for your arrest? Or you even get labeled an “enemy combatant”?

Sounds kind of absurd, right? Well, how else would you explain your Google searches for “homemade explosives” and “President Obama upcoming trips”? Or your visits to underground child sex trafficking sites? Or your posts made to pro-Al Qaeda message forums? It would seem like you’ve been up to a whole lot of no good!

You may protest, “I would never do such things!” My point is that through the use of Cross-Site Request Forgery, an attacker can populate your browser’s history with all kinds of unpleasant Web traffic. Not to mention that the requests would actually be originating from, and traveling through, your home or office network. In fact, if you are lured to a malicious page and stay on it for more than a brief period of time (perhaps to watch an interesting 10-minute video), an attacker can simulate real, human behavior by spacing out the incriminating requests so the traffic resembles that of someone actually clicking on links and spending time on questionable pages (rather than have all malicious requests placed in rapid succession).

“But wait,” you say, “isn’t there a way to distinguish CSRF traffic from legitimate user traffic?” Well, the malicious requests will likely have a ‘Referer’ header set to the URL of the page where the attacks originated from, such as: “Referer: http://attacker.example.com/csrfattack.php”; however, consider the following:

1. The ‘Referer’ header is not tracked in your browser’s history, so that won’t help you in court.
2. Although I’d need to actually research how much detail is tracked by ISPs, government agencies, etc., I suspect that the ‘Referer’ is among the lesser-tracked items.  Besides, even if ‘Referer’ is tracked, an investigation would still be required to determine that the traffic was spoofed, and that’s a headache all on its own.
3. It may be possible to spoof the ‘Referer’ header by exploiting flaws in common technologies such as Java or Flash.
4. It is trivial to strip the ‘Referer’ altogether (kudos to Jeremiah Grossman for the tip).

The bottom line is, falling victim to this kind of CSRF attack can, at the very least, be an enormous inconvenience and a hassle to clear up. At its worst, being framed in this way − even if you’re eventually shown to be innocent − could destroy your reputation, your marriage, your career. False accusations can tarnish even the most innocent person’s reputation, especially if that person is a prominent figure and the media gets involved.

We live in an amazing age where information − and especially “news” − spreads like wildfire. With social media apps connecting billions of people worldwide − I’m thinking of Twitter in particular − breaking news can hit your cell phone before it even crosses a news anchor’s desk. If a celebrity, politician, or other public figure were to be targeted by this type of CSRF attack, his or her life could become exceedingly complicated − very quickly.

Consider the upcoming 2012 election: Such an attack could be just what a candidate needs to derail an opponent’s campaign progress. By the time the victim could prove the allegations false, the election could be long over!

Our world is rapidly changing, and each new generation becomes even more submerged in the technological realm than the one before. The more immersed in technology we become as a society, the more sophisticated and damaging attacks on our privacy and personal information will become. For example, it’s only a matter of time before hackers start getting into your fridge.

How long have you been reading this post? Five, maybe ten minutes? Did you switch over to another tab for a while half-way through? Or maybe you got up for a bit to get some food? Better check your browser history… you never know when − or from where − a CSRF attack might originate…

Who Has Your Credentials?

One day I was perusing a client’s site during a business logic assessment, watching in my proxy history for anything interesting, when I noticed something peculiar after logging in. I saw two POST requests, both containing my credentials, but posting to two different URLs. The first request was an authentication script, such as /validateLogin, and it looked like it belonged.  The second, however, made no sense at all: It was posting to the /terms-and-conditions page. With my “hacker sense” tingling and my curiosity piquing, I dug deeper.

When I tried to replicate the odd behavior, I didn’t get the same results. This time it posted to the /validateLogin and /login pages, but nonetheless it still generated two requests. As it turns out, the first request was being generated by JavaScript when the login button was clicked. The second request, however, resulted from the form submitting normally after the JavaScript failed to return a “false” value and abort the default submission process. The form’s “action” attribute would hold the key.

During the most recent test, the value of “action” was simply an empty string, and therefore the value posted back to the same page. However, when compared to the initial request that sparked my interest, the “action” attribute was set to “/terms-and-conditions”, which, lo and behold, was the page I had visited immediately prior to accessing the login page. Sure enough, a quick test confirmed that the form’s “action” was being populated from the “Referer” header.

I assumed the JS-generated POST was part of an upgrade to the application’s authentication system, and the original method for logging in wasn’t properly retired. Regardless, the fact remains that at some point in time, the developers decided to trust the “Referer” header and use it as part of their authentication mechanism.

And while I’m interested to know how often the “Referer” is used this way in the wild, it brought to light a bigger issue: You can’t trust any part of a request.

From a development perspective, major frameworks give developers access to various aspects of a request object through identifiers and properties, such as Request.Headers (C#).  From a hacker’s perspective, using Burp Suite for example, every bit (literally) of a request is easily manipulated and open to attack.

Your everyday Internet user, Joe Schmo, is only going to have control over the URL and (maybe) some GET/POST parameters while interacting with a web app using his browser.  He’s unlikely to intentionally tamper with cookies, headers, or any other part of the request.

However, attacker Billy Bob will exercise direct control over every byte of the request if doing so results in some form of lulz or profit.  The request method, path, query string, HTTP version number, headers, and body are all fair game in the world of hacking.  As a developer, the moment you trust any piece of that request, you open yourself up to attack.

In my above example, with the “Referer” header being used as the action for the login request, a working exploit was trivial.  As a proof of concept, I simply created a page that auto-redirected to the vulnerable login page.  That’s it.  Well, mostly.

I sent the link to my target victim, my boss, and made sure my redirection page captured any login data that got posted back to it.  I wish this part of the story had a more interesting ending, but my boss knows better than to click on links I email him, so it didn’t really play out.  In the real world, however, if this application’s login page ever made its way onto a Google search results page, for example, any users following that link and logging in would wind up posting their credentials back to Google.

While it’s not difficult to exercise a certain amount of control over the “Referer” header when trying to actively exploit another user,  not all parts of a request are easily spoofed.  However, just because something can’t be done today doesn’t mean it won’t be doable tomorrow.  New web technologies − and their corresponding vulnerabilities − change the threat landscape regularly.  It’s more like a raging ocean than a solid-sounding “landscape”.

As web technologies become more advanced, and attacks get more sophisticated, the issue of trust becomes all the more important.  The safest position is to never trust any data, whether it’s perceived to be “user input” or not.  Put safeguards in place for everything, because you never know where an attack will come from next.

The 3:00 A.M. Incident Response Phone Call − A Success Story

It’s 3:00 A.M., and you receive the dreaded IR phone call. Your CSO is demanding an immediate response to an attack on your company’s resources. Dreary and lethargic, you stumble out of bed and VPN into your network. You pull up your centralized log management and see that there have been literally thousands of requests to your website in the span of time that typically sees between 50 and 100 requests. You feel your heart rate pick up, your palms get damp….

You’re under attack.

You begin rummaging through your network changelogs for the past twenty-four hours, attempting to see if there have been any major changes to the infrastructure or major software roll-outs across the network. But you find there have been no network changes, and no previously unvetted software updates have been pushed. “Damn,” you mutter to yourself, “if only the problem were that easy to identify….”

Your fingers flash across the keyboard in a rush as your Chief of the Network Operations Center floods your instant messenger with requests for updates.

C-NOC: “I guess since you’re up at this ungodly hour, CSO has you running IR for the breach?”

Me@3: “Yeah, any word from the network side? Hopefully we’re not seeing any data exfiltration from internal, right?”

C-NOC: “No, just a metric ton of smtp requests coming from the log management…. What alert controls did you have in place in case of an attack?”

Me@3: ”Crap, sorry  John, guess I forgot to put the alert mail cap in place…wait a second, I have to go, John. I totally forgot to check one of the most obvious things!”

C-NOC: ”Ha, you forgot to check the WAF? Noob 😛 “

{C-NOC John has disconnected}

You have to love an environment where even the most severe problems result in good-hearted ribbing between colleagues.

You quickly surf to the URL where your WAF typically resides, and find the elegant interface filled with thousands of requests, which appear to be the result of someone running a fuzzer against the account information pages. It seems as if someone is attempting to SQLmap to iterate through all possible injections.

You laugh maniacally to yourself and lean back in your office chair, thoroughly satisfied with your department’s preparations for this very problem.  Just three weeks ago, you completed the transition from raw user interaction with the SQL database to a more secure parameterized transaction. As you pour yourself a bowl of cereal, you begin mentally drafting the incident report to your boss.

It’s going to be a good day.