Welcome, come on in, have a seat. There is a cold beer in the fridge, help yourself!

I may be new to the team, but I’m (reasonably) old to the game. My name is Tyler Shields and I’m the latest addition to the Veracode research team. I started at Veracode in September 2008 as a Senior Security Researcher and have been immediately thrown into the fire. Working for a fast paced, highly energetic company like Veracode, keeps you busy and challenges you every day. I plan to blog on the most interesting pieces of my work with Veracode and hope that you find it enlightening or at the very least entertaining.

In the past I have worked as the security engineer at a .com startup, as an incident response and forensics specialist for the United States Postal Service (think HUGE network), and most recently as a security consultant for @stake and Symantec. I have consulted on engagements for Fortune 500 companies, most major financial institutions, and the highest levels of the United States government. As a consultant my focus was on anything related to application security including, application penetration assessments, product security assessments, secure development lifecycle consulting, and secure application architecture engagements. I lead the @stake/Symantec Application Security Center of Excellence that was used to help guide the knowledge of the global consulting team. I also spent time as the lead for the Symantec Vulnerability Research program in which a number of interesting vulnerabilities were discovered and publicly released. In my spare time I enjoy reverse engineering and malware research. I recently completed my graduate degree in Information Security/Computer Science from James Madison University in Virginia.

So… Here’s to a new job, a new blog poster, and of course lots of fun to come.

Last week, during the OWASP AppSec 2008 Conference, the people behind the ubiquitous CISSP certification announced their latest creation — the Certified Software Security Lifecycle Professional (CSSLP). In front of a captive audience waiting for a 42″ plasma TV to be raffled, the Executive Director of (ISC)2 outlined this new certification designed to appeal to application security professionals. To his credit, Mr. Tipton stated very clearly that the CSSLP is not intended to measure one’s technical skillset. Unfortunately, it’s inevitable that employers will treat it as such.

You can read all the details on their website (except for the part about the certification not being a measure of practical skills). From what I can tell, the CSSLP is just the CISSP with different CBKs, or Common Bodies of Knowledge. As with the CISSP, they are going for broad knowledge, not depth. Starting in June 2009, you can get certified by taking a paper exam, likely a multiple choice test similar to the CISSP. Why June? Because the test isn’t even written yet — I’ve heard from several sources that they are actively soliciting their existing pool of CISSPs to help write test questions.

Ah, but what if you can’t wait that long and want to get certified right away? You’re in luck. If you act before March 31, 2009, you can get grandfathered in without even having to take the exam! That’s right, they call it the CSSLP Experience Assessment, and here are the requirements:

• Upload a resume showing three years of experience related to software security, or four years if you don’t have a college degree
• Write short essays (500 words maximum) discussing four CBKs of your choice
• Get a CISSP to vouch for you
• Pay $650

Let’s examine these requirements one at a time.

Three years of experience. (ISC)2 doesn’t provide any requirements on depth of experience, other than citing the broadly-defined CBKs. Considering they are targeting everyone from software developers to security assessors to business analysts (yes, really), chances are they are going to accept any experience that is even tangential to the SDLC or software security.

Short essays on four of the CBKs. I asked the (ISC)2 exhibitors specifically what they are looking for to satisfy this requirement, and they said the essays should be a general discussion of the CBK topic, optionally citing your personal experience in that area if you have any. This messaging is not quite aligned with the website guidance, which states that the essays should be “Accomplishment Records” which are self-reported descriptions of experience. Either way, with a maximum essay length of 500 words, it’s pretty obvious that substance is not (ISC)2’s first priority. Here’s one data point for you: I spoke to someone who has already submitted the CSSLP Experience Assessment, and he said it took about an hour to write the essays.

Get a CISSP to vouch for you. Actually this can be any (ISC)2 certified person, not just CISSPs. Contrary to what you’d expect, though, the person isn’t vouching for your skillset so much as they are confirming that the attestations on your resume are accurate.

