Research

Really excellent article by Kim Zetter on the Wired Threat Level site in regards to “PIN cracking”, and some of the techniques being employed to gather large amounts of consumer financial data. I know Rich referenced this post earlier today, but since I already wrote about it and have a few other points I think should be mentioned, hopefully you will not mind the duplicated reference. Before I delve into some of the technical points, I want to say that I am not certain if the author desired a little sensationalism to raise interest, or if the security practitioners interviewed were not 100% straight with the author, or if there was an attempt to disguise deployment mistakes by hyping the skills of the attacker, but the headline and some of the contents are misleading. The attackers are not ‘cracking’ the ATM PINs, as the encryption is not what is being attacked here. Rather they are ‘scraping’ the memory of the security devices, looking for unencrypted data or the encryption keys. In this case by grabbing the data when it is unencrypted and vulnerable (in a cryptographic sense if not the physical one) within the Hardware Security Device/Module/Unit for electronic funds transfers, hackers are in essence sniffing unencrypted data. The attack is not that sophisticated, nor is it new, as various eavesdropping methods have been employed for years, but that does not mean that it is easy. Common tactics include altering the device’s operating system or ‘attaching’ to the hardware bus to access keys and passwords stored in memory, thus bypassing intended interfaces and protections. Some devices of this type are even constructed in such a way that physical tampering will destroy the machine and make it apparent someone was attempting to monitor information. Some use obfuscation and memory management technologies to thwart these attacks. Any of these requires a great deal of study and most likely trial and error to perfect. Unless of course you leave the HSM interface wide open, and your devices were infected with malware, and hackers had plenty of time to scan memory locations to find what they wanted. I am going to maintain my statement that, until proven otherwise, this is exactly what was going on with the Heartland breach. For the attack to have compromised as many accounts as they did without penetrating the Heartland facility would require this kind of compromise. It implies that the attackers have access to the HSM, most likely exploiting negligent security of the command and control interface, and infecting the OS with malicious code. Breaking into the hardware or breaking the crypto would have been a huge undertaking, requiring specialized skills and access. Part of the reason for the security speed-bump post was to illustrate that any type of security measure should be considered a hindrance; with enough time, skill and access, the security measure can be broken. Enough hindrances in place can provide good security. Way back when in my security career, we used to perform hindrance surveys of our systems to propose how we might break our own systems, under what circumstances this could be done, and what skills and tools would be required. Breaking into an HSM and scraping memory is a separate and distinct skill from cracking encryption (keys), and different from writing SQL and malware injection code. Each attack has a cost in time and skill required. If you had to employ all of them, it would be very difficult for a team of people to accomplish. Some of the breaches, both public as well as undisclosed breaches I am aware of, have involved exploitation of sloppy deployments, as well as the other basic exploitation techniques. While I agree with Rich’s point that our financial systems are under a coordinated multi-faceted attack, the attackers had unwitting help. Criminals are only slightly less lazy than system administrators. Security people like to talk about thinking like a criminal as a precursor to understanding security, and we pay a lot of lip service to it, but it is really true. We are getting to watch as hackers work through the options, from least difficult to more difficult, over time. Guessing passwords, phishing, and sniffing unencrypted networks are long since pase, but few are actively attacking the crypto systems as they are usually the strongest link in the chain. I know it sounds really obvious to say that attackers are looking at easy targets, but that is too simplistic. Take a few minutes to think about the problem: if your boss paid you to break into a company’s systems, how would you go about it? How would you do it without being detected? When you actually try to do it, the reality of the situation becomes apparent, and you avoid things that are really freakin’ hard and find one or two easy things instead. You avoid things that are easily detectable and being watched. You learn how to leverage what you’re given and figure out what you can get, given your capabilities. When you go through this exercise, you start to see the natural progression of what an attacker would do, and you often see trends which indicate what an attacker will try and why. Despite the hype, it’s a really good article and worth your time. Share:

This is a great day for security researchers, and a bad day for anyone with a bank account. First up is the release of the 2009 Verizon Data Breach Investigations Report. This is now officially my favorite breach metrics source, and it’s chock full of incredibly valuable information. I love the report because it’s not based on bullshit surveys, but on real incident investigations. The results are slowly spreading throughout the blogosphere, and we won’t copy them all here, but a few highlights: Verizon’s team alone investigated cases that resulted in the loss of 285 million records. That’s just them, never mind all the other incident response teams. Most organizations do a crap job with security- this is backed up with a series of metrics on which security controls are in place and how incidents are discovered. Essentially no organizations really complied with all the PCI requirements- but most get certified anyway. Liquidmatrix has a solid summary of highlights, and I don’t want to repeat their work. As they say, Read pages 46-49 of the report and do what it says. Seriously. It’s the advice that I would give if you were paying me to be your CISO. And we’ll add some of our own advice soon. Next is an article on organized cybercrime by Brian Krebs THAT YOU MUST GO READ NOW. (I realize it might seem like we have a love affair with Brian or something, but he’s not nearly my type). Brian digs beyond the report, and his investigative journalism shows what many of us believe to be true- there is a concerted attack on our financial system that is sophisticated and organized, and based out of Eastern Europe. I talked with Brain and he told me, You know all those breaches last year? Most of them are a handful of groups. Here are a couple great tidbits from the article: For example, a single organized criminal group based in Eastern Europe is believed to have hacked Web sites and databases belonging to hundreds of banks, payment processors, prepaid card vendors and retailers over the last year. Most of the activity from this group occurred in the first five months of 2008. But some of that activity persisted throughout the year at specific targets, according to experts who helped law enforcement officials respond to the attacks, but asked not to be identified because they are not authorized to speak on the record. … One hacking group, which security experts say is based in Russia, attacked and infiltrated more than 300 companies – mainly financial institutions – in the United States and elsewhere, using a sophisticated Web-based exploitation service that the hackers accessed remotely. In an 18-page alert published to retail and banking partners in November, VISA described this hacker service in intricate detail, listing the names of the Web sites and malicious software used in the attack, as well as the Internet addresses of dozens of sites that were used to offload stolen data. … Steve Santorelli, director of investigations at Team Cymru, a small group of researchers who work to discover who is behind Internet crime, said the hackers behind the Heartland breach and the other break-ins mentioned in this story appear to have been aware of one another and unofficially divided up targets. “There seem, on the face of anecdotal observations, to be at least two main groups behind many of the major database compromises of recent years,” Santorelli said. “Both groups appear to be giving each other a wide berth to not step on each others’ toes.” Keep in mind that this isn’t the same old news. We’re not talking about the usual increase in attacks, but a sophistication and organizational level that developed materially in 2007-2008. To top it all off, we have this article over at Wired on PIN cracking. This one also ties in to the Verizon report. Another quote: “We’re seeing entirely new attacks that a year ago were thought to be only academically possible,” says Sartin. Verizon Business released a report Wednesday that examines trends in security breaches. “What we see now is people going right to the source … and stealing the encrypted PIN blocks and using complex ways to un-encrypt the PIN blocks.” If you read more deeply, you learn that the bad guys haven’t developed some quantum crypto, but are taking advantage of weak points in the system where the data is unencrypted, even if only in memory. Really fascinating stuff, and I love that we’re getting real information on real breaches. Share:

We spend a lot of time talking about security metrics over here, and I’ve been pretty critical of both overly-broad initiatives that don’t help people get their day to day jobs done, and “fluffy” models that try to put hard numbers on risks/threats and such. Well, it looks like it’s time for me to put up or shut up. I’m pleased to announce our latest metrics project, which we’re currently calling Project Quant. (Yes we need a better name). We were approached by Jeff Jones at Microsoft to help build an independent model to measure the costs and effectiveness of patch management. This will be a hard metrics model, focused on measuring the operational processes associated with patch management. The goal is to provide IT organizations a tool they can use to measure how effective they are, and track that over time. I’m excited about this project for two main reasons: We get to focus on hard, practical metrics people can use to improve operations. We are following a “radical” version of our Totally Transparent Research process to ensure objectivity. We’ve set up a dedicated landing area for the project at http://securosis.com/projectquant where we will be posting all the materials. Here are the bits you might care about: We are soliciting as much participation in the project as possible- including competing vendors, end users of all sizes, consultants, whoever. The project has a deadline of late June, so this won’t drag out indefinitely. The first version may not be perfect, but come the end of June there will be a first version. We really need you to get involved. We’ll be asking for survey participants, reviewers, and just plain ‘ol grumpy commenters to keep us honest, and help produce a useful result. The results will be released under a Creative Commons license in an open format. We have the first two posts up at the landing site. The first, Introducing Project Quant, provides an overview of the project and the research process. The second, Project Quant: Goals delves into the project goals in more detail. This is a pretty huge project, even though it’s laser focused on one single operational area. Hopefully you like the idea, and are interested in participating. Share:

Things are so crazy this week, getting ready for RSA, that I nearly forgot we record this little podcast thing every week. Sure, I’ve only been doing it every week for over a year, but you’d think I’d learn to remember. This week we start by reviewing all the happenings at RSA, before talking about the cable cuts in the Bay Area and the Twitter worm. Martin and I will be doing our best to push out shorter daily shows (usually interviews) every day at RSA, and these tend to be some of our more popular episodes. The Network Security Podcast, Episode 146. Share:

Oracle released the April 2009 Critical Patch Update; a couple serious issues are addressed with the database, and a couple more that concern web application developers. For the database server, there are two vulnerabilities that can be remotely exploited without user credentials. As is typical, some of information that would help provide enough understanding or insight to devise a workaround is absent, but a couple are serious enough that you really do need to patch, and I will forgo a zombie DBA patching rant here. If you are an Oracle 9.2 user, and there are a lot of you out there still, there is a vulnerability with the resource manager. Basically, any user with create session privileges, and as all users are required to have this in order to connect to the database, it is only going to take one “Scott/Tiger”, default account or brute forced user account to exercise the bug and take control of the resource manager. Very few details are being published, and the CVSS “Base Score” system is misleading at best, but a score of 9 indicates a takeover of the resource manager, which is often used to enforce polices to stop DoS and other security/continuity policies, and possibly leveraged into other serious attacks I am not clever enough to come up with in my sleep deprived state. If this can be implemented by any valid user, it is likely a hacker will locate one and take advantage. The second serious issue, referenced in CVE-2009-0985, is with the IMP_FULL_DATABASE procedure created by catexp.sql, which runs automatically when you run catalog.sql after the database installation. This means you probably have this functionality and role installed, and have a database import tool that runs under admin privileges- which a hacker can use on any schema. Attack scenarios over and above a straight DoS may not be obvious, but this would be pretty handy for surreptitious alteration and insertion, and the hacker would be able to then exercise this imported database. As I have mentioned in previous Oracle CPU posts, these packages tend to be built with the same set of assumptions and coding behaviors, so I would not be surprised if we discover that EMP_DATABASE_FULL and EXECUTE_CATALOG_ROLE have similar exploits, but this is conjecture on my part. This is serious enough that you need to patch ASAP! And if you have not already done so, you’ll want to review separation of user responsibilities across admin roles as well. I know it is a pain in the @$$ for smaller firms, but it avoids cascaded privileges in the event of a breach/hack. Finally, CVE-2009-1006 for JRockit and CVE-2009-1012 for the WebLogic Server are in response to complete compromises (Base Score 10) to the system, and should be considered emergency patch items if you are using either product/platform. If we get enough information to provide any type of WAF signature I will, but it will be faster and safer to download and patch. Red Database Security has been covering many of the details on these attacks, and there are some additional comments on the Tech Target site as well. Share: