WhiteHat Security Blog

WhiteHat Security @ RSA — To Host an Interactive Twitter Session

andrew.daniel — Thu, 23 Feb 2012 01:24:42 +0000

Jeremiah Grossman (@JeremiahG), CTO at WhiteHat (@WhiteHatSec), is slated to host a virtual discussion (or “Twitter Party”) via Twitter that will focus on the topic of aligning security budgets with the needs of today’s businesses. Scheduled for Tuesday, February 28th from 11AM-Noon PT, the session will utilize the hashtag #WHatRSA and feature several prizes for participation.

Game Rules:
You must follow @WhiteHatSec
Utilize the hashtag #WHatRSA
Engage in the topic and be an active participant

*One point will be awarded to each participant for every tweet they submit using the #WHatRSA hashtag.
*Participants with the same number of points at the end of the session will have their names entered and drawn from a hat.

Prizes include:

Beats Solo HD (PRODUCT) RED High Definition On-Ear Headphones with ControlTalk
Monster iBeats™ Headphones with ControlTalk™ From Monster® In-Ear Noise Isolation
24 pack of Red Bull
WhiteHat “Hack Yourself First” t-shirt
VIP pass to WhiteHat’s 3rd Annual Cocktail party at Osha Thai Restaurant

In addition to the interactive session, WhiteHat’s Jeremiah Grossman will speak about large-scale increases in website breaches over the course of the past year and the need for application security testing in agile development environments. He will also be participating on a panel debating best practices in addressing security challenges for modern web technologies. Other members of our team will be presenting at the Cloud Security Alliance Summit at RSA and the BSides San Francisco event.

For those unable to attend the Twitter Party or in-person conference sessions, Grossman will be at Akamai Technologies’ vendor booth to discuss combatting prevalent Web attacks.

What, Who, When & Where:

Conference Sessions:
- WhiteHat Security Overview
  - Speaker: Stephanie Fohn, president & chief executive officer, WhiteHat Security
  - Monday, February 27th
  - 10:15am PT – 10:30am PT
  - AGC Conference – The Westin San Francisco
  - 50 3^rd Street, San Francisco, CA
- Cloud Innovation – The Panel’s View on the Next Generation of Cloud Security Devices and Services (Panel Session)
  - Panelists:
    - Philippe Courtot, chief executive officer, Qualys Inc. (Moderator)
    - Matt Johansen, threat research center manager, WhiteHat Security
    - Don Godfrey, security consultant, Humana (Representing Zscaler)
    - David Lingenfelter, information security officer, Fiberlink
  - Monday, February 27th
  - 11:30am PT – 12:30pm PT
  - Moscone Center South, Gateway Room 102/103
- Hacking the Bank: 8 Post-Breach Points for Accurate Cost Analysis
  - Speaker: Gillis Jones, application security specialist, WhiteHat Security
  - Monday, February 27th
  - 2:00pm PT – 3:00pm PT
  - Children’s Creativity Museum
  - 221 4^th Street, San Francisco, CA
- Staying Secure in an Agile World (Panel Session)
  - Panelists:
    - Chenxi Wang, vice president & principal analyst, Forrester (Moderator)
    - Jeremiah Grossman, chief technology officer, WhiteHat Security
    - Ido Breger, product manager, F5 Networks
    - Joel Scambray, managing principal, Cigital, Inc.
  - Tuesday, February 28th
  - 3:50pm PT – 5:00pm PT
  - Moscone Center, Room 302
- Web Breaches in 2011 – “This is Becoming Hourly News and Totally Ridiculous”
  - Speaker: Jeremiah Grossman, chief technology officer, WhiteHat Security
  - Friday, March 2nd
  - 9:00am PT – 9:50am PT
  - Moscone Center, Room 103

Online Session:
- Shifting Security Budgets in 2012
  - Tuesday, February 28th
  - 11:00am PT – 12:00pm PT
  - Follow: @WhiteHatSec , @JeremiahG and #WHatRSA

On the Show Floor:
- Akamai Technologies
  - Wednesday, February 29th
  - 2:00pm PT – 2:15pm PT
  - Moscone Center, Booth 851

To learn more about RSA, other events WhiteHat Security will be attending and registration information, visit the WhiteHat Security Events page.

In Your Oracle: Part Two

Justin Barron — Fri, 17 Feb 2012 17:00:55 +0000

In Micheal‘s previous post, ‘In Your Oracle: The Beginning‘, he introduced a blind SQL Injection vulnerability that a client was asking us to dig deeper into. The client wanted us to do this, because while they recognized that the vulnerability was real, actionable, and a threat – especially to their users – they weren’t convinced of its severity. Instead, the client claimed that the vulnerability could only be leveraged to read data already intended to be accessible by the logged-in user. In other words, the SQL query was executing within the context of a low-privileged database user.

A quick aside: I had a different client who recently downplayed the severity of an SQL Injection vulnerability because the result set was being parsed and formatted before being incorporated into the response. Because of this behavior, they didn’t think any data could be accessed other than what was intended to be parsed and formatted into the page. Aside from being able to UNION other data into the result set, or simply to brute force dropping tables, I introduced the client to something Micheal touched on in his post: The true/false/error condition. More on this in a minute.

The Vulnerability

The vulnerability that Micheal and I were digging into did not involve the entire result set being output to the page, so we couldn’t simply UNION other data and get it all dumped back to us. That’s because the application would execute an SQL query – using an ID that was being supplied in the query string – and the first row of data returned by the query would be used to determine the response. Therefore, we could only return a limited amount of data at a time, and that data would have to conform to certain data types – otherwise, the page would error out.

Here’s an example of what the back-end SQL query may have looked like (though, in reality, it was much more complex than this):

SELECT * FROM listingsData WHERE id='504'

And an example of the URL we were injecting on:

http://example.com/somepage?id=504

And last, but not least, an extraordinarily simplified example of the output from the page:

Listing ID: 504 Listing Entity: Acme, Inc. Listing Data:

The True/False/Error Condition

When an SQL Injection vulnerability can’t be leveraged to just dump rows upon rows of data, a true/false condition can allow an attacker to fuzz the database, and determine the table and column names, the cell values, and more. Basically, with a reliable true/false condition, an attacker can brute force the entire database in a practical amount of time.

However, due to strange behavior from the application (plus what we suspected was a complex query syntax that we couldn’t discern), we were not able to simply append our own WHERE clause condition, like this:

http://example.com/somepage?id=504'%20AND%201=1%20AND%20''='

We were, however, able to perform string concatenation. Injecting id=5'||'0'||'4 would give us the same response as id=504. We also discovered that id=54 would result in the following response:

Listing ID: Listing Entity: Listing Data:

Furthermore, we found that a syntax error, such as what id=' would cause, produced the following response:

An error has occurred. Please try again.

In Oracle, there exists a dummy table called ‘dual‘. We were able to use this table, in combination with string concatenation and a sub-query, to establish a boolean condition:

http://example.com/somepage?id=5'||(SELECT%200%20FROM%20dual%20WHERE%201=1)||'4

The URL encoding makes it look messy. Here’s the URL-decoded version of our injection:

5'||(SELECT 0 FROM dual WHERE 1=1)||'4

Because the WHERE clause of our sub-query evaluated to TRUE, the SELECT would return a zero, which got concatenated with the 5 and 4, and became 504. This injection resulted in Acme, Inc.’s information being returned in the page, and became our TRUE condition.

Now consider this injection (URL decoded for readability):

5'||(SELECT 0 FROM dual WHERE 1=0)||'4

Because the WHERE clause evaluated to FALSE, the SELECT returned nothing, which got concatenated with 5 and 4, and became 54. This injection resulted in blank listing data in the response, and was considered to be our FALSE condition.

The TRUE condition let us know when the WHERE clause of our sub-query evaluated to TRUE, and the FALSE condition told us the inverse. The error condition (described a few paragraphs above) let us know if there was a syntax error in our query (possibly due to characters being unexpectedly encoded).

Now that we had established a reliable true/false/error condition, we could start having some fun.

The Good Stuff

We were able to use the true/false condition to brute force some pieces of information that we figured the client did not intend logged-in users to obtain, such as the database name (from this point forward, all injections will remain URL-decoded for the sake of readability):

5'||(SELECT 0 FROM dual WHERE SUBSTR(SYS.DATABASE_NAME, 1, 1) BETWEEN 'a' AND 'z')||'4

The above injection took the first character of the database and determined if it was a lowercase letter. If true, we’d get Acme, Inc.’s data in the response; if false, we’d get blank listing data.

We could quickly brute force each character by cutting our BETWEEN range in half for each test. For example, if the above injection resulted in a TRUE condition, then we could figure out which lowercase letter the database name started with by using the following process:

Cut the range of characters in half:

5'||(SELECT 0 FROM dual WHERE SUBSTR(SYS.DATABASE_NAME, 1, 1) BETWEEN 'a' AND 'm')||'4

If the above resulted in a TRUE condition, then we knew the letter was between ‘a’ and ‘m’, and could then test for it being between ‘a’ and ‘g’. If the above resulted in a FALSE condition, then we’d drill down into the ‘m’ through ‘z’ range. In either case, we kept narrowing the search range until we were able to pinpoint the correct character.

We could then brute force the rest of the database name characters by incrementing the second parameter of the SUBSTR function (2 for the second character, 3 for the third, etc). If we incremented the parameter and got an error condition as a result, we knew we had surpassed the length of the database name.

We could also pre-determine the length of the database name with a similar “test and drill down” technique with this injection:

5'||(SELECT 0 FROM dual WHERE LENGTH(SYS.DATABASE_NAME)>10)||'4

Once we had brute forced the entire value, we verified our finding with this injection:

5'||(SELECT 0 FROM dual WHERE SYS.DATABASE_NAME='dbmaster01')||'4

We were able to extract information from other tables, too, such as:

5'||(SELECT 0 FROM SYS.USER_USERS WHERE SUBSTR(username, 1, 1) BETWEEN 'a' AND 'z')||'4

Using this method, we were able to extract various pieces of information, such as the database name, database user (which the query was being executed with), database user ID, and default table space. However, Micheal and I were not happy stopping there. With the help of pentestmonkey.net, we discovered some interesting Oracle features that gave us some juicy insights into our client’s network.

The Juicy Stuff

Oracle has a couple of variables that allowed us to extract the server’s internal hostname and IP address: UTL_INADDR.get_host_name and UTL_INADDR.get_host_address, respectively. Using the same brute force technique described above, we were able to successfully extract the hostname/IP and verify our findings with the following injections:

5'||(SELECT 0 FROM dual WHERE UTL_INADDR.get_host_name='srvdb01')||'4 5'||(SELECT 0 FROM dual WHERE UTL_INADDR.get_host_address='10.1.20.5')||'4

What we found even more interesting was the fact that UTL_INADDR.get_host_name would accept a parameter – an IP – and would allow us to basically perform DNS queries through the SQL Injection vulnerability:

5'||(SELECT 0 FROM dual WHERE LENGTH(UTL_INADDR.get_host_name('10.1.20.6'))>0)||'4

If the above resulted in a TRUE condition, we knew the IP resolved successfully, and we could proceed with brute forcing the hostname. If the result was a FALSE condition, we’d presume the IP to be invalid.

