[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

[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.

[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

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.

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.

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.

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.

Each year in Web security new vulnerability classes are published, new variations of the existing ones are documented, and each website must be tested for them. Likewise, each year, the already mountainous pile of HTTP requests necessary to test for these issues grows, which significantly increases scan times. This problem can’t be solved by threading scans, making simultaneous HTTP requests, alone. A smarter way of going about the scanning process is required. We need solutions drastically reducing the number of HTTP requests per scan, while maintaining vulnerability identification performance.

To begin the discussion, let’s take a look at SiteX, an every day e-commerce website. The attack surface of SiteX can be encompassed by 100 distinct URLs that have a total of 400 unique name / value pairs, 20 Web forms with a total 60 of fields, and 3 cookies that add 12 more input points. This gives a grand total of 472 injection points, all of which must be checked for vulnerabilities in a dynamic scan. (aka run-time testing, fuzz testing, fault-testing, black-box testing, etc.)

Let’s begin testing SiteX for Cross-Site Scripting (XSS) by starting with a simple payload like <* XSSTEST>. If “<* XSSTEST>” returns un-html-encoded in the response page, this is a good indication a vulnerability exists. 472 HTTP requests later, to fully exercise the aforementioned attack surface, we might have some interesting bug-bounty-worthy results.

Of course “<* XSSTEST>” alone is not enough for thorough XSS testing. Fortunately, we can easily try another XSS payload such as attribute injection, “ onmouseover=alert(document.domain).” Doing so costs another 472 HTTP requests. What about testing if the injection lands directly in Javascript space? Simple, submit “‘; alert(document.domain); ”. You get the idea now. Each payload tested must be run across SiteX’s entire attack surface and the price of 472 requests must be paid.

Scaling this out further, consider what happens if we need to test 5 XSS payloads, 10 payloads, 20, or maybe even 50! Racking up such a lengthy list of injections is trivial when attempting all the myriad of filter-bypass tricks documented over the years. For example, full url hex encoding converts “<* XSSTEST>” into “%20%3C%58%53%53%54%45%53%54%3E,” which might even work! We can even try Base64 encoding as well if we’d like, “PFhTU1RFU1Q+.”

In our scenario, such exhaustive XSS testing may require up to 23,600 HTTP requests (50 payloads x 472 attack surface), which could take a long while to complete. Next, think about similar testing for SQL Injection, Content-Spoofing, Command Execution, Path Traversal, HTTP Response Splitting, and injection style classes of attack. All of a sudden the number of HTTP requests for a full website vulnerability scan starts getting up into the 6 figures rather fast. This is why scans routinely take hours, even multiple days to finish.

At WhiteHat Security, one such way we’ve been counteracting this problem is by analyzing our historical vulnerability scan data. We’ve scanned tens of thousands of real-world websites of all shapes, sizes, and types, over and over again for years, and identified countless numbers of vulnerabilities. The data shows that certain payloads are far more likely to succeed than others. Obviously then, it makes sense to attempt those most likely to succeed first. If one payload works, injecting subsequent payloads in that class become unnecessary.

Figure 1 illustrates payload by payload performance using a simple graph. On the horizontal, each tick mark represents one of our payloads. The vertical is their relative effectiveness by website percentage. Clearly some payloads succeed on a large number of websites, while others do not. Figure 2 is subtly different. Instead measuring website percentage, the vertical shows the relative total quantity of vulnerabilities payloads are credited for identifying. Some payloads are definitely more productive than others.

Figure 1.

 Figure 2.

Back to our previous example, if “<* XSSTEST>” works on the first shot, the remaining 49 payloads, whatever they are, for that one injection point, don’t have to be sent. We can save 49 HTTP requests and the time it takes to send them. By smartly ordering our injections we drastically increase our scan efficiency without sacrificing overall vulnerability identification performance. We can know this for a fact through regression testing. This is one of the areas our Research team, the “R” in “TRC,” focuses on.

From here, scan efficiency in our technology gets ever cooler, well, sophisticated at least. A while back we introduced data-backed conditional logic. Depending on how SiteX responds to one test, it impacts what the next test will be. For example, if SiteX does not echo “>” and “<,” there is no need to inject any more of those types of payloads. Doing this exponentially cuts down the number of requests a scan might otherwise require.

Figure 3 is a dynamically generated graphical diagram of the logic flow of our payloads that illustrates a little bit about how this looks. At the risk of revealing some intellectual property, Figure 4 zooms in on a particular area of the decision tree and provides a bit clearer picture of what’s happening behind the scenes.

 

Figure 3.

Figure 4.

As a Software-as-a-Service vendor, we have the ability to see and measure payload performance and use it to our advantage — to our customer’s advantage. A luxury the desktop scanner guys do not have. Every day, with each new scan, with each new website we test, with each new payload to test, we get just a little bit better. Every day, a little bit smarter.

 

We would like to know more about what you and/or your organization are doing in terms of application security, looking back at 2012 as well as looking toward what will be important in 2013.

Here is a link to the survey: https://www.surveygizmo.com/s3/1101673/WhiteHatSec.

Please answer the six quick questions to be entered to win a Kindle Fire. The first 25 participants to complete the survey will receive a free t-shirt!

Additional Information:

• All completed entries will be entered into the final drawing for a Kindle Fire.
• First 25 participants to submit a completed survey will receive a free T-shirt.

The survey will be open through January, and only one entry per person is permitted.

If you have any questions or comments, please let us know! Send all emails to whitehatsec@horngroup.com.

Like us on Facebook: WhiteHat Security

Follow us on Twitter: @WhiteHatSec

For more information, please visit www.whitehatsec.com.
 Thanks again and good luck!

What if right now, people and companies are spending billions of dollars, each and every year, to be less secure? What if security products, those things indoctrinated by best-practices and mandated by compliance obligations, are actually the weakest link in the security chain? What if defense-in-depth is really nothing more than a nice idea. I’m confident this reality is coming, soon even. An inescapable and ironic situation where the security industry is going to be publicly embarrassed and must eat its own dog food for a change. That yucky, yucky stuff we’ve been trying to force down the throats of everyone else for decades.

Wait. Stop. Let me back up.

Back in the day, malicious hackers commonly targeted unpatched FTP, mail, and DNS servers — others brute-forced telnet ports. From a defense perspective, patch and configuration management in an enterprise environment is often difficult and expensive, particularly when there’s a lot of hosts to protect. This was is a leading reason why network firewalls are pervasively deployed across basically all Internet-connected organizations, to hide away insecure software from the hostile wilds of the Internet. This was the classic network response to an inherent software security problem, a problem no one from that industry ever bothered to address. What did happen was 65,536 ports became just two, 80 and 443 (Web), and developers largely just recreated the software that already existed to run on those ports, and within a Web browser.

In response, the bad guys SHIFTED.

The bad guys began focusing their attacks at the Web-layer, which is where today we see the majority of the breaches taking place and almost all of the data being lost.

During the same period of time, other digital miscreants preferred hacking operating systems, such Windows, which for a long while was fairly trivial. The recommendation from the Information Security (InfoSec) industry, from their RSA keynote stages, was to spend more on firewalls and anti-virus software. Oh yeah, and patch, patch, patch… if you can.

Microsoft grew tired of being the security industry’s laughing stock and hacking’s path of least resistance, so they kicked off an initiative called Trustworthy Computing and invested heavily in their Software Development Lifecycle (SDL). It took some time, but their efforts in software security paid off.

How do we know? Well, the bad guys SHIFTED.

We saw that instead of predominantly targeting Windows, our cyber adversaries began exploiting the applications installed on top of the desktop. Applications like Web browsers, Microsoft Office, PDF processors, and email clients — but mostly the Web browsers. Of course the InfoSec industry said, buy more firewalls! Buy more [email and browser] AV! And sadly, a lot of people listened. Patching, yeah, that‘s good idea. Do that too! Some listened.

Then, as we saw starting around 2007, to exploit thousands, nay, millions of PCs, all one had to do was SQL Inject a vulnerable website, take your pick of millions because remember that pesky 80/443 software security problem was never solved by firewalls or AV, and lace those websites with browser-based exploits. Well-known exploits, zero-days, it didn’t matter which, few people ever kept up on browser patches anyway. Yet, more money spent on firewalls and AV just the same.

Browsers and browser vendors, Google, Microsoft, and Mozilla, then took their turn in the exploitation crosshairs, feeling the pain of a lack of adequate software security in their respective products. Browser exploitation became a leading cause of malware propagation. As we could expect, they didn’t much like that position, that reputation, even when offering a $0 application. Users expected the software to be secure. Browser vendors had to get serious about software security, and you know what, they did!

How do we know? Wait for it… the bad guys SHIFTED!

If you notice, the bad guys next began targeting browser plug-ins, namely Flash and Java. Yep, that software already installed in just about everyones browser. That software riddled with vulnerabilities. That software rarely patched by the end-user. Adobe (Flash) and Oracle (Java) are working through their own software security nightmare right now.

The browser vendors, not content to wait for Adobe and Oracle, are taking their own steps to protect their platforms, like Microsoft did by offering up ASLR and DEP. They are alerting, disabling or unbundling outdated plugins, if not actively uninstalling them altogether, and making sure technology exists so as not to need them at all. See HTML5.

Give the situation 6 months. Give it a year. It’s difficult to say when exactly, but eventually browser hacking, including the plugins, will get sufficiently difficult to warrant another SHIFT. So where will the bad guys focus next? That’s the billion dollar question. My bet is not “mobile,” while that day may come too, I think it’ll be “security products” targeted first.

Think about it. Think about all the security products out there, such as IPS, DLP, WAFs, various deployment forms of AV software, and so on are pervasive across enterprise networks and end-user PCs. These products are designed to parse and analyze data from unknown origins, making them ripe for haxoring. Products whose makers, the InfoSec Industry, never really had an emphasis on “software security,” if they even know what that concept is, and notoriously bad at handling vulnerability disclosure — a sure sign of immaturity. Their only training being how to sell more firewalls and AV.

Imagine an email specifically designed to exploit a system, but only one protected by an anti-virus email gateway. A piece of Web page code that exploits a browser, but only those protected by anti-virus software. Incoming Web traffic whose goal is to compromise an IPS or WAF itself, not necessarily the website behind it.

None of this is far fetched. In fact, the writing is already on the wall. Just look at what Tavis Ormandy did recently to Sophos’s products in his spare time. No one should be naive enough to believe this is an anomaly. How many zero-days do you think are yet to be found in that software? What about other AV products? What about all the other security products out there? Juicy untouched zero-day heaven, that’s what it is. Oh right right, we know the answer we’ll be given. Buy more firewalls and AV! And of course people will listen, but what for? To protect insecure firewalls, insecure AV, and the other insecure security products? Please.

I’m sure the industry apologists will also predictably say, “there is no silver bullet,” as if that somehow absolves responsibility for shipping risk increasing products.

Hacktivists, cyber-criminals, nation-state sponsored APT, however we label them, we’ve witnessed how our adversaries select their targets, and especially the method of attack, typically by the path of least resistance. One vulnerability is all a bad guy really needs, and the first and easiest one to identify and exploit will do just fine. So when one path of attack doesn’t work or becomes too difficult, the bad guys will shift. Reporters and PR agencies, get your digital ink ready, we’re in for a bumpy ride.