Description: Look up the parameter in the RBL given as parameter. Parameter can be an IPv4 address, or a hostname.

Example:

SecRule REMOTE_ADDR "@rbl sc.surbl.org"

The OWASP ModSecurity CRS includes limited use of the @rbl operator within the optional_rules/modsecurity_crs_42_comments_spam.conf file:

#
# Comment spam is an attack against blogs, guestbooks, wikis and other types of
# interactive web sites that accept and display hyperlinks submitted by
# visitors. The spammers automatically post specially crafted random comments
# which include links that point to the spammer's web site. The links
# artificially increas the site's search engine ranking and may make the site
# more noticable in search results.
#

SecRule IP:PREVIOUS_RBL_CHECK "@eq 1" "phase:1,t:none,pass,nolog,skipAfter:END_RBL_LOOKUP"
 SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org" "phase:1,t:none,pass,nolog,auditlog,msg:'RBL Match for SPAM Source',tag:'AUTOMATION/MALICIOUS',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.automation_score=+%{tx.warning_anomaly_score},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var},setvar:ip.spammer=1,expirevar:ip.spammer=86400,setvar:ip.previous_rbl_check=1,expirevar:ip.previous_rbl_check=86400,skipAfter:END_RBL_CHECK"

 SecAction "phase:1.t:none,nolog,pass,setvar:ip.previous_rbl_check=1,expirevar:ip.previous_rbl_check=86400"
SecMarker END_RBL_LOOKUP

SecRule IP:SPAMMER "@eq 1" "phase:1,t:none,pass,nolog,auditlog,msg:'Request from Known SPAM Source (Previous RBL Match)',tag:'AUTOMATION/MALICIOUS',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.automation_score=+%{tx.warning_anomaly_score},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var}"

SecMarker END_RBL_CHECK

The goal of this ruleset is to run an @rbl check once for each IP address and then save the response in a TX variable for 1 day.  This is used to limit the number of @rbl lookups that the web server needs to do as there is a latency hit for executing the DNS queries.

Why use Real-time Blacklist Lookups anyways?   What we are talking about here is IP Reputation.  Has this client been identified as bad by other web sites?  It is sort of like the "No Fly" lists that the Department of Homeland Security makes available to airlines.  It is a method of sharing information about clients so that you can decided if you want to allow this client access to your site at all or perhaps treat them differently (such as with increased logging).  Real-time block lists (RBL) are community-based, central repositories for IP Reputation. RBLs are most commonly used to identify web-based comment spam. If you run a blog or user-forum site, wouldn't you like to know if the current client has already been identified as a spammer?

While @rbl is a useful feature, there is a caution with its usage - it is a severe performance hit and can cause increased latency for clients.  Whereas the @geoLookup operator accessed a local DB, @rbl checks occur in real-time over the network and utilize the DNS infrastructure.  For the same reason that most web admins disable real-time client resolution in logging, running a DNS lookup on each client request can cause severe delays.  

Here are a few recommended tips for using @rbl.

Implement a local caching DNS server like rbldnsd so that your @rbl checks issue DNS queries to the local system first.

Alternatively, you can use ModSecurity to save rbl responses in the IP persistent storage collection.  This is what the CRS modsecurity_crs_42_comment_spam.conf file does.  The persistent data is cached for 1 day.

Make sure that you choose your RBL carefully.  You not only want to ensure that the RBL category is appropriate for your site but also that the accuracy of the list is good.

With exploit code now freely available and being ported to numerous platforms (mobile phones, for example), Sony essentially faces an insurmountable task to suppress the information and distribution of devices at this point. So long as Sony can address the particular method employed to mod the console (i.e. specific USB capabilities) there is still scope for them to remove the ability to mod via a firmware update. A downside to this approach is that it could break the functionality of their own test jig, which achieves similar results and is used by authorised repairers on faulty consoles.

It didn't take very long for Sony to deliver their response, in the form of firmware version 3.42, which has been confirmed to prevent PSJailbreak and its variants from working. Now that the firmware update has been delivered, the exploit developers are either going to have to accept a console that can't access the PSN (given 3.42's status as a mandatory update), or find another means to gain control of the console.

This was pretty surprising to see:

Dear ePassporte Account Holders,

Please be advised that, at 12:00 PM PDT today, September 2, 2010, we were notified that effective immediately, Visa International has suspended our banking partner’s (St. Kitts Nevis Anguilla National Bank) ePassporte Visa program. The ePassporte e-Wallet program continues to be up and running, except funds cannot be transferred between your Visa Account and your e-Wallet. At this time ePassporte can no longer issue Visa Cards, and the ability for our Account Holders to make point of sale purchases and withdraw funds from ATMs has also been suspended.

At this time we do not know why this drastic action was taken by Visa. To us, it is unconscionable that such action would be taken without the opportunity for ePassporte to fully understand Visa’s reasons and to be able to take all steps necessary to keep our program running the way it has so successfully done for over 7 years. But that is what Visa has done.

As soon as we have more information we will be in contact with you.

In the meantime please be assured that your funds are safe.

We are very sorry for the short notice and apologize for any inconvenience this may cause. The ePassporte team is working diligently to rectify this situation.

We kindly ask you to bear with us while we work through this issue.

Please feel free to contact us via the message center or at our call center, should you have any questions, comments or concerns.

Thank You,
Christopher Mallick

Pretty amazing the did that all at once like that: leaving epassporte high and dry.

Since the dawn of our species (well 2005, if you want to be picky about it) t2 has been granting free admission to the elite of their kind, the winners of the t2 Challenges. Don’t be suckered in by all the cheap imitations out there, their snooze-fest la-di-da dog and pony shows, because t2 is back! And we’re pleased to announce the release of the
t2’10 Challenge!

Now is your chance to join the past elites ([t2.fi]) by winning free admission to this year’s t2’10 Infosec Conference!

This year’s t2’10 Challenge is based on multi-staging (much like good shell code), which will be powered by a scoreboard ([t2.fi]) so that you can see — (almost) in real time — how the other participants are fairing out there in the land of the living.

The rules are simple: t2 will release the t2’10 Challenge and the first one to solve it will win free admission to the t2’10 Infosec Conference. But don’t stop just because you weren’t the first one to solve it: The Advisory Board will select another winner among the next ten correct answers, paying particular attention to the elegance of the solution rather than the speed. In other words you can win with either speed or style

The t2’10 Challenge will be released 2010-08-28 10:00 EEST at [t2.fi]

Good luck

UPDATE: A solution for the challenge has been posted, you can see it here: [t2.fi] or you attend the conference and talk to the winner for yourself

-

Let the experts make sure your website is safe. Vulnerability Assessment is the answer.

PDF based XSS isn’t a new concept, even Adobe considers PDFs to be active content.  With that said, I’m surprised at the number of web applications that allow users to upload PDFs and then serve those PDF’s inline as opposed to an attachment (although there are some gotchas with content-disposition attachment).  Serving a user supplied PDF inline essentially allows that user to execute arbitrary client side code from the domain serving the PDF.  The safer way to handle PDFs is to serve them with the content-disposition set to attachment.  An even better method is to serve the user controlled content from a separate domain.  This can be difficult for web content portals that are deployed internally like SharePoint, Outlook Web Access (OWA) and Oracle Web (all of which were affected by this bug) where the organization would have to write custom code and employ custom configurations to protect themselves from PDF based XSS exposures.  Serving PDFs with a content disposition set to attachment also creates usability issues as an ugly download warning will appear instead of the more friendly PDF content in the browser window behavior.

Although this particular bug was patched by Adobe a few months ago, there were a few things I learned that could possibly be used in other PDF bugs.  I’d like to share some of the more interesting items.

PDFs support  JavaScript from within the PDF.  Unfortunately, the script executed from within the PDF will not have access to the browsers DOM.  In order to gain access to the browser’s DOM, we have to use the PDF to redirect the browser to a JavaScript URI.  Normally, redirection to JavaScript URIs are blocked by the PDF security routines, however I discovered an easy bypass using octal encoding.  I place the JavaScript payload into an OpenAction for the PDF, using an octal encoded value (72) for the “:” character.  An example of the OpenAction is presented below:

%PDF-1.1
1 0 obj
<<
/Type /Catalog
/OpenAction <<
/S /URI
/IsMap false
/URI (javascript72alert(“FTW – “+document.domain))
>>

A super simple XSS with PDFs.  When the PDF is opened in the browser, it redirects the browser to a JavaScript URL allowing for XSS.  Mailing out a rigged PDF as an attachment to some friends using OWA would have been an interesting exercise as certain versions of OWA open PDF attachments inline.  Although I encoded the “:” character in the example above, any character in passed to the OpenAction can be encoded and Adobe Reader will handle it.  In fact, octal encoding can be used throughout the PDF in various scripts and actions.  For example, you could encode the entire protocol handler and it would still work:

/URI (11210112610112310312211112012472alert(document.domain))

You can even mix and match the encoding, making it extremely difficult for any signature based IDS to detect malicious payloads.

/URI (j101v101s103r111p12472alert(document.domain))

If you’re up against a security blacklist when attempting to exploit a PDF bug, try passing an octal encoded value for your payload.  This was the bug Adobe fixed with CVE-2010-0190

Like most browser plug-ins Adobe has implemented different security mechanisms for PDFs opened from the local file system and PDFs opened remotely.  It can be useful to determine whether the PDF was opened remotely or locally.  The following script returns an indication as to how the PDF was loaded.

//In the browser or loaded locally
if ( this.external )
{
// Viewing from a browser
}
else
{
// Viewing in the Acrobat application.
}

This can be useful if your exploit only works for locally loaded PDFs or maybe if your exploit only works for remotely loaded PDFs.

There can be situations where the user browses certain websites with one browser, but uses another browser as their default browser.  Adobe Acrobat Reader actually provides an API (I’m not sure if it’s intentional) to pass a URI to the default browser.

app.launchURL(“http://xs-sniper.com/”,true);

If a user calls app.launchURL and passes the “true” flag, the default browser is opened and handles the passed URI.  This can provide a bridge between two different browsers and can increase the reachable attack surface in some circumstances.  If the user is using the default browser to open the PDF, this can help bypass pop-up blockers.  You can test this by setting your default browser to IE and browsing the following PDF in FireFox.  PDF HERE

There was an excellent presentation at PacSec that covered a ton of PDF bugs and Didier Stevens always has interesting PDF stuff.  I hope this helps someone out there!  Happy hunting.

Looking ahead, the Women In Tech teleconference on September 15 includes TechCrunch CEO Heather Harde is on the “Female Ferocity” panel.  There’s the sold-out Grace Hopper Celebration of Women in Computing in Atlanta at the end of the month.  And late last week, Arrington tweeted that they were going to add an all-women panel to TechCrunch Disrupt to discuss “women’ issues”.*   So I suspect we’ll be hearing a lot more about this …

Hopefully as we move forward, as well a continued focus on the underlying issues and realities of structural biases against women and minorities, we’ll also see a lot more discussion about what people can do. Mary’s Where to after the required reading? on Geek Feminism asks for suggestions.  I’ve got a draft response in What each of us can do; feedback welcome.

In any case I thought it would be useful to collect the links to what’s been written so far.  It’s really striking how much good stuff there’s been on blogs and Twitter (I collected some of the tweets that caught my eye in various comments in another thread**) so hopefully the list it’ll be valuable to anybody else writing about it.

First though, in a comment that the Arrington’s of the world will no doubt dismiss as pandering, I’d like to take a moment and express my admiration for the women in technology who have been doing such great work to change the ratio.  The women I know who speak out on gender equity aren’t “whiners”, as they’re so often dismissed by people who don’t want to hear what they’re saying.   They’re remarkably successful despite the huge biases against them, and somehow manage to find time for diversity work in addition to having careers, friendships, and often families.

Of course they’re frustrated when privileged guys who clearly haven’t looked at the problem in any detail deny there’s a problem, attack women and allies, and disclaim responsibility — and who can blame them?  Despite that, though, they’re a remarkably positive group … and with good reason: they’ve invested a huge amount of time and effort here over the years and it’s really starting to pay off.

So kudos and respect to you all.  I’m impressed by what you’ve accomplished and proud to know you  And thanks, too: the technology world is a much more pleasant for your efforts!

And you know, stuff like this makes a big difference. There was a very encouraging episode late last week in response to Chiara Atik’s Guest of a Guest article on TechStars New York’s ratio of 46 male mentors and only two women. When Cindy Gallop brought it up on Twitter, David Tisch of TechStars quickly reached out.  Props  all around. More of this please!

Here now the links, in rough chronological order.  There’s also excellent discussion in the comments of many of these; I’ve also included “HN” links for the meta-discussions on Hacker News on some.  I’m sure I missed some — please tweet them to me at @jdp23 or leave ‘em in the comments.  Thanks as always!

jon

• Addressing the Lack of Women Running Tech Startups, Shira Ovide, Wall Street Journal
• Too Few Women In Tech? Stop Blaming The Men.  Or at least stop blaming me, Michael Arrington, TechCrunch. (HN)
• Stop Playing the Blame Game, Allyson Kapin, Fast Company
• “Too Few Women in Tech?”, Eva Smith, Tech.  Food.  Life.
• Nobody’s Blaming Anybody, Cindy Gallop, WIMN’s Voices
• Blame Sexism. Ivan Boothe, Rootwork
• Fretting, Asking, and Begging Isn’t a Plan, Jon Pincus, Liminal States, cross-posted on Feminism 2.0
• Arrington is completely wrong about women in technology, Laurie, Seldo.com (HN)
• My Challenge to Michael Arrington, Michelle Greer, michelle’s blog
• In Response to Michael Arrington’s “Too Few Women in Tech” article, Helena Stone, ChipChick
• The Lack of Tech Industry Diversity: One Year Later, Jeff Nolan, Venture Chronicles
• Women in Tech and Women Entrepeneurs Discussion, Fred Wilson, A VC
• More Women in Tech Discussions, Brad Feld, FeldThoughts
• Arrington: “Women Entrenepeneurs: Stop Blaming Men for Your Problems”, Alyson Shontel, Business Insider
• Women in Tech: What Gives?, Shefaly Yogendra
• How Anonymity Contributes to the Problem, Arvind Narayanan, 33 Bits
• A Realistic Look at the Numbers, Jolie O’Dell
• Getting More Women to Tech, Kay, Feministe
• Musing about Inclusion in Technology, JP Rangaswami, Confused of Calcutta
• TechCrunch Comments Fail: from STFU to “Female Supremecists”, clarley, Mavenity,
• What Do “Where are the Women” Sh*tstorms Achieve? Irin Carmon’s Jezebel.
• 5 Simple Ways to Help Women as Tech Leaders, Ja-Naé Duane’s
• 18 Reasons Your Company Might Be a Sausagefest, Jessica Wakeman
• Try Harder Isn’t an Answer, Jamelle Bouie, TAPPED
• On Influence, Lists, Women and the Confluence Thereof, K. Tempest Bradford, Geek Feminism
• There’s More than You Think, Terri, Geek Feminism
• A few things each of us can do (DRAFT), Jon Pincus, Liminal States
• Is There a Gender Divide in Startups?, Leah Culver, The Daily Beast
• “I  Could Keep Writing About the Lack of Women in Tech, but Starting a New Company Seems Like More Fun”,  Rachel Sklar, Change the Ratio
• My List of 30 Great Women, Don Dodge, The Next Big Thing
• Mindfulness is the Key to Finding Female Speakers, Geoff Livingston
• Douchebag Decree: Michael Arrington, Technological Determinist, Kelsey Wallace, Bitch
• Women in Tech: What to do Now?, Clara Byrne, Venture Beat
• Finding more women to speak at Ohio LinuxFest, Mackenzie, Geek Feminism
• We Aren’t Blaming Men , Aliza Sherman
• Stop Telling People How They Should Feel About It, Sasha Pasulka, Seattle 2.0
• Quick Thoughts, Leslie Poston, Uptown Uncorked
• Blame Men — And Women, Gayle Laakmann, Technology Woman
• Go Aliza.  Women in Tech do Blame Some Men, Eilieen Brown, Eileen’s Technology Blog
• “Ambient Un-belonging” , Audrey Watters, an/archivista (HN)
• Blogging and Mass Psychomanipulation, Michael Arrington, TechCrunch
• Not sure if I agree with this dude’s logic, Rachel Sklar, Change the Ratio
• Women in Tech, Men in Tech, and the Blame Game, Cameron Sorden, Digital Life
• Girls in Tech Debate: A Publicity Hoax?,  Ellie Cachette, Social Times
• An apologetic Mike Arrington, Paramendra Bhagat, Netizen
• What You Can(’t) Tell Just By Looking At Her, Tara Hunt, HorsePigCow
• Ratio: Changing, Rachel Sklar, Change the Ratio
• Why We Don’t Need more Women in Tech … Yet, Jolie O’Dell
• women, entrepeneurs, and tech, Emma Persky

* see @navarrowwright, @nakisnakis, and @randomdeanna for some points on the TC Disrupt panel

** including Arrington snarking at me if you read far enough down

As we battle Ithaqua.

Best.  Burn Night.  Ever.

for D, September 2010

We didn’t go to Burning Man this year.  Who knows, maybe next year.  Instead we observed burn night in our own way, by having spaghetti, playing Arkham Horror, and drinking champagne.  We lost three of five investigators but in the end Roland and Patrice barely took Ithaqua out in the final battle.  What a great night.   And a fine weekend, too!

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.

I often find myself thinking about egyp7’s DefCon speech last year. He was talking about browser autopwn, which was a relatively new concept at that time being built into Metasploit. Pretty cool technology, and with only one minor mishap he was able to demonstrate it on stage with impressive results. That’s all well and fine, and you should check it out, but one thing stuck out from the presentation more than the technology itself.

By doing variable detection he could find out everything down to the individual patch level of the device in most cases. Of course a bad guy can mess with these variables and lie, which egyp7 admitted to. But, wisely he said something to the effect that if you find a browser that is lying about it’s user agent, you probably have found yourself a browser hacker, and you don’t want to try to be owning his browser anyway. Once you find yourself in this condition, bail. The idea mirrors a lot of the type of stuff I wrote about in Detecting Malice. By identifying the signature of browsers and how people navigate sites you can know a lot about your potential adversary. Either for good or, in the case of autopwn, evil. Growing this signature database over time could be very useful as attention on browser exploitation increases and the need for understanding user traffic and intent grows.

In it, we get a picture of the Babylonian’s laws and punishments. In particular, there’s this one:

If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death.(Another variant of this is, If the owner’s son dies, then the builder’s son shall be put to death.)

(Source: Wikipedia)

So essentially, this is one of the earliest building codes. Pretty harsh, but you know…

What this means is that only qualified builders prepared to take the risk of death built houses. This obviously focuses the mind.

In our industry, we have hobbiests and self-taught folks working side by side with software engineers and computer scientists, but they usually share one thing in common: they know nothing of security.

This is like an accountant graduating without knowledge of auditing principles or GAAP. It’s exactly like a civil engineer being unaware of load stresses and envioronmental factors necessary that require safety and tolerances to be built into every structure.

When the average person goes to a builder or architect, and asks for a house to be built, we expect them to know how to build the two or three story building such that it not only complies with minimum code requirements, but that it will not collapse. When they do, we strike those builders off the master builder’s register and they can no longer build homes. We can sue them for gross negligence.

When the average small company does their books, they expect the accountants they hire to know how to do double entry book keeping, and be aware of local, state and federal tax rules. When they fail to do so, they lose their CPA accreditation and we can sue them for gross negligence.

When a city or state wants to build a new bridge, they expect the winning tenderer to design the bridge to last for the expected period of time, satisfy all state and federal road and safety laws, and obtained specialist advice for key elements of constructions, such as wind tunnel tests. If the bridge falls down, this is usually the end for that building group and they are sued out of existence.

Why is so different in our field? What we do is not art. SQL injection is so utterly preventable and has been for over 10 years that I truly believe it is gross negligence to have injectable code in any running code today.

There is a huge difference between using MYOB to run a small business and building a cubby house. Yet this is all 99.9% of all developers are capable of today. They lack the most basic awareness of software security, the only key non-functional requirement of all software – from games through national treasury finance systems.

Efforts like Rugged Software and OWASP are vital. We must get out to Universities and employers and make sure that security is taught and that all IT, CS, and software engineering graduates have done at lease one 13 week subject on it, and make it the easiest possible path to major in software security. We must get out to employers and make sure they require all new hires to know about it and be able to code for it. Moreover, if they buy off the shelf software, we must get them to include clauses in contracts, such as the OWASP Secure Software Contract Annex to protect themselves from gross negligence such as SQL injection or XSS. We must reach out to frameworks and make them utterly aware that what they do affects millions of developers and they simply must be better at security than everyone else.

It’s time for the software industry to grow up, realize that fortunes, privacy and lives really are at risk, and we’re doing a repeatable engineering process, and not some black art. We have to have consequences.

A year or so ago I went to go visit the Intel guys at their internal conference that they throw (similar to Microsoft’s Bluehat). I honestly had no idea what to tell a bunch of hardware guys. What correlation does chip manufacturing really have with browsers or webapps. Well virtualization and malware certainly, but what else? It got me thinking… one of the things they are in direct control over is how fast operating systems (and subsequently browsers) work. I talked it over with id before going out there. Faster is better right?

I’ve got mixed feelings about fast vs slow browsers. When something is slow, you can actually detect that something strange is going on. It’s also easier to stop it from mis-behaving if an attack takes a while. When it’s fast, it’s much harder to notice that your computer had to chug for a while to do something complex and much less likely that a user can intervene. There have been a number of exploits out there that have really been proof of concept only. They’re deemed not practical because they take too long, or hang the browser temporarily while they’re being executed. If the speed barrier is removed, then suddenly those old proof of concepts (think res:// timing attacks and so on) are actually much easier to perform. So while I think innovation and performance improvement is a good thing overall, it does come with some unintended consequences.

I got an email last night from someone asking me to do a breakdown of which browser is better, Internet Explorer, Firefox, Opera, Safari and Chrome. First of all, there’s already a pretty good reference that Michal Zalewski put together. Like anything this comprehensive, since it’s not been edited for about half a year it’s already out of date in a few ways, but it’s a great place to get started for those who want to get familiar with the internal differences between various browsers. No need to re-invent the wheel, go read it. Now, that’s the purely technical side, but there is one thing that’s wildly missing from most documents that talk about browser security.

Browser security often turns into a religious war amongst technologists, instead of thinking about it pragmatically. What are the real motives of the companies that are developing the browsers? In most cases they care primarily about market share because market share makes them money (through search engine agreements, and so on). So now you have to think about yourself and your needs. What kind of user are you? I tend to be a very security conscious person, and if you’re reading this you probably are too. I’m willing to severely degrade my usability for an increase in security, whereas most users are not. So the browser I will tend towards is one that offers me the flexibility to make those decisions for myself while still giving me enough usability to be able to do anything I need to do, when I decide to. This is why Firefox has been my personal browser of choice for years - but don’t be confused and think it’s because I think Firefox is more secure out of the box. Firefox has just as many flaws as other browsers, by default.

While security people’s needs are important, if you look at the number of people who are security folks compared to the rest of the world, we are insignificant as a percentage. That means that it is not in the browser company’s interest to focus on appeasing security people. Sure, it’s nice to have a browser that is secure, but that’s not ever going to drive the volume of users necessary to make the real revenue for their organizations - or at least that’s what the market seems to be proving. Plus most of the major browsers above tout themselves as being more secure than their competitors - so normal consumers don’t know who to believe. As such, while I think all the major browsers mentioned above have their pros and cons, none of them are designed with security first. They’re designed for a different set of users in mind (which includes security people, but it also includes our grandmas, and tweens and cousin Cletus), and that puts browser design choices somewhat at odds with security, because what does Cletus care or know about security? So that’s where plugins, addons, sandboxes, VMs, etc… come into play. It’s like wearing a condom around your browser, if you like. It gives us the ability to use the same underlying product while still protecting ourselves as much as possible.

I honestly think most browsers can be made to be very secure, if you’re willing to sacrifice all usability - not completely secure, no doubt, but far more secure than any of the major browsers above ship by default. So, it’s a little hard for me to play favorites. They each have their own security mess to clean up, so currently there is no good solution, and I don’t recommend any browsers to anyone (although you people still on IE6 really should upgrade already). The work involved in really securing your browser simply isn’t worth explaining to most people. In fact, “which browser do you use” is my least favorite question, because it’s not as simple as a single word. Boutique browsers, while interesting, don’t often have the support behind them to make them useful for a lot of the more common applications (lacking vast plugin support, etc…) although of anyone, they actually could align themselves nicely with the needs of security people. So, while I think browser security is often about minutia, we need to fully grasp the market forces at work before getting completely fed up by a constant string of functionality that only makes it less secure, instead of expecting dramatic security improvements. Or we need to pick something more obscure and assume the risks involved with a product that is not tried and true. It’s not an easy problem for us or the browser companies - I don’t envy their situation.

For those who may be unfamiliar with the tool, EMET provides users with the ability to deploy security mitigation technologies to arbitrary applications.  This helps prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited.  By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products.  In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor.

Below is a screenshot of the tool, which features a brand new interface as part of this release.

The installation package for EMET v2.0 includes a detailed user guide.  A copy can also be found at the bottom of this post.  It gives an overview of the tool, instructions on how to use it, answers to frequently asked questions, and caveats about the mitigations that users should be aware of.  Please be sure to read the guide before using the tool.

Additionally, the BlueHat team has helped us put together a training video on EMET v2.0.  The video gives an even more in-depth look at some of the security mitigations offered by the tool.  You can watch the video online here.

To get more information on how this FREE tool can help you take advantage of the protections it offers please refer to our previous blog post announcing the upcoming release.  That post also gives a rundown of all the changes that are new with the 2.0 version.

As always, we welcome your feedback and would like to hear more about your experiences with EMET.  Please feel free to e-mail us at switech@microsoft.com

- Andrew Roths and Fermin J. Serna

I have long been a fan of card games. During lunch breaks at work, my co-workers and I would often play such games to pass the time and socialize. I found myself thinking that this activity could not be unique to my office; countless others out there undoubtedly have similar routines. It occurred to me that there must be a way to harness this social gathering at work and turn it into a fun learning experience built around what I know best – software assurance and software security. After all, if people are going to play a card game, why not play one that can help ingrain the very ideas that Cigital has been trying to expound on for over a decade?

So I began designing Remediation, a card game that pits web application companies focused on generating revenue against the threat of malicious users focused on negatively impacting that revenue for their own nefarious motives. This is the very scenario that we encounter at Cigital on a regular basis and a theme that can easily transcend the commercial world and find relevance within the Federal space… an area of particular interest to me due to my work with the Application Software Assurance Center of Excellence (ASACoE) for the US Air Force.

Remediation has players compete to end up with the highest score while playing through real life software security scenarios. While taking on the role of either a company or a malicious user, the players take turns with the ultimate goal of playing the most revenue cards. The malicious users attack the company players with exploit cards, a SQL Injection attack for example, and score points in the form of revenue that the company loses by having their web application taken offline. The company players will then play cards, like a Database Restore, to recover from these attacks so their web applications return online and generate revenue for their own scores. Additionally, the company players can choose to spend some of that gained revenue to play cards that represent an investment into advanced security techniques that can prevent specific attacks against their applications, such as the game’s namesake, a Vulnerability Remediation card. At its heart, Remediation conceptualizes how various exploits could affect a web application and what measures would need to be taken in order to recover from these situations.

With its focus on software security themed gameplay, one of the primary goals for Remediation is for it to be useful as an educational tool. In today’s increasingly web-centric environment, it is more important than ever for developers to be able to think like an attacker and stay one step ahead of the threats that plague web applications every day; this game is designed to instill that mindset by presenting specific examples of how an attacker might target a system. As for managers, it is absolutely vital to understand how these risks might affect the successful conduction of business; the game works on this level by not only showing how these types of attacks can harm a company, but also how Cigital’s service offerings can help protect against these threats. By mirroring real life situations, Remediation strives to impart crucial skills that will help improve the players’ real world security posture outside the game.

Of course an additional goal would be to have a fun game with replay value so that the game could have a life of its own and introduce future players down the road to software security and how Cigital fits into this picture. Email us at remediationthegame@cigital.com if you’re interested in getting a copy of the game for yourself.

So Pyloris doesn’t work particularly well for port exhaustion on the server, but what if we can exhaust the connections on the client to better meter out traffic? That would make it easier for a MITM to see each individual request if it worked. So I started down a rather complicated path of using a mess load of link tags on an HTTP website trying to affect the connections on the HTTPS version of the same domain. No joy. It turns out that the limits placed on one port don’t affect what happens on another (at least in Firefox). So while I can exhaust all the connections to a domain over a single port I can’t do anything using HTTPS - or so it seemed (unless I was willing to muddy the water further by sending a bunch of requests that I knew are a certain size to the HTTPS site - which just seemed more painful than helpful).

Then, based on some earlier research I stormed into id’s office and I started bitching that there was no point in trying to stop port exhaustion if they were going to allow tons of connections, just over multiple sockets anyway. As the words came out of my mouth I realized I had come up with the answer - a ton of webservers. I guessed that there must be some upper bound of outbound connections and it’s probably at or less than 130. You should have seen id’s face as I asked him to set up 130 connections / 6 connections per socket = 22 web-servers for me. Hahah… I thought he’d kill me.

It turns out it’s nowhere near 130 open connections. Firefox sets a rather arbitrary 30 connection limit. So if you can create 5 open web-servers and exhaust 30 connections and only free up one long enough to allow the victim to download one request at a time, I think we’re in business. Makes sense in theory. The problem is that it’s REALLLLY slow. I mean… painful. In my testing it seemed more like the server was broken entirely from the victim’s perspective. But eventually… and in some cases I mean minutes later - it would load. I’m sure that the attack could be optimized to work based on the fact that no more packets are being sent when the image gets downloaded or whatever… which would signal the program to free up a connection. This is opposed to my crapola time based solution combined with chunked encoding to force the connection to stay open without downloading anything that I came up with for testing. So I bet this attack could work if someone put some tender loving care into it, but it was kind of a huge waste of time for me personally - and for poor id.

Incidentally, for those who have never seen or met id, and would like to know a little about the other side of webappsec that I don’t talk about much here (the configuration, operating system and network), you’re chance is nearing. There’s a rumor that he’ll be speaking at Lascon in October. He’ll be talking on how he’s managed to secure ha.ckers.org for all these years despite how much of a target I’ve made it. Should be fun.

Pyloris is a python version of Slowloris, and since it is written in python it’s SSL version is thread safe. So what better way to lock up an SSL/TLS Apache install (given that Apache still hasn’t fixed their DoS)? Well, one of the big problems attackers have when trying to decipher SSL/TLS traffic is the fact that browsers not only send a lot of request down a single connection but they also connect use a bunch of open connections over separate sockets. What if we could use pyloris to exhaust all but one open socket?

Well it turns out that while this sorta works, there are a lot of issues with the concept. Firstly, it requires Apache. Secondly the server can’t be using a load balancer (assuming the load balancer isn’t using Apache itself). Thirdly it requires that there are no other users on the system or there will be a seriously annoying user experience for the poor victim who can’t reach the site that the man in the middle is trying to decipher traffic from. Alas… So while this didn’t work particularly well in my testing, I’m certain with more thinking someone can figure out a way to do this.

If you’re familiar with XSHM this is going to look awfully similar (but better). When a script creates a new popup (or tab) it retains control over where to send it at a later date. I talked about this concept before. But let’s see what else can be done. What if the attacker uses the history.length function to calculate how many pages a user has visited after they left the tab for wherever they landed. The attacker could do something like this:

a.location = 'data:text/html;utf-8,<script>alert(history.length);history.go(-1);</script>';

By setting either a recursive setTimeout or using some manual polling mechanism, the attacker can (in this case) cause a popup which monitors how many pages they’ve gone. Normally it wouldn’t cause a popup, the attacker would redirect to another domain that they had access to which would do the same history.length check. Voila. The user only sees a brief white flash and then the same page they were just on - as if nothing happened. They’d probably just think their browser is messing up again. This could be helpful in a number of esoteric situations where the number of pages visited may change, or you may want to force them through several flows (and back and forth again) all with a single mouse click - giving you authority to popup in the first place. The best part is that this will follow them while they surf for as long as both windows stay open.

While thinking about the previous issue and listening to Jeremiah’s preso and talking with the guys at Microsoft I got to thinking about cookie clobbering. Let’s say that Microsoft thinks HTTP cookies overwriting secure cookies is a big enough problem to fix. Let’s walk through the use cases. Let’s say there is a separate place for secure cookies that can’t be overwritten by non-secure cookies. Does that mean two cookies are replayed in HTTPS space, or that the HTTPS cookie always wins? Okay… let’s say it wins and the secure flag cookie cookie is the only one sent. Well let’s not forget about Jer’s cookie clobbering script.

When an attacker forces overwriting of the cookie jar, they get the exact same effect. Now the victim has no cookies secure or otherwise if the global cookie jar stays the same size and it remains a LIFO system. So now you’re saying, well the attacker can just use a SSL/TLS enabled cookie clobbering scripts - you’re right! So now there has to be a per-site container… or something - and doesn’t that completely defeat the purpose of the upper limits on cookies anyway? Now DoS conditions become an issue with overwriting the disc with tons of huge cookies, and so on. Anyway… this probably needs a lot more thought, and I’m certainly not advocating “fixing” this, just to end up with a worse situation than we already have. But certainly secure cookies shouldn’t be clobbered by HTTP cookies - in my opinion.

It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.

When I told one of my guys about the double DNS rebinding attack, he said, “Well it’s a good thing I use perspectives.” So that was my clue that I had better get familiar with the plugin if people are seriously relying on it for security. In the process we found a number of potential issues. For those of you who aren’t super clued in about this tool it was originally designed to handle situations where governments are tapping people using things like Packet Forensics where a valid certificate authority is being used to man in the middle someone or a group of individuals.

First of all it’s easy to detect perspectives for a man in the middle. Perspectives sends a lot of HTTP traffic, which the attacker can easily read and figure out is related to perspectives. That may not seem important, because if an attacker knows that a user has it installed what can they really do? We’ll come back to this.

Embedded content is not verified by perspectives, only the parent window. Because most websites (even HTTPS) use third party service providers, caching servers or whatever for static content, the attacker will simply MitM’s the “static” servers serving up CSS, JavaScript or objects that are dynamic content once rendered. By modifying the response and including active content, anything that can be seen by the DOM is still accessible to the man in the middle. Kinda defeats the purpose of perspectives…

Using the fact that an attacker knows that someone is using perspectives (which they can determine by forcing someone through an SSL/TLS link), the attacker can simply MITM only the embedded content. Of course there are changes a user can make to the settings and options to reduce this risk, but like all options, they’re probably not changed often and the defaults really aren’t good.

Lastly, I tried perspectives against the double DNS rebinding issue, and unfortunately instead of the huge pop-down that would actually alert someone to the problem, because the attack uses a valid cert from a nearby sub-domain that perspectives has probably seen before it only gives the small warning that most people probably wouldn’t notice unless they were really paying attention.

One of the issues Josh and I talked about at Blackhat was how the SSL certificate warning message can be used to gain information about a user’s behavior and how that can be used against the user. Let’s say a man in the middle causes an error via proxying a well-known owner/subsidiary. For example let’s say https://www.youtube.com/ which most technical people know belongs to Google and which, incidentally causes SSL/TLS mismatch errors because it’s mis-configured. Experts who see such an error and investigate will think it’s just a dumb (innocent) error. Non-experts will click through immediately, because they always do when they see such things.

By measuring the wait time the attacker can know which type of user the victim is - a technical one, or a novice. If the user is a novice the attacker knows they don’t have to worry anymore - they can deliver their snake oil cert later if the user goes through it “quickly” because that user’s behavior will most likely stay the same. Of course figuring out the timing might be a bit tricky because really new users will be awfully confused by cert warnings and will seem “slow” I’d bet. Anyway, something to investigate further.

It’s a numbers game. There are far fewer women in tech than men. So anyone genuinely interested in changing the ratio and evening out the balance, has to more than meet women halfway …

– Cindy Gallop in No One’s Blaming Anyone on WIMN’s Voices

Shira Ovide’s Wall Street Journal article Addressing the Lack of Women Running Tech Startups kicked off the latest women-in-technology firestorm, and Michael Arrington’s TechCrunch rant  Too Few Women In Tech? Stop Blaming The Men.  Or at least stop blaming me sent it into overdrive.   The list of 30+ links on Liminal States includes views from the Seattle area community in Sasha Pasulka’s excellent Stop Telling People How They Should Feel About It on Seattle 2.0, Cameron Sorden’s Women in Tech, Men in Tech, and the Blame Game and my own  Fretting, Asking, and Begging Isn’t a Plan.

Good stuff!

One consistent theme in the responses to Arrington’s post is that blame isn’t helpful.  The underlying causes of gender inequity and other diversity problems in the tech industry are complex, including education, cultural norms, the advantages of the “old boys club”, and sexism.*    Most people I talk to, no matter what their gender, agree that it would be a better if the industry and their organization were more balanced.**

So how to make progress?  Here are a few things each of us can do:

• Mentor women (suggested by Ja-Naé Duane in 5 Simple Ways to Help Women as Tech Leaders).  Finding good mentors is a huge challenge for women, and Elizabeth Stark’s The Gender Gap in Tech: Why Mentors Matter describes why it’s so important.
• Reach out when you’re hiring.  The Geek Feminism Wiki’s resource page is a good starting point for this. At my most recent startup, we made sure to get our job descriptions  reviewed by women and diversity experts to make sure they were equally inviting to women, and routinely posted them on Digital Eve Seattle as well as other lists.  And if any angels and VCs happen to be reading this, please pay attention: you’re in a uniquely leveraged position to encourage diversity, so please work towards having a diverse team yourselves as well as encouraging diversity in your companies.
• Reach out even when you’re not hiring.  Allyson Kapin (aka @WomenWhoTech) and Aliza Sherman both list some of the many organizations working in this space: Anita Borg Institute, She’s Geeky, Women Who Tech, National Women of Color Technology Conference, Women 2.0, Girls in Tech, Astia, Pipeline Women ….  In Seattle, there’s TechMavens and the Professional Women of Color Network as well as Digital Eve.  Get involved with them.  If you’re looking for expert speakers at a conference or event, they’ve got plenty of good resources.  And don’t forget Twitter; follow hashtags like  #geekfeminism, #womaninnovator, and #fem2 and RT stuff you think people will find interesting.
• Get out of your cultural cocoon (as suggested by Carol Tran of  Chic Meets Geek in this excellent  video).  Shireen Mitchell points out that using social media to diversify your online network is only the first step; real world connections matter a lot too.  Last month I went to a CRAVE Seattle networking event, and got to experience the role reversal of being one of only two guys in a room and realizing that everybody was looking at me and wondering what I was doing there — and met a bunch of people I never would have otherwise.
• Mention women, not just men:*** track the ratio of men to women that you mention in your email, blog posts, tweets, or “top 25″ lists “.  Is it lopsided?  As K. Tempest Bradford describes on Geek Feminism, it can happen easily enough: “when measuring the nebulous concept of ‘influence’ a lot of gut decisions are made that have more to do with personal perceptions than other factors.”  If so, look for ways to bring balance.  If you’re giving out awards, look at your committee: if they’re 80% male, then you probably won’t have a lot of women finalists and winners.

Of course, these only scratch the tip of the iceberg.  There are plenty more good suggestions in the articles and sites I link to above — and please drop your own in the comments!

jon

* Vivek Wadhwa’s Silicon Valley: You and Some of Your VC’s have a Gender Problem, Janine de Nysschen’s Why Men Get VC Money and Women Don’t….and How that is Changing, and the definitive women in CS/STEM thread on Geek Feminism have a lot of data, and if you’re not familiar with the issue are great starting points.

** Although if you’re an entrepeneur or investor reading this and don’t think diversity matters for you, I’d encourage you to think again.  As Clara Byrne notes on VentureBeat, female employees and co-founders are a competitive advantage; on TechCrunch Europe, Inmaculada Martinez goes into more detail in It’s time to hire more women in startups – your products deserve it. .  Paying attention to diversity — gender, race, age, and all the other dimensions — opens new opportunities, broadens your hiring pool and investment options, helps you avoid blind spots, and results in products that are more appealing to everybody.   It’s getting harder and harder to deny there’s a problem, and that the advantages moving ahead will go to those who address it most quickly.

*** For more on this, see Shelley Powers’ Guys don’t link,  Susan Herring et al’s Women and children last: the discursive construction of Weblogs.  And as always, look for similar patterns — and take similar steps to improve the situation — with other dimensions of diversity like race and age as well.

Jon Pincus is a Seattle-area strategist, writer, and activist, currently volunteering for NWEN and co-chairing the First Look Forum with Rochelle Whelan.

Today we wanted to provide an update by answering several questions we have received from customers and addressing common misperceptions about the risk posed by this class of vulnerability.

• The user experience of the exploit in progress
• The dangers of untrusted, Internet-zone WebDAV
• Enabling the CWDIllegalInDllSearch protection tool

The user experience of the exploit in progress

This class of vulnerabilities does not enable a “driveby” or “browse-and-get-owned” 0-click attack. To be exploited, a victim would need to browse to a malicious WebDAV server or a malicious SMB server and double-click a file in the Windows Explorer window that the malicious server displays. Let’s walk through an example of what an attack might look like:

First, the user browses to a malicious website:

The website would then attempt to display a new Windows Explorer window that points to a malicious WebDAV or SMB share. On systems running Protected Mode, Internet Explorer will require user consent to launch Windows Explorer, using a security warning like the one below. Protected Mode is enabled by default for Internet Explorer on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

After the user allows Windows Explorer to launch (or if they have previously requested that Internet Explorer no longer display this warning), the user will be presented with a Windows Explorer dialog that is likely to look like the one below:

At this point, if the user were to double-click the data file on the share, the affected application could potentially run attacker code that is separately hosted on the same WebDAV server.

The dangers of untrusted, Internet-zone WebDAV

As described above, this class of vulnerabilities could allow malicious code to run if an attacker can convince a victim to do the following:

• Browse to a malicious, untrusted WebDAV server in the Internet Zone; and
• Double-click a file that appears by its extension and icon to be safe

Unfortunately, based on attack patterns we have seen in recent years, we believe it is no longer safe to browse to a malicious, untrusted WebDAV server in the Internet Zone and double-click on any type of files. Attackers are clever, substituting dangerous file icons with safe, trusted file icons. They have even recently begun obfuscating the filename based on character encoding tricks (such as right-to-left character encoding). Their goal is to entice unsuspecting users into double-clicking on a malicious executable. With or without this new remote vector to the DLL Preloading issue, it’s very hard to make a trust decision given the amount of control an attacker has over the malicious WebDAV server browsing experience. We recommend users only double-click on file icons from WebDAV shares known to be trusted, safe, and not under the control of a malicious attacker.

Enabling the CWDIllegalInDllSearch protection tool

We have received several questions regarding the best way to enable the protection tool released on the Microsoft Download Center last week.

First, you should know that downloading and installing the tool alone will not protect a workstation from vulnerable applications. It ships “off-by-default” and must be enabled either system-wide or for specific applications. After releasing this tool, we received a number of questions on how best to deploy it. We have now updated the KB article to address them. We encourage you to review the updated knowledge base article 2264107.

Secondly, customers have asked us to recommend the best setting among the three choices. We recommend one of two settings, depending on the specific risk about which you are concerned.

• Setting the CWDIllegalInDllSearch regkey to 2 system-wide will completely block any network-based attack. We’ve built an automated Fix-it solution to enable that. You can click the Fix-it graphic below on systems that have already installed the tool to set CWDIllegalInDllSearch = 2, blocking DLL loads from the current working directory for both WebDAV and SMB except in cases where the application is run from a WebDAV or SMB share.

Note: The Fix-it itself does not install the workaround tool. You’ll need to separately download and install the tool beforehand.

• To instead completely block all DLL-preloading attack vectors, including the threat of malicious files on a USB thumb drive or files arriving via email as a ZIP attachment, set CWDIllegalInDllSearch to 0xFFFFFFFF. This will address any DLL preloading vulnerabilities that may exist in applications running on your system. However, it may have some unintended consequences for applications that require this behavior, so we do recommend thorough testing.

This section option can be enabled by following these steps:

• Install the tool from KB2264107.
• Log on to your computer as an administrator.
• Open Registry Editor.
• Locate and then click the following registry subkey: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager
• Right-click Session Manager, point to New, and then click Dword Value.
• Type CWDIllegalInDllSearch, and then click Modify.
• In the Value data box, type 0xFFFFFFFF, and then click OK.

While the impact of the above change seems to be low, a reader of this blog wrote in that he experienced a compatibility issue with the Outlook 2002 address book. If you experience issues such as this, they can be mitigated by setting a special policy for the affected binaries that overrides the default CWDIllegalInDllSearch. The following steps show how to do this for OUTLOOK.EXE:

• Log on to your computer as an administrator.
• Open Registry Editor.
• Locate and then click the following registry subkey: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionImage File Execution OptionsOUTLOOK.EXE
• If a key with the application binary name does not exist, then you will have to create one.
• Right-click OUTLOOK.EXE, point to New, and then click Dword Value.
• Type CWDIllegalInDllSearch,and then click Modify.
• In the Value data box, type 2, and then click OK.

This will still prevent OUTLOOK.EXE from loading DLL’s from a remote network share or WebDAV location, but it does not remove CWD from the library search path for this application altogether. This process can be repeated for all other applications that may no longer work correctly. As discussed, we don’t believe this will be common, but we do recommend testing.

Thanks for your interest in this issue. Please send questions in to switech@microsoft.com.

Jonathan Ness, MSRC Engineering
Maarten Van Horenbeeck, MSRC Program Manager

*Posting is provided "AS IS" with no warranties, and confers no rights.*

This excerpt is taken from the updated Reference Manual section of Ivan Ristic's book ModSecurity Handbook.

Transformation functions are used to alter input data before it is used in matching (i.e., operator execution). The input data is never modified, actually—whenever you request a trans- formation function to be used, ModSecurity will create a copy of the data, transform it, and then run the operator against the result.

Note

There are no default transformation functions, as there were in the first generation of ModSecurity (1.x).

In the following example, the request parameter values are converted to lowercase before matching:

SecRule ARGS "xp_cmdshell" "t:lowercase"

Multiple transformation actions can be used in the same rule, forming a transformation pipeline. The transformations will be performed in the order in which they appear in the rule.

In most cases, the order in which transformations are performed is very important. In the following example, a series of transformation functions is performed to counter evasion. Per- forming the transformations in any other order would allow a skillful attacker to evade detection:

SecRule ARGS "(asfunction|javascript|vbscript|data|mocha|livescript):"  

"t:none,t:htmlEntityDecode,t:lowercase,t:removeNulls,t:removeWhitespace"

Warning

It is currently possible to use SecDefaultAction to specify a default list of transfor- mation functions, which will be applied to all rules that follow the SecDefaultAction directive. However, this practice is not recommended, because it means that mistakes are very easy to make. It is recommended that you always specify the transformation functions that are needed by a particular rule, starting the list with t:none (which clears the possibly inherited transformation functions).

The OWASP ModSecurity CRS makes extensive use of transformation functions.  Each rule applies a specific transformation pipeline that was developed from user feedback and testing and aims to avoid false negative issues.  The following example rule is taken from the modsecurity_crs_41_sql_injection.conf file:

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "bunionb.{1,100}?bselectb" 
 "phase:2,rev:'2.0.8',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'SQL Injection Attack',id:'959047',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

The goal of this transformation pipeline is to try and counter-act typical evasion attempts that are used by SQL Injection attacks (which we describe more in depth in the following section).

Why are transformation functions so important?  One word - EVASIONS.  We have blogged about the term Impedance Mismatch many times in the past.  The issue is that there are many ways in which an attacker may be able to alter the format of an inbound payload, so that it may not match an input validation filtering scheme, however it is still functionally equivalent code and will be executed by the back-end application.

Example SQL Injection Evasion Techniques:

delete from -- lowercase

DELETE FROM -- upper-case

deLeTe fRoM -- mixed-case

Delete From -- more than 1 space between keywords

DELETEtFROM -- t represents a TAB character

DELETE/* random data */ FROM -- use of SQL Comments

Let's take a look at an example SQL Injection attack payload:

http://localhost/vulnerable_app.php?foo=1'%20UniOn%09(/*blah%20blah%20blah*/SeLeCt%20%20%20%20%20%20%20'1','2',PASSword%20from%20USERS)%20--%20-a

This payload has a number of the same evasion techniques described in the previous section.  Let's take a look at the modsecurity debug log (set to level 9) and see how the transformation pipeline used in CRS rule id 959047 handles the payload:

[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) urlDecodeUni: "1' UniOnt(/*blah blah blah*/SeLeCt '1','2',PASSword from USERS) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) htmlEntityDecode: "1' UniOnt(/*blah blah blah*/SeLeCt '1','2',PASSword from USERS) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) lowercase: "1' uniont(/*blah blah blah*/select '1','2',password from users) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) replaceComments: "1' uniont( select '1','2',password from users) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) compressWhitespace: "1' union ( select '1','2',password from users) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][4] Transformation completed in 36 usec.
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against ARGS:foo.
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] Target value: "1' union ( select '1','2',password from users) -- -a"

As you can see from the debug_log, the ARGS:foo parameter payload data was normalized to remove the evasion techniques before the payload was inspected by the @rx operator.

While transformation pipelines work fairly well at identifying most evasion attacks, they are by no means perfect.  In fact, attackers may abuse the fact that ModSecurity only applies the specified operator only once, at the end of the transformation pipeline.  Here is an example attack payload that indeed evaded previous versions of the CRS which were only inspecting more generic payloads such as REQUEST_URI:

http://localhost/vulnerable_app.php?foo=%2f*&bar=%E2%80%98+UNION+SELECT+*+FROM+user+%26%23x2f*

The evasion trick this payload is attempting is to spread the SQL C-style comment across multiple parameter payloads.  Let's look at how the previous CRS rule would have processed this REQUEST_URI payload and applied the transformation pipeline:

[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) urlDecodeUni: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) htmlEntityDecode: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) lowercase: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 union select * from user /*"
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) replaceComments: "/vulnerable_app.php?foo= "
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) compressWhitespace: "/vulnerable_app.php?foo= "

Opps... As you can see, once the replaceComments transformation function is applied, it effectively removes the SQLi payload before the operator is applied.  This is a perfect example of Impedance Mismatch, were the WAF is normalizing data in a different way as the target application.

So, how do we combat this evasion issue?

By default, operators are only applied once after the entire transformation pipeline is completed.  This is a sound approach for normal everyday use as it strikes a balance between detecting attacks and not adversely affecting performance.  Keep in mind that there is a latency cost each time that ModSecurity has to apply an operator to data.  

There is a seldom used action called multiMatch and its purpose is to change when operators are applied to data.  

With multiMatch, the operator is actually applied to data each time that the individual transformation function alters the data.  With this approach, it is now possible to detect the previous SQL Injection bypass attempt.  Here is how the multiMatch operator execution looks now:

[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=%2f*&bar=%E2%80%98+UNION+SELECT+*+FROM+user+%26%23x2f*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Operator completed in 1 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] T (0) urlDecodeUni: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Transformation completed in 42 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Operator completed in 1 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] T (0) htmlEntityDecode: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Transformation completed in 78 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Operator completed in 0 us
ec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] T (0) lowercase: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 union select * from user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Transformation completed in 109 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 union select * from user /*"

In order to balance out the latency hit and its chance for higher false positives, we have implemented use of the multiMatch action into the OWASP ModSecurity Core Rule Set by only conditionally using it if the Admin configures the PARANOID_MODE variable in the modsecurity_crs_10_config.conf file.  When this is set, many of the rules will then inspect more generic variables and use the multiMatch action.  As indicated by the name, PARANOID_MODE is mainly meant for people who want to get more aggressive with detection and have a higher tolerance for false positives.

Transformation Function Tips

Here are a few recommended tips for using transformation functions.

Start with t:none

Due to the fact that transformation functions pipelines are cumulative, it is possible that you could unintentionally inherit transformation functions from a previous SecDefaultAction.  It is therefore good practice to start each transformation function pipeline with "t:none" as this will clear out any existing ones.

Choose the right transformations

There is no "one size fits all" magic transformation function pipeline.  You need to analyze what type of attack you are targeting and then identify the methods in which attackers may try evade detection.  For instance, the transformation pipelines for detecting Cross-site Scripting (XSS) is much different then what you would use for SQL Injection.

Beware of performance

The larger the payload is, the longer it will take to complete the transformation pipeline.  This is not that big of a concern for inbound request data as they are generally small in size.  Where you can run into higher latency hits is when you are attempting to inspect outbound data (RESPONSE_BODY variable).  It is for this reason that you should try to limit the use of transformations when inspecting RESPONSE_BODY and instead specify mixed-case within your regular expression.

1) Privacy is free. Many privacy advocates believe it is a free lunch‚ - that is, consumers can obtain more privacy without giving up anything. Not so. There is a strong trade-off between privacy and information: The more privacy consumers have, the less information is available for use in the economy. Since information helps markets work better, the cost of privacy is less efficient markets.

There are two problems with this statement. The first counter-fallacy is the idea that more information, any information, makes markets work better; that just isn't true. Take a simplistic example of someone who signs up for a golf magazine and is then spammed by so many adverts for golfing gear that they train their spam filter to block it. The company got some information, used it inappropriately, leading to the client making fewer purchases for no better reason than too much advertising. What's needed is a mechanism for the right (i.e. necessary to enable consented activities in the consumers interest) information to get to the right companies (i.e. not spammy affiliates or surveillance groups). This is exactly what privacy advocates are working for currently; what controls can enforce this rather than the overly permissive current state.

The second problem is that the cost goes both ways. Right now a consumer has to spend the effort in enforcing their privacy. The current technical complexities of, for example, ensuring cookies for services you use, are not used to correlate your identity across affiliate sites, is high and only performed by the few who understand the implications and care enough to do something about it. Thus, the cost (understanding, technical ability, actual work required) is too high for many consumers to reasonably enforce their own privacy. This cost needs to shift to companies in order to achieve a more reasonable middle ground.

2) If there are costs of privacy, they are borne by companies. Many who do admit that privacy regulations restricting the use of information about consumers have costs believe they are born entirely by firms. Yet consumers get tremendous benefits from the use of information.

Think of all the free stuff on the Web: newspapers, search engines, stock prices, sports scores, maps and much more. Google alone lists more than 50 free services‚ - all ultimately funded by targeted advertising based on the use of information. If revenues from advertising are reduced or if costs increase, then fewer such services will be provided.

I don't see fewer services, in return for more control of what information is collected and how it is used, as a poor trade off i.e. it's a cost most consumers would be willing to bear. If anything, efficiencies may be generated in the market with weaker services that exist purely as third party data collection points (e.g. spammers, personal data warehouses (e.g. Axciom) and other organisations that end up with data from our primary service providers that we would prefer didn't) being weeded out. It would be hard to argue that more privacy would result in all information supported services disappearing.

3) If consumers have less control over information, then firms must gain and consumers must lose. When firms have better information, they can target advertising better to consumers‚ - who thereby get better and more useful information more quickly. Likewise, when information is used for other purposes‚ - for example, in credit rating‚ - then the cost of credit for all consumers will decrease.

4) Information use is "all or nothing." Many say that firms such as Google will continue to provide services even if their use of information is curtailed. This is sometimes true, but the services will be lower-quality and less valuable to consumers as information use is more restricted.

For example, search engines can better target searches if they know what searchers are looking for. (Google's "Did you mean . . ." to correct typos is a familiar example.) Keeping a past history of searches provides exactly this information. Shorter retained search histories mean less effective targeting.

Once again, we have the counter fallacy: "more information == higher quality service" coupled with a misunderstanding of what sort of control privacy advocates are looking for.

First, a large amount of information currently collected is not collected for direct use with that service; while Google search does collect your search term, it also correlates that use with other services. If Google were to say "we collect exactly this information for this specific purpose, if you don't like it leave" that would be a huge improvement over the current vague statement of "we collect some information, we share some of it, if you don't like it leave, but we'll still try to track you around the web."

Second, privacy advocates, for the most part, have no problem with Google collecting search terms and using that data for the typo correction example above. The problem is strongly associating those terms with an identity and then barely anonymising them. It would be quite possible for Google to collect the search terms and provide typo correction without knowing UserX searched for that term.

5) If consumers have less privacy, then someone will know things about them that they may want to keep secret. Most information is used anonymously. To the extent that things are "known" about consumers, they are known by computers. This notion is counterintuitive; we are not used to the concept that something can be known and at the same time no person knows it. But this is true of much online information.

This "fallacy" is phrased incorrectly. It should be "If consumers have less privacy, then someone *could* know things about them they may want to keep secret." This is not a fallacy. Sure, for the most part there isn't a sweaty sysadmin reading each of my Yahoo mails (although research by others suggests there may be), but if a sysadmin/private investigator/government organisation wanted to they could. If the information is stored and identified then at some point someone will want to consume it. My experience in information security tells me that you can't provide perfect protection, and as the Saudi/RIM lawful intercept saga indicates, gov pressure to be able to violate your privacy/secrecy/confidentiality wins. As the Google/China hack indicates, lawful intercept gets used by the bad guys too.

What's more, the advanced data analytics performed by the likes of Facebook and Google allow additional secret information, that you may not have intentionally disclosed about you, to be discerned. In short, if the information isn't stored, it can't be compromised.

6) Information can be used for price discrimination (differential pricing), which will harm consumers. For example, it might be possible to use a history of past purchases to tell which consumers might place a higher value on a particular good. The welfare implications of discriminatory pricing in general are ambiguous. But if price discrimination makes it possible for firms to provide goods and services that would otherwise not be available (which is common for virtual goods and services such as software, including cell phone apps) then consumers unambiguously benefit.

7) If consumers knew how information about them was being used, they would be irate. When something (such as tainted food) actually harms consumers, they learn about the sources of the harm. But in spite of warnings by privacy advocates, consumers don't bother to learn about information use on the Web precisely because there is no harm from the way it is used.

8) Increasing privacy leads to greater safety and less risk. The opposite is true. Firms can use information to verify identity and reduce Internet crime and identity theft. Think of being called by a credit-card provider and asked a series of questions when using your card in an unfamiliar location, such as on a vacation. If this information is not available, then less verification can occur and risk may actually increase.

9) Restricting the use of information (such as by mandating consumer "opt-in") will benefit consumers. In fact, since the use of information is generally benign and valuable, policies that lead to less information being used are generally harmful.

10) Targeted advertising leads people to buy stuff they don't want or need. This belief is inconsistent with the basis of a market economy. A market economy exists because buyers and sellers both benefit from voluntary transactions. If this were not true, then a planned economy would be more efficient‚ - and we have all seen how that works.

If Communism is to economists as Nazism is to moralists, then I'm calling Godwins Law (I know, I lose). That being said, I'm not going to defend this point, as it's a dumb one. Targeted advertising is much better than untargeted advertising. Guess what's better for the consumer? NO ADVERTISING coupled with easy ways of finding out information on products they actually want to purchase. The only reason I allow advertising (and sometimes click the ads) is for sites I want to support who use ad-revenue, for the rest, there's ad block. But I try not to let any of them profile me to offer targeted ads, yet somehow I am still fully empowered to both find products I want, research them in detail and purchase them from companies selling them.

This brings us to the end. In short, I disagree with everything Rubin says. He misunderstands that privacy advocates are looking for a balance of controls, not extremes, and makes unvalidated assertions about how information inherently leads to all sorts of good economic things. He also fails to consider abuses of information, which are the specific cases privacy advocates are trying to protect against.