Computer Security Mashup

More rss feeds from SecurityFocus

News, Infocus, Columns, Vulnerabilities, Bugtraq ...

Mark Rasch: Hacker-Tool Law Still Does Little

Hacker-Tool Law Still Does Little

Adam O'Donnell: The Scale of Security

The Scale of Security

Mark Rasch: Lazy Workers May Be Deemed Hackers

Lazy Workers May Be Deemed Hackers

>> Advertisement <<
Can you answer the ERP quiz?
These 10 questions determine if your Enterprise RP rollout gets an A+.
http://www.findtechinfo.com/as/acs?pl=781&ca=909

Gunter Ollmann: Time to Squish SQL Injection

Time to Squish SQL Injection

Infocus: WiMax: Just Another Security Challenge?

WiMax: Just Another Security Challenge?

Infocus: Data Recovery on Linux and ext3

Data Recovery on Linux and <i>ext3</i>

>> Advertisement <<
Can you answer the ERP quiz?
These 10 questions determine if your Enterprise RP rollout gets an A+.
http://www.findtechinfo.com/as/acs?pl=781&ca=909

Infocus: Responding to a Brute Force SSH Attack

Responding to a Brute Force SSH Attack

Infocus: Enterprise Intrusion Analysis, Part One

Enterprise Intrusion Analysis, Part One

News: FBI and SOCA plot cybercrime smackdown

Fri, 23 Oct 2009 00:00:00 -0700

FBI and SOCA plot cybercrime smackdown

>> Advertisement <<
Can you answer the ERP quiz?
These 10 questions determine if your Enterprise RP rollout gets an A+.
http://www.findtechinfo.com/as/acs?pl=781&ca=909

News: Security firm chokes sprawling spam botnet

Wed, 11 Nov 2009 00:00:00 -0800

Security firm chokes sprawling spam botnet

News: Researcher busts into Twitter via SSL reneg hole

Mon, 16 Nov 2009 00:00:00 -0800

Researcher busts into Twitter via SSL reneg hole

News: Major IE8 flaw makes 'safe' sites unsafe

Mon, 23 Nov 2009 00:00:00 -0800

Major IE8 flaw makes 'safe' sites unsafe

>> Advertisement <<
Can you answer the ERP quiz?
These 10 questions determine if your Enterprise RP rollout gets an A+.
http://www.findtechinfo.com/as/acs?pl=781&ca=909

Brief: No cyberwar yet, but soon, says firm

Tue, 17 Nov 2009 00:00:00 -0800

No cyberwar yet, but soon, says firm

Brief: Firms fail to secure mobile, cloud data

Fri, 20 Nov 2009 00:00:00 -0800

Firms fail to secure mobile, cloud data

Brief: Climatologists hot over e-mail hack

Mon, 23 Nov 2009 00:00:00 -0800

Climatologists hot over e-mail hack

>> Advertisement <<
Can you answer the ERP quiz?
These 10 questions determine if your Enterprise RP rollout gets an A+.
http://www.findtechinfo.com/as/acs?pl=781&ca=909

Brief: Microsoft releases password attack data

Fri, 27 Nov 2009 00:00:00 -0800

Microsoft releases password attack data

News: FTC persuades court to shutter rogue ISP

Fri, 05 Jun 2009 00:00:00 -0700

FTC persuades court to shutter rogue ISP

News: Web attacks hit U.S., South Korean sites

Wed, 08 Jul 2009 00:00:00 -0700

Web attacks hit U.S., South Korean sites

>> Advertisement <<
Can you answer the ERP quiz?
These 10 questions determine if your Enterprise RP rollout gets an A+.
http://www.findtechinfo.com/as/acs?pl=781&ca=909

News: Hacker charged with Heartland, other breaches

Tue, 18 Aug 2009 00:00:00 -0700

Hacker charged with Heartland, other breaches

News: Popular apps need better patching, says report

Thu, 17 Sep 2009 00:00:00 -0700

Popular apps need better patching, says report

The Joel Test: 12 Steps To Better IT Management

Mon, 14 Sep 2009 12:59:24 -0700

(With apologies to Joel Spolsky, from whom this post was ripped off)

Have you ever heard of COBIT? It’s a fairly esoteric system for measuring how good a network security team is. No, wait! Don’t follow that link! It will take you about $3,500,000 just to understand that stuff. So I’ve stolen my own, highly irresponsible, sloppy test to rate the quality of a network security team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to law school.

(I’m using network security as a synecdoche for all of enterprise IT, but I think I’d win an argument about whether the same issues apply to the team that manages the WebSphere deployments and all the WAR files and whatnot.)

The Joel Test

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

1. Do you use source control?

Programmers have had source control since the 1980s. With source control, every change you make to a file is tracked. Any line of code can be tracked diff-by-diff back to the origin of the file. Are your firewall rules under version control? If you don’t have source control, you’re going to stress out trying to get engineers to work together. They’ll have no easy way to know what their coworkers did. Mistakes can’t be rolled back easily. And source control backs up all your rules, in a single place, so you can reconsitute that PIX ASA that just threw a rod from a cold spare in minutes.

2. Can you make a build in one step?

By this I mean, how many steps does it take to get an access rule change deployed from the latest source snapshot? On good teams, there’s a simple process you can follow to get a firewall completely deployed from scratch, which checks out the company standard configuration, adds the right doodads to the configuration, tracks the device in inventory, etc.

A process that takes more than one step is prone to errors. And when you’re under pressure because Pepsi needs you to punch a hole for a database management app that Coke has forbidden you from allowing near their dat,a, you want to have a very fast cycle of making sure your rules work. If it takes 20 steps to deploy a rule, you’re going to crazy and you’re going to bring the network down.

3. Do you make daily builds?

When devs use source control, sometimes people check things in that break the build. The usual pattern is, things work fine on the developer’s machine, but she forgot to add a header file, so nobody else can build. “Breaking the build” can cost developers whole days of productivity, so good teams have rules to detect and punish people who do it.

Network security engineers have a “build”, but when they break it, they don’t just kill the rest of the team’s productivity. They kill the network. So good network security teams want to make sure people can work on projects that touch access rules without getting unreviewed changes into the configurations that will get pushed out during the next change window.

4. Do you have a bug database?

I don’t care what you say. If you’re managing access rules, even if you only have a few devices, without an organized database listing all the change requests that produced the rules, you’re going to have crappy firewall rulesets. Lots of engineers think they can hold the rules in their heads. Uh huh. What hosts on your network are allowed to talk FTP to the outside world, and why? Thought so. You absolutely have to track change requests formally.

Change tracking can be complicated or simple. A minimal tracking system needs to record the following facts for every request:

Who requested the change
Why they requested it
Was the request approved
Who was the request assigned to
What devices had to change to accomodate the request

You can absolutely DIY this; lots of teams build their own tracking systems in-house, and they work great.

5. Do you fix bugs before writing new code?

When Joel Spolsky worked on the Excel team at Microsoft, he picked up a story about Word for Windows, which slipped constantly because the schedule allowed no time to fix bugs. The quality of the codebase decayed, to the point where developers were writing “if 2+2 !+ 4 return 4” or whatever. They referred to this as “infinite defects methodology”, converted to “zero defects methodology”, which meant they got to fix bugs, and eventually shipped. And when Joel Spolsky was in the alps fighting grizzly bears, he used his magical fire breath and saved the maidens fair.

But I digress.

Once every year or so, big companies commission small companies like ours to do the “annual external pen-test”, in which testers try to break in through the perimeter firewall. Even though I don’t do a lot of network pen-testing, I’ve done a couple. And on all of them, some stale old Win2k host gets left exposed or some branch network has 445/tcp open, because there are 20,000+ lines of firewall rules and rules only get added, never removed.

Just like with code, it is much more expensive to fix a bug early than late. But at least with software, you find out about bugs because your program crashes or a user sees the wrong header font size in the help file. With firewall rules, not so much. You mostly find out that you’re boned when you flunk some random audit.

Most of the same reasons developers need to fix bugs before writing new code apply to enterprise IT, too:

It’s easier to fix a bug when it’s right there in your face than to remember it or track it down later
It’s easier to predict to your customers when their changes are going to get completed when you know you aren’t going to lose 2 days fishing old SMB exceptions out of your rules after an MSRC announcement
It’s less stressful and less costly to fix things up front than to blow a change window or push an emergency change because of an advisory or a client audit.

6. Do you have an up-to-date schedule?

