Category Archives: Web Application Security

Anonymity or Accountability?

Over a decade ago, when I was just starting in the computer security scene, I went to a conference for managed security services providers as the sole representative for my company. Near the end of the day-long conference there was a large discussion in which people were asked, “If you could change one thing with a magic wand to have the biggest impact on security, what would it be?”

When it finally got to me, I said the only thing that came to mind, “Attribution.” I explained, “If I had a magic wand and could change anything to have the largest impact on security, I’d make it so that everything on the Internet could be attributed to people so that we could have accountability. If you knew the packet you sent would be tagged with the information necessary for someone to track you down, you’d be extremely unlikely to commit any crimes using the Internet.”

I know it’s impossible to do that, but it was a magic wand after all. But that’s not the end of the story. Over the years I have become a privacy “guy” insomuch as I take people’s privacy seriously. However, I also have one foot squarely in the world of banking, finance, retail and so on – where attribution is hugely important for security, and also as an unintended consequence *ahem* marketing. So as much as I’d love to have people live in a free and open society, we all know what a bunch of jerks people can be when they know there’s nothing at risk when they break the law.

On the flip side, 100% attribution is terrible for privacy when you’re not doing anything illegal, or if you are a political dissident. The very last thing our forefathers wanted when they were talking amongst themselves in pubs on the East coast, considering creating a new nation, was attribution. They saw fit to write amendments to the constitution to limit unlawful search and seizures, and to allow freedom of speech.

So on one hand you have freedom and on the other hand you have safety. I have taken to asking people: “If you had to chose only one, which would it be? Accountability or Anonymity? Do you ever want there to be a way for you to do something anonymously or not? Do you ever want to be at risk of not finding someone who had committed a crime or not?”

I am somewhat surprised to find that when given only the choice between one or the other, it has been nearly an even split amongst people I talk to – usually at conference – about which they’d prefer. Right now, we teeter on the brink of having no anonymity at all. With enough vulnerabilities that allow full compromises of millions of machines, and enough listening posts all over the world, anonymity is slowly but surely getting harder and harder to get. Look at the most recent busts of various Tor hidden services like Silk Road 2 – people whose livelihoods and freedom depend on privacy still can’t manage it.

Most people would say that drug dealers and arms dealers deserve to be behind bars, so good riddance, regardless of how it happened. However, what about Colorado? Last year, being in possession of marijuana would land you in jail. This year it won’t. So are we as a society willing to indiscriminately put people in jail for breaking the law, even when the law later turns out to be unjust and/or bad for society?

Or worse yet, what if our government moves into a second age of McCarthyism – where they hunt down those who engage in civil disobedience with untold masses of siphoned information to decide whom to jail and whom to leave alone? What if adultery suddenly became a felony? Thought crimes could be punishable in such a dystopian world — not a pretty sight either. Though your banking passwords would be safe, certainly. (Except from the government.)

Perhaps releasing certain types of criminals or forgiving certain types of crimes, as California is about to do, might be a worthwhile exercise. A certain level of crime, while seemingly bad, is critical to allowing for a free society. It’s a complex issue, and of course there is always a middle-ground, but I think to properly understand the middle ground you have to explore the edges. What would a perfectly accountable Internet bring? It would bring with it a near zero cyber-crime rate but also limited freedoms. What would a perfectly anonymous Internet bring? It would bring unfettered cyber-crime but unlimited freedoms. It feels like you’d want some sort of middle ground, but there’s no such thing as “somewhat anonymous” when your life depends on it.

While my younger self would have said that “attribution” was the key to security, I would now tell my younger self to look beyond security, and really contemplate what a completely secure society would look like. Maybe a completely secure society with attribution for every act isn’t such a great idea after all, I would warn him. There are probably no easy answers, but it’s a conversation that needs to happen.

Assuming for a second that there was only one answer, if you had to chose one, which would it be: anonymity or accountability? And more importantly, why?

#HackerKast 9: .NET Goes Open Source, “SChannel” Vulnerability and Browserstack’s Breach Report

“Oh. My. God. Becky, look at that .NET code”
Leading story of this week’s HackerKast was about Microsoft choosing to open source .NET on GitHub. This is a pretty huge deal and a bold move from the big wigs up in Seattle. The issue here? Everybody has access to the source code, good and bad people alike. Robert is a bit pessimistic, understandably so. The thing we all agree on is that right out of the gate starting today there will be new vulnerabilities found. The real question comes down to which side puts in more diligence in flushing out the low-hanging fruit first. After that, things will be mostly unchanged from the current state except with the added benefit of the community getting to find and even help fix vulnerabilities via pull requests.

Next, Jeremiah dug into a new breach report from the team over at Browserstack. Really cool service that if you’re not familiar with you should go check out. Turns out they were hacked by Shellshock, cleaned it up, did a post mortem, and (most importantly to us) published their lessons learned! Super interesting incident response writeup so go check it out. Side note: The other company I was referring to in the video was CodeSpaces going out of business due to their AWS getting hacked in a similar fashion.

Robert followed that up with an overview of some of the recent TOR news about the Silk Road clones getting taken down by law enforcement. The interesting point here is that none of us know for sure how the feds found the actual location of the TOR Hidden Services. TOR did a great job by putting out a response blog of possibilities of how these things got decloaked. The most AppSec related avenue of attack TOR mentioned was SQL Injection which could possibly be a cause of deanonymizing the server.

I rounded this week’s HackerKast out by getting the word out about the latest major Microsoft 0-Day. This time the culprit is the Secure Channel or “SChannel” package that is used to turn on SSL/TLS implementations on all sorts of Windows Server boxes going back to 2003. The bug found was a remote code execution and can lead to some seriously nasty compromise. Now that this has been announced and the severity is well understood, the attackers will be all over this in a matter of days so please go patch!

Resources:
Microsoft Security Bulletin MS14-066 – Critical
BrowserStack Explains The Hacking Attack With Honesty And Maturity
Both Of The Men Accused Of Running The Silk Road Made The Exact Same Mistake

#HackerKast 8: Recap ofJPMC Breach, Hacking Rewards Programs and TOR Version of Facebook

After making fun of RSnake being cold in Texas, we started off this week’s HackerKast, with some discussion about the recent JP Morgan breach. We received more details about the breach that affected 76 million households last month, including confirmation that it was indeed a website that was hacked. As we have seen more often in recent years, the hacked website was not any of their main webpages but a one-off brochureware type site to promote and organize a company-sponsored running race event.

This shift in attacker focus has been something we in the AppSec world have taken notice of and are realizing we need to protect against. Historically, if a company did any web security testing or monitoring, the main (and often only) focus was on the flagship websites. Now we are all learning the hard way that tons of other websites, created for smaller or more specific purposes, happen either to be hooked up to the same database or can easily serve as a pivot point to a server that does talk to the crown jewels.

Next, Jeremiah touched on a fun little piece from our friend Brian Krebs over at Krebs On Security who was pointing out the value to attackers in targeting credit card rewards programs. Instead of attacking the card itself, the blackhats are compromising rewards websites, liquidating the points and cashing out. One major weakness that is pointed out here is that most of these types of services utilize a four-digit pin to get to your reward points account. Robert makes a great point here that even if they move from four-digit pins to a password system, they stop can make it more difficult to brute force, but if the bad guys find value here they’ll just update current malware strains to attack these types of accounts.

Robert then talked about a new TOR onion network version of Facebook that has begun to get set up for the sake of some anonymous usage of Facebook. There is the obvious use of people trying to browse at work without getting in trouble, but the more important use is for people in oppressive countries who want to get information out and not worry about prosecution and personal safety.

