Author Archives: Robert Hansen

About Robert Hansen

Robert Hansen is the Vice President of WhiteHat Labs at WhiteHat Security. He's the former Chief Executive of SecTheory and Falling Rock Networks which focused on building a hardened OS. Mr. Hansen began his career in banner click fraud detection at ValueClick. Mr. Hansen has worked for Cable & Wireless doing managed security services, and eBay as a Sr. Global Product Manager of Trust and Safety. Mr. Hansen contributes to and sits on the board of several startup companies. Mr. Hansen has co-authored "XSS Exploits" by Syngress publishing and wrote the eBook, "Detecting Malice." Robert is a member of WASC, APWG, IACSP, ISSA, APWG and contributed to several OWASP projects, including originating the XSS Cheat Sheet. He is also a mentor at TechStars. His passion is breaking web technologies to make them better.

Aviator Status – 100k Downloads and Growing!

I realize it’s only been a handful of days since we launched the Windows version of Aviator, but it’s been an exciting ride. If you’ve never had to support a piece of software, it feels a bit like riding an unending roller coaster — you’re no longer in control once you get on the ride put your software out there. People will use it however they use it, and as the developer you simply have to adapt and keep iterating to make the user experience better and better. You can never get off the ride, which is a wonderful feeling – if you happen to like roller coasters! Okay, enough with that analogy.

When we released Aviator for Mac in October, we felt we were onto something when people started – almost immediately – emailing us asking us for features. We were sure we were on the right track when the media started writing articles. And when the number of downloads climbed from the thousands to tens of thousands to close to 45,000 Mac OSX downloads in just five months, we thought we were getting pretty incredible traction. But none of that prepared us for the response we received in just the handful of days since we launched Aviator for Windows. In just 5 days since the Windows launch, we have already hit a total number of 100,000 Aviator users – and that is without spending a single dime on advertising!

We were also pleasantly surprised that a huge chunk of our users came from other regions – as much as 30% of our new Windows user base was from Asia. This means that Aviator is already making a difference in every corner of the world. We’re extremely excited by this progress, and are very encouraged to continue to iterate and deliver new features. I think this really shows how visceral people’s reaction to security and privacy is. It’s no wonder – we’ve never given this kind of control to users before. Either that or our users got wind of how much faster surfing without ads and third-party tracking can be. :) Ever tried to surf the Internet on in-flight wireless? With Aviator you will find that websites are actually usable — give it a try!

We may never know why so many people chose Aviator, but I do hope more people share their user stories with us. We want to know our successes as well as the challenges that remain before us as we continue on this unending roller coaster ride. We really do appreciate all of your feedback and we thank you for helping to make Aviator such a huge success, right out of the gate. We’re just getting started!

Download WhiteHat Aviator for Windows or Mac here: http://www.whitehatsec.com/aviator

WhiteHat Aviator Beta for Windows

Since launching the Mac version of WhiteHat Aviator in October, the number one most-asked-for feature was a Windows version of the browser. Today we hit a major milestone: our Labs team is excited to announce that we are launching the Windows beta. If you want to try it, please download Aviator for Windows here.

Outside of keeping our blog and Twitter followers up-to-date since it’s release in October, we have done little-to-nothing to get attention for Aviator. There has been no marketing or sales resources invested in Aviator. Despite this, we’ve gotten tens of thousands of downloads with our Mac OSX version, and that number has been growing rapidly as the world takes notice.

Now the obvious next question everyone will ask is: “when do I get a version for XYZ operating system?” While we know this is highly important to a lot of our users, we have to balance that with a number of other features — which leads us to perhaps the second most-asked question: “how are you making money on Aviator?” The answer is, right now we aren’t. Therefore, some of our efforts will also be directed towards determining how to sell this in a way that does not involve profiting from our users’ information as many other browsers are in the unfortunate business of doing. As the saying goes, “if you aren’t paying for it, you’re the product.”