Micheal and I, being the PHP fans that we are, collaborated with each other to automate the entire process. Several hundred lines of code later, we were able to quickly harvest dozens of internal IPs and corresponding hostnames – information that would come in quite handy for a network-level attack, or even for a social engineering approach (“Hi, I’m Matt from IT. I’m having trouble logging in to srvdb01 at IP 10.1.20.5. Is the root password still “qSSQ[W2&(8#-/IQ4b{W;%us”?).

Conclusion & Take-Aways

Never assume that you know the full extent of the threat that a vulnerability represents to your organization. While you can reach a particular level of confidence in your knowledge and understanding of the situation, you never know what new and imaginative avenues of attack or combinations of techniques an attacker may discover or create – like mapping out your internal network through an SQL Injection vulnerability.

“Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world, and all there ever will be to know and understand.” -Albert Einstein

Top Ten Web Hacking Techniques of 2011

Jeremiah Grossman — Tue, 14 Feb 2012 16:49:44 +0000

Every year the Web security community produces a stunning amount of new hacking techniques published in various white papers, blog posts, magazine articles, mailing list emails, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and so on. Beyond individual vulnerability instances with CVE numbers or system compromises, we’re talking about actual new and creative methods of Web-based attack. The Top Ten Web Hacking Techniques list encourages information sharing, provides a centralized knowledge-base, and recognizes researchers who contribute excellent work.

How the winners are selected…

Phase 1: Open community voting (Ballot) [COMPLETE]

From of the field of 51 total entries received listed below, each voter (open to everyone) ranks their fifteen favorite Web Hacking Techniques using a survey. Each entry (listed alphabetically) get a certain amount of points depending on how highly they are individually ranked in each ballot. For example, an each entry in position #1 will be given 15 points, position #2 will get 14 point, position #3 gets 13 points, and so on down to 1 point. At the end all points from all ballots will be tabulated to ascertain the top fifteen overall. And NO selecting the same attack multiple times! (they’ll be deleted)

Voting will close at the end of the day this Monday, February 20.

[CLOSED] The more people who vote, the better the results! Vote Now!

Phase 2: Panel of Security Experts [IN PROGRESS]

From the result of the open community voting, the top fifteen Web Hacking Techniques will be voted upon by panel of security experts (to be announced soon). Using the exact same voting process as phase 1, the judges will rank the final fifteen based of novelty, impact, and overall pervasiveness. Once tabulation is completed, we’ll have the Top Ten Web Hacking Techniques of 2011!

Voting will close at the end of the day on Sunday, February 26.

Soon after the winners will be announced!

Good luck everyone

The Final 15:

Hundreds of votes were cast during the open vote — a great turn out. Thank you everyone for taking the time! 44% of the respondents were self-described “Breakers,” follow by 22% “Defenders,” 16% “Builders,” and 17% did not specify. There was a very smooth distribution of points totals across the range of entries. Clearly everyone had their favorites. Of course we saw a lot of ballot stuffing action, which required a substantive amount of clean-up, but when ranking a Web hacking techniques’ its kind of what you expect This is exactly why we have a final 15 process first, so the top ten outcome isn’t negatively affected. Any entries that obviously don’t belong in the top ten are easily eliminated during the “Panel of Security Experts” phase. Now it’s the judges turn to have their say!

The Big List:

Web Browser Defense-in-Depth: 3 Layers is Good, 5 is Better

Jeremiah Grossman — Mon, 13 Feb 2012 02:06:24 +0000

Defense-in-Depth is an approach to security emphasizing that if any particular layer of defense fails, at least one more overlapping layer is present to take over. Defense-in-Depth limits single points of security failure and increases the difficulty for an attacker to compromise a system.

A simple example of Defense-in-Depth is protecting a PC from remote compromise by keeping the machine up-to-date on patches AND surrounding it with a firewall. Should a firewall fail for some reason, the PC remains resilient against remote exploitation because it is properly patched. If the PC falls behind on its patches, which frequently happens, a well-configured firewall protects against compromise by denying inbound connections.

Web browsers also have a notion of Defense-in-Depth, but the major vendors don’t ship them with as many layers as they could (or should?). By my count, Chrome installs with three layers. Fortunately, with a simple configuration change and installing a specific add-on, anyone can add two more layers of defense and dramatically improve their protection against browser exploitation and PC malware infection. Before discussing the specifics, we should first describe the attack pathology we’re defending against.

A very common way malware is propagated is by visiting “infected” websites. Infected websites could be hosting the malware package itself, or including it as part of third-party Web page content, like an advertisement. When a browser, such as Chrome, visits an infected website it could be exploited via an unpatched software flaw. It is also possible, if not typical, for the exploit to target an installed browser plugin like Flash. We pick on Chrome and Flash only because they provide extra layer of defense that the other browsers and other extensions including Java and Quicktime do not. A sandbox.

To successfully compromise a Chrome browser with five layers of Defense-in-Depth, the attacker must overcome:

1) Phishing and malware detection

“Phishing and malware detection,” enabled by default in Chrome, gives users an interstitial warning that, “Visiting this site may harm your computer.” This is essentially a curated blacklist of dangerous websites and is by no means ever complete. For an attacker to bypass the phishing and malware layer of defense, one of three things would have to take place:

Their victim would have to manually disable this setting in the preferences, which is unlikely yet possible.
Their victim must REALLY wants to see the dancing monkey on the next screen and is willing to risk infection to do so. As we know, people click past warning screens all the time.
The attacker plants their malware in a location that evades, even temporarily, detection by Google’s and their partners. Certainly possible.

It is prudent to assume one of these three scenarios may transpire and the layer of defense will fail, so we need another.

2) Ad Blocking

Instead of setting up their own infected websites, or compromising otherwise legitimate websites and injecting them with malware, malware purveyors commonly purchase advertising impressions and use them to mass distribute their wares to a potential victim. Malicious advertisements are often referred to as “malvertisements.” Millions of malvertisements can be purchased for mere dollars and this is where ad blocking, with extensions such as Ad Block and Adblock Plus, prove highly effective.

Ad blocking extensions, which do not ship with a mainstream Web browser, prevent HTTP requests from being sent to well-known advertising networks and downloading potentially malicious content. If your browser doesn’t download a malvertisement, then it obviously can’t be exploited by it. With ad blocking, a Web browser may remain unscathed even while visiting a website currently infected by malvertisements. So, not only does ad blocking make for a more pleasant user experience, it makes surfing the Web much safer!

Since ad blocking is itself a black list, a malicious ad could potentially slip through, and if so, another layer of defense is necessary.

3) Plug-in Blocking

As mentioned earlier, malware exploits are well-known for targeting Web browser plug-ins/extensions such as Flash, Java, Quicktime, and others that auto-execute by default when called by a website. Theoretically, if extensions did not auto-execute, extensions could also not be auto-exploited. To make this theory a reality, in Chrome you can disable the auto-execution of plug-ins.

Wrench > Preferences
Under the Hood > Privacy
Click the “Content Settings…” button
Scroll down to “Plug-ins” and select “Block all.”

Now for Flash, Java, or Quicktime, etc files to play, a user must specifically allow it with additional clicks.

Normally, extension-based exploits that lead to malware are embedded invisibly so their victim doesn’t see them, especially in malvertisements, which means there is little reason to click to allow them to play. This also means if there is a movie on the screen, or something else that you really want to see, it should be safe enough to allow — but not always. So, something malicious might still find a way to load and another layer of defense is necessary.

4) Software Security & Auto / Silent Patching

Google (maker of Chrome), and Adobe (maker of Flash) have invested extraordinary amounts of resources to improve the security quality of the software they ship. Despite their best efforts, software flaws will remain, often found by outsiders, and their products will need to be patched frequently. Patching frequency leads to patch fatigue and without help, every user falls behind eventually.

To help, Google and Adobe ship with an integrated auto and/or silent update feature for their software. Chrome and Flash regularly check on their own accord if they need to be patched so users don’t have to remember. Doing so has proved measurably effective in keeping users up-to-date on their patches and by extension, secure. However, it is possible for attackers to slip an exploit within the window of time before a would-be victim patches, or they may leverage a zero-day exploit for which no patch exists. This brings us to our last layer of defense-in-depth.

5) Sandbox

A sandbox is a software security wrapper that encompasses both Chrome and the Flash plug-in in a highly-restricted, low-privilege environment. Java and Quicktime do not have a sandbox, but they should. Firefox is working on theirs. Should an attacker leverage an unpatched exploit, or one for where no patch exists, they’ll need another exploit that allows them to breach the sandbox. This means the attacker will need two exploits instead of just one. This is another significant hurdle to overcome because with present security offense knowledge, sandboxes are notoriously difficult to escape.

For an attacker to succeed in infecting a users PC with malware via the Chrome browser, they’ll have to somehow overcome five layers of Defense-in-Depth…

First, the attacker must keep their malware off black-listed sites or have the malware in a location attractive enough where the victim is convinced to manually ignore all the big red warning signs.

Second, upon landing on the infected Web page the malware must NOT come from a well-known advertising network, but if so, the victim must be enticed to specifically allow the ad to load.

Third, should the malware try to exploit an extension, the victim must manually allow the extension to load, and the visible content must be attractive enough to convince them to do so.

Fourth, the attacker’s exploit must be newer or faster than Chrome and Adobe’s patch management system, or they’ll need to use a zero-day vulnerability.

Lastly, that attacker will need to exploit another vulnerability to escape the sandbox. Then, and only then, after bypassing all five layers of Defense-in-Depth will an attacker be able to infect a user’s PC with malware.

Collectively, when considering all these layers, Chrome users should be able to click on anything on a Web page that they want, which is the nature of the Web, and not become infected with malware. Of course there are several more speed bumps and layers to be added with other configuration settings and add-ons, but with these five, everyone can do it easily.