Pay $650. You knew it was coming. After all, there is money to be made. How is it that qualifying for the CSSLP through professional experience should cost $650? If you’re taking the written exam, fair enough, (ISC)2 does incur the cost of administering and grading that exam (even though the Scantron machine is probably paid off by now). But $650 for the submitted-online Experience Assessment? If we assume that the person reading these essay submissions makes a rather generous $100k per year, then $650 accounts for roughly a day and a half. Will it really take that long to read a maximum of 2,000 words and pass judgment? Of course not. (ISC)2 wants to get as many people as possible to qualify based on “experience”, seeding the initial pool of CSSLPs and netting them $650 per head for doing next to nothing.

As Lee Kushner stated during his OWASP AppSec presentation (7 Habits of Highly Effective Career Managers), “the more people who own a cert, the less relevant it becomes.” Irrelevant — that’s exactly what the CISSP has become, and it’s exactly where the CSSLP is headed. Meanwhile, (ISC)2 will sit back and watch while you and your employers continue to fill their coffers.

In closing, let me acknowledge that this blog entry probably comes across as judgmental. I accept that. I’m not ranting against the idea of certifications, though admittedly I’m not a fan of them either. I am disappointed that (ISC)2, an organization with tremendous influence, could have created something more meaningful but chose not to. Why bother when people will just fork over the cash anyway?

Assuming the mailbox hack is not an elaborate ruse, how did they do it?

Almost as bad as the Sprint PCS password reset fiasco that made the news in April, here is the Yahoo Mail password reset screen:

As you can see, you need to know the user’s birthday, country of residence, and postal code. Not difficult information to dig up in Palin’s case, as shown here. After you enter this information correctly, you are asked to type in the alternate e-mail address that’s associated with the account. But they give you hints — so if your alternate e-mail was sarah@alaska.gov, they would show you s****@a*****.gov.

Assuming you guess the alternate e-mail correctly, Yahoo mails a password reset link to that address. So it’s likely that the attacker may have also had to gain access to her alternate e-mail account. Either that, or they exploited a vulnerability in the Yahoo password reset mechanism itself, which seems less likely but not implausible.

So Yahoo itself probably didn’t get hacked, per se, even though there will probably be a lot of FUD in the media about that.

Update 08/18/2008 1:00am EST:

Just found this writeup describing how it transpired: http://pastebin.com/f7fb944c5. Again, not vouching for the authenticity but it does seem plausible, and it’s consistent with my password reset theory. I guess my Yahoo account doesn’t have a secret question defined so I wasn’t presented that option when I tested the reset mechanism earlier today.

Just for fun, here’s the list of non-customizable secret questions Yahoo lets you pick from, as of tonight:

And they sure don’t make it easy for you to update your secret question, do they? (must be logged in to Yahoo for that link to work)

Earlier today, the US District Court dealt a victory to the MBTA hackers and the EFF, lifting the injunction issued on August 9th to prevent the three MIT students from presenting their findings at DEFCON 16. In summary:

The lawsuit claimed that the students’ planned presentation would violate the Computer Fraud and Abuse Act (CFAA) by enabling others to defraud the MBTA of transit fares. A different federal judge, meeting in a special Saturday session, ordered the trio not to disclose for ten days any information that could be used by others to get free subway rides.

“The judge today correctly found that it was unlikely that the CFAA would apply to security researchers giving an academic talk,” said EFF Staff Attorney Marcia Hofmann. “A presentation at a security conference is not some sort of computer intrusion. It’s protected speech and vital to the free flow of information about computer security vulnerabilities. Silencing researchers does not improve security — the vulnerability was there before the students discovered it and would remain in place regardless of whether the students publicly discussed it or not.”

This sets a good precedent for future cases, and perhaps next time a similar situation arises, a judge will not be so quick to issue a gag order. It’s not a happy ending yet though, as the original lawsuit is still in effect.

As Chris Wysopal pointed out last week, the MBTA’s ire is misdirected. Rather than suing the vendor who sold them the defective system, they sued and attempted to silence the students who discovered the weakness. This is 2008, not 1988 — did they honestly think a gag order would prevent the information from reaching the general public? The DEFCON presentation was already available on the Intertubes prior to the injunction being issued, and the MBTA attorneys included a copy of the confidential whitepaper with their filing, thereby making it public.

