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.

DHS and Cyberterrorism

The DHS was recently polled on what groups and attacks they are personally most concerned about. This comes from a pretty wide range of intelligence officers at various levels of the military industrial complex. This underscores how the military is thinking and what they are currently most focused on. The tidbits I found interesting are on pages 7 and 8:

https://www.start.umd.edu/pubs/START_UnderstandingLawEnforcementIntelligenceProcesses_July2014.pdf

The DHS seems to be most concerned about Sovereign Citizens and Islamic Extremists/Jihadists (in that order). The rationale isn’t well explained, but I would presume that physical proximity and the radical nature of Sovereign Citizen groups trumps the extremist nature of Jihadists. I’m speculating, but that would seem to make sense. It could also be a reaction to FUD, but it’s hard to say.

More interestingly, the threat they find most viable is Cyberterrorism. That makes a lot of sense, because Cyberterrorism is cheap, can be done instantaneously, can be done remotely, and can be done with minimal skills and at minimal risk. It’s really hard to tell what’s Cyberterrorism versus what is just a normal for-profit attack, and attribution is largely an un-solvable problem if the attacker knows what they’re doing. Also, even if you can identify the correct adversary, extradition/rendition are tough problems.

There’s not a lot of substance here, because it’s all polls, but it’s interesting to see that our industry is at the top of the US intelligence community’s mind.

The Ghost of Information Disclosure

Information disclosure is a funny thing. Information disclosure can be almost completely innocuous or — as in the case of Heartbleed — it can be devastating. There is a new website called un1c0rn.net that aims to make hacking a lot easier by letting attackers utilize Heartbleed data that has been amassed into one place.

The business model is simple – 0.01 Bitcoins (Around $5) for data. It leaves
no traces on the remote server because the data isn’t stored there anymore,
it’s on un1c0rn’s server. So let’s play a sample attack out.

1) Heartbleed comes out;

2) Some time in the future un1c0rn scans a site that is vulnerable and logs it;

3) A would-be attacker searches through un1c0rn and finds a site of interest;

4) Attacker leverages the information to successfully mount an attack against the target server leveraging the data.

In this model, the attacker’s first packets to the server in question could be
the one that compromises them. But it’s actually more interesting than that. As I was looking through the data I found this query.

un1c0rn

For those of you who don’t live and breathe HTTP this is an authorization request with a base64 encoded string (which is trivial to reverse) that contains the usernames and passwords to the sites in question. This simple request found 400 sites with this simple flaw in it. So let’s play out another attack scenario.

1) Heartbleed comes out;

2) Some time in the future un1c0rn scans a site that is vulnerable and logs it;

3) Site is diligent and finds that they are vulnerable, patching up immediately and switching out their SSL certificate with a new one.

4) A would-be attacker searches through un1c0rn and finds a site of interest;

5) Using the information they found they still compromise the site with the username/password, even though the site is no longer vulnerable to the attack in question.

This is the problem with Information Disclosure – it still can be useful even long after the hole that was used to gather the data has been closed. That’s why in the case of Heartbleed and similar attacks not only do you have to fix the hole but you also have to expire all of the passwords, and remove all of the cookies or any other way that a user could gain access to the system.

The moral of the story is that you may find yourself being compromised seemingly almost magically in a scenario like this. How can someone guess a cookie correctly on the first attempt? Or guess a username/password on the first try? Or exploit a hole without ever having looked at your proprietary source code or even having visited your site before? Or find a hidden path to a directory that isn’t linked to from anywhere? Well, it may not be magic – it may be the ghost of Information Disclosure coming back to haunt you.

Spooky!

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.