The importance of knowing exactly how Snowden breached security by attacking trust and an open invitation to correct us

To date little real information exists publicly to explain how Edward Snowden stole secrets from one of the world’s most advanced and sophisticated intelligence organizations. Reports on “How Snowden Did It” detail little more than the obvious: he breached the National Security Agency (NSA). As experts in securing and protecting the trust established by keys and certificates, Venafi understands how Snowden accomplished this breach. To develop this understanding, Venafi security analysts have methodically analyzed public information for over 3 months, connected pieces of the puzzle based on our knowledge of attacks and vulnerability in the Global 2000, and requested peer review and feedback from industry experts.

Ironically, the blueprint and methods for Snowden’s attack were well known to the NSA. The NSA had to look no further than the US’s own Stuxnet attack to understand their vulnerability. Clearly, Edward Snowden understood this. Here we describe how Venafi solved this puzzle and explain why Snowden’s actions affect not only the NSA but your organization.

If we’re wrong, we invite the NSA and Edward Snowden to correct us. NSA Director General Keith Alexander wants to promote information sharing, and now is the perfect opportunity. General Alexander stated “At the end of the day it’s about people and trust” and we agree. The attacks on trust that breached the NSA are vulnerabilities in every business and government. Sharing how the breach was researched and executed is important to help every business protect its valuable intellectual property, customer data, and reputation. We believe both the NSA and Edward Snowden would agree that helping businesses and governments improve their security is a worthy cause.

Limited (read that as no) information to date has been shared publicly

Neither investigative reports nor the NSA leadership’s public statements have explained the methods Snowden used to breach the NSA’s security.

Here is what we know about Snowden’s work environment and the tools he had at his disposal:

1. Valid access—As a contractor, Snowden was issued a valid Common Access Card (CAC). This smart card had preloaded cryptographic keys and digital certificates that authenticated his identity and provided basic trusted status and access to the information and systems he was authorized to access.
2. SSH Keys—As a systems administrator, Snowden used Secure Shell (SSH) keys to authenticate and manage systems as a part of his everyday job. Prior to working for the NSA, Snowden is known to have tested the limits of his administrator privileges to gain unauthorized access to classified information while at his CIA post in Geneva, Switzerland.
3. Limited computing resources—Like many external attackers, Snowden didn’t have a bay of servers, top-end Macintosh computers, or even a Windows laptop hanging off the NSA network, which is referred to as NSAnet. It’s been reported that Snowden had basic terminal or thin-client access to the NSAnet. He had much the same view an attacker might have after a successful initial intrusion or reconnaissance mission.

Piecing together the puzzle of how Snowden attacked trust to breach the NSA

Once we understood Snowden’s tools and network environment, we reviewed the information that had been reported about Snowden and identified the critical elements that would help us piece together the full story of how Snowden attacked the trust established by cryptographic keys and digital certificates to breach the NSA:

• Snowden fabricated digital keys—In testimony to the House Permanent Select Committee on Intelligence, General Alexander explained that Snowden “fabricated digital keys” to enable his attack. “Fabricating keys” could describe creating his own digital certificates or other types of cryptographic keys such as those used for SSH access.
• The role of keys and certificates—In the same testimony to the House Permanent Select Committee on Intelligence, Congresswoman Terri Sewell asked General Alexander to describe the role and use of digital certificates in the NSA. Because this line of questioning follows the classified briefing Alexander presented, it is highly likely that the use of certificates was discussed in the classified briefing. In the context of “fabrication” of certificates, self-signed certificates are created and issued by their maker. Self-signed certificates are common part of the cybercriminals toolkit to enable the exfiltration of data.
• Branching out—Snowden reportedly obtained usernames and passwords from dozens of colleagues. This afforded him the opportunity to significantly extend his reach and time to gather data. When logging in with his colleagues credentials, he would also have access to their SSH keys and digital certificates. And he could also then take “fabricated” SSH keys and establish them as trusted. In all cases, and unlike passwords that are frequently required to be changed, SSH keys and digital certificates live much, much longer lives.
• Snowden’s perfect security—Finally, Snowden has boasted that encryption provides the perfect security system. In an online Question and Answer session with The Guardian, Snowden explained:
  “Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on.” Snowden also claims to have encrypted his stolen data for distribution. Therefore, his use of encryption, which is enabled by SSH keys and self-signed certificates, is that much more likely and supports General Alexander’s statement that Snowden fabricated keys. Cisco, Mandiant, and other experts have long established the use of encrypted and authenticated sessions as a common cybercriminal tool to exfiltrate undetecetd. In fact, as far back as 10 years ago, Snowden was inquiring on message boards about methods to create anonymous and obfuscated connections, and even mentioned SSH as a common method.

General Alexander summed up well Snowden’s ability to attack: “Snowden betrayed the trust and confidence we had in him. This was an individual with top secret clearance whose duty it was to administer these networks. He betrayed that confidence and stole some of our secrets.” Unfortunately it seems that like so many organizations Venafi has worked with, the NSA had no awareness and no ability to respond to these attacks on keys and certificates.

Venafi Exposes How Snowden Did It: Three Important Steps on the Kill Chain

Using military Kill Chain analysis, which Lockheed Martin and others have made popular in IT security, we can reveal how Snowden executed his theft of data from the NSA:

