Category Archives: Technical Insight

#HackerKast 18 Bonus Round: Password Cracking

Hey Everybody! Thanks for checking out this week’s bonus footage. We like to do these to not just focus on current events but to also get our hands dirty with some technical demos. This week, we decided to talk about password cracking.

You hear news stories all the time about passwords being stolen and you may have heard of password hashes being cracked. What this means is that somebody got a hashed copy of a lot of passwords out of a database and are running programs against it to get the plain text password out.

For those of you familiar with password cracking this will be super boring but we decided to actually show what this looks like for those who haven’t seen it. I decided to use John the Ripper for this demo but could have used a ton of others like OCL Hashcat. Kali Linux has a few of these installed by default for those who want to play.

Since we are web app guys here at WhiteHat I decided to pick on some password hashes that make sense in our world, WordPress. Most password cracking demos you’ll see are running against local machine password files so instead of that I made a few of my own WordPress password hashes. The giveaway showing that these are WordPress hashed passwords is that they use a PHPass algorithm which results in a hash that always starts with $P$B.

The passwords I chose were pretty easy ones just to prove to you guys how easy cracking easy passwords is. Anything in the top couple of 1000 used passwords will be cracked in seconds with the help of a word list, as you’ll see in the video.

The other major point I wanted to make is that seemingly “good” passwords that follow all the rules of a websites password strength requirements can actually be pretty weak. The example I used was “Jeremiah29:11″ as a password passes most requirements. It’s over 8-10 characters, it is has upper and lower case letters, has numbers, and special characters. Seems great right? Well since it is a popular bible verse, this took less than 30 min. to crack on my laptop and would take seconds on a computer built for password cracking.

Check out the end of the video for some of our tips on secure password selection. Let us know what you think!

Web Security For the Tech-Impaired: The Dangers of Email

Editor’s Note: The following post is the first in a series of blasts that we will be sharing for readers who are – or who know people that are – not technically savvy. We will touch on topics that we in the security community are very aware of and attempt to break them down into language that those who are not as internet skilled may understand. If you have suggestions for topics you wish for us to cover in this series, please share in the comments.

You’ve all been there. You open your email and your mom has sent you something. You see the two letters you dread: FW. Oh look, it’s an email with a link to a YouTube video about a cat who just can’t seem to figure out that the sliding glass door is a solid object. You contemplate sending back an email saying ‘Come on Mom, you should know to never ever click on links in emails,’ but you don’t want to ruin her fun — and more than likely she won’t understand WHY clicking on links in emails is a bad thing. You could try to explain it to her, but you’re afraid her brain will explode if you start talking about things like “Cross Site Scripting”. Well folks, I’m going to try and help you out. In this new blog series, I am aiming to provide tips and advice that you can share with your less-than-tech-savvy friends and family – whether its your mom, grandpa, cousin Vinny or whomever. These are posts that I intend for you to FW: (uh oh, there are those letters again) the links to your mom (or whomever) so that they can get a non technical explanation of the dangers of the ‘internets.’ Now begins the non-technical explanation, here we go!

Hello there! You’re no doubt reading this as a result of your son/daughter/grandson/granddaughter having sent you here for guidance. Fear not, I will help guide you through the dangers of the internet and help you be more secure with your personal information. No doubt you’ve heard of recent credit card breaches in stores you visit every day. You’ve also probably heard about ‘phishing’ emails that ask for your personal information in an email or ask you to click some link. You may have seen emails that say ‘Your credit card has been stolen, please email your Social Security number, mother’s maiden name and birthdate to this email address.’ The good news is that you can prevent yourself from being a victim of these scams.

The first thing you’ll need to know is that you should be very, VERY paranoid about anything you get in an email. If someone knocks on your front door, you’re always skeptical about what they want; the same principle should be applied to email. Anyone and everyone can email you and not all emails should be trusted, particularly from contacts that you do not know or that ask you for personal information. Most businesses make it a point to not request such information over email, so if you get such a request, it is quite likely a scam. Secondly it is very easy to fake the sender of an email. Just because it says ‘’ doesn’t mean it is. Never trust that your email is coming from the business that it purports to be coming from.

Furthermore, links and attachments in emails can be bad news. Just as it’s very easy to make it look like an email is coming from someone else, it’s just as easy to make a link in an email look different. I can easily make it look like it’s going to ‘’ but really when you click on the link it will take you to ‘’ Fake sites are set up under the guise of seemingly legitimate URLs in an effort to get you to click on them which could lead to theft of personal information or worse. Attachments in emails from unknown sources are also bad news. You could be unknowingly downloading malware — software that can interfere with the proper functioning of your computer, damage your privacy or even install the dreaded virus.

