When OSX Worms Attack!

Dave G. | February 28th, 2006 | Filed Under: Defenses, Malware

OS X security is very popular to talk about right now. On one side, you have rabid Apple fans who insist that OS X is completely secure. On the flip side, you have security experts claiming that OS X is swiss cheese. I doubt it will surprise anyone that I say its somewhere in between. Let me throw my hat into the ring on this subject, and we will start with the latest OS X issues:

1. Leap.A: Seems to be a genuine, in-the-wild worm. Not clear to me if this was just posted somewhere or if people genuinely got infected. Even if it was running around on the Internet, I suspect the number of infected computers was quite low.
2. InqTana.A,B,C: Grandstanding. Written so that it could be sent to AV vendors and be talked about in mailing lists. Well documented techniques, or variations on well documented techniques. Only existed in a lab.
3. Safari/Mail Vulnerability: Far more interesting. This is a serious vulnerability that needs to be fixed. If you are Mac user, I would at the very least uncheck ‘Open Safe Files’ in Safari preferences. I don’t understand why Apple isn’t advising people on this better. This vulnerability is public, trivial to exploit, and we are at the 7 day mark.

1 Comment

Self-interested Rambling on Consolidation

Thomas Ptacek | February 27th, 2006 | Filed Under: Industry Punditry

Oh I do so love these posts by Richard Steinnon. They’ve got to be true. They’ve just got to be!

But:

• Are there really more firewall vendors playing in the majors now than in 2000? Who am I missing:
  • Cisco
  • Checkpoint
  • Juniper/Netscreen
  • Sonicwall
  • Watchguard
  • F5
  • Microsoft doesn’t count.

  Which vendor entered the market after 2000 and, after 6 years of competing, established a viable niche? I’m guessing (irresponsibly) that you hit hand-rolled OpenBSD+pf in the Global2k before you hit anyone outside the shortlist here.

  And only a few of these vendors are viable exits for an entrant that took an A round.

• On the other hand, if you draw a line at vendors who beat $1MM in trailing revenue, what happens to the number “1500” here? And, I assume (irresponsibly) that the overwhelming majority of serious novel entrants to the security market plan to primarily address North America. What happens to the list when you slice off APAC and products you can take to market just by double-byteing the UI of another product?

So I’m conflicted: on the one hand, the consolidation meme seems to have legs (it seems like it should be harder to bring an IPS to market now than in 2000 —- though given the margins you can command with one, maybe that’s a silly thought). On the other hand, the factoid about the thundering herd of security companies seems artificial too.

On the other other hand, the article Steinnon riffs off of is legitimately retarded. “If you met with two [of the 700] different vendors a day it would take a whole year including weekends”, says Toby Weiss of CA.

And, If you take the ~200 of those 700 who are viable and relevant, triage the 2/3rds of them that align with this years spending priorities, and divide them over all the IT security buying centers in a typical Global2K enterprise (Windows Server, Windows Desktop, Unix, Storage, Networking, IT Security) and scale by regional divisions, your architects and decision makers still have an awful lot of time to read ESPN, Slate, and Reddit.

1 Comment

Oh, The usage() Function’s You’ll Write!

Thomas Ptacek | February 27th, 2006 | Filed Under: Bitching About Protocols, Matasano, Reversing

For those of you playing along at home, blackbag has been bumped to 0.6, as I lazily spiral deeper into a fugue state of Unix shell protocol testing one-offs. Don’t worry, you’re not missing anything, my colleagues are as confused by it as anyone else.

Here’s the new stuff you get, all for the low-low price of editing your own cryptic makefile:

• len: read input, tack a binary length to the front, end, or offset, in 8, 16, 32, or 64 bit format, BE or LE.
• shf: instead of dd. chop bytes off beginning or end of a file. chop a byte, try decryption, chop a byte, repeat.
• touchwait: synchronize a shell script on the mtime of a file; telson will also update that file on I/O if you tell it to.
• tsec: “tsec -t .5 yes” prints 500ms of “yes”; more importantly, “cat foo | tsec .1 nc -u victim 161” allows subsecond timeouts for netcat.
• sub: fuzzing printf. take a binary message capture, open it in a hex editor, find the “username”, replace it with “${hex:1000}”, then “cat capture.raw | sub | blit” to send broken message to server. Also, “${shell:echo foo}”.
• asn1: See previous posts on shell-script ASN.1 fuzzing, and note that I am in fact cheating by giving you programs written in C to generate the low-level binary data.

Some other changes:

• telson supports listen mode (for clientside attacks), and may or may not support SSL.
• replug supports UDP mode, because as the deranged Howard Hughes of Unix protocol pen-testing it has become easier for me to write C code than to figure out how to specify a nonstandard port for “snmpwalk”
• b64 and “hexify +” print pretty.
• … and all the programs now have usage statements.

Telson’s hacked-up “listen mode” and “touchwait” allow you to create shell scripts to generate bogus responses to client requests:

telson sync:./oninput @:5555 &
while [ 1 ]
do
touchwait ./oninput
dd if=/dev/random bs=1 count=500 | len | blit
done

2 Comments

And now the Triple Axel of sarcastic marketing commentary:

Thomas Ptacek | February 24th, 2006 | Filed Under: Industry Punditry, Matasano

From the front page of security “startup” Consentry Networks: “Consentry earns 8 out of 10 Stars from CRN!”. What’s wrong, guys, couldn’t afford the other two?

(And he lands it!)

No Comments

Jerry Springer’s Bugtraq

Dave G. | February 21st, 2006 | Filed Under: Disclosure

Nothing like ethical debates on bugtraq. To try and sum up the original post in a sentence or two, it would be:

Advanced societies are producing tougher computer crime laws which will reduce/eliminate the number of talented security professionals because there won’t be as many people who have real life experience breaking into computers. Advanced societies will ultimately have less security because security professionals won’t have a hacking background.

If this were an episode of Jerry Springer, it might sound something like:

“I can’t break into a computer to explore? *BEEP* you, I do what I WHOAAH-ant!”

Normally, you just read this type of post and either agree with it or not. My personal take is that reducing the punishment of a crime in order to make sure that we are able to properly defend ourselves from computer crime is ridiculous. There may be a seperate issue of whether or not the current punishment fits the crime, but that isn’t what this was about, nor do I understand the laws well enough to comment.

So far, Soooooo BUGTRAQ.

Then, mjr weighed in. It started out reasonable, comparing computer trespass to physical trespass. Concisely put:

Advanced societies have a sense of property. We should favor property owner’s rights to control their property, not the trespasser’s ability to go where they please.

In Springerspeak:

Stay away fr’m my BLEEPING woman! She ain’t yers, n’ i love ‘er!

At this point, you typically have a lot of yelling, some finger pointing, and finally the bouncers seperate today’s guests.

That’s when mjr comes back in wielding a folding chair, and while intending to take a swing at his combatant, instead hits some guy next to him. Let’s call him ‘The entire industry of penetration testers’.

What you’ll find is that engineers who understand engineering discipline find bug-hunting to be an utterly boring process; well-designed and implemented systems don’t need “pen testers” - they cross-check themselves.The only reason the industry is in the horrible condition it’s in today is because the vast majority of code that’s been fielded to date is crap. That will have to change. And when it does, “pen testers” will become peons in the quality assurance department. … Put differently: either way you slice it, pentesters aren’t worth a bucket of warm spit as far as I am concerned.

Who’s-it in the what-now?

Well-designed and implemented systems not only need penetration testers, I would assert that they are actually more likely to have been penetration tested. Why? Because if the person who owned the security process at an organization is savvy enough to incorporate security into requirements, design and implementation, they will absolutely know that they NEED to continue to have security be a part of testing. Our industry changes too fast. Engineers are always going to be pressed for time. Even if everyone had the time, mistakes happen. Mistakes that are increasingly more likely to be monetized by an attacker.

Final Thoughts

Relaxing the laws are not going to help us become a more secure society. Having security built into software and software development lifecycles will. Software engineers should all know how to design and build secure software. However, they will never be perfect. Penetration testers reduce the risk that an mistake made earlier in the process is found by someone interested in fixing the problem, not exploiting it. Take care of yourself, and each other.

daveg: good discussion in the comments

7 Comments

Radioactive

Thomas Ptacek | February 21st, 2006 | Filed Under: Defenses

I have a theory about avoiding speeding tickets. It’s simple and it’s easy to test and it’s worked reliably for me over the last 5 years. I used to get a lot of tickets, so pay attention:

Pull over before the lights come on.

You’re doing 85 down I-90 at 10:00PM. Blow past an underpass and see headlights pulling on to the road behind you. What you do now is, pull over. Before the blinky lights come on. Turn off your engine, turn the dome lights on, roll down the window, put your hands on the wheel.

You will now play out one of four scenarios:

1. It’s not actually a cop. You have no problem.
2. It’s a cop, but he keeps going. You have no problem.
3. It’s a cop, and he pulls over behind you. He walks up to your window and asks, “why did you pull over?”. You respond, “I saw you pull out behind me and realized I was going way too fast. I’m sorry.” He goes back to his car for the requisite 10 minutes, comes back, and says “I’m letting you off with a warning, but slow down!”. You have no problem.
4. It’s a cop, she pulls over, you do everything outlined in scenario 3, and you get a ticket anyways. This has never happened to me. Scenario 3 has happened to me a lot. But even if I did get a ticket, I wouldn’t have a hard time convincing myself that I was getting that ticket no matter what I did.

My explanation for this is that cars on the road obey the same laws as dogs do in the wild: when two dogs fight, and one loses, he rolls over and shows his belly and the dominance hierarchy is established and everyone goes away happy, or at least, breathing. And that’s the same thing you’re doing with a police officer by paying attention and pulling over before she has a chance to pull you over.

I do have a point.

Several months ago Matasano published some initial results testing iSCSI SAN technology. We got an advisory out with Network Appliance, but haven’t published much since. We have not been sitting on our hands. Matasano is currently averaging over 4 months from disclosure to public advisory: we don’t publish without vendor coordination. To put it in perspective: we had stuff queued up when the first iSCSI advisory came out. And NetApp iSCSI is the only advisory we’ve published so far!

Since then, in addition to testing iSCSI, we’ve had a chance to take a whack at iFCP. iFCP is one of the two Fiber Channel equivalents to iSCSI (the other is FCIP, and if you know why there are two of these, you know more than I do about SAN tech). One sentence refresher: SAN protocols like iFCP and iSCSI let your OS pretend to have a physical block-based disk drive attached, when really the disk commands are being proxied over the network.

iFCP was not much fun. Here’s why: from what we saw, against a market leading vendor, iFCP has basically no “built-in” security. Instead, iFCP wants to be run on a backchannel network, or through an IPSEC tunnel. In the environment we tested, there was no iFCP login for us to defeat. We could fuzz Fiber Channel commands or the iFCP framing, but, what’s the point? I could be wrong —- our iFCP engagement did not take place under conditions as favorable as our iSCSI work —- but access to iFCP seems like gameover.

It’s hard for me to argue that this is a bad thing. The lack of superficial (or worse, complicated) security mechanisms forces operators to confront the fact that SAN security requires network architecture support. And as a pentester in this engagement, I have an idea of how the cop might feel when I pull over preemptively —- she could write the ticket, but what’s the point? It won’t make her feel any better.

Some protocols and network services are just radioactive. Rationalizing their exposure to arbitrary network clients or attempting to mitigate vulnerabilities with countermeasures like “strong authentication” is playing to lose. The SAN protocols are an example. So are routing protocols. So is SNMP. Labeling individual vulnerabilities in these protocols without recognizing that they are fundamentally scary is like labeling a container full of plutonium with its atomic number, weight, density, and boiling point, but not having the big yellow “radioactive” pictogram on it.

So one of the things I liked about RSA was meeting Peter Lindstrom, and one of the things I’ve been meaning to discuss with Lindstrom is his industry request for a “materials safety data sheet” for software. And, what I think is, he’s right (and the comments about that stupid “Software Facts” label are a straw man response).

But we’re getting ahead of ourselves. In particular: both the MSDS and the “Software Facts” label try to be predictive of vulnerabilities. But I’ll argue that, at least to start with, my clients don’t need to be able to predict vulnerabilities, and any labeling practice is going to fail at that anyways. We need to know which protocols are radioactive and which ones are going to combust. And I think there’s a better metaphor to play on than either the MSDS or (gag) food labeling.

