Tag Archives: security

It Can Happen to Anyone

Earlier this summer, The Intercept published some details about the NSA’s XKEYSCORE program. Those details included some security issues around logging and authorization:

As hard as software developers may try, it’s nearly impossible to write bug-free source code. To compensate for this, developers often rely on multiple layers of security; if attackers can get through one layer, they may still be thwarted by other layers. XKEYSCORE appears to do a bad job of this.

When systems administrators log into XKEYSCORE servers to configure them, they appear to use a shared account, under the name “oper.” Adams notes, “That means that changes made by an administrator cannot be logged.” If one administrator does something malicious on an XKEYSCORE server using the “oper” user, it’s possible that the digital trail of what was done wouldn’t lead back to the administrator, since multiple operators use the account.

There appears to be another way an ill-intentioned systems administrator may be able to cover their tracks. Analysts wishing to query XKEYSCORE sign in via a web browser, and their searches are logged. This creates an audit trail, on which the system relies to ensure that users aren’t doing overly broad searches that would pull up U.S. citizens’ web traffic. Systems administrators, however, are able to run MySQL queries. The documents indicate that administrators have the ability to directly query the MySQL databases, where the collected data is stored, apparently bypassing the audit trail.

These are exactly the same kinds of problems that led to the Snowden leaks:

As a system administrator, Snowden was allowed to look at any file he wanted, and his actions were largely unaudited. “At certain levels, you are the audit,” said an intelligence official.

He was also able to access NSAnet, the agency’s intranet, without leaving any signature, said a person briefed on the postmortem of Snowden’s theft. He was essentially a “ghost user,” said the source, making it difficult to trace when he signed on or what files he accessed.

If he wanted, he would even have been able to pose as any other user with access to NSAnet, said the source.

The NSA obviously had the in-house expertise to design the system differently. Surely they know the importance of logging from their own experience hacking things and responding to breaches. How could this happen?

The most cynical explanation is that the point is not to log everything. Plausible deniability is a goal of intelligence agencies. Nobody can subpoena records that don’t exist. The simple fact of tracking an individual can be highly sensitive (e.g., foreign heads of state).

There’s also a simpler explanation: basic organizational problems. From the same NBC News article:

It’s 2013 and the NSA is stuck in 2003 technology,” said an intelligence official.

Jason Healey, a former cyber-security official in the Bush Administration, said the Defense Department and the NSA have “frittered away years” trying to catch up to the security technology and practices used in private industry. “The DoD and especially NSA are known for awesome cyber security, but this seems somewhat misplaced,” said Healey, now a cyber expert at the Atlantic Council. “They are great at some sophisticated tasks but oddly bad at many of the simplest.

In other words, lack of upgrades, “not invented here syndrome,” outsourcing with inadequate follow-up and accountability, and other familiar issues affect even the NSA. Very smart groups of people have these issues, even when they understand them intellectually.

Each individual department of the NSA probably faces challenges very similar to those of a lot of software companies: things need to be done yesterday, and done cheaper. New features are prioritized above technical debt. “It’s just an internal system, and we can trust our own people, anyway…”

Security has costs. Those costs include money, time, and convenience — making a system secure creates obstacles, so there’s always a temptation to ignore security “just this once,” “just for this purpose,” “just for now.” Security is a game in which the adversary tests your intelligence and creativity, yes; but most of all, the adversary tests your thoroughness and your discipline.

The Perils of Privacy Personas

Privacy is a complex beast, and depending on who you talk to, you get very different opinions of what is required to be private online. Some people really don’t care, and others really do. It just depends on the reasons why they care and the lengths they are both willing and able to go through to protect that privacy. This is a brief run-down on some various persona types. I’m sure people can come up with others, but this is a sampling of the kinds of people I have run across.

Alice (The Willfully Ignorant Consumer)

  • How Alice talks about online privacy: “I don’t have anything to hide.”
  • Alice’s perspective: Alice doesn’t see the issues with online advertising, governmental spying and doesn’t care who reads her email, what people do with her information, etc. She may, in the back of her mind, know that there are things she has to hide but she refuses to acknowledge it. She is not upset by invasive marketing, and feels the world will treat her the same way she treats it. She’s unwilling to do anything to protect herself, or learn anything beyond what she already knows. She’s much more interested in other things and doesn’t think it’s worth the time to protect herself. She will give people her password, because she denies the possibility of danger. She is a danger to all around her who would entrust her with any secrets.
  • Advice for Alice: Alice should do nothing. All of the terrible things that could happen to her don’t seem to matter to her, even when she is advised of the risks. This type of user can actually be embodied by Microsoft’s research paper So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users, which is to say that spending time on security has a negative financial tradeoff for most of the population when taken in a vacuum where one person’s security does not impact another’s.

