15 posts left…

I’ve talked about this a few times over the years during various presentations but I wanted to document it here as well. It’s a concept that I’ve been wrestling with for 7+ years and I don’t think I’ve made any headway in convincing anyone, beyond a few head nods. Bad security isn’t just bad because it allows you to be exploited. It’s also a long term cost center. But more interestingly, even the most worthless security tools can be proven to “work” if you look at the numbers. Here’s how.

Let’s say hypothetically that you have only two banks in the entire world: banka.com and bankb.com. Let’s say Snakoil salesman goes up to banka.com and convinces banka.com to try their product. Banka.com is thinking that they are seeing increased fraud (as is the whole industry), and they’re willing to try anything for a few months. Worst case they can always get rid of it if it doesn’t do anything. So they implement Snakeoil into their site. The bad guy takes one look at the Snakeoil and shrugs. Is it worth bothering to figure out how banka.com security works and potentially having to modify their code? Nah, why not just focus on bankb.com double up the fraud, and continue doing the exact same thing they were doing before?

Suddenly banka.com is free of fraud. Snakeoil works, they find! They happily let the Snakeoil salesman use them as a use case. So our Snakeoil salesman goes across the street to bankb.com. Bankb.com has seen a two fold increase in fraud over the last few months (all of banka.com’s fraud plus their own), strangely and they’re desperate to do something about it. Snakeoil salesman is happy to show them how much banka.com has decreased their fraud just by buying their shoddy product. Bankb.com is desperate so they say fine and hand over the cash.

Suddenly the bad guy is presented with a problem. He’s got to find a way around this whole Snakeoil software or he’ll be out of business. So he invests a few hours, finds an easy way around it and voila. Back in business. So the bad guy again diversifies his fraud across both banks again. Banka.com sees an increase in fraud back to the old days, which can’t be correlated to anything having to do with the Snakeoil product. Bankb.com sees their fraud drop immediately after having installed the Snakeoil therefore proving that it works twice if you just look at the numbers.

Meanwhile what has happened? Are the users safer? No, and in fact, in some cases it may even make the users less safe (incidentally, we did manage finally stop AcuTrust as the company is completely gone now). Has this stopped the attacker? Only long enough to work around it. What’s the net effect? The two banks are now spending money on a product that does nothing but they are now convinced that it is saving them from huge amounts of fraud. They have the numbers to back it up - although the numbers are only half the story. Now there’s less money to spend on real security measures. Of course, if you look at it from either bank’s perspective the product did save them and they’ll vehemently disagree that the product doesn’t work, but it also created the problem that it solved in the case of bankb.com (double the fraud).

This goes back to the bear in the woods analogy that I personally hate. The story goes that you don’t have to run faster than the bear, you just have to run faster than the guy next to you. While that’s a funny story, that only works if there are two people and you only encounter one bear. In a true ecosystem you have many many people in the same business, and you have many attackers. If you leave your competitor(s) out to dry that may seem good for you in the short term, but in reality you’re feeding your attacker(s). Ultimately you are allowing the attacker ecosystem to thrive by not reducing the total amount of fraud globally. Yes, this means if you really care about fixing your own problem you have to help your competitors. Think about the bear analogy again. If you feed the guy next to you to the bear, now the bear is satiated. That’s great for a while, and you’re safe. But when the bear is hungry again, guess who he’s going after? You’re much better off working together to kill or scare off the bear in that analogy.

Of course if you’re a short-timer CSO who just wants to have a quick win, guess which option you’ll be going for? Jeremiah had a good insight about why better security is rarely implemented and/or sweeping security changes are rare inside big companies. CSOs are typically only around for a few years. They want to go in, make a big win, and get out before anything big breaks or they get hacked into. After a few years they can no longer blame their predecessor either. They have no incentive to make things right, or go for huge wins. Those wins come with too much risk, and they don’t want their name attached to a fiasco. No, they’re better off doing little to nothing, with a few minor wins that they can put on their resume. It’s a little disheartening, but you can probably tell which CSOs are which by how long they’ve stayed put and by the scale of what they’ve accomplished.

Shared by Jeff Williams
If you're relying on automated tools without a skilled human being involved... your sense of security is false. This article describing Hurricane Earl shows a woman putting a pattern of duct tape on the window. Does this duct tape really help?

No, of course not. Duct tape does nothing to stop the glass for shattering, and does almost nothing to stop fragments flying around.

What it does give people is a false sense of security. For whatever reason, they’ve decided not to buy hurricane shutters (even though they live in a hurricane zone) and not board up their windows with plywood. But they can’t just do nothing, so they resort to sympathetic magic like taping up windows. At least they are putting something on their windows.

