“We Don’t Sell It? Then It’s Not Important”

[UPDATE: Since there seems to be some confusion, the "We" in the title of this post is NOT "Veracode". The expression is a generic one intended to illustrate the attitude exhibited by many companies who like to downplay the value and/or effectiveness of technologies that they themselves do not sell. I can't believe I am having to explain this.]

Fair warning, this is a bit of a rant.

Back in my consulting days (early 2000, I’m getting old), we delighted in the fact that our web application penetration testing methodology didn’t rely on automated tools. This was completely true; we did everything manually, and we were among the best in the industry. Many so-called security consultants of the day would run a commercial web scanner and repackage the results as a high dollar “penetration test” — what a ripoff!

What we didn’t acknowledge to our customers is that those web scanners, even in their immature state, were probably capable of detecting some of the low hanging fruit that we didn’t want to spend our time looking for. Oh, we’d find a few “representative examples” of XSS and SQL injection, but then we’d get bored and move on to the more interesting and complex attack vectors. In our naivete, we figured developers would be inspired to revisit their entire input validation and/or output encoding practices, as opposed to just fixing the proof-of-concept examples we found.

Meanwhile, the commercial web scanner vendors were always downplaying the value of manual testing! “Why would you want to pay for an expensive penetration test when you can just run this less expensive tool and find the same vulnerabilities?” They’d gloss over all the technical challenges of automated web scanning and conveniently forget to mention how it was impossible for them to find authorization issues, cryptographic weaknesses, business logic flaws, and so on.

What’s my point?

Using multiple testing methodologies is crucial. Sure, there may be some overlap, but ultimately they are complementary to one another. That’s why at Veracode, we’ve never positioned automated static analysis (SAST) as a complete solution. That’s why we integrated both automated web scanning (DAST) and manual penetration testing into our service offerings less than a year after launching the company, even though SAST is our patented bread-and-butter technology. This meant we could always be completely honest about the strengths and weaknesses of each technique. I’ve had a slide titled “There Is No Silver Bullet” in my corporate slide deck since the very beginning.

Our silver bullet is better than yours

Meanwhile, it’s been amusing to watch other companies — who only had a single offering — having to espouse the tactic of downplaying any testing approach that wasn’t in their service portfolio.

• Over at Fortify, Brian Chess famously predicted that 2009 would mark ">the end of penetration testing.
• Over at WhiteHat, Jeremiah Grossman often downplays the value of writing secure code and testing code quality.
• Even as recently as last week, we have Errata Security (a consultancy) claiming that automated tools are useless and doomed to fail. Welcome back to 1999.

I’m only picking on these guys because they’re visible, well-respected practitioners in the application security space. Of course Brian knows source code scanning is an incomplete solution, and now that Fortify and WebInspect are part of the same parent company, I suspect he’s adjusted his message. I’m certain Jeremiah knows there’s value in writing secure code during the SDLC, which is why WhiteHat is now trying to get into the SAST market by acquiring some technology.

And I’m pretty sure Dave Maynor knows automation does provide real value. How else can a big company — spooked by all the recent breaches — quickly hunt for SQL injection vulnerabilities across 5,000 websites without the benefit of automation? How does one look for issues in the 150 third-party libraries you use, where only the binary is available? Do you hire Mark Dowd to spend a month looking at each one?

Building trust

We all know a few sales reps that jump from one company to another, changing their pitch as they go no matter how much it conflicts with things they’ve said in the past. First a service-based approach is best, but suddenly an on-premise tool is better. Source code scanning used to be pointless, but now it’s the best thing since sliced bread! It’s no surprise these guys don’t experience more success — they lack credibility. The most successful account reps I’ve seen are the ones who build trust with their customers over time by being honest about what they are selling, even when hopping from one company to the next.

Look, it’s no big secret why people talk up their own stuff and imply everything else stinks. It’s part of the sales and marketing machine and by no means is it unique to the security industry. Even so, can’t we make an effort — as practitioners — to cut back on the rhetoric a little bit and be more honest with our customers? Customers look to us as experts to help them build their security programs, and what do we do? We oversell them on an approach that has huge gaps we pretend don’t exist. If you’re really looking out for your customers, start being more honest, and stop handing out kool-aid.

Here’s another approach: Instead of outright dismissing an effective technology or methodology just because you don’t sell it, sometimes it’s worth thinking about partnering, or even building something better. That’s why at Veracode we designed our service platform around the idea of technology integration. There is no silver bullet and there never will be.

Whitepaper: A Dose of Reality on Automated Static-Dynamic Hybrid Analysis

As application inventories have become larger, more diverse, and increasingly complex, organizations have struggled to build application security testing programs that are effective and scalable. New technologies and methodologies promise to help streamline the Secure Development Lifecycle (SDLC), making processes more efficient and easing the burden of information overload.

In the realm of automated web application testing, today’s technologies fall into one of two categories, Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). SAST analyzes application binaries or source code, detecting vulnerabilities by identifying insecure code paths without actually executing the program. In contrast, DAST detects vulnerabilities by conducting attacks against a running instance of the application, simulating the behavior of a live attacker. Most enterprises have incorporated at least one SAST or DAST technology; those with mature SDLCs may even use more than one of each.