That said, we want to make sure that all of our existing users of WhiteHat Aviator know that they will continue to get the browser for free, forever. That’s right! Once we have determined how to monetize it, only new users will need to pay for a license. So, by all means encourage your friends to download it now, so they can enjoy Aviator for free, forever. This is our small way of thanking early Aviator adopters: if you’re one of them, you will never have to pay. A safer browser with free lifetime technical support? It’s unheard of, I know!

Don’t worry, we have a lot of exciting features on the horizon, and we do plan on supporting a number of additional operating systems. One thing at a time! We are thrilled with the hundreds of people who have written encouraging emails, made suggestions, offered feedback and sent us bug reports. We know we’ve hit a nerve and we’re excited by the prospect of a better, faster browser that works for the masses.

Lastly, a special thanks to all of our Windows Alpha testers and Mac Beta testers, without whom we surely wouldn’t have had such a well thought-out product. Please keep your feedback coming! Your input is critical for improving future Aviator versions.

List of HTTP Response Headers

Every few months I find myself looking up up the syntax of a relatively obscure HTTP header. Regularly I find myself wondering why there isn’t a good definitive list of common HTTP Response headers anywhere. Usually the lists on the Internet are missing half a dozen HTTP headers. So I’ve taken care to gather a list all of the HTTP response headers I could find. Hopefully this is useful to you, and removes some of the mystique behind how HTTP works if you’ve never seen headers before.

Note: this does not include things like IncapIP or other proxy/service specific headers that aren’t standard, and nor does it include request headers.

Header Example Value Notes
Access-Control-Allow-Credentials true
Access-Control-Allow-Headers X-PINGOTHER
Access-Control-Allow-Methods PUT, DELETE, XMODIFY
Access-Control-Allow-Origin http://example.org
Access-Control-Expose-Headers X-My-Custom-Header, X-Another-Custom-Header
Access-Control-Max-Age 2520
Accept-Ranges bytes
Age 12
Allow GET, HEAD, POST, OPTIONS Commonly includes other things, like PROPFIND etc…
Alternate-Protocol 443:npn-spdy/2,443:npn-spdy/2
Cache-Control private, no-cache, must-revalidate
Client-Date Tue, 27 Jan 2009 18:17:30 GMT
Client-Peer 123.123.123.123:80
Client-Response-Num 1
Connection Keep-Alive
Content-Disposition attachment; filename=”example.exe”
Content-Encoding gzip
Content-Language en
Content-Length 1329
Content-Location /index.htm
Content-MD5 Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range bytes 21010-47021/47022
Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP default-src ‘self’ Different header needed to control different browsers
Content-Security-Policy-Report-Only default-src ‘self’; …; report-uri /csp_report_parser;
Content-Type text/html Can also include charset information (E.g.: text/html;charset=ISO-8859-1)
Date Fri, 22 Jan 2010 04:00:00 GMT
ETag “737060cd8c284d8af7ad3082f209582d”
Expires Mon, 26 Jul 1997 05:00:00 GMT
HTTP /1.1 401 Unauthorized Special header, no colon space delimiter
Keep-Alive timeout=3, max=87
Last-Modified Tue, 15 Nov 1994 12:45:26 +0000
Link <http://www.example.com/>; rel=”cononical” rel=”alternate”
Location http://www.example.com/
P3P policyref=”http://www.example.com/w3c/p3p.xml”, CP=”NOI DSP COR ADMa OUR NOR STA”
Pragma no-cache
Proxy-Authenticate Basic
Proxy-Connection Keep-Alive
Refresh 5; url=http://www.example.com/
Retry-After 120
Server Apache
Set-Cookie test=1; domain=example.com; path=/; expires=Tue, 01-Oct-2013 19:16:48 GMT Can also include the secure and HTTPOnly flag
Status 200 OK
Strict-Transport-Security max-age=16070400; includeSubDomains
Timing-Allow-Origin www.example.com
Trailer Max-Forwards
Transfer-Encoding chunked compress, deflate, gzip, identity
Upgrade HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Vary *
Via 1.0 fred, 1.1 example.com (Apache/1.1)
Warning Warning: 199 Miscellaneous warning
WWW-Authenticate Basic
X-Aspnet-Version 2.0.50727
X-Content-Type-Options nosniff
X-Frame-Options deny
X-Permitted-Cross-Domain-Policies master-only Used by Adobe Flash
X-Pingback http://www.example.com/pingback/xmlrpc
X-Powered-By PHP/5.4.0
X-Robots-Tag noindex,nofollow
X-UA-Compatible Chome=1
X-XSS-Protection 1; mode=block