Bob (The Risk Taker)

  • How Bob talks about online privacy: “I know I shouldn’t do X but it’s so convenient.”
  • Bob’s perspective: Bob knows that bad things do happen, and is even somewhat concerned about them. However, he knows he doesn’t know enough to protect himself and is more concerned about usability and convenience. He feels that the more he does to protect himself, the more inconvenient life is. He can be summed up with the term “Carpe Diem.” Every one of his passwords is the same. He choses weak security questions. He uses password managers. He clicks through any warning he sees. He downloads all of the programs he finds regardless of origin. He interacts on every social media site with a laissez-faire attitude.
  • Advice for Bob: He should pick email/hosting providers and vendors that naturally take his privacy and security seriously. Beyond that, there’s not much else he would be willing to change.

Cathy (The Average Consumer)

  • How Cathy talks about online privacy: “This whole Internet thing is terrifying, but really, what can I do? Tax preparation software, my utilities and email are essential. I can’t just leave the Internet.”
  • Cathy’s perspective: Cathy knows that the Internet is a scary place. Perhaps she or one of her friends has already been hacked. She would pick more secure and private options, but simply has no idea where to start. Everyone says she should take her security and privacy seriously, but how and who should she trust to give her the best advice? Advertisers are untrustworthy, security companies seem to get hacked all the time – nothing seems secure. It’s almost paralyzing. She follows whatever best practices she can find, but doesn’t even know where to begin unless it shows up in whatever publications she reads and happens to trust.
  • Advice for Cathy: Cathy should try to find options that have gone through rigorous third party testing by asking for certificates of attestation, or attempt to self-host where possible (E.g. local copies of tax software versus Internet-based versions), and follow all best practices for two-factor authentication. She should use ad-blocking software, VPNs and logs out of anything sensitive when finished. Ideally she should use a second browser for banking versus Internet activities. She shouldn’t click on links out of emails, shouldn’t install any unknown applications and even shouldn’t download trustworthy applications from untrustworthy websites. If a site is unknown, has a bad or nonexistent BBB rating or seems to not look “right”, she should avoid it. It may have been hacked or taken over. She should also do reputation checking on the site using Web of Trust or similar tools. She should look for the lock in her browser to make sure she is using SSL/TLS. She shouldn’t use public wifi connections. She should install all updates for every software that is already on her computer, uninstall anything she doesn’t need and make sure all services are disabled that aren’t necessary. If anything looks suspicious, she should ask a more technical person for help, and make sure she has backups of everything in the case of compromise.

Dave (The Paranoid Reporter)

  • How Dave thinks about online privacy: “I know the government is capable of just about anything. So I’ll do what I can to protect my sources, insomuch as that it enables me to do my job.”
  • Dave’s perspective: Dave is vaguely aware of some of the programs the various government agencies have in place. He may or may not be aware that other governments are just as interested in his information as the US government. Therefore, he places trust in poor places, mistakenly thinking he is somehow protected by geography or rule of law. He will go out of his way to install encryption software, and possibly some browser security and privacy plugins/add-ons, like ad-blocking software like Disconnect or maybe even something more draconian like NoScript. He’s downloaded Tor once to check it out, and has a PGP/GPG key that no one has ever used posted on his website. He relies heavily on his IT department to secure his computer. But he uses all social media, chats with friends, has an unsecured phone and still uses third party webmail for most things.
  • Advice for Dave: For the most part, Dave is woefully unequipped to handle sensitive information online. His phone(s) are easily tapped, his email is easily subpoenaed and his social media is easily crawled/monitored. Also, his whereabouts are always monitored in several different ways through his phone and social media. He is at risk of putting people’s lives in danger due to how he operates. He needs to have complete isolation and compartmentalization of his two lives. Meaning, his work computer and personal email/social presence should not intertwine. All sensitive stuff should be done through anonymous networks, and using heavily encrypted data that ideally becomes useless after a certain period of time. He should be using burner phones and he should be avoiding any easily discernible patterns when meeting with sources in person or talking to sources over the Internet.

