Cатсн²² (in)sесuяitу / ChrisJohnRiley

[Introduction] Opening with Jeff Moss

More people are present at Blackhat from the US this year due to the strong dollar. Shortlist of countries that only sent 1 person to the conference. Russia only sent 1 person this year. Blackhat Europe will be in Barcelona next year and is officially a 3 track event.

[Keynote] Douglas Merrill

The way work has changed in the last 10-15 years.

CEO’s are terrified of CSO’s. Most CEO’s think that their company has been the victim of a security breach. However this can’t be the case, as the total number of breaches  doesn’t support this. 1 in 3 CEO’s sign off on the security budget without knowing what it’s for.

16% of breaches tracked by privacywatch in 2009 (so far) were from lost/stolen laptops. 10% were from lost or incorrectly disposed of paperwork. However we rarely say that the company should buy more shredders. More focus should be made on the realistic threats to an organisation.

Lots of effort goes into preventing employees from using applications such as IM. However 50% of employees use personal IM accounts for work activities. Employees want to use the latest technology not to bypass security, but to improve their effectiveness in the workplace. Make it easy for the users to do the right thing and really hard to do the wrong thing. Constantly blocking the user just means that they spend valuable time trying to bypass the rules to get their job done they way the want/need to.

As an example, Google removed a number of controls to allow their staff to be able to to innovate. This can cause issues when it comes to things like end-point security. To prevent this from being an issue the security moved to the infrastructure with monitoring in specific locations.

[Testing/Exploitation] Ruby for penetration testers

Scripting/reversing/fuzzing and integrating Ruby with your existing toolset

(Scripting)

Lots of great security tools are written in Ruby (eg. Metasploit, IdaRub, Ronin) however there should be more.

Use and extend whats already available to you. Don’t reinvent the wheel – Take tools and techniques that work and make them better.

WWMD – A Ruby framework for penetration testing

Includes a number of classes to easily write scripts to interface with web-applications being tested. Classes such as the fuzz module allow for fuzzing inputs for possible XSS vulnerabilities. Modules are also available to test viewstate ASP based applications. By turning the viewstate into a XML format it’s possible to preform fuzzing.

JRMI (Java Remote Method Invocation). There aren’t many tools that can test JRMI based applications. Nessus can do limited enumeration, but that’s about it. JRMI in ruby allows interaction with the Java listener and the ability to pull out valuable information (passwords, configuration, etc…)

(Reversing)

Ruby Black Bag (RBKB) – A Ruby port of Matasano’s Blackbag tool (originally developed in C)

This allows Ruby to be used to reverse unkown protocols and inject traffic into these connections. Black Bag also allows you to extract data from embedded files

Ruckus – A DOM-Inspired Ruby Smart Fuzzer

Ruckus allows you to define the structure of a packet and use this as the basis for testing. It can also be used to define file structures.

FRASM – Static analysis using a Ruby wrapped disassembler.

Ragweed – Dynamic analysis inspired by PyDbg.

JDI-HIT Tracing – Dynamic Java analysis

(Fuzzing)

Unfortunately due to time constraints the presentation had to draw to a close before really covering anything useful in this section. Hopefully I’ll have a chance to review the slides.

[Testing/Exploitation] Demystifying fuzzers

Writer of the Peach fuzzing platform.

Dumb Fuzzers – Using techniques such as DWORD sliding or bit flipping. Now so popular that data is very often accompanied with a CRC value to prevent the use of dumb fuzzing attacks.

Smart Fuzzers – More knowledge of the target required to ensure that things like CRC are fixed when fuzzing. In order to test more than the first few packets of a communication, the fuzzer has to know how to progress to the point in the communication you want to fuzz. This could mean performing authentication or loading a valid file into a player before being able to fuzz specific commands.

Why are we fuzzing ?

• Fuzzing is about finding bugs
• Fuzzing is repeatable
• Fuzzing should be easy on the wallet (low cost per bug)

Fuzzing alone is not enough, however it is a great addition to any secure development lifecycle.

Bugs that cause crashes or violations .:

• Memory corruption issues
• Overflows
• Type issues

DoS types discovered .:

• Memory consumption
• Process hangs

Fuzzer types (File, Network, General, Custom)

Lots of fuzzers to choose from. More appear every year, most have a short lifespan as they’re written to discover a specific bug and enable a conference talk on the subject/bug.

Of all the fuzzers available, only a handful are still in active development (fuzzware and Peach are good examples). Custom one-off fuzzers rarely go beyond the 0.1 revision and often aren’t updated after the conference talks are completed.

Commercial Fuzzers

• Mu Dynamics (Network Only, hardware based fuzzing device)
• beSTROM (General Fuzzer, Software based)
• Codenomicon (General Fuzzer, but not a fuzzer. Test-case based)

Difference between offensive and defensive fuzzing

Attackers need to find 1 bug to make their name.
Corporates need to find ALL the bugs to maintain security.

Fuzzer development process

• Investigate
  • Determine what needs to be fuzzed
  • Mapping fuzzer capability to needs
  • Old code (tested less than new code)
  • Complex parsers
  • Exposed attack surface
  • Security boundary crossing

