Google Glass At Your Own Peril

I made this list to help people understand why surveillance at all times is not acceptable. There are plenty of times throughout the day that it’s just totally unacceptable, rude or otherwise dangerous to be photographing anything with a device on your head. Besides looking idiotic, Google Glass solves a problem almost no one has, and ultimately introduces a lot of additional issues in the process of just making the person wearing it look dorky.

Here is a list of some of the places and situations in which it is inappropriate to wear Google Glass. Places/scenarios where it will be assumed you are a pervert, or an idiot and are likely to get yourself beaten up, arrested, fired, shunned, or have your Google Glass (or yourself) broken, etc:

  • In the shower (I’m looking at you Scoble), especially in a communal one at a campground, prison, etc.
  • At any point where a police officer may decide that it is illegal – which, honestly, seems like pretty much any time at all these days.
  • In bed with someone you just met, unless that’s their thing
  • In a confessional, hearing a confession
  • At a urinal, especially a trough style urinal at a football game
  • At the movie theater
  • At a concert
  • Just checking in to make sure everything is okay during your daughter’s slumber party
  • While buying condoms, sanitary pads, or anything else, where it is assumed one wouldn’t want photographic evidence unless you are a pervert
  • While committing any crime at all, even J-walking, or speeding
  • In the changing room
  • At a strip club or burlesque show
  • While scuba diving
  • While playing or working on a casino floor
  • While operating heavy machinery – automobiles (especially during any sort of Irish road racing), airplanes, front end loaders, excavators, etc.
  • At bars
  • Courtrooms (especially federal) unless specifically authorized to do so
  • While taking a test of just about any kind
  • In any location at any time in Alabama, Arkansas, California, Delaware, Georgia, Hawaii, Kansas, Maine, Michigan, Minnesota, New Hampshire, South Dakota and Utah unless people give concent and/or recognize that they are under surveillance, due to covert surveillance laws
  • During takeoff or landing
  • The sauna
  • Clothing optional beaches/resorts
  • During many televised sporting events
  • In many Museums
  • At the United Nations
  • At most hospitals in the United States (especially while giving an OBGYN checkup, a venereologist exam or a proctology checkup)
  • While doing interviews for plastic surgery
  • During a psychiatric therapy session
  • While selling women’s shoes
  • While giving pedicures
  • Pretty much any profession involving children
  • While performing any job with top secret clearance
  • During an MMA fight or while boxing
  • While giving a massage
  • While in a locker room

Oh yeah, and while at my house.

HackerKombat II: Capturing Flags, Pursuing the Trophy

Years ago, a small group of 5-6 of us at WhiteHat held impromptu hacking contests – usually over lunch or during breaks in the day – in which we would race each other to be the quickest to discover vulnerabilities in real live customer websites (banks, retailers, social networks, whatever). No website survived longer than maybe 20 minutes. These contests were a nice break in the day and they allowed us to share (or perhaps show off) our ability to break into things quickly. The activity usually provided comic relief, moments of humility, :) and most importantly they opened opportunities to learn from each other.

We have scores of extremely talented and creative minds working at WhiteHat and these activities were some of the earliest testaments to that. Our corporate culture is eager to break what was previously thought of as “secure,” often just for the fun and challenge. Today, WhiteHat has more than 100 application security specialists in our Threat Research Center (TRC) alone – essentially our own Web hacker army. With so many people now, our contests were forced to evolve, to grow and to mature. We now organize a formal internal activity called HackerKombat.

HackerKombat is a WhiteHat employee only event, a game we hold every couple of months, a late-night battle between some of the best “breakers” in the business. HackerKombat is our version of a “Hackathon,” which companies like Facebook and others host as a means to challenge their engineers to build cool new apps, new features, etc.

BJSgv2mCYAI1Lft

HackerKombat challenges our team to break things — to break websites and web applications, to test our hacker skills in a pizza and alcohol infused environment. The goals are to have some fun in a way that only hackers could appreciate, but also to encourage teamwork and thinking outside the box, and to expose areas of knowledge where we are weak.

Unlike years past, the websites and applications we target are staged – no more hacking live customer sites! We have learned that while the average business-driving website might withstand the malicious traffic of a few hackers targeting it, a dozen or more could easily cause downtime. We certainly can’t have that and you’ll see how easy that can be later in this post.

The HackerKombat challenges are designed by Kyle Osborn (@theKos), a WhiteHat TRC alumnus, accomplished security researcher, and frequent conference speaker, who is currently employed by Tesla Motors. Challenges are also developed by current TRC members, but doing so disqualifies them from actually playing — gotta keep things fair as we can. This isn’t much in way of rules for HackerKombat. I mean, are hackers expected to follow them anyway? ;)

Today, finding a single vulnerability is nowhere near enough to claim victory. HackerKombat is a series of challenges that are very difficult and require a wide variety of technical ability. Defeating every challenge requires a great team, and great teamwork. No way can a single person, even the best and brightest among us, get through every challenge and expect to have any chance of winning. Past events have shown there is strength in numbers – so we also had to cap the team size at 5-6 to keep things even.

A few weeks ago we hosted the second formal event – HackerKombat II. Teams were decided by draft, for a total of six teams with five combatants each spanning our Santa Clara headquarters as well as in our TRC location in Houston. In the hours leading up to HK II the trash talking was constant and searing. There was even an office pool posted and people were placing bets on the winning team! The biggest prize of all: our custom trophy.

trophy

The exact moment the game began the trash-talking ceased, poker faces were set – chatter became eerily quiet. If you wanted to win, and everyone did, every second and key press mattered. If someone was active on Jabber (chat client), you knew they were stuck. ;)

Each team’s approach to the 10 challenges was probably different. For my team – “Zerg” – we assessed each by triaging them first: determining what skill sets it would take and assigning those tasks to the right team member to tackle.  The first 4 challenges or so were completed fairly easily within the first hour. The next 2-3 challenges we had to pair up to defeat them. Writing some code was necessary. Another hour gone. Then things got hard, really hard, and every team’s progress slowed way down.