So, block all extensions and install ad blocking software. Happy clicking!

A Single-Site Browser’s impact on XSS, CSRF, and Clickjacking

Jeremiah Grossman — Wed, 08 Feb 2012 20:53:35 +0000

A Single-Site Browser (SSB) is a highly restricted Web browser only capable of connecting to a single website. A “website” can be defined as a white-listed collection of one or more hostnames, IP addresses, ports, and protocols. For example, the SSB may only connect to Yahoo Mail “*.yahoo.com”, Facebook “https://www.facebook.com,” or Bank of America “https://www.bankofamerica.com/” and nothing else. In addition to these hostnames, an SSB would likely also need to have entries for off-domain content delivery networks and any required third-party Web widgets, but you get the idea. With a Yahoo Mail SSB you could not visit Facebook and a Facebook SSB could not visit Yahoo Mail.

Practically no one in the marketplace offers SSBs, you have to build them yourself. When you think about it though, an SSB is functionally similar to a mobile application often provided by service providers very much like these. Often enough, a mobile app is basically a browser without a location bar, rendering a stripped down HTML/Javascript version of their website. SSBs are also very interesting from a security perspective as they have a profound impact on Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and Clickjacking attacks.

Hypothetically, let’s say I’m an average online user. My “important” online accounts are Yahoo Mail (email), Facebook (social network), and Bank of America (bank). These are the online accounts I REALLY don’t want hacked. I’m disciplined to only use these services, and more importantly, log-in to them with their respective SSB. All my other promiscuous Web surfing is conducted with a general purpose Web browser like Chrome, Firefox, and Internet Explorer.

Next, let’s consider a common attack flow for XSS. Assume I’m logged-into Twitter’s website with Chrome, and I click on a link from someone I follow — you know one of those shortened link things that are impossible to know if they’re safe. That link is a disguised (reflected) XSS attack targeting Yahoo Mail, Facebook, or Bank of America, aka the accounts I care about. If the XSS vulnerability is located on an authenticated section of the website, more than likely, I’ll get redirected and asked to log-in. Obviously I’ll know not to enter my username and password because that is only for that websites SSB. So, I’m safe and not auto-hacked.

If the vulnerability does NOT require authentication, I’ll get XSS’ed. While the attacker has a control over my browser, at least temporarily, he can’t steal my authenticated session cookies because they don’t exist on this browser. Unless I break my rule of logging-in without my SSB my “important” accounts remain safe.

What about CSRF? While using a general purpose Chrome browser I click on some random link, could be on a blog post, message board, or news story. This link sends my browser to a malicious website that attempts to CSRF me on Yahoo Mail, Facebook, or Bank of America. Chrome can always be forced to send forged HTTP request to whatever target website, the nature of CSRF, but since I’m not authenticated nothing will happen that will compromise or even adversely affect my “important” accounts. The exact same is true for a Clickjacking attack. Any XSS, CSRF, or Clickjacking payload a bad guy chooses to deploy is limited to unathenticated attacks, which can still be damaging, but the accounts I care about remain safe.

Now let’s assume I’m operating within an SSB on Yahoo Mail, a website that consumes and redistributes user-supplied content in the form of email. User-supplied content, email, could include some form of HTML/Javascript. Should that content execute Javacript inside the SSB where I’m logged-in to Yahoo, technically a persistent XSS vulnerability, the bad guy can do some real damage. The security benefits of an SSB in this context with respect to XSS are more limited. Technically the XSS payload can do anything I can do (ie read, send, delete email). Data exfiltration, such as stealing session cookies which can lead to account compromise, may also take place via the same mechanisms (email). What the attacker can’t do is chain multi-site XSS attacks.

Keep in mind, though, that allowing users to send HTML/Javascript content to each other is an inherently dangerous feature to begin with and fortunately it is not all that common on the highly trafficked websites outside of WebMail providers. For example, Facebook and Bank of America do not offer this functionality. As a result, persistent XSS vulnerabilities like the one previously described are rare.

Another beneficial aspect of SSBs is that if I click on an off-website link, it’ll simply open a new tab in my default general purpose browser. Any XSS, CSRF, or Clickjacking attack an off-website link tries is now separated from my SSB. That’s huge! However, if the link is on-website then I have to be careful as it could be a non-persistent XSS attack and do everything the early mentioned persistent XSS vulnerability could. A possible exception being calling in additional Javascript payload.

