Jeremy Rauch | July 31st, 2006 | Filed Under: Uncategorized
Since all of the cool kids are saying which talks they’ll be at during Blackhat, I feel its my duty, as Matasano’s coolest kid, to let you all know where I’ll be. In no particular order:
- Halvar’s talk: I’ve been lucky enough to see Halvar at a number of Blackhats over the years. In spite of his disclaimers in his comments to Dino’s post the other day, his talks are always interesting. Personally, I find tool demos at talks to be a mixed bag — I’d much rather hear Halvar’s thoughts on the challenges that face people doing binary reverse engineering. My money says he has some really cool ideas on how to overcome them. He’s also one of the nicest guys in computer security, so make sure to say “hi” to him.
- Chris Eng: Breaking Crypto Without Keys: Analyzing Data in Web Applications: Chris is a super smart guy, with a mysterious NSA background. Ooooh scary. Seriously, though — I’ve heard some rumors about what Chris will be speaking about, and it ain’t no rot-13 breaking.
- David Hulton + Dan Moniz: FPGA hacks: Put the word FPGA in your talk title, and I’m there. Having done some work with FPGA’s (but not in a computer security setting), I’m always interested to see what people come up with.
- FX: The Blackberry Case: I wish! I get the “privilege” of speaking opposite FX, otherwise I’d be at this one. Our phones are turning in to insane little networked computers, and I’m curious to hear what FX has to say. Hopefully one of my traitorous coworkers, who apparently want to go to FX’s talk instead of mine will let me know what he has to say.
I’d put my own talk, or those of Dino or Dave/Tom, but that smacks of…is nepotism the term? Close enough. The Dave/Tom talk I’m familiar with — I’ve actually delivered pieces of the talk that sort of evolved in to this one. Its chock full of intrigue, espionage and action. Definitely the makings of a summer blockbuster.
I haven’t seen Dino’s talk yet — no one has, but judging from his exciting ramblings over the last few months, this one is sure to be a fun one. However, he keeps asking me weird questions about my machine stability, and won’t tell me why. Go to his talk, and maybe he’ll let you know.
No Comments
Thomas Ptacek | July 29th, 2006 | Filed Under: Navel Gazing, Uncategorized
Our readers are cooler than we are, and you can’t see them if you’re
just reading us in RSS. Choice comments from July:
Halvar Flake on “Dramatic Speedup in AES Timing Attacks”
[…] Throwing overboard a paradigm that we happen to understand pretty
well (S-Boxes, their linear and differential characteristics and how
to construct them in order to make modelling them as polynomials
annoying) because of an implementation issue that we could fix is
“emptying the bath with the child” […]
Dennis Cox on “Improving The Great Firewall of China”
[…] It’s equivalant is the “upstanding” people that bragged about them
helping the underground railroad while it was happening for
politicial/fame means, which caused parts of the underground
railroad to fail. It’s selfish - plain and simple. I wonder what
happens when some poor freedom loving person in China that has been
using these methods and gets caught? […]
Ivan Arce on “Improving The Great Firewall of China”
I think all of this is irrelevant. My impression is that those “poor
freedom loving persons in China” are way smarter that the Watson
group and all the rest of us. They do not need to be schooled about
MITM attacks and IP/TCP tricks. What’s next? Other clever people
will tell them how to break hash functions and how to write
exploits…
Dan Ingevaldsen on “Improving The Great Firewall of China”
I’m in China right now, and I don’t have anything to say about the
great firewall or anything, but I am definitely wondering why every
American here is wearing sweatpants. Can you guys do a blog entry
about that? Thanks.
Wendy N. on “Arbor Ops on Why You Shouldn’t Use RFPs”
Not only that, but in the public sector, where all contracts and
purchases have to be justified, accounted for and audited in
excruciating detail, the RFP is absolutely necessary. You have to
prove that you had a planned set of requirements, and you have to
demonstrate that your process for selecting the right vendor to meet
those requirements was above-board, fair, and provided the “best
value” to the taxpayers. (Well, that’s the theory, anyway.) Just try
explaining to an auditor that you watched a WebEx and picked up some
brochures at a trade show in order to spend $100K …
Paul Morville on “Arbor Ops on Why You Shouldn’t Use RFPs”
Yes, nothing cuts through the marketing bullsh*t like a good RFP!
Most RFPs are largely an exercise in cntl-c/cntl-v of the same three
year-old copy you’d get through other channels.
The stack of paper is undoubtably impressive to auditors and
managers, but there are probably more efficient ways than having
5-10 companies collaborate on a giant position-piece.
Mike Rothman on “Arbor Ops on Why You Shouldn’t Use RFPs”
[…] An RFP is one of quite a few information gathering steps that a user
can take. Depending on the nature of the purchase, it may make sense
or not. But in no way shape or form am I saying RFPs don’t need to
happen.
wrc on “Really, MD5 Sucks For Password Storage.”
If you’re talking the good-old-fashioned, traditional crypt(), the speed disadvantage of using md5 disappear once that ninth password character gets used.
To defend against a brute force attack, you can increase the search
space or increase the time for each search. Both work. Every
implementation of md5 for passwords I’ve seen had the capability (if
not the actuality) to increase the search space.
Steven on “Really, MD5 Sucks For Password Storage.”
Poul-Henning Kamp’s MD5-crypt, the one used on FreeBSD, is not a
single iteration of MD5 over the salt and password. It uses a 1000
iteration loop that continually remixes the password and
intermediate hash values. It’s quite a bit slower than crypt(3).
I owe PHK an apology
Greg Hoglund on “My Sacrosanct Kernel”
Trust isn’t based on the technology used. You trust your own code
don’t you? After all, you did write it? Or, someone you trusted
wrote it? There is some inherent trust in, say, Symantec, when you
install their software, right? Do you really believe that using
similar technology implies similar intent of the user? You probably
are for gun control too? […]
Richard Bejtlich on “Bejtlich Considered Wrong (For A Change)”
External intruder (”outsider”) scenario:
- Outsider attacks and compromises victim.
- Victim recovers, outsider remains at large.
- Return to step 1, except add to the number of outsiders.
Internal intruder (”insider”) scenario:
- Insider attacks and compromises victim.
- Victim recovers, and removes insider.
- The insider population has decreased. Until a new malicious insider is hired, the threat has actually decreased — as opposed to the external intruder scenario.
Josh Daymont on “Symantec Paper Validates Trustworthy Computing?”
Ivan is probably right in regards to this being a bad sign for the
new Vista ip stack. I reskimmed the paper and didn’t find the issue
of techniques specifically addressed, but most of the language
around discovered vulnerabilities indicates that this research did
not include any binary analysis of the stack, but instead was
limited to testing it through simlpy remotely pentesting the box. If
this is the case and then there will definitely be lots of
interesting problems lurking behind the scenses, and if microsoft
doesn’t have some qualified vulnerability researchers do a binary or
code based analysis of the stack before release, well then you can
bet your bottom dollar the intruder community will find some 0day
when they do just such a thing post release.
Nate Lawson on “Oh, The Bad Crypto You’ll See (an open letter)”
there are only 2 categories of manufacturers.
You’re Not Special (98%):
Separate your marketing department’s claims about your
product’s external view from the internal design. Nearly all
problems boil down to ones already solved by existing protocols and
libraries. Encrypting a file? GPG. Sending anything over the wire?
TLS/SSL. Your special sauce is in how you glue all these things
together to make some product. Don’t reimplement these, and still
get review of how you’ve glued them together.
You Are Special (2%):
You are Voltage and you were founded by Dan Boneh. Or your business
is cryptanalyzing products in concert with Adi Shamir. Note the most
important part here — if you’re special, you are willing to plunk
down $400/hour for a full-time cryptographer for at least 6 months.
Chris Wysopal on “Do We Need an ISO Secure Coding Standard?”
The solution is not more lists of things not to do, its checking
technology to tell you when you did do one of those things. […]
3 Comments
Thomas Ptacek | July 28th, 2006 | Filed Under: Defenses, Gatherings, Uncategorized
Device Drivers, Johnny Cache and David Maynor: Johnny
and David can get ring0 on your laptop just by having you turn
it on, by exploiting bugs in your 802.11 drivers. Johnny’s
also got an 802.11 driver/chipset fingerprinting tool. They
say that driver code is full of holes that were fixed in
app-layer software years ago. I buy it.
Analyzing Complex Systems: The BlackBerry Case, FX: FX
scares the crap out of me. I don’t care about BlackBerries
per se (although I’m sure you do), but “huge complicated
system with no documentation and proprietary everything”
describes a huge chunk of what Matasano tackles. Expecting to
learn stuff.
Vulnerabilities in Not-So Embedded Systems, Brenden
O’Connor: I’ve never seen any of Brendan’s stuff. I spent
some time looking for what the OS was on the Xerox printers
he’s broken. I’m hoping it’s not just embedded Win32
(yawn). But even if it isn’t: these are your printers!
Network printer malware has a shot at halting paper-based
business processing across the world, so this has my
attention.
2 Comments
Dino Dai Zovi | July 28th, 2006 | Filed Under: Uncategorized
BlackHat is coming up and it looks like there will be some great talks this year. I’m really looking forward to some of them for various reasons:
2 Comments
Thomas Ptacek | July 28th, 2006 | Filed Under: Navel Gazing, Uncategorized
Ron Gula leads Tenable Security, a thriving product company that ranks
as one of the startups I most admire in the space. They manage Nessus
(much as SourceFire manages Snort), and invented Nevo (now “PVS” —-
put the old name back, Ron!), the Passive Vulnerability Scanner. When
Ron says something, I listen.
Which is why it’s a good thing that his team now has a blog. I’m
looking forward to what they have to say.
No Comments
Thomas Ptacek | July 26th, 2006 | Filed Under: Industry Punditry, Uncategorized
A better title for this Secure Computing press release would be, “Secure Computing
Thinks Trade Journalists Are Pretty Dumb”. Choice quotes:
… artificial intelligence (AI) software used in testing by a small
number of software developers is now being widely used by hackers to
find formerly undiscovered vulnerabilities. These AI tools use a
methodology referred to as “Fuzzing.” …
and
“Software vendors were already struggling to keep up with patches
for software bugs; the use of Fuzzing tools by hackers and the
flood of newly discovered vulnerabilities may overwhelm software
vendors’ ability to respond with patches.”
… because prior to advent of “fuzzing”, vendors were doing just
peachy keeping up with patches. Damn you hackers!
A question for the journalists reading chargen (we know you’re out
there): do vendors get penalized in any way when they’re this
blatant?
Thanks to HDM for the headsup.
2 Comments
Thomas Ptacek | July 26th, 2006 | Filed Under: Gatherings, Uncategorized
In the wake of Bejtlich starting NoVASec, Adam and Chris trendspot
“The CitySec Movement” (and thank you for the name, which I am
stealing). Adam seems to have theories as to why CitySec
works. Ok. For my part, all Cory Scott and I did was make CitySec simple to go to:
no registration, no dues, no membership, no minutes, no vendors, no
sales pitches.
CitySec meetups will work for all the reasons formal meetings
don’t. 99% of the value you get from going to a meeting is, uh,
meeting people. Everything that isn’t about hanging around drinking
with interesting security people in your area is overhead.
The CitySec meetings we know about include:
- ChiSec in Chicago (next one: late August)
- NYSec in New York
- SeaSec in Seattle
- BeanSec in Boston (coming soon, inquire for details)
- NoVASec in DC Metro
We’ve gotten pings for BaySec and, I believe, Austin
(SouthBySouthSec! (duck)).
You can feel free to comment here if you’re interested in any of
these, or have other locations to suggest. The rule is, two people
find themselves wanting to set up the same CitySec, and it’s on.
19 Comments
Thomas Ptacek | July 26th, 2006 | Filed Under: Defenses, Uncategorized
Dark Reading quotes me again, because I’m all famous and stuff. This
time, I’m bloviating about CERT’s efforts to create an ISO “secure
coding” standard. Quoth the cynic,
Tom Ptacek, researcher with Matasano Security, says there are
already plenty of sources of information on secure programming. He’s
skeptical of the impact of CERT’s standards. “And what does
standardization actually mean? What is scarier to say about a
program — that it is nonstandard or that it is insecure?” Ptacek
says. “The code we deal with is already insecure. Sophisticated
buyers know in their gut that this is true. So why do they care if
it’s nonstandard to boot?”
Before I gave this quote, I actually did pore through the
SCI materials. As you can expect, the above was a choice quote. If you’re a
security geek, the rest of my rant might be interesting:
There are already a myriad of good sources of information about
secure programming, including books targeted specifically to
developers that don’t have experience with secure
programming. I don’t understand why a wiki or an ISO standard
would be more accessible to these developers, who write the
majority of all code.
I’m talking about “19 Deadly Sins”, and yes, you should read
that before you read a wiki on secure programming.
Most bugs of any type are caused by simple, well-known patterns of
programming errors. We’ve been documenting these patterns for
decades. But we still have bugs.
Let me put it this way: you can write insecure C++ STL code,
despite the fact that “safe” STL programming has books,
standards, and built-in checking tools
The types of errors targeted by the CERT SCI are similar to the
types of errors that high-level languages such as Java are
supposed to eliminate. But a typical Java network program is
rife with security errors. Once you eliminate the simple
vulnerabilities, like buffer overflows, attackers just move to
logic flaws.
Right now, the SCI will help you avoid buffer overflows and
integer errors. Good luck with SQL, or crypto, or state
machines. Even against C code, a large portion of
what Matasano finds is not textbook overflows
We already have standards for secure “products”, such as the DOD’s
own Common Criteria. These standards are heavily touted by
marketing groups and broadly ignored by the rest of the
industry.
Especially if all the “standard” says is that you haven’t
misused “strcpy” in any obvious way, and is then used to
preempt customer security testing.
I guess I have a bigger problem with “secure coding standards”, and I
can’t figure out how to say it without making 2 points:
The security problems of code that has already been written
totally dwarfs the problem of new code, and standards don’t
do much to solve that problem.
The solution to the secure coding problem is going to come
from security QA, not secure coding.
3 Comments
Thomas Ptacek | July 26th, 2006 | Filed Under: Industry Punditry, Uncategorized
Slightly off topic, but I can’t resist. This Slashdot article cites an
interview claiming that Vyatta’s XORP-based “open source router” will
give Cisco a run for its money in the mid-market. Look, XORP is cool,
and I wish Vyatta the best of luck. But come on.
Data center routing belongs to switches. Routing protocols are
not the hard problem in switching. Vyatta can’t make a dent in
price-per-port. Not only do they not have hardware, but the
one place they haven’t spent time is the forwarding path.
Click is a project that innovates in the router forwarding
path. Suez is a project that used commodity hardware to build
a scalable switch. XORP is a next-generation GateD hooked up
to the Linux forwarding path.
Open sourcing routing protocol processing is old, old news;
remember GateD (it was much more profitable for NextHop to
license it to hardware manufacturers than to get ISPs to use
it instead of old Cisco gear) and Zebra?
The opex costs of a high-speed telco circuit or a colo gigE
connection utterly dominate the capex costs of buying the
router itself. Buying and building a Vyatta switch is probably
a dumb purchasing judgement. Tell me the circumstances in
which I’m wrong, and I’ll concede the point.
Routing is a fraction of Cisco’s revenue, and the buzz
around Cisco’s routing product line, especially in the markets
where Vyatta would play, is the ISR. Vyatta isn’t even close
to the ISR (answer to integrated PIX: NetFilter. answer to
integrated VPN: none.). Maybe Vyatta should figure out a way
to bundle Asterix.
What really sets me off here is the Vyatta spokesman saying “sure,
we’ll be doing hardware too! So forget about the 800mb/s you can push
through PCI now!” Brother, I can say the same thing too. The Click
project did interesting things with high-speed forwarding without
hardware. Last-generation NPUs and Xilinx boards are probably fertile
ground for real open source forwarding hardware. If you’re going to do
that, go do it. Otherwise, shut up about hardware. You’re a PC, just
like KA9Q was.
7 Comments
Thomas Ptacek | July 25th, 2006 | Filed Under: Bitching About Protocols, Defenses
Dear Software Development Industry,
Please stop writing your own crypto code. You aren’t qualified. I know
that sounds harsh, but here’s how I know I’m right: I’m not qualified
to build cryptosystems, and I can find the flaws in your
products. The history of your present efforts is one of repeated
injuries and vulnerabilities. To prove this, let facts be submitted to
a candid world:
You have used ECB encryption, often without even knowing
it; ECB is what is accomplished by repeatedly applying the AES
block function in a “for” loop. The deficiency of ECB is so
simple that it can be demonstrated with a picture:
The bottom image has been “encrypted”, using a strong
passphrase, with 128 bit ECB AES. But one block of 16 “black”
bytes is the same as any other such block, all of which
ECB encrypt to the same ciphertext.
“Seeing through” encrypted bitmaps is not the practical
problem with ECB. Replayability is. In your lock-step
client/server protocols, where messages can be distinguished
by size, direction, and protocol iteration, this weakness
is intolerable.
You have confused encryption with authentication, in
the belief that forcing an opponent’s injected message to
decode to gibberish is a defense against forgery. Injecting
gibberish is the greater part of what your opponent is trying
to accomplish, and because you aren’t encrypting the passage
of time, you concede to your opponent the placement of that
gibberish as well.
You have relied on key exchange for authentication,
perhaps believing that an attacker who has expended the effort
to write a malicious client to your encrypted server has
exhausted herself and will be incapable of writing a malicious
proxy server to complete the circuit. Neither an RSA key without
a verifiable signature, nor an RSA key whose signature you
fail to verify, nor the MD5 of a public certificate without
confirmation that the opponent holds the corresponding
private key tells you anything about the identity of a caller.
You have failed to check parameters, and if you believed
detecting malicious input was hard when working with SQL
metacharacters, try it modulo a large prime number. A number
raised to the 0th power is 1, even mod p.
I could offer individual solutions to each of these flaws (CBC or CTR
mode, HMAC, etc). But as I said before, I’m not qualified to do that,
and you aren’t qualified to evaluate my advice. Your only reasonable
option is to fall back on the competence and experience of those who
are qualified. And that means that if you’re trying to:
encrypt data sent over the wire so I can’t read it, or
use crypto to verify the integrity of that data so I can’t fake it, or
use crypto to verify my identity, then
you are going to use TLS, with a peer-reviewed library, meaning, the
same one everyone else uses.
Sincerely,
Matasano Security
4 Comments