Eve (The Political Dissident)

  • How Eve thinks about online privacy: “What I’m doing is life or death. Everyone wants to know who I am. It’s not paranoia if you’re right.”
  • Eve’s perspective: Eve knows the full breadth of government surveillance from all angles. She’s incredibly tuned in to how the Internet is effectively always spying on her traffic. Her life and the lives of her friends and family around her are at risk because of what she is working on. She cannot rely on anyone she knows to help her because it will put them and ultimately, herself, in the process. She is well read on all topics of Internet security and privacy and she takes absolutely every last precaution to protect her identity.
  • Advice for Eve: Eve needs to got to incredible lengths to use false identities to build up personas so that nothing is ever in her name. There should always be a fall-back secondary persona (also known as a backstop) that will take the fall if her primary persona is ever de-anonymized instead of her actual identity. She should never connect to the Internet from her own house, but rather travel to random destinations and connect into wifi at distances that won’t make it visually obvious. Everything she does should be encrypted. Her operating system should be using plausible deniability (E.g. VeraCrypt) and she should actually have a plausibly deniable reason for it to be enabled. She should use a VPN or hacked machines before surfing through a stripped down version of Tails, running various plugins that ensure that her browser is incapable of doing her harm. That includes plugins like NoScript, Request Policy, HTTPS Everywhere, etc. She should never go to the same wifi connection twice, and should use different modes of transportation whenever possible. She should never use her own credit card, but instead trade in various forms of online crypto-currencies, pre-paid credit cards, physical cash and barter/trade. She should use anonymous remailers and avoid using the same email address more than once. She should regularly destroy all evidence of her actions before returning to any place where she might be recognized. She should avoid wearing recognizable outfits, and cover her face as much as possible without drawing attention. She should never carry a phone, but if she must, it should have the battery removed. Her voice should never be transmitted due to voice-prints and phone-line/background noise forensics. All of her IDs should be put into a Faraday wallet. She should never create any social media accounts under her own name, never upload a picture of herself or surroundings, and never talk to anyone she knows personally while surfing online. She should avoid using any jargon, slang or words that are unique to her location. She should never talk about where she is, where she’s from or where she’s going. She should never tell anyone in real life what she’s doing and she should always have a cover story for every action she takes.

I think one of the biggest problems in our industry is the fact that we tend to give generic one-size-fits-all privacy advice. As you can see above, this sampling of various types of people isn’t perfect but it never could be. People’s backgrounds are so diverse and varied, that it would be impossible to precisely fit any one person into any bucket. Therefore privacy advice must be tailored to people’s ability to understand their interest in protecting themselves and the actual threat they’re facing.

Also, we often are talking at odds with regards to privacy vs security. Even if we didn’t have to worry about the intentions of those giving advice, as discussed in that video, we still can’t rely on the advice itself necessarily. Nor can we rely on the advice being well taken by the person we are giving it to. One party might fully believe that they’re doing all they need to be doing, while they are in fact making it extremely dangerous for those around them who have higher security requirements.

Anything could be a factor in people’s needs/interest/abilities with regards to privacy – age, sex, race, religion, cultural differences, philosophies, their location, which government they agree with, who they’re related to, how much money they have, etc. Who knows how any of those things might impact their privacy concerns and needs? If we give people one-size-fits-all privacy advice it is guaranteed to be a bad fit for most people.

Aviator: Some Answered Questions

We publicly released Aviator on Monday, Oct 21. Since then we’ve received an avalanche of questions, suggestions, and feature requests regarding the browser. The level of positive feedback and support has been overwhelming. Lots of great ideas and comments that will help shape where we go from here. If you have something to share, a question or concern, please contact us at aviator@whitehatsec.com.

Now let’s address some of the most often heard questions so far:

Where’s the source code to Aviator?

WhiteHat Security is still in the very early stages of Aviator’s public release and we are gathering all feedback internally. We’ll be using this feedback to prioritize where our resources will be spent. Deciding whether or not to release the source code is part of these discussions.

Aviator unitizes open source software via Chromium, don’t you have to release the source?

WhiteHat Security respects and appreciates the open source software community. We’ve long supported various open source organizations and projects throughout our history. We also know how important OSS licenses are, so we diligently studied what was required for when Aviator would be publicly available.

Chromium, of which Aviator is derived, contains a wide variety of OSS licenses. As can be seen here using aviator://credits/ in Aviator or chrome://credits/ in Google Chrome. The portions of the code we modified in Aviator are all under BSD, or BSD-like licenses. As such, publishing our changes is, strictly speaking, not a licensing requirement. This is not to say we won’t in the future, just that we’re discussing it internally first. Doing so is a big decision that shouldn’t be taken lightly. Of course, when and/if we make a change to the GPL or similar licensed software in Chromium, we’ll happily publish the updates as required.

When is Aviator going to be available for Windows, Linux, iOS, Android, etc.?

