Archive for June, 2007
Thomas Ptacek | June 28th, 2007 | Filed Under: Uncategorized
Joanna will accept our challenge, provided that:
We provide her with 5 laptops, to make a random guess less
than 3% likely to win the bet.
Our tests don’t crash or halt the machine.
Our tests don’t peg the CPU for more than 1 second.
We open-source our tools (and she’ll open-source her
rootkit).
We arrange to have her paid $384,000.
Our response:
Sure.
Wokay.
Irie! (hat tip: Ryan Naraine)
Yept.
Why would we pay you $384,000 to buy a rootkit we already know
we can detect?
Here’s what’s going to happen:
We’re going to get up on stage
for free
at Black Hat
for free
and explain how our detection techniques work
for free
and show our code
for free
whether or not you accept our challenge.
and
If, by some stroke of luck, you manage to get Blue Pill 2.x to the
point where you’re confident it actually works…
our challenge stands.
You don’t even have to pay us for it!
[Update: 7/5]
Dave Aitel, regarding SysCan ‘07:
Today at lunch:
1300 Singapore time
Title of Talk: Detecting BluePill
Speaker: Edgar Barbosa (COSEINC)
45 Comments
Dan Moniz | June 28th, 2007 | Filed Under: Gatherings
In keeping with the tradition of other CitySec meetings, it’s my pleasure to provide you almost no notice about CapSec, tonight at 7:30 PM at the Brickskeller in Washington, D.C. For anyone who hasn’t been there before, the Brickskeller is Washington’s best bar for beer, with a decent menu from the kitchen as well. Come hungry or come thirsty, they can take care of you.
We’ll be in somewhere the basement, and I’ll be sure to leave something obvious out so you can find the group. Help us kick off this inaugural CitySec meeting in the District. Once again, that’s the Brickskeller:
The Brickskeller
Dining House and Down Home Saloon
1523 22nd St, NW
Washington, DC 20037
Google Map
3 Comments
Thomas Ptacek | June 27th, 2007 | Filed Under: Defenses, New Findings, Uncategorized
Nate Lawson, spilling the beans on our some of our Black Hat plans:
“The crux of the matter is that a perfect emulator of any
sufficiently complex system would have to be a bug-free program, and
we don’t know how to write those yet,” he argued. “The important
thing to consider when writing a rootkit is what layer to implement
it at. Joanna chose “entire x86 PC”, which we argue is too big a
cross-section.”
Joanna, we respectfully request terms under which you’d agree to an
“undetectable rootkit detection challenge”. We’ll concede almost
anything reasonable; we want the same access to the
(possibly-)infected machine than any antivirus software would get.
The backstory:
Dino Dai Zovi, under Matasano colors,
presented a hypervisor rootkit (“Vitriol”) for Intel’s VT-X extensions at Black Hat last year,
at the same time as Joanna presented BluePill for AMD’d SVM.
We concede: Joanna’s rootkit is coolor than ours. I particularly
liked using the debug registers to grab network traffic out of
the drivers. We stopped weaponizing Vitriol.
Peter Ferrie, the Symantec branch of our Black Hat team, releases
a kick-ass paper on hypervisor detection. Peter’s focus is
on fingerprinting software hypervisors (like VMWare), but he also
comes up with a clever way to detect hardware virtualization.
Nate Lawson, Dino, and I are, simultaneously, working on hardware
rootkit detection techniques.
Nate, Peter, Dino, and I join up to defend our thesis at Black
Hat: if you surreptitiously “hyperjack” an OS, enabling hardware
virtualization (or replacing or infecting an existing hypervisor),
you introduce so many subtle changes in system behavior —- timing
and otherwise —- that you’re bound to be detectable.
And so the stage is set for our Black Hat talk.
For the record: I’m the least scary member of this particular team,
but have likely written the most code (by LOC) behind the
talk. Obviously, Dino’s Vitriol work is what made it possible for us
to figure this stuff out, and Joanna’s BluePill work —- which we
haven’t seen —- is what makes it interesting.
I’ll have more to say in the coming weeks.
9 Comments
Thomas Ptacek | June 27th, 2007 | Filed Under: New Findings, Uncategorized
Our commenters will be more useful than I will on this post, but:
Theo de Raadt on Intel CORE 2:
These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.
Errata he calls out specifically:
AI65
When the temperature reaches an invalid temperature the CPU does not
generate a Thermal interrupt even if a programmed threshold is
crossed.
I don’t see how this is a security concern; maybe he meant AI56,
which gives unpredictable behavior if you change the attributes of a
PTE without fixing up the TLB; AI64 involves system management mode
and AI67 involves VTX.
AI79
During a series of REP (repeat) store instructions a store may try to
dispatch to memory prior to the actual completion of the instruction.
This behavior depends on the execution order of the instructions, the
timing of a speculative jump and the timing of an uncacheable memory
store. […] When this erratum occurs, the processor may live lock
and/or result in a system hang.
Unless the behavior depends on system memory inaccessible to
userland, this could imply userland crasher exploit.
AI43
When a logical processor writes to a non-dirty page, and another logical-
processor either writes to the same non-dirty page or explicitly sets the dirty
bit in the corresponding page table entry, complex interaction with internal
processor activity may cause unpredictable system behavior […] and hang.
Two userland processes on two different cores can race each other and
hang the system?
AI39
When request for data from Core 1 results in a L1 cache miss, the request is
sent to the L2 cache. If this request hits a modified line in the L1 data cache
of Core 2, certain internal conditions may cause incorrect data to be returned
to the Core 1.
Where the word “incorrect data” is errata code for “Zuul’s return as
the Sta-Puft Marshmellow Man” —- two cores race each other, and a
process gets the wrong cache line.
AI90
If code segment limit is set close to the end of a code page, then due
to this erratum the memory page Access bit (A bit) may be set for the
subsequent page prior to general protection fault on code segment
limit. […] a non-accessed page which is present in memory and
follows a page that contains the code segment limit may be tagged as
accessed.
Theo says this is exploitable on operating systems other than OBSD;
the A bit signals the VM system that a page has been accessed by the hardware.
AI99
Code #PF (Page Fault exception) is normally handled in lower priority order
relative to both code #DB (Debug Exception) and code Segment Limit
Violation #GP (General Protection Fault). Due to this erratum, code #PF may
be handled incorrectly, if all of the following conditions are met:
A PDE (Page Directory Entry) is modified without invalidating the
corresponding TLB (Translation Look-aside Buffer) entry
Code execution transitions to a different code page such that
both:
One of the following simultaneous exception conditions is present following the
code transition:
Software may observe either incorrect processing of code #PF before code
Segment Limit Violation #GP or processing of code #PF in lieu of code #DB.
We’ll have more to say about chip errata this month.
2 Comments
Dave G. | June 25th, 2007 | Filed Under: Slashdot Rounddown
The answer is best summed up in this article about the ATM Machine turning 40 years old. They quote John Shepherd-Barron, the inventor of the ATM:
Mr Shepherd-Barron came up with the idea when he realised that he could remember his six-figure army number. But he decided to check that with his wife, Caroline.
“Over the kitchen table, she said she could only remember four figures, so because of her, four figures became the world standard,” he laughs.
If you had asked me how they had come up with the length requirements, I would have thought that somewhere, someone might have tried to run some basic statistics, figure out acceptable losses based on likelihood of a PIN number getting guessed. Then try and balance that user requirements.
Nope. That wasn’t (isn’t?) how decisions and standards are made. And even today, MOST PINs are four digits in length. Policies are well documented inside of the enterprise. One thing that usually doesn’t get well preserved is why those policy decisions were made.
The other choice quote from this article:
“Money costs money to transport. I am therefore predicting the demise of cash within three to five years.”
While I can appreciate anyone who tries to predict the future, we should remember there is a reason why we say most of them are insane. I can see a future without cash, but even if we all said right now that it is time to move away from cash, it would take more than five years to execute on that.
Finally, Mr Shepherd-Barron, is working on a new invention. One to scare salmon-stealing seals away from his salmon farm:
“I invented a device to scare them off by playing the sound of killer whales, but it’s ended up only attracting them more.”
It’s clearly an uphill battle to top the invention of the ATM.
6 Comments
Eric Monti | June 20th, 2007 | Filed Under: Development, Reversing
In the process of doing software security analysis, it is pretty common to encounter unknown network protocols or file formats that are part of the attack surface you’re investigating.
Not too long ago, we wrote a post entitled Reversing a ZLib-obfuscated? Network Protocol where we talked about reversing an undocumented protocol to look for security weaknesses. We got several good questions about some of our deductions about the protocol as we picked it apart. I’d like to take the opportunity to talk more about protocol reversing in general and hopefully help explain how that deduction process works while getting some broader coverage on the subject in.
This will be the first of at least 2 blog posts. I’m going to start by discussing building blocks and see where that takes us. In the early phases of talking about this process, I’m not making a distinction between whether a protocol is “unknown” because of lack of documentation or because it’s simply “unknown to you/me” because we’re unfamiliar with it. Of course an undocumented protocol is going to be tricker to reverse. If there’s a point to these initial posts, it’s that working with documented protocols helps us understand the undocumented ones.
To illustrate some basic protocol dissection ideas, I’m going to talk about iSCSI. I mostly picked iSCSI since I happen to be working with it at the moment and it makes a pretty good case study.
In this post we’ll:
1. Talk a little bit about what iSCSI is and what it’s for.
2. Use Wireshark to find a iSCSI PDU and isolate it.
3. Compare the raw PDU to the specification.
4. Talk a bit about how this all relates to protocol reversing.
In a nutshell iSCSI is:
… SCSI over IP. It’s designed as a low cost solution for network attached storage. A storage server (say a NAS appliance) exports storage as “targets” on any TCP/IP network to which clients (aka “initiators”) connect. Once attached by connecting and logging on, the initiator’s OS sees the target as a hard drive and treats it as a block device. Filesystem drivers ride on top of the device as they would any other SCSI device. Besides file access, an initiator can arbitrarily partition and format the target using its allocated space.
Sounds a bit crazy from a security perspective, right? Well, just bear in mind that that iSCSI is not intended as a replacement for CIFS or NFS at all. iSCSI is first and foremost designed as an alternative to more expensive fiber channel NAS solutions by using cheaper gig-ethernet and possibly leveraging a company’s existing network infrastructure. The iSCSI spec is also apparently designed to be used over other transports besides TCP/IP.
We’re interested in what iSCSI looks like on the wire. This is not undocumented or new territory. Wireshark has iSCSI decoding capabilities way above and beyond the simple dissection tools we’re going to get into for iSCSI. We’re not going to use those decodes much for this discussion, though. Building our own tools gives us more intimate knowledge than relying on Wireshark will. We also want to have some building blocks for doing things later like fault injection if our exploration leads us that way.
iSCSI’s a good case study for protocol exploration since it’s not exactly a “common” network protocol, but has pretty decent documentation and specifications available in RFC’s. Picking it apart with some guidance helps illustrate some common network protocol concepts and we can double-check things against the actual specification to make sure we’re getting them right.
Here’s a hexdump of an isolated iSCSI PDU as it appears on the wire:
I isolated this using Wireshark and saved it as a as a file to work with. iSCSI uses TCP/3260 as its transport. The pcap filter for this is “tcp port 3260″. Here’s how I did that:
Now that we’ve isolated a sample, the next step is making sense out of the raw PDU. If this were an undocumented protocol, this would be the part where we opened it in a hex editor and started trying to separate chunks into boundaries based on educated guesswork, assisted by good conversion tools. Actually that’s just one way. Probably the most basic one.
This involves a lot of educated guesswork and is not always a straightforward process. We’re still talking about the guesswork, not doing it (yet).
Here’s the basic header syntax of an iSCSI PDU as defined in RFC 3720 (yep there it is… we could stop now, but where’s the fun in that)
This type of breakout basically represents how we’d like to be able to understand a network protocol. It’s very rare, even at best, that you’ll actually figure out what every field is for in an undocumented protocol. Just getting fields broken up so you can make sense out of most of them is what you’re usually going after initially. As you start to make sense of other things later, the things you may have originally passed over can gain context.
This RFC explains the various fields pretty well and covers much more than just that. There’s more information in there than we are even likely to need. This raises a good point. Before you start “reversing” anything, always make sure it isn’t documented somewhere or implemented in something you can pull apart.
Using the spec to guide us, we’re going to try to understand this header and see what our captured PDU says. We’ll need to write a tool for this.
In the next post, we’ll:
1. Write a C dissector to emulate Wireshark decodes.
2. Write a Ruby dissector to approximate the C version.
3. Discuss some pros and cons of each.
4. Discuss some of the general things we can learn and how they can be applied to reversing truly unknown protocols.
7 Comments
Dave G. | June 20th, 2007 | Filed Under: Apple, Industry Punditry
The fear mongering stories about the iPhone are beginning to pour in. From exploits to execs storing critical data on it, everyone is talking about how the iPhone is going to be the next security nightmare.
Every device that walks into your organization is just another way for data to leave. Laptops, iPods, cell phones, PDAs and even the dreaded Furby have all gone through this same set of concerns.
Yes, somewhere deep inside of every enterprise is a small team of people that have to worry about data management. And yes, everytime something like this comes out, they have to write a bunch of policy blocking it. And then they have to start relaxing that policy as the devices become commonplace.
If you are responsible for keeping data inside of your organization, for the love of everything that is holy, please don’t spend too much time on the iPhone. Allow us to remind you about all of the data breaches that are happening thanks to insecure wireless access points, tape backups disappearing, wrapping your newspapers in customers’ personal financial information, and stolen laptops.
Will the iPhone compound this problem? Slightly.
Will researchers attack the iPhone? You bet.
Will attackers spend a lot of time trying to steal data off of an iPhone? I doubt it.
Will someone run Linux on the iPhone? Sadly, yes.
The person that spends 500$ on their phone will protect it more than the laptop you issued them.
18 Comments
Dave G. | June 14th, 2007 | Filed Under: Gatherings
NYSEC is a-comin’ in a little less than a week. It will be located at Pound And Pence, 55 Liberty St. in the financial district, on TuesdayJune 19th, starting at 6PM. They usually run between two and three hours, and are chock full of smart and interesting security folks.
Reminder: There is a google calendar for NYSEC. It lets you export into your calendaring software.
IndySec 8 will be on June 21st. More details here.
BAYSEC will be on June 20th 2007 at 21st Amendment in San Francisco.
SeaSec will be on Monday June 18th at Broadway Grill at 7PM.
Is there a citysec in your town?
No Comments
Jeremy Rauch | June 12th, 2007 | Filed Under: Apple, Disclosure
[Interesting Discussion In Comments -daveg]
Its no secret: I’ve advocated “responsible disclosure” for years. I
don’t buy that vulnerability research, and discourse about findings,
is why there are so many security problems. Keeping our heads in the
sand won’t improve the situation.
Apple’s recent release of Safari for Windows spurred people in our
community to start looking for its flaws. Great. I say Safari, for all
its good qualities (it’s quick, looks nice, and claims to render more
accurately than other browsers), hasn’t benefitted from
the scrutiny IE or Firefox gets. If people spend time looking at it, finding
vulnerabilities, and reporting them back to Apple, we could have
something here. That a large portion of its open sourced makes it all the better.
I’ve been finding vulnerabilities for over 10 years. I’ve been
frustrated by vendors that resist patching flaws. And I’ve seen
serious flaws go unfixed, due solely to vendor apathy, on numerous
occasions. I can see how that could make someone question the
“responsible” side of disclosure. Are we wasting our time “playing
nice” with vendors?
One of the things we codified when we started Matasano was a
disclosure code of ethics. Part of it applies today. In spite of the
bad vendor experiences we’ve all had, individually and as group, we
felt strongly that to research vulnerabilities without keeping vendors
in the loop wasn’t something that we could participate in.
In fact, we’ve gone one step further. We won’t release information
without a vendor patch being available. We’re just not comfortable
deciding how you should manage your risk. I’d like to keep
thinking that disclosure is about making software safer, and not just
about ego and marketing.
And that’s why, after my blog hiatus/hibernation/avoidance, I’ve
decided to post again.
I say, have all the hostility you want towards Apple. Apple may have
done Dave Maynor wrong. Dave may be justified in carrying a grudge. I
don’t know all of the facts there, and at the moment, it doesn’t look
like any of us will. But I hope Dave, and all the other people taking
shots into the barrel of fish that is Safari, are going to do their best
to deal responsibly with Apple. I’ve found the Apple security folk
I’ve met to be well intentioned and concerned, even if they are severely
overburdened and understaffed.
But Dave, if you’re not going to keep Apple in the loop, and you are
going to harbor secret Safari vulnerabilities that only your company
and your customers and whoever your customers talk to and whoever ever
manages to break into those customers may be, can I ask a favor? Can
you post what your code of ethics is? A lot of us would like to
know. We could show a spectrum, from Errata on the “left”, through
MoXB, to eEye on the “liberal”, Matasano on the “centrist”, ISS on the
“conservative”, and Cisco on the “right wing”.
48 Comments
Dave G. | June 11th, 2007 | Filed Under: Industry Punditry
Problem Statement
One of the more interesting problems product companies face is the embedding of 3rd party applications and libraries. Apart from all of the normal support challenges, API changes and the like, you are tied to another vendor’s security posture. This includes:
How they respond to security vulnerabilities. If they sit on vulnerability reports, those are latent vulnerabilities in your product. I do not envy the vendor who tries to explain to customers why they are vulnerable. Even if it isn’t your code, it is your responsibility.
Patching release cycles. When your popular database program releases a patch that fixes 5 critical remote code execution on Monday, how do you vet out the patches and get them out to your customers? How fast can you reasonably move? Take a look at
how this impacted Mac OS X with the recent Samba vulnerability.
The second issue is really challenging for vendors, as they don’t even have an early warning system in many situations. They find out at the same time everyone else does.
What Do You Do
Vendor. Perform your vendor selection for your third party components carefully. Ask them what their policies are on vulnerability disclosure. When interacting with commercial developers try and get early access to security updates so you can start your internal testing processes. For open source, you should always be tracking the projects you are leveraging.
Enterprise. Identify what third party components (and their version numbers) exist inside of the applications you purchase. This will let you track which libraries and open source/third party projects that are actively deployed in your enterprise. That should let you apply pressure on vendors when you find that your database is 9 months behind on critical security patches.
What other advice do our readers have for this problem?
9 Comments
