This page has a lot of info on how we recruit. We're getting pretty good at turning systems programmers into breakers, and we love hiring from HN:

http://www.matasano.com/careers/

The great thing about this field is that it's always changing. A long-term dev job gives you a chance to master two or three different technology stacks. Your next three projects at an appsec shop might each be just two weeks apart, and each will use radically different technologies. Even (maybe even especially) with web software.

You could join one startup... or spend a couple years beating up all of all the startups.

Also: I understand why Cody didn't write it this way, but the reality is, if you're going to test web apps, Burp is the standard tool. You can use things like mitmproxy or even WebScarab, but most people end up in Burp. Burp is also extremely valuable for testing even if you're not doing appsec full-time.

(They aren't deliberately hard; they just cover a lot of ground --- you're starting with basic substitution ciphers and ending with RSA signature block forgeries).

I helped design them, and I'm really happy with how they came out. They're neat. You should see how many sets you can get through.

I hope it goes without saying that if you crush Sean's crypto challenges for fun and are interested in being a full-time appsec person, you will have our full and undivided attention. :)

I'd like to take the time and look over the crypto challenges.

I sent Sean an email. Even if I'm not in that latter category, it still sounds like a great chance to learn a little something about a field which intimidates but interests me.

Also sent an e-mail.

#1 Lack of honesty. Seriously, they promised releasing those crypto challenges publicly 2 years ago (Blackhat 11: Crypto for Pentesters) and never done so: https://twitter.com/matasano/status/101714851633700864. And now they're using them as a recruiting tool.

#2 Lack of humility: Matasano guys seem to disregard common tools like Burp scanner or Sqlmap. It's fine to cherry-pick tools to suite your needs; but if you choose to disregard them completely just because you feel they're associated with "Security Rookies" then you're more than likely to miss something, consequently disservice your client (they expect you, as a consultant, to find the most vulnerabilities regardless of tools used). Matasano may have better fuzzer/scanner, but since they don't publicly release them, I found that going around and bashing other security tools to position themselves higher than their competitors is a sign of arrogance.

Go work for other companies, I don't want you HN people turn out to be like them!

For those of you who emailed sean at matasano dot com but haven't received any response, go play with Trustwave crypto challeges: https://github.com/SpiderLabs/CryptOMG - And yes they don't have BS subscription model.

We changed the format for the crypto challenges because:

* the "vulnerable" web app got in the way of what we were trying to teach people (it's easy to work CTR mode into "decrypt this cookie" but not so easy to work Diffie Hellman into that)

* the web parts got repetitive (there's only so many times you can show people "decrypt this cookie" before the "cookie" part of that gets in the way).

* some of the challenges involve implementing crypto constructions (which we found to be the best way to learn how to break them). We had features in 36 Chambers that tried to capture "building" as well as "breaking", but they were extremely clumsy and contrived.

* But mostly, because we'd rather put effort into tech supporting people learning crypto, as opposed to Ruby code running on Heroku.

Sean's crypto stuff has about 2.5x as much material as the 36Chambers crypto-for-pentesters site had, and that's mostly because we stopped wasting our time making it look pretty. The site was a silly way to spend our time. We'll have RC4 keystream bias challenges by the end of next week. If we were going to work them into a shiny web app, we might not have them by the end of the year.

If the pricing model we use for the challenges ("mail Sean and ask for them and he'll give them to you for free") is too much for you, I don't know what to tell you. Yes, making it to the end does incur the penalty of us begging you to come work with us. But if you're unwilling to surrender to a life of indentured servitude in the pentest mines at Matasano, we will happily accept a warrant on the blood of your firstborn child. That is, I think you'll agree, a tiny price to pay.

I guess thanks for giving me a chance to clear up this issue, which, if you follow me on Twitter, has maybe had you confused for awhile (at least until last November or so when we started telling people every damn week to mail Sean for the challenges).

This site never existed, at least according to Matasano's offical website or Twitter account.

>"If the pricing model we use for the challenges ("mail Sean and ask for them and he'll give them to you for free") is too much for you, I don't know what to tell you"

You are deviating from the fact that you promised to give sth away at a national conference, then completely ignored it until s.b obviously pointed it out. What happened between BH-11 to last November - when you started telling everyone to send email to Sean?

"Free" challenges, indeed. Ah hah hah hah hah haaaaaa! Mwrhwprh -gulp-. Mmmm. Fungus.

Also, I wholeheartedly endorse Tom's responses to your insinuations.

I'm surprised none of you think I'm devious enough to have planted that anonymous commenter, though. "What, you're saying you test ALL the form inputs? What are you, some kind of atomic superman?"

"I wish Burp didn't have a Scanner. I might pay $25 more for a branded version of Burp that specifically didn't have that feature, so I could reassure clients I wasn't ever using it."

Tell me, how do you expect to find MOST instances of SQL Injection or XSS without using tools? Do you manually tamper with every cookie parameters? Unless Matasano has better tools and release them publicly, then I am interested in hearing about them.

We automate lots of things. We just don't automate things that remove judgement from testers.

I've been a vuln researcher since 1995 and so have my partners. I was a lead dev on the industry's second commercial vulnerability scanner (Ballista), and Jeremy worked at ISS on the first. I think we know what we're talking about. Here is what we've learned: when you give a smart tester a tool that purports to find "low hanging fruit" vulnerability X, testers get worse at finding vulnerability X on their own. They subconsciously lean on the tool. They make assumptions about what kind of vulnerability the tool will find that they shouldn't waste time looking for. They gradually start getting worse at finding even the clever variations of X.

So the challenge is to find ways to eliminate drudgery (for instance, in comparing large numbers of responses from a web app to a run of different metacharacter input vectors across every parameter) without introducing things that degrade tester judgement.

Burp Intruder: Fine (though we do better internally for some things). Burp Scanner: Not Fine.

While it sounds compelling to beat up startups, startups are probably not the clients. Our consulting day rates were very expensive and usually only large corporations or the government could afford it.

You just go and check for the top OWASP vulnerabilities. Sometimes, it requires some creativity, but oftentimes, you get a "feeling" for a web app after a while. Many PHP projects, many open source software projects that got a few custom made plugins. And then it's a bit dull. Testing every single parameter of a web app with many attack vectors...

I have to admit that there was one guy at our company who did a lot of reverse engineering, iOS security, testing a DRM system for an ebook online library (key takeaway: you can't control the client. DRM makes it harder, but it is never impossible to crack the system as long as the hardware is not custom made or something), stuff like that. So this was quite challenging and changing, but this was rare.

One gem I want to add to the original post: If you're interested in SQL injection, check out sqlmap. That tool is a real breaker and worked wonders for us and we downloaded entire databases by having a tiny little sql injection vulnerability in the signup form of a newsletter or something like that.

We do zero government work.

I don't feel like we're along in appsec shops for having this mix. I think one possible difference is between pure appsec shops like us, iSec Partners, IOActive, and Stach & Liu, versus general security practices. The work at general security practices might be more of a drag.

It's also the case that network security, being a race to the bottom (with Nessus and Metasploit "scanner jockies" and the like) is actively trying to push up into appsec. Maybe the web appsec work at a place like that is boring? We take it pretty seriously.

We avoid tools like sqlmap.

I'm answering this on the off chance that the conversation is a good glimpse into the working life of an appsec pentester (since that's what Cody's writing about).

Could be. Your work description sounds different though. We did use Nessus and Metasploit for some things, but not for web app security, since ALL these tools suck on a web app security level. They do stupid request-response analysis and they usually have no capability to hold some sort of state, which gets increasingly important in modern web apps.

> We avoid tools like sqlmap.

I think there's actually no other tool like sqlmap. Sqlmap is pure gold as a time saver and also capability-wise. Exploiting a blind time-based SQL vulnerability manually is a pain. Why not use a good tool for that?

If you want to be super careful, just hook up Burp between sqlmap and the target host and check every statement manually. Still better than typing it out.

Note for non-security guys: Blind means that you don't get an error message from the host, which should be the default. Time-based means that you craft some SQL statements that take longer than other statements to get an idea which statement is true. So you could ask something like "does user 1 in table 1 start with letter a-f? if so, return it, if not, wait 3 seconds". This way, you get true or false based on the time it takes the host to respond.

Still, if you're interested in web app security, go and try it out. But if you feel you're some sort of pentesting monkey that does the same stuff day-in day-out, better leave and chase something more interesting :)

But there is no tool that will come close to competing with a top-notch pentester on a SQLi hunt. Automated tools just don't cut it. There is nothing like watching First Blood in action.

If I get in touch, would you point me towards some resources even if it won't lead to employment?

Either way, it must be fun doing that full time. Nothing in the world comes quite close to the feeling of breaking someone's system. The building excitement and anticipation as you realise you might just have found a place where they don't properly encode one protocol into another. The intense satisfaction when you get to demo an exploit. Unlike the rest of app dev, you can prove your attack is right.

That's mostly just an artifact of the fact that so much software over the past ten years is web-based. I'd say maybe 80% of the client work I've done has been web-based (with maybe 10-15% non-web application, and the remainder network stuff).

But it's not the same everywhere. I would posit that one of the differentiators is the size of the company (i.e.: bigger security firms probably do more web-based stuff than more boutique places, mostly due to the clients that big firms service).

At the last place I worked, I ran a 10-person consulting division, and it was maybe 50/50 web app/non web-app testing. We were eventually acquired by a giant telco (two actually), and fast-forward a couple years, and the now 200-person consulting division is mostly doing PCI-related web-app testing (I have since left, although I think I stayed longer than I should have).

The larger the company, the larger your clients (generally), and the less agility of your sales process (ie: sales people tend to have a much easier time selling web application testing, as there is a huge number of clients who need it, and it's easy to put together statements of work around it).

So my advice, if you're interested in the more interesting types of security work, is to look for a small-to-medium-sized place. Actually, regardless of the type of security work you're interested in, I'd recommend a smaller firm. I've worked at enough of both to think that there's a certain size (either of head count or revenue) where you start to do less interesting work.

I actually forgot to update that -- it was on my list of edits. Done now, thanks!

I've been demonstrating web app security topics for the Intro to Security course at Brown University this semester. I've used Burp almost exclusively. I've even had the students use the free version of Burp for labs. I don't know that the functionality / price tradeoff would make sense for them even if they were full time freelancers: they use Repeater and Proxy more than any other tools.

That being said, any time someone complains about it being too expensive I point out that a single vulnerability found as part of a security bug bounty program (ie: Google, Facebook, Mozilla, etc) nets you more than the cost of a license.

I am weird among Matasanos (and ex-Matasanos :|) in that I live inside of Burp Intruder; I use it instead of Repeater. Why replay a request once when I can replay it 1000 times? So for me, non-crippled Intruder isn't optional.

I wish Burp didn't have a Scanner. I might pay $25 more for a branded version of Burp that specifically didn't have that feature, so I could reassure clients I wasn't ever using it.

Huh? Do you like wasting clients time/money?

* which is why we don't charge billable hours to run off-the-shelf tools that our clients could just run themselves,

* I addressed why we don't "augment" with scanners downthread (shortened answer: it's a slippery slope to testers just running scanners),

* Our scoping and rates are dead square in the middle of the market, so if scanners are helping other firms deliver projects more cheaply than us, I don't think the savings are being passed along. (We also don't double- or triple- book consultants on multiple projects, and we don't pay overtime.)

I upvoted you, because while I thought that was a pretty snide way to ask the question, I sure am happy to get to say over and over again how our projects aren't just Burp Scanner results. :)

I wouldn't bill a client for running a scan on them. I would start a scan and do manual testing at the same time, focusing on more intelligent attacks and understanding the application. By the time I am done, the scan would typically kill off a significant number of buggy parameters that I now don't have to test because I already know it's as vulnerable. For some projects, this can be quite substantial. Beyond creating a POC and documenting the issue, I now don't have to spend billable hours on all of that.

The fact that scans consistently find a lot of bugs tell you that clients aren't running tools themselves. They don't know the tools, don't understand the results, don't know how to use them beyond point-and-click. They don't know how to set up macros that validate the session and re-log in, etc.

Although it sounds good to say that they aren't paying you to just run a scanner, the reality is no other reputable testers are doing that either.

Yeah, it was a bit snide, but you were scoffing at testers who do use scanners, and I genuinely think not using them (properly) is a colossal waste of time

It would be fun to have this debate somewhere that wasn't 10 comments deep into an old thread.

I don't actually know you, or who you work for, so please don't think I could be calling you out as a bad tester. We just don't test with automated scanners. We're not the only shop that doesn't use scanners. It's just the way we work.

(It's actually not great at doing those comparisons, but I don't have a better alternative).

Burp costs money, but it costs so little money relative to its value that if you think it's expensive, I'm going to suggest you're doing something wrong with your bill rate.

Couldn't agree enough. Even if this is something you do as a hobby, Burp will more than pay for itself in a single bug bounty payout.

I think that's the area it's hard to break if you're already engulfed into security. I've been in architecture, research and pentesting across a lot of shops but I've always felt like minimum viable exploitation was all most places were after.

Fast forward years and you end up in something you don't feel like you've transitioned into something deeper. Sure, you can go there on your own but it has limited viability unless you're path forward is Pwn2Own or bounties in general.

I'd love to work for the Matasanos of the world but feel like I may be locked out based on the initial hurdle of being more proficient in code as a first class skill vs having a more honed skilkset in finding flaws on the systems as a whole. Also tracking the relevant things within the security landscape is a skill in and of itself and since most orgs don't understand how to find and cultivate that talent it open the doors foe the Risk.IO of the world.

Sure, I've done some reverse engineering, lots of (easy) pentesting and am proficient in Python. I've designed many F100 systems as it pertains to the security construct, yet I can't see a path forward to digging in deeper with those like Matasano. So @tptacek, any advice? The money is excellent on this side of the fence, but the real challenges are, seemingly, few and far between.

Edit: I need to stop writing posts from phone/tablet (spelling).

http://www.acloudtree.com/how-to-configure-burp-and-chrome-f...

Want to make sure I catch your future editions, do you have anything I can sign up for notification? Can't find an RSS feed on your blog.

Oh, also, follow me on twitter, as I'll certainly link it there. https://twitter.com/daeken

And the 5th

From now on, every time I write web code I'll use this as a check list!

I don't like Java applications any more than you do, but it happens that the best web testing application is built in Java; I'm not going to not use it out of pique.