Aviator was originally an internal project designed for WhiteHat Security employees. This served as a great environment to test our theories about how a truly secure and privacy-protecting browser should work. Since WhiteHat is primarily a Mac shop, we built it for OS X. Those outside of WhiteHat wanted to use the same browser that we did, so this week we made Aviator publicly available.

We are still in the very early days of making Aviator available to the public. The feedback so far has been very positive and requests for a Windows, Linux and even open source versions are pouring in, so we are definitely determining where to focus our resources on what should come next, but there is not definite timeframe yet of when other versions will be available.

How long has WhiteHat been working on Aviator?

Browser security has been a subject of personal and professional interest for both myself, and Robert “RSnake” Hansen (Director, Product Management) for years. Both of us have discussed the risks of browser security around the world. A big part of Aviator research was spent creating something to protect WhiteHat employees and the data they are responsible for. Outside of WhiteHat many people ask us what browser we use. Individually our answer has been, “mine.” Now we can be more specific: that browser is Aviator. A browser we feel confident in using not only for our own security and privacy, but one we may confidently recommend to family and friends when asked.

Browsers have pop up blockers to deal with ads. What is different about Aviator’s approach?

Popup blockers used to work wonders, but advertisers switched to sourcing in JavaScript and actually putting content on the page. They no longer have to physically create a new window because they can take over the entire page. Using Aviator, the user’s browser doesn’t even make the connection to an advertising networks’ servers, so obnoxious or potentially dangerous ads simply don’t load.

Why isn’t the Aviator application binary signed?

During the initial phases of development we considered releasing Aviator as a Beta through the Mac Store. Browsers attempt to take advantage of the fastest method of rendering they can. These APIs are sometimes unsupported by the OS and are called “private APIs”. Apple does not support these APIs because they may change and they don’t want to be held accountable for when things break. As a result, while they allow people to use their undocumented and highly speed private APIs, they don’t allow people to distribute applications that use private APIs. We can speculate the reason being that users are likely to think it’s Apple’s fault as opposed to the program when things break. So after about a month of wrestling with it, we decided that for now, we’d avoid using the Mac Store. In the shuffle we didn’t continue signing the binaries as we had been. It was simply an oversight.

Update: November 8, 2013:
Our dev team analyzed the overly-permissive chmod settings that Aviator 1.1 shipped with. We agreed it was overly permissive and have fixed the issue to be more in line with existing browsers to protect users on multi-user systems. Click to read more on our Aviator Browser 1.2 Beta release.

Why is Aviator’s application directory world-writable?

During the development process all of our developers were on dedicated computers, not shared computers. So this was an oversight brought on by the fact that there was no need to hide data from one another and therefore chmod permissions were too lax as source files were being copied and edited. This wouldn’t have been an issue if the permissions had been changed back to their less permissive state, but it was missed. We will get it fixed in an upcoming release.

Update: November 8, 2013:
Our dev team analyzed the overly-permissive chmod settings that Aviator 1.1 shipped with. We agreed it was overly permissive and have fixed the issue to be more in line with existing browsers to protect users on multi-user systems. Click to read more on our Aviator Browser 1.2 Beta release.

Does Aviator support Chrome extensions?

Yes, all Chrome extensions should function under Aviator. If an issue comes up, please report it to aviator@whitehatsec.com so we can investigate.

Wait a minute, first you say, “if you aren’t paying you are the product,” then you offer a free browser?
Fair point. Like we’ve said, Aviator started off as an internal project simply to protect WhiteHat employees and is not an official company “product.” Those outside the company asked if they could use the same browser that we do. Aviator is our answer to that. Since we’re not in the advertising and tracking business, how could we say no? At some point in the future we’ll figure out a way to generate revenue from Aviator, but in the mean time, we’re mostly interested in offering a browser that security and privacy-conscious people want to use.

Have you gotten and feedback from the major browser vendors about Aviator? If so, what has it been?

We have not received any official feedback from any of the major browser vendors, though there has been some feedback from various employees of those vendors shared informally over Twitter. Some feedback has been positive, others negative. In either case, we’re most interested in server the everyday consumer.

Keep the questions and feedback coming and we will continue to endeavor to improve Aviator in ways that will be beneficial to the security community and to the average consumer.

What’s the Difference between Aviator and Chromium / Google Chrome?