If I’ve missed any response headers, please let us know by leaving a comment and I’ll add it into the list. Perhaps at some point I’ll create a similar list for Request headers, if people find this helpful enough.

Aviator Updates and Windows Alpha

Aside from the a Windows version of Aviator which is on the way (we get countless emails a day asking about it), we wanted to quickly update our users on what the latest versions of Aviator for Mac have fixed. Here is a list of the various fixes:

Aviator Release 1.4

  • This release contained crash fixes.
  • Links from emails or IMs, etc. will always be opened in protected mode.
  • Focus is set to the omni bar when opened in a new tab.

Aviator Release 1.5

  • This release contained fix for an AdBlock extension installation issue – a common extension requested by our users.

Aviator Release 1.6

  • This release updated Aviator to the latest version (31.0.1650.57) of Chromium at the date of release.

Aviator Release 1.7

  • This release contains a bugfix for an Application quit command issue not working.

The browser should have auto updated, but if it didn’t for some reason please download the latest version to get the fixes above. You can check your current version by going to “WhiteHat Aviator”->”About WhiteHat Aviator.” As we begin the countdown to the launch of the Windows Beta, we are opening our program to users who want to be added to the list of Alpha testers for Windows. The Alpha user program is set to probably start the second week of Febuary or therabouts. Please contact us if you’re interested in joining the Aviator Alpha for Windows.

Why com.com Should Scare You

A long time ago I began to compile a list of lesser known but still very scary choke points on the Internet. This was a short list of providers (like the DNS 4.2.2.2 that most routers use, for instance) that could have major impact if they were ever compromised or owned by a nefarious 3rd party. One of those was com.com.

Com.com is the single best typo squatter domain on the planet. Let’s say, for instance, you accidentally type in user@yahoo.com.com (notice the end there). Yes, it would go to .com.com email servers if they were set up to allow email to come in. If you typed a URL as http://www.yahoo.com.com similarly, you would also redirect to the typo domain. Or how about phishing sites of ebay.com.com or have you downloaded the latest patch from microsoft.com.com? Given that .com is the largest TLD, com.com is the best typo domain naturally.

A few months ago and without much fan fare, com.com was silently sold by CNET to DSparking.com – one of the most notorious domain squatters ever. Sources close to the deal told me it was sold for around $1.5 million. Yes, the fox owns the hen-house. For $1.5 million it was a steal though – it’s easily worth that just in typo traffic and the huge volume of accidental inbound links.

However, things are not as bad as they could be. For instance, port 80 (web) is open, yes, but port 25 (mail) is not. If and when DSparking decides to open port 25 they will start receiving tons of email that is potentially extremely sensitive. Even if it seems rejected by the mail servers they could still be logging it.

For now mail appears to be closed and has been since the deal went through. They could easily be opening port 25 only to selective IP address ranges, or even opening and closing it periodically to get a snapshot of traffic. There’s no easy way to know for sure. I doubt it’s open at all but should that change, and it could easily, this should be considered an extremely dangerous domain.

Correction:
as @spazef0rze pointed out although port 25 is closed on the website, mail is still being processed through a seperate DNS entry:

$ host -t MX yahoo.com.com
yahoo.com.com mail is handled by 10 mx.b-io.co.

Also, as @mubix noted, there are many other ports/protocols that can be subject to interception if typo’d in the same way. So yes, it’s probably time to block this. No good can come of it.

Aviator 1.2 Beta Released

