Not logged in | Login

My Security Planet

Feeds

10940 items (0 unread) in 75 feeds

WebSecurity

Security

SEO

Tools

Opensourcetesting.org News

Recent items

terminal23

symantec hack is whack is a case study

Posted: September 7th, 2010, 2:29pm CDT by michael

Tags: [edit]

Yeah, we've all heard more than we need to about Symantec's Hack is Whack campaign and the security holes found in the newborn site.

This is what I call a decently Big Deal; a sort of case study in how even a security giant is dropping a site out onto the internet that is full of holes. Certainly Symantec has security experts enough to review their code and make suggestions, or code it up properly from the start. Or at least have some oversight to slow down the process and make sure marketing has their details buttoned up, right? (I'm quite aware that marketing no doubt implemented and ran with this completely on their own, likely through a third party or even fourth party, but my point will remain...)

This really provides a horrible, sobering example of the state of things right now, especially in how important security truly is to organizations. Far too many do whatever they want, until someone pokes the soft spots and points them out. The more public or damaging, the more likely a quick response is forthcoming. And this from a security company!

I'm not going to go so far as to say this is a call to arms for security to be at the forefront of marketing in Symantec or even any organization. That's a dreamy ideal, but not one I'm thinking is realistic at this point. No one likes security dragging the timelines out and making things complicated!

It should instead be more of a call to arms for executives to care about this sort of thing, which in turn can start permeating that cultural change in everyone else. It just doesn't work to be 100% reactive. That is still what I call the Big Gamble in organizational security. Roll it out there and hope no one ever cares too much and finds big holes. That or the attitude that you can't secure it yourself, so roll it out there and let others provide your QA and security testing for you. I agree you can do those approaches, but they can't be your only approach. You'll either continue to be laughed at, or you'll get pwned and not know it.

I may still be a bit idealistic in my viewpoint. In larger corps, they're just too big to play catch-up on everything that is going on. In smaller corps, they just want to survive and can't afford to go slow or imbed security in something that may not even exist in 6 months if it fails.

ModSecurity Blog

Advanced Feature of the Week: Real-time Blacklist Lookups

Posted: September 7th, 2010, 10:58am CDT by Ryan Barnett

Tags: [edit]
This week's feature is the effective use of Real-time Blacklist lookups (@rbl).
Reference Manualrbl
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"
```
OWASP ModSecurity CRS
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.

So What?
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.
@rbl Tips
Here are a few recommended tips for using @rbl.
DNS Caching
Implement a local caching DNS server like rbldnsd so that your @rbl checks issue DNS queries to the local system first.
Use ModSecurity Persistent Storage
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.
Choose your RBL carefully
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.

Schneier on Security

Consumerization and Corporate IT Security

Posted: September 7th, 2010, 7:25am CDT

Tags: [edit]

If you're a typical wired American, you've got a bunch of tech tools you like and a bunch more you covet. You have a cell phone that can easily text. You've got a laptop configured just the way you want it. Maybe you have a Kindle for reading, or an iPad. And when the next new thing comes along, some...

Sunnet Beskerming Security Advisories

PS3 Hack Spreads, Sony Update Kills It

Posted: September 7th, 2010, 3:09am CDT

Tags: [edit]

Although Sony has been successful in suppressing the sale of the PSJailbreak devices in Australia for the time being, detailed information about the processes involved in the hack has now lead to multiple alternative hacks surfacing.

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.

SEO BlackHat: Black Hat SEO Blog

Epassporte Dropped by Visa

Posted: September 7th, 2010, 2:36am CDT by QuadsZilla

Tags: SEO [edit]

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.

SecuriTeam Blogs

T2 Conference Challenges

Posted: September 7th, 2010, 1:51am CDT by noam

Tags: Commentary [edit]

Hi,

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.

Billy (BK) Rios

PDF XSS (CVE-2010-0190)

Posted: September 6th, 2010, 9:57pm CDT by xssniper

Tags: Security [edit]

In April of this year, Adobe patched a couple of bugs I reported to them. One was a code execution bug (CVE-2010-0191) and the other was a PDF based XSS (CVE-2010-0190). I’ll cover the code execution bug in a future post (as Adobe is still fixing a variant I reported), but for now I’d like to touch on the PDF XSS.

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 Octal Encoding
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
Security models are different for local and remote PDFs
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.
PDFs can be used to call the default browser
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.

Liminal states

Links from the Arrington/TechCrunch women in tech kerfuffle

Posted: September 6th, 2010, 1:45pm CDT by jon

Tags: [edit]
Even over the three-day weekend here in the US we continue to see some excellent discussions, for example Qworky advisor Gayle Laakmann’s Blame Men — And Women and Audrey Watters’ “Ambient Un-belonging” Arrington’s got another post up too.

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

Schneier on Security

Terrorism Entrapment

Posted: September 6th, 2010, 7:24am CDT

Tags: [edit]

Back in 2007, I wrote an essay, "Portrait of the Modern Terrorist as an Idiot," where I said: The JFK Airport plotters seem to have been egged on by an informant, a twice-convicted drug dealer. An FBI informant almost certainly pushed the Fort Dix plotters to do things they wouldn't have ordinarily done. The Miami gang's Sears Tower plot was...

Liminal states

Windstorms on Playa (Labor Day Weekend 2010)

Posted: September 5th, 2010, 7:23pm CDT by jon

Tags: [edit]

Windstorms on Playa

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!

ha.ckers.org web application security lab

The Effect of Snakeoil Security

Posted: September 4th, 2010, 12:53pm CDT by RSnake

Tags: Webappsec [edit]

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.
Browser Detection Autopwn, etc…

Posted: September 4th, 2010, 10:53am CDT by RSnake

Tags: Webappsec [edit]

16 posts left…

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.

cat slave diary

Code of Hammurabi – or 4000 years later, we still haven’t got it

Posted: September 4th, 2010, 1:52am CDT by vanderaj

Tags: OWASP [edit]

The Code of Hammurabi is one of the earliest known written laws, and possibly pre-dates Moses’ descent from the Mount.

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.

Schneier on Security

Friday Squid Blogging: Squid Car

Posted: September 3rd, 2010, 4:58pm CDT

Tags: [edit]

Squid car....

ha.ckers.org web application security lab

The Perils of Speeding up the Browser

Posted: September 3rd, 2010, 12:41pm CDT by RSnake

Tags: Webappsec [edit]

17 posts left until the end…

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.
Browser Differences, Minutia Et Al…

Posted: September 3rd, 2010, 11:27am CDT by RSnake

Tags: Webappsec [edit]

18 posts left…

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.

terminal23

writing compensating controls

Posted: September 3rd, 2010, 9:31am CDT by michael

Tags: [edit]

The PCI Guru has a nice reference on writing compensating controls for PCI requirements you "can't" meet.

Jeremiah Grossman

Our infrastructure -- Assessing Over 2,000 websites

Posted: September 3rd, 2010, 8:43am CDT by Jeremiah Grossman

Tags: [edit]

Recently I was asking a colleague how desktop black box web application vulnerability scanners, from a scalability perspective, approach scanning large numbers of websites (i.e. 100 to 500+) simultaneously. I was curious about the way they address the physical infrastructure requirements to support big enterprise deployments as compared to our own. Anyone with experience knows commercial desktop black box scanners can easily eat up several gigs of memory and disk space for even a single website. Nothing high-end workstations can’t handle, but multiplied out it’s an entirely different story. The person had an unexpected answer, “Desktop black box scanners don’t have the use-case you [WhiteHat] do, their technology doesn’t need to scale.” Say Whaaa!?!

Asking for clarification he said consider how black box scanners are normally used in the field. They are “developer” or “pen-test” tools where the use-case is one person, one machine, one website, one configured scan, and then let it run for however many hour or days it takes until completion. Attempting to perform dozens or hundreds of scans at the same time would be exceedingly rare, if ever, so the capability to do so doesn’t need to exist. He said, “Who beside you guys [WhiteHat] needs to scan that many websites at a time?” To which I humbly replied, “the customer.”

As we know new Web attack techniques are being published weekly and Web application code is change is rapidly (Agile). Web applications, even those that are old and unchanged, need to be tested often for these issues. Testing once a year, or even once a month, isn’t enough in an environment like the Web where daily attacks are normal. So if an enterprise has say 10 or more websites, to say nothing of those with hundreds or thousands, mass scanning is essential to get through them regularly. Burdening enterprises by having them wire scan nodes together with command and control systems to achieve scale is patently absurd. That's as an inefficient one-to-one model. 100 simultaneous scans = 100 scan boxes. Of course I’m sure they are happy to sell the hardware.

So yes I was a bit surprised that the desktop scanner guys haven’t seen fit to tackle the technology scaling problem, even though two of them are mega corps. They above all should know that scaling must be addressed if performing routine vulnerability assessments on all the Internet’s most important websites is to become a reality. To be fair, we’ve never pulled back the curtain to show off our own infrastructure. Maybe it’s time we did so because over the years we’ve invested heavily and it’s something we’re particularly proud of. I think others would be interested and impressed as well. The physical requirements for WhiteHat Sentinel, a SaaS-based website vulnerability management platform, are in a word -- massive.

Operationally we’re assessing over 2,000 websites on a fairly routine basis (~weekly). A dedicated IT staff is monitoring the systems for over 300 points of interest (utilization of network, cpu, memory, uptime, latency, etc.) ensuring everything is running smoothly 24x7. Metrics show at any moment 450 scans are running concurrently, generating about 300 million HTTP requests per month, and processing 90,000 potential vulnerabilities per day. We preserve a copy of every request sent and response received for audit, trending, tracking, and reporting purposes. This system itself is being access by over 350 different customers with tens of thousands of individual Sentinel users.

CPU and memory wise our ESX virtualization chassis allow us to control resource allocation and scale fast between multiple scanning instances and load balanced front-end & back-end Web servers. As you can see from the pictures we have some serious storage requirements. Our clustered storage arrays have 250TB ready to go (additional capacity at a moments notice), writing about 500GB to disk per day, and connected by dual 10GB backplane ethernet connections. Sick!

Oh, did I forgot to mention the two 100MB links to the Internet? Also very important is that the infrastructure is fully redundant. Pull any network cable, push any power button, and the system keeps on humming. I left out the pictures of the backside of the cages, which is every bit as cool as the front, but there’s a lot of network cords, firewalls, routers and other stuff we’d prefer to keep to ourselves. :) If someone else claims to have a SaaS scanning platform I’m wondering if it looks anything remotely like ours.

The data center where everything is housed is SAS70 Type II certified and state-of-the-art when it comes to power, fire protection, cabling, construction, cooling, and physical security. Guards are on site 24/7/365, active patrols both inside and outside the facility, with 54 closed circuit video cameras covering the interior and exterior of building. To get access to our area requires an appointment, government issued ID, thumbprint, retina scan and only then do they hand over the key to our private space where only two people at WhiteHat have access. I’m not one of them. :) Compare this to the scanner on laptop sitting somewhere unguarded in the enterprise. Clearly we’re not a desktop scanner behind a curtain like others out there. We’re not playing around. We take this stuff extremely seriously.

WhiteHat Security is a leading provider of website security services.

deep inside | security & tools

WASC Threat Classification 2 - Wordle

Posted: September 3rd, 2010, 7:55am CDT by Romain

Tags: [edit]

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

Schneier on Security

UAE Man-in-the-Middle Attack Against SSL

Posted: September 3rd, 2010, 6:27am CDT

Tags: [edit]

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

terminal23

incomplete thoughts: dreamy aspects of a solid security posture

Posted: September 2nd, 2010, 4:48pm CDT by michael

Tags: [edit]

This is another incomplete, but interesting post. Not sure why I started writing this , but I always like the dreamy feel of "best case scenario" types of descriptions. Like what is your dream job? What is your dream vacation? In this case, what is your dream security team posture? I've added a thought below in bold. I probably never released this since I likely have said these same items in other blog posts, comments on other blogs, over twitter, and in personal discussions, so it sounds a bit like a broken record to myself.

Simple steps to a strong security posture:

- Staff. Don't skimp on quality security staff. The anchor of any security team is the skill, talent, and enthusiasm of the top players. It is ok to have some lesser-skilled players or interns. They help provide perspective, an ability to allow senior staff to mentor, be mentored, and possibly do the things that you'd hate to have a $100k staffer do every day like cruise logs or something. In addition, be liberal with their training opportunities, both on and off the books.

- Operate the team as an advisory unit, a monitoring unit, and an active penetration team. Basically, don't just watch for breaches or react to things already done. Be an internal consultation team for developers, sysadmins, or others who would like or need more guidance on security issues. The team should also be able to and allowed to do planned and unplanned security audits and penetration tests against company assets. It's not just about implementing, tuning, and addressing trouble tickets about a host-based firewall on desktop systems, or auditing the systems through a central mgmt interface to ensure exceptions aren't being granted by non-security-minded desktop staff. It's about helping the business as a whole.

- Be given autonomy and authority in the company to make recommendations, on par with a high-level consultancy. If a security team expects an application to be built securely and offers proper assistance and knowledge to the app team, they should expect to have their concerns addressed reasonably, rather than what often turns into a mgmt political battle or simply ignored demands. It needs oversight over the company assets and IT, really.

- The team should be given some level of operational power or control, especially over their own systems and test systems/networks. Security staff isn't just about installing endpoint software or watching logs or even consulting or pen-testing internally. They should be able to test and implement changes as needed without having to walk someone else through it or wait (politically and timely) for a real engineer to attend to their ticket. It is my opinion that quality security staff would also make quality operations staff (or quality management in general if that is their focus)...so give them that latitude. (They should also be held as accountable with availability mistakes as operations, when acting in that space.) Of course, this butts up against the problem of having too many hands in the cookie jar, for instance 6 people having access to update firewall rules. That's 5 extra ways of doing it that don't match your own philosophy!
incomplete thoughts: 5 of my security pet peeves

Posted: September 2nd, 2010, 3:21pm CDT by michael

Tags: [edit]

This is my getting rid of some incomplete thoughts sitting around in my unpublished bucket. This post could be 3 years old or it could be 3 weeks old, I'm not sure. Peeve #4 is a bit of a reality, and I'm not sure I would today include that in here if I rewrote this today. The ending example goes nowhere, and #5 isn't finished. Either way, just getting this off my chest and published.

5 of my IT security pet peeves. Notice that these are not necessarily technical issues. I don't feel like our biggest challenges are technical in nature. And while I might call these pet peeves, they don't necessarily frustrate me nearly as much as most of my driving pet peeves.

1. No Big Box Tool beats a good admin, but we're obsessed with the Big Box Tools. I'm not a big fan of all-in-one-boxes or UTM or centralized SOC-in-a-BOX. On one hand, I really like the power that tools have been getting in terms of analyzing and collecting data in one place. Sadly, I don't think any single box performs better than other smaller tools being used wisely by a crafty admin to achieve the same goals. There is a certain watering down (each piece is lower quality compared to specialized tools) and dumbing down (take the analyst away from the guts long enough and he'll only know how to work the GUI and not dig deeper manually) and feature-bloat (try to pack every option that 10,000 companies will use but no company uses half of them at once) to big boxes that simply cost in terms of quality. The real key here is whether you have a crafty admin with the time necessary to wisely wield those surgical tools. Instead, we too often take the quality hit to save some money...

2. Not enough time. In our American culture, we have this obsession with milking productivity from our workers. We demonize leisure time, personal time, even vacations; maybe not openly, but we insinuate that anything less than 100% is bad. This trickles down into IT staff who have little free time to improve their situation beyond rushing from one fire to the next, or one project to the next. You know you're in this situation if you're doing task A, notice that issue X is occuring just because you happen to see it, but know you won't ever get to it and so just leave it. Security cannot be improved when time is booked. Either you don't have the time to properly tune tools, investigate alerts (we've all had days where 1 alert takes 1 hour and days where 1000 alerts takes 5 minutes), do simple audits to verify security, or keep on top of current news. Let alone the mistakes that will be made due to the pressured time-boxing... You want to improve security? Improve the time your staff has to find and make enhancements. Anything else just means everyone relies on the audits and only does what is prescribed at the time. (This also means your staff needs to be enthused about security, and not just use their extra time to surf YouTube. If you don't have enthused staff, then replace this item with : People who don't hire enthused staff!)

3. Too many people still believe ignorance (or ignoring it) is an effective security strategy. I'm borrowing this straight from the article I just posted about earlier, because I think it is an epidemic (pandemic) problem. That noise coming from your engine? Yeah, it'll go away, right? It wouldn't happen to us! I think ignorance and human habits of ignoring problems is a real issue. I understand that some risks are accepted and not every problem absolutely needs resources pushed at it to solve it, but collectively we're sucking with even the basics of digital security. (I think most organizations scope-limit their auditors from half the stuff that is wrong.)

4. Convenience trumps security, or, security is never as easy as it sounds. There are a few tasks that sound easy but illustrate exactly how time-consuming really managing security is: data classification company-wide, account oversight and review, file server permissions audits, knowing exactly what data is where (yay laptops!), log reviews, and change management. Convenience trumping security is a more appropriate way of saying functionality over security.

5. We want security now, for free, and to last for years without further inputs. How many PCI projects have we collectively seen that have deadlines? And after that deadline, PCI (or security) is considered done and the consultants/contractors let go). That's a win for sure!

Just to juxtapose a few items from above, here is one scenario. You have a not-very-technically-proficient security admin in your company. He's not given the most access, probably not enough to do this job effectively. He doesn't have the ability to implement proper NSM without the techs making his requests bottom-of-the-barrel priority. In fact, he doesn't have much more than the ability to get an All-In-One-Security-Box. Likewise, said security box doesn't give him much data for an alert. Oh, and by the way, he's an important admin who talks with execs every few weeks with some certs under his belt, so he feels he gets paid more than someone who does the grunge work like reviewing logs, accounts, or testing those firewall changes. So no one really checks that stuff. When audited, the admin knows just enough to give the auditor enough for a report, keep him away from the things he knows suck, but not enough to allow the auditor to expose underlying issues.
incomplete: a better representation of risk and compliance

Posted: September 2nd, 2010, 3:08pm CDT by michael

Tags: [edit]

I really don't know where the fuck this post came from or where I was going with it. It offers nothing, but the picture links are fun! Took me a bit on the wildebeest one to realize I was trying to say "just another beest in the herd" with the "middle" pic. To my sensitive readers (really, there are sensitive security geeks?), skip the seal pic.

1. Too many words in PowerPoint presentations are bad. More creativity, more pictures, more visualization. Less words, less boring.

2. We also have this need to give quick representations of our risk or compliancy to management, often in the form of scores or grades.

I think these ideas should be combined "mashed up." Screw the grading scale of A, B, C, and the levels like high, medium, low.

Imagine: You walk into the board room with several managers and execs. They get around to asking you how the company looks as far as compliance to PCI and/or your desired security level. You stand, flip open your notebook, and pull out a card the displays this picture:

[msnbcmedia3.msn.com]

I don't have to give details, I think it speaks for itself: STATUS BAD!

Here are some more examples of compliance status levels.

Bad: [wwwdelivery.superstock.com]

Middle: [www.african-parks.org]

good: [farm2.static.flickr.com]

[upload.wikimedia.org]
incomplete: shmoocon podcaster's meetup interesting topics

Posted: September 2nd, 2010, 2:59pm CDT by michael

Tags: [edit]

I wrote this months ago but I guess I forgot to publish it. Maybe I wanted to proof it more? Who knows, but here it is. Any non-bullet points that are bolded were added by me just now.

The mess that was the 2010 Shmoocon podcaster's meet-up audio is available. I totally could use not hearing Paul "shhh" on a mic ever again! The talking was pretty crazy and all over the place, even disrespectful (hey beer was involved so it's forgivable), but I feel like they did touch on some extremely important questions. Questions I'd love to hear them discuss again in a more refined situation (arguably, a podcaster's meetup is more party than panel, however!)

There are no correct answers to these topics! That is probably why opinions in these discussions can be very passionate and even violent! Sometimes in certain properly bounded contexts, there are correct answers, but mostly not.

(Late update: Personally, the more I listen to Chris Nickerson, the more I appreciate his frank opinions and where he has his head. It's in the right place, and while I know he can have an acerbic sense of humor to some people, he's increasingly one of those voices worth listening to if he tells you something.)

1. exploit vs not exploit - I'm not sure this topic was given its fair due, but I'm not sure everyone was on the same page in the discussion anyway. Andy Willingham gave this the once-over already in a blog post. The topic brings up good questions on what you do on a test and what is actually meaningful. I notice I didn't really weigh in on this topic, and honestly the view from the fence is fine for me and probably reflects both my security and operations sides.

2. SMB vs large enterprise - There is a big gap that is hopefully becoming less the elephant in the corner and more one of the usual voices in the conversation. The world of the SMB in security is dramatically different from that of an enterprise or a city-state-nation. Approaches that work for large enterprises can be ridiculous for SMBs, and vice-versa. I think it matters that this came up multiple times. This still needs to come up, and the topic deserves a month of posts in itself.

3. properly presenting findings/recommends to a business - I'm finding it hard to word this topic, but it really runs the gamut of how you present security to an organization. And this digs at a very sensitive topic: security aligning to the business. I sympathize with all sides to this discussion. You could give the security teams and CSO their highly technical reports and let them distill it down to what is relevent. Or you could align yourself with the business and report your findings directly to someone like the CEO, in the CEO's terms. Honestly, maybe pen-test teams need to have both capabilities and have that project manager/lead who is the one that acts as a temporary CSO in the absence of one. This is a great topic, by the way, and I think really demonstrates the art and the versatility today's security experts need to have; both the technical chops and the strategic chops and the ability to know when to use each.

4. "good enough security" - I think it was Mick from Pauldotcom that brought this up, and it didn't get enough treatment, although I think this is also just as passionately divisive a topic as any. When you accept that there is no ultimately "secure" state, or there is no "win" in security, then you really do subscribe to some form of "good enough security." Where that proper line is drawn is really the art of risk management, and that line is probably far lower for SMBs than large enterprises. Security pros these days have to be able to get into the mode where it's not just about violently defending every little insecurity, but about recognizing each issue as part of the whole. Bad password policy? Fix it!! Outdated SSLv2 cipher on an internal app that is 5 years old used by one team? Consider letting it slide. (Side note: This is where lack of real security chops can bite many people in the ass. It is inevitable that non-tech people will look at issues presented and demand fixes for each one, even the "low" priotity ones. This creates wasted effort and inefficiency...and so on.)

5. privacy differences between europe and the us - I thought this was an excellent question by Nickerson to spark some conversation on a topic I hadn't really dwelled on before. Because Europe has a different emphasis on privacy for people, they have an entirely different mindset in regards to security in organizations. Not saying it's all good, but the difference can be useful.

6. listening to internal security experts vs paying someone outside the company to say the same damn thing - Good point on this topic, and I think every penetration tester or consultant or third party needs to not just work to align with the business and talk in a way the CxO understands, but also empower and support those internal persons who make security happen. Recognize and empower (and not undermine!) the talented security folks out there. Build networks, exchange advice, encourage; don't have an antagonistic relationship with them, plop down some mysterious report on a CxO's desk, then walk away briskly. Try to change the way the CxO views her internal support staff so that we can Get Shit Done. But yes, it really, really sucks when a CxO pays top dollar to get a report that says the exact same thing I may have been saying for years.

If there's any topic I'd love to have brought up because it fits with this motley crew of passionate voices, I'd have asked opinions on MSSPs vs internal staff, both for large enterprises but also SMBs.
incomplete: fundamental cultural changes caused by the internet

Posted: September 2nd, 2010, 2:50pm CDT by michael

Tags: [edit]

I'm sure there are plenty, PLENTY, of other essays by far smarter people than me in this topic, so rather than let this languish in the "polish this up" bucket, I'll throw it out as is because I know I'll never truly ever finish this. Still, this actually reads fairly decently for a 30-minute stream-of-consciousness bit. Oh, and I know it's not ten!

Ten Ways Internet/Computers have changed our culture deeply.

- I barely know what a phone book is anymore, if I want to find a location or phone number for a business or category of business that I need to visit, I'll search for it on the web. This is a culmination of easy, extensive searching and ubiquitous web presence. Phone book? Ok, I've used it to find a mechanic on a Sunday...

- Dispelling irrational answers to questions - Back when I was a kid, you had four places to gleen information, in general: media, teachers, parents, public library. Media would have included newspapers, magazines, radio, and television. All of these meant effort and a certain expectation of trust. The web still requires trust, but I can much more quickly find corraborating stories and information and weed out the misinformation. While the web may not give accurate information all the time, it at least gives me a better chance of self-serving accurate information.

- I'm more in control of my time. While the Internet seems to suck time away with an infinite number of things to do and see, it does let me bring back time control into my life. Rather than wait for 30 minutes in the evening news to see the sports scores or tomorrow's weather, I can get it immediately online. I can skip the things I don't care about, and read more of what I do care about. I can shop and order products online, research and compare.

- I'm more in control of my tastes and interests. In my youth, I was only exposed to whatever was near at hand, for the most part. Musically, I only experienced what was available on the radio, television, or through friends, all of which precluded most anything that was not pop-oriented. With such portable media and access to anything I want, I can expand my boundaries and listen to musical media that I never, ever will hear on the radio in the central United States. As a kid, if I wanted to figure out the solutions to a particular video game, I had to wait for it to be released in book form, in a magazine, or advice from friends in my neighborhood. My neighborhood for interests is now limitless, and I don't have to leave a game unsolved.

- My social network has grown. As a child, I had a finite number of people I knew and could spend time with, all of which had to be in close proximity to me, unless I picked up a pen pal. Today, I can get first hand information about life in China through knowing people either in chats or other social networks, or through their blogs and stories.

- My idea of a job has dramatically changed. I can't actually imagine what I would do for work without the computerization revolution. I have not experience office work without automation or computers or digital information. I'm not that removed from such an archaic workplace, but it certainly seems a world away.

- I am a much more informed and well-supplied consumer. Rather than rely on a magazine, friends, or in-store help, I can self-serve online research on what products are good and which ones to avoid. Hell, I can also buy things online without getting up off my ass, either from storefronts or auction sites. In fact, not only can I research online, but if I want specific item ABCD, I don't have to hunt my city for it and maybe walk away empty-handed. I pretty much *will* find it online, somewhere.
incomplete: leveling up your security career wow-style

Posted: September 2nd, 2010, 2:43pm CDT by michael

Tags: [edit]

This is an incomplete thought I first jotted down a while back, but never fleshed out into some more coherent. I liked the thought though, and wanted to just release as is and get it off my "unpublished" list! I was reminded of this post by Rothman's recent Securosis blurb about practice (way at the bottom). Thoughts added just now are in bold. Keep in mind this is incomplete, unedited, and unpolished. I ramble and mix things and even repeat things with wild abandon! Oh, and even now as I play some Starcraft 2 and get my ass repeatedly stomped in Platinum 1v1, I know that I can read and practice against the AI and read some more, but nothing will replace actual experience in going into another game and getting stomped and learning the hard way.

I've not made it a secret that I've been an avid World of Warcraft (WoW) gamer for years. I definitely don't play as obsessively as I used to (for those in the know, I 'hardcore' raided MC, BWL, AQ40, and even some of Naxx40, then skipped ahead after a break to 'softcore' raid Hyjal and BT pre-nerfs; since then I've done a couple naxx25 clears and that's it beyond 5m heroics and casual leveling), but even my casual playing sparks some interesting thoughts now and then, especially when it comes to "leveling up."

In WoW, and really any other RPG game, there are a few key tenets to making the most of your effort. Surprisingly, these tenets can match exactly across to real life endeavors. And every time I put forth some effort to improve one of these tenets in WoW (leveling up a toon, making some gold...), I'm reminded of the opportunity cost of putting that effort into something more tangible like my security career. (Don't get me wrong; I'm a lifelong video game hobbyist, and I'm not saying video games are useless, but it shouldn't dominate one's time, just like any other hobby pursued in leisure time!)

So if you find yourself stuck in an MMORPG gaming rut, start looking to translate that effort over to something useful in security. This may start with asking yourself what it is about gaming that is relaxing, and why security does not bring that same relaxation. If it relaxes, stimulates, and makes you happy, then your free time will be spent in it just as casually as a 4-hour trip into WoW.

1. Knowing your class. From here I was going to go into knowing your skills, strengths, and weaknesses. In WoW, a warrior class doesn't try to heal, and translate that into security skills and roles...somehow.

2. Grinding (aka leveling up). This is pretty basic to any role-playing game: your character gets stronger the more experience he gets, aka "leveling up." In gaming, "exerience" is usually a value, even if it is hidden behind the scenes, which accrues as you fight and kill monsters. As your experience increases, you gain more power, and can tackle more powerful monsters, which will gain you experience...and so the hamster wheel begins to turn. A more physical version of this is lifting weights and slowly increasing your limits as your muscles and supporting structure build and grow.

Sometimes this is a "grind." "Grinding" in WoW means the slow cycle of killing monsters and doing the same ol' quests to gain your experience; basically it becomes a long, boring grind...kinda like work!

Growth in a security career comes much the same way; the more experience you have, the better you are able to handle the challenges in front of you. Often, this is gained by simply doing security-related things. The more nmap port scans you run, the better you are able to tackle complex scans. The more you use Metasploit to expand your empire, the more you can dig into the lesser-known components of the tool and not get bogged down on strange gotchas. The more PCI audits you do and reports you make, the better and quicker you get with them, and the more value you can provide efficiently to your client.

We often don't have an end goal in sight, but rather know that we simply want to level up.

3. Leveling up tradeskills. WoW has what are called "tradeskills." These are skills you build up by doing that activity. For instance, Fishing and Blacksmithing are two tradeskills. You can fish better and do blacksmithing activities better by, well, doing them in the first place. For something like blacksmithing, the higher your skill, the better your opportunity to make really cool and valuable things.

In other words, if you want to be good and useful at something specific, you have to practice it and get better, especially when it comes to various skills you want to acquire. Unlike leveling up, most often this begins with an end goal in mind, for instance, being able to use a particular skill to create/do XYZ which will gain you money or notoriety.

You want to be good at public speaking? You have to do some public speaking. You want to be good at coding exploits? You have to code some exploits. You want to be good at picking locks? Obviously, you have to pick some locks. (Nicely, WoW has a lockpicking skill you can build!)

And just like starting out your skills at a puny level in WoW, you usually start small. You do some low-key public speaking. You walk-through an exploit tutorial. You pick training locks.

So if you want to be known as being good at some tools or aspect of security, you gotta practice it and build up your skill. This isn't so much a part of your character and confidence like leveling up your character, but more like being good with the tools you have and want.

In WoW, you can leverage these grown "tradeskills" to make in-game money so you can buy cooler gear and weapons. In real life, well, these skills will get your nice REAL things.

3. Gearing up. In WoW, your character's success relies more on just his level (aka amount of experience earned). Success, especially as you get further into the game, resides very much in the gear and equipment you've acquired for your character. You won't be very successful with a low level sword, but if you find a badass high level sword which you can use, you'll be nicely ready to do some damage to the next red slime that oozes your way. Gearing up means a few things. First, giving yourself a chance to get/buy/find the gear. Second, knowing what gear is useful to you.

Security careers have the same dilemma. Some tools are going to be useful to you, but some will not.

Strangely, WoW doesn't have unlimited inventory space for you to keep 1000 pieces of gear. In life, you really don't have the aptitude and time to likewise hold onto and learn 1000 tools. Figure out what you need to improve, and pursue the tools that will help you succeed in your goals.

WoW players can put a ton of time into picking out, pursuing, and testing out their gear.

Oh, and don't forget that you can get a bit literal with "gearing up." A nice pair of slacks and a tie can increase your chances of getting what you need out of management, at times.

4. Socialization. The "MMO" part of the MMORPG genre means "massively multiplayer online," meaning you're playing with lots of other actual people around you. You can spend your time in a game like WoW and neven bother with anyone else, but you'll only be able to learn on your own only so far, and you certainly cannot see most of the end-game content and challenges unless you socialize to some degree. Most often to experience end-game content, you have to join a guild (a group of players, much like a team) and start participating in group runs through tougher dungeons.

Obviously, careers are the same way. You can probably get by on your own for quite some time, but there will be many doors you simply can't open or even get near without socializing with others in the career. Whether that is simply networking to find new opportunities, gaining contacts you can turn to when you need assistance, or finding smart people from whom you can learn new skills and knowledge. Better yet, this also means socializing with people more "newb" than you are; which gives you a chance to reinforce your own knowledge by regurgitating it to others to help them.
incomplete thoughts: really changing the game?

Posted: September 2nd, 2010, 2:15pm CDT by michael

Tags: [edit]

This is an incomplete post that I never published and don't see myself truly completing. And rather than keep it in my list of nagging unpublished things, I thought I'd release it to the wild that is the blogs.

First, go read Rocky's piece over at fudsec on changing the game. Then read Mortman's response over at Securosis. Those two links started whatever thoughts I had below...I think some are points the authors were making, and others are my own responses...but I don't recall. Any current thoughts I'll bold.

This quick, dirty synopsis is for my own benefit to better dissect the point of the article, and also demonstrate what I took away, in chunks.

1. The Information Domain is manmade, and it is a domain where we can change the landscape, not be bound to changing for it.

2. We're short-sighted, rather than long-sighted. We tackle immediate hurdles rather than perform city-planning.

3. Need to change from short-term fixes to long-term strategy.

4. 3 ways: leadership, research, information sharing.

5.Leadership: No one is jumping to save us. We need to lead the way.

6. "[Businesses] need to care much less about being compliant and more about being fundamentally secure - or if you prefer having better visibility into real risk [to the business, not necessarily to an asset]."

7. Too much of what we measure is point-in-time.

8. As infosec pros we have let compliance initiatives drive spending and have ridden along for the ride.

9. We lack the knowledge of the business and how to apply what we do in a meaningful way to the business. I still find this an arguable point. In some cases, the business needs to understand IT (and security) more to better understand business continuity... Nonetheless, this is usually the weakest point in topics like this, not because it is not true, but because it is arguable and situational. Can we always convince business to treat security more aligned with the business or part of the core business line? No. How often are we satisfied that security is good and top notch? Not often, if ever.

10. Vendors fall into the hole of non-innovative solutions that are just meeting our needs, without pushing forward. Vendors ned to be thought-leaders. In turn, vendors need to listen to their customers and deduce their actual needs. Consultants need to listen better. Vendors are in the same boat as internal security experts: trying to sell the idea. It would be far easier to be thought-leaders if security weren't already perceived as dragging ont he heels of innovation and itself being drug into the boardrooms by breaches/regulations. Huge point about consultants!!! Need to listen better and the industry needs to ditch or teach the charlatans.

11. Get past the "way its been done."

12. Research. We need to support research. Research should be revolutionary, not evolutionary.

13. Information Sharing. Collaborate with industry competitors.

At this point my notes ended.

Schneier on Security

Successful Attack Against a Quantum Cryptography System

Posted: September 2nd, 2010, 1:46pm CDT

Tags: [edit]

Clever: Quantum cryptography is often touted as being perfectly secure. It is based on the principle that you cannot make measurements of a quantum system without disturbing it. So, in theory, it is impossible for an eavesdropper to intercept a quantum encryption key without disrupting it in a noticeable way, triggering alarm bells. Vadim Makarov at the Norwegian University of...

terminal23

thoughts on the 2010 verizon dbir

Posted: September 2nd, 2010, 12:19pm CDT by michael

Tags: [edit]

Over a month ago, the 2010 Verizon DBIR was released. I'm still reading through it, but wanted to point out a low and a high point on the report. The low point (and by low, I'm not saying a horrible point, but rather just the lowest point in an already excellent and needed report!) of the report is including a significant amount of US Secret Service data. While this may prove over the years to be a very good inclusion, for now the USSS data obviously influences the percentages and totals. Of course, Verizon's data set itself may have influences...so maybe the answer is to get more and more contributors and USSS is just the first.

Now, the USSS dataset influence is addressed many times in the DBIR itself. Which actually brings up the high point: the presentation. I love the way this report is worded, almost conversationally. They are candid with the data, point out conclusions, and even fuzzy places where you should maybe take the resultant data with a grain of salt due to whatever reasons. I totally appreciate that! In past years, I could make some inferences from the data that were not covered in the text, but I feel like this year the authors did a great job of analyzing and conversing about the data. I don't actually feel like I can or need to infer my own conclusions. (Granted, you have to read the text to get that point, as the figures/graphs themselves can be misconstrued when out of context, in some cases.)

Also, the cover has a hidden message again, this year. This continues to lend "geek cred" to this report, along with the conversationally honest writing.

Security Vulnerability Research & Defense

The Enhanced Mitigation Experience Toolkit 2.0 is Now Available

Posted: September 2nd, 2010, 12:00pm CDT by swiblog

Enclosure: [download]

Tags: [edit]

Today we are pleased to announce the availability of the Enhanced Mitigation Experience Toolkit (EMET) version 2.0. Users can click here to download the tool free of charge.

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

terminal23

housekeeping - decompression

Posted: September 2nd, 2010, 11:21am CDT by michael

Tags: [edit]

I apologize if you've submitted any recent comments. I've been swamped the past few months with work, and my free time has been spent decompressing with things like beer, pocasts, hookers, StarCraft 2, and so on. I just dumped about 10k comments which I quickly skimmed through, so I'm sure I dumped some legitimate ones on accident.

Keeping up on the latest security happenings, comments being submitted, and my own postings has been spotty at best. Things are looking to settle down just a little bit here, so hopefully I can get my own news-reading caught up as well. My RSS feeds are utterly out of control!
kidney punches from the windows dll hijacking vuln

Posted: September 2nd, 2010, 11:01am CDT by michael

Tags: [edit]

There's been a surprising amount of discussion about the recent Windows DLL hijacking vulnerability, often focusing on whether this is a Big Deal or something stupid. I won't bother linking to anything or even joining in any further except to expound on my post earlier.

The DLL hijacking is interesting because, well...it's like walking up to someone you have no reason to mistrust. You shake his hand, but while you do so, someone (maybe his evil twin who was following him) wings a hook beyond your peripheral vision and WHAM! kidney punch. Now, good twin had no idea evil twin was around, and was sincere in his greeting and handshake. But you left yourself open by shaking that hand, and evil twin dropped you to a knee for it.

We can often curse ourselves for shaking hands with the app/guy/file that throws the hook. You run an exe and that's your problem. You run a streamed media file with malicious code, and that's still mostly your problem (and partly the fault of the vulnerable app you used to open it). But in this case, you could open a completely innocent file, and get kidney punched.

That's the important gist of the hijacking vuln, to me. That and the importance this places on patching 3rd-party Windows apps that are vulnerable to this method.

Justice League

Remediation – The Game

Posted: September 2nd, 2010, 9:50am CDT by Guest

Tags: Software Security [edit]

(This is a guest post, contributed by Timothy Champagne, a consultant at Cigital.)

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.

Schneier on Security

Cyber-Offence is the New Cyber-Defense

Posted: September 2nd, 2010, 7:33am CDT

Tags: [edit]

This is beyond stupid: The Pentagon is contemplating an aggressive approach to defending its computer systems that includes preemptive actions such as knocking out parts of an adversary's computer network overseas—but it is still wrestling with how to pursue the strategy legally. The department is developing a range of weapons capabilities, including tools that would allow "attack and exploitation of...

ha.ckers.org web application security lab

Throttling Traffic Using CSS + Chunked Encoding

Posted: September 1st, 2010, 9:17pm CDT by RSnake

Tags: Webappsec [edit]

19 posts left…

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 and Metering Traffic

Posted: September 1st, 2010, 8:56pm CDT by RSnake

Tags: Webappsec [edit]

20 posts left…

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.
XSHM Mark 2

Posted: September 1st, 2010, 8:48pm CDT by RSnake

Tags: Webappsec [edit]

21 posts left…

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.
Cookie Clobbering

Posted: September 1st, 2010, 8:38pm CDT by RSnake

Tags: Webappsec [edit]

22 posts left…

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.
MITM, SSL and Session Fixation

Posted: September 1st, 2010, 8:25pm CDT by RSnake

Tags: Webappsec [edit]

23 posts left…

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.
Issues with Perspectives

Posted: September 1st, 2010, 8:12pm CDT by RSnake

Tags: Webappsec [edit]

24 posts left

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 MitMs 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.
Prior Knowledge Of Users Cert Warning Behavior

Posted: September 1st, 2010, 7:57pm CDT by RSnake

Tags: Webappsec [edit]

25 posts left

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.

terminal23

moaub has begun

Posted: September 1st, 2010, 2:18pm CDT by michael

Tags: [edit]

The Month of Abysssec Undisclosed Bugs (MOAUB) has begun. Since this includes (or maybe fully encompasses) the people behind exploit-db and offensive security, we can probably expect plenty of explanation on the bugs, especially the planned binary analyses.

Seeing things like this and the people behind it, it makes me a little annoyed to be in operations for an SMB. Ops means knowing a bit about a lot of things, but rarely having the time to go into the deep dives often necessary for real security knowledge. I envy and support anyone who has that ability and time! /whine

Schneier on Security

Wanted: Skein Hardware Help

Posted: September 1st, 2010, 1:17pm CDT

Tags: [edit]

As part of NIST's SHA-3 selection process, people have been implementing the candidate hash functions on a variety of hardware and software platforms. Our team has implemented Skein in Intel's 32 nm ASIC process, and got some impressive performance results (presentation and paper). Several other groups have implemented Skein in FPGA and ASIC, and have seen significantly poorer performance. We...

terminal23

unprotecting excel sheets

Posted: September 1st, 2010, 10:46am CDT by michael

Tags: [edit]

Ever solve a problem, then 6 months later need to solve it again but don't recall how you solved it previously? That is the sort of housekeeping I'm doing with this post. I make no guarantee that the site or tool mentioned below is safe/secure for your use. Always take necessary precautions.

Have an Excel file that has password protected sheets or workbooks? I found a handy set of macros to facilitate unprotecting such files over at straxx.com. To be safe, I'd suggest unlocking the files, copying the contents out to a new file, and make sure no strange macros get carried over. I didn't witness any, but better to be safe. And do this all on an expendable system. [excel password crack unprotect]

Schneier on Security

More Skein News

Posted: September 1st, 2010, 6:01am CDT

Tags: [edit]

Skein is my new hash function. Well, "my" is an overstatement; I'm one of the eight designers. It was submitted to NIST for their SHA-3 competition, and one of the 14 algorithms selected to advance to the second round. Here's the Skein paper; source code is here. The Skein website is here. Last week was the Second SHA-3 Candidate Conference....

Liminal states

Women in technology startups: a few things you can do (DRAFT)

Posted: August 31st, 2010, 10:20pm CDT by jon

Tags: [edit]
DRAFT! Work in progress, feedback welcome!
revised version intended for NWEN’s blog

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.

terminal23

the wide impact of windows dll hijacking issue

Posted: August 31st, 2010, 4:25pm CDT by michael

Tags: [edit]

How can the recent Windows DLL hijacking issue affect me? Or rather, can it be used to specifically target vulnerable applications?

A disclosure this afternoon involving KeePass certainly does show you can target specific applications. For instance, if you can get someone with KeePass to attempt to open a KeePass file and load your malicious DLL, you can execute code...such as installing a keylogger/filemon to track what your victim uses to open that super-secret KeePass database.

Note an important issue here: While this vulnerability was announced by Microsoft, Microsoft may not be able to fix this underlying issue. Which really breaks many vulnerability management practices in enterprises that don't do a good job keeping inventory of installed applications and their own updates/patches/vuln announcements.

Security Vulnerability Research & Defense

An update on the DLL-preloading remote attack vector

Posted: August 31st, 2010, 4:00pm CDT by swiblog

Tags: [edit]
Last week, we released Security Advisory 2269637 notifying customers of a publicly disclosed remote attack vector to a class of vulnerabilities affecting applications that load dynamic-link libraries (DLL’s) in an insecure manner. At that time, we also released a tool to help protect systems by disallowing unsafe DLL-loading behavior.

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

ModSecurity Blog

Advanced Feature of the Week: Transformation Functions

Posted: August 31st, 2010, 3:47pm CDT by Ryan Barnett

Tags: [edit]
This week's feature is the effective use of Transformation functions.
Reference Manual
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).

OWASP ModSecurity CRS
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).

So What?
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
```
Example Transformation Execution
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.
Evading Transformation Pipelines
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?
multiMatch Action
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.

Dominic White's .tHE pRODUCT

A Response to Paul Rubin's "Ten Fallacies About Web Privacy"

Posted: August 31st, 2010, 1:40pm CDT

Tags: Privacy [edit]

Paul Rubin had a piece in the Wall Street Journal describing 10 fallacies of Web Privacy. This is my response, and the start of my blogs official "privacy" category.

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.

Giving consumers more control of their information does not lead to firms having worse information. If anything the firms are likely to have access to higher quality information and avoid many of the poor inferences current data sets lead to (e.g. googling for "bomb making" means you're a terrorist). The key quality differentiator is that a consumer can target the intended use with the right information, due to the disclosure of intended use by the firm when gathering consent. The current situation is more akin to my bank knowing my shoe size, just because they can, and sharing that with affiliates; rather than the bank collecting credit rating specific data for their own calculations.

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.

It may be because I'm not an economist but it sounds like Rubin makes a weak point (coupled with my observation in parenthesis) here: "Differential pricing is bad (mostly to the poor), but some good could come from it (mostly to the rich), so it's okay." The way I see it, if one side has perfect information about the other, but not vice versa, then the negotiation is flawed and will not work to mutal benefit. Even if you could argue that this is not true, people who take steps to prevent their information from being collected and tagged with their identity would be in a stronger bargaining position and would benefit more than the consumers who didn't.

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.

It's true, harm from privacy violations is difficult to asses. If only someone wrote a book about it providing some sort of comprehensive taxonomy of privacy harms. In short, it is very short sighted of Rubin to claim that violations of online privacy cannot lead to harm.

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.

The panopticon is a well understood and flawed model. Giving firms and governments all the information reduces consumer liberty and gives firms/governments all the power. There needs to be a balance; banks can't have "anonymous" banking with them, and governments can't allow "anonymous" through their borders. However, governments shouldn't be able to ask banks about all their customers because they feel like create some sort of creepy total awareness office. If anything allowing consumers more control over their information and firms/governments less control makes it easier for consumers to keep those firms/governments honest leading to a more efficient market.

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.

I'm calling wild assertion on this one. While the mass of information gathered is likely used for benign purposes, the exceptions which cause harm and the potential for this harm to occur if no controls are in place, is enough to justify their existence. That's why even though the majority of the populace don't commit crimes, we still have police for the few who do.

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.

My Security Planet

Feeds

Recent items

Posted: September 7th, 2010, 2:29pm CDT by michael

Tags: [edit]

Posted: September 7th, 2010, 10:58am CDT by Ryan Barnett

Tags: [edit]

Posted: September 7th, 2010, 7:25am CDT

Tags: [edit]

Posted: September 7th, 2010, 3:09am CDT

Tags: [edit]

Posted: September 7th, 2010, 2:36am CDT by QuadsZilla

Tags: SEO [edit]

Posted: September 7th, 2010, 1:51am CDT by noam

Tags: Commentary [edit]

Posted: September 6th, 2010, 9:57pm CDT by xssniper

Tags: Security [edit]

Posted: September 6th, 2010, 1:45pm CDT by jon

Tags: [edit]

Posted: September 6th, 2010, 7:24am CDT

Tags: [edit]

Posted: September 5th, 2010, 7:23pm CDT by jon

Tags: [edit]

Posted: September 4th, 2010, 12:53pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 4th, 2010, 10:53am CDT by RSnake

Tags: Webappsec [edit]

Posted: September 4th, 2010, 1:52am CDT by vanderaj

Tags: OWASP [edit]

Posted: September 3rd, 2010, 4:58pm CDT

Tags: [edit]

Posted: September 3rd, 2010, 12:41pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 3rd, 2010, 11:27am CDT by RSnake

Tags: Webappsec [edit]

Posted: September 3rd, 2010, 9:31am CDT by michael

Tags: [edit]

Posted: September 3rd, 2010, 8:43am CDT by Jeremiah Grossman

Tags: [edit]

Posted: September 3rd, 2010, 7:55am CDT by Romain

Tags: [edit]

Posted: September 3rd, 2010, 6:27am CDT

Tags: [edit]

Posted: September 2nd, 2010, 4:48pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 3:21pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 3:08pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 2:59pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 2:50pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 2:43pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 2:15pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 1:46pm CDT

Tags: [edit]

Posted: September 2nd, 2010, 12:19pm CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 12:00pm CDT by swiblog

Enclosure: [download]

Tags: [edit]

Posted: September 2nd, 2010, 11:21am CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 11:01am CDT by michael

Tags: [edit]

Posted: September 2nd, 2010, 9:50am CDT by Guest

Tags: Software Security [edit]

Posted: September 2nd, 2010, 7:33am CDT

Tags: [edit]

Posted: September 1st, 2010, 9:17pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 1st, 2010, 8:56pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 1st, 2010, 8:48pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 1st, 2010, 8:38pm CDT by RSnake

Tags: Webappsec [edit]