Aviator Going Open Source

One of the most frequent criticisms we’ve heard at WhiteHat Security about Aviator is that it’s not open source. There were a great many reasons why we didn’t start off that way, not the least of which was getting the legal framework in place to allow it, but we also didn’t want our efforts to be distracted by external pressures while we were still slaving away to make the product work at all.

But now that we’ve been running for a little more than a year, we’re ready to turn over the reins to the public. We’re open sourcing Aviator to allow experts to audit the code and also to let industrious developers contribute to it. Yes, we are actually open sourcing the code completely, not just from a visibility perspective.

Why do this? I suspect many people just want to be able to look at the code, and don’t have a need to – or lack the skills to – contribute to it. But we also received some really compelling questions from the people who have an active interest in the Tor community who expressed an interest in using something based on Chromium, and who also know what a huge pain it is to make something work seamlessly. For them, it would be a lot easier to start with a more secure browser that had removed a lot of the Google specific anti-privacy stuff, than to re-invent the wheel. So why not Aviator? Well, after much work with our legal team the limits of licensing are no longer an issue, so now that is now a real possibility. Aviator is now BSD (free as in beer) licensed!

So we hope that people use the browser and make it their own. We won’t be making any additional changes to the browser; Aviator is now entirely community-driven. We’ll still sign the releases, QA them and push them to production, but the code itself will be community-driven. If the community likes Aviator, it will thrive, and now that we have a critical mass of technical users and people who love it, it should be possible for it to survive on its own without much input from WhiteHat.

As an aside, many commercial organizations discontinue support of their products, but they regularly fail to take the step of open sourcing their products. This is how Windows XP dies a slow death in so many enterprises, unpatched, unsupported and dangerously vulnerable. This is how MMORPG video games die or become completely unplayable once the servers are dismantled. We also see SAAS companies discontinue services and allow only a few weeks or months for mass migrations without any easy alternatives in sight. I understand the financial motives behind planned obsolescence, but it’s bad for the ecosystem and bad for the users. This is something the EFF is working to resolve and something I personally feel that all commercial enterprises should do for their users.

If you have any questions or concerns about Aviator, we’d love to hear from you. Hopefully this is the browser “dream come true” that so many people have been asking for, for so long. Thank you all for supporting the project and we hope you have fun with the code. Aviator’s source code can be found here on Github. You don’t need anything to check it out. If you want to commit to it, shoot me an email with your github account name and we’ll hook you up. Go forth! Aviator is yours!

Top 10 Web Hacking Techniques of 2014

Every year the security community produces a stunning number of new Web hacking techniques that are published in various white papers, blog posts, magazine articles, mailing list emails, conference presentations, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and their mobile platform equivalents. Beyond individual vulnerabilities with CVE numbers or system compromises, we are solely focused on new and creative methods of Web-based attack. Now in its ninth year, the Top 10 Web Hacking Techniques list encourages information sharing, provides a centralized knowledge base, and recognizes researchers who contribute excellent work. Past Top 10s and the number of new attack techniques discovered in each year:

2006 (65), 2007 (83), 2008 (70), 2009 (82), 2010 (69), 2011 (51), 2012 (56) and 2013 (31).

Phase 1: Open community submissions [Jan 7-Jan 19]
Comment this post with your submissions from now until Jan 19. The submissions will be reviewed and verified.

Phase 2: Open community voting for the final 15 [Jan 19-Feb 2]
Each verified attack technique will be added to a survey which will be linked here, on Jan 19th. The survey will remain open until Feb 2. Each attack technique (listed alphabetically) receives points depending on how high the entry is ranked in each ballot. For example, an entry in position #1 will be given 15 points, position #2 will get 14 points, 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 15 overall.

Phase 3: Panel of Security Experts Voting [Feb 2-Feb 23]

From the result of the open community voting, the final 15 Web Hacking Techniques will be ranked based on votes by a panel of security experts. (Panel to be announced soon!) Using the exact same voting process as Phase 2, the judges will rank the final 15 based on novelty, impact, and overall pervasiveness. Once tabulation is completed, we’ll have the Top 10 Web Hacking Techniques of 2014!