A few weeks have passed and we’ve had an overwhelmingly positive response from the community for the Aviator Beta. As you can probably expect, the vast majority of comments we received were around building a Windows version or a Linux version. But in the mean time, we wanted to make sure we continued iterating on some of the bugs that have floated in. Aviator version 1.2 has the following changes:

  • Fixed gate keeper – unidentified developer code signing issue
  • Fixed crash issue with Mac version 10.6
  • Fixed plugins installation issue (correcting an error in the User Agent)
  • Fixed broken images while adding new user in settings page
  • Fixed typo issue in the Protected mode message popup
  • Permissions fixed to be safer and less permissive

If you already have Aviator, it should automatically update. If you don’t, please feel free to download Aviator here.

We’re committed to fixing the remaining issues, and iterating. As we decide how to move forward we encourage everyone to continue to send us bug reports and tell us what you think, what you’d like to see, and how we can improve. You can reach us through one of our emails. Together we’ll make the web a more private place, one browser at a time!

Blindspot – Target Fixation

This is part two of a series of posts about blindspots that I discussed during my LASCON keynote presentation this year. To see the first post about network and host security blindspots, click here.

One thing I have come to notice is that there is a strange tendency in our industry to focus on specific things, just because that’s what’s interesting to us. I definitely encourage enthusiasm, but not when it comes with a blindspot towards other vulns. For instance, one excercise I regularly ask people to do is to give me an off the cuff DREAD severity rating for a particular vuln that they are currently excited about. They start by saying, “It’s horrible” – which is a very strong word in the English language I’d typically say is a high level of risk severity. However, after performing a DREAD analysis by hand, it almost always ends up significantly lower than the person instinctually felt.

Likewise, I see strange blindspot in the industry around buying of vulns. I did an experiment and attempted to sell a half dozen vulns (mostly medium to high level severity) and I was surprised to find that there were no buyers. Let me show you why that’s odd. A buffer overflow in some DNS server might give an attacker a user level access to a machine, and that would be worth $100k on the vuln markets, let’s say. Some of the exploits I discovered would allow an attacker to get a shell on the box in the “www” user context. So both vulns are almost equivalent with the exception of the method of propagation (remote unauthenticated vs CSRF). One is worth $100k and the other is worth $0. Seems odd? Let’s dig in a bit deeper.

I began asking my friends in the underground what a compromised webserver is worth to them. They say somewhere around $500 for what they were doing with it. So if my exploit allowed them to compromise 2,000 CMSs (which it could rather easily) it would be a $1 million pay day for their group. I confirmed with then that even an attack using CSRF would still be easy to monetize – so even the method of propagation wasn’t an issue. There’s a blindspot here. If the security industry is not willing to pay a dime, but attackers are valuing it at $1 million, that’s a discrepancy that makes it extremely difficult to stay on the right side of the law.

I think the problem has always been that there is a misperception in our industry of the importance of what we think is cool or intellectually interesting versus what attackers think is useful and can be leveraged to make money. Admittedly, vuln purchase programs all come down to a supply and demand issue. However, since there is no easy outlet for webappsec vuln research even after all these years, things will continue to stay bad for a very long time. I predict this problem won’t go away any time in the near future — until all vulns are purchased on an equal playing field, using DREAD or something similar. For now though, expect your CMSs to stay vulnerable, unless you’re being extremely proactive.

The point is, I encourage you not focus too much on one target, one vuln, or one vuln class, when there are others with the potential to do equal or greater damage potential or that are easier to exploit. Just because it’s interesting to us as security researchers doesn’t mean attackers see it the same way.

Blindspot – Network and Host Security

At LASCON this year, I was invited to deliver the keynote address. Unlike most of my presentations, I got an opportunity to be really reflective and give my take on how the industry is progressing. Rather than deliver a purely technical presentation I decided to focus on some blindspots that I saw in the industry. These are areas where we can do better and I thought I would recap some of them here.

The first blindspot that I see regularly in the webappsec space is a general failure to understand how the entire industry and the Internet at large works. I regularly run into people who have worked in security for the better part of their career but don’t really understand how things work. Specifically I am talking about network security, host security, OS rendering, caching, DNS, TCP/IP and so on, all of which are highly important, but tend to get missed almost entirely by people our area of security – webappsec.