Some of the challenges posed interesting hurdles that the designers did not anticipate. For instance, one challenge required teams to run DirBuster, which brute-forces web requests looking for a hidden web directory. The problem, however, is that a single Apache web server is not used to handling a dozen people all doing the same thing and sending thousands of requests per second. The challenge server died. Remember how I mentioned downtime? Apparently, speed in capturing that particular flag was the winning skill because no other team could get in to tackle it! Argh!

For the most difficult challenges, 9 and 10, Zerg had to gel together as a team to try to figure out the best approach and make incremental gains. I’m clearly very weak in my steganography skills. Terribly frustrating at a time we were so close to victory, but couldn’t seal the deal. An hour of study beforehand would have been enough.

In the end, the winning team –  “Terrans” from Santa Clara – prevailed by completing all 10 challenges and capturing all 12 flags in a time of 4h and 46min, barely edging out the team in Houston – “PurpleStuff” – which came in second at 4h and 49min. Yes, when it was all said and done, 3 minutes separated the leaders. Imagine that!

In another moment of humility, Robert Hansen (@RSnake), another “great” in the industry, can at least claim he beat me and came in second. :) I’m not exactly certain even now where my team placed, probably around 4th, as every team managed to capture at least 10 flags before the Terrans claimed ultimate victory.  I congratulate Rob, Nick, Dustin, Jon Paul and Ron for their win.

All in all, HK II was fun for all involved and everyone learned a great deal. We learned new techniques that the bad guys can use in the wild, and we learned where each of us individually needs to brush up on our studies. HK II’s success makes a founder very proud. I’m sure there are few, if any, companies that can pull off such an event.

 I look forward to HK III. I want that trophy!

[Check out photos from JerCon and HK II here.]

Web Storage Security

The web waits for no one, not even W3C.

While the HTML5 specification isn’t finalized, and HTML5 Storage has even been broken out into its own Web Storage Specification, which is even further from being finalized, code continues to move to the client and more developers are (mis-) using the next generation features that are already available in the browsers. Engineers and researchers in the WhiteHat Security Threat Research Center are in a unique position to know “where there is code, there are vulnerabilities,” and JavaScript is certainly no exception.

Over the past few months, the Threat Research Center has implemented new checks into WhiteHat Sentinel to better identify and analyze the usage of Web Storage and its potential security impact.  During the course of this research, I analyzed over 600 applications that made at least one call to Web Storage — “getItem” or “setItem”.  The preliminary results may surprise you. They sure surprised me.

Before I jump into the vulnerability discussion, a brief word about some of the so-called “security advice” concerning HTML5 APIs and specifically Web Storage. I’ll be the first to admit that before this project I’d never used the Web Storage APIs; this was a from-scratch effort. Like any good developer (or hacker) learning a new technology, I googled “Web Storage Security”, “localStorage Security”, and “HTML5 Storage Security”. The results were somewhat discouraging.  I couldn’t find a single vulnerable code example and most security commentaries boiled down to either “there is no major risk” or “if developers use Web Storage properly there is no risk.”

The argument is that because stored values aren’t transmitted over HTTP we actually have a more secure option for storing data that is only needed on the client. In my opinion, this is just flat out wrong.  Arguing that “if developers use it correctly there is no risk” is like saying “if PHP developers use $_GET correctly there won’t be any problems.” We all know how that turns out.

So I knew I needed to go to the source. Section 7 of the Web Storage Specification is titled “Security”; certainly we can get some good advice here. Honestly though, I found section 7.1’s warning about DNS spoofing attacks and 7.2’s warning about cross-directory attacks to be a bit hollow. I’m not saying these attacks don’t exist, but certainly we can give some better advice than “Use TLS” and “Don’t implement on shared domains”. Section 7.3, on implementation risks, appears to be entirely targeted at browser makers. If developers can’t go to W3C for advice on how and how not to use Web Storage securely, then where can they go? It looks like we are back to Stack Overflow and random blog posts. With that being the state of security advice on Web Storage, I figured I’d throw my hat in the ring.

Examples of Vulnerability:

Evil Roommate / Public Computer

Firefox’s about:home page is vulnerable to DOM (document object model) XSS via localStorage injection through the snippets functionality. While I can’t send you a link or build a malicious website to exploit this issue I’m willing to bet that thousands of people use FireFox on a shared or public computer every day. It sure would be nice to be able to log all of those keystrokes even after the browser is closed and private data has been cleared.

Screen Shot 2013-05-18 at 5.12.34 AM

Just sit down and run a weaponized version of the following bookmarklet:

javascript:window.localStorage.setItem(‘snippets’,'<iframe src=”https://www.whitehatsec.com” onload=”prompt()” style=”width:100%;height:100%;z-index:9999999;position:absolute;left:0px;top:0px;”/>’);

When contacted about the above issue via email the Mozilla security team advised that they are migrating the functionality off of localStorage for reasons other than security. Even so, I’ll be keeping my Firefox usage to my own computer that is always locked whenever I am not using it. At least until this functionality is patched.

DOMXSS –> localStorage XSS –> The persistent vector your sever will never see.

Vulnerable Code:

<script language=”JavaScript”>

var Id = getPramValue(“id”);

var persistId = localStorage.getItem(‘id’);

if( isValid(Id) ){

document.write(‘<a href=”http://www.example.com/?s=13436&id=’+ Id” id=”store_locator”>’);

document.write(‘<div>Find Store</div>’);

document.write(‘</a>’);

} else if( localStorage && isValid(persistId)) {

document.write(‘<a href=”http://www.example.com/?s=13436&id=’+ persistId” id=”store_locator”>’);

document.write(‘<div>Find Store</div>’);

document.write(‘</a>’);

}else {

document.write(‘<a href=”http://www.example.com/locator” class=”scroll linktomap” id=”store_locator”>’);

document.write(‘<div>Find Store</div>’);

document.write(‘</a>’);

}

</script>

Proof of Concept:

<a href=”http://www.example.com/#?id=’”><img/src=”x”onerror=eval(String.fromCharCode(119,105,110,100,111,119,46,108,111,99,97,108,83,116,111,114,97,103,101,46,115,101,116,73,116,101,109,40,39,105,100,39,44,39,34,62,60,105,109,103,47,115,114,99,61,92,34,120,92,34,111,110,101,114,114,111,114,61,97,108,101,114,116,40,49,41,62,39,41))>

The String.fromCharCode here just makes it easier to insert the needed injection into localStorage without excessive quote escaping. Here is what it decodes to:

window.localStorage.setItem(‘id’,'”><img/src=\”x\”onerror=alert(1)>’)

The Always and Never of Web Storage

ALWAYS:

Always  validate, encode, and escape user input before placing into localStorage or sessionStorage

Always  validate, encode, and escape data read from localStorage or sessionStorage before writing onto the page (DOM).

Always  treat all data read from localStorage or sessionStorage as untrusted user input.

NEVER:

Never store sensitive data using Web Storage: Web Storage is not secure storage. It is not “more secure” than cookies because it isn’t transmitted over the wire. It is not encrypted. There is no Secure or HTTP only flag so this is not a place to keep session or other security tokens.

Never use Web Storage data for access control decisions or trust the serialized objects you store here for other critical business logic. A malicious user is free to modify their localStorage and sessionStorage values at any time, treat all Web Storage data as untrusted.

Never write stored data to the page (DOM) with a vulnerable JavaScript or library sink.  Here is the best list of JavaScript sinks that I am aware of on the web right now.  While it is true that a perfect storm of tainted data flow must exist for a remote exploit that relies 100% on Web Storage you must consider two alternate scenarios. First, consider the evil roommate, unlocked, unattended, or public computer scenario in which a malicious user has temporary physical access to your user’s web browser. The computer’s owner may have disallowed a low privileged user from installing malicious add-on but I’ve never seen a user prevented from making a bookmark. Second, don’t ignore the possibility of improper Web Storage usage allowing escalation of another vulnerability such as reflective cross-site scripting into persistent cross-site scripting.

Interview With A Blackhat (Part 3)

[Please note that this series of posts discusses criminal activities from the perspective of the criminal. This may be distressing to some readers; please exercise caution.]

This is part 3/3 of my interview with “Adam” – a blackhat (hacker engaging in criminal activity) who has decided to go legit. During this part of the interview we discuss, among other things, the rationale behind Adam’s desire to go legit, how he and others in the community see “whitehats” (legitimate hackers in general – not a specific reference to WhiteHat Security!) and why the punishment doesn’t appear to be deterring the crimes. If you missed the previous parts you can see them here: part 1 and part 2.

Q: How do you perceive the risk involved in going to jail? Why isn’t the punishment deterring the crime?

A: I’ve thought about it, for about 10. Suppose it could be a bad thing. Wonder if the staff do banking in jail? Hmmm. Also, people ask, ‘doesn’t the jail term scare you? Losing the money?’ If the Feds can find 100 dollars I’ll give them all of it. You see, working in the underground everyone has hundreds of names, passports, etc. If the Feds can find one they can have them all. You use fake identities and then you give the money to a cafe you own then they feed to through into a bank. It all looks legit. Doesn’t have to be a cafe — can be nightclubs etc. Or you can provide a service to a legit business and they feed it through.

It’s super hard to gather evidence for the crime, and even so the money is impossible to find. Ten or eleven mil over 10-13 years for a 10-15 year sentence. I can’t really say what it’d be like without freedom as I’ve always had it so I can’t imagine losing it.

Q: What’s the difference, in your opinion, between a talented blackhat and a script kiddy? How would you rank yourself?

A: Everyone starts somewhere it just depends on if you move on. A script kiddy will never get on the legit underground as the elders make anyone who even tries to get into the ug develop botnets, viruses, worms etc. — like a right of passage. Skids are used as the door matt. Am I a skid? I hope not, would have been a waste of time making the first automated server infection botnet. Lol.

Q: How many hours a week do you think you dedicate to your blackhat activities?

A: When I fancy a new venture – e.g. a new 0-day is released — anything up to two days non stop. 8-9 hours sleep then two days again. But on average about 8-10 hours a day. It is a job after all. :)

Q: What were the job prospects in your area for someone with your skill sets and background prior to going into criminal activity? How much money could you make if you hadn’t gone into criminal activity?

A: I got offered a job to work as a cyber security specialist for a rather large company. For the money? I’d earn in a year at that job what I would in about a fortnight black hatting.

Q: What do you think the biggest misperceptions are of the blackhat world by the security community?

A: That we’re all tied to the mafia, we want the world to burn and we are all Russian. For example 90% of the carders I know donate huge amounts to charities (80-90k a year) I know of carders who went to Africa and bought thousands of mosquito nets. Just because we found a way to make super fast money doesn’t mean we want the world to go bankrupt, people to die, people to go homeless. It’s a lot like business. If someone is dying of cancer and you hold the cure I bet you’d make them pay — it’s the same mentality, exploiting someone’s case for my own good. We are good people.

Q: What made you decide to want to go legitimate?

A: They’re only so many credit cards in the world. :( Also, I suppose getting paid to find 0-days, hack systems and do it legally is more appealing.

Q: How much stress do you think being a Blackhat has been on you, worrying about being caught?

A: Being caught has always been a concern, if I wasn’t concerned about being caught I’d be stupid. Sometimes I go days and nights with no sleep wondering when I’d get raided. Sometimes I took it to the extreme and slept during the day and hacked on at night. I felt more comfortable knowing if I was to be raided at least I’d be awake.

Q: What do you think other blackhat friends will say once they find out you have gone legit? Is there any cause for concern or do you believe they’ll let you do what you want?

A: No I think they’ll be fine with my decision. I asked several of the guys I’m close to and all seemed ok with the prospect of me turning white [legit]. There really isn’t a hatred of whitehats from the blackhats. In fact, quite the opposite. If we stayed with viruses from 2000 because we were never challenged we’d be so out-dated and not capable of making a tenth of the amount of money we make currently. Most blackhats love whitehats for that reason.

Q: What do you plan to do now that you are legitimate?

A: I’ve had and have many ideas on things I’d like to do. I’d like to do some research into the time it takes from when blackhats find 0-days to [when] whitehats find them. That’s always being an interest to me. I’m also planning on releasing the exploits + patches I commonly used and further develop 0-Day research to compete with the blackhats.

Q: Do you worry that your past will come back to haunt you in the future?

A: It’s a worry, if someone can find the evidence; if not, it’s just an advantage I posses :)

Interview With A Blackhat (Part 2)

[Please note that this series of posts discusses criminal activities from the perspective of the criminal. This may be distressing to some readers; please exercise caution.]

This is part 2/3 of my interview with “Adam” – a blackhat who has decided to go legit. During this part of the interview we discuss, among other things, some of the specifics on why defenses aren’t working, things that do help make a dent, and how the underground is dominated by organized crime. If you missed the previous part you can can see it here: part 1.

Q: Is there something that websites do to try to defend themselves from guys like you that they always get wrong?

A: I could re-write Shakespeare here. I’ll pick three things.

1. Hire stupid admins who have never been a bad guy, just fed with a silver spoon all their lives and went to Uni on mummy and daddies money. If I were the CEO of a company I’d much rather employ someone who has a criminal record for hacking than a Uni graduate any day of the week. The guy who has the criminal record has gained the knowledge of how a bad guy would go about getting in. and not just what a text book says.

2. They allow untrained, young, dumb, Saturday workers to operate the phones.

3. Companies don’t purchase DDoS protection. Cloudflare for example offers incredibly strong DDoS protection for 200 dollars a month (also its harder to jack a cloudflare domain). If I extort you for 200-1000 dollars for 1 day why not make yourself immune for the minimal fee?

Q: What types of security devices/services/techniques legitimately make your life harder as a blackhat? Any that you think are a complete waste of money?

A: Hmmmm, DDoS protection is a serious knock back, although as many groups have proven before it’s easy to bypass – e.g. cloudflare resolver before they changed the protection method (almost bypassable lol). Things that are a waste of money… Hmm, anti-virus is completely useless — yes it may protect you from skids using non-fud files but that’s it. Every botnet that gets sold comes fud as default. People do it for free, it’s that easy. Anti-spam software (except CAPTCHAs, although that has a reputation for bad customer reviews).

The thing you have to remember is the black hat world is 10 steps ahead of what’s commercially available. When a 0-day is released blackhats have used it for months. Two-step authorization is a pain and sometimes yes, it does stop a hack completely especially in social engineering, but just as Cosmo (a 15 year old UGNazi member) proved, it’s bypassable. It’s like buying a game. When it’s first released it gets patched a lot, it’ll take a long time before it makes any sort of major impact.

Q: Which types of browsers tend to be the most vulnerable? Why do you think that is?

A: if you asked me this a few years ago I’d've said almost 100% was IE. That is still hugely vulnerable but now people have taken to the better, faster browsers such as Chrome and Firefox. IE still dominates the market at about 52% but Chrome is the majority of the rest. I think IE is dominating the market because the vast majority of people feel comfortable with it. Unless you actually read into vulnerabilities etc., you don’t know how dangerous IE is, so why do you need to change? Chrome already forced it to be better. One thing that did hugely affect bot infection rates was the mass removal of Java. When news of a java 0-day gets published people panic (rightly so) and un-install it or patch but as we all know java never stays secure for long.

Q: How do you keep yourself anonymous given that you have to deal with buyers?

A: I use bots to talk. Not like routing my traffic through them to create ‘proxies’ but actually coding a PC to take orders. The buyer gets the buyer bot code from the market, installs it, then types in what he wants; then without his knowledge his PC joins my IRC, which gives me the order and payment method. But obviously I don’t know this happens. ;)

Q: Is there anything that you consider emerging technology that could be disruptive to the black markets?

A: No, not at all. A market never stays on a domain for more than a week, if it does it’s a fed market.

Q: Is there any line you personally wouldn’t have crossed as a blackhat? Any types of crime that were outside of what you wanted to get involved with, despite the money?

A: I refuse to allow my botnet to be used to attack charities or soldier memorial pages. Apart from that it’s fair game. I get asked a lot about what if my botnet gets used to target ‘rival’ pedophile sites? Well the fact is, pedos have their own botnets. But if someone wants to attack a pedo site I’ll most of the time do it for free. Revenge porn is another thing I let people attack for free. See, we aren’t always mean. ;)

Q: Who, in your opinion, are the most dangerous people in the underground and why?

A: By far the drug lords. Any hacker who is respected will refuse to help them. They are brutal. One quite well known guy who became well known for his ‘anti drug’ attacks was tracked down and killed. Apparently they killed his family as well but that isn’t my business to divulge.

Q: How do you think those dangerous people (cartels and so on) are shaping the rest of the underground and its tactics? Are they making the average blackhat’s job easier or harder?

A: Ahh, drug cartels. They try to extort you with death threats etc. so you just post their personal information. Everyone hates them but its the underground so it’s ok I suppose. Can’t complain to the Feds haha.

Q: How did you gain the trust of the people to get access to join these forums?

A: Make a name for yourself in one of the IRC’s or create botnets for free or cheaply and they’ll start talking. Until then it’s an iron door you’re banging on.

Q: What do you consider to be your personal ethics? How do you perceive the owners of the websites you compromise and the victims of the machines that your botnet infects?

A: I kinda feel sorry for the people who become victims of CC fraud, although if you’re stupid enough to click a link you probably deserved it. For the admins, I hate them. If you can’t patch an SQLi or XSS you really shouldn’t be handling people’s CC. It’s just dangerous, stupid and laughable.

Interview With A Blackhat (Part 1)

[This interview openly discusses criminal activities from the perspective of an admitted criminal. You may find this content distressing, even offensive, but what is described in this interview is real. We know from personal experience is that these activities are happening on websites everywhere, everyday, and perhaps even on your websites. WhiteHat Security brings this information to light for the sole purpose of assisting those who want to protect themselves on their online business.]

Over the last few years, I have made myself available to be an ear for the ‘blackhat community.’ The blackhat community, often referred to as the internet underground, is a label describing those participating on the other side of the [cyber] law, who willingly break online terms of service and software licensing agreements, who may trade in warez, exploits, botnets, credit card numbers, social security numbers, stolen account credentials, and so on. For these individuals, or groups of them, there is often a profit motive, but certainly not always.

Most of the time, the people I speak with in the information security industry understand the usefulness of engaging in dialog with the underground — even if it’s not something they feel comfortable doing themselves. However, I occasionally get questioned as to the rationale — the implication being that if you play with pigs you start to stink. People sometimes even begin to insinuate that one must be bad to know bad people. I think it is incredibly important for security experts to have open dialogues with the blackhat community. It’s not at all dissimilar to police officers talking with drug dealers on a regular basis as part of their job: if you don’t know your adversary you are almost certainly doomed to failure.

One ‘blackhat,’ who asked to be called Adam, that I have spoken to a lot has recently says he’s decided to go legit. During this life-changing transition, he offered to give an interview so that the rest of the security community could learn from his point of view. Not every blackhat wants to talk, for obvious reasons, so this is a rare opportunity to see the world through his eyes, even if we’re unable to verify any of the claims made.

Hopefully by learning how Adam and other blackhats like him think, how they communicate, people can devise better solutions, abandon failed technologies, and fix the most glaring issues. Maybe people reading this can find more effective punishments to deter the criminal behavior before it happens, or ruin the incentives, disable the markets, or find ways to keep people from the allure of criminal activity in the first place. A great deal can be unearthed by examining Adam’s words and those of other blackhats like him. Or maybe we can entice some of them, like this individual, to leave the blackhat life behind completely.

Adam’s interview took place over a few days, and required a lot of back and forth. Due to the way in which this interview had to take place, a lot of editing was required to make it readable, but primarily to spelling, capitalization and punctuation. In every meaningful sense, these are Adam’s unaltered words.

(Note that when Adam refers to “whitehats,” he is referring to legitimate hackers in general, and that this should not be confused with WhiteHat Security the business.)

This is the first of our three-part interview. The next post will be tomorrow.

Q: Can you describe what you think your hacking/security related skills are?

A: My personal expertise and area of knowledge is in social engineering. I think it is pretty obvious I’m a blackhat, so I social engineer to card. Another area of “hacking” (I use the ” as DDoS isn’t really hacking) is botnet building and takedown orders. This is where most money in my opinion is made — where one day can bring in several thousand dollars. The whole blackhat market has moved from manual spreading to fully automated software.

In addition, many sites are targeted in malware/info leaks by using some really common and easy methods. These include SQLi, basic and advanced XSS, CSRF, and DNS cache poisoning. Although SQLi is still a big player, XSS has taken over the market. I estimate about 50-60% of the attacks my crew did last year (Jan 1st-Jan 1st) were XSS. I also learned several programming languages — Python, Perl, C, C++, C#, Ruby, SQL, PHP, ASP, just to name a few.

Q: Can you describe the first time you remember deliberately breaking a computer-related law? Why did you do it and how did you justify it?

A: Hmmmmm. That was many years ago. The first time I remember was when I was in school (aged about 14). The admins were pretty good at security (for school admins, bear in mind). I was in the library one day and I knew that the admins had remote access to every PC. I also knew the librarian did. The library just so happened to be the place where they marked our exam papers and entered the grades. I was never the genius at school but I was getting mediocre grades. What if I could get ‘A’s and ‘A+’s and not do half the work? So I started to read around. I eventually came across keyloggers.

It seemed strange and amazing that a program I could make (with a little research) could get me the top grades. So I did it. I installed the keylogger onto the librarian’s PC and then used the remote administration program to download the file onto the other PCs. I was suspended for two weeks.

Q: Where did you learn the bulk of your skills?

A: Books, Google, and the people I began speaking with on irc/forums. Unlike today’s 1337 haxorz (lol) we all shared, spoke, and helped each other. There wasn’t a sense of being mocked because you didn’t know.

Q: What attracted you to the blackhat way of life?

A: Money. I found it funny how watching tv and typing on my laptop would earn me a hard worker’s monthly wage in a few hours. [It was] too easy in fact.

Q: Can you recall a tipping point at which you started considering yourself a blackhat? What was the nature of the event?

A: It’s difficult really. I and the guys/girls I hung with never called ourselves blackhats, I don’t know, it was just too James Bond like. We just saw ourselves as people who found a way to make money. We didn’t care about what category we were in. It was just easy and funny. Although saying that, I first realized I might be branded a blackhat when my “real life” friend became a victim of credit card fraud. That’s when I realized my actions had real victims and not just numbers that were worth money.

Q: How many machines do you think you directly controlled at the peak of your botnet activity?

A: Erm, depends. I had two separate botnets (although some bots cross over). The DDoS botnet contained the bots which were public computers or computers that were in offices. [There were] two reasons I did that.

Either: 1. they are on for the majority of the day and have good connection speeds or 2. people weren’t stupid enough to do their banking on them (if you were I’d let a script kiddy have it). :) Then there was my carding botnet, definitely the most valuable. These were PCs of banks, estate agents, supermarkets and obviously home PCs. I preferred to target PCs where an employee would enter customer data, i.e. banks (yes banks are super easy to bot). This gave me a constant supply of credit cards and a never-ending amount of spam ammo. DDoS botnet has about 60-70k bots at the moment, most in the west. Carding botnet had a lot less at around 5-10k, most in Asia. 570k is the biggest I’ve controlled.

Q: How much money do you think you made after expenses per year at your peak doing blackhat activities?

A: I can’t really go into specifics but when 9/11 happened we were making millions.

Q: And how much do you think you made last year?

A: Off the top of my head? Around about 400-500k. Last year was kind of shit. People became wiser, patches became more frequent. This year we have 3/4 of that amount already.

Q: When you started, did you have a goal in mind to make a certain amount of money or achieve a certain goal?

A: I get asked this a lot by new people on the forums. I never set myself goals until probably in the last 4 years. I started it out just for easy laughs, bragging rights (lol) and easy, very easy money.

Q: Can you describe the process that you use to make money with your botnet?

A: Making money with a botnet is easier than brushing your teeth, especially if you’re in the automated industry. Any crew has several members. The bot master, researcher, reverse engineer, spreader, social engineer, sales man and fudder*. The people who sell 0-days are solely selling 0-days half the time. The buyers are bot masters without a crew.

Our crew developed a tool that checks the bot’s cache for Facebook/twitter accounts then checks their Facebook interests (e.g. justin bieber), then age, name, location. So for example bot no. 2 is signed into Facebook. The account likes Justin Bieber, aged 14, female, and lives in America (important to get correct language). Then automatically it selects a pre made list of links and for example would choose the ‘Justin bieber sex tape video’. Using zero days to compromise a website, then insert an iframe is kinda old, boring and sometimes doesn’t bring in the best results — unless of course you’re hijacking a high Alexa rating; then it’s worth it.

Combining 0-days to deface the website and then a 0-day in e.g. java to hijack with a drive by is a lot more effective than tracking the user into downloading a file. What a lot of people don’t realize is that emails easily available on their Facebook profile can be sold for spam. Again, this makes more money automatically.

* A fudder can be a tool that binds to a virus and makes it more difficult for antivirus to detect, or a person specializing in such a tool.

Q: How easy is it for you to compromise a website and take control over it?

A: For beginners you can simply Google inurl:money.php?id= — go ahead try it. But most of them will be cancelled or dried up. So, now you target bigger websites. I like to watch the news; especially the financial side of it. Say if a target just started up and it suddenly sky rocketed in online sales that’ll become a target. Most of these websites have admins behind them who have no practical experience of being the bad guy and how the bad guys think. This leaves them hugely vulnerable. They patch SQL but choose a DNS that is vulnerable to DNS cache poisoning. You can break in and be gone within an hour.

Q: How easy is it for you to take over the ownership of an account via whois information or other publicly available information?

A: Whois used to be crucial to gaining information. Now people spew it on Facebook, twitter, etc. Companies like Amazon only require name, address and email on the account to add another credit card. You then hang up. Ring the password reset department and tell them as verification the name, address, email and the credit card number you just added (it doesn’t even have to work (lol), just use fakenamegenerator.com) and then you are in. You can now see the ‘legit’ credit card’s last 4 digits. Now you can get an email password reset and you’re in. Amazon says they patched this two years ago but I use this method all the time. Seriously Amazon, train your staff.

Q: What is your favorite kind of website to compromise? Or are your hack attempts entirely untargeted? What are the easiest sites to monetize?

A: Most of the time un-targeted but once a company (which I won’t name) pissed me off for not giving me discount in a sale so we leaked every single credit card number online. One type of company I love to target is Internet security, i.e. anti virus companies.

There is nothing better than a clothing store at the summer sales (except porn websites). These are in my personal opinion the easiest and most successful targets to breach. I’ll talk about clothes stores first. Clothing websites are SO easy because of two main types of attacks.

1. The admins never ever have two-step authentication. I don’t know why, but I have never seen one admin have it (and I’ve done it thousands of times). 2. The ‘admin’ usually works there behind the tills or in the offices. They have no clue what they’re doing: they just employ someone to make the website then they run it. They never ever have HTTPS, [so they have] huge SQLi vulnerabilities (e.g.. inurl:product.php?id=). Once you have the SQLi vulnerability you can go two routes or both. Route one: steal the credit card info and leave. Route two: deface the website, keep the original HTML code but install an iframe that redirects to a drive by download of a banking Trojan.

Now to discuss my personal favourite: porn sites. One reason why this is so easy: The admins don’t check to see what the adverts redirect to. Upload an ad of a well-endowed girl typing on Facebook, someone clicks, it does a drive by download again. But this is where it’s different: if you want extra details (for extortion if they’re a business man) you can use SET to get the actual Facebook details which, again, can be used in social engineering.

Q: What is your favorite/most effective exploit against websites and why?

A: If it’s a 0-day, that obviously ranks at the top. But below that is XSS. It’s really well known but no one patches it. I suppose DDoS isn’t really classed as an exploit but that can bring in monthly ‘rent’ for our ‘protection’. But over all 0-days are the greatest exploits.

Q: How do you monetize DDoS?

A: People buy accounts so for example you rent 1k bots and have a DDoS time limit of 30 mins. Some people buy one-offs. Black mail is a huge part of it. Take the website down for an hour. Email them or call them and say they pay 200 dollars or it stays offline for good. They usually pay up. If they don’t, they lose days, weeks, months of business.

Q: How do you pick targets to DDoS when you are attempting to extort them?

A: Hmmm. It depends. If there is a big sporting event, e.g. the Super Bowl, I can guarantee 95% of bookies have been extorted. I knew of one group who took down cancer research website and extorted them after their race for life donation process was meant to start. They got their money, kinda sad really.

Q: What kind of people tend to want to buy access to your botnet and/or what do you think they use it for?

A: Some people say governments use it, rivals in business. To be honest, I don’t care. If you pay you get a service. Simple.

Continue Reading Part 2

InfoSec Europe Wrapup

It took an hour for my mind to catch up to my experience when a member of the House of Lords stopped by the WhiteHat Security booth at InfoSec Europe in London a few weeks back.  I read the organization name on his badge when he stopped to talk to me.  “House of Lords.”  But it didn’t quite click.  Here was a nice, easy going, casually dressed late middle aged man with a round nose and loose slightly unkempt brown hair, smiling and joking about how the kids were going to fight over the little WhiteHat branded fold up multi-tool we were giving away to visitors at our booth.  He didn’t really seem like he had much interest in our actual technology so I scanned his badge and exchanged a few words and he went on his way.

That’s how these trade shows work- everyone has some freebie to give away in an attempt to get the attention of passers by, often enough just for long enough to scan their badge and capture their information for a leads database.  Our marketing and events team, led by Kim Gerton, does a great job of bringing things that are actually useful.  I had some fellow come by in the afternoon asking if we had any more of the flashlights we’d given out at an earlier show; he loved his so much that he wanted a spare in case it ever died.  Another gentleman came by towards the end of the day and during our conversation mentioned that a hacking event at another booth wouldn’t have come off without the tool we were giving away today.  Someone had installed the hard drive on the machine wrong and there were half a dozen software guys trying to figure out what to do and not one screw driver among them.

For me, as a Product Manager, a conference like this is a rare opportunity to speak with potential and current customers I don’t usually encounter. Obviously the CIO who dropped by to ask “Do you do static analysis?” Yes. “Does it do Java?” Yeah. “Great, here’s my card. Have your sales people get in touch with me” is a rather desirable visitor, as was the one sent over by a colleague who told him we’d be a great fit to hear about the details of our service in a sit down session. For me, however, it’s more exciting to talk to people uncertain about whether WhiteHat is a good fit.

Whether it was the keynotes that focused on security best practices and budget management, the release at InfoSec Europe of the 2013 Cyber Security Breaches Survey, or simply the growing awareness and interest, there was a lot of interest from attendees in how WhiteHat’s offering worked. The Cyber Security Survey, a UK government study, is an interesting read and highlights the need for comprehensive Web Application Security programs. According to the survey, 80% of attacks are a result of well known problems detectable via security assessments, and 93% of large organizations (250+ employees) and 87% of small business had at least one security breach last year.  I spent time with a broad variety of people from students and interns interested in how WhiteHat’s technology works, to people from small businesses who had staffing constraints but still wanted to solve their security concerns, to the aforementioned CIOs looking for large scale solutions.

Perhaps the most interesting category of people I spoke with was the Indian consultants.  That’s at least partly because I realized over time that these guys were quite serious and represented an interesting trend I had not yet seen personally.  I usually figure consultants are worth talking to because they may end up being influencers within organizations or experts in the community.  Indeed, half the American or European consultants I talked to ended up knowing about us already and asking me to send their greetings to Jeremiah or Jim or Jerry (btw guys hi from PDP and Dinis).

The Indian consultants turned out to be a different story – or rather a very similar one repeated three times.  They consult with many private and/or governmental organizations in India, helping them architect and manage their IT and/or Security policies and infrastructure.  As I spoke to them and listened to what they had to say, I realized that these guys were here on serious business to find solutions for pressing needs so they could serve their customers better, and that they understood better than most people I’ve spoken to how WhiteHat might help them do that.  Typically I assume people with “consultant” on their badge at security conferences are doing manual pen testing themselves and wouldn’t particularly care for our message; here the situation was quite different.  When I talked about taking that workload off their hands entirely for all their customers, they seemed interested, not uneasy.  When we discussed how WhiteHat can give their customers, their end users, direct access to our portal and through that the ability to ask questions and get clarity directly from our large team of security engineers in the Threat Research Center they started pulling out business cards and asking to talk more later.  For them the idea of being able to offload the day to day management, support, and education in the web application security domain was a big potential boon which they immediately understood and valued.  They were more interested in being able to deliver quality to their customers without a lot of personal time investment, leaving them free to focus on the bigger IT management and/or security picture.

InfoSec Europe was a big success for the organizers and for WhiteHat with over 12,000 attendees and a great deal of positive engagement. For me it was a reminder that though on the surface the swag and lead collection seems like the main activity, there is a real and more substantive reason these conferences are so well attended. The industry is growing and changing rapidly, and the chance for newcomers and old hands to talk to each other and learn what is possible – and what is needed – is invaluable for those who take advantage of it.

The State of Web Security

After months of hard work, today we are releasing the 2013 WhiteHat Website Security Statistics Report. Collectively represented are more than 650 organizations and tens of thousands of real-world websites continually monitored by WhiteHat Sentinel Services. This is the largest data set of its kind and we’re anxious to share all the new things we’ve learned.

This year, our 6th, we’ve done things differently. We wanted to try something truly ambitious, something that advances our collective understanding of application security, and something that to our knowledge has never been done before!

So, in addition to releasing detailed website vulnerability metrics that the community has come to rely upon, we sought to measure the impact of today’s so-called “best-practices.” To find out if activities such as software security training for developers, pre-production testing, static code analysis, web application firewalls, etc. really do lead to better security metrics and fewer breaches. To answer the fundamental question, what aspects of an SDLC program actually do make a difference – and how much? Of course, every “expert” has an opinion on the matter, but the best most anyone has is personal anecdote. That is, until now.

To get there we asked all Sentinel customers to privately share details about their SDLC and application security program in a survey format – we received 76 total responses. We then aggregated and correlated their answers to their website vulnerability outcomes and reported breaches. The results of this data combination are nothing less than stunning, enlightening, and often confusing.

To give you a taste for the full report, let’s start with the high-level basics:

The average number of serious* vulnerabilities per website continues to decline, going from 79 in 2011 down to 56 in 2012. This was not wholly unsuspected. Despite this, 86% of all websites tested were found to have at least 1 serious vulnerability during 2012. Of the serious vulnerabilities found, on average 61% were resolved and they took an average of 193 days to get resolved from the date of notification.

Web

As far as the Top Ten most prevalent vulnerability classes in 2012, the list is relatively close to last year’s – though Information Leakage surpassed Cross-Site Scripting yet again:

  1. Information Leakage – 55% of websites
  2. Cross-Site-Scripting – 53% of websites
  3. Content Spoofing – 33% of websites
  4. Cross-site Request Forgery – 26% of websites
  5. Brute Force –26% of websites
  6. Fingerprinting – 23% of websites
  7. Insufficient Transport Layer Protection –22% of websites
  8. Session Fixation – 14% of websites
  9. URL Redirector Abuse – 13% of websites
  10. Insufficient Authorization – 11% of websites

Conspicuously absent is SQL Injection, which fell from #8 to #14 from 2011 to 2012, and now identified in only 7% of websites. Obviously vulnerability prevalence alone does not solely equate to exploitation.

When we took a closer look at some of the correlations of vulnerability and survey data, we found some counter-intuitive statistics – implying that software security controls, or “best practices” do not necessarily lead to better security – at least at all times in all cases:

  • 57% of organizations surveyed provide some amount of instructor-led or computer-based software security training for their programmers. These organizations experienced 40% fewer vulnerabilities, resolved them 59% faster, but exhibited a 12% lower remediation rate.
  • 39% of organizations said they perform some amount of Static Code Analysis on their website(s) underlying applications. These organizations experienced 15% more vulnerabilities, resolved them 26% slower, and had a 4% lower remediation rate.
  • 55% of organizations said they have a Web Application Firewall (WAF) in some state of deployment. These organizations experienced 11% more vulnerabilities, resolved them 8% slower, and had a 7% lower remediation rate.

Two questions we posed in our survey illustrated that compliance is the number one driver for fixing web vulnerabilities…while it was also the number one driver for not fixing web vulnerabilities. Proponents of compliance often suggest that mandatory regulatory controls be treated as a “security baseline,” a platform to raise the floor, and not represent the ceiling. While this is a nice concept in casual conversation, this is typically not the real-world reality we see.

The last point I want to bring up for now focuses on accountability in the event of a data breach. Should an organization experience a website or system breach, WhiteHat Security found that 27% said the Board of Directors would be accountable. Additionally, 24% said Software Development, 19% Security Department, and 18% Executive Management. Here’s where things get really interesting though. By analyzing the data in this report, we see evidence of a direct correlation between increased accountability and decreased breaches, and of the efficacy of “best-practices” and security controls.

Questionstats_img

We stopped short of coming to any strong conclusions based upon this data alone. However, we now have something solid to work from in establishing new theories and avenues of research to explore. Please, have a look at the report and let us know what stands out to you. What are your theories for why things are the way they are? If you’d like different slices of the data, we’re all ears.

#WebsiteVulnStats

Twitter to @jeremiahg and @whitehatsec.

Personal side note: I would like to thank all of our customers who responded to our survey earlier this year as well as to a select group of respected individuals in the security space (they know who they are) that got a sneak peek of our findings last week and whose feedback was invaluable. Also thank you to my colleagues Gabriel Gumbs, Sevak Tsaturyan, Siri De Licori, Bill Coffman, Matt Johansen, Johannes Hoech, Kylie Heintz, and Michele Cox, whose teamwork helped bring everything together.

Why You Should Overload WebSite Errors

I often have to explain to people that they need to overload error messages on their websites, and I occasionally get weird looks. It’s important to know that there are three scenarios that regularly occur that can be used to an attacker’s advantage.

The first scenario is where an error occurs in the application logic and creates a 500 error (Internal Server Error). These errors can often include stack traces, which provide incredibly useful information for crafting SQL injection attacks, among others. There’s no reason a user should see these.

The second is 400 errors (Bad Request). If an attacker can send overly large cookies, the server will respond with a bad request and will include the cookie payload in the response. This response, which includes the over-long cookie, can be read by an XMLHTTPRequest, even if the HTTPOnly flag is set. This allows an attacker who can set cookies (via XSS for instance) to break the protection that HTTPOnly provides, so it’s critical that these errors are trapped.

The third scenario is that the difference between a 404 (File Not Found) and a 403 (Forbidden) is noticeable to a scanner and can help tools that do directory enumeration figure out which directories exist verses aren’t there, at which point it is possible to brute force the files that are contained within. Ideally all directories that have Directory Indexing turned off as well as files that aren’t there should respond with 200 OK to confuse scanners. Disabling Directory Indexing is important and useful, but so is making it impossible to tell which directories are there or not there. Overloading a 404 (File Not Found) error is also useful in that it can be used to your advantage for instance, to tell users in a graceful way that they can go back to another page, offer a search box to find what they need, or whatever makes sense for your users.

There may be many other use cases as well, but this should give you some ideas as to why it’s important to trap errors. Don’t worry that you will lose visibility into the problems your site may have. Just because the user can’t see it doesn’t mean you can’t. You can disable this type of error trapping in QA, and you can review your logs and identify pages that are problematic. This allows you to fix your issues without introducing additional security issues.

“How does WhiteHat Security approach BYOD?”

BYOD is a big topic for companies, particularly when it comes to how to properly implement policy around personal devices used for work purposes. It’s a question that we are asked often by employees and by our customers, so I thought I would take a moment to share a little about our approach to BYOD.

By nature, the work we do at WhiteHat Security involves work with some of our customers most sensitive data and critical assets. We don’t take this lightly. So, we deal with BYOD perhaps a little differently then most companies. Getting access to sensitive customer data is only performed via WhiteHat Security supported hardware and job function. So in a sense, we do not provide outright support for BYOD. If employees or guests do bring their own devices to our offices, they can only access our public wifi, and no WhiteHat Security data or customer data is accessible on that network. We segment our data pretty aggressively to prevent data leakage. Employees that require access to certain mobile devices – smart phones or laptops, for instance - WhiteHat Security will pay for the device and the IT department will configure it for access, but access is limited to email and not customer data.