1. Researching the target—Snowden used his valid access (such as CAC with keys and certificates and SSH keys for system administration) to determine what information was available and where it was stored—even if he didn’t immediately have full access to that information.
2. Initial intrusion—Snowden gained unauthorized access to other administrative SSH keys and inserted his own to gain full, trusted status to information he was not authorized to access. Using usernames and passwords from colleagues could afford him more opportunities to take keys or insert his own as trusted. Having “root” or equivalent administrative status gave Snowden total access to all data. Just like an advanced and persistent attacker, he took care not to set off alarms and covered his tracks.
3. Exfiltration—To get data off the NSAnet, he could not simply save it to a flash drive. Instead data needed to be moved across networks and under the radar to evade detection. Just like common cybercriminals, Snowden used Command and Control servers to receive encrypted data sessions. These sessions were authenticated with self-signed certificates.

> View the Breaching the NSA Infographic

Everything’s already been seen in the wild

You might think that only advanced cyber teams in the NSA have the knowledge and skill to fabricate self-signed certificates or use unauthorized SSH keys to exfiltrate data. However, all of these attacks have been reported publicly in the wild. Cyber-criminals have used them to launch successful attacks and will continue to use them. In fact, Snowden was in many ways just following the methods and means the NSA had already used successfully.

In one of the first and most powerful demonstration of what attacking the trust established by keys and certificates can accomplish, the NSA is reported to have helped carry out the Stuxnet attacks on Iranian nuclear facilities. Using stolen digital certificates from unknowing Taiwanese companies, the architects of Stuxnet, identified by Snowden to include the NSA, were able to launch the Stuxnet attacks with trusted status. These and other attacks provided Snowden a blueprint for attack: compromise the trust established by keys and digital certificates.

More specifically to the NSA Breach, attackers used SSH key stealing Trojans to gain unauthorized access to SSH keys and have unfettered access to the FreeBSD source code for more than a month. As a system administrator, Snowden didn’t need to use Trojans to steal or create his own SSH keys.

Mandiant reported that the APT1 attackers generated self-signed certificates to enable their command and control servers to receive cloaked, encrypted stolen data. These certificates went completely undetected as being rogue—purporting to be from IBM or Google or for use with “webserver” or “alpha server.” Freely available tools such as OpenSSL would allow Snowden to create self-signed certificates on demand.

The gap that’s allowed cyber-criminals to breach these and other organizations is why Forrester Consulting described the situation in simple, blunt terms: “Basically, the enterprise is a sitting duck.”

Every enterprise is an NSA breach waiting to happen

Just like the NSA, most enterprises have little to no awareness of the keys and certificates used to create trust—the authentication, integrity, and privacy on which almost all IT security is built. In fact, the Ponemon Institute surveyed 2,300 large organizations and reported that these organizations have, on average, more than 17,000 keys and certificates in their core infrastructure alone. This number doesn’t include mobile apps or the SSH keys that administrators use to access systems. Ponemon also reported that 51% of organizations don’t know where and how these keys and certificates are used. And industry experts agree, this number is grossly underreported.

All these facts clearly applied to the NSA before Snowden breached the agency’s security and stole data. The NSA had no awareness of the keys and certificates in use, no ability to detect anomalies, and no ability to respond to an attack. Because of these deficiencies, General Alexander believes strongly that the NSA must use automated machine intelligence to improve its ability to detect and respond to threats:

“What we’re in the process of doing—not fast enough—is reducing our system administrators by about 90 percent. What we’ve done is put people in the loop of transferring data, securing networks and doing things that machines are probably better at doing.”

The NSA is already setting out on the path Gartner expects most organizations to reach by 2020 or sooner: reallocating spending to focus on detection and remediation of security issues using fast, automated security systems. This trend will create a tectonic shift in IT security, putting almost two-thirds of IT security’s budget into detection and remediation, up from less than 10 percent today.

But, the game won’t be over if these detection and remediation efforts don’t include securing and protecting the keys and certificates that provide the foundation of trust in the modern world. Therefore, the NSA would be well advised to take Forrester Consulting’s advice:

“Advanced threat detection provides an important layer of protection but is not a substitute for securing keys and certificates that can provide an attacker trusted status that evades detection.”

Of course, Edward Snowden knew this. Unfortunately, the NSA did not.

Want to learn more about this problem and the strategies that can help an organization secure and protect its data?

• Watch The Snowden Breach: Attack Steps & Prevention Webinar
• View the Breaching the NSA Infographic
• Learn How to Protect Your Organization From Snowden-style Attacks

Should the NSA be reformed? Fierce debate rages

“Jeff Hudson, CEO at Venafi, says Snowden likely elevated his privileges by generating SSH keys to use them to get access to other servers. ‘He then used that SSH key to get access to another,’ said Hudson. SSH keys allow for authentication and encrypted file transfer, but tracking SSH keys in use can be a problem. ‘Why doesn’t the NSA just come out and say that happened?’”

Read More

How Did Snowden Do It?

“…Snowden fabricated SSH keys and self-signed digital certificates to access and ultimately steal the NSA documents. And the company — which provides security for crypto keys and digital certs — is challenging the NSA and Snowden to prove its conclusion wrong. Snowden succeeded in stealing the documents, according to Venafi, because the NSA was unable to detect Snowden’s unauthorized access to, and ultimate exfiltration of, the information.”

Read More

How Snowden Breached the NSA from the Inside

“This is the crux of the attack: as an administrator Snowden was able to fabricate digital certificates and cryptographic keys; but the NSA had no ability to detect the forgeries. ‘The NSA had no awareness of the keys and certificates in use, no ability to detect anomalies, and no ability to respond to an attack,’ writes Venafi CEO Jeff Hudson.”

Read More

Infographic: How Snowden Breached the NSA

“In this infographic, Venafi breaks open how Edward Snowden breached the NSA. Venafi shared this information and challenges the NSA or Edward Snowden to provide more information so that enterprises around the world can secure their systems and valuable data.”

Read More

Nearly everyone understands the need to use data encryption to protect data both in transit and at rest, but I have found that there is some confusion about the strength of the key that is used to encrypt that data. Some of this confusion is in part due to the fact that we have been warned for so long that certain keys and certificates are not strong enough, yet organizations that issue these certificates continue to allow us to acquire these weak encryption assets.

This practice reminds me of the proverb of the boy who cried wolf. For nearly four years, the U.S. National Institute of Standards and Technology (NIST) has been telling us that we should be using 2048-bit keys, but we have collectively ignored those warnings. Now that the requirement to use 2048-bit certificates is upon us, many are decrying the fact that this requirement is being foisted upon the industry without much warning. These people are forgetting that we have grown complacent with the constant warning cries—much like the people who ignored the boy crying wolf. Now that the danger is upon us, we are caught unaware and unprepared.

What’s the big deal anyway? Hackers may be able to use the increasing computational power available—either on their physical hardware or through renting cloud computing hours—to overcome the encryption strength of algorithms and key sizes that were once deemed sufficient. A few years ago, a “brute force” attack that cracked an encryption algorithm was unthinkable, but such an attack is fast approaching the horizon of reality. In a brute force attack, a machine systematically tries all possible encryption combinations in an attempt to crack open the data. To understand how a simple brute attack works, think of an old-fashioned, three-digit briefcase lock. If you wanted to, you could try rotating the wheels in a systematic fashion until you stumbled across the right combination to open the lock. You may discover the right combination of digits on the first try, or the hundredth, or the last possible combination, but you will discover the combination sooner or later.

According to Moore’s Law, computational power doubles roughly every 18-24 months. This means that a key strength that was adequate a few years ago is rapidly reaching obsolescence at an ever increasing rate. And if quantum computing evolves and makes its way to the masses, encryption algorithms will also need to evolve to provide the strength to resist even more powerful attacks. Even encryption techniques that we feel are adequate today may be rendered useless if quantum computing continues to evolve and makes its way to the masses. Therefore, correcting a problem today—such as the move from 1024 to 2048-bit encryption—will not ensure that you will never have to do this again.

The Certificate Authority/Browser Forum (CA/B Forum) seems to have sounded the death knell for the 1024-bit certificate. The forum has instructed Certificate Authorities (CAs) to support only 2048-bit certificates and larger by the end of 2013. Responding to this requirement, many CAs stated that they would revoke all active certificates that are below 2048 bits on October 1, 2013. Other CAs have been a bit more gracious in not overtly revoking them on that day, but all have stood by the CA/B forum’s edict to require 2048-bit certificates by 1/1/2014. See the blog post titled “Gone in 60 Months” which you can read if you want additional information on this topic.

What is the result of this requirement? In short, the most visible action may be that individual Internet browsers will begin to disallow the use of certificates that are less than 2048 bits. For example, Mozilla provided an implementation timeline of December 31, 2013. “Soon after this date [December 31, 2013], Mozilla will disable the SSL and Code Signing trust bits for root certificates with RSA key sizes smaller than 2048 bits.[CA:MD5and1024]” And on September 24, 2013, Google Chrome’s team stated in a submission to the CA/B Forum that “in early 2014, Chrome will begin warning users who attempt to access sites with certificates issued by publicly-trusted CAs, that meet the Baseline Requirements’ effective date, and with key sizes smaller than those specified in Appendix A [that is, less than 2048 bits].”[Upcoming changes to Google Chrome's certificate handling].

“What effect will this new requirement have on my organization?” is a question I have fielded with ever-increasing frequency. Most people ask this question with a sense of confidence, clearly thinking that there will be little or no impact. Unfortunately my experience and research have shown that this will not be the case. Even just a cursory review of some of the most common banking, retail, airline, software providers, and even government sites will yield a plethora of 1024-bit certificates.

This problem becomes even more difficult to tackle because organizations incorrectly assume that they can rely on their internal and external CAs to help them identify all their weak certificates. If the only certificates in use were those generated by a CA, then this would be a reasonable solution. However, almost any software application that we install and most hardware devices on which we rely have certificates, and a huge portion of these certificates are 1024 bits. These certificates are found in email systems, virtualization platforms, routers and switches, printers, databases, telecom equipment, and almost all other systems and devices we rely upon in our daily operations. I’m certainly not trying to be an alarmist and say that the world will come to a screeching halt on 1/1/2014 ala Y2K. There is a real possibility, however, that users may have a particularly bad experience when they access websites to transact business and they see browser warnings. Perhaps it will be the inability of network administrators may be unable to log in remotely and manage the network virtualization infrastructure or even perform simple tasks such as adjusting wireless access points.

The first step in remediating this issue is really quite simple: we must create a comprehensive inventory of all certificates on all of our devices. The second step is also relatively easy: we must continuously monitor the entire network to ensure that “weak” certificates are not introduced into the environment as new applications come online and new devices are installed. The third step is a bit more involved: we must move quickly to replace all weak certificates identified in the first step above. When more weak certificates are discovered on the network during continuous monitoring (the second step above) they must be replaced immediately. It becomes more challenging when these certificates are found on hardware devices such as printers and telecom equipment, yet no weak certificate or key should be ignored. Only with constant vigilance, until the industry from top to bottom fully complies with the requirement to use 2048 bit certificates, will we be able to eradicate these weak keys and certificates.

Snowden Used Fabricated SSH Keys and Self-Signed Certificates to Hack the NSA

“According to Jeff Hudson, Venafi’s CEO, experts have found evidence that Snowden used fabricated SSH keys and self-signed certificates. These elements, combined with the NSA’s inability to detect their presence and use, are what ultimately led to Snowden having access to classified information.”

Read More

Snowden Borrowed from APT Playbook In NSA Hack

“To get data out of the NSA, Snowden used another common trick of APT-style attackers: using self-signed certificates again to encrypt the sensitive data and sending it out to command and control (C&C) servers that received and stored the encrypted data sessions.”

Read More

NSA Spying could prove costly to Internet companies

“‘Absolutely, our business is growing very rapidly,’ said Jeff Hudson, CEO of Venafi, a Utah security company with an office in Palo Alto, Calif. Referring to the repeated revelations about NSA spying, he added, ‘People are starting to wake up because this keeps happening over and over again.’”

Read More

Mobile. It’s the new normal. Never in the history of the world has a technology changed the way we work, live, and play in such a short period of time.

Think back 20 years. In 1993, we faxed important documents, checked answering machines, paid bills with paper checks, dialed 411 to find a number we needed, tuned into the local TV news at 6:20 p.m. to get the weather forecast, and took our roll of film to the local pharmacy to be developed. And astonishingly enough, back in my day growing up near Boston, we even called each other on landline phones to talk about the great deal we got that day on the new Nirvana “Nevermind” CD at Strawberries (sadly, a now long-defunct local music and cassette tape retailer).

Today, we can complete all these tasks (and much, MUCH more) on our smartphones and tablets. And we can perform all these tasks without uttering a single word.

This explosion of mobile technology makes us more productive than ever, yet conversely, keeps cyber-criminals very busy. We find ourselves in a “Wild West” period for mobile technology: opportunity abounds amongst danger at every turn. It’s estimated that by the end of 2013, nearly 90,000 new strains of mobile malware will have been released, and that figure will quadruple to over 403,000 new strains by the end of 2014.  Clearly, the convenience of mobile technology comes complete with an unprecedented, exploding new threat surface, which must be secured and protected.

Over the last decade, a multi-billion dollar market has emerged around mobile security. The mobile security market is expected to total approximately $1.88 billion by the end of 2013 and to grow to $2.9 billion by 2017. Nearly all, major enterprise security solution vendors provide products and services that address threats to mobile communications, productivity, and commerce.

Among these solutions, Mobile Device Management (MDM) has emerged as a “must-have” for many organizations. MDM vendors promote easy-to-implement solutions, which secure mobility without interfering with users’ experience. Most solutions, such as those from Citrix and Zenprise, offer some type of “top 10 must-haves” for secure enterprise mobility.

In an effort to create a more secure mobile enterprise, MDM solutions integrate with mobile certificate authorities (CAs), simplifying the process of requesting and receiving certificates to secure mobile communications. Today, most companies issue multiple certificates to authenticate users, devices, applications, and virtual private networks (VPNs) to the corporate network.

Cyber-attackers exploit weak certificates to exist in mobile environments

The use of mobile certificates is growing, and the attack surface is growing along with it. Without a good understanding of your legitimate mobile certificate inventory, you allow glaring weaknesses to exist in your mobile environment, including orphaned certificates, fraudulent certificates, and weak-crypto certificates. Cyber-attackers can easily detect and exploit these weaknesses.

Mobile and user certificates must be secured and protected as aggressively as any other part of the infrastructure. At a high-level, to effectively secure and protect mobile trust, enterprises need to:

• Prevent mobile certificates from being misused
• Detect mobile certificate anomalies
• Respond with immediate remediation when a threat is detected

Securing and Protecting Mobile Certificate = “Mobile Trust”

Take the common case of a user losing a smartphone: The resolution policy is typically to remotely wipe the smartphone via the MDM and issue a new one. However, a remote wipe alone doesn’t guarantee that your organization is safe from attack. All certificates on that lost smartphone can be copied and manipulated. And if the certificates associated with that user are not immediately revoked, you have a hidden vulnerability. Multiply the number of employees by the average number of devices and certificates each employee has, and you can see how an organization’s risk can spiral out of control. Having a “kill switch” not only for the device but also for ALL certificates ON the device is paramount to success.

Adding the security and protection of mobile certificates to your mobile security strategy slams the door on a wide-reaching component of the mobile attack surface. As with traditional infrastructure, there is no silver bullet for mobile security. But controlling which mobile users and devices you can and cannot trust is a good first step and can be completed today. It took more than 100 years for the Wild West to be won. Let’s work together to ensure it doesn’t take that long to better secure mobile ecosystem.

NSA Given Millions to Prevent Data Leaks, but Money Alone Doesn’t Solve Problems

“‘The reality for most organizations is that there is very little awareness and understanding of the impact that cyber attacks trust can have on an organization and Snowden is a classic example of this fact,’ Jeff Hudson, CEO of Venafi, told Softpedia.”

Read More

How the NSA was Infiltrated and Why Your Business May Be Next

“Given Snowden’s valid access to certain cryptographic keys and certificates for system administration, he was able to discover information to steal, gain access to, and “fabricate” new keys and certificates to gain trusted status. Then with this trusted status, he was able to exfilitrate data without being detected using encryption. Just like nation-state cyber espionage organizations, Snowden methodically probed and stole data with trusted status, and always flew under the radar—all of this thanks to cryptographic and authentication capabilities that the NSA itself uses to execute its mission everyday.”

Read More

How the NSA was Infiltrated and Why Your Business May Be Next

“As described in testimony by General Keith Alexander, Edward Snowden fabricated digital keys because of the NSA’s failure to detect anomalies. He used his authorized access to create new keys, obtain unauthorized keys, and create trust for new keys.”

Read More

There is an old adage from the British Army known as the “seven Ps,” that is frequently used in project planning, or when training for life-or-death situations. “Proper Planning and Preparation Prevents Piss Poor Performance.” My apologies if I have offended anyone’s sensibilities but in view of the growth of Cyber Warfare, every organization needs to ask itself if it has planned, and is prepared, for increasingly likely attacks.

The reality is that no matter how good we think we are, or how well protected, the people and organizations who are now targeting our organizations are better trained, have unlimited resources, and are extremely capable! Cyber Warfare is a reality, and as in any war, weapons do not distinguish between legitimate and innocent targets. Collateral damage is never avoidable, and your management needs to be aware that they will be held accountable for harm to the organization regardless of its source. Now this has led a number of security specialists to demand an international treaty that would halt online weapons which, quite frankly, seems a little bit like a weapons manufacturer asking for a ban on weapons.

SSL Certificates - The Target of Choice

As anyone who has been following the news for the last few months will realize, the SSL certificate has now become a key target in the cyber attack arsenal. Flame, Stuxnet, Duqu, and Mediyes are the high-tech weapons, and are likely only the tip of the iceberg when it comes to what is lurking beneath. Each of these pieces of malware have been signed by a digital certificate owned, or appearing to be owned, by reputable companies, and issued – or, again, appearing to be issued – by trusted authorities such as VeriSign, and Microsoft.

In spite of all the cries that SSL is not safe, and that there are problems with the trust model, the fact of the matter is that SSL is probably the best we have right now to protect ourselves. No one claims it is perfect, but show me a better and more secure alternative. Passwords are certainly not the way to go – they’re being hacked left, right and center. Some will argue that OTP token-based solutions do the job, but it’s not so long ago that RSA were replacing millions of them because they were hacked!

The biggest problem with SSL certificates is that most organisations have applied no Proper Planning and Preparation for the use of certificates, and as a result are vulnerable to attack.

Seven Point Plan to Avoid Piss Poor Performance

Contrary to popular opinion, Microsoft did not invent Excel to be a certificate management or policy enforcement system. Then again, given the extensive use of Excel among PKI departments, they could probably rebadge it and charge a fee! That said, in most companies, this is the level of sophistication that exists. So here are some guidelines that might be helpful, even if you’re convinced that Excel does it all.

1. Get SSL and SSH policies in place and review them annually In many organizations, a Certificate Practice Statement (CPS) does not even exist, and where it does certificate policies and the certificate practice statement are generally out of date. For example a CPS should cover topics including minimum key lengths, approved cryptographic algorithms, approved trusted root certificates, administrative access to private keys, etc.. There are many other points, but the important thing is that the CPS remains current. Last year’s CPS may already be out of date given developments in the industry. 2. Have a system-generated inventory of keys and certs Relying on manual entry in a spreadsheet does not qualify as an inventory! The general status of most IT departments is that they only have a view of a fraction of the total number of keys and certificates that are deployed. In most organizations, the management of keys has been so diluted across various groups that most organizations don’t even know how many Certificate Authorities they use. IT departments should perform network and on-board scans periodically and ensure that details such as the locations for certificates and private keys, owners or contacts are identified, and all relevant attributes of the certificates are collected. It is curious why organizations talk about having the on-going problem of finding the person responsible when a certificate expires. You would think that when this occurred once, action would be taken to stop this re-occurring – or is this just too obvious! 3. Make sure that keys and certs are compliant with policy When you consider how much time is spent on enforcing password policies, you would think that keys and certificates would also benefit from the same TLC. When organizations are still using key lengths less than 2048 and MD5 hashing algorithms, it should not come as a surprise that they are vulnerable. Can you have really even have a policy without the ability to enforce it? Certainly Excel aids nothing there. Deploying wildcard certificates across multiple systems with a long validity periods is not good practice. You might as well use the same admin password on all your systems! If you have policies, then enforce them! 4. Review your private key management processes The market for stolen SSL certificates is purportedly worth $5 billion, and since most organizations do not have system-generated inventory, it’s probably unlikely that you would notice one or two going missing. Also since you have no inventory, would you even know if a private key your admins had access to, tied to a certificate issued by any one of 650 plus CAs, from anyone of 54 countries, went walkabout? In the same way that you probably stop your admins having access to root passwords, the same steps should be taken to control their access to private keys. For example, how many organizations, as a matter of policy, replace private keys that have been directly accessed by administrators when those administrators are reassigned or leave the organization? How often are keystore passwords changed, or do you even have keystore passwords, and is there any separation of duties related to key access. These are just some of the basic steps you should be taking. 5. Safeguards to prevent migration of nonproduction keys and certs to production In a recent check on a single production server at a global, Fortune-ranked organization: instead of the 5 certificates they expected to find, there were in excess of 190! When systems move from development, to test, to production, very often the keys go with them. Not only are the keys being exposed to multiple administrators, but test environments and developers have much less regard for security than, say your average hacker. It is important that test CAs and test certificates should not be trusted on production systems, and certificates, and private keys used in tests do not move into production. 6. Be ready for the certificate authority (CA) compromise Just because Microsoft, VeriSign, and a host of others have been compromised doesn’t mean you will be. But then would you even know, because it’s not just the 650 plus CAs that you have to think about, but the over 1400 root certificates trusted by your systems. And these are only the external ones. Apart from ensuring that you have active contractual relationships with more than one vendor, and don’t end up in a Diginotar scenario where you have to shut down your internet business, you also need to be able to be ready to rapidly replace all certificates issued from each CA currently in use, assuming you know what they are. And of course this assumes you know where they keys and certificates are, which brings us back to having a system-generated inventory of keys and certs. There’s no point is simply getting new certificates if you don’t know who needs them! 7. Do a Sanity Check Like any IT security measure, its ultimate purpose is to ensure that your business is not threatened and runs smoothly. Ultimately the effectiveness of key and certificate management controls can have a major impact on the business, so take the initiative and demonstrate why somebody in your organization decided to add the “C” to your title. Otherwise you may discover that the “C” word when used to refer to you is not “Chief!"

Certificates exactly like the ones compromised as part of the Flame malware, are used everywhere in organizations worldwide today and are vulnerable to the exact same compromise. If organizations do not have an automated certificate management system in place, the likelihood of a catastrophic event is very high. Also, when the event occurs, recovery and remediation will take a very long time. Just like you need to manage and keep software up to date, you need to do the same thing with certificates.

We have seen a steady stream of third-party trust providers and the instruments they provide being compromised for nefarious purposes; RSA, Comodo, StartSSL, DigiNotar, Verisign, and now with FLAME, Microsoft. Major takeaways, NO ONE is too big to be compromised. If you hear someone talk about how they know what they are doing and have taken precautions so that they won’t be compromised, run the other way. They are in denial or worse. These trust providers are very high value targets and the compromises will continue. I chuckle when I think back on how so many said that the RSA compromise was an isolated incident.

Weaponized malware (remember when that terms was first used to describe Stuxnet?) is a trend, a progression, a continuing fact of life. Stuxnet, DUQU, and now FLAME. This is not the end, it is the beginning. It was called “weaponized” because it translated to physical damage and / or because it was apparently (95% confidence) developed by nation state(s) to engage in cyber warfare. The interesting thing about nation-state developed weapons is that once developed and deployed, they find their way into the hands of non-nation state actors. Night vision goggles, shoulder launched surface to air missiles, and Kevlar vests, for example, were developed by nation states for military use and are now in the hands of criminals and worse. The attack vectors brought to you by weaponized malware are, with certainty, going to be employed by criminals to steal money, intellectual property, and anything else of value.

What can be done to reduce susceptibility to these attacks and to remediate once the attack has occurred? A long time ago CIOs, among others, questioned the need to diligently detect down-rev and unpatched software and the importance of keeping the software at the latest revisions. This is now a well-known best practice that reduces vulnerability to many kinds of attacks.

The same diligence is required to make sure that down-rev and nonconforming-to-policy certificates are detected and updated to the latest levels. From the many conversations I have with CIOs and CISOs in the industry, their understanding of this issue and their commitment to actually fixing this problem is similar to their thinking on software updates and patches a long time ago. The attitude can be characterized as poor understanding, non committal to act, ambivalence, and from one perspective, dereliction of an important duty.

We work hard to educate organizations about their vulnerabilities. Once this particular vulnerability (ie, poorly managed certificates) is understood, it is easily addressed.

This is not a problem that anyone is going to fix for you. Microsoft just patched a majority of their software products to remove the compromised intermediate root certificates. If this was a cross-platform attack/compromise, who does the patching and updating? You do. Certificates are a cross-platform, cross-application, cross-device instrument. You must keep track of where they are installed and make sure that if there is a compromise, you can act fast. One of our customers has approximately 10,000 certificates in numerous locations (Interestingly, they thought they had about one half that number before we started the project). Before they installed an automatic certificate management system it would have taken them many months to replace the certs if there was a compromise. Now with automated certificate management the replacement can be performed in hours.

I often wonder why something so fundamental as knowing which certificates are active on the network, understanding the attributes, and managing the keys associated with the certificates is not a top priority, especially when managing these instruments radically reduces the vulnerability. This isn’t hypothetical, the compromise and threat has happened time and again. Maybe because managing things like certificates isn’t nearly as sexy as having the latest APT detection and amazing firewalls?

One of the greatest concerns of an information security person is doing something that inadvertently enables someone to have access or even take control of data or systems that they should not have access to. In reality this is exactly what FLAME is doing – taking advantage, in a very planned way, of a number of small vulnerabilities that exist in systems. How it does this is very creative and very dangerous. It exposes not just those systems that are infected today but demonstrates an attack vector that may be available for some time. This post will try to explore those ideas.

The FLAME malware has been dissected over the last few days and one of the most disturbing finds that has come out is the discovery of 3 certificates that appear to be rooted in the Microsoft Root CA. These certificates are used for many purposes, including code signing and CRL signing. We will get back to why that is important in a bit.

The big question for many is how did FLAME get into systems? The, apparently, fraudulent certificate seems to be the key to that. The creators of FLAME appear to have created a certificate that is trusted by the Microsoft Root CA. It appears that this was accomplished by taking advantage of a weakness in the hashing algorithm that was used to create the CA's certificate. The hashing algorithm that was used was MD5. This algorithm has been shown to have a weakness that allows an entity with enough computing resources to create a whole new certificate with the same hash. This is of course the working theory, as true confirmation will require more investigation, but this is not the first time a certificate has had its hash recreated using different data. In fact this was first done in 2005 leveraging networked PS3 Playstations. Once this certificate was created it was a matter of injecting it into a system and since it appeared to be trusted by the Microsoft Root CA most applications would automatically trust it, including the OS.

This is where the malware developers were very creative. In creating the certificate using the hash of existing Microsoft PCA and RA certificates they were able to be trusted for the same purpose, which included code validation and CRL signing. The CRL signing becomes important since the CRL issued by a CA is the list of certificates that were issued by the CA that are no longer trusted. Having the capability to sign a CRL meant that even if a bad certificate was found the perpetrators could easily just issue a CRL that did not have the certificate on it.

It appears that FLAME was intended to perform a similar function as to that of Duqu, an earlier piece of malware. There are similarities in that the intended purpose of both appears to be data collection. What is interesting is that Duqu did appear to collect certificates and, where possible, private keys. This may indicate some linkage between the two but right now that would be pure speculation. Duqu does have similarities to the earlier discovered Stuxnet malware code, which was very targeted in its actions. It performed some data collection activities, but its major purpose was to disable command and control systems in SCADA-like systems.

The question for most readers at this point is - "Why should I be concerned?"

Well the concern arising from this is a very real concern. It is not a concern that FLAME may affect you, even though it is possible that it could, but so far it has affected a very targeted set of systems. The greater concern is the attack vector that was used.

Much like Duqu and Stuxnet, FLAME leveraged vulnerabilities within the Microsoft platform. Duqu and Stuxnet leveraged zero-day vulnerabilities for code delivery, FLAME apparently took advantage of a weak hashing algorithm that was used on a set of certificates that had broad application use. This type of vulnerability also raises questions about processes within Microsoft when they create CAs and when they assign usage parameters. These concerns include:

• Use of MD5 for signature hashing
• Broad definition of key usage for given certificates
• Lifetime of intermediate CAs given the ever-changing technology environment

So outside of the obvious issues for anyone that was impacted directly by FLAME this does highlight a number of weaknesses in managing environments. One's own environment may be greatly influenced by those you deal with. In this case an injection occurred, likely, through a software registration process. It was achievable due to poor management of signature algorithms and certificate usage settings. This attack demonstrates that these types of attacks are achievable and likely have been for at least 5 years.

So if you were not paying attention to what certificates were in your stores before I hope you will now. You need to:

• Look for known bad ones;
• Evaluate what roots you trust, and why;
• Look at what signing, hashing and key lengths are used and;
• Look at what certificate lifetimes are indicated

This area of certificate and key management is becoming more critical as it no longer just touches how I secure my running shoe purchase on Zappos but now it affects how I get software and how I trust that and in todays cloud-based world that is a potentially disconcerting issue.

Read the Venafi Security Alert: MD5 Vulnerability and learn more about how to identify your MD5 certificates.

A couple of days ago I wrote a quick post on FLAME and how the developers of the malware had been very creative in their attack vector. At that time there was still a considerable amount of work being done to validate the attack vector, but as I pointed out the evidence that existed pointed to a collision attack on the MD5 hashing algorithm that was used in generating two of the CAs’ root certificates signatures.

Today there is some confirmation that the attack did leverage the collision vector, as highlighted in an email to a cryptography discussion group. The approach of the developers was unique and had not been seen before, but the concept was the same concept that had been used in previous MD5 collision demonstrations, including those in 2008. As we discussed, the attackers then leveraged the fraudulent certificate to hijack the Windows update mechanism. It appears that the ongoing investigation is confirming what we have believed all along.

Microsoft's response to the fraudulent certificates was rapid but it only addresses the problems that existed in the Microsoft environment. It is imperative that organizations quickly determine if there are other CA certificates that exist in their system trust stores that could be as easily taken advantage of and compromised. We recommend that organizations stop issuing certificates with MD5 and remove from their trust stores any certificates that use MD5 within the signature hashing algorithm.

The other actions that were mentioned in the previous post should also be put into an organizations existing operational action plan including:

• Look for known bad certificates and remove them;
• Evaluate what roots certificates you trust, and why;
• Look at what signing, hashing and key lengths are used and;
• Look at what certificate lifetimes are indicated

These steps are the simple ones that need to be taken today. Moving to a comprehensive Key and Certificate Management System will ensure that the processes to maintain the environment can be automated.

FLAME demonstrated what can be done. Organizations need to take action to ensure that they do not get caught and burned by the next variant of FLAME.

Read the Venafi Security Alert: MD5 Vulnerability and learn more about how to identify your MD5 certificates.

In a Network World article posted yesterday, Marcus Carey, a researcher at Rapid7 is quoted as saying:

“Flame is an impressive piece of work, but it doesn't appear to pose a threat to most corporate networks because it seems to have been crafted for targeted attacks against networks in the Middle East.”

I would like to expand on and get specific about what he is quoted as saying. Parsing the statement, Carey claims that the Flame malware probably doesn’t pose a threat to corporate networks. He is probably right because every half-conscious security person is on the lookout for Flame.

The problem is that most people are looking at the malware package… the 20MB malware, and not the attack vector. The bigger issue is the door that Microsoft left open for the introduction of Flame: utilizing certificates with MD5 that has been proven vulnerable for the last 7 years. Microsoft closed their door (removed those untrusted vulnerable certificates) and have announced to the world that they fixed the problem.

Whew… everyone breathe a sigh of relief.

Big problem, that sigh of relief. The serious security vulnerability door remains wide open for 99% of all remaining organizations around the world. We know this to be a fact. MD5 is being used broadly on critical networks.

So when Microsoft says not to worry, the problem’s fixed. When well-respected researchers correctly point out that Flame itself is not a threat, most people assume that the danger is behind us. That assumption could not be more wrong and dangerous.

The attack vector is still wide open. Stay tuned.

Read the Venafi Security Alert: MD5 Vulnerability and learn more about how to identify your MD5 certificates.

Microsoft takes security seriously. We know this because they apply a huge amount of resource to improving security in their products and systems. Additionally, it has been an area of focus of theirs for a while.

Microsoft issued digital certificates in 2009 using MD5 technology, which they themselves told people in 2008, not to use. They used these certificates in the licensing and update systems for one of their products. The MD5 based certificates were proven to be breakable in 2005.

"Certificates are a foundational part of the internet security infrastructure. Certificates protect data as it moves throughout the internet and they identify and represent that an application or a machine is what it says it is (authentication). Without certificates we would not have ecommerce, secure communications, and most of the other facilities that the world relies on today."

The attackers used these breakable MD5 certificates to open doors in the targeted networks. They broke the MD5 certificates and manufactured fraudulent copies. Using the fraudulent copies the attackers executed a man-in-the-middle attack which in effect created a wide open door into their targets. Through these open doors, they installed the Flame malware. MD5 based certificates were the open door, or attack vector, that allowed Flame to work. Microsoft closed the door by rendering the Microsoft specific MD5 certificates, invalid.

They closed THEIR door, but they did not close any other doors, including many that are on your network now. The really bad part of this whole situation is that Flame has received intense and ongoing attention in the media worldwide. Every attacker is contemplating how they use these open doors in their attacks.

Further, we know that the open doors exist throughout the Global 2000. We have current data from scans of the G2000 showing that 17.4 % of certificates in the Global 2000 use MD5 hash algorithms and are therefore open doors. This is not speculation, theoretical, or hypothetical. The doors are open now.

We have been informed by a number of the G2000 companies that their legal and risk departments are mandating that MD5 certificates be removed from the network. There are a number of rather severe consequences if one knowingly leaves doors open that could compromise customer, patient, or financial data. And that is not the biggest risk. Imagine your most valuable data. What would happen if it was stolen? Know that attackers will use the currently open doors on your network to go after your most valuable data.

"Certificates are a bit of a mystery to almost everyone on this planet except for technologists that work with them. Because of non-understanding, certificates are mismanaged just about everywhere. Even at Microsoft, they used certificates that by their own admission were known to be breakable in 2005. This is a classic case of poor certificate management."

Also please realize that IDS, IPS, firewalls, AVs and other security measures do not address these open doors on your network. You need to take specific action immediately.

What do you need to do about the open doors on your network today?

1. Locate the MD5 based certificates on your network:
   Priority - High
2. Remove them or replace with acceptable technology like SHA1 and SHA2
   Priority - High
3. Establish a centralized management system for tracking and managing certificates so that the weak certificates or certificates that do not conform to your policies do not reappear on your network
   Priority - High

In summary, there are known open doors on your network right now. Before you do anything else, find out where they are and close them. Then put a system in place that will make sure they stay closed.

Read the Venafi Security Alert: MD5 Vulnerability and learn more about how to identify your MD5 certificates.

There is an old adage from the British Army known as the ‘seven Ps', and it is frequently used in project planning or when training for life-or-death situations.

‘Proper planning and preparation prevents piss poor performance'. My apologies if I have offended anybody, but every organisation needs to ask itself if it has planned and is prepared for increasingly likely attacks.

As anyone who has been following the news for the last few months will realise, the SSL certificate has now become a key target in the cyber attack arsenal. Flame, Stuxnet and Duqu are the high-tech weapons, and are likely only the tip of the iceberg when it comes to what is lurking beneath.

Each of these pieces of malware have been signed by a digital certificate owned, or appearing to be owned, by reputable companies and issued by trusted authorities, or are appearing to be.

In spite of all the cries that SSL is not safe and that there are problems with the trust model, the fact of the matter is that SSL is probably the best we have right now to protect ourselves. No one claims it is perfect, but I haven't yet seen a better and more secure alternative.

Passwords are certainly not the way to go – they are being hacked and some will argue that one-time password (OTP) token-based solutions do the job, but it's not so long ago that RSA was replacing millions of them. The biggest problem with SSL certificates is that most organisations have applied no proper planning and preparation for the use of certificates, and as a result are vulnerable to attack.

Contrary to popular opinion, Microsoft did not invent Excel to be a certificate management or policy enforcement system, although given the extensive use of Excel among PKI departments, they could probably re-certify it and charge a fee! But then in most companies this is the level of sophistication that exists. So here are some guidelines that might be helpful:

Read Full Article