It’s a fundamental rule of Web security: a Web browser must be able to defend itself against a hostile website. Presently, in our opinion, the market share leading browsers cannot do this adequately. This is an every day threat to personal security and privacy for the more than one billion people online, which includes us. We’ve long held and shared this point of view at WhiteHat Security. Like any sufficiently large company, we have many internal staff members who aren’t as tech savvy as WhiteHat’s Threat Research Center, so we had the same kind of security problem that the rest of the industry had: we had to rely on educating our users, because no browser on the market was suitable for our security needs. But education is a flawed approach – there are always new users and new security guidelines. So instead of engaging in a lengthy educational campaign, we began designing an internal browser that would be secure and privacy-protecting enough for our own users — by default. Over the years a great many people — friends, family members, and colleagues alike — have asked us what browser we recommend, even asked us what browser their children should use. Aviator became our answer.

Why Aviator:

The attacks a website can generate against a visiting browser are diverse and complex, but can be broadly categorized in two types. The first type of attack is designed to escape the confines of the browser walls and infect the desktop with malware. Today’s top tier browser defenses include software security in the browser core, an accompanying sandbox, URL blacklists, silent-updates, and plug-in click-to-play. Well-known browser vendors have done a great job in this regard and should be commended. No one wins when users desktops become part of a botnet.

Unfortunately, the second type of browser attack has been left largely undefended. These attacks are pernicious and carry out their exploits within the browser walls. They typically don’t implant malware, but they are indeed hazardous to online security and privacy. I’ve previously written up a lengthy 8-part blog post series on the subject documenting the problems. For a variety of reasons, these issues have not been addressed by the leading browser vendors. Rather than continue asking for updates that would likely never come, we decided we could do it ourselves.

To create Aviator we leveraged open source Chromium, the same browser core used by Google Chrome. Then, because the BSD license of Chromium allows us, we made many very particular changes to the code and configuration to enhance security and privacy. We named our product Aviator. Many people are eager to learn what exactly the differences are, so let’s go over them.


  1. Protected Mode (Incognito Mode) / Not Protected Mode:
    TL;DR All Web history, cache, cookies, auto-complete, and local storage data is deleted after restart.
    Most people are unaware that there are 12 or more locations that websites may store cookie and cookie-like data in a browser. Cookies are typically used to track your surfing habits from one website to the next, but they also expose your online activity to nosy people with access to your computer. Protected Mode purges these storage areas automatically with each browser restart. While other browsers have this feature or something similar, it is not enabled by default, which can make it a chore to use. Aviator launches directly into Protected Mode by default and clearly indicates the mode of the current window. The security / privacy side effect of Protected Mode also helps protect against browser auto-complete hacking, login detection, and deanonymization via clickjacking by reducing the amount of session states you have open – due to an intentional lack of persistence in the browser over different sessions.
  2. Connection Control: 
    TL;DR Rules for controlling the connections made by Aviator. By default, Aviator blocks Intranet IP-addresses (RFC1918).
    When you visit a website, it can instruct your browser to make potentially dangerous connections to internal IP addresses on your network — IP addresses that could not otherwise be connected to from the outside (NAT). Exploitation may lead to simple reconnaissance of internet networks, or it may permanently compromise your network by overwriting the firmware on the router. Without installing special third-party software, it’s impossible to block any bit of Web code from carrying out browser-based intranet hacking. If Aviator happens to be blocking something you want to be able to get to, Connection Control allows the user to create custom rules — or temporarily use another browser.
  3. Disconnect bundled (Disconnect.me): 
    TL;DR Blocks ads and 3rd-party trackers.

    Essentially every ad on every website your browser encounters is tracking you, storing bits of information about where you go and what you do. These ads, along with invisible 3rd-party trackers, also often carry malware designed to exploit your browser when you load a page, or to try to trick you into installing something should you choose to click on it. Since ads can be authored by anyone, including attackers, both ads and trackers may also harness your browser to hack other systems, hack your intranet, incriminate you, etc. Then of course the visuals in the ads themselves are often distasteful, offensive, and inappropriate, especially for children. To help protect against tracking, login detection and deanonymization, auto cross-site scripting, drive-by-downloads, and evil cross-site request forgery delivered through malicious ads, we bundled in the Disconnect extension, which is specifically designed to block ads and trackers. According to the Chrome web store, over 400,000 people are already using Disconnect to protect their privacy. Whether you use Aviator or not, we recommend that you use Disconnect too (Chrome / Firefox supported). We understand many publishers depend on advertising to fund the content. They also must understand that many who use ad blocking software aren’t necessarily anti-advertising, but more pro security and privacy. Ads are dangerous. Publishers should simply ask visitors to enable ads on the website to support the content they want to see, which Disconnect’s icon makes it easy to do with a couple of mouse-clicks. This puts the power and the choice into the hands of the user, which is where we believe it should be.
  4. Block 3rd-party Cookies: 
    TL;DR Default configuration update. 

    While it’s very nice that cookies, including 3rd-party cookies, are deleted when the browser is closed, it’s even better when 3rd-party cookies are not allowed in the first place. Blocking 3rd-party cookies helps protect against tracking, login detection, and deanonymization during the current browser session.
  5. DuckDuckGo replaces Google search: 
    TL;DR Privacy enhanced replacement for the default search engine. 

    It is well-known that Google search makes the company billions of dollars annually via user advertising and user tracking / profiling. DuckDuckGo promises exactly the opposite, “Search anonymously. Find instantly.” We felt that that was a much better default option. Of course if you prefer another search engine (including Google), you are free to change the setting.
  6. Limit Referer Leaks: 
    TL;DR Referers no longer leak cross-domain, but are only sent same-domain by default. 

    When clicking from one link to the next, browsers will tell the destination website where the click came from via the Referer header (intentionally misspelled). Doing so could possibly leak sensitive information such as the search keywords used, internal IPs/hostnames, session tokens, etc. These leaks are often caused by the referring URL and offer little, if any, benefit to the user. Aviator therefore only sends these headers within the same domain.
  7. Plug-Ins Click-to-Play: 
    TL;DR Default configuration update enabled by default. 

    Plug-ins (E.g. Flash and Java) are a source for tracking, malware exploitation, and general annoyance. Plug-ins often keep their own storage for cookie-like data, which isn’t easy to delete, especially from within the browser. Plug-ins are also a huge attack vector for malware infection. Your browser might be secure, but the plug-ins are not and one must update constantly. Then of course all those annoying sounds and visuals made by plug-ins which are difficult to identify and block once they load. So, we blocked them all by default. When you want to run a plug-in, say on YouTube, just one-click on the puzzle piece. If you want a website to always load the plug-ins, that’s a configuration change as well. “Always allow plug-ins on…”
  8. Limit data leakage to Google: 
    TL;DR Default configuration update.

    In Aviator we’ve disabled “Use a web service to help resolve navigation errors” and “Use a prediction service to help complete searches and URLs typed in the address bar” by default. We also removed all options to sync / login to Google, and the tracking traffic sent to Google upon Chromium installation. For many of the same reasons that we have defaulted to DuckDuckGo as a search engine, we have limited what is sent in the browser to Google to protect your privacy. If you chose to use Google services, that is your choice. If you chose not to though, it can be difficult in some browsers. Again, our mantra is choice – and this gives you the choice.
  9. Do Not Track: 
    TL;DR Default configuration update.

    Enabled by default. While we prefer “Can-Not-Track” to “Do-Not-Track”, we figure it was safe enough to enable the “Do Not Track” signal by default in the event it gains traction.