Prizes [to be announced]

The winner of this year’s top 10 will receive a prize!

Ongoing List of 2014 Hacks (in no particular order)
Heartbleed
TweetDeck XSS
OpenSSL CVE-2014-0224
Rosetta Flash
Unauthenticated Backup and Password Disclosure In HandsomeWeb SOS Webpages cve-2014-3445
CTA: The weaknesses in client side xss filtering targeting Chrome’s XSS Auditor
Advanced Exploitation of Mozilla Firefox Use-After-Free Vulnerability (Pwn2Own 2014) CVE-2014-1512
Facebook hosted DDOS with notes app
The Web Never Forgets: Persistent Tracking Mechanisms in the Wild
Remote File Upload Vulnerability in WordPress MailPoet Plugin (wysija-newsletters)
The PayPal 2FA Bypass
AIR Flash RCE from PWN2OWN
PXSS on long length videos to DOS
MSIE Flash 0day targeting french aerospace
Linskys E420 Authentication Bypass Disclosure
Paypal Manager Account Hijack
Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID
How I hacked Instagram to see your private photos
How I hacked GitHub again
ShellShock
Poodle
Residential Gateway “Misfortune Cookie”
Recursive DNS Resolver (DOS)
Belkin Buffer Overflow via Web
Google User De-Anonymization
Soaksoak WordPress Malware
Hacking PayPal Accounts with 1 Click
Same Origin Bypass in Adobe Reader CVE-2014-8453
RevSlider
HikaShop Object Injection
Covert Timing Channels based on HTTP Cache Headers
NODE.JS CONNECT CSRF BYPASS ABUSING METHODOVERRIDE MIDDLEWARE
Bypassing NoCAPTHCA
Delta Boarding Pass Spoofing
Cryptophp Backdoor
Microsoft SChannel Vulnerability
Google Two-Factor Authentication Bypass
Drupal 7 Core SQLi
Apache Struts ClassLoader Manipulation Remote Code Execution and Blog Post
Reflected File Download
Misfortune Cookie – TR-069 ACS Vulnerabilities in residential gateway routers
Hostile Subdomain Takeover using Heroku/Github/Desk + more: Example 1 and Example 2
File Name Enumeration in Rails
FlashFlood
Canadian Beacon
setTimeout Clickjacking

#HackerKast 16: India blocks GitHub, GoGo fake SSL certificates, North Korea’s only network

Happy 2015 everybody! Jeremiah, Robert, and I got right back on track our first week back in the office and there were plenty of stories to talk about. Turns out hackers don’t really take vacation.

Right off the bat Robert brought up a story about the Indian government pulling a China and blocking access to a ton of sites this week. Some notable sites include Pastebin, Dailymotion, and Github, according to reports coming from Indian users. The reasons cited all have to do with anti-terrorism and blocking potential terrorists’ access to sites that can be used as virtual dead drops. This seems like a complete overreaction to us and has some serious overarching repercussions, most obviously the fact that a giant chunk of the world’s developers can no longer access the largest chunk of open source code, GitHub. We’ll see where this goes but if you’re an investor in VPN services you probably have a big smile on your face right about now.

Next, I brought up some disturbing tweets that caught my eye this week about GoGo Inflight WiFi services. If any of you are frequent flyers like us you’ve undoubtably been forced to use GoGo at some point, but a few more technically savvy users noticed GoGo is up to no good recently. While browsing the internet in the air, some noticed that GoGo was issuing fake SSL certificates while browsing certain websites such as Google and YouTube. Ironically, the user who started attracting attention to this was an engineer who worked for Google. This effectively allows GoGo to Man in The Middle all the SSL traffic of their users and read sensitive data that should be encrypted. Spokespeople from GoGo have stated this is only used to block or throttle video streaming services so that there is enough bandwidth to go around but it is still pretty shady that they have access to sensitive information.

Next, Robert found a fun image floating around of a (the?) North Korean web browser called Naenara Browser:

RSnake_2015-Jan-06

This was just something really quick we wanted to bring up because the screenshot shows that as soon as you install this browser it makes a call to a RFC 1918 address (10.76.1.11) from your computer. The importance of this that left my jaw open was that this means that all of North Korea is on the same network. As in intranet. Things that make you go “Wah?”.

Ever think you found something cool and couldn’t wait to share it with your friends? Well don’t share it with RSnake because he probably knows about it already. As was the case with this “recent” HSTS (HTTP Strict Transport Security) research coming out of the UK. A few weeks ago you might remember us mocking Google’s former CEO Eric Schmidt over his claim that Google’s Incognito mode would protect you from the NSA. Well after we all facepalmed collectively on the podcast, this researcher in the UK decided to set out and prove Schmidt wrong. Robert gets into the technical details of deanonymizing somebody with the nitty gritty of how HSTS works, which is super interesting and deserves a read through some of these blog posts.

Lastly, we talked about Moonpig. Not to be confused with Pigs In Space.

pigsinspace

This Moonpig is an online mail order greeting card service. While most mail order greeting card services are at the forefront of information security, Moonpig fell victim to a vulnerability in their API which allowed full account take over of any user. Their API was poorly designed and had no authentication at all which allowed just a quick flip of a customerID parameter to start impersonating other users, making fake orders, stealing credit card information, etc. The kicker of this vulnerability was that it was responsibly disclosed to Moonpig back in August of 2013 and responded with they’d “get right on it”. 17 months later, this researcher and user of Moonpig was frustrated of waiting for a fix and decided to write them again in September 2014. The reply this time was that a fix was coming before Christmas. Well, New Years has just passed and the researcher decided to publish his findings publicly and guess what? Less than 24 hours an engaget article later the API was pulled offline. Another unfortunate win for Full Disclosure.

We closed off with some musings about time to fix statistics and overall browser security suggestions for everyday people. Unfortunately we are going to have to break the web to fix the web. There is a Dan Kaminsky quote about this never happening somewhere…

That’s all for this week. Stay tuned for next week when hopefully we’ll have some bonus footage for you all. Also! Check us out in iTunes now for those of you who like that sort of thing and would rather just listen to the podcast instead of staring at our mugs for 15-20 minutes.

Happy New Year!

Notable stories this week that didn’t make the cut:
Banks doing Hack-back being investigated by FBI
Playstation network may have just been a ploy to market a DDoS tool
But then one of the alleged Lizard Mafia guys got arrested, and another is being questioned
Katie from HackerOne was detained and forced to decrypt her laptop in France – don’t travel with exploits or anything you care about!
$5M US in Bitcoin stolen from Bitstamp in unexplained hack

Resources:
Pastebin, Dailymotion, Github blocked after DoT order: Report
Gogo issues fake HTTPS certificate to users visiting YouTube
North Korean Browser
Brit Proves Google’s Eric Schmidt Totally Wrong: Super Cookies Can Track Users Even When In Incognito Mode
Moonpig flaw leaves customer accounts wide open for 17 months (update)

#HackerKast 15: New Year. Same Hacks.

WhiteHat Security Top Security Stories of the Week: December 29, 2014 to January 2, 2015 from WhiteHat Security on Vimeo.

We were able to squeeze a recording in between Christmas and New Year’s Eve and I’m glad we did because we had a lot to chat about. Although we were still in a food coma from Christmas, I think we were able to shake it off and record a good episode for you guys.

First, we hit on a funny story of Instagram getting wise to millions of fake profiles and giving them all the axe at the same time. These sockpuppet accounts were all over; I personally noticed a severe uptick recently and was in contact with Facebook/Instagram security team to chat about it. Some of the hilarity being noted in the post-spamageddon world is that fairly popular-seeming accounts dropped to near zero followers as their numbers were very bloated by robots.