• Modeling (most of the time is spent here
  • Model Data of our system
    • Data Types
    • Relationships (size,count,offset)
  • Model State of our system
    • Send, Receive, Call

• Validate (critical)
  • Verify model matches reality

• Monitor
  • Sending data is just the beginning
  • Fault detection
  • Data collection
  • Complex setup support

Basic monitoring should include debugger and network capture at the very least. Advanced monitoring should be extensible and have VM support (to revert after a crash).

It’s important for the fuzzer to not stop at the first bug found. Complex setups are required to ensure that when a fault is found it’s logged and then the fuzzing continues to see what other flaws are present.

Parallel running of tests is important when you start to look at large test-cases. By using 10 parallel tests at once you can drop the time required for a test significantly. Possibility of using something like Amazon’s cloud computing services to speed up the process (possibly at the expense of costs).

• Crash Analysis
  • Bucketing of duplicate crashes
  • Analysis of exportability
    • Microsoft’s !exploitable for WinDbg (supported in Peach)

Many freeware fuzzers use the Windows System debugger instead of the WinDbg direct COM objects. This limits their effectiveness.

Put some thought into the choice of what fuzzer to implement. Not only how modern and updated it is. Also check if it has a community around it, support (bugs, assistance), good documentation, training (taking it to the next level, get staff going fast).

Nice metrics on the adoptability risks of specific fuzzers. Lots of considerations to look at. What would happen if the sole developer of the fuzzer dies or gives up the project ? Commercial fuzzers are better for adoption, but lacking in other areas. Costs are spread. Open source costs less (free ?) but it takes longer to train staff and implement.

[Testing/Exploitation] Our favourite XSS filters/IDS and how to attack them

Slides available at http://p42.us/favxss

Both speakers are very active on the sla.ckers.org website discussing XSS attacks and filter bypasses.

New website should be up soon at tra.ckers.org –> discussing and tracking XSS attack vectors

Presentation covers mod_security and PHP-IDS on the server-side and IE8 / noscript on the client-side.

HTML Tricks such as “object data”, “isindex”, XHTML namespaces such as <x:script>

JavaScript Tricks “location=name”, setter, usage of non-alphanumeric characters, VBscript in event handlers

Using Firefox’s getter/setter allows you to bypass the requirement for parenthesis. This function has been marked as deprecated for around 3 years, but still functions in the latest FF versions.

There are a lot of examples here. Far to many for me to note. I’d suggest grabbing a copy of the slides and giving them a quick run against your favourite opensource applications 😉 in a testbed of course…

HTML5’s support of seamless frames could allow for pure CSS-based XSS attacks.

Unicode and XSS –

0xxx xxxx -> ASCII
1xxx xxxx -> Unicode

PHP’s Unicode function (c) attempts to fit 21bits into a 16bit variable. This causes and overflow and drops some of the input. This can be used to avoid some filters.

(Mod_Security)

Has issues when dealing with encoding types (filters are mostly ineffective)

Uses 2 stages of filtering. The first examines for specific keywords, if it fires, this is sent to the second stage which uses a regex to confirm the finding.

Good as a testbed for practicing XSS bypasses

(PHP-IDS)

http://php-ids.org

Very aggressive, blacklist based filter.

• Attempts to detect all attacks (not just common attacks)
• Easily catches all basic injections

The project homepage allows you to submit bypasses and have the ruleset tweaked to improve detection.

Detection is based on regex. Has in total around 68 filters targeting XSS and other attack vectors.

(IE8 XSS Filter)

Can be disabled from the server-side by injecting X-XSS-Protection header.

Various methods of bypass are possible including injection of new line chars, as well as alltering the use of things like document.cookie to document.[‘cookie’].

IE 8 filer doesn’t detect attacks against systems in the intranet zone ?

(NoScript)

Security over usability. Is NOT an XSS filter.

It is possible to bypass like any other filter. It’s also possible to DoS the NoScript process to sneak other javascript past the filter.

(IDS)

Simply bypass due to blacklist based solutions.

Using OR 2=2′– instead of OR 1=1′–

Very easy bypass methods that work on some of the more basic IDS systems.

Don’t trust your IDS – It can and will be bypassed

[Testing/Exploitation] Exploiting rich content

Adobe Flash is by far the mostly widely spread technology found during reviews.

Millwards Brown Survey claims that 99% of systems have Above Flash installed. A vulnerability in Flash has the ability to infect machines of all platforms.

FLEX and AIR are additions to the format.

ActionScript acquired by Adobe in 2005 during the buyout of Macromedia. Based on EMCAScript, so very similar to Javascript. ActionScript 2.0 supported by all popular flash players.

Testing Methodology

• Manual Testing
• Reverse Engineering
• Fault Injection

FlashFire (Fault Injection for Reverse Engineers)

• Gather Input
• Survey Input
• Mutate Input
• Process Instrumentation (breakpoint instructions to be monitored)
• Process Monitoring

Testing Flash using Flashfire

• 3 million injections in 36 hours of testing
• 23 unique vulnerabilities discovered

Using Read Beyond Bounds vulnerabilities to exploit systems. By using various sizes of stage it’s possible to force memory to be allocated in different areas of the heap. It’s then possible using the Read Beyond Bounds vuln in Flash to read other information from the heap within that section.

Due to the nature of the vulnerability the PoC will rarely fail on a system and works on every version of OS tested (were the heap is contiguous).

These issues are patched in Flash version 10.

--------------------------------

Checkout the material for these presentations at

http://www.blackhat.com/html/bh-usa-09/bh-usa-09-archives.html