In the past year or so, industry analysts and product vendors have become enamored with so-called “hybrid analysis” technologies. Hybrid techniques aim to correlate the results of SAST and DAST to dramatically expand dynamic coverage, prioritize the combined set of results, and reduce both false positives and false negatives. This whitepaper will examine each of these claims to give consumers technical insight into whether hybrid technologies can realistically live up to the hype.

Several observations will be described in the following sections:

• Hybrid analysis may expand dynamic coverage, but the lack of application context limits its effectiveness.
• The challenge of reliably generating URL-to-source mappings, coupled with the existence of URL rewriting, undermines the accuracy and usefulness of vulnerability correlation.
• Hybrid analysis does not reduce false positive rates; rather, it lulls users into a false sense of security by suggesting that non-correlated vulnerabilities are false positives.
• Correlation should not be equated with exploitability. Vulnerabilities should be prioritized based on severity and business impact, not based on how many scanners are capable of detecting it.

Download the full whitepaper.

An Ounce of Prevention is Worth a Pound of Cure

A conversation on Twitter this morning started out like this:

@dinozaizovi: Finding vulnerabilities without exploiting them is like putting on a dress when you have nowhere to go.

This clever analogy spurred a discussion about the importance of proving exploitability as a prerequisite to fixing bugs. While I agree that nothing is more convincing than a working exploit, there will always be a greater volume of bugs discovered than there are vulnerability researchers to write exploits. Don’t get me wrong — as a former penetration tester, I agree that it is fun to write exploits, it just shouldn’t be a gating factor. Putting the burden of proof on the researcher to develop an exploit is not scalable, nor does it help create a development culture that improves software security over the long term.

A related topic, and one that hits closer to home for me, is how software developers deal with the results of static analysis. Static analysis is often misunderstood, particularly by people who have only dealt with dynamic analysis (fuzzing, web scanning, etc.) or penetration testing in the past. Because static analysis detects flaws without actually executing the target application, there’s an increased likelihood of finding “noise” (insignificant flaws) or false positives. On the other hand, static analysis provides broader coverage, often detecting flaws in complex code paths that a web scan or human tester would be unlikely to find. So there’s your trade-off.

Here’s a conversation I have all too frequently, paraphrased:

Now imagine that conversation stretching out to 30 minutes or more. They could’ve fixed a half-dozen flaws already. And it’s not limited to SQL injection. For example, consider cross-site scripting (XSS):

Buffer overflows:

By now you get the picture. Many developers want proof, to the extent that they’ll sacrifice efficiency to get it. If we are to improve software over the long haul, developers must learn to recognize situations where it takes less time to patch a bug than to argue about its exploitability. On a more positive note, from someone who talks to static analysis customers on a daily basis, the tide is starting to turn in the right direction. But it is still an uphill battle.

Polip and entry point obfuscation

A while ago, on a visit to an Anti-Virus lab, we started playing with some Polip samples. One of the analysts mentioned how tedious was in some cases to find the obfuscated entry-point in files infected with Polip.

We looked into a few samples of the malware, observing how the transfer of control to Polip code happens. As we read through the code, I started seeing some patterns.
In the cases we looked at, Polip always added a new section to the end of the infected executable. Then it chose some call within the original application and modified it to jump to the virus code, later on resuming execution in the original target of the call. Keeping, in that way, the original functionality of the infected application, just with a small detour.

Needless to say, it would be very tedious to manually find the redirected call(s) within an infected executable, but really easy with some scripting. Using IDAPython and the knowledge about how the jumps to the malicious code look like, we can easily come up with something that will quickly list them for us.

Let's take a look at the structure of the executable. The code of the standard application will, in most cases, reside in a single segment named CODE, .text or something along the lines. The code of the virus will reside in a segment appended to the end of the file.



Hence, if we could make a simple script that checks every single code reference that crosses segment boundaries, we would be able to list the transfers of control to the virus. Some other references might come up depending on the executable, but with some additional filtering, we will get just a few, with Polip's entry point(s) among them.

