#HackerKast 10 Bonus Round: Live Hack of Browser AutoComplete Function

While we were all recording HackerKast Episode 10 this week we decided to add a little bonus footage for a bit more technical content instead of just news stories. We mastered the power of Screensharing on our video chat and decided to put it to use.

This week’s bonus footage features Jeremiah diving into the world of browser Autocomplete hacking. This isn’t a new topic by any means but as us hackers get curious every once in a while, Jeremiah decided to see if this bug was still around.

The premise is simple: you can place a form on a website that you control. On that form you can ask for a user’s name. When you begin to type in that name, some browsers (Chrome & Safari featured in the video) will offer up the convenience of auto-filling the form for you. In this case the user doesn’t feel like typing their whole name out and allows the browser to do so. What the user doesn’t see is the rest of the form fields which are easily rendered invisible with simple CSS which are titled properly to grab the rest of the information out of your AutoFill contacts profile.

In the video Jeremiah shows how it is possible with a bit of tom foolery and Javascript to grab things like an unsuspecting user’s phone number, birthday, address, email, etc. just by having them starting to type in their name and letting AutoFill do the rest. This demo was done on Mac OSX using the latest versions of Safari and Chrome.

Again, not much new and revolutionary but still a scary attack that most users would fall for and be none the wiser as to what is going on.

We have posted the code to this particular hack on ha.ckers.org for anyone interested in testing it out.

Happy Hacking!

#HackerKast 10: XSS Vulnerability in jQuery, Let’s Encrypt, and Google Collects Personal Info

We kicked off this week’s episode chatting about a new XSS vulnerability that was uncovered in the very popular jQuery Validation Plugin. This plugin is used widely as a simple form validator and the researcher, Sijmen Ruwhof, found the bug in the plugin’s CAPTCHA implementation. This bug was very widespread, with a few Google dorks showing at least 12,000 websites easily identified as using it, and another 300,000 – 1 million websites potentially using it, or similar vulnerable code. The piece that was amusing for all of us about this story was that Ruwhof disclosed the bug privately to both the author and to jQuery back in August and received no response. After doing some digging the bug was already in OSVDB from 2013 with no action taken. After warning the plugin’s author and writing the blog post on the research publicly, the bug was closed within 17 hours. A nice little case study on Full Disclosure.

Next, Jeremiah covered the launch of new certificate authority called Let’s Encrypt. This kind of thing wouldn’t normally be news since there are a ton of CAs out there already but what makes Let’s Encrypt interesting is the fact that it is a non-profit, *FREE*, certificate authority. The project is backed by EFF, Mozilla, Cisco, Akamai, IdenTrust, and University of Michigan researchers and is focusing on being free and easy-to-use to reduce the barrier to entry of encrypting your web traffic. Robert brings up a good question of browser support, if Microsoft or Google doesn’t support this right away it really only helps the 20% or so of the users using Firefox. The other question here is what effect this will have on for-profit Certificate Authorities.

Now we of course had to mention the blog post that went somewhat viral recently about all the information Google is collecting about you. None of this was terribly surprising to many of us in this industry but was certainly eye-opening for a lot of people out there. You can easily look up their advertising profile on you, which was hilariously inaccurate for me and a few others who were posting their info online (contrary to popular belief I’m not into Reggaeton). However, the creepy one for me was the “Location History” which was *extremely* precise.

These 6 links hitting the blogosphere had good timing as Mozilla also announced that they will be switching the default search engine used in FireFox to be Yahoo. This is HUGE news considering somewhere upwards of 95% of Mozilla’s revenue comes from the fact that Google pays to be the default engine. FireFox also still has 20% market share of browser users all of whom will be using significantly less Google these days.

Robert also dug up a story about a recent ruling from a judge in the United States that said the police are allowed to compel people for any sort of biometric-based authentication but not password-based. For example, a judge has said it is perfectly legal for police to force you to use your fingerprint to unlock your iPhone but still not so for a four-digit-pin. This has all sorts of interesting implications when it comes to information security and personal privacy when it comes to law enforcement.

With absolutely no segway we covered a new story about China which seems to be one of Robert’s favorite topics. Turns out that China came out with a list of a ton of new websites they blocked from anybody accessing and one that stood out was Edgecast. Edgecast was particularly interesting because on it’s own it isn’t a website worth noting but they are a CDN which means China has blocked all of their customers as well which could affect hundreds of thousands of sites. The comparison was made of it being like blocking Akamai. Will be fascinating to see what the repercussions of this are as we go.

Closed out this week just chatting about some extra precautions we are all taking these days in the modern dangerous web. Listen in for a few tips!

Resources:
Cross-site scripting in millions of websites
Let’s Encrypt- It’s free, automated and open
6 links that will show you what Google knows about you
After this judge’s ruling, do you finally see value in passwords?
China just blocked thousands of websites

5 Characteristics of a ‘Sophisticated’ Attack

When news breaks about a cyber-attack, often the affected company will [ab]use the word ‘sophisticated’ to describe the attack. Immediately upon hearing the word ‘sophisticated,’ many in the InfoSec community roll their eyes because the characterization is viewed as nothing more than hyperbole. The skepticism stems from a long history of incidents in which breach details show that the attacker gained entry using painfully common, even routine, and ultimately defensible methods (e.g. SQL Injection, brute-force, phishing, password reuse, old and well-known vulnerability, etc).

In cases of spin, the PR team of the breached company uses the word ‘sophisticated’ in an to attempt convey that the company did nothing wrong, that there was nothing they could have done to prevent the breach because the attack was not foreseeable or preventable by traditional means, and that they “take security seriously,” — so please don’t sue, stop shopping, or close your accounts.

One factor that allows this deflection to continue is the lack of a documented consensus across InfoSec of what constitutes a ‘sophisticated’ attack. Clearly, some attacks are actually sophisticated – Stuxnet comes to mind in that regard. Not too long ago I took up the cause and asked my Twitter followers, many tens of thousands largely in the InfoSec community, what they considered to be a ‘sophisticated’ attack. The tweets received were fairly consistent. I distilled the thoughts down to set of attack characteristics and have listed them below.

5 Characteristics of a ‘Sophisticated’ Attack:

  1. The adversary knew specifically what application they were going to attack and collected intelligence about their target.
  2. The adversary used the gathered intelligence to attack specific points in their target, and not just a random system on the network.
  3. The adversary bypassed multiple layers of strong defense mechanisms, which may include intrusion prevention systems, encryption, multi-factor authentication, anti-virus software, air-gapped networks, and on and on.
  4. The adversary chained multiple exploits to achieve their full compromise. A zero-day may have been used during the attack, but this alone does not denote sophistication. There must be some clever or unique technique that was used.
  5. If malware was used in the attack, then it had to be malware that would not have been detectable using up-to-date anti-virus, payload recognition, or other endpoint security software.

While improvements can and will be made here, if an attack exhibits most or all of these characteristics, it can be safely considered ‘sophisticated.’ If it does not display these characteristics and your PR team still [ab]uses the word ‘sophisticated,’ then we reserve the right to roll our eyes and call you out.

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

Oil Droplets and Your Banking Credentials

Warning: IANAQC (I am not a quantum cryptographer)

What does a droplet of oil have in common with the security of your banking credentials? Very little, you might think. However, there is research that came out a few months back, that confirms a theory made (and then dismissed) over 80 years ago about quantum effects. Bear with me.

For the last 80 years or so people have believed that particles are in two or more places at once, and only once measured do they “choose” a position and lock in. By virtue of being in two or more places at once, it is believed that a quantum computer can test all theories in a binary question simultaneously (on or off). Each binary question is effectively one bit of entropy, and if you get enough bits, you can build a very powerful computer.

From a computer security perspective it means that factoring large primes is a relatively easy thing to do – you get enough bits into your machine and you can factor the largest publicly available crypto-systems. While it is believed by the likes of Dr. Martin Helman (of Diffe-Hellman-Merkel key exchange infamy) that we have 10 years before such a machine is feasible and an additional 10 years before such a machine is usable, that still brings the time horizon of quantum cryptology into our lifetime.

That’s a scary thought if you have secrets that need to live beyond your lifetime – you only have 20 years before they are breakable by the military — or by anyone who could afford such a device in their evil lair; the only caveat would be the data collection and storage space for all that encrypted data.

However, recent findings suggest that particles might actually not be in multiple positions all at once; they might instead act like a droplet of oil dancing along the surface of a pool of water. Unlike a droplet of water, an oil droplet won’t go beneath the surface of the water (because of differing densities for oil and water). Instead, the oil droplet will bounce along on the surface. But when the oil droplet is first dropped, it causes a ripple, and that ripple will bounce around and could actually interact with the oil droplet again, causing it to move seemingly erratically.

So perhaps quantum particles, like oil, do not behave in “spooky” ways, but rather in very deterministic (as opposed to probabilistic) ways. That is to say that there may be no “magic” behind how particles behave – it may just be a very challenging fluid-dynamics problem. If we knew enough about the waves and the oil we might be able to predict exactly where the oil (or particle) would end up. Okay, but what does this have to do with your banking password?

If this theory is indeed true, cryptographers might be unable to build a quantum computer capable of being in a super-position (two positions at once), and therefore capable of factoring all possible variations at once in the way once envisioned. If that is true, we could be much safer in the near-term as our secrets stay safe from such a machine. That means that crypto-reliant technologies like SSL/TLS might actually have some greater longevity than previously thought (barring things like Poodle, BEAST, CRIME, etc.).

Although this is an unconventional theory, one that is not at all agreed upon by the scientific community (yet), and a difficult one to prove at that, it might make your banking passwords safe for a little longer than we previously thought. Who knew? Oil. Hmm! Read more about it in Wired.

#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