I brought up an interesting bug bounty that was shared on the blogosphere this week by a researcher named von Patrik who found a fun XSS bug in Google. I was a bit sad (Jeremiah would say jealous) that he got $5,000 for the bug but it was certainly a cool one. The XSS was found by uploading a JSON file to a Google SEO service called Tag Manager. All of the inputs on Tag Manager were properly sanitized in the interface but they allowed you to upload this JSON file which had some additional configs and inputs for SEO tags. This file was not sanitized and an XSS injection could be stored making it persistent and via file upload. Pretty juicy stuff!

Finally we wrapped up talking about Google some more with a bypass of Gmail two-factor authentication. Specifically, the attack in question here was going after the text message implementation of the 2FA and not the tokenization app that Google puts out. There are a list of ways that this can happen but the particular, most recent, story we are talking about involves attackers calling up mobile providers and social engineering their way into accessing text messages to get the second factor token to help compromise the Gmail account.

That’s it for this week! Tune in next week for your AppSec “what you need to know” cliff notes!

Resources:
J.P. Morgan Found Hackers Through Breach of Road-Race Website
Thieves Cash Out Rewards, Points Accounts
Why Facebook Just Launched Its Own ‘Dark Web’ Site
[BugBounty] The 5000$ Google XSS
How Hackers Reportedly Side-Stepped Google’s Two-Factor Authentication

#HackerKast 7: Drupal Compromise, Tor + Bitcoin Decloaking, Verizon’s ‘Perma-Cookie,’ and Formula One Racing

This week Jeremiah Grossman, Robert Hansen and Matt Johansen discuss the latest around the recent compromise to Drupal which affects any Drupal 7 site that was not patched prior to Oct. 17. Also, Robert takes us to the Circuit of the Americas Track in Austin to talk a little about a Tor + Bitcoin can effectively decloak people and even allow users to steal all the user’s bitcoins. Also a topic of discussion this week: Verizon’s Unique Identifier Header, or UIDH (aka a ‘Perma-Cookie’) which can be read by any web server that you visit and used to build a profile of your internet habits.

Resources:
Assume ‘Every Drupal 7 Site Was Compromised’ Unless Patched By Oct. 15

Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine

Bitcoin Over Tor Isn’t a Good Idea

#HackerKast 6: Microsoft Takes Over No-IP, LASCON 2014 Wrap-up, Shopping Cart Software Security

This week Jeremiah Grossman, Robert Hansen and Matt Johansen talk about interesting news and talks out of LASCON as well Microsoft taking over small Internet service provide No-IP and @mattjay gloats about taking the top spot in the recent WhiteHat HackerKombat competition with the most individual flags captured.

Resources:
How Microsoft Appointed Itself Sheriff of the Internet

‘Spam Nation’ Publisher Discloses Card Breach

#HackerKast 5: POODLE Attack, HackerKombat and Drupal SQLi Flaw

This week Jeremiah Grossman, Robert Hansen and Gabe Gumbs host HackerKast at Levi’s Stadium – the home of the SF 49ers – to discuss the recently announced POODLE Attack on SSL 3.0 and a critical SQLi flaw affecting Drupal making headlines. WhiteHat’s 6th HackerKombat capture the flag competition will also stream LIVE on Twitch.tv.

Watch HackerKombat LIVE starting at 3 pm PT on 10/17:
http://www.twitch.tv/hackerkombat

Other Resources:
POODLE Attack Information:
https://blog.whitehatsec.com/what-you-need-to-know-about-poodlessl-3-0-vulnerability/
http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
https://www.openssl.org/~bodo/ssl-poodle.pdf

Drupal SQLi Flaw Advisory:
https://www.drupal.org/SA-CORE-2014-005
http://news.techworld.com/security/3581251/drupal-releases-patch-for-severe-sql-injection-flaw/?olo=rss

What you need to know about POODLE/SSL 3.0 vulnerability