The idea in pseudo-code could look something like the following:

for each segment in the executable:   for each function if the segment:     for each instruction in the function:       for each code reference from the instruction:         if the reference points to another segment and both source and target segments are marked executable then           print 'Possible obfuscated entry point found'

And in IDAPython... well, not all that different:

for segment in idautils.Segments():   for func_start in idautils.Functions(segment, idc.SegEnd(segment)) :     for head in Heads(func_start, FindFuncEnd(func_start)):       for ref in list( CodeRefsFrom(head, 0) ):         if SegName(ref) != SegName(func_start) and GetSegmentAttr( ref, SEGATTR_PERM ) & 0x1 and GetSegmentAttr( func_start, SEGATTR_PERM ) & 0x1:           print '%08x: intersegment reference to %08x' % (head, ref)

Polip also finds cavities within the "standard" text section and places chunks of itself there. For those cases this simple idea of looking for inter-segment code references won't yield anything. Fortunately, most of the code lies in the extra section and studying the references from that code is almost trivial to find the chunks that Polip inserted in the cavities... it's just a few more lines of IDAPython left as an exercise for the reader... ;-)

Just want to remind anyone interested that BlackHat Vegas is coming in a few weeks and Pedram Amini and I will be teaching our training, "Reverse Engineering on Windows: Application in Malicious Code Analysis " . If you want learn about how to build this kind of automation among other things, we would love to have you in our class.

Polip and entry point obfuscation

A while ago, on a visit to an Anti-Virus lab, we started playing with some Polip samples. One of the analysts mentioned how tedious was in some cases to find the obfuscated entry-point in files infected with Polip.

We looked into a few samples of the malware, observing how the transfer of control to Polip code happens. As we read through the code, I started seeing some patterns.
In the cases we looked at, Polip always added a new section to the end of the infected executable. Then it chose some call within the original application and modified it to jump to the virus code, later on resuming execution in the original target of the call. Keeping, in that way, the original functionality of the infected application, just with a small detour.

Needless to say, it would be very tedious to manually find the redirected call(s) within an infected executable, but really easy with some scripting. Using IDAPython and the knowledge about how the jumps to the malicious code look like, we can easily come up with something that will quickly list them for us.

Let's take a look at the structure of the executable. The code of the standard application will, in most cases, reside in a single segment named CODE, .text or something along the lines. The code of the virus will reside in a segment appended to the end of the file.



Hence, if we could make a simple script that checks every single code reference that crosses segment boundaries, we would be able to list the transfers of control to the virus. Some other references might come up depending on the executable, but with some additional filtering, we will get just a few, with Polip's entry point(s) among them.

The idea in pseudo-code could look something like the following:

for each segment in the executable:   for each function if the segment:     for each instruction in the function:       for each code reference from the instruction:         if the reference points to another segment and both source and target segments are marked executable then           print 'Possible obfuscated entry point found'

And in IDAPython... well, not all that different:

for segment in idautils.Segments():   for func_start in idautils.Functions(segment, idc.SegEnd(segment)) :     for head in Heads(func_start, FindFuncEnd(func_start)):       for ref in list( CodeRefsFrom(head, 0) ):         if SegName(ref) != SegName(func_start) and GetSegmentAttr( ref, SEGATTR_PERM ) & 0x1 and GetSegmentAttr( func_start, SEGATTR_PERM ) & 0x1:           print '%08x: intersegment reference to %08x' % (head, ref)

Polip also finds cavities within the "standard" text section and places chunks of itself there. For those cases this simple idea of looking for inter-segment code references won't yield anything. Fortunately, most of the code lies in the extra section and studying the references from that code is almost trivial to find the chunks that Polip inserted in the cavities... it's just a few more lines of IDAPython left as an exercise for the reader... ;-)

Just want to remind anyone interested that BlackHat Vegas is coming in a few weeks and Pedram Amini and I will be teaching our training, "Reverse Engineering on Windows: Application in Malicious Code Analysis " . If you want learn about how to build this kind of automation among other things, we would love to have you in our class.

Polip and entry point obfuscation

A while ago, on a visit to an Anti-Virus lab, we started playing with some Polip samples. One of the analysts mentioned how tedious was in some cases to find the obfuscated entry-point in files infected with Polip.

We looked into a few samples of the malware, observing how the transfer of control to Polip code happens. As we read through the code, I started seeing some patterns.
In the cases we looked at, Polip always added a new section to the end of the infected executable. Then it chose some call within the original application and modified it to jump to the virus code, later on resuming execution in the original target of the call. Keeping, in that way, the original functionality of the infected application, just with a small detour.