I think this is probably a bit of a hold over from the old developer mantra of thinking that “if it’s not code that you wrote, it’s not your problem, it’s a sys-admin’s problem.” Unfortunately that line of thinking allows us to fully ignore major areas of security, and I see people pigeonholed into their small issues, without thinking about the larger security realm. This can even get smaller than webappsec as a whole, down to individual vuln classes within webappsec.

A good simple example of how this can directly affect us is STS (Strict Transport Security). Once upon a time, Firesheep was making a lot of news, as was Middler and SSLStrip, and we as an industry needed a way to ensure that if someone came to our site that we always sent them to HTTPS. There are two problems with STS though. By virtue of creating a single ‘bit’ of information per subdomain, pinned to HTTP, STS turns into a method of tracking people. If you get 30 subdomains, you have enough bits to properly track every IP on the Internet. Of course after this issue was uncovered the “fix” was to delete the STS flag upon deleting cache, which is another way people can be tracked. In my opinion that makes STS not worth much (it’s either important to have or it isn’t, and it’s either important not to be tracked or it isn’t – either way, it’s a bad design as a result).

With browsers, when you go from an HTTPS site to an HTTP site the browser is supposed to strip out the referring URL to protect against information leakage of nonces, URL structures, private domain names, etc. But with STS in (at least some) browsers it allows an adversary that has been linked to from HTTPS sites to upgrade themselves to HTTPS using STS. If the STS flag is sent the browser doesn’t realize this is not really an HTTPS->HTTPS link and sends the referring URL on subsequent requests after the STS flag has been set.

By only focusing on one problem (man in the middle attacks) STS has ended up causing at least two additional security issues (de-cloaking and information leakage) because a proper threat model was never completed. Being only partially aware of certain aspects of our industry makes it extremely easy to have blindspots. Any area that you don’t feel comfortable with should be an area that you focus on, or at minimum know the guy/girl who is comfortable with that area and get them on speed dial. This isn’t just about network and host security, this is about being hyper focused on a single issue/threat at the expense of the rest of the ecosystem. We all have blindspots, it’s just a matter of what we do about it.

Over the next few posts I will share some insights into what I think are some of the other industry blindspots.

Introducing WhiteHat Aviator – A Safer Web Browser

Jeremiah Grossman and I have been publicly discussing browser security and privacy, or the lack thereof, for many years. We’ve shared the issues hundreds of times at conferences, in blog posts, on Twitter, in white papers, and in the press. As the adage goes, “If you’re not paying for something, you’re not the customer; you’re the product being sold.” Browsers are no different, and the major vendors (Google, Mozilla, Microsoft) simply don’t want to make the changes necessary to offer a satisfactorily secure and private browser.

Before I go any further, it’s important to understand that it’s NOT that the browser vendors (Google, Mozilla, and Microsoft) don’t grasp or appreciate what plagues their software. They understand the issues quite well. Most of the time they actually nod their heads and even agree with us! This naturally invites the question: “why aren’t the necessary changes made to fix things and protect people?”

The answer is simple. Browser vendors (Google, Mozilla, and Microsoft) choose not to make these changes because doing so would run the risk of hurting their market share and their ability to make money. You see, offering what we believe is a reasonably secure and privacy-protecting browser requires breaking the Web, even though it’s just a little and in ways few people would notice. As just one example of many, let’s discuss the removal of ads.

The online advertising industry is promoted as a means of helping businesses reach an interested target audience. But tens of millions of people find these ads to be annoying at best, and many find them highly objectionable. The targeting and the assumptions behind them are often at fault: children may be exposed to ads for adult sites, and the targeting is often based on bias and stereotypes that can cause offense. Moreover, these ads can be used to track you across the web, are often laden with malicious malware, and can point those who click on them to scams.