UPDATE – 10/16 12:45 p.m. PT: For users with Akamai sites, Akamai has made the following updates:

  • Akamai is going to be disabling SSLv3 and SSLv2 support on an aggressive timeline
  • If SSLv3 support is necessary for legacy support clients can be exempted upon request

  • Users that utilize Akamai should contact Akamai for further details. Here are some Akamai blogs which clients may find helpful:
    SSL is dead, long live TLS
    Excerpt: How POODLE happened

    UPDATE – 10/15 7:15 p.m. PT: WhiteHat Security has added testing for the new POODLE attack. These vulnerabilities will be shown as ‘Insufficient Transport Layer Protection’ in the Sentinel interface. They will have the description ‘CVE-2014-3566 – POODLE Attack’. These tests will be run at the start of a new scan.

    Google researchers released a new SSL vulnerability yesterday nicknamed “POODLE Attack.” POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption, is an attack that targets SSL version 3.0 and allows interception and compromise of supposedly secured data.

    Only SSL version 3.0 is known to be effected by this exploit. Although SSL 3.0 is extremely outdated, connection failures will result in older versions of SSL being used in an attempt to establish connection. Attackers can leverage this and force connection reattempts with SSL 3.0.

    Disabling SSL 3.0 will fix the issue however unforeseen compatibility problems may exist on sites. The Google researchers recommended supporting TLS_FALLBACK_SCSV. It’s also important to note that RC4 encryption has no padding, and as such is not vulnerable to this specific attack – although RC4 is not exempt from known issues as well.

    WhiteHat Security is currently researching a check for the POODLE Attack and will implement it as soon as it is possible.

    If you want to protect yourself in your browser, as Robert Graham with Errata Security has suggested, disabling SSLv3 in browsers is easy. On Chrome, Chromium and Aviator, use the command-line flag –ssl-version-min=tls1, and on Firefox set security.tls.version.min to 1. Mozilla also has an add-on available for disabling SSL 3.0 in Firefox. If you choose not to do this, please make sure you avoid unknown wireless connections until an official update is available for your browser.

    We will continue to update this blog as more information about POODLE is known and as more information for our customers becomes available. If you have any questions please contact WhiteHat Customer Support at support@whitehatsec.com.

    How I stole source code with Directory Indexing and Git

    The keys to the kingdom pretty much always come down to acquiring source code for the web application you’re attacking from a blackbox perspective. This is a quick review of how I was able to get access to a particular client’s application source code using an extremely simple vulnerability: Directory Indexing. Interestingly enough, they also had a .git repository accessible at https://www.[redacted].com/.git/ (although the ‘why’ still baffles me). If you have access to this you also have access to any commits and all logs that may exist in the repo.

    The following screenshots are from a recreation of the environment being run locally that I /etc/hosts mapped to http://demo.jkuskos.com. All client information has been redacted.

    image1 copy_Kuskos_10.14.14

    First, I confirmed that Directory Indexing was enabled. You’ll see why this is great in a moment.

    image2 copy_Kuskos_10.14.14

    The easiest way to download anything would be with a recursive wget(you simply need to set the flag -r).

    wget -r http://demo.jkuskos.com/.git/

    image3 copy_Kuskos_10.14.14

    Now let’s investigate. With the repository downloaded we can perform git commands on it.

    image4 copy_Kuskos_10.14.14

    Now that we can see which files exist in the repository, access to them is as simple as checking them out.

    git checkout *.php; ls;

    image5 copy_Kuskos_10.14.14

    This example is clearly simplified; however, the real site allowed me to find several SQL Injections and authorization bypasses that would have been cumbersome to find through dynamic blackbox testing alone. It also allowed me to find several files that would otherwise have been available only if you had the appropriate credential access. These types of flaws are easily found through static code analysis and much harder to find through a dynamic assessment only. As a hacker, turning a blackbox penetration test into a whitebox penetration test is always a victory.