Such ignorance is not just useless, but in some cases, can be harmful. Some people believe they should leave their windows open a crack during a hurricane, in order to equalize pressure. The opposite is true: this makes it more likely that the hurricane will pop your roof off. The reason is that wind traveling over your roof creates low pressure above, and wind entering your house creates high pressure inside. This lifts your roof off, in precisely the same manner it lifts an airplane wing when flying.

There are obvious analogies with cybersecurity. People do things, like install anti-virus, firewalls, or WEP, because “doing something” makes them feel good. But they haven’t thought through the cause-and-effect whether doing such things actually work. If you're relying on automated tools without a skilled human being involved... your sense of security is false.

•OWASP Vicnum version 1.4 (PHP/Perl) •Mutillidae version 1.3 (PHP) •Damn Vulnerable Web Application version 1.06 (PHP) •Ghost (PHP) •Peruggia version 1.2 (PHP) •OWASP CSRFGuard Test Application version 2.2 (Java) ...

Have you ever heard someone ask “Do we need to fuzz this?”

This question comes up quite a bit in the context of reactive security work.  There are basically two traditional answers:

• Yes.
  When you’re attempting to find variants of something like a memory corruption bug, fuzzing is your best friend.  It’s a no-brainer.
  
  
• No.  Er, wait.  Sure, uh, go for it...
  When you’re attempting to find variants of something that looks more like a design bug, fuzzing might at first seem silly.  The answer becomes less clear after thinking about it a little more.  With 20/20 hindsight you can usually think up a way in which any particular bug might be caught by an automated process.  Would that automated process fit a loose definition of fuzzing?  Possibly.
  
  This intellectual discussion usually doesn’t go very far.  This is because of a general perception that fuzzing for design bugs just isn’t going to deliver the ROI that creative hacking, code analysis, etc. can provide in a given period of time.  But it’s very hard to say that this is true in all cases.  Hence the vague answer above.

Example

Here’s one simple scenario where a technique that could surely be considered fuzzing (and was specifically designed to identify design bugs) did yield a good result.

While testing the Internet Explorer XSS Filter prototype in 2007, SkyLined identified that classic ASP would simply drop invalidly encoded character sequences from HTTP request querystring parameters prior to the HTTP response formation.  This resulted in a situation where our filter could not properly match requests to responses and thus the filter could be bypassed for apps on classic ASP.

The XSS Filter was adapted to account for this situation and test cases were created.

Later we developed a fuzzer capable of slightly modifying test cases before running them.  As you may imagine, it’s not hard for a simple fuzzer to generate various forms of invalidly encoded character sequences.  As it turned out, our fix for the encoding issue missed a corner case that our fuzzer was able to trigger.  We were then able to fix the variant and add a new test case to cover any future regressions.

Thoughts?

Fuzzing for design bugs is not a new idea.  Just in regards to XSS, it was mentioned by Alexander Sotirov in 2008, and of course the sla.ckers are well known for putting this approach into practice.  What is most interesting to me right now is the question of when / how to apply fuzzing style techniques for design bugs in general.  I don’t recall ever having seen a really good answer to this question.

So I would be interested in your thoughts on classes of design defects that are particularly amenable to some form of fuzzing, as well as classes of design defects where fuzzing is just a waste of time.  (Some other questions: What actions must a DOM crawler have to perform in order to be a true fuzzer, and does it even matter if it’s called a fuzzer or not?)

Feel free to hit me up on Twitter or leave a comment on this blog.

dross

I just dig that image out; I made it for the release of the WASC Threat Classification 2.0

Romain03424422661754357103

Interesting:

Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft's software trusts more than 100 private and government institutions.

Disturbingly, some of these trusted certificate authorities have decided to delegate their powers to yet more organizations, which aren't tracked or audited by browser companies. By scouring the Net for certificates, security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motors­and a UAE mobile phone company called Etisalat.

In 2005, a company called CyberTrust­which has since been purchased by Verizon­ gave Etisalat, the government-connected mobile company in the UAE, the right to verify that a site is valid. Here's why this is trouble: Since browsers now automatically trust Etisalat to confirm a site's identity, the company has the potential ability to fake a secure connection to any site Etisalat subscribers might visit using a man-in-the-middle scheme.

schneier110888389224464497591299129032743816257806748650429334202339145567035696569821891134531414684058811202585988719661023088031122769238568184481303386143574287416909709248271686049233117432141916310433130107890991197529744308060419678676185941167681046473434407121812046870906543773005650439971478030852