I guess you wouldn’t expect that a transit authority would have paid any attention to the Ciscogate fiasco from a few years ago. That presentation never got out either, did it? All that taxpayer money the MBTA spent on ridiculous lawsuits and restraining orders could have been put toward fixing the security flaws. What a concept.

Another BlackHat has come and gone. As usual, it was a very busy week juggling customer meetings, recruiting, conference planning, vendor parties, and, oh yes, the actual BlackHat presentations. I had a fantastic time catching up with old friends and finally getting the opportunity to meet more of the Security Twits and others in the security community. I didn’t submit a talk this year, but nevertheless, fake Dan Kaminsky was still excited to see me.

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned (here is a more accurate report). It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

Three French journalists have been booted for life from Black Hat and Defcon for compromising the Black Hat press room wired network and grabbing the credentials for at least one reporter. Their goal was to publicize the risks to reporters especially current given the massive reporter presence in Bejing for the Olympics. This risk is certainly real and it is a shame that these journalists had to compromise and embarass one of their own and potentially run afoul of US Federal wiretap laws.

Sniffing, or monitoring all traffic on a network, is so 1999. That is when L0pht came out with AntiSniff, which could detect many scenarios where someone was sniffing a wired network. How can we be using plain text authentication protocols in 2008? It is a well known and easily solved problem. But people authenticate in clear text everyday when they log into social networking or blogs or other “unimportant” applications. The problem is when they use those same credentials for work or online banking.

We need to think of any application that alows users to authenticate in the clear as broken. If 3 journalists can monitor passwords, anyone can.

Update 08/08/2008 12:30pm EST:

It turns out the attack was likely a MITM attack where the attackers ran their own DHCP server and handed out a gateway IP that was controlled by them. At least one reporter was connecting to his organization’s content management system over unencrypted HTTP and got his password compromised. More details in “How eWeek Got Hacked at Black Hat.”

Here’s the rest of my list:

10:00-11:00 FX, Developments in Cisco IOS Forensics.

11:15-12:30 Oliver Friedrichs, Threats to the 2008 Presidential Election (and more).

13:45-15:00 Option 1: Scott Stender, Concurrency Attacks in Web Applications. Option 2: Travis Goodspeed, Side-channel Timing Attacks on MSP430 Microcontroller Firmware.

15:15-16:30 Option 1: Alexander Sotirov and Mark Dowd, How To Impress Girls With Browser Memory Protection Bypasses. Option 2: Karsten Nohl, Mifare - Little Security, Despite Obscurity. This is one of the toughest time slots as you also have McFeters/Carter/Heasman and Grossman/Evans in the lineup. Choices, choices.

16:45-18:00 Option 1: Bruce Dang, Methods for Understanding Targeted Attacks with Office Documents. Option 2: Christopher Tarnovsky, Inducing Momentary Faults Within Secure Smartcards/Microcontrollers.

Lots of intriguing hardware talks on Day 2. A lot of it is probably over my head and my first options are more applicable to my day job. There might have to be some room hopping.

I fly out to Vegas tonight — see you all there!

Well, it’s almost BlackHat time. Here are my picks so far for Day 1. As you can see, I still haven’t narrowed it down completely.

11:15-12:30 Option 1: Dan Kaminsky, “DNS Goodness”. On one hand, the DNS vulnerability is already public; on the other hand, the talk will probably still be interesting even if the 0day hype is missing. Option 2: Nate Lawson, “Highway to Hell: Hacking Toll Systems”. My formal education and early work was in Electrical Engineering, so I’m always interested in hardware talks. I haven’t touched a soldering iron in years so I have to live vicariously through people like Nate.

13:45-15:00 Option 1: Chris Hoff, “The Four Horsemen of the Virtualization Security Apocalypse”. I haven’t been paying enough attention to virtualization security and I think this talk will be quite informative. Option 2: Danny Quist and Colin Ames, “Temporal Reverse Engineering”. Sounds like an interesting approach.