Needless to say, it would be very tedious to manually find the redirected call(s) within an infected executable, but really easy with some scripting. Using IDAPython and the knowledge about how the jumps to the malicious code look like, we can easily come up with something that will quickly list them for us.

Let's take a look at the structure of the executable. The code of the standard application will, in most cases, reside in a single segment named CODE, .text or something along the lines. The code of the virus will reside in a segment appended to the end of the file.



Hence, if we could make a simple script that checks every single code reference that crosses segment boundaries, we would be able to list the transfers of control to the virus. Some other references might come up depending on the executable, but with some additional filtering, we will get just a few, with Polip's entry point(s) among them.

The idea in pseudo-code could look something like the following:

for each segment in the executable:   for each function if the segment:     for each instruction in the function:       for each code reference from the instruction:         if the reference points to another segment and both source and target segments are marked executable then           print 'Possible obfuscated entry point found'

And in IDAPython... well, not all that different:

for segment in idautils.Segments():   for func_start in idautils.Functions(segment, idc.SegEnd(segment)) :     for head in Heads(func_start, FindFuncEnd(func_start)):       for ref in list( CodeRefsFrom(head, 0) ):         if SegName(ref) != SegName(func_start) and GetSegmentAttr( ref, SEGATTR_PERM ) & 0x1 and GetSegmentAttr( func_start, SEGATTR_PERM ) & 0x1:           print '%08x: intersegment reference to %08x' % (head, ref)

Polip also finds cavities within the "standard" text section and places chunks of itself there. For those cases this simple idea of looking for inter-segment code references won't yield anything. Fortunately, most of the code lies in the extra section and studying the references from that code is almost trivial to find the chunks that Polip inserted in the cavities... it's just a few more lines of IDAPython left as an exercise for the reader... ;-)

Just want to remind anyone interested that BlackHat Vegas is coming in a few weeks and Pedram Amini and I will be teaching our training, "Reverse Engineering on Windows: Application in Malicious Code Analysis " . If you want learn about how to build this kind of automation among other things, we would love to have you in our class.

badass debugger + badass toy = geek pr0n

Today I finally got working a hacked-together minimal version of the iPhone debugger client for BinNavi. It's heavily based on Patrick Walton's (with HD's updates) weasel debugger. Once tied to BinNavi debug client framework the whole client-server interaction is trivial.

It feels just right, the best looking debugger together with the slickest device.. recipe for fun.. ;-)



The test application is telnet on the iPhone. On the iPhone's screen is the debug output from BinNavi's debug client. telnet is launched from an ssh session in OSX, where BinNavi is running.



For anybody trying to link Mach's debugging interface with a C++ iPhone application, remember the extern "C" when defining boolean_t exc_server(mach_msg_header_t *in, mach_msg_header_t *out); (which is not defined in the header files, as pointed in weasel's source code). Otherwise you'll get a nasty "Undefined symbols" message when linking.

extern "C" is also needed for catch_exception_raise(...) so exc_server can call it to handle exceptions. Documented here.
(I've used the standard iPhone toolchain on Debian, this is running on the firmware 1.1.3)

badass debugger + badass toy = geek pr0n

Today I finally got working a hacked-together minimal version of the iPhone debugger client for BinNavi. It's heavily based on Patrick Walton's (with HD's updates) weasel debugger. Once tied to BinNavi debug client framework the whole client-server interaction is trivial.

It feels just right, the best looking debugger together with the slickest device.. recipe for fun.. ;-)



The test application is telnet on the iPhone. On the iPhone's screen is the debug output from BinNavi's debug client. telnet is launched from an ssh session in OSX, where BinNavi is running.



For anybody trying to link Mach's debugging interface with a C++ iPhone application, remember the extern "C" when defining boolean_t exc_server(mach_msg_header_t *in, mach_msg_header_t *out); (which is not defined in the header files, as pointed in weasel's source code). Otherwise you'll get a nasty "Undefined symbols" message when linking.