We so far have appreciated the response to WhiteHat Aviator and welcome additional questions and feedback. Our goal is to continue to make this a better and more secure browser option for consumers. Please continue to spread the word and share your thoughts with us. Please download it and give it a test run. Let us know what you think! Click here to learn more about the Aviator browser.

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.

Browser Wars to Browser Foes – MS13-069

Microsoft has just published a high-level threat 0-day vulnerability for all versions of Internet Explorer 6.0 and greater and affecting all operating system higher then Windows XP service pack 3. This vulnerability uses a corrupted memory object to remotely execute code that runs on the victim’s machine with the current users privileges. More information about how the vulnerability is exploited can be found at Microsoft here.

All that is required from the victim is to click a malicious link hosted by the attacker to become exploited; this in turn runs the attacker’s executing code and gives the attacker access to the machine.

This attack can still be sent through social media sites, chat messages, email, and malicious websites. As a precaution it may be wise to change the default browser to something other than Internet Explorer until the affected machine is patched. The instructions from Microsoft to change the default browser here Windows 7 And Windows XP.

The scope of users affected is very high, since the Microsoft Windows Operating Systems and Internet Explorer have been the de facto standard for more then a decade. Since Internet Explorer ships as the only browser in Windows it’s very easy not to bother installing a different browser. Internet Explorer users still make up roughly a third of browser usage average, when comparing Internet Explorer to Chrome and Firefox.

Internet Explorer on Windows Servers above 2003 are at a lower risk because they run in a default enhanced security configuration, and it’s strongly discouraged in security to be browsing the internet from Windows server or any server for that matter.


Patching can be a hectic task for admins that are using Internet Explorer dependently, but should be done immediately to prevent exposure.

The official instructions from Microsoft Suggested Actions:

General Information for all users

Enhanced Mitigation Experience ToolKit