Which brings us to schedules. Because the dirty secret is, the rest of the IT team at your company probably hates you, because your job mostly involves saying “not yet” to their requests to change things on your devices. But that doesn’t cut it. Too many business processes are impacted by your workflow; clients can’t get brought online until the PMP-certified project manager checks off your box in the process, and so you’re a cost center, and the VP/Operations starts to hear about how one of next year’s priorities is to “streamline firewall management and reduce TCO”.

It’s possible to keep a schedule; figure out how fast you can complete a change, and track the number of outstanding change requests you have. It can take significant time to research and execute a complicated firewall architecture change, as long as you can communicate up-front to project teams how long it will take, and then come in on schedule.

7. Do you have a spec?

Documenting all your configuration is like writing a software spec: everybody agrees it’s a good thing, but nobody does it.

It’s weird that this is the case, because nobody in the company has a stronger opinion about how technology should be deployed and managed than the network security engineering team, but probably all you have is apocryphal Visio diagrams on a network share somewhere, and you’re much more likely to just throw another configuration line onto a device than to write a document that explains what you’re doing.

Documentation doesn’t have to be painful. You can just set up Mediawiki and start by writing a short paragraph for every device you manage. Or you can write programs that take inventory and analyze your configs. However you do it, you should be able to have a rule that says “no changes without updating the documentation”.

8. Do programmers have quiet working conditions?

And also, pet unicorns?

9. Do you use the best tools money can buy?

“Top notch development teams don’t torture their programmers […] and programmers are easily bribed by giving them the coolest, latest stuff”.

Things it’s crazy network security engineers don’t get to have include:

A network switch on their desk
Two monitors
A laptop with a big screen
Unlimited disk space
A place to get a new VMware image up with a couple of clicks
A license for Burp Suite

I could go on and on here, but the only reason I’m writing this is that Joel Spolsky has this as a Joel Test item. Motherhood, meet apple pie, and also see “pet unicorns”.

10. Do you have testers?

“Skimping on testers is such an outrageous false economy that I’m simply blown away that more people don’t recognize it”, which is probably why most network security teams have testers. There had to be something network engineering teams do better, processwise, than developers.

11. Do new candidates write code during their interview?

It’s hard to write code in an interview. Interviewing teams are so infamous for skipping this step that there’s a whole interview question methodology, the “FizzBuzz test”, that says “at least show me you can print the numbers 1-100 with every 3rd number as ‘fizz’ and every 5th as ‘buzz’”, which is a 1-liner in Ruby, but that’s how desperately teams need to know that candidates even know where the parens and the braces go.

And so here’s another thing network security teams do better. Because, do security engineering teams have this problem? Probably very few candidates actually know how TCP flow control works, or whether they actually need path MTU discovery enabled, but I tend to doubt that a lot of teams are staffed with people who couldn’t punch an exception into an IOS ACL set for FTP or DNS if they needed to.

12. Do you do hallway usability testing?

And here I concede that there is one item on the Joel Test that does not directly apply to network security teams.

My Point, And I Do Have One

There’s a seed funding firm called Y Combinator that is all the rage with the kids these days; they’ll give you ~$20,000 for your 2-person startup in exchange for 5-6% of the company even if you have almost no working code and you’re just out of school. Some surprisingly good companies have come out of YC. One of them is Dropbox, a hugely popular and powerful file synchronization system. A few days ago, Dropbox’s application to YC was posted. One of the grafs in the application talked about Subversion, and ended with “hackers [(developers)] have access to these tools, but normal people don’t”.

And its true of network engineering teams too. In a lot of shops, Subversion is space alien technology (and yes, it’s true of some dev shops, too). And where problems are recognized, as with issue tracking, they’re “solved” by massive enterprise management systems with their own headcount dedicated just to keeping Remedy working properly, and everyone hates it.

And of course this is a self-serving post, because “solving the Joel Test for firewall admins” could be the thesis statement for our product. But then, I’ve recently changed up roles at Matasano, and am managing Playbook instead of consulting, and I want to start talking more about what we’re doing. And here’s a way to start the conversation.

Good to be talking to you all again, by the way.

Take Survey, Get Free Huge Poster, Courtesy Of Me

Mon, 14 Sep 2009 15:00:50 -0700

OK, that’s 100 (actually a little more). We’ll still give away 50 more, at random, to people who complete the survey this week.

So, we made these posters. We meant to hand them out at Black Hat, but they didn’t get finished in time, even though we rushed them by —- among other things —- doing it ourselves without our designer, who will certainly mock us for the next year about the color scheme and perhaps you have a recommendation for a good print designer for us? And anyhow, here it is:

Yes, we have a fetish for hex charts. We also have “man ascii” in like 15 forgotten terminal windows on all our desktops. And now we can just look up at the wall. And here are some things to know about the posters:

They are big, by shwag poster standards. About as wide as a normal cubicle panel.
They are printed on heavy stock, which we thought would be a win but turns out not to be as much of a win as we thought but might be great for you.
The image here is not 100% accurate, because Preview.app botched the PDF->GIF transformation, so please don’t submit bug requests about it.
I am fully to blame for the terrible color scheme.

And you’re wondering, how do I get one of these posters? And I am here to tell you that today, one good way to get a poster is if you’ve ever been responsible for managing more than one firewall, you could: fill out our survey and help us figure out what to do next with Playbook, our firewall sync product.

Otherwise, you can wait, and we’ll come up with something else that will get you a poster shortly. I think they’re pretty cool, even if they are kind of crazy looking.

First 100 real submissions get free posters. Next 50 posters after that go out by lottery. We’ll let you know when that happens.

PS: I may already owe you a poster, in which case, drop me an email or a DM, and we’ll send one.

Ruby for Pentesters: Stupid FFI Tricks

Tue, 22 Sep 2009 12:25:22 -0700

Lately, Ruby has left me wondering whether I should go back to C or (gasp) python for my day-to-day coding. But then I took a breath of fresh awesome that convinced me to stay put.

Here’s a fun trick I stumbled into while playing around with FFI and Metasm in ruby.

This probably falls under the “stupid ruby hacker tricks” category. I’m also pretty sure the FFI guys never had this in mind as an exposed feature in their library. But damn if it isn’t refreshing when sometimes things work exactly as you hope they will.

When I see something like this work, it also occurs to me that my reluctance to leave the fireside coziness of my IRB prompt is a sign of something. Probably something unhealthy.

Scenario:

You’re coding in assembly language (for good, evil, or neutral) and you’d like to quickly test your code as you work. You know what would be great? It would be great to have a way to dynamically assemble and shove your instructions into memory someplace, then call them on the fly.

Solution:

Write a little wrapper to load your bytecode into memory and jump to it. No fussing with ELF/PE/whatever headers, overwritten return addresses on the stack, heap bugs, etc. This isn’t necessarily exploit development, just shellcode development. The goal is just to make sure your bytecode works the way you expect it to when you land on it.

So… you could:

Abuse a function pointer in C:

Here’s how you could do this in C with minimum fuss. Use malloc(3) and memcpy(3) to load your code from a command-line argument and cast the resulting heap memory address to a function pointer. Then call the function pointer.

 #include <stdlib.h> #include <string.h> int main(int argc, char *argv[]) { size_t bloblen; char *blob; void (*funcptr)(); if (argc > 1) { bloblen = strlen(argv[1]); // hope you're nullsafe! blob = (char *) malloc(bloblen); if(blob != NULL) { memcpy(blob, argv[1], bloblen); funcptr = (void *) blob; funcptr(); exit(0); } } exit(1); }

Or Abuse a FFI function pointer in ruby:

Here’s how you can (ab)use FFI from ruby to achieve the same effect. This reads the code from standard input instead of the command-line, by the way:

 begin ; require 'rubygems' ; rescue LoadError ; end require 'ffi' # Use FFI to stuff our bytecode somewhere on the heap. # here's the malloc(3)/memcpy(3) combo code = STDIN.read memp = FFI::MemoryPointer.from_string(code) # memp is now a pointer object FFI can use # Now we cast our function pointer. # # Yea so this is much nastier looking than: # # void (*funcptr)(); # funcptr = (void *) blob; # # It'd be swell if FFI stopped changing this interface, but # hey, beggars can't be choosers. I'm not complaining... funcptr = ## use FFI::Function for ffi-0.5.0. if FFI.const.defined?("Function") FFI::Function.new( FFI.find_type(ret), args, memp, :convention => :default ) ## use FFI::Invoker for ffi-0.4.0 - two flavors even! elsif FFI.const_defined?("Invoker") if RUBY_PLATFORM=='java' ## JRuby FFI FFI::Invoker.new(memp, args, FFI.find_type(ret), "") else ## and not Jruby... FFI::Invoker.new(memp, args, ret, FFI.find_type(ret), "", nil) end else raise "oh noes! this version of ffi is totally unfamiliar" end # Now we call our bytecode stub directly. # This is basically like saying "funcptr();" in the C version. funcptr.call()