extern "C" is also needed for catch_exception_raise(...) so exc_server can call it to handle exceptions. Documented here.
(I've used the standard iPhone toolchain on Debian, this is running on the firmware 1.1.3)

badass debugger + badass toy = geek pr0n

Today I finally got working a hacked-together minimal version of the iPhone debugger client for BinNavi. It's heavily based on Patrick Walton's (with HD's updates) weasel debugger. Once tied to BinNavi debug client framework the whole client-server interaction is trivial.

It feels just right, the best looking debugger together with the slickest device.. recipe for fun.. ;-)



The test application is telnet on the iPhone. On the iPhone's screen is the debug output from BinNavi's debug client. telnet is launched from an ssh session in OSX, where BinNavi is running.



For anybody trying to link Mach's debugging interface with a C++ iPhone application, remember the extern "C" when defining boolean_t exc_server(mach_msg_header_t *in, mach_msg_header_t *out); (which is not defined in the header files, as pointed in weasel's source code). Otherwise you'll get a nasty "Undefined symbols" message when linking.

extern "C" is also needed for catch_exception_raise(...) so exc_server can call it to handle exceptions. Documented here.
(I've used the standard iPhone toolchain on Debian, this is running on the firmware 1.1.3)

Take Two: Packers, Time and Google Groups

I just had to do it... This morning I read about chronoscope in a post in the Google Code Blog and I could not help myself from wanting to tinker with it.

I wrote a Mathematica function to export a time-series of the format (timestamp, value) into the dataset format used by chronoscope.

Epoch[date_] :=   ToString[AbsoluteTime[DateList[ToString[date]]] -   AbsoluteTime[DateList["1970"]]]; ChronoscopeJsExport = Function[ {datasetName, id, label, axis, data},   jsData = datasetName <>   " = {\nId: \"" <> ToString[id] <> "\", \n" <> "domain: [" <>   StringJoin[ Riffle[ Map[ Epoch, data[[All, 1]] ], ", "] ] <>   "], \n" <> "range: [" <>   StringJoin[     Riffle[ Map[ ToString, data[[All, 2]] ], ", "] ] <> "], \n" <>   "label: \"" <> ToString[label] <> "\", \n" <>   "axis: \"" <> ToString[axis] <> "\"\n};";   jsData ];

And ran it through the packer time-series I harvested from Google Groups. Then I picked some widget demo code and put it all together in a mash-up. The results of the quick hack are here... much nicer to visualize than in the previous post. (and it's interactive!)

• Use the mouse-wheel to zoom
• Drag the plot left/right to browse around different date ranges
• You can pick any packer and the data will be plotted against the previously selected one

Next Page »

• Categories

  • ALL THINGS SECURITY
  • analysis recipes
  • application security
  • Application Security Metrics
  • applied security visualization
  • Binary Analysis
  • bindiff
  • BinNavi
  • books
  • cisco
  • cloud
  • code opimization
  • conference
  • data visualization
  • developer-first
  • Digital Warfare
  • Disclosure
  • Discussion Entries
  • Dynamic Analysis
  • equillibRIAA
  • events
  • Graph Exchange
  • ida2sql
  • idapython
  • INFOGRAPHICS
  • Interesting Tech
  • law
  • Links
  • Log Analysis
  • Malware
  • mathematics
  • Miscellaneous
  • Mobile
  • Mobile Spyware
  • ninja
  • Non Sequiter
  • pefile
  • Podcast
  • privacy
  • programming
  • python
  • QA
  • quality
  • research
  • responsible disclosure
  • reverse engineering
  • Rights Online
  • rights_online equalibRIAA
  • SaaS
  • SDLC
  • secure
  • security
  • security books
  • Security Information Management
  • Security Intelligence
  • Security Market
  • Security Start-up
  • security visualization
  • Social Media
  • Software Development
  • SOURCE Boston
  • SOURCE Conference
  • tools
  • training
  • travel
  • Uncategorized
  • video
  • visualization
  • Vulnerabilities

• Subscribe

   Subscribe in a reader

• Recent Comments

  • Louis Vuitton Handbags on The SOURCE Barcelona Apartment Experience
  • coachnewbag.webnode.jp on The SOURCE Barcelona Apartment Experience
  • http://www.getfitnstrong.com/bowflex-dumbbells/4-reasons-bowflex-weights-get-here/ on The Slow Death of Antivirus
  • chloeshopjp.webnode.jp on The SOURCE Barcelona Apartment Experience
  • LOUIS VUITTON OUTLET on Dan Geer’s Keynote

• Twitter

• Tags

  andrew jaquith certification christofer hoff code audit code inspection Cool Conference cyber security cyber warfare dan geer dilldog fun government regulations granite island group herd intelligence innovation intro john tan l0pht lee kushner Little rooms live blogging marketeers matt moynahan michael murray mike rothman mudge neosploit net-centric warfare net neutrality richard clarke rich mogull security security conference silicosis SOURCE Boston source boston. james atkinson space rogue tech target times square sign logo twitter veracode video weld pond yankee group zero day