Vulnerabilities-Web Application Security-WhiteHat HackerKast

#HackerKast 14: Google’s XSS Problem, Delta Airlines, Sands Casino, Eric Schmidt and more Google Facepalms

I come bearing a special Holiday HackerKast for you all today! The crew here at WhiteHat were talking about just picking these up after the New Year but there was just too much going on to skip out. Let’s jump right in with our first story about a cool persistent XSS problem our friends over at Google had this week. This bug was discovered by some SEO folk which is pretty interesting but the problem lay within a Google feature called “rich snippets.” In the search engine results page, there is a small snippet of content from every website under the links. It turns out that if you craft your website just the right way and include a bit of Javascript, that Javascript will fire if your site shows up in those search results. These XSS landing spaces of sourced-in code are always tricky.

Next, we talked about a story that hit close to home for me as a Delta Airlines loyal flyer. The attack disclosed this week was taking advantage of the lack of protections on electronic boarding passes. The super duper hack here was to break out your favorite hacking tool (a web browser) and just rotate through the URLs of your boarding pass and access other people’s boarding passes. That in itself wasn’t terrifying to me because if I tried to board the plane after somebody pretending to be me boarded, I feel like that would turn out poorly for them fast. The trickier part was that apparently, according to Robert, you could even change seat assignments and kick people out of first class. This is also the same hack that landed Weev in jail, even though granted Weev took it a bit further. I could’ve used this bug to get me out of the middle seat on my last long flight.

Another bad breach this week for the Sands Casinos. They disclosed a recent breach, without sharing much detail. The attackers in this case were attempting to brute force the casino’s VPN service for days on end until Sands got fed up and blocked them from doing that. This caused the attackers to shift focus, and they found a public facing staging (QA) website which didn’t have the same security controls as production would, and they were able to compromise the network that way. The details are sparse but apparently they did a lot of damage once they pivoted around the internal network.

We then had a little discussion about a noble Google proposal from their Chromium team to mark anything over HTTP as “insecure.” In their opinion, everything on the web should be encrypted over HTTPS or using some other TLS encrypted channel. The proposal puts forth the idea of flagging any connection in chrome that isn’t using TLS as “insecure” and warning the user about it. The points we brought up is that there is very little at that point for the user to do to remedy the fact that a website isn’t using TLS. Robert also brought up the opinion that there are tons of sites we don’t care about being encrypted. He also suggested that Google’s motivation of doing this is probably to do with the recent AT&T/Verizon news of the ISPs intercepting, monitoring, and modifying traffic. My opinion of all this was at least optimistic about the mindset change that it might stir up in everyday users as they at least learn the difference between HTTP and HTTPS.

We followed this somewhat uplifting Google news with a straight Google facepalm. Eric Schmidt, executive chairman and former CEO of Google, was quoted stating that if users just used Incognito mode in Chrome that they’d be safe from the NSA. Not only was he quoted saying that he thought this was true, he actually, and I quote, “strongly recommended” Incognito mode to avoid tracking from the government. We all joined in a collective facepalm after this one.

Lastly, after a nice long Holiday episode this week, we covered a fun bug recently disclosed in some popular router firmware that was used by many manufacturers. Some researchers discovered that just by sending a maliciously malformed cookie as part of an HTTP request through any routers using this firmware, they could get immediate remote code execution with admin privileges on the device itself. Important side note: this isn’t home routers we are talking about, it is ISP Residential Gateway routers. The funny (sad?) part about this bug is that the vulnerable code was written in 2002. Should I repeat that? The vulnerable code was written in 2002. Even crazier is that it was fixed by the firmware developer in 2005. Even though all of that is true, the router manufacturers are putting out brand new 2014 devices with the 2002 firmware. The researchers who found this bug scanned around the internet and found ~12 million vulnerable devices, in some cases affecting up to half the Internet users in a given country. Even though this is the longest paragraph, I’m leaving out some details so check out the video.

Keep your eyes out for some bonus footage Robert and I filmed after this episode with some cool iframe hacking.

Thats all we have this week. Happy Holidays from all of us here at WhiteHat Security, I hope you all have a wonderful rest of your year and at least a few mental days off from work. Be safe and see you in 2015!

Resources:

How I Hacked Google (For Good)

Need a last minute flight?

Now at the Sands Casino: An Iranian Hacker in Every Server

Marking HTTP As Non-Secure

12 Million Home Routers Vulnerable to Takeover

Top Google exec mistakenly suggests Chrome’s incognito mode can foil the NSA

Tags: Google, JavaScript, Vulnerabilities, XSS, XSS Vulnerability
  • John

    Marking http as insecure will force companies to adopt https by scaring customers. Ecommerce websites typically put their checkout flow under https but leave the remainder of the site unsecured. This type of warning on the unsecure pages will drastically decrease conversion rates on ecommerce sites because customers will be hesitant to checkout on a site they think is insecure.

    I think this is one of the best moves anyone has made post Snowden in the “encrypt everything” direction because aside from the (relative) technical difficulty of implementing https the second most common reason for not doing it is apathy. Suddenly everyone is going to have to care, and that is a good thing.