Category Archives: Vulnerabilities

#HackerKast 17: UK Bans WhatsApp and iMessage, Instagram Privacy Issues, Cross Site Content Hijacking (XSCH), Amazon S3 Bitcoin Hack

Howdy Partners! Hope you all are in full swing in the new year and taking names. I know for a fact that a ton of you are busy since every hotel in Santa Clara, Calif., was sold out this month just as Robert and I were trying to visit the mothership.

Anywho… we started this week’s HackerKast chatting about how our blog post of the North Korean Web Browser got so much traffic that it DoS’d us. The ol’ Reddit hug of death got us and our poor IT department was thrilled with us.

The first news story we covered was the brilliant discussion going on across the pond in the UK about banning a ton of encrypted messaging services, including WhatsApp and iMessage. We all feel this is a silly reactionary measure to try to thwart terrorist communications but will have repercussions that will be wide-reaching. Knowing our audience, I’m probably preaching to the choir, but there are plenty of legitimate reasons for strong encryption protected messaging services. I think another side of my feelings were best summed up by a tweet:

Next, we brought up some Instagram news about a privacy problem they had over there. Turns out that if you ever had your Instagram profile set to public, no matter what your current privacy settings, your photos are accessible via direct URL. This is a thinly veiled illusion of privacy and further proves that if you don’t want a photo seen, you shouldn’t put it on the Internet at all.

Robert followed this up by mentioning briefly some new attack research that was published recently that was dubbed Cross Site Content Hijacking. We need another acronym like we need a hole in the head but this research could prove to be very interesting. The thing that perked our ears up about this type of vuln was that it might be possible to read arbitrary HTTP Headers across domain. This includes referring URLs which are widely used as a CSRF protection in many web applications including the Django framework. We haven’t dug deeply into this one but wanted to bring it up as a potentially interesting bit of research for you folks to chew on.

Some news about an Amazon S3 hack bubbled to the top this week which we’ve heard about before but is still super fun to talk about and – more importantly – to learn to protect yourself from. We all know our private keys are an important thing to keep private but with the ever-growing popularity of programmatically spinning up and down virtual instances in Amazon it is becoming easy to forget those private keys in your code. If you are using these keys in development and you accidentally leave them in your code when you push it up to a GitHub repo, those keys are now public. GitHub and Amazon do a good job of trolling the Internet keeping an eye out for this happening but it still happens, even to the best of us. A popular (mis)use case of this kind of hack is using your private key to spin up instances that start mining bitcoins for the attacker. This usually doesn’t get caught until the victim gets the big bill in the mail for the CPU time.

“Kid hacks into school’s website to shame them for making them go to school when the roads were covered in snow” has to be our favorite headline of the week. We’d love to include the screenshots from this website defacement but they are pretty NSFW. The kids hacking school stories are always a lot of fun because I think it resonates with a lot of us who have memories of being bored in school and playing with computers just wondering if you could switch your grades. Not that any of us did such a thing.

Notable stories this week that didn’t make the cut:
Iran oders 3 communication apps blocked (LINE, WhatsApp and Tango)
AT&T is going to start supporting webrtc
Silk Road Reloaded moving to I2p instead of Tor
Obama proposal: Hacked companies have 30 days to fess up

References:
WhatsApp and iMessage could be banned under new surveillance plans
Iran orders 3 communication apps blocked
Your private Instagrams weren’t as private as you thought they were
Content hijacking proof-of-concept using Flash, PDF and Silverlight
Dev put AWS keys on Github. Then BAD THINGS happened
Angry Student Hacks County’s Website to Apologize for Snow Day

#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

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.

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:

http://www.scriptarchive.com/download.cgi?s=wwwboard&c=txt&f=wwwboard.pl

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.

#HackerKast 12: Operation Cleaver, Sony and PayPal Hacks, Google’s Alternative to CAPTCHA

Kicked this week off in the holiday spirit with Robert and Jeremiah hanging out in a festive hotel down in Los Angeles, probably preparing to cause lots of trouble. The first story we touched on was about Operation Cleaver, a report put out by Cylance. This research investigates the movements and threat of one particular pro-Iranian hacking group who was targeting airports and transportation systems across 16 countries. The claim is that this group has “attained the highest level of system access” across all the countries targeted. The reason us web nerds are interested is that the main front door used to start these hacks is pointing towards SQL injection.

Next, we had to do it: we simply couldn’t get away with a HackerKast without talking about Sony. This hack is bad. Bad for a lot of people and as Jeremiah points out, there is a real human aspect to this. Tons of real people’s information has been leaked that will cause a lot of pain. So far, 40GB of a claimed 100TB that was stolen is now leaked and available on the Internet via torrents. Robert brings up a good point that due to the business that Sony does, moving around Terabytes of data probably isn’t an alarm-ringing event. Another great point we discussed is that this hack required insider access. Even though the end result was bad, this does point to the fact that Sony is probably doing a pretty good job on their exterior security otherwise the attackers would’ve taken the path of least resistance there.

Can we get through an episode without talking about a WordPress vulnerability? Please? Anyway, we have another one this week that affects 850,000 WordPress sites. The culprit this time is the WordPress Download Manager which is extremely popular. This plugin is vulnerable to a very blatant Remote Code Execution via a simple POST request. An attacker can craft an HTTP POST request with some PHP code and it gets immediately executed on the server. This would lead to absolute and full compromise of the server running this plugin. Do I even need to mention that the vulnerable function has the names “ajax_exec” in it?

Robert then took a look at a nasty PayPal hack that was put out by an Egyptian researcher this week. The clever attack outlined here utilized a CSRF vulnerability to bypass protections in place to change a user’s password reset security questions. These security questions are a soft spot in a lot of web applications since they are just as good as a password to get into an account since if answered correctly you can just make your own password. The reason CSRF is so bad on this functionality is because an attacker can force an authenticated user’s browser to reset these questions unbeknownst to them. I then sat back for a moment and let Jeremiah and Robert reminisce about the good ole days when dinosaurs roamed the internet and CSRF wasn’t even considered a vulnerability.

Finally, we talked a bit about the new Google gadget recently released which is a bold new alternative to the ever-annoying CAPTCHA. Instead of entering some mess of garbled text, Google is claiming it can detect the difference between a bot and a human with just one click of a checkbox. Robert got visibly angered by this idea (ok maybe not, but he really doesn’t like it). He does admit that today this idea will work well due to the current heuristics in place of detecting a human. Things like mouse movements, time to click the button, etc., are key pieces of information that differentiate real from fake traffic and have been important to Google for the sake of detecting Ad Fraud for years. The problem lies in that this has now been released publicly for any attacker to fuzz this and defeat the heuristics. The rest of the problems with this probably deserve a separate blog post but to put a bow on it, what Robert is suggesting is that this is now going to raise the bar necessary for bot sophistication. Along with this boost in sophistication comes the fact that it will break the ability of non-Google-level heuristics to keep up.

That’s a wrap this week, hope you enjoy watching as much as we enjoy making these episodes!

Resources:
Security Advisory – High Severity– WordPress Download Manager
Hacking PayPal Account with Just a Click
Are you a robot? Introducing ‘No CAPTCHA reCAPTCHA’
Critical networks in US, 15 other nations, completely owned, possibly by Iran
Cylance: Operation Cleaver Report
Why Sony’s Plan to Foil PlayStation-Type Attacks Faltered