Here are some statistical results showing the popularity/average browser and operating usage across the world:






20,000. That’s the number of websites we’ve assessed for vulnerabilities with WhiteHat Sentinel. Just saying that number alone really doesn’t do it any justice though. The milestone doesn’t capture the gravity and importance of the accomplishment, nor does it fully articulate everything that goes into that number, and what it took to get here. As I reflect on 20,000 websites, I think back to the very early days when so many people told us our model could never work, that we’d never see 1,000 sites, let alone 20x that number. (By the way, I remember their names distinctly ;).) In fairness, what they couldn’t fully appreciate then is “Web security” in terms of what it really takes to scale, which means they truly didn’t understand “Web security.”

When WhiteHat Security first started back in late 2001, consultants dominated the vulnerability assessment space. If a website was [legally] tested for vulnerabilities, it was done by an independent third-party. A consultant would spend roughly a week per website, scanning, prodding around, modifying cookies, URLs and hidden form fields, and then finally deliver a stylized PDF report documenting their findings (aka “the annual assessment”). A fully billed consultant might be able to comprehensively test 40 individual websites per year, and the largest firms would maybe have many as 50 consultants. So collectively, the entire company could only get to about 2,000 websites annually. This is FAR shy of just the 1.8 million SSL-serving sites on the Web. This exposed an unacceptable limitation of their business model.

WhiteHat, at the time of this writing, handles 10x the workload of any consulting firm we’re aware of, and we’re nowhere near capacity. Not only that, WhiteHat Sentinel is assessing these 20,000 websites on a roughly weekly basis, not just once a year! That’s orders of magnitude more security value delivered than what the one-time assessments can possibly provide. Remember, the Web is a REALLY big place, like 700 million websites big in total. And that right there is what Web security is all about, scale. If any solution is unable to scale, it’s not a Web security solution. It’s a one-off. It might be a perfectly acceptable one-off, but a one-off none-the-less.

Achieving scalability in Web security must take into account the holy trinity, a symbiotic combination of People, Process, and Technology – in that order. No [scalable] Web security solution I’m aware of can exist without all three. Not developer training, not threat modeling, not security in QA, not Web application firewalls, not centralized security controls, and certainly not vulnerability assessment. Nothing. No technological innovation can replace the need for the other two factors. The best we can expect of technology is to increase the efficiency of people and processes. We’ve understood this at WhiteHat Security since day one, and it’s one of the biggest reasons WhiteHat Security continues to grow and be successful where many others have gone by the wayside.

Over the years, while the vulnerabilities themselves have not really changed much, Web security culture definitely has. As the industry matures and grows, and awareness builds, we see the average level of Web security competency decrease! This is something to be expected. The industry is no longer dominated by a small circle of “elites.” Today, most in this field are beginners, with 0 – 3 years of work experience, and this is a very good sign.

That said, there is still a huge skill and talent debt everyone must be mindful of. So the question is: in the labor force ecosystem, who is in the best position to hire, train, and retain Web security talent – particularly the Breaker (vulnerability finders) variety – security vendors or enterprises? Since vulnerability assessment is not and should not be in most enterprises’ core competency, AND the market is highly competitive for talent, we believe the clear answer is the former. This is why we’ve invested so greatly in our Threat Research Center (TRC) – our very own professional Web hacker army.

We started building our TRC more than a decade ago, recruiting and training some of the best and brightest minds, many of whom have now joined the ranks of the Web security elite. We pride ourselves on offering our customers not only a very powerful and scalable solution, but also an “army of hackers” – more than 100 strong and growing – that is at the ready, 24×7, to hack them first. “Hack Yourself First” is a motto that we share proudly, so our customers can be made aware of the vulnerabilities that exist on their sites and can fix them before the bad guys exploit them.

That is why crossing the threshold of 20,000 websites under management is so impressive. We have the opportunity to assess all these websites in production – as they are constantly updating and changing – on a continuous basis. This arms our team of security researchers with the latest vulnerability data for testing and measuring and ultimately protecting our customers.

Other vendors could spend millions of dollars building the next great technology over the next 18 months, but they cannot build an army of hackers in 18 months; it just cannot be done. Our research and development department is constantly working on ways to improve our methods of finding vulnerabilities, whether with our scanner or by understanding business logic vulnerabilities. They’re also constantly updated with new 0-days and other vulnerabilities that we try to incorporate into our testing. These are skills that take time to cultivate and strengthen and we have taken years to do just that.

So, I have to wonder: what will 200,000 websites under management look like? It’s hard to know, really. We had no idea 10+ years ago what getting to 20,000 would look like, and we certainly never would have guessed that it would mean we would be processing more than 7TB of data over millions of dollars of infrastructure per week. That said, given the speed at which the Internet is growing and the speed at which we are growing with it, we could reach 200,000 sites in the next 18 months with. And that is a very exciting possibility.

WhiteHat to Host Webinar—Beyond the Breach: Insights Into the Hidden Cost of a Web Security Breach

On Wednesday, September 12, at 11:00 AM PT, join WhiteHat Security’s Gillis Jones as he shares his research into the real financial implications of a website hack. On his journey through the business-side of Web security, Gillis uncovered bleak realities including discrepancies in accounting practices; a lack of consistent disclosure policies to address Web hacks; and gross under-reporting of financial losses once a breach is disclosed.

Gillis will also share cost-analysis formulas he developed while researching website breaches, as well as the specific costs of a breach in each of these areas:

  1. Personnel
  2. Technical, Infrastructure & Immediate Losses of Income
  3. Compliance
  4. Damaged, Destroyed or Stolen Hardware
  5. Customer Turnover & Loss of Customer Trust
  6. “Customer Management” After the Breach
  7. Fines & Lawsuits
  8. Public Relations “Damage Control”

To register for the webinar, please visit this link: https://reg.whitehatsec.com/forms/WEBINARbreach0912

Session Cookie Secure Flag Java

What is it and why should I care?
Session cookies (or, to Java folks, the cookie containing the JSESSIONID) are the cookies used to perform session management for Web applications. These cookies hold the reference to the session identifier for a given user, and the same identifier is maintained server-side along with any session-scoped data related to that session id. Because cookies are transmitted on every request, they are the most common mechanism used for session management in Web applications.

The secure flag is an additional flag that you can set on a cookie to instruct the browser to send this cookie ONLY when on encrypted HTTPS transmissions (i.e. NEVER send the cookie on unencrypted HTTP transmissions). This ensures that your session cookie is not visible to an attacker in, for instance, a man-in-the-middle (MITM) attack. While a secure flag is not the complete solution to secure session management, it is an important step in providing the security required.

What should I do about it?
The resolution here is quite simple. You must add the secure flag to your session cookie (and preferably to all cookies, because any requests to your site should be HTTPS, if possible).

Here’s an example of how a session cookie might look without the secure flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;

And now, how the same session cookie would look with the secure flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; secure;

Not much to it. Obviously, you can do this manually, but if you’re working in a Java Servlet 3.0 or newer environment, a simple configuration setting in the web.xml will take care of this for you. You should add the snippet below to your web.xml.


As you can see, resolving this issue is quite simple. It should be on everyone’s //TODO list.




Session Fixation Prevention in Java

What is it and why should I care?
Session fixation, by most definitions, is a subclass of session hijacking. The most common basic flow is:

Step 1. Attacker gets a valid session ID from an application
Step 2. Attacker forces the victim to use that same session ID
Step 3. Attacker now knows the session ID that the victim is using and can gain access to the victim’s account

Step 2, which requires forcing the session ID on the victim, is the only real work the attacker needs to do. And even this action on the attacker’s part is often performed by simply sending the victim a link to a website with the session ID attached to the URL.

Obviously, one user being able to take over another user’s account is a serious issue, so…

What should I do about it?
Fortunately, resolving session fixation is usually fairly simple. The basic advice is:

Invalidate the user session once a successful login has occurred.

The usual basic flow to handle session fixation prevention looks like:

1. User enters correct credentials
2. System successfully authenticates user
3. Any existing session information that needs to be retained is moved to temporary location
4. Session is invalidated (HttpSession#invalidate())
5. New session is created (new session ID)
6. Any temporary data is restored to new session
7. User goes to successful login landing page using new session ID

A useful snippet of code is available from the ESAPI project that shows how to change the session identifier:

http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/reference/DefaultHTTPUtilities.java (look at the changeSessionIdentifier method)

There are other activities that you also can perform to provide additional assurance against session fixation. A number are listed below:

1. Check for session fixation if a user tries to login using a session ID that has been specifically invalidated (requires maintaining this list in some type of LRU cache)

2. Check for session fixation if a user tries to use an existing session ID already in use from another IP address (requires maintaining this data in some type of map)

3. If you notice these types of obvious malicious behavior, consider using something like AppSensor to protect your app, and to be aware of the attack

As you can see, session fixation is a serious issue, but has a pretty simple solution. Your best bet if possible is to include an appropriate solution in some “enterprise” framework (like ESAPI) so this solution applies evenly to all your applications.