When everything is considered, the only time I can get my accounts compromised by XSS, CSRF, or Clickjacking is while I’m within the SSB. This dramatically cuts down my risk profile when traversing the Web. Suddenly general purpose browsing with Chrome, Firefox, and Internet Explorer become safer because sessions are separated by desktop application boundaries.

In Your Oracle: The Beginning

Micheal Cottingham — Mon, 06 Feb 2012 17:00:20 +0000

In the TRC, we cover the WASC in our search for vulnerabilities on the web. Among this large list of vulnerabilities is SQL injection. The TRC looks for error-based and blind SQL, and does various tests to verify the vulnerabilities found by both scanning and performing PE-level business logic assessments to create the Sentinel service.

Recently, Justin and I received a request from a client to dig deeper and show what could be done with an SQL injection vulnerability. This sort of thing isn’t uncommon, because clients often may want to show developers why a particular vulnerability is a problem, or to explain to upper management why more resources are needed to fix a particular vulnerability in an application.

Justin and I wanted to have some fun with this request. The vulnerability was a blind SQL injection that was particularly annoying to verify due to its behavior and various blacklisting already done. When I discovered and verified the vulnerability, I was able to fingerprint the database server as Oracle, based on the behavior of the SQL injection. Once we established a true/false/error condition that we could rely on, we started building out our exploits. First, we grabbed the database username, then we grabbed the database name. Next, we decided to take our investigation a step further and use some of Oracle’s network capabilities.

Programmatically, we were able to

You are probably wondering why I left that incomplete. Stick around for Part Two of this post to learn more about what Justin and I did next.

Who Would Want to Take Down the Internet?

Jeremiah Grossman — Tue, 24 Jan 2012 16:08:08 +0000

This is a question I often ask in response to those sounding the alarm that “hackers” can take down the Internet and that we all should be very worried. This is a warning I’ve seen consistently for years ever since The L0pht told the U.S. Congress they could take down the Internet in about 30 minutes. I’m not about to disagree with The L0pht’s claims, maybe they and others can, but more importantly I fail to see the motivation for why they, or anyone else fitting their profile, would want to. Interestingly enough, there is only one particular class of attacker where it would make sense to take down the Internet.

To break this down we’ll use Mikko Hypponen’s TED talk as a framework. Mikko did a fine job categorizing and articulating the three main types of online attackers. They are cyber-criminals, hacktivists, and national-state. While the hacking techniques they use might be very similar to each others, each group has a unique set of motivations that drive their actions.

Hacktivists, such as Anonymous, LulzSec and others are among those who leverage hacking skills as a means to promote a social or political message — a form of protest if you will. A hacktivist might deface websites, publish stolen sensitive data, perform targeted Denial of Service attacks, but by enlarge their agenda does lead them to take down the Internet. Quite the contrary. If hacktivists disrupted the Internet, they also couldn’t spread their message, nor could others receive it and join the protest. Not to mention hacktivists are notoriously heavy supporters of the Internet, a free and open Internet.

Cyber-criminals, all they want is to make money. As much money as they can get their hands on. Cyber-criminals will hack their way into online accounts, directly or via compromised end-user PCs, and steal whatever money and data of value there is. Cyber-criminals also may Denial of Service a website to extract some extortion money, but just like the hacktivists, taking down the Internet would only obstruct their ability to profit. If the Internet went down, it would actually cost them money as they would not be able sell access to their botnet farms.

This leaves us with national-state, a type of online attacker that is government backed, whose mission is the theft of intellectual property, intelligence gathering, and surreptitious command-and-control over as many critical systems as possible. National-state hackers would also not seem to want to take down the Internet because it would directly prevent them from continuing their mission, especially when their targets are other countries. They’d lose their surveillance capabilities. However, there are exceptions here, two very particular scenarios where national-state and taking down the Internet makes sense.

In the first scenario, a national-state attacker would take down an enemy countries Internet access as part of an active and kinetic military conflict. The Russia v. Georgia conflict back in 2008 serves as a good example. Russia was accused of attacking Georgian government websites in a cyber war to accompany their military bombardment.