All this sounds pretty frightening already. You may think you now need to go make a tin foil hat and build a bunker in your backyard. But with this knowledge you are well-armed to combat identity thieves. Here are a few simple things you can do to help protect yourself:

* Never give your personal information to anyone. No legitimate business will ask you to email them your Social Security number, credit card number, passwords, date of births, etc., over email. If they’re asking for that information it is 99.9% likely that it’s a scam. Sometimes an attacker will send an email that makes it sound like there’s an emergency — if you don’t do what they’re asking for right away something horrible will happen! Instead of doing what the email says, if it looks like it might be from a legitimate business – like a bank that you do actually have an account with – contact that business directly. Don’t use any links from that email. Let them know what email you received and that you want to confirm whether or not it was a legitimate email.

* Never click on a link in an email — it’s just asking for trouble. If you really want to watch that cat video, copy the link address into your browser window so you can be sure you’re sending your browser where you actually want it to go.

* If you receive an email that has an attachment and you were not specifically expecting that person to send you that attachment, contact them directly and confirm that they sent it and it’s a legitimate attachment. More than once a friend of mine has found out that their email account was hacked because I contacted them about a suspicious attachment.

This is all but the beginning of your training and you should come back to this blog often to hear more helpful (and hopefully easy to understand) advice on how to better protect yourself on the internet. Go forth and click on!

5 Days to Setting Up an Application Security Program

Congratulations! You now have the responsibility of ensuring your web applications are secure. This is the reality that modern day CISOs and security professionals address every day. You may have even lobbied for and championed this initiative because you are acutely aware of the risk that vulnerable web applications present to the business. Or as is often the case in reaction to a breach or an attack (aka a “security event”), web applications have now appeared on the radar of your senior management team. So, where to begin? Where’s the playbook?

To assist you in this endeavor, we have created an “Application Security Program Quick Start Guide.” WhiteHat has years of combined web application and security management experience which came in very handy for this undertaking. This guide is essentially a playbook that is both easy-to-consume yet prescriptive-enough that the reader is able to walk away with concrete action items to set in motion.

Web application testing is not a fledging security activity by any measure. That said, finding resources to help navigate the process of building a web application security program are scarce and often too high-level. In practice, there is no shortage of tools or services to perform web application testing, but testing alone is not a substitute for a comprehensive web application security program. To be successful, we should aim for a program that is more than simply testing sites and delivering results to stake holders. Those activities represent just two of the many inputs and outputs necessary to reduce the risk associated with web applications.

Today we are releasing this “Application Security Program Quick Start Guide” in the hopes that it will help CISOs in their ongoing work to ensure the security of their organization’s web applications and mission-critical information. In addition, we have donated the guide under a Creative Commons license to the OWASP community for everyone to use.

You can download the guide here:

The OWASP project page can be found here:

We hope this initial draft serves to spur the collective insights of those willing to participate.

North Korea’s Naenara Web Browser: It’s Weirder Than We Thought

Naenara Browser is the DPRK’s version of Firefox that comes built into Red Star OS, the official operating system of North Korea. I recently got my hands on Naenara Browser version 3.5. My first impression in playing with it is that this is one ancient version of Firefox. Like maybe more than a half dozen major revisions out of date? It’s hard to tell for sure in cursory checking but the menus remind me of something I used to use 5+ years ago. That’s not too surprising; it’s tough to have a browser and update it all the time, especially with such a small team devoted to the project, as I’m sure they have a lot of other things going on.