Next, somebody came up with a clever way to bypass the age old two-factor authentication implementation of a trusty fingerprint. Wait… did I say “trusty”? Scratch that. This research shows that with a high resolution photo of somebody’s finger, you can recreate their fingerprint well enough to bypass a touch ID scanner. They proved this by copying the fingerprint of Germany’s Minister of Defense, Ursula von der Leyen, off of a simple photo. Robert points out that your fingerprints are left nearly everywhere you go and are a pretty weak second factor authentication mechanism due to the many ways to get around it.

Now we get to two of Robert’s favorite topics that just so happen to both be in the same story this week: Google AND China. Turns out, China blocked another site this week, as they tend to do, but this time the site was a little known email provider called Gmail. This is pretty huge news in itself but as Robert points out, this could have a major ripple effect of nobody in China being able to receive email from a gmail address. So not only might this force people in China to a different email provider, it might force people around the world who need to communicate with people/businesses in China to use something else as well.

We couldn’t get out of a HackerKast without talking about Lizard Mafia (Patrol? Squad?). A sentence I never thought I’d say. Anyway, this slowly becoming infamous hacker crew of lizards – who have been tormenting Brian Krebs and took down Xbox Live/PSN over Christmas – have now set their crosshairs upon Tor. They made a clever attempt to DoS Tor with what is known as a Sybil attack, which spokespeople from Tor have noted would probably cause them some problems if launched by an adversary who had sufficient time/means. This attempt wasn’t successful, but it is interesting to read how they were going about trying.

I touched quickly on a fun business logic flaw (near and dear to my heart and to Jer’s) that had to do with getting cheaper hotel rooms. By the nature of being a logic flaw, this isn’t really a technical “hack” so-to-speak but it is clever nonetheless. The “attack” outlined a method of getting a huge discount on your hotel room by booking alongside some local conferences. These conferences that have huge draws (RSA anyone?) usually strike deals with local hotels to get a “conference rate.” Well it turns out that this rate is sometimes given out with little-to-no verification as to whether you are actually a conference attendee. In some cases this knocked the price down more than $200 per night from the current research.

Guess what everybody? WordPress caused a site to get hacked! Contain your shock/awe/riots please. In this case, ISC.org was hacked – allegedly the fault of a WordPress install – and was serving up malware. ISC is popular for its creation of things like BIND DNS, DHCP, etc., and as Robert points out the scary thing about this hack might not be the website itself but the highly technical system admin type users who might be compromised. Imagine your IT person – who also has the keys to the corporate kingdom – is the one who gets malware on their machine for a minute. Doesn’t sound good right? ISC swears this breach was just on their website and no sensitive code was compromised but we aren’t really sure of any details.

Lastly, Jeremiah showed us a pretty picture. No really! A popular infographic made its way around the tubes this week showing the immense size of records lost in data breaches in the last decade or so. This one was super cool, letting you check out how something like the Target breach last year compared to the TJ Maxx or Heartland breaches of a few years ago. The moral of this story is that information about you is probably stored somewhere that will be compromised, so be diligent about what you put where and prepare for what happens when it gets stolen. Also, a lesson for companies: don’t store what you don’t have to! I know we live in a data-centric world but unless you absolutely must, you probably should “just say no” [insert Smokey the Bear motivational image] to storing sensitive data.

That’s all for us folks. Sorry for the long one today but there was a lot going on while we were all opening gifts, sipping eggnog, and toasting the new year! Hope your 2015 is off to a great start!

Resources:
Hackers say they can copy your fingerprint from just a photograph
Gmail has been blocked in China
Hackers who shut down PSN and Xbox Live now attacking Tor
How we hacked the hotel industry to save $200+ per night
Someone went from 3.6 million Instagram followers to 8 today. Eight.
ISC.org website hacked: Scan your PC for malware if you stopped by
The world’s biggest data breaches, in one incredible infographic

#HackerKast 14 Bonus Round: Canadian Beacon – JavaScript Beacon and Performance APIs

In this week’s bonus footage of HackerKast, I showed Matt my new JavaScript
port scanning magic that I dubbed “Canadian Beacon” because it uses the new Beacon API. It was either that or Kevin Beacon – I had to make a tough choice with my puns. It utilizes both the performance API and the beacon API.

It shows how you can use iframes and performance APIs to do basically the same thing we used to be able to do with onload event handlers on iframes of yester-year.

Not a huge deal, because we can do this in a bunch of different ways already, but it shows how easy it is to do JavaScript port scanning; and even if someone bothers to shut one variant down, this and other variants will take their place. This is one of the major reasons Aviator has chosen to break access to RFC1918 from the Internet.

Only a few browser variants are vulnerable, Chrome and apparently Firefox though I only got it working in Chrome. If you want to see a demo you can check out Canadian Beacon here.

#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

Hack Yourself First: National and Economic Security

It’s safe to say most countries are investing in their cyber-offense capabilities or will be very soon. Even the smallest countries can wreak havoc on the most powerful with very little money. And while you consider the ramifications of this, here’s a quote to help it sink in.

“National security is no longer about tanks. National security is increasingly about economic well-being, internet security, and issues that allow us to live on a daily basis. We’re not worried today about the soviets blowing us up with nukes, but we are worried that our kids will be able to enjoy a quality of life vaguely related to our own.” -Ian Bremmer

How can a corporation — even the largest, let alone small businesses and individuals — possibly defend against armies of well-funded nation-state sponsored hackers? These hackers are professionally trained, with no reason to fear our laws, physically distant from their victims, and operate 24 hours a day, 7 days a week, 365 days a year. Remember, the Internet does not recognize or respect geographic borders. The Internet is particularly adept at routing around country-by-country laws and regulations that impeded traffic.

Many people in positions of power have expressed concern about the Internet being brought down. I’m more worried about what happens if the majority of people lose confidence in the system – the security of the Internet – and either stop or limit their use of the Internet. I’m worried about the long-term economic damage this causes, the loss of our ability to innovate, the failure to take advantage of the opportunities that the Internet provides.

New laws against criminal hacking are not going to help. Conventional warfare tactics are not much good either. Governments are largely unable to protect the private sector from international cyber-attack, nor should they be expected to. The perpetrators can be located anywhere, are extremely difficult to identify, prove attribution, and track down, even harder extradite, and even if identified, located, and extradited, difficult to successfully prosecute. And then, if they are found to be spies, the likelihood of them getting traded for our own spies is high – so they go back to what they were doing. Not to mention foreign governments are highly unlikely to turn over their own cyber-warriors. Every CEO in America must understand — in cyber-security you’re on your own.

The reality is that a problem as diverse and wide reaching as cyber-crime cannot be solved by any one thing; but I’ll tell you this — protecting the Internet requires a completely new way of thinking. While our cyber-defense ability is severely lacking, one thing we all clearly know how to do extremely well is cyber-offense.

Offense can inform defense.

I call this approach Hack Yourself First, a concept that is critical to our self-defense. Internet security can be thought of as a race between the bad guys who find and exploit security weaknesses (we call them vulnerabilities) and the good guys who find and fix them. I felt so strongly about this that I built a company, WhiteHat Security, around this idea. At WhiteHat, we get paid by companies doing business online to hack into them and explain how we did so.

In no time flat we’re able locate digital doorways to take over some or all of their the systems, steal whatever sensitive data they have, access their customers accounts, or steal data they have on the system — all the things that could have made headlines like those you’ve probably seen recently. And let me make something else perfectly clear. These are systems owned by the largest and most well known organizations in the world. You know them. You do business with them. Collectively, they constitute billions of end-user accounts. In short, we’re probably already protecting you. Every vulnerability we find and our customers fix is one less hack that happens.

“Hack Yourself First” is also the reason why we teach other people how to hack, hundred and thousands of them. We teach all sorts of ways to hack into banks, retail websites, social networks, government systems, and more. We teach people how this can be done from anywhere across the Internet.

Many wonder why teaching people how to hack is a good thing. I know hacking is often stereotyped as illegal or nefarious activity — but this is not always the case. Teaching people how to hack — building up our cyber-offense skills — is absolutely essential. Only if we have hacking skills can we focus these skills inward at ourselves BEFORE the bad guys do. The idea of “Hack Yourself First” is critical to national security and to ensuring our long-term economic well-being.

Remember, security is optional, but so is survival.

The Parabola of Reported WebAppSec Vulnerabilities

The nice folks over at Risk Based Security’s VulnDB gave me access to take a look at their extensive collection of vulnerabilities that they have collected over the years. As you can probably imagine, I was primarily interested in their remotely exploitable web application issues.

Looking at the data, the immediate thing I notice is the nice upward trend as the web began to really take off, and then the real birth of web application vulnerabilities in the mid 2000’s. However, one thing I found that struck me as very odd was that we’re starting to see a downward trend in web application vulnerabilities since 2008.

  • 2014 – 1607 [as of August 27th]
  • 2013 – 2106
  • 2012 – 2965
  • 2011 – 2427
  • 2010 – 2554
  • 2009 – 3101
  • 2008 – 4615
  • 2007 – 3212
  • 2006 – 4167
  • 2005 – 2095
  • 2004 – 1152
  • 2003 – 631
  • 2002 – 563
  • 2001 – 242
  • 2000 – 208
  • 1999 – 91
  • 1998 – 25
  • 1997 – 21
  • 1996 – 7
  • 1995 – 11
  • 1994 – 8

Assuming we aren’t seeing a downward trend in total compromises (which I don’t think we are) here are the reasons I think this could be happening:

  1. Code quality is increasing: It could be that we saw a huge increase in code quality over the last few years. This could be coming from compliance initiatives, better reporting of vulnerabilities, better training, source code scanning, manual code review, or any number of other places.
  2. A more homogenous Internet: It could be that people are using fewer and fewer new pieces of code. As code matures, people who use it are less likely to switch in favor of something new, which means there are fewer threats to the incumbent code to be replaced, and it’s therefore more likely that new frameworks won’t get adopted. Software like WordPress, Joomla, or Drupal will likely take over more and more consumer publishing needs moving forward. All of the major Content Management Systems (CMS) have been heavily tested, and most have developed formal security response teams to address vulnerabilities. Even as they get tested more in the future, such platforms are likely a much safer alternative than anything else, therefore obviating the need for new players.
  3. Attacks may be moving towards custom web applications: We may be seeing a change in attacker tactics, where they are focusing on custom web application code (e.g. your local bank, Paypal, Facebook), rather than open source code used by many websites. That means they wouldn’t be reported in data like this, as vulnerability databases do not track site-specific vulnerabilities. The sites that do track such incidents are very incomplete for a variety of reasons.
  4. People are disclosing fewer vulns: This is always a possibility when the ecosystem evolves far enough where reporting vulnerabilities is more annoying to researchers, provides them fewer benefits, and ultimately makes their life more difficult than working with the vendors directly or holding onto their vulnerabilities. The presence of more bug bounties, where researchers get paid for disclosing their newly found vulnerability directly to the vendor, is one example of an influence that may affect such statistics.

Whatever the case, this is is an interesting trend and should be watched carefully. It could be a hybrid of a number of these issues as well, and we may never know for sure. But we should be aware of the data, because in it might hide some clues on how to further decrease the numbers. Another tidbit that is not expressed in the data above shows that there were 11,094 vulnerabilities disclosed in 2013, of which 6,122 were “web related” (meaning web application or web browser). While only 2,106 may be remotely exploitable (meaning it involves a remote attacker and there is published exploit code) context-dependent attacks (e.g. tricking a user to click a malicious link) are still a leading source of compromise at least amongst targeted attacks. While vulnerability disclosure trends may be going down, organizational compromises appear to be just as common or even more so than they have ever been. Said another way, compromises are flat or even up, and new remotely exploitable web application vulnerabilities being disclosed is down. Very interesting.

Thanks again to the Cyber Risk Analytics VulnDB guys for letting me play with their data.

#HackerKast 13: Zombie POODLE, TCP/UDP Vulnerabilities, Jailed for XSS

This week Robert was keeping warm by his yule log while Jeremiah was freezing in the Boston snow and I won’t be putting Christmas ornaments in my beard no matter how many of you send me that blog post. To get right into it, we started off by talking about the return of POODLE. For those with short term memory loss, POODLE was a nasty vulnerability disclosed a few weeks back that affected SSL v3 which is: a) already widespread as-is and, b) easy to downgrade somebody’s browser to use. The zombie POODLE this week didn’t go after SSL this time and instead went after TLS 1.2 which is used *everywhere*. The most prominent place that will need patching is all F5 load balancers which are using this version of TLS – and that happens to be most of them. Sorry for all of you who lost sleep a few weeks ago because it is about to happen again this week. Happy Holidays!

Next, if you recall a topic from last week’s episode regarding Google’s alternative to CAPTCHA, well it appears Robert may be getting a Christmas wish early, and it didn’t take long. Before any of us had ever seen it in the wild, Google’s new solution to replace CAPTCHAs was found to be very easily avoidable. The check-box that is supposed to tell if you are a human or a robot turns out to fail back to a normal CAPTCHA which is nothing new. If that wasn’t useless enough, it actually introduces a new weakness that didn’t exist before! This check-box is clickjackable! You can gather tons of valid tokens that say you are a human and load them into your botnet or whatever you’d like.

Now buckle up and put your splash guards on because this next story blew our minds. A new proposal for the HTTP spec has popped up that would allow a browser to… wait for it… make TCP/UDP requests! Yup, you heard it. We had TCP/UDP and said: “Hey, let’s abstract a layer on top of that, and we’ll call it HTTP.” Now, fast forward to this month and we are saying: “Hey remember TCP/UDP? Lets put that on top of HTTP!” I’m picturing Dory from finding Nemo here. This opens tons of doors to all sorts of attacks behind a firewall via a web browser. Watch the video for a list of ideas that might be possible if this is implemented from Robert and I.

Lastly, we have a weird and sad story about somebody ending up in jail for a web “hack.” In Singapore, some unlucky fellow decided to poke around on their prime minister’s website. The website had a Google search bar embedded in it which seemed to tie into some reflection of that text which was unsanitized and therefore vulnerable to XSS. This led him to get a laugh out of it and craft a link with the reflective XSS in it and send it around which showed the prime minister’s site displaying a Guy Fawkes mask in reference to Anonymous. The thing with this though is that the site wasn’t actually defaced and no breach actually occurred. That didn’t stop the local authorities from sending this guy to jail for six months and fining him the equivalent of $34,000. As far as we know this is the first person since Samy on Myspace (who is my hero) who landed in jail due to XSS.

Keep an eye out for some Bonus Footage this week where Robert and I dig into some JavaScript Flooding attacks with an easy demo!

Resources:
POODLE back to bite TLS connections
The No CAPTCHA Problem
TCP and UDP Socket API
Singapore Hacker Jailed for XSS on Prime Minister’s Office Website

#HackerKast 13 Bonus Round: FlashFlood – JavaScript DoS

In this week’s HackerKast bonus footage, I wrote a little prototype demonstrator script that shows various concepts regarding JavaScript flooding. I’ve run into the problem before where people seem to not understand how this works, or even that it’s possible to do this, despite multiple attempts at trying to explain it over the years. So, it’s demo time! This is not at all designed to take down a website by itself, though it could add extra strain on the system.

What you might find though, is that heavy database driven sites will start to falter if they rely on caching to protect themselves. Specifically Drupal sites tend to be fairly prone to this issue because of how Drupal is constructed, as an example.

It works by sending tons of HTTP requests using different paramater value pairs each time, to bypass caching servers like Varnish. Ultimately it’s not a good idea to ever use this kind of code as an adversary because it would be flooding from their own IP address. So instead this is much more likely to be used by an adversary who tricks a large swath of people into executing the code. And as Matt points out in the video, it’s probably going to end up in XSS code at some point.

Anyway, check out the code here. Thoughts are welcome, but hopefully this makes some of the concepts a lot more clear than our previous attempts.