In the second scenario, when national-state enemy is domestic in origin (i.e. the people), then taking down or severely limiting Internet access for the entire country can be used to suppress citizen dissent. There are reports of this having occurred in Egypt and Iran — massive surveillance, disruption of communication, and censorship.

So when you get right down to it, the only attacker with motivation to “take down the Internet” is government backed. Then in one of the two scenarios, if your Internet goes down your government will be responsible. For myself, as one always considering the most pressing day-to-day threats to Internet security, I’m less concerned if the Internet can be taken down, but what happens when it stays up.

Who are WhiteHat Security’s competitors? — It’s not who you think

Jeremiah Grossman — Tue, 03 Jan 2012 20:57:17 +0000

A significant portion of my travel schedule is dedicated to meeting with InfoSec teams at organizations large and small, mostly asking questions about the current status of their application security programs. From the interaction I learn A LOT about today’s most pressing challenges. Such as what strategies [really] work, which [really] don’t, and what direction things are heading. Budgetary resources, or the lack thereof, is easily the most commonly cited obstacle to progress, second only maybe to management & developer awareness, which is probably the root cause.

During the same discussions I’m often asked by prospective customers, industry analysts, and the media too, “Who does WhiteHat Security compete with?” Sometimes the question is asked to better understand how we’re different or what problems we help solve. Other times the question is about getting a clearer picture of where WhiteHat Security fits in the market. I typically answer with the names of the usual suspects, how they are either a desktop scanner or a billable hour consulting shop, while we’re a better, more efficient, scalable option as an on-demand subscription service. The more I repeat this, though, and the more of the aforementioned discussions I participate in, the more I find this answer wholly superficial and inadequate.

Here’s the thing. By the time serious application security planning takes place, when it comes time for organizations to invest real $ in executing a strategy, 90% or more of the InfoSec budget has normally already been spent or spoken for — spent protecting the network and hosts. Important layers such, but it also leaves just a tiny fraction of the pie available to address the biggest and most important problem the entire security industry is facing. Crumbs to protect the area of IT where the business invests the most money creating — software. Let me put this another way. Every firm, every person in the application security field, more directly competes with firewalls and anti-virus products.

The big security companies out there, the guys who peddle these products to those who purchase them out of habit or compliance mandate, also simply don’t “get” application security, nor do they care to. This is understandable since the overall application market is still too small for the mega-corps to care about. That’s just basic business economics. If one of their customers wants to invest in application security, to them that probably just means swapping dollars away from their firewall & AV cash cow, and zero net new revenue to them. Yet they’ll be happy to sell you an cheap widget, that is “better than nothing,” and/or toss it in as part of larger “enterprise” sale.

Organizations are starting to figure this game out though. They are asking why their firewall, anti-virus, and intrusion detection systesm didn’t protect their multi-million, multi-billion dollar Web-based business from getting hacked — for the the money or the lulz. With every breach headline, more are more are to realizing how little of what they spent 90% of the budget on is designed to do anything of the kind. This is precisely why I’m optimistic about change. 2012 is going to be an important year, a year where application security became too painful to ignore.

Cross-Site Request…Framing?

Justin Barron — Fri, 23 Dec 2011 16:00:36 +0000

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: . 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: . 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…

sIFR3 Remote Code Execution

Jason Calvert — Wed, 14 Dec 2011 21:38:49 +0000

WhiteHat Security Vulnerability Advisory

Affected Product: scalable Inman Flash Replacement (sIFR) version 3

Vulnerability: Cross Site Scripting

CVE ID: CVE-2011-3641

Affected Versions: sIFR3 r436 and prior

Vendor Homepage: http://wiki.novemberborn.net/sifr3/

Description: sIFR3 allows for the use of non-free fonts within a web application via Adobe Flash plugin. The sIFR3 module interfaces with an external JS file and utilizes the parameter “version” to ensure the two files are compatible. The textField that is displayed upon invalid input in the “version” parameter supports limited HTML rendering and allows for remote code execution. An attacker can render arbitrary images that execute malicious javascript and in Adobe Flash player 10.3 and prior include a large break space to remove the encapsulating error message.

Proof of Concept:

/cochin.swf?version=

Fix:

Recompile any affected modules with the latest release (r437) which can be obtained from the vendor’s website: http://dev.novemberborn.net/sifr3/nightlies/sifr3-r437-CVE-2011-3641.zip