When I first saw an image of the browser I was awe-struck to see that it made a request to an adddress ( upon first run. That may not mean much to someone who doesn’t deal with the Internet much, but it’s a big deal if you want to know how North Korea’s Internet works.

If you want to send a request to a web address across the country, you need to have a hostname or an IP address. Hostnames convert to IP addresses through something called DNS. So if I want to contact DNS will tell me to go to But there are certain addresses, like those that start in “10.”, “192.168.” and a few others that are reserved and meant only for internal networks – not designed to be routable on the Internet. This is sometimes a security mechanism to allow local machines to talk to one another when you don’t want them to traverse the Internet to do so.

Here’s where things start to go off the rails: what this means is that all of the DPRK’s national network is non-routable IP space. You heard me; they’re treating their entire country like some small to medium business might treat their corporate office. The entire country of North Korea is sitting on one class A network (16,777,216 addresses). I was always under the impression they were just pretending that they owned large blocks of public IP space from a networking perspective, blocking everything and selectively turning on outbound traffic via access control lists. Apparently not!

But it doesn’t stop there! No! No sirrreee… I started digging through their configuration settings and here are some gems:

  1. They use the same tracking system Google uses to create unique keys, except they built their own. That means the microtime of installation is sent to the mothership every single time someone pulls down the anti-phishing and anti-malware lists (from in the browser. This microtime is easily enough information to decloak people, which is presumably the same reason Google built it into the browser.
  2. All crash reports are sent to the mothership ( So every time the browser fails for some reason they get information about it. Useful for debugging and also for finding exploits in Firefox, without necessarily giving that information back to Mozilla – a U.S. company.
  3. All news feeds go back to the mothership in a specially crafted URL: At first it was unclear if that actually does anything or not, since we can’t see the IP address, but it looks like it probably does act as a feed aggregator.
  4. Strangely, the browser adds “.com” instead of “” as a suffix when the browser can’t find something. It’s odd because this means in some cases this might accidentally be contacting external hosts when someone typos something in the country. A bad design choice, but perhaps meant for usability since most things live on .com.
  5. There are quite a few references to “.php” on the mothership website. I would be unsurprised if most things on it were written in PHP.
  6. Then I spotted this little number: This is the warning that pops up when users turn on geolocation. But here’s the really crazy part: if you remove the DPRK specific URL part and just leave it as and substitute %LOCALE% with “ko” you end up on Mozilla’s site translated into Korean. Could the mothership be acting as a proxy? Is that how people are actually visiting the Internet – through a big proxy server? Can that really be true? It kind of makes sense to do it that way if you want to allow specific URLs through but not others on the same domain. Hm!
  7. More of the same. This time the safe browsing API that Google supports to find phishing/malware stuff — — if you remove the preceding part of the URL and fill in the variables it’s a real site. And there are a bunch more like this.
  8. Apparently they allow some forms of extensions, plugins and themes, though it’s not clear if this is the whole list or their own special brand of allowed add ons:

  9. Apparently all of the mail from the country goes through the single mothership URL. Very strange to build it this way, and obviously vulnerable to man in the middle attacks, sniffing and so on, but I guess no one in DPRK has any secrets, or at least not over email: I found a reference to “evolution” with regards to mail, which means there is a good chance North Korea is using the Evolution project for their country.

  10. Same thing with calendaring? So many sensitive things end up in calendars, like passwords, excel spreadsheets, etc… it’s still very odd that they haven’t bothered using HTTPS internally:

  11. This one blew my mind. Either it’s a mistake or a bizarre quirk of the way DPRK’s network works but the wifi URL for GEO still points to – not only is there no way for this to work since Google hasn’t gone through the country with their wifi cars, and it’s on the public Internet without going through their proxy of doom, but also it’s over HTTPS, meaning that if it were able to be contacted, the DPRK might have a hard time seeing what is being sent. Would they allow outbound HTTPS? More questions than answers it seems.
  12. The offical Naenara search function isn’t Google, and it’s not even clear if it’s a proxy or not. But one thing makes me think it might be – it’s in UTF-8 charcode, and not something that you might expect like BIG5 or ISO-2022-KR or SHIFT_JIS or something. But wait a tick, after a little digging I found a partial match on the URL: /search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1 and where did I find this? Google. Are they proxying Google results? I think so! That means that depending on what Google can put on those pages, they technically can run JavaScript and read the DPRK’s email/calendars, etc. using XMLHTTPRequest, since they are all on the same domain. Whoops!

  13. In looking around at the certificates that they support, I was not surprised to find that they accepted no other certificates as valid – only their own. That means it would be trivial to man in the middle any outbound HTTPS connection, so even if they do allow outbound access to Google’s JSON location API it wouldn’t help, because the connection and contents can be monitored by them. Likewise, no other governments can man in the middle any connections that the North Koreans have (I’m saying that with a bit of tongue in cheek, because of course they can according to Wikileaks docs, but this probably makes the DPRK feel better — and more importantly they probably don’t know how to do it in the same way as the NSA does, so they have to rely on draconian Internet breaking concepts like this).

  14. The browser automatically updates, without letting the browser disable that function. That’s actually a good security measure, but given how old this browser is, I doubt they use it often, and therefore it’s probably not designed to protect the user, but rather allow the government to quickly install malware should they feel the need. Wonderful.
  15. Even if the entire Internet is proxied through North Korean servers, and even if their user agent strings are filtered by the proxy, an adversary can still identify a user using Naenara by looking at it in JavaScript space using navigator.UserAgent. Their user agent is, “Mozilla/5.0 (X11; U; Linux i686; ko-KP; rv: 19.1br) Gecko/20130508 Fedora/1.9.1-2.5.rs3.0 NaenaraBrowser/3.5b4″ So if you see that UserAgent string in JavaScript you could target North Korean users rather easily.
  16. Although the Red Star OS does lock down things like their file manager that only shows you a few directories, disables the command-O (open) feature, removes the omnibar feature and so on, it’s still possible to do whatever you want. Using the browser users can go to file:/// to view files and they can write their own JavaScript using javascript: directives which give them just about any access they want, if they know what they’re doing. Chances are they don’t, but despite their Military’s best efforts the Red Star OS actually isn’t that locked down from a determined user’s perspective.
  17. Snort intrusion detection system is installed by default. It’s either used as an actual security mechanism as it was designed or it could be re-purposed as a way to constantly snoop on people’s computers to see what they are doing when they use the Internet. Even if it didn’t phone home necessarily, the DPRK soldier who broke down your door could fairly easily do forensics and see everything you had done without relying on any IP correlation at the mothership. So using your neighbor’s wifi isn’t a safe alternative for a political dissident using Red Star OS.

My ability to read North Korean is non-existent, so I had to muddle my way through this quite a bit, but I think we have some very good clues as to how this browser and more importantly how North Korea’s Internet works, or doesn’t work as it might be.

It is odd that they can do all of this off of one IP address. Perhaps they have some load balancing but ultimately running anything off of one IP address for a whole country is bad for many reasons. DNS is far more resilient, but it also makes things slower, in a country with Internet connectivity that is probably already pretty slow. If I were to guess, the DPRK probably uses a proxy and splits off core functions by URL to various clusters of machines. A single set of F5s could easily handle this job for the entire country. It would be slow, but it doesn’t seem the country cares much about the comforts of fast Internet anyway.

Ultimately the most interesting takeaway for me personally was what lengths North Korea goes to to limit what their people get to do, see and contribute to — Censorship at a browser and network level embodied in the OS called Red Star 3.0. It’s quite a feat of engineering. Creepy and cool. Download the Red Star OS here.

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)
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
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
HikaShop Object Injection
Covert Timing Channels based on HTTP Cache Headers
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

#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!

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.

Infancy of Code Vulnerabilities

I was reading something about modern browser behavior and it occurred to me that I hadn’t once looked at Matt’s Script Archive from the mid 1990s until now. I kind of like looking at old projects through the modern lens of hacking knowledge. What if we applied some of the modern day knowledge about web application security against 20-year-old tech? So I took at look at the web-board. According to Google there are still thousands of installs of WWWBoard lying around the web:

I was a little disappointed to see the following bit of text. It appears someone had beat me to the punch – 18 years ago!

# Changes based in part on information contained in BugTraq archives
# message 'WWWBoard Vulnerability' posted by Samuel Sparling Nov-09-1998.
# Also requires that each followup number is in fact a number, to
# prevent message clobbering.

In taking a quick look there have been a number of vulns found in it over the years. Four CVEs in all. But I decided to take a look at the code anyway. Who knows – perhaps some vulnerabilities have been found but others haven’t. After all, this has been nearly 12 years since the last CVE was announced.

Sure enough its actually got some really vulnerable tidbits in it:

# Remove any NULL characters, Server Side Includes
$value =~ s/\0//g;
$value =~ s/<!--(.|\n)*-->//g;

The null removal is good, because there’s all kinds of ways to sneak things by Perl regex if you allow nulls. But that second string makes me shudder a bit. This code intentionally blocks typical SSI like:

<!--#exec cmd="ls -al" -->

But what if we break up the code? We’ve done this before for other things – like XSS where filters prevented parts of the exploit so you had to break it up into two chunks to be executed together once the page is re-assembled. But we’ve never (to my knowledge) talked about doing that for SSI! What if we slice it up into it’s required components where:

Subject is: <!--#exec cmd="ls -al" echo='
Body is: ' -->

That would effectively run SSI code. Full command execution! Thankfully SSI is all but dead these days not to mention Matt’s project is on it’s deathbed, so the real risk is negligible. Now let’s look a little lower:

$value =~ s/<([^>]|\n)*>//g;

This attempts to block any XSS. Ironically it should also block SSI, but let’s not get into the specifics here too much. It suffers from a similar issue.

Body is: <img src="" onerror='alert("XSS");'

Unlike SSI I don’t have to worry about there being a closing comment tag – end angle brackets are a dime a dozen on any HTML page, which means that no matter what this persistent XSS will fire on the page in question. While not as good as full command execution, it does work on modern browser more reliably than SSI does on websites.

As I kept looking I found all kinds of other issues that would lead the board to get spammed like crazy, and in practice when I went hunting for the board on the Internet all I could find were either heavily modified boards that were password protected, or broken boards. That’s probably the only reason those thousands of boards aren’t fully compromised.

It’s an interesting reminder of exactly where we have come from and why things are so broken. We’ve inherited a lot of code, and even I still have snippets of Matt’s code buried in places all over the web in long forgotten but still functional code. We’ve inherited a lot of vulnerabilities and our knowledge has substantially increased. It’s really fascinating to see how bad things really were though, and how little security there really was when the web was in it’s infancy.

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.