Here’s my SWAG.

1 Comment

RSA Wrap-up

Dave G. | February 20th, 2006 | Filed Under: Industry Punditry, Matasano

It has been awhile since I have spent any real time at RSA. It was RSA 2000, and, for me, it marked the launch of @stake. I would say the biggest change since then is the sheer number of vendors. That, and a noticable lack of ridiculousness at the vendor boothes (RSA 2000 had things like car giveaways, night vision goggles to win, free lockpicks…), but these are different times.

If I had gone to RSA to see the talks and what the vendors were up to, chances are I would have walked away disappointed. Not a lot of new and interesting announcements. But as an entrepreneur, it’s what happens in between the talks and the vendors hawking products that makes RSA so worthwhile. We sat down with a number of VCs, who always have an interesting take on the industry as a whole. General consensus was optimistic, with some concern over the sheer number of security companies. From an events perspective, here is a quick rundown (note that all 3 of us went to different events, so there was a lot going on:

1. Intrusic. Small. Lots of familiar faces (I think that might be a Boston thing).
2. Debix. Large. Bar scene type thing. Lots of good conversations going on.
3. Greylock. Large. Best networking to be had at RSA IMHO.
4. Trinity. Small. Finally met this characterthere.

It should be noted that I also got there late, thanks to a rather large blizzard that managed to cancel not one, but two of my flights. I would also like to thank all of the people that made the time to talk to us about what we are doing. We got a lot of great feedback and good advice.

No Comments

Today On This Old Vulnerability

Thomas Ptacek | February 17th, 2006 | Filed Under: This Old Vulnerability

Each week on This Old Vulnerability we try to bring you description of a software vulnerability of Significance. For example, last week’s inaugural episode described Loadmodule2, a cat-and-mouse classic in which 8lgm beat Sun’s IFS environment resetting countermeasure by simply creating two IFS variables. That’s a vulnerability we can file under “clever”.

On today’s episode, we bring you a vulnerability we can file under “sick”: the wu/bsd FTPD signal race.

FTP is a scary protocol. It allows users to upload and download files from remote servers. Non-credentialed Internet users can interact with an FTP server by logging in as “Anonymous”. FTP servers naturally take safeguards to limit what anonymous users can do. In 1997, the state of the art in FTP security countermeasures was to “downgrade” privileges from “root” to “nobody” and chroot the server to an anonymous FTP jail, in which “anonymous” has no privileges to write files.

Unfortunately, for no reason that remained valid in 1996, the FTP protocol introduces needlessly complex connection handling drama. The details we’ll save for a different show (“this old protocol”?), but, suffice it to say, a server managing a single anonymous FTP login has to manage many individual connections. Not only that, but, because FTP is a protocol designed before the select() system call, it uses TCP URG to deliver command-and-control traffic.

Here’s what you need to know about TCP URG to understand the FTP signal race: an application that cares about URG tells the kernel to deliver a signal (SIGURG) when an URG segment is received.

(Here’s what else you need to know about TCP URG in any other situation: nothing).

Here’s what you need to know about signals to understand the FTP signal race: in normal BSD socket code, the receipt of a signal causes a process to perform the moral equivalent of spawning a new temporary thread of control. In FTPD, when SIGURG was received, that thread’s job was to longjump the server back to the command loop to process the new incoming command.

This wouldn’t be a problem except that FTPD also used signals to gracefully handle connection loss. If you abruptly closed one of your FTP connections, the server would get SIGPIPE. It would handle SIGPIPE by performing a logout operation on your behalf.

Here’s what you need to know about FTPD’s logout routine to understand the FTP signal race: it restored the server’s effective UID back to root.

Here’s what happened when a certain Mac FTP client terminated a download by both closing a connection and sending the “ABORT” FTP command to the server: it got silently logged in as root.

More specifically:

1. Closing the data connection generated caused the server to receive SIGPIPE.
2. SIGPIPE caused the server to try to log the client out, restoring the UID to 0 to allow it to clean up. But, just before the server process could exit(),
3. The “ABORT” command, in a TCP URG segment, arrived at the network stack, generating a SIGURG that bounced FTPD out of the SIGPIPE signal handler and into the SIGURG signal handler, which
4. handled the ABORT command by restoring the server process to the FTP command loop to handle the next command.

This was a fun vulnerability check to write (I wrote the Ballista check for it). It worked everywhere, and FTP banners were a poor predictor of it. It’s a race condition, so it takes many (many) attempts to get it right. But you could exploit it with a GUI FTP client just by clicking the “cancel” button a bunch of times.

Here’s more paranoia about Unix signal handling, much of which applies to concurrency in general.

Brought to you in part by a grant from the Jon M. Olin Foundation. Major underwriting for Matasano Chargen is provided by Archer Daniel Midland Company. ADM: Feeding A Hungry World. And of course, readers like you!

1 Comment

Bad Timing

Dave G. | February 10th, 2006 | Filed Under: Disclosure

We have another report of approximately 10 vulnerabilities in a single vendor’s product. This time Secunia pummels Lotus Notes. I think there is more credibility with these vulnerabilities as Lotus Notes is a business application that has an attack surface of thousands of employees. Six out of ten buffer overflows, the remaining were cross site scripting (did I say credible earlier?!). Worst part is, released on a Friday afternoon. It is going to be a fun weekend if you are a Lotus Notes Administrator!

And next week we can expect a slew of advisories and announcements, thanks to RSA and this Microsoft announcement. From the announcement:

Microsoft warned users Thursday that they needed to set aside time on Tuesday, Feb. 14, to deploy seven security bulletins, the most the Redmond, Wash.-based developer has released since October 2005.

I wonder how many admins will have to work late on Valentines Day patching various systems. Bad week to be in security and a relationship!

No Comments

IPv6 Will Mark It Hard For Worms To Propagate. On Abilene.

Thomas Ptacek | February 10th, 2006 | Filed Under: Bitching About Protocols, Malware, New Findings

From Schneier (his summary: “Nice”), this paper, an analysis of how worms can spread even given sparse IPv6 addressing (the address space is so large that it suppresses brute-force scanning). The Cliff’s Notes:

• Worms will use Neighbor Discovery (ARP)
• or they’ll use routing protocols
• or they’ll scan using the embedded MAC address in the IPv6 address
• or or or multicast!
• and don’t forget zone transfers
• and sniffing!

I don’t mean to be glib. It’s a good paper. I am not as smart as Bellovin. But this is not my perception of what the state of the art in worm design is. Two high-level comments:

1. The trend in “smart” worms —- and a worm that sniffed or tapped routing protocols to locate prey qualifies as “smart” relative to Witty —- will be towards “topology awareness”, a dumb word for worms that take advantage of IM Buddy Lists or trust relationships. This has been extremely effective for mail viruses. These worms rely on application layer location services, not raw addresses. The long and the short of it: building an OSPF adjacency seems like a lot of effort to go through in a programming environment that involves assembly instructions written in hexidecimal with no NUL bytes. Hyperbole, I know, but the sentiment is valid.
2. Worms use random probing not just to locate targets, but to locate targets without competing with other instances of the same worm. This is what enables them to spread quickly without using explicit coordination. Look at it this way: simply by observing biases from random number generation seeding, Paxson’s team was able to make a credible claim at identifying “patient zero” for Witty. What does “seeding” based on zone transfers and routing tables do to this? Worms spread by mass probing, generating orders of magnitude more candidates than would be obtained even from a dump of a flat OSPF network. Won’t the worms just stomp all over each other? Not to mention the fact that the overwhelming majority of infected hosts to date have not run routing protocols.

The Ptacekometer Reading for IPv6 Worm Propagation: we’ll never have IPv6 anyways so it’s somewhat irrelevant, but studying how to randomly scan a 128 bit address space IS an interesting problem, but relying on OS artifacts to get around the size of the address space seems like cheating.

The real reason I’m writing about this, though, is to ask Peter Lindstrom a question:

The sole purpose of this paper is to educate people on how to write better malware. Not close vulnerabilities, mind you, because it doesn’t document any closeable vulnerabilities. It just tells worm authors how to write more virulent worms.

Your response?

PS: IPv6 does not make multicast any less untenable.

No Comments