“PIN Crackers” and Data Security

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:

Read Post

Our Financial System is Under a Coordinated, Sophisticated Attack

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:

Read Post

Announcing Project Quant: New Security Metrics Project (with Microsoft)

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 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:

Read Post

The Network Security Podcast, Episode 146

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:

Read Post

Oracle CPU for April 2009

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:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.