FFI rocks in general. Ruby’s been lacking a good answer for python’s ctypes, and FFI is definitely the answer. But I’m stalking Wayne Meissner to make sure he keeps this feature around and maybe even gives it a standard interface.

As evidence that I’m mentally unhinged, here’s a version of that script with all kinds of superfluous and ridiculous additional features.

 Usage: asm_lab.rb [opts] < someassmebly.s -s, --sled=SIZE Add a nop-sled -g, --debug Add debug trap and spawn gdb in xterm. -f, --file=FILE Read input from file instead of stdin -r, --raw Input as raw bytecode -d, --drop_id=RID Drop real privs to RID -D, --drop_eid=EID Drop effective privs to EID -h, --help Show this message.

Um, a not so superfluous feature there: metasm!

Metasm rocks! ‘Nufsaid.

Indie Software Security: A ~12 Step Program

Thu, 24 Sep 2009 13:02:26 -0700

Every autumn, John “Wolf” Rentzsch holds an indie software development conference for Apple developers in Chicago called C4. It’s really excellent. I’d recommend you attend, but it’s become one of those things that sells out the day he announces the tickets. We don’t get to go this year.

But last year, we did get to go. Because we’re local, Rentzsch asked us to get up on stage and give a talk. So we roped in Nate McFeters, another local, and put together a security talk for indie Mac developers with no budget for security. What does a security talk for Mac developers look like? As it turns out, it’s very much like the talk we think every indie developer, Mac or not, should see, and it’s very much unlike the talk the rest of the security industry is giving. And, without further ado:

Here’s our talk. Here’s the slides.

(But see the bottom of this post for some caveats about this talk.)

Indie Software Security: A ~12 Step Program

You’re launching the first version of your web application. You’re pre-revenue. Your every waking moment is consumed with the backlog of product enhancements you believe will help your app break through. And you’re about to land on the top of Reddit because of a security flaw.

We’re software security people. Our industry is built around breaking software. People like us are the ones putting people like you on the top of Reddit. People like you are the weak, and people like us are the tyranny of evil men.

You’re listening to us because you’ve finally given up trying to control the security of your application. Everything else you’ve tried has failed. The advice the “security industry” has given you has had negligible business value, because you’re not a Fortune-500, and you aren’t shipping shrink-wrap to 1,000 enterprises. And the failure of that advice is partly our fault. This is our response.

Read the advice we’re giving here. See how you’re doing. Honestly, are you on top of these issues? Remember, there is no disgrace in facing up to the fact that you have a problem.

Step 0: Are You Our Audience?

Do you make lots of money? Do you have lots of money? Are you taking credit card numbers? Do you have a formal SDLC? Do you actually employ security researchers? Does anyone in your company have “security” in their title? Answer “yes” to any of these?

You’re not our audience. You have different problems. Some things we say you should do in this post, you should not do. Other things we say not to do, you can go ahead and do.

With that said, critique away.

Step 1: Stop Caring So Much

Here are five things that will kill your startup before software security does:

Slowness
Poor graphic design
XML
The RIAA
Product Marketing Managers

The graveyards in this town are littered with the corpses of startups that pinned their hopes on advanced security. Better engineers than you have tried and failed. Theo de Raadt coordinated the first large-scale security codebase audit. His reward:

~~Three years without a~~Only two remote holes in the default install!

This is not a killer marketing message.

Or, try Daniel Bernstein. qmail shipped for ten years without an exploitable remote flaw. It has the best security track record of any piece of mainstream software, ever. But Bernstein got integer signedness wrong in one place —- resulting a bug that you can’t even exploit on any modern system —- and now every security blurb about qmail is up for debate.

We don’t want you to be the guy in the PG-13 movie, the one everyone’s really hoping makes it happen.

37signals is not bad about software security. They’re incredibly successful. They make millions of dollars on an online contact manager. 37signals has a genius for marketing. They’re so money! It’s like Jedi Mind Shit! They’re not bad about security; they’re just not awesome about it.

We want you to be like the guy in the rated R movie. You know, the one you’re not sure whether you like him yet. Okay? You’re a bad man. You’re a bad man.

Step 2: First, Get Outreach Right

Do this first. Don’t waste time with anything else.

There are a lot of ways to be good at security without being awesome at it. Most of them don’t matter. This one does: you need to be smart about how you interact with people finding and reporting vulnerabilities in your products

Take, for instance, 37signals. There’s been a pretty negative response to their handling of the disclosure of a cross-site scripting vulnerability in their software. Why did that happen? Because if your company doesn’t act as if it knows how to handle security reports, the world will assume the worst of you, no matter how hard you’re trying.

This is literally the simplest security challenge your shop shouldn’t be screwing up:

Get your developers in a room, draw straws, and the short straw is now “security@mystartup.com”. She’s the “security contact”. You now have one.
Create a “security” page on your main site. It says, in a nutshell, “we’ve thought about security.” It does not talk about AES key sizes or RSA-OAEP.
Create a “security reports” page. Link to it from your “security” page. It says, in a nutshell, “here’s how to send us security reports, and we’re not going to be jerks about it.” The one 37signals set up is, we think, an excellent example of the genre.
Your “security reports” page needs to link to a PGP key. This is code for “we’ve given a moment’s thought to the idea that we might have a security flaw in our app reported to us”.
Fixes for security flaws are not features or enhancements. Don’t call them that. In fact, don’t even call them bugs. Give them “security IDs”. This costs you nothing, and is another subtle signal you can send that you’ve done this before.
For the love of god don’t argue about severities. You won’t win. Security researchers have more buzzwords to throw than you do. Even if you’re right, 50-75% of readers will assume that (a) you’re not right and (b) you’re being petulant.
Thank the people who submit security flaws to you, even if you don’t feel thankful.

If there’s one thing we want you to understand about vulnerability reporting, it’s this: however hard your startup has had to struggle to get press and attention, no practicing security researcher has had to work 1/100th as hard to get in the mainstream press. For a myriad of reasons, some good, many bad, everything security researchers do is newsworthy. They’ve drawn KK to your A7 suited. Don’t overplay it.

Step 3: Everything You Need To Know About Vulnerabilities In Two Bullets

There’s a sprawling literature about different kinds of security flaws. You can safely ignore it. If you try to stay up to speed, you’ll still lose, but you’ll miss the simple stuff. You only need to know two things, and here they are:

Bullet 1: Counting is scary. Many billions of dollars have been spilled dealing with one basic problem, which is that it’s hard to keep track of memory. If you understand this, you understand stack overflows, heap overflows, integer overflows, integer underflows, uninitialized variables, offset null-pointer attacks, and even that crazy pulseaudio Linux kernel flaw that depends on a compiler optimization.

Bullet 2: Content is scary. Many billions of dollars have been spilled dealing with one basic problem, which is that it’s hard to keep metacharacters out of user-controlled content that moves between different domains. If you understand this, you understand cross-site scripting, SQL injection, shell injection, xpath injection, and Nate McFeters GIFAR attack.

And so:

Initialize your variables to 0 or the empty string.
Abort your program when malloc fails.
Count, using unsigned integers, and don’t let them wrap.
Whitelist content to alphanumeric.
Swap punctuation for HTML entities.
Go live your life.

But, but, but! What about that Black Hat talk that Mark Dowd gave about the plug-in interfaces in all those browsers? What about that crazy Flash exploit he wrote? Those were cool. They made waves in the security industry. But they weren’t about you. His audience is security researchers, not indie startups.

Step 4: Seven Deadly Features Of Indie Software

Here are 7 features that you simply shouldn’t implement yourself.

Encryption, unless it’s GPG for data at rest, or SSL for data in motion.
Password storage, unless it’s bcrypt.
Writing anything directly into the DOM of a browser via a plugin or any third-party software.
Installers.
Things that listen on network ports when your code is running, or (just as likely) all the time. Even —- no, wait, especially —- if it’s a web server.
Content-controlled code. For instance, if you’re designing a web templating system for a PHP app, the templating language cannot be PHP.
File download or, worse, upload.

People hear this list and they think we mean “be really careful when you implement these features”. We do not mean “be really careful”. We mean “don’t do it”. Change your app design so it doesn’t need the feature. If you can’t get dodge the feature, find its best-known, most-beloved implementation, and use that instead.

Step 5: Deploy Rubber Chicken Security

Here are some security features that don’t really do anything for your security, but that you should consider doing anyways:

Big long random URLs. Nothing says “security” like a big long random URL.
SSL. Use it wherever you can, and then you get to put the little graf on your “security” page about how you use “the same kind of security that banks use”.
Little lock icons.
Encoded inputs and outputs. Don’t just stop at Base64; jumble the Base64 character set up, so when people decode it, it looks like it’s been encrypted.
Encryption. Wait, didn’t we just say not to use encryption? Yes. Don’t rely on encryption. Don’t care about the encryption. But do scramble things. And don’t just use AES; add or subtract a couple of rounds (a 1-line change in your AES code), so that a standard AES implementation won’t decrypt things properly.
Write things in a “safe” scripting language instead of C.
Buy “Hacker-Safe” certification, or get PCI certified, so you can put a little seal on your site.

None of these things really protect you. For every item on this list, there’s a domain-specific threat that’s far more important than what that feature is trying to address. Some of these features do nothing for you whatsoever.

But that doesn’t mean you shouldn’t take advantage of them. Some of them improve your marketing. Some of them raise the bar, very slightly, on finding flaws in your site, which may somewhat improve the quality of security researchers you deal with. Just don’t talk about this stuff in arguments with security people, and you’ll be fine.

Step 6: Fuzz

And now it’s time for Secrets of the Security Masters.

Every year, the security industry gets together at Caesar’s Palace in Vegas for Black Hat, the most important conference in software security. A huge chunk of the vulnerability research community submits talks. Most of these talks get significant press. And 50% of them follow a predictable pattern:

Here is a new technology that is in the news or that secretly controls our lives.
Here is the fuzzer I wrote for this important technology.
Here are the horrible flaws I found when I ran that fuzzer.

(Hey, we’re guilty as charged here).

What’s a fuzzer? Very simple. A fuzzer is something that knows how to talk to something else, using a protocol or a file format or an SDK, and that systematically replaces parts of the input with progressively scarier inputs —- long strings, SQL metacharacters, long strings seperated by various forms of punctuation, long strings seperated by SQL metacharacters, the 4 numbers clustered around every bit position in 16, 32, and 64 bit numbers, and so on.

You’re a software developer. You can write this code. For instance, part of your application handles vCard contacts. Write the vCard contact fuzzer. Run it against your application. If you wrote your fuzzer the same way most consultants write theirs, it will take a day or so to run. Fix what it finds.

If you’re a web developer, you’re in luck. Somebody wrote a really good fuzzer you can just go buy for a couple hundred bucks. It’s called Burp Suite. You can about the “Proxy History”, “Repeater”, and “Intruder” tabs. Buy it, run your application through it, and figure out how to use those these Burp features. Cover every input in your application. That’s almost 90% of what every pro web-app pentester is going to do.

(You want the commercial version, not the free version.)

Step 7: Your Code Isn’t A Secret

This last point is easy, and you’re probably already on the same page as us.

A couple years back, Nate Lawson reverse-engineered the Bay Area FasTrak tolling system, which uses an RF protocol to tell tollbooths to debit your toll account. To pull this off, Nate got a FasTrak dongle and reversed the hardware, at one point going as far as decapping the chip to enable the JTAG debugging interface.

Nate Lawson is an extremely smart guy. But he has a bill rate. He’s part of this industry. Any company that wants to work with him can pay him, and he’ll do that same stuff to whatever app they sicc him on.

My point here, and I do have one, is that you are doomed. The state of the art in reverse engineering has advanced to the point where, on general-purpose computers, it’s mostly point-and-click.

Nothing in your software should depend on the security of your source code. Even more importantly, you can’t fetishize your source code. If you communicate to the world that your code is hard to reverse engineer, then it’s a “win” for a security researcher just to have reversed it, whether or not they find anything interesting from doing so.

If you’re shipping code written in anything other than C, you should understand that you have shipped your source code. Even if you ran it through an obfuscation product of some sort (another rubber chicken). An easy way to absolutely convince people who know security that you don’t know anything about security is to make an argument that involves how hard it would really be for an attacker to figure out how your software works.

Step 8: And that’s it.

We’re short some steps, and that’s because for an indie development shop, those steps don’t matter. So few people are getting this stuff right that it seems pointless to talk about the rest of it. And that’s sad, because what our program recommends costs almost nothing, doesn’t involve certification or third-party testing, and immediately improves outcomes in security incidents.

Stop freaking out about security. You’re worrying about the wrong things anyways. Get this simple stuff right, and then get on with your life.

Some quick caveats about the talk itself:

We gave this talk a year ago.
We went back and annotated the slides, which really don’t stand by themselves, and we know that too.
YES I HAVE ARMS. It was the only clean button-up shirt I had that day.
Again, this is a talk aimed at indie Mac developers. If you’re a large ISV, a bank, a Fortune 500 company, we know: you do not want, you cannot use.

Ruby For Pentesters - WIN32OLE

Sat, 26 Sep 2009 16:43:53 -0700

This week in our Ruby For Pentesters series I wanted to cover a Ruby library we have used a lot over the past year or so. Using Ruby on Windows is not one of the most exciting things I can think of. But there are times when you have no choice, working with ActiveX controls is one of those times.

Working with COM objects can be tricky, its a complex and sometimes confusing technology. Lucky for us, Ruby provides us with a library called WIN32OLE by default. WIN32OLE can be used for parsing and controlling COM/OLE components from Ruby. For example, we can use the WIN32OLE library to open up and play with Internet Explorer.

    require ‘win32ole’

    ie = WIN32OLE.new(‘InternetExplorer.Application’)
    ie.visible = true
    ie.navigate(‘http://www.runplaybook.com’)

We passed in the ProgID for Internet Explorer and sent it to a URL of our choosing. Pretty standard stuff for a COM interface. But it’s pretty neat how seamlessly it works form Ruby.

Do you subscribe to milw0rms RSS feed? Its full of ActiveX vulnerabilities. But let me fill you in on a little secret, most of them are nothing more then feeding some random ActiveX controls eatAString() method a bunch of A’s. But how are these obscure (it’s called sarcasm people) and seemingly exploitable bugs found?

Well I’m here to show you! And I promise by the end you will be finding bugs in some random ActiveX control on your box. When an ActiveX control is marked ‘Safe For Scripting’ it usually exposes a bunch of methods and properties that the browser can call or set from a scripting language like Javascript or VBScript. This is what makes ActiveX bugs fun: ITS NATIVE CODE. But how can we find these interfaces and start poking at them with Ruby? WIN32OLE of course.

Note: We won’t go too deep into the details of COM/OLE here, check out http://www.cert.org/archive/pdf/dranzer.pdf or http://uninformed.org/?v=9&a=2&t=txt if your interested in a more detailed write up.

WIN32OLE can do a lot more then just control InternetExplorer. We can use it to list all of the properties and methods any ActiveX control exposes. Lets drill down and focus on an individual ActiveX control that we can start fuzzing. Microsoft XP ships with an ActiveX control named ‘htmlfile’. You can read more about it here http://cometdaily.com/2007/11/18/ie-activexhtmlfile-transport-part-ii/ and here http://msdn.microsoft.com/en-us/library/aa752574(VS.85).aspx. This is a good example control because it contains a lot of methods we can play with. Heres some small example ruby code that demonstrates how to get a list of methods the control exposes:

   require ‘win32ole’

   a = WIN32OLE.new(‘htmlfile’)
   methods = a.ole_methods.select { |m| m.visible? }
   methods.each do |meth|
       puts “#{meth.name}(” +
           meth.params.map {|p| “#{p.ole_type} #{p.name}” }.join(‘, ‘) + “)”
   end

You should have seen a bunch of junk scroll up your terminal, junk like:

   cloneNode(BOOL fDeep)
   removeNode(BOOL fDeep)
   swapNode(IHTMLDOMNode otherNode)
   replaceNode(IHTMLDOMNode replacement)
   appendChild(IHTMLDOMNode newChild)

What you saw was WIN32OLE opening the ‘htmlfile’ control by using its ProgID and dumping the methods exposed by the control along with type information. Great, now we know what methods we can call into and what type of arguments those methods are expecting. With this information we can start generating test cases and looking for bugs. But we’re getting ahead of ourselves here, first we need to understand how to instantiate the control in a real-world way. We can use some simple HTML and Javascript for that:

   <html>
    <script lang=’JavaScript’>
       var axobj = new ActiveXObject(“htmlfile”);
    </script>
   </html>

Note: Yes, its possible to fuzz directly into the control via WIN32OLE but were interested in vulnerabilities we can reach via Javascript within Internet Explorer. For this reason we stick with the ‘fake webserver’ technique.

Now if we wanted to call the cloneNode() method within htmlfile our Javascript looks like this:

   <html>
    <script lang=’JavaScript’>
       var axobj = new ActiveXObject(“htmlfile”);
       axobj.cloneNode(1);
    </script>
   </html>

So now we need to use Ruby to automate all of this and find some bugs. Enter AxRub.

AxRub is a tool I threw together and discussed this July at Blackhat 2009 during our Ruby For Pentesters talk. AxRub was inspired by HD Moore’s AXMan, which is an impressive tool, but difficult to use on a targeted penetration test. AxRub makes the process of fuzzing ActiveX controls much more targeted, and fast! It’s very early stage code and needs a lot of improvement, your ideas are welcome. You can grab AxRub here http://github.com/struct/AxRub

Here is an overview of how it works:

   1. Use WIN32OLE to get a list of methods/properties our target ActiveX control exposes
   2. Setup a small fake web server
   3. Listens for connections from IE
   4. Generate test cases and serves them up via HTML

Demo:

   C:/> ruby axrub.rb htmlfile

Now connect to http://localhost:8080 with Internet Explorer and wait for those quality 0days to roll in.

A C++ Challenge

Fri, 09 Oct 2009 13:51:13 -0700

Let’s say you show up at an interview.

The interviewer asks whether your comfortable reviewing C code.

You say “sure!”, confident in your ability to spot a bad call to memcpy() on the spot.

The interviewer asks you if you have any experience auditing not just C, but C++.

Again, you confidently respond “no problem!”.

The interviewer presses further: “What about the intricacies of C++ templates and class instantiation at the assembly level?”.

This time you pause for a moment to ponder the question …

C++ lends itself to much more complex vulnerabilities then plain old C. From templates to string classes, C++ raises the skill level required to play the memory corruption game. And while the quality of C/C++ code we see has increased dramatically over the years, a lot of developers still don’t understand the more obscure C++ bug classes.

I recently found a vulnerable C++ code pattern that I wanted to share with our readers. But instead of just writing some boring technical blog post, Matasano would like to present a C++ audit challenge to our audience. It consists of a contrived vulnerability that follows the same vulnerable code pattern. Our rules are simple:

1. We give you working C++ source code you can compile with g++

2. You audit the source or binary, find the bug and submit your findings via email to: chris _at_ matasano.com All submissions should include a paragraph explaining where the vulnerability is, why its vulnerable, your exploit it and how you would fix it. A working exploit is required to win, but we will also post correct runner-up submissions that don’t include one.

3. Matasano announces the best three correct submissions and sends them Matasano branded magnet and posters (sorry no cash prizes!)

The quicker you submit, the better. Following the contest’s conclusion we will present a follow-up post that goes over the details of our contrived vulnerability and how to exploit it. More importantly, we will also blog about the real world vulnerability we found with a similar code pattern.

The contest vulnerability is confirmed exploitable on Linux and OS X. If you’re an experienced security researcher you can probably spot the bug in just a few minutes. Maybe seconds! We don’t expect to stump the Mark Dowds of the world, but if we can have some fun and educate a few developers in the process then were all for it.

We also ask that you don’t post any answers in the comments, but we can’t stop you and we certainly aren’t in the business of deleting legitimate comments. So without any further delay, you can download our challenge HERE

Blog-fix-omatron: DH Parameter Tampering Explained

Wed, 14 Oct 2009 19:14:16 -0700

When we moved the blog off Wordpress, the new host had trouble with our XML export. So we’re missing posts, and I’m gradually adding them back.

Here’s one you may have missed back in ‘07. It explains how to beat bad implementations of Diffie Hellman and SRP:

Adam Bozanich Did Not Uncover An NSA IPSEC Conspiracy (but he found a pretty cool bug).

Corporate Pentesters: Fill Out Survey, Get Big Poster

Wed, 14 Oct 2009 19:20:38 -0700

[Update: That was fast! We’re at 97 submissions. 3 more and we go to lottery mode. For the rest of the week, if you fill out the survey, you will almost certainly get a poster. We’d give everyone a poster, but they cost a couple bucks a piece to ship.]

A few weeks ago we ran a survey for firewall operators. The results were a huge win for us. But most of our readers aren’t firewall operators. A lot of you are company pentesters, though. Are you part of a company application security team? Fill out a survey, and we’ll send you a poster. It will look marginally better and be significantly bigger than the picture below.

Take the survey here. It’ll take you less than 5 minutes.

The first 100 responses will get posters, and we’ll ship 50 more posters by lottery if we go over 100 responses (we’ll let you know in this post if that happens).

A C++ Challenge - The Conclusion

Thu, 15 Oct 2009 17:04:55 -0700

The contest is over! We got some good submissions and as expected a few security researchers found the bug rather quickly. The sample code had numerous defects, however not all were exploitable. Here are our top 3 correct submissions in order they were received:

1st Drew Yao: With the quickest submission and first exploit. He exploited the bug on OSX Snow Leopard
2nd Kevin Easton: Sent in code that produces an exploit file
3rd Evin Robertson: With a great fuzzing technique for initially finding the bug (valgrind a.out /dev/urandom)

Other correct entries:
Joe Damato - Joe did a great write up on the challenge here
Rachel Blum
Anonymous 1
Anonymous 2

In addition to our contest submissions, we promised we would provide an answer to our vulnerability challenge, and here it is. The example code has a lot of issues. Everything from missing NULL pointer checks to a missing free. The bug we were looking for is the size overflow in the argument to our new operator. Our program opens up a binary file and reads some values out of it using a _stream structure. From those first few values we get an integer ‘s->num_of_streams’, which of course we sanity check before using it as an argument to a memory allocator. Unfortunately our sanity check is broken in the following if statement:

   if(s->num_of_streams >= INT_MAX / (int)sizeof(int)) {
       safe_count = MAX_STREAMS;
   } else {
       safe_count = s->num_of_streams;
   }

The problem with this check is that our Object class is not sizeof(int). We assign safe_count the value of ‘s->num_of_streams’ and go on our way. Following this bad check we call the C++ new operator to allocate an array of class instances representing each stream in our file. Unfortunately g++/libstdc++’s new operator allows for overflow to occur. This happens because we are asking for new to allocate ‘safe_count * sizeof(Obj)’. This a known issue, but more on that later.

So now we’ve allocated a smaller number of class instances than ‘safe_count’ specifies. Following the allocation of our class instances a meta data structure is placed on the heap using malloc(), zeroed out and a function pointer is setup. Now we enter a for loop using our attacker controlled safe_count value. This is where our problems begin, our for loop allocates a temporary buffer with each iteration copying a stream from the file into it, a DWORD is read from the stream and the parse_stream() method is called for each class instance we allocated earlier. The parse_stream() method sets the class member variable ‘type’ to the value of the parse_stream() method ‘t’ argument. The location of class member variable ‘type’ should be in the heap because we allocated the class instance using the new operator. Unfortunately this is done for more class instances then we actually allocated earlier. This allows us to overwrite the function pointer in the ‘imd’ structure, by way of the parse_stream() method, and gain code execution. This happens because the parse_stream() method effectively performs a 4-byte overwrite into heap memory that contains the ‘imd’ structure.

The fix here should start at the sanity check of s->num_of_streams. We should declare num_of_streams unsigned. This value should then be validated such that s->num_of_streams is not greater then MAX_STREAMS.

We originally wanted to share a similar real-world code pattern but that bug isn’t officially patched yet and we wanted to get this post out. But thats OK because we can still talk about the core issue.

As our example showed you can easily misuse the new operator. This is a known issue in libstdc and was mentioned as far back as 2002 in this Blackhat presentation. Using new to allocate some storage space may be common but there is another similarly dangerous but slightly less used code pattern here, and thats using new to allocate an array of class instances. Most developers have learned to carefully inspect the size of an allocation before copying user data to it. But allocating too few classes can result in similar memory corruption and have subtle but exploitable consequences when all the right stars are aligned, and thats what this challenge was all about.

In the real world vulnerability we found exploitation was not as straight forward and may not even be possible. But the reason for that is actually an interesting story in itself (and by interesting I mean dry and boring). If the Obj class in our challenge had a constructor things would have been far different. Let’s add a simple constructor to our example:

   Obj(){ length = 0; }

To understand why this changes things you need to dive down and disassemble the code. Long story short, even though we tricked our application into allocating 8 classes, g++ compiles the code in such a way that constructors are called for every class instance we requested, all 357913943 of them! Now if the constructor does something like set some class member variables to NULL then our chances of exploitation are pretty slim. This is because our process will essentially rip through its own heap writing NULL bytes until it hits the end of the heap and crashes. Thats quite a destructive constructor! When a constructor like this isn’t present our fake class instances become an API for writing into arbitrary memory. Thats how you gain code execution in our challenge.

Some of our commentors made the point that this was not C++, but merely C with classes. To those commentors I would like to say ‘welcome to the real world’. Code patterns like this are why security vulnerabilities exist!

This code pattern raises some interesting areas for exploitation since your non-existent class instance(s) are basically an API for writing into arbitrary memory locations in the heap. Bad allocations from the new operator are a known problem, Michael Howard at MSFT has written about this issue before and MSFT did something about it! MSVC produces better code that doesn’t allow the integer overflow in the new operator to occur. Unfortunately g++ users are stuck with this issue for the forseeable future.

Ninja Threat Modeling

Tue, 20 Oct 2009 06:00:14 -0700

Conquer your fear

Like it or not, developing an attack plan for a penetration test requires standing up a rudimentary threat model. Not surprisingly, threat modeling often produces discomfort in the stomach and uncertainty in the heart of many testers, but you’ve got to cowboy up and do it.

You need to determine where you’re going to spend your limited testing time, which tools you want to pull out of your arsenal, and how to prioritize your findings after the test is complete. Testing an application while blind to the context of how it could be abused in a real world environment is a sure-fire recipe for disaster and embarrassment.

Start with an application overview sitting peacefully on your desk. A sudden bang, a quick diversion, a cloud of smoke - and a test plan appears in its place… Fear no more, for the guide to ninja threat modeling is here.

SDL: This isn’t the threat model you’re looking for

You’ve probably heard of threat models before, especially in traditional security development lifecycle circles. In that context, the threat models are generated in the requirements/design phase, which is much earlier in the process. It has spawned not just one, but two, Visio-driven toolsets from Microsoft and countless data-flow diagrams, attack trees, consulting engagements, and perplexed developers. When performed by a skilled and experienced team member, the model can be used to identify architectural weaknesses, guide default application behavior, and outline functional requirements for the product.

However, by the time you’re in the verification phase of the lifecycle, generating a formal threat model starts to yield diminishing returns. We recommend taking a short-cut with a set of assumptions that have served us well over the years.

Software would be great if it wasn’t for the users:
Client-side code assumptions

The attacker will have unfettered access to the client and will instrument all of the functionality (this includes the “secret” admin and debug functions), and all of the client-side controls will be removed.
If it accesses the network, there’s a man-in-the-middle.
All input will be malformed and unexpected - even from the trusted end user… who will happily introduce input from untrusted sources.
The source code is completely exposed - including any secrets stored in the code.
If the application runs at a privilege level that the attacker desires, he will attempt to abuse it for nefarious purposes.
Don’t assume the code you’re testing is the attacker’s final destination in his path of exploitation. If the code weakens the system’s security posture in any way, the attacker will abuse it.

“I’m sorry, Dave. I’m afraid I can’t do that”:
Server-side code assumptions

All of the assumptions for client-side code hold for server-side code as well. This includes the source code disclosure assumption if you’re shipping product. If you’re running SaaS, it’s more of a question of when, not if.
The attacker is going to sit on the same network segment as the application. There’s no firewall or filters. There’s a special place in hell reserved for products that require firewalls or filtering to protect themselves against attack.
The naming service that the product relies upon will be compromised.
The switching and routing fabrics will be compromised.
If you have more than one defined user, one user will want to do things as the other user.
If you have more than one defined role, a user in one role will want to perform functions in the other role.
An attacker may want to cover their tracks. If he can do it with subtlety, he will take that path if it is easy to do.
If it is exposed to the Internet, some yahoo will want to make it crash with an asymmetric attack (think packet of death or attack amplification).
If the application runs on a multi-user system, other users on the system will attempt to subvert the application through any and all resources they can access (such as the file system, shared frameworks, IPC, and others).
If the application uses URIs (HTTP/FTP/SMTP/ITMS, whatever), an attacker has compromised the innocent client and has access to the session command channel.

A return to olde SDL land?

With these assumptions in place, you could go ahead and do some basic data flow analysis. You should be able identify key entry points in the application where data and functionality cross trust boundaries. If you want to stay in step with Microsoft, feel free to pull out the STRIDE* model and apply the threat types to each entry point, keeping in mind the assumptions mentioned above. With the threat landscape outlined, you’ll find the STRIDE process will go faster than simply working from a blank data flow diagram without context.

However, ninja threat modeling uses data flow analysis as a clean-up task, rather than the opening salvo. We’re impatient and want to know the answer to the question,”What entry points should we really care about?” right away.

* As required by the SDL powers-that-be, I am obligated to mention STRIDE threat types (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) in all communications relating to threat modeling at least once.

Where there’s smoke, there’s fire

A heat-seeking approach to drive your test plan is just what you need. When we blather on about entry points, trust boundaries, and threat vectors, what we’re really thinking is “Where can I do the most damage in the shortest period of time?”

The ninja threat model relies on two techniques: incident and vulnerability history and the commission of deadly sins.

Those who cannot learn from history are doomed to repeat it

The first technique examines how the product or similar products have been abused in the past. Don’t just look up old advisories or bug reports - look for incident data. Did a product have a vulnerability that allowed malicious code to spread? Was the vulnerability discovered and abused by a 16-year-old to make lots of friends on the social networking platform of the day?

Examine these abuse cases and make sure you can recreate them against the application you’re testing. At the root of each one, there should be a vulnerability, a threat actor, and an impacted asset. If you’re stuck with dry vulnerability advisories, sometimes the researcher will have a good grasp on the impact of the finding and will document it well. In other cases, you have to watch out for advisories with overreaching statements or extreme speculation.

What’s nice about these types of derived threats is a good amount of the test planning is already done for you and can be lifted wholesale. Watch out for tunnel vision, though - time, platform specifics, or other dependencies may have limited the avenues available to the researcher or intruder. Make sure you’re looking for the pattern that indicates the flaw is present, not just performing a pattern match on yesterday’s exploit.

Where DIY should be DDIY - Don’t Do it Yourself

The second technique focuses on what developers get wrong most of the time - otherwise known as the “Deadly Sins”. The vulnerabilities introduced by these common flaws are mentioned for a reason: they get abused by threat actors on a regular basis.

Every security outfit has a list of their deadly sins, including Microsoft, SANS, OWASP, and Matasano, because lists are just that cool. We think ours is better for one major reason - our Deadly Sins are features rather than defects. As a result, our work fits into ninja threat modeling much cleaner than a laundry list of vulnerabilities.

It’s an issue of perspective and language. Developers don’t roll out of bed in the morning and say, “I’m going to code up a few SQL Injection vulnerabilities today!” Instead, they say, “I’m going to write the Advanced Search module for the Report Engine today!” When you hear this, your utter lack of faith in your development brethren should kick into overdrive and you should be busily entering “Test for SQL Injection here, here, and here” in your test plan.

We’ve appended our list of Deadly Sins for Web Applications for easy reference. Parts of it also apply to other sorts of applications. When you see these features, get out your red pen, add another page to your test plan, and start outlining how many different ways developers get these things wrong and how to test for it.

Time for the test plan

After wrapping up the heat-seeking exercises, it’s time to sanity check your work with data flow analysis including the selective application of STRIDE mentioned earlier. Hopefully, the overlap should be extensive. If it isn’t, you may be dealing with something that hasn’t been tested extensively and may bear some interesting fruit. On the other hand, you may have been assigned the most boring application known to mankind. Congratulations!

After following this approach, you should have a good definition of the application’s attack surface and the threat landscape which you will be attempting to recreate. As a result, you should be able to produce a meaningful test plan with a threat model that is defensible and sufficient to guide your engagement. You might even get away with doing one without a single Visio diagram.

Deadly Features for Web Applications

1. Security

Encryption
Hierarchical role/privilege management
Password storage
Password reset

2. E-mail functionality

3. Thick Clients: Web Applications In Name Only (WINOs)

4. File Upload/Download

5. Templating and Content-Controlled Code

6. Advanced Search

More Deadly Features for Applications

7. Persistent network sockets that accept arbitrary connections

8. Installers

9. Use of plug-ins or third party software to write directly to the DOM

10. Single Sign-On / Authentication Hand-offs

Nastygram: MySpace phish plants spy software

Mon, 09 Nov 2009 09:21:00 -0800

A new spam campaign targeting MySpace.com users once again illustrates the blended threat from junk e-mail attacks, experts warn. This latest run tries to lure recipients into giving up their MySpace credentials, and then attempts to trick victims into installing password-stealing malicious software. Attackers began blasting out the junk e-mails early Monday, according to researchers at the University of Alabama, Birmingham, Researchers at the school so far have tracked more than 30 Web site names associated with this attack, each beginning with "accounts.myspace.com" and ending in a United Kingdom country code domain (.uk). The campaign is nearly identical to one launched late last month targeting Facebook.com users, said Gary Warner, director of research in computer forensics at UAB Birmingham: Recipients are directed to a fake Myspace.com page and asked for their login credentials. That attack cycled through at least 242 different look-alike Facebook scam sites before the last was

Apple ships 50+ security updates

Tue, 10 Nov 2009 07:57:55 -0800

Apple has shipped a large security update for computers running its Leopard and Snow Leopard operating systems for the Mac. The bundle contains security fixes for more than 50 vulnerabilities, including updates for components like Adaptive Firewall, FTP server, QuickTime and Spotlight. The update applies to Snow Leopard (10.6.x) and Mac OS X Leopard (10.5.8) systems, as well as OS X Server versions of these operating systems. Users can grab the patches directly from Apple Downloads or via the Mac's built-in Software Update feature. Some of the individual fixes in these bundles are interesting in their own right. For example, Apple said that a vulnerability in Snow Leopard's Login Window could let a user log in to any account without supplying a password. Another update, this one for a bug in Leopard' Dictionary program, is limited to users on the local network, but gives a whole new meaning to the

Eight indicted in $9M RBS WorldPay heist

Tue, 10 Nov 2009 09:40:41 -0800

Eight men have been indicted on charges that they hacked into credit card processing firm RBS Worldpay, and helped steal more than $9 million in a highly coordinated heist nearly a year ago, the U.S. Justice Department said Tuesday. The 16-count indictment, which names individuals from Estonia, Moldova and Russia, is the first major break in a case federal investigators are calling "perhaps the most sophisticated and organized computer fraud attack ever conducted." "Today, almost exactly one year later, the leaders of this attack have been charged," said Sally Quillian Yates, acting U.S. attorney of the Northern District of Georgia, in a written statement. "This investigation has broken the back of one of the most sophisticated computer hacking rings in the world." The men are accused of cracking the data encryption that RBS WorldPay used to protect customer data on payroll debit cards, allowing them to clone the cards. Some

Microsoft plugs 15 holes in Windows, Office

Tue, 10 Nov 2009 14:22:53 -0800

Microsoft on Tuesday released software updates to fix at least 15 security flaws in Windows, Windows Server and Microsoft Office. One of the patches addresses a flaw so serious that users could find their Windows PCs compromised just by visiting booby-trapped Web sites. Richie Lai, director of vulnerability research for patch management firm Qualys, said the most dangerous vulnerability addressed in this month's updates is a flaw in the way Windows handles so-called "embedded font" files. An attacker could stitch specially made embedded fonts into a Web page and use this flaw to install malicious software when people merely browse the site with Internet Explorer on Windows 2000, Windows XP or Windows Server 2003 systems, Lai said. Microsoft said it believes hackers will quickly figure out a way to exploit this flaw for criminal gain. Andrew Storms, director of security operations for San Francisco-based security firm nCircle, agreed, saying the

A year later: A look back at McColo

Wed, 11 Nov 2009 07:50:01 -0800

A year ago today, the Internet community witnessed a remarkable event: The unplugging of McColo, a Web hosting facility in Northern California that for a long time controlled a majority of the spam-sending operations on the planet. McColo's two main Internet providers abruptly yanked the cord after Security Fix presented them with scads of evidence collected by security researchers tying massive amounts of spam and other illicit activity to McColo's network. The outcome, of course, is now well known: The volume of spam sent worldwide tanked overnight, and remained at diminished levels for many weeks. All sorts of other badness diminished as well (more on that later). But since then, the sizable chunk of virtual real estate previously occupied by McColo has remained eerily quiet. A review of more than 3,000 Internet addresses previously assigned to the hosting firm reveals an Internet ghost town, as if the entire neighborhood had

Brazilian Govt: Soot, not hackers, caused '07 blackouts

Wed, 11 Nov 2009 09:35:05 -0800

The Brazilian government is refuting a report aired on Sunday by the CBS news magazine 60 Minutes, which stated that power blackouts in the South American nation in 2005 and 2007 were caused by hackers. Meanwhile, a large swath of Central Brazil is still reeling from another massive blackout that occurred in the region Tuesday evening. Citing six unnamed sources in the intelligence, military and cybersecurity communities, 60 Minutes claimed that a two-day outage that affected 3 million people in the Brazilian state of Espirito Santo was caused by hackers hitting a utility company's control systems. Another, smaller outage in January 2005 also was caused by hackers, the report said. According to the Wired.com Threat Level blog, the utility company involved, Furnas Centrais Elétricas, said it "has no knowledge of hackers acting in Furnas' power transmission system." "Brazilian government officials disputed the report over the weekend, and Raphael Mandarino Jr.,

Featured Advertiser

NEC

Ads by Pheedo

Nastygram: Beware the NACHA gotcha

Thu, 12 Nov 2009 15:44:19 -0800

Cyber thieves on Thursday began blasting out millions of e-mails impersonating NACHA - The Electronic Payments Association, a not-for-profit group that develops operating rules for organizations that handle electronic payments, from payroll direct deposits to online bill pay services. The missives in this latest scam arrive with various subject lines, but all complain about an unauthorized, rejected or failed ACH transaction. Most regular Internet users probably will ignore this message, as few people probably even know what ACH stands for (ACH, or "automated clearing house" refers to the electronic network used by banks to process credit and debit transactions in batches). That's likely just fine with the attackers, who appear to be targeting bookkeepers at small to mid-sized companies -- people who actually recognize what a failed or rejected ACH transaction can mean for their business's bottom line and reputation. According to an alert at the real NACHA Web

Security update for Apple's Safari Web browser

Fri, 13 Nov 2009 13:22:07 -0800

Apple has shipped a new version of its Safari Web browser that fixes at least seven security vulnerabilities. The Safari 4.0.4 update is available for both Mac and Windows versions of the browser. Mac users can grab the latest version through Software Update; Windows users will need to use the bundled Apple Software Update application.

Microsoft warns of Windows 7 security hole

Tue, 17 Nov 2009 06:10:05 -0800

Microsoft has confirmed reports of a security flaw in its Windows operating system that hackers could use to temporarily destabilize Windows 7 PCs. The software giant also acknowledged that blueprints for exploiting the flaw are now available online. At issue is a so-called "denial-of-service" vulnerability in the component of Windows that handles the sharing of files and folders. Microsoft said attackers could use exploit code now publicly available to cause vulnerable systems to stop functioning or become unreliable. The flaw is present in Windows 7 and Windows Server 2008 R2, and does not exist in older versions of the operating system, the software giant said. In a security bulletin published Friday, Microsoft said the vulnerability would not let attackers install malicious software or take control over an affected system, and that any ill effects from an attack on this flaw could be remedied by simply restarting the PC. In addition,

Featured Advertiser

Wed, 18 Nov 2009 06:33:00 -0800

Experts: Smart grid poses privacy risks

Wed, 18 Nov 2009 06:33:00 -0800

Technologists already are worried about the security implications of linking nearly all elements of the U.S. power grid to the public Internet. Now, privacy experts are warning that the so-called "smart grid" efforts could usher in a new class of concerns, as utilities begin collecting more granular data about consumers' daily power consumption. "The modernization of the grid will increase the level of personal information detail available as well as the instances of collection, use and disclosure of personal information," warns a report (PDF) jointly released Tuesday by the Ontario Information and Privacy Commissioner and the Future of Privacy Forum (FPF), a think tank made up of chief privacy officers, advocates and academics. Smart grid technology -- including new "smart meters" being attached to businesses and homes -- is designed in part to provide consumers with real-time feedback on power consumption patterns and levels. But as these systems begin to

Bill would ban P2P use on federal networks, PCs

Wed, 18 Nov 2009 09:50:04 -0800

The chairman of the House Oversight and Government Reform Committee introduced legislation on Tuesday to prohibit the use of peer-to-peer (P2P) file-sharing software across all federal government computers and networks. The "Secure Federal File Sharing Act" would direct the White House's Office of Management and Budget to issue guidelines barring the use and/or installation of P2P software on federal systems, unless otherwise approved for a specific purpose. The bill also calls on OMB to develop a policy that would extend to networks and computers operated by agency contractors, as well as to personal computers of federal employees remotely accessing federal networks. "We can no longer ignore the threat to sensitive government information that insecure peer-to-peer networks pose," said Rep. Edolphus Towns, the Democrat from New York who chairs the House oversight panel, in a statement. "Voluntary self-regulations have failed so now is the time for Congress to act." The bill

FDA targets rogue Internet pharmacies

Thu, 19 Nov 2009 13:45:18 -0800

The U.S. Food and Drug Administration is pressuring a number of Internet service providers to shut off nearly 12 dozen Web sites alleged to be selling counterfeit or unapproved prescription drugs. The FDA's office of criminal investigations said it sent 22 warning letters to the operators of the sites, and alerted the appropriate ISPs and domain name registrars that the sites were selling phony pharmaceuticals, all without requiring a prescription. The agency said none of the sites represent pharmacies located in the United States or Canada, as most claim. According to the letters sent to owners of the 136 targeted sites, the online stores hawked everything from powerful controlled substances, including Valium and Xanax, to lifestyle drugs like Viagra and Levitra. Some sites even offered prescription drugs that have not yet been approved for distribution or sale in the United States, such as the anti-obesity drug Acomplia. "Many U.S. consumers

Alpha Software disclosure leads to confusion

Fri, 20 Nov 2009 10:15:36 -0800

A few days ago, Security Fix heard from a reader who received a breach notification so casual in tone that he asked me to verify whether it was for real. Sure enough, Burlington, Mass.-based database application company Alpha Software Inc. recently told customers that a data breach had exposed their payment information. That fact was confirmed by similarly confused users posting to the company's online forum. The e-mail notice to affected customers reads: November 9, 2009 Dear Customer, We have been informed that there has been a security breach at the Internet Service Provider where our web site is hosted. This may have resulted in your credit card information being compromised. While it is entirely possible that your credit card information has not been stolen, in the interests of caution, we recommend that you contact your credit card provider to discuss what steps, if any, they recommend. Going forward, we

New attack targets weakness in Internet Explorer

Mon, 23 Nov 2009 07:59:49 -0800

Blueprints showing attackers how to exploit a previously unknown security hole in versions of Microsoft's Internet Explorer browser recently were published online. The danger here is if IE users browse to a hacked or booby-trapped Web site that uses the exploit, that site could install malicious software. Microsoft has not yet issued an advisory about this threat. According to initial reports from Symantec and vulnerability management firm VUPEN, the exploit works against IE 6 and IE 7 versions only. The vulnerability apparently resides in the way IE handles so-called cascading style sheet information (CSS), which a great many Web sites use to control the design and formatting of text and other site elements. Symantec reports that the attack code is a bit buggy and unreliable at the moment, but that a fully-functional and more reliable exploit almost certainly will be released soon. Symantec advises IE users is to make sure

Spam 'Godfather' gets 51 months in prison

Mon, 23 Nov 2009 22:16:28 -0800

These past few days have seen some notable cyber justice cases: Late Monday, Alan M. Ralsky -- a man dubbed the "Godfather of Spam" -- was sentenced to 51 months in prison. And on Friday, a California man pleaded guilty in a case involving the sale of counterfeit high-tech computer parts to the U.S. military. Ralsky, 64, of West Bloomfield, Mich., joined two co-conspirators in earning stiff prison sentences for long careers of blasting junk e-mail. Following more than four years in prison, Ralsky will be subject to five years of supervised release and will forfeit $250,000 the government seized from him in December 2007, the Justice Department said. According to the government, Ralsky was a top promoter of so-called pump-and-dump scams, schemes in which fraudsters buy up a bunch of low-priced microcap stock, blast out millions of spam e-mails touting it as a hot buy and then dump their

PrevX and other projects

Wed, 28 Oct 2009 11:24:22 -0700

Posted by dave on Oct 28

So you can read one Immunity deliverable linked here:
http://www.prevx.com/ (look for "Independent Review").

Likewise, if you have wondered where all the Immunity Debugger scripts
ran off to, they were on the old Immunity Forum. We ripped the old forum
content out of the old database and imported into the new hotness, so
you can seem them all here:
https://forum.immunityinc.com/. I don't think Google spiders HTTPS sites
for some reason...

Re: PrevX and other projects

Fri, 30 Oct 2009 05:06:38 -0700

Posted by Shane Macaulay on Oct 30

The chart on their main page would be a lot more compelling if they had
conversely applied whatever method they used to collect that information.

""""These statistics are provided to show that all vendors miss threats
and cannot be interpreted to compare the effectiveness of one product to
another."""""

That seems to indicate they would show us their failure rate when
compared to these vendors? And...

MITM Attack on Smartphones whitepaper

Thu, 05 Nov 2009 17:54:33 -0800

Posted by Mayank Aggarwal on Nov 05

SMobile has released a detailed report on research indicating that smartphone users are just as susceptible to
man-in-the-middle (MITM) attacks as PC users. This report details the results of attempts to produce MITM attacks to
determine whether it is possible to intercept SSL encrypted communications between various smartphone devices and
servers. Of the devices that were tested, each of the major smartphone operating systems appeared to lack...

"We're in the top of the league."

Mon, 09 Nov 2009 10:57:35 -0800

Posted by Aaron on Nov 09

Anyone else catch the 60-minutes story about Cyber warfare? There are a lot of interesting anecdotes from Admiral Mike
McConnell (described in the story as the former top spy of the nation), Jim Lewis (director of the Center for Strategic
and International Studies), and Jim Gosler.

Some of the more WTF things admitted were:
- "Some foreign power" was able to penetrate the Pentagon by leaving infected thumbnail drives where military...

a brief interlude between exploits

Mon, 09 Nov 2009 11:40:25 -0800

Posted by dave on Nov 09

There's been a lot happening in the world, and usually everyone is too
busy to comment on it. Exploit devs sometimes think of the world as the
dark troughs in a storm ocean, where the peaks are the sudden insights
of truth provided by a really good exploit, where all of a sudden you
can see for miles. Or maybe I just made all that up. In any case:

CBS says that someone turned off Brazilian power using cyber attack:...

Re: "We're in the top of the league."

Fri, 13 Nov 2009 07:50:29 -0800

Posted by Nate Lawson on Nov 13

gold flake wrote:

The government is just a very large company. They experience the same
security problems as other big companies. I'm always annoyed to hear the
"we're under cyber attack via cyber warfare using cyber malware".

Please... you're under attack just like any other big company with
extremely valuable assets. You're not any more special than that. It's
possible the IRS is more valuable a target than Joe Random sergeant's PC.

Fedora 12 Fail

Wed, 18 Nov 2009 18:55:06 -0800

Posted by Dave Aitel on Nov 18

Probably the best Linux thread in months:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00945.html

To sum it up, Fedora 12 is defaulting to "Any user can install any
package from the repo and then exploit it to get root". So like, if
the repo signs something hilarious like "bob's vulnerable FTP
server.rpm", every Fedora 12 server is vulnerable. Unless you've
uninstalled PolicyKit or something else...

Re: Fedora 12 Fail

Thu, 19 Nov 2009 19:33:05 -0800

Posted by Kees Cook on Nov 19

I've seen variations on this sentence get repeated in a few places and I
think it's valuable to point out it should read as "Any _local_ user..."
(where "local" is defined by console-kit[1] -- see "ck-list-sessions"
command). This makes it a smaller scope of problem, but it should not
discourage anyone from reading the bug report anyway:
https://bugzilla.redhat.com/show_bug.cgi?id=534047

-Kees

[1]...

English Shellcode

Tue, 24 Nov 2009 07:42:00 -0800

Posted by dave on Nov 24

This hit Slashdot recently, and it's interesting.

http://www.cs.jhu.edu/~sam/ccs243-mason.pdf

One thing people always try to avoid mentioning in papers about
shellcode is size. But in this case, they say that a exit(0) Linux
shellcode is going to be 2K or so which is good to know. There's the
obligatory "our shellcode is too powerful to include a complete example
of!" which is pretty funny. Developing these sorts of techniques to...

Re: English Shellcode

Tue, 24 Nov 2009 11:16:54 -0800

Posted by Bob Auger on Nov 24

Darrin Barall spoke about this exact thing at blackhat in 2005.

http://www.blackhat.com/html/bh-usa-05/bh-usa-05-speakers.html (grep
Shakespearean Shellcode)
http://media.blackhat.com/bh-usa-05/audio/2005_BlackHat_Vegas-V31-D_Barrall-Shakespearean_Shellcode.mp3
http://mirror.fpux.com/HackerCons/Blackhat%202005/CD/BH_US_05_BARRALL.PDF

Winplot (.wp2 File) Local Buffer Overflow Exploit