15:15-16:30 Option 1: Hovav Shacham, “Return-Oriented Programming: Exploits Without Code Injection”. The topic sounds pretty straightforward conceptually but it will be interesting to see the implementation. Option 2: Tom Stracener and Robert Hansen, “Xploiting Google Gadgets: Gmalware and Beyond”. Not expecting any huge revelations on this one but it’s likely to be entertaining.

18:00-19:00 The Pwnie Awards. Turnout last year was kind of slim, but I bet the room will be full this year as it’s been publicized more.

Day 2 picks coming soon!

This post is a response to Alan Shimel’s Topic of Interest #2 for the Security Bloggers Network.

So what motivates me to attend BlackHat? The #1 reason for me is networking — meeting new people and catching up with old friends and colleagues. Despite our best intentions, we are all busy and our networks are constantly expanding, making it increasingly difficult to stay in touch with old friends in the industry. Twitter and other forms of microblogging help you chip away at the communication gaps; you get a glimpse into peoples’ lives but it’s no replacement for a real conversation.

Obviously, the briefings themselves are a major draw. Even though it’s expanded to over 10 tracks now, the quality hasn’t suffered much. This year’s experiment with allowing paid delegates to vote on speakers seems to have produced a good lineup, though I’m sure there was still a selection committee that could and probably did overrule the votes in some cases. Either way, BlackHat presentations are a decent indicator of the overarching themes that will be prevalent in information security for the upcoming year or two.

When I first started attending BlackHat, I was drawn to the talks discussing 0-day vulnerabilities, tool releases, shellcode tricks, and the like. These days, anything relating to static analysis, automation, and of course web security are most interesting to me. I also consider who’s speaking, regardless of the topic (e.g. one of these guys presents, I’m there). In general, I’ll try to gauge how much value the speaker will add to the presentation — in other words, what do I gain by attending the talk vs. flipping through the slides later? I never attend every time slot; sometimes the hallway conversation is just more interesting.

Some of my other reasons for attending, in no particular order, most of which fall under the “networking” umbrella:

• The parties (duh)
• The Pwnie Awards
• Meeting fellow security bloggers
• Recruiting speakers for SOURCE
• Finding future Veracode employees
• Trading war stories
• Picking up vendor schwag for my kids (RSA is much better for this one)
• Meeting current and former customers — and future ones, hopefully

Things I could do without:

• The cigarette smoke
• The heat
• Quark’s

I’ve stuck around for DEFCON a couple times in the past, but I don’t anymore. I fly out Friday morning or early afternoon so I get home in time to spend the weekend with the family. Personally, three days in Vegas is plenty for me.

When it gets closer to BlackHat time, I’ll post my picks from the briefings schedule.

From the Burlington Free Press, a story about a local hacking competition set up as a spectator event.

Their competition, tantalizingly called a “digital combat exercise,” was supposed to give onlookers a rare opportunity to watch a computer hacking job in progress, complete with play-by-play.

It didn’t work out that way, though, thanks to — what else? — some sort of technical glitch that obstructed efforts to monitor what the competitors were doing. So for the few non-techie spectators who showed up, the business of hacking was still as opaque and mysterious at the end of the 1 1/2-hour exercise as it was in the beginning.

A technical glitch? They always happen at the worst possible time, don’t they? Read on.

The commentary was to come from Peter Stephenson, a member of the program’s faculty, who sat at his own terminal and displayed on a big screen something he called a “sniffer trace,” a multi-colored table with columns of numbers and letters — the first in what was to be a series of tableaus that held the promise of monitoring all the traffic on the network next door.

The minutes passed, and not much happened. The sniffer trace stayed the same, and from time to time, when Stephenson tried to check on what individual teams were up to, the screen went blank. Could it be that the hackers weren’t getting anywhere?

Someone decided to check on them in the old-fashioned way — paying a visit in person. The report came back that they were, in fact, getting somewhere — finding holes and vulnerabilities of various kinds.

You’d think that somebody on the faculty, or one of the grad students, or even somebody in the audience would have realized the problem. The story implies that they never did figure out what those pesky hackers were up to.