One would think that people who don’t want to click on ads are not the kind of people the ad industry wants anyway. So if browser vendors offered a feature capable of blocking ads by default, it would increase the user satisfaction for millions, provide a more secure and privacy-protecting online experience, and ensure that advertisements were seen by people who would react positively, rather than negatively, to the ads. And yet not a single browser vendor offers ad blocking, instead relying on optional third-party plugins, because this breaks their business model and how they make money. Current incentives between the user and browser vendor are misaligned. People simply aren’t safe online when their browser vendor profits from ads.

I could go on and give a dozen more examples like this, but rather than continuing to beat a drum that no one with the power to make the change is willing to listen to – we decided it was time to draw a line in the sand, and to start making the Web work the way we think it should: a way that protects people. That said, I want to share publicly for the first time some details about WhiteHat Aviator, our own full-featured web browser, which was until now a top secret internal project from our WhiteHat Security Labs team. Originally, Aviator started out as an experiment by our Labs team to test our many Web security and privacy theories, but today Aviator is the browser given to all WhiteHat employees. Jeremiah, myself, and many others at WhiteHat use Aviator daily as our primary browser. We’re often asked by those outside the company what browser we use, to which we have answered, “our own.” After years of research, development, and testing we’ve finally arrived at a version that’s mature enough for public consumption (OS X). Now you can use the same browser that we do.

WhiteHat Security has no interest or stake in the online advertising industry, so we can offer a browser free of ulterior motives. What you see is what you get. We aren’t interested in tracking you or your browsing history, or in letting anyone else have that information either.

Aviator is designed for the every day person who really values their online security and privacy:

  • We bundled Aviator with Disconnect to remove ads and tracking
  • Aviator is always in private mode
  • Each tab is sandboxed (a sandbox provides controls to help prevent one program from making changes to others, or to your environment)
  • We strip out referring URLs across domains to protect your privacy
  • Flash and Java are click-to-play – greatly reducing the risk of drive-by downloads
  • We block access to websites behind your firewall to prevent Intranet hacking

Default settings in Aviator are set to protect your security and your privacy.

We hope you enjoy using Aviator as much as we’ve enjoyed building it. If people like it, we will create a Windows version as well and we’ll add additional privacy and security features. Please download it and give it a test run. Let us know what you think! Click here to learn more about the Aviator browser.

JavaScript Rendering and SEO

Over the weekend I spent some thinking about the fact that Google renders JavaScript. It occurred to me that Google is almost certainly smart enough to (a) cache all JS so that if it sees it multiple times it’s not going to pull it multiple times, and (b) also check to make sure that the JavaScript renderer doesn’t run away and eat up tons of processor time if the JavaScript is poorly written. Therein may lie opportunity for the malicious marketer (often called an SEO – search engine optimizer/search engine optimizing) who is trying to get to the top of the Google search results page.

Let’s say Google will only perform a loop as long as it believes it is not infinite and/or as long as the rendering engine doesn’t loop “too many” times. By finding that looping limit of N, you can do N+1 loops and put your cloaking code (where Google sees a benign high quality site and the user sees something quite differently) in plain sight. You may have to do some testing, and it’s entirely possible that Google’s rendering engine uses the same limits the browser does when it determines if something is going to run slowly before it throws a “slow script” warning (that’s the worst case scenario for messing with it).

Google’s rendering engine has almost certainly got to have limits though, and there is some experimentation that can be done there. The trick would be to find a mathematical JavaScript function that Google gives up on but the browser wouldn’t. As an aside, if Google is not smart enough to put limits in place, you can use it to mine bitcoin for you by making each URL unique so that Google can’t cheat and cache it. Either way, a malicious marketer wins, assuming there is no penalty associated.

Of course, it is possible that Google may use the “slow script” as a signal of a poor quality site; I know I would. It stands to reason that they may use that as a signal, because page load time has always been something Google has professed to care about, and with JavaScript rendering they can get a clearer view of that. That means that marketers should be very cautious in allowing third party JavaScript on their site for reasons beyond the security implications, since if it slows down page rendering time that could easily be cause to reduce their SEO rankings. There’s definitely some experimentation to do there.

The short of it is, if you run a website, try to avoid 3rd party JavaScript whenever possible to avoid this sort of slowness that might be used as a negative SEO tool.