angry tapir writes "Facebook users will soon have a new way of knocking spammers out of legitimate accounts. The social-networking company is rolling out a new security feature that lets users see which computers and devices are logged into their Facebook accounts, and then removing the ones that they don't want to have access."(author unknown)

The irda_bind function in net/irda/af_irda.c in the Linux kernel before 2.6.36-rc3-next-20100901 does not properly handle failure of the irda_open_tsap function, which allows local users to cause a denial of service (NULL pointer dereference and panic) and possibly have unspecified other impact via multiple unsuccessful calls to bind on an AF_IRDA (aka PF_IRDA) socket.

** DISPUTED ** lxsession-logout in lxsession in LXDE, as used on SUSE openSUSE 11.3 and other platforms, does not lock the screen when the Suspend or Hibernate button is pressed, which might make it easier for physically proximate attackers to access an unattended laptop via a resume action. NOTE: there is no general agreement that this is a vulnerability, because separate control over locking can be an equally secure, or more secure, behavior in some threat environments.

The do_anonymous_page function in mm/memory.c in the Linux kernel before 2.6.27.52, 2.6.32.x before 2.6.32.19, 2.6.34.x before 2.6.34.4, and 2.6.35.x before 2.6.35.2 does not properly separate the stack and the heap, which allows context-dependent attackers to execute arbitrary code by writing to the bottom page of a shared memory segment, as demonstrated by a memory-exhaustion attack against the X.Org X server.

The xfs_swapext function in fs/xfs/xfs_dfrag.c in the Linux kernel before 2.6.35 does not properly check the file descriptors passed to the SWAPEXT ioctl, which allows local users to leverage write access and obtain read access by swapping one file into another file.

WebYaST in yast2-webclient in SUSE Linux Enterprise (SLE) 11 on the WebYaST appliance uses a fixed secret key that is embedded in the appliance's image, which allows remote attackers to spoof session cookies by leveraging knowledge of this key.

Cross-site request forgery (CSRF) vulnerability in the apache2-slms package in SUSE Lifecycle Management Server (SLMS) 1.0 on SUSE Linux Enterprise (SLE) 11 allows remote attackers to hijack the authentication of unspecified victims via vectors related to improper parameter quoting. NOTE: some sources report that this is a vulnerability in a product named "Apache SLMS," but that is incorrect.

SQL injection vulnerability in index.php in Seagull 0.6.7 and earlier allows remote attackers to execute arbitrary SQL commands via the frmQuestion parameter in a retrieve action, in conjunction with a user/password PATH_INFO.

Multiple SQL injection vulnerabilities in the JE FAQ Pro (com_jefaqpro) component 1.5.0 for Joomla! allow remote attackers to execute arbitrary SQL commands via category categorylist operations with (1) the catid parameter or (2) the catid parameter in a lists action.

Multiple PHP remote file inclusion vulnerabilities in Multi-lingual E-Commerce System 0.2 allow remote attackers to execute arbitrary PHP code via a URL in the include_path parameter to (1) checkout2-CYM.php, (2) checkout2-EN.php, (3) checkout2-FR.php, (4) cat-FR.php, (5) cat-EN.php, (6) cat-CYM.php, (7) checkout1-CYM.php, (8) checkout1-EN.php, (9) checkout1-FR.php, (10) prod-CYM.php, (11) prod-EN.php, and (12) prod-FR.php in inc/.

Multiple PHP remote file inclusion vulnerabilities in Seagull 0.6.7 allow remote attackers to execute arbitrary PHP code via a URL in the includeFile parameter to (1) Config/Container.php and (2) HTML/QuickForm.php in fog/lib/pear/, the (3) driverpath parameter to fog/lib/pear/DB/NestedSet.php, and the (4) path parameter to fog/lib/pear/DB/NestedSet/Output.php.

Cross-site scripting (XSS) vulnerability in ajax.php in Wiccle Web Builder (WWB) 1.00 and 1.0.1 allows remote attackers to inject arbitrary web script or HTML via the post_text parameter in a site custom_search action to index.php. NOTE: some of these details are obtained from third party information.

SQL injection vulnerability in index.php in GaleriaSHQIP 1.0, when magic_quotes_gpc is disabled, allows remote attackers to execute arbitrary SQL commands via the album_id parameter. NOTE: some of these details are obtained from third party information.

Multiple PHP remote file inclusion vulnerabilities in DiY-CMS 1.0 allow remote attackers to execute arbitrary PHP code via a URL in the (1) lang parameter to modules/guestbook/blocks/control.block.php, (2) main_module parameter to index.php, and (3) getFile parameter to includes/general.functions.php.