April 9, 2014 | Leave a Comment
By Patriz Regalado, Product Marketing Manager, Venafi
Your organization’s policies—or lack of policies—regarding trusted root CA certificates are exposing you to unnecessary risk. Because certificates serve as credentials for so many mission-critical transactions, attackers are constantly trying to obtain trusted certificates that can be used in targeted attacks. Systems, for their part, refer to their store of trusted root certificates to determine which certificates to trust. If a certificate is signed by a trusted CA, the system trusts the certificate. To compromise a system, therefore, an attacker simply needs to obtain a certificate that is signed by a trusted root CA—whether by tricking the CA into issuing a fraudulent certificate or by compromising the CA. Every CA that your systems trust represents a potential entry point for attackers.
Many organizations expose themselves to unnecessary risk by allowing far too many of these entry points. They retain the default trust stores distributed with most operating systems and application servers, which include far more certificates than are necessary. According to a University Hannover Germany study, common trust stores for various platforms and operating systems—such as Windows, Linux, MacOS, Firefox, iOS and Android—contained more than 400 trusted root certificates. However, only 66% of these certificates were used to sign HTTPS certificates, leaving the other 34% of trusted root certificates susceptible to use in certificate-based attacks.
We are seeing more and more evidence of malware signed with a legitimate CA because an attacker stole a private key or obtained a fake certificate. Consider the following scenario: Your organization is currently trusting AcmeCA on many of your systems simply because AcmeCA is approved by the vendor providing the software for your systems. If a malicious attacker gains access to a fraudulent certificate from AcmeCA, that attacker can use it to attack multiple systems within your organization.
Your organization has outward-facing systems, such as those focused on customer interaction or users’ desktops, that must trust a particular CA in order to perform day-to-day business. However, your organization also includes systems that don’t need to trust a particular CA but are, in fact, trusting it. For example, internal systems that communicate only with other internal systems don’t need to trust any CAs but the internal CA(s). In addition, partner-focused systems that communicate with a limited number of partners require just a handful of CAs.
Most organizations have no visibility into which root certificates they are trusting and where those root certificates are deployed; consequently, they cannot limit their exposure to certificate-based attacks. As a critical first step, organizations must gain visibility into which root certificates are being trusted within their environment. They must compile an inventory of their root certificates so they can reduce the risks caused by unnecessary trust. In the AcmeCA scenario, for example, you would see that AcmeCA is installed on multiple systems within your organization, determine that these systems don’t need to trust AcmeCA, and remove it. Thus, an attacker would be unable to use a fraudulent certificate from AcmeCA to successfully attack your organization.
By identifying CAs that should not be trusted on mission-critical systems, organizations have the intelligence and risk awareness to prevent attacks that leverage certificates from those CAs. One way to take action is through certificate whitelisting, which ensures that whitelisted certificates are included in trust stores and blacklisted certificates are excluded from trust stores. Certificate whitelisting limits the number of CAs that are trusted, allowing organizations to secure and protect the CAs they trust while flagging or disallowing untrusted SSL/TLS sessions. As a result, the attack surface is dramatically reduced.
Organizations can eliminate unnecessary risk from digital certificates signed by untrusted CAs by establishing and enforcing certificate whitelists and updating which CAs are trusted within the enterprise. They can enforce baseline requirements for which CAs should be trusted (whitelist) and not trusted (blacklist) on mission-critical systems and ensure whitelisted certificates are included in trust stores and blacklisted certificates are excluded, preventing attacks that leverage certificates from blacklisted CAs.
April 4, 2014 | Leave a Comment
By Gavin Hill, Director, Product Marketing and Threat Intelligence, Venafi
Last month, ESET, a leading IT security company, published a detailed analysis of operation Windigo. This operation, active since 2011, has compromised over 25,000 Linux and Unix webservers. Cyber-criminals use these servers to steal SSH credentials, redirect visitors to malicious websites, and send millions of spam messages per day. The ESET report provides information on several components of Windigo, including Linux/Ebury, an OpenSSH backdoor used to steal payloads, SSH passwords, SSH keys, private keys, private key passphrases, and other credentials.
I found it very intriguing that the report indicated that Windigo does not exploit any cryptographic or system vulnerabilities. Instead, this operation leverages only stolen credentials—highlighting the rapidly increasing prevalence of trust-based attacks.
At the heart of operation Windigo’s success is the SSH credential-stealing Linux/Ebury backdoor. Without the SSH credentials, Windigo is not able to expand and compromise additional systems. Once malicious actors have obtained the SSH credentials and installed Linux/Ebury on systems, they can continue to collect new or modified credentials on infected systems. As they do with SSH daemon backdoors, cyber-criminals exploit the blind trust in encryption to own the compromised systems, maintaining access even if the credentials are later changed.
Stolen SSH credentials that do not provide root-level access do not go to waste; they are used as part of spam bot operations or to log into other servers. ESET monitored data sent to exfiltration servers over a period of five days. During that time, ESET captured 5,362 unique successful logins. The figure below shows the number of logins that used root credentials as compared to other forms of access.
Although the Windigo botnet is smaller than most end-user botnets, it’s important to note that Windigo-compromised systems are all webservers with a magnified ability to direct users to malicious sites hosting malware. In fact, Windigo is redirecting over 500’000 web visitors to malicious content every day. By using keys, adversaries have the privileges and trusted status required to turn legitimate systems into a malicious infrastructure that dwarfs even some cloud computing vendors.
Infected systems that are part of the operation Windigo botnet are extremely difficult to detect, in no small part because adversaries have the elevated privileges required to install any binaries they choose. They then conceal these highly sophisticated binaries with advanced cryptography. “System administrators attempting to clean systems that are part of the Windigo operationare usually able to remove other malware components such as Linux/Cdorked, but often overlook the OpenSSH backdoor due to the stealth mechanisms used.” With the backdoor still open, the Windigo operators can return at a later date and revert the changes made by system administrators.
For this reason, the ESET paper advises administrators to “completely wipe their [infected] servers and rebuild them from scratch using a verified source.” Administrators should also assume that all administrator credentials on a compromised system have also been compromised. Like Mask malware, used to steal cryptographic keys and digital certificates, operation Windigo demonstrates the increasing numbers of advanced and persistent adversaries targeting keys and credentials. Last week the latest set of released Snowden documents, titled “I Hunt Sys Admins,” further revealed how malicious attackers and nation states target the SSH credentials of system admins for theft. This unsurprising information still highlights most organizations’ lack of visibility and control over their keys and certificates.
It’s no surprise that adversaries are increasingly using keys and certificates in their nefarious campaigns. Too many organizations employ a lackluster approach to protecting their SSH keys, recklessly exposing themselves to eager cyber-criminals. In addition, most organizations have little visibility into their cryptographic assets—the very assets that criminals are exploiting—making it hard for administrators to understand the scope of the problem or to detect anomalous usages.
In research conducted by Venafi, 74% of organizations have inadequate SSH security policies. This statistic alone is an enticing invitation for any attacker. Why not target an organization with no security controls or ability to respond? Based on revelations in just the first three months of this year (including the release of more Snowden documents and revelations about Mask and Windigo), I’d suggest that we are seeing only the first crest of a threatening tsunami of attacks on SSH. It’s time organizations understand what trust-based attacks are and how to protect against them.
On behalf of the CDPC Leadership Team: Open Review Period – Cloud Data Protection Cert Candidate Project
March 29, 2014 | Leave a Comment
We would like to invite Cloud Security Alliance (CSA) members as well as the cloud and security community to participate in the open review period for a new candidate project that we are proposing for contribution to the CSA Research Portfolio. In addition, we are considering contributing this Intellectual Property to CSA for further development with no patent or copyright encumbrances. The name of the project is the Cloud Data Protection Cert (CDPC) which we, Richard Noguera, Global Head of Information Security at Gap, Inc. and Evelyn de Souza, Compliance and Data Privacy Leader at Cisco Systems, co-developed. The open review period will start today and end on April 28, 2014.
As background, the Cloud Data Protection Cert is intended to be a web-based tool that presents Cloud Providers and Cloud Consumers with a tiered data sensitivity model. Given all the recent and ongoing news tied to data breaches, this is intended to help companies apply optimum data protection controls within cloud environments by reporting an overall protection score and controls guidance based on a maturity curve.
We are proposing that the Cloud Data Protection Cert be included as part of the CSA’s Governance, Risk Management and Compliance (GRC) stack as organizations will also have more granular controls for leveraging the Cloud Controls Matrix (CCM). As part of the GRC stack, it will allow for implementing controls based on data type and recognizes that controls don’t apply equally across data with a more public profile versus data that is regulated.
At the recent RSA Conference (US), we held an exclusive executive roundtable where 23 CISO and VP-InfoSec level attendees across service providers, industry and security vendors participated and provided feedback to the beta version of the web-based tool. The feedback was positive, so we decided to open this up to a larger audience for review and comments.
We would like to ask reviewers of the Cloud Data Protection Cert for assistance in assessing the following:
- Would you like to see this project contributed to CSA for further development?
- Is the tiered data protection model useful?
- Should it be built into the CCM as a default model versus a one size fits all data protection model?
- Should this be a standalone tool within the GRC suite of tools or merged with the CCM?
- Do reviewers like this format for this tool – what should stay the same – what should change?
To review the Cloud Data Protection Cert, visit: http://clouddataprotection.org/cert/
Feedback and questions can be submitted via the online form after testing the web-based tool or you can email [email protected].
Richard Noguera, Global Head Information Security, Gap, Inc.
Evelyn de Souza, Compliance & Privacy Leader, Cisco Systems
March 28, 2014 | Leave a Comment
KEVIN BOCEK, VP, SECURITY STRATEGY & THREAT INTELLIGENCE, VENAFI
SSH keys again confirmed as a favorite target for advanced attackers – how will IT security fight back?
Newly leaked NSA documents from Edward Snowden, entitled “I Hunt Sys Admins” show that sophisticated attackers are aiming to breach targets by taking aim on system administrators. Threatpostaptly described this strategy as the “biggest no-brainer.” A core part of this playbook is targeting SSH and the keys used to gain authenticated privileged access.
We must assume that based on previous attacks that adversaries of all types also are targeting system administrators and have the same or even more effective techniques. These sophisticated adversaries include nation states seeking to exploit intellectual property for economic benefit and organized cybercriminals motivated for profit.
The targeting of SSH comes as know surprise given The Mask APT operatorsand others hunger for SSH keys to infiltrate networks, gain administrator level access, and keep it for a very, very long time.
Part 4 of the leaked documents – “I hunt admins that use SSH” – demonstrates attackers understand the opportunity SSH provides and value for Computer Network Exploitation (CNE) – also known as owning your network, data, and business. As previous Venafi research identified, an attacker with SSH is able to gain administrator-level access that travels over encrypted sessions and in most organizations will never expire. With 1 in 2 organizations never changing SSH keys, attackers fly under the radar and remain in a breached state, forever. And in recent conversations I’ve had with some of the world’s most sophisticated IT security teams, incident response teams indicated they don’t change SSH keys during remediation – perpetuating the insanity!
If organizations can take just a few steps, they’ll have taken giant leaps in defending their enterprises from the assault on SSH and system administrators:
- Place IT security in charge of securing SSH: This has nothing to with technology. Systems administrators are not security experts but yet they are self-policing SSH keys that provide access to critical systems. IT security is best equipped to understand threats and security controls necessary to protect systems.
- Survey all keys, map key owners and access, and continuously monitor: No enterprise today knows who is responsible for all SSH keys and which servers, VMs, and cloud services these keys provide access to. Searching networks, servers, and endpoints to find all keys and map these to trusted key lists is no longer optional.
- Enforce key rotation policies: Probably the biggest step forward is treating SSH keys like IT security has secured other critical systems. Replacing SSH keys at regular intervals (e.g. every 30 days like your Windows password) helps to limit the exposure of a possible breach. Attackers will need to keep stealing keys, increasing the likelihood of detection, to maintain access to your network and systems.
- Detect anomalies, respond fast: In addition to stealing keys, attackers are known to insert their own keys as trusted. These anomalies can be detected and instantly remediated if the current trusted state of keys is known and understood. As well, incident response teams must replace SSH and SSL keys whenever they perform remediation on systems even if the compromise of a key is not suspected.
Taking these steps will go a long way to defending against attackers that hunt system administrators. Venafi is already helping the world’s most targeted enterprises secure their SSH keys with Venafi TrustAuthority to gain visibility and Venafi TrustForce to enforce policy, detect anomalies, and respond immediately. This powerful security is part of the Venafi Trust Protection Platform that secures not only SSH keys but also SSL keys and certificates along with mobile certificates.
And one more thing: if system administrators and their SSH keys are targets, it is not a giant leap to assume that SSL keys and certificates are also being targeted and compromised by the same adversaries. This would allow attackers to monitor encrypted SSL communications, surveil their targets, and impersonate trusted web services to collect data and further expand attacks. Defending our enterprises from these assaults means not just protecting SSH keys but also SSL keys and certificates.
Putting these new revelations together with our current understanding means were just another step closer to Gartner’s prediction of “Living in a World Without Trust.” If we don’t secure and protect all of the keys and certificates that establish trust for our enterprises, “I Hunt Sys Admins” shows we’re quickly headed to making this prediction a reality.
March 26, 2014 | Leave a Comment
By Sanjay Beri, Founder and CEO, Netskope
For as long as “Shadow IT” has existed, technology vendors have encouraged IT professionals to uncover unsanctioned apps in their organizations so they can block them. But people rely on apps like Box, Dropbox, Evernote, Jira, and Workday for business critical functions. A recent Cloud Report revealed that 90 percent of organizations grossly underestimate the number of cloud apps running in their environment, and 77 percent of cloud apps are not enterprise ready. The cloud is such a part of standard practice that blocking even non IT-run apps isn’t an option anymore.
With just a little diligence, you can eliminate the catch-22 of letting people use the cloud apps they want while protecting the enterprise from data loss and network threats. By looking closely at cloud app usage, implementing granular policies, and using data to have a conversation, you can make employees more productive while protecting the business’ interests.
Here are ten ways:
- Evaluate app risk. Discover the cloud apps in your environment and evaluate their risk against an objective yardstick. You can comfortably deploy and manage low-risk apps. For higher-risk ones – especially ones you don’t procure or administer – go a step further to evaluate how those apps are being used in your enterprise. Are they broadly deployed or used in important ways? Do they deal with sensitive data? If so, you may need to limit certain activities (e.g., share) across all of the high-risk apps or partner with the business to select less risky alternatives.
- Monitor usage. Go beyond simply discovering cloud apps in your environment to understand what people are doing in them. Measure users and usage volume to ascertain scope of the app’s impact. For heavily-used apps, identify activities (e.g., sharing, downloading, and editing), and build a business case to either support the app or, in the case of redundancy, suggest consolidation. Finally, look at usage through a risk lens, assigning each activity a risk level. When you find an app in which users are performing high-risk activities, set a policy blocking the risky activity.
- Look for anomalies. When monitoring activities, it’s important to set a baseline so you can detect anomalous behavior. Create a set of activities you regularly track for that could signal risky behavior or an external attack. Anomalies to watch out for include sudden spikes in usage, excessive downloading, and log-ins in from atypical locations or from two locations at once.
- Block an activity, not an app. Some technology vendors encourage IT to uncover unsanctioned apps so they can shut them down. This sledgehammer approach is so yesteryear and pits IT against the business. Rather than block apps wholesale, analyze the activities within apps that represent the most risk (e.g., downloading to a mobile device, sharing with someone outside of the company) and block them. This lets you shape the activity to mitigate risk. Make sure you do this for not just the apps you manage but especially for the ones you don’t.
- Protect data in context. Adopters of data leakage prevention solutions – or any detection technologies for that matter – know full well that too many false positives erode the value of a solution. Rather than just detect patterns or key words, define granular contextual situations incorporating user, group, app category, location, device, and activity (such as upload or share) that help narrow the scope of where a data breach is likely to occur. This helps increase accuracy when you do apply data loss prevention techniques such as blocking or encrypting.
- Have a conversation. Some businesses need to comply with strict regulations like PCI or HIPAA, but at the same time need to allow usage of cloud apps. In this case, when you find an app or app behavior that could hurt your compliance status, learn how the app is being used, come up with a few options to improve your compliance status, and then have a conversation about it with the user or line of business. Tapping someone on the shoulder and having a data-driven conversation increases the chance of an optimal outcome for everyone.
- Provide alternatives. If you need to block a certain app because it doesn’t meet your industry’s compliance needs, investigate and provide alternatives. It’s possible to identify apps that have similar features and functionality to riskier ones. Tell your staff why certain apps put the business at risk (e.g., poor auditability or lack of HIPAA compliance) and offer choices that better meet your criteria. This positions you as a problem-solver and increases the chances that personnel will solicit your input before procuring a cloud app next time.
- Trust but verify. Many businesses are reluctant to put onerous policies in place because their corporate culture centers on trusting people. However, being too trusting can compromise security and open you up to data leakage. To balance this, audit your cloud app usage on a periodic basis and set watch lists for particular behaviors that can signal a potential data breach or malicious activity.
- Do post-event forensics. Besides audits, perform forensic analysis after a suspected breach. For example, if a departing employee steals proprietary content to take to a competitor by downloading and re-uploading it to a cloud storage app, reconstruct a trail of those activities to generate the evidence you need to take action and even recover the content.
- Get specific. Run analytics and set policies based on combinations of app, category, user, group, location, device, OS, browser, time, app confidence score, activity, and content. This specificity allows you to be alerted when people in Investor Relations share content from a cloud app during the company’s quiet period, block downloads of sensitive documents to mobile devices, prevent HR employees from accessing salary data outside of work, and limit content uploads for people in Germany to apps hosted in the United States, among other parameter combinations.
The above are ways to take a proactive approach to cloud adoption and enablement while also mitigating risk and keeping your businesses compliant with your policies. While you may find that sometimes the best course of action is to block an app, at least you have options and can make the decision with data.
March 19, 2014 | Leave a Comment
BY: GAVIN HILL, DIRECTOR, PRODUCT MARKETING AND THREAT INTELLIGENCE, VENAFI
I’ve been attending RSA for many years now, each year it seems to get bigger and better. This year a record breaking 28,500 attendees were in San Francisco to learn how to stop cyber-criminals in their ever increasing malicious campaigns against organizations.
At RSA 2013, Microsoft declared “PKI is under attack”, and Intel Security-McAfee outright questioned the validity of digital certificates as a trust mechanism. In an ironic twist of fate, the Mask “Careto” malware was discovered days before RSA 2014. Dubbed one of the most advanced threats to date, the Mask malware payload included the theft of SSL, VPN, and SSH cryptographic keys and digital certificates.
At Venafi, each year we conduct a survey of RSA attendees to get a better understanding how well organizations are doing at protecting themselves against compromise, and responding when compromised. Our focus is specifically on how malicious actors abuse the blind trust that every organization has in keys and certificates—trust-based attacks.
Responding to an Attack
In the last 24 months, the significant increase in trust-based attacks has caught the media’s attention. It would seem with all the publicity, that organizations should be more aware and better prepared to detect and remediate trust-based attacks. But it’s quite the contrary; last year 43% of organizations took less than 24 hours to correct certificate trust on all devices for trust-based malware—malware that uses keys and certificates. This year only 35% of organizations could do the same—the time to respond actually increased, resulting in enterprise networks being compromised for longer periods of time.
The time to respond to any attack determines the amount of damage incurred to any organization. The challenge, you first need to be able to detect that your organization has been compromised and understand the attack vector. When it comes to keys and certificates as an attack vector, most organizations don’t know how to detect malicious activity. 58% of survey respondents stated that their organizations either don’t know how they would detect stolen or compromised keys and certificates used to attack their network, or simply could not detect this attack vector at all.
According to Intel Security-McAfee, in the last 24 months mobile malware has risen by 1600%. In an effort to mitigate this new threat, many organizations deploy MDM solutions and remote-wipe devices that are lost or potentially compromised. Regardless how many time a device is remote-wiped; if the certificates associated with the user (VPN, S/MIME) of the device are not revoked, and a malicious actor already has a copy, they still have access to your network. Our survey shows that almost 20% of organizations do not revoke certificates when remote-wiping a device, the result is that anyone with the certificate will have access to the network.
The impact of the National Security Agency (NSA) breach by Edward Snowden exposed a dirty little secretthat IT admins have been aware of for many years. 74% of organizations report that they have no systems to secure SSH. When detecting new SSH keys used in the cloud, 44% of respondents stated that system administrators are responsible for their own SSH keys, while 16% relied of scripted solutions to discover the SSH keys. In January of this year, the exposure of hundreds of administrators’ SSH keys showed the implications of letting administrators self-police when it comes to securing SSH keys.
Worse yet, 60% of organizations would take more than 24 hours to identify and replace rogue SSH keys used in an attack on the network.
Rise of a New Attack Vector
Gartner predicts that by 2017, over 50% of all network attacks will use encryption. We asked RSA 2014 attendees what their thoughts were on this. The results were in line with Gartner predictions, 62% of respondents believe there will be an increase in the use of SSL in cyber-attacks.
I’m not surprised by the response that cyber-attacks will use more SSL over the next 3 years. The demand for “always on SSL” is only fueling the use of SSL in cyber-attacks. Cyber-criminals need to be able to disguise malicious traffic, and what better way to do so when less than 20% of SSL traffic is inspected by organizations.
Every organization needs to take a step back and reevaluate their security strategy. Cyber-criminals are taking advantage of the trust established by keys and certificates. So much so that Forrester Research has concluded “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.”
As any good security practitioner would recommend, when malware known to steal credentials—including keys and certificates, and SSH keys—like Mask malware, is discovered on the network; the recommended practice is to remove the malware, change passwords, replace keys and certificates, and patch for any zero-day exploits. Sadly, 67% of RSA 2014 survey respondents work at organizations that are in a state of continuous vulnerability to cybercriminals. Only 33% of them replace user password and keys & certs when credential stealing malware is discovered on the network. Are you one them?
March 11, 2014 | Leave a Comment
By Patriz Regalado, Product Marketing Manager, Venafi
Because cyber-criminals always seem to find new ways to circumvent traditional security measures, the threat landscape is constantly changing. A McAfee Labs Threat Report in Q3 2013 revealed an alarming trend: the type of malware proliferating most rapidly is digitally signed malware on mobile devices. McAfee Labs also identified a new family of Android malware that is enabled by compromised certificates. This new malware already accounts for 24% of digitally signed malware.
Although it is not surprising that malware targeting mobile devices—particularly Android devices—is proliferating, the severity of the threat is alarming. The rapid increase of digitally signed mobile malware continues to call into question the validity of all the mobile digital certificates that are in use and begs the question of how enterprises and individuals can distinguish between legitimate and compromised mobile certificates.
One thing is for certain, mobile malware attacks that are exploiting poorly secured cryptographic keys and certificates on mobile devices will continue to increase. Digitally signed malware is on it’s way to triple-digit growth, and by the end of 2014, it won’t be surprising to find almost all mobile malware attacks using digital certificates. But what’s even scarier is that most organizations today don’t have a mechanism in place to detect compromised mobile certificates. The traditional security controls and solutions they are using do not detect such attacks. Consequently, mobile certificates will continue to be a perfect target for cyber-criminals and pose a huge risk to organizations.
Cyber-criminals have learned that the quickest and easiest way to inject malware that resides undetected on mobile devices for months or even years is by signing the malware with compromised or stolen digital certificates. This digitally signed mobile malware can operate undetected by most organization’s whitelisting security controls. Cyber-criminals then become trusted users on mobile devices, evading traditional security controls and gaining undetected access to network resources.
Why is it so easy? Most organizations cannot detect or respond to anomalous certificates that authenticate systems and users on mobile devices, applications, and networks. Exploiting digital certificates is, therefore, the perfect attack. For example, certificates are used to verify the identity of an application’s owner. If cyber-criminals can obtain one of these digital certificates, their malware can circumvent any traditional security provisions. Because organizations do not protect their digital certificates from such attacks, users have a false sense of security, relying on an illusion of trust. Attacks that inject mobile devices with malware to gain access to corporate networks and steal corporate data take advantage of the broken trust caused by unsecured and exposed certificates and keys.
Many organizations invest significant resources into detecting and remediating mobile malware but ignore the more dangerous and underlying threat of weak and unsecured mobile certificates. Maybe they make this mistake because mobile certificate security is overshadowed by the focus placed on mobile malware itself. Whatever the reason, organizations continue to focus on mobile malware rather than examining the factors that erode trust and reducing their risk by implementing better mobile certificate security practices.
Although it is critical to address mobile malware, it is equally important to identify how attackers are exploiting broken trust to infiltrate systems and steal sensitive corporate data. I have seen too many instances where organizations place themselves at massive risk of attack because improperly secured certificates have opened doors to mobile malware.
March 6, 2014 | Leave a Comment
BY KEVIN BOCEK, VP, SECURITY STRATEGY & THREAT INTELLIGENCE, VENAFI
Breached Enterprises Will Be Owned by The Mask operation for Years to Come
For over a year, Venafi has been charting the course of attacks on the trust established by keys and certificates. The dramatic rise in attacks has led Microsoft to declare “PKI is under attack” and Intel Security-McAfee to “question the validity of digital certificates as a trust mechanism.” From key and certificate stealing trojans to stolen certificate marketplaces, the cybercriminal community has woken up to a whole slew of new vulnerabilities and powerful attacks.
It now appears that in fact a monster has woken up! Kaspersky Labs hasidentified and documented what it terms as “one of the most advanced threats.” Known by its Spanish name “Careto,” The Mask operation is a sophisticated, organized attack using multiple attack methods to steal data. Its alarming set of targets include a variety of SSL, VPN, and SSH cryptographic keys and digital certificates.
The impact of this revelation is simple: breached organizations are now owned by The Mask operation. Cleaning up malware, reimaging servers, and resetting password won’t help. The attackers now own keys and certificates that provide the fundamental trust that is used to know if a server, cloud, or administrator is to be trusted. The attackers can decrypt communications and data formerly thought secure and private. The likely inability to remediate all of the compromised keys and certificates will leave the attacked breached for years, and in many cases decades.
Breached enterprises might as well bulldoze their data centers to regain ownership if they can’t replace all—not some—but all of their keys and certificates.
How can this be? Mask’s operations are known to steal SSH keys used to authenticate administrators, servers, virtual machines, and cloud services. SSH keys provide root-level access and don’t expire—ever. Steal an SSH key and you likely have perpetual backdoor access. That bleak outlook is why Forrester Consulting simply previously concluded, “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.”
Breached organizations must now identify all keys and certificates and immediately replace them. Based on industry research and Venafi’s experience in securing Global 2000 enterprises and governments, the breached will likely have no visibility in to the scope of the problem facing them and no ability to respond to these attacks on keys and certificates by replacing all of them. They need to take quick action now as the true intentions and impact of The Mask operation are yet to be seen. Otherwise, they might as well invest in bulldozers instead of malware cleanup or new firewalls.
The analysis is troubling. The details to follow are even more troubling. The impact and seriousness of The Mask on the breached cannot be understated or underestimated. For those not involved, it serves as another lesson that attacks on keys and certificates are very, very real and every enterprise must gain visibility, controls, and response mechanisms now.
Attacking Trust: Ownership for Life
Mask’s operations to steal keys and certificates is alarming. By stealing and leveraging trusted status, The Mask organization can now impersonate, surveil, collect, and decrypt its targets’ communications and data. Essentially, The Mask operators own the breached and for a very long time to come.
In a masterful criminal effort, Mask’s team didn’t just create powerful weapons—they attacked where they know their targets have no visibility and no ability to respond. Yes, the breached can now clean up malware infections, reimage servers, and reset passwords. But, as research has shown, Mask’s targets will not be able to identify and replace the tens of thousand of SSL, SSH, and other keys and certificates stolen.
Mask’s targets are like fish just caught and hauled on to a fishing boat. Fish will struggle to get back in the water, but will slowly suffocate on the boat’s deck with no hopes of escaping and returning to the water. With the ability to impersonate, surveil, collect, decrypt its targets communications and data, and their targets inability to respond and remediate to the attacks already committed with keys and certificates there may be little hope for the breached as they wait to potentially be attacked and suffocated by the blind trust they relied upon is turned against them.
Mask’s Attack on Trust
Mask’s methods of attacking trust make it a monster. Stuxnet, like 27% of Android malware, used stolen certificates today, to enable its attack. SpyEye, Zeus, and over 800 other Trojans are known to steal keys and certificates. Mandiant and others have well documented the use of self-signed certificates and SSLin enabling the APT1 group to exfiltrate stolen intellectual property. What makes Mask so special is that it uses all of these methods, improves on them, and adds new innovations. It’s a perfected weapon.
Evading Detection With Trusted Status
As reported by Kaspersky, Mask’s Windows malware was digitally signed with a valid certificate. Just like the hundreds of certificates used in malware attacks tracked by the CCSS Forum, the valid certificates enabled the malicious code to run trusted.
Like some other attacks using certificates, Mask’s certificate are believed to have been purchased legally from VeriSign by representing a fictitious company TecSystem Ltd of Bulgaria. Once again, Gartner’s prophetic statement on the state of IT security and certificate comes true: “Certificates can no longer be blindly trusted.”
What makes Mask so devastating now and for years to come is its hunger for stealing keys and certificates. SSL keys and certificates, SSH keys, disk encryption keys, and others have all been stolen. Even more troubling is that Mask’s malware not only ran on Windows but also on Linux, Mac OS, and likely mobile platforms. The theft of both server, administrator, user, and device keys and certificates for everything from SSL for websites, to administrator access to servers with SSH, to VPN access from a remote site places the breached in jeopardy now and a troubling sign for everyone else of what’s to come.
The theft of so many keys and certificates is what’s likely to make Mask remembered for many years to come. Just as Stuxnet signaled to the cybercriminal community the benefits of using stolen certificates, Mask will signal the power in stealing as many kinds of keys and certificates that establish trust as possible. While a SSL key might be replaced and certificates will expire, SSH keys never expire. They will exist as a perpetual vulnerability until they are replaced and no longer trusted. SSH key rotation is something that few, if any, enterprises actually do. As more cybercriminals learn from Mask and accelerate the theft of keys and certificates, the less trust we’ll have in everything from servers, to clouds, to mobile devices.
Changing what’s trusted
If not troubling enough, Kasperky’s research has identified even more powerful capabilities in Mask’s toolset. Mask’s command set indicates that the malware could add and delete certificates to a system. This allows the attackers to set what certificates or Certificate Authorities could be trusted. These methods have been seen in the wild already going back to 2010 just as the Mask operation was gearing up. Changing what websites and software that’s trusted is a powerful weapon. Not only does it allow users and security systems alike to be tricked in to connecting to fake websites or running malicious software, it allows the encrypted communications to be decrypted.
Surveillance and monitoring today and well in to the future
Mask is also able to monitor and potentially capture network traffic. Kaspersky reports that multiple plugin modules are capable of intercepting network traffic. With stolen keys and certificates, Mask’s operators may have been able to easily monitor encrypted communications thought to be private and secure. Unfortunately, even with Mask’s known, active operations shutdown, the attacker will still be able to decrypt network communications that can be intercepted.
Escaping detection: flying under the radar with encryption
The Mask operator’s understood that exfiltrating data can be risky business and raise alarms. However, using encrypted traffic allowed Mask to keep its activities under the radar of detection. Kaspersky reports that Mask’s team used various methods including encrypting communications directly with RC-4 and also could use HTTPS. While the increased use of SSL/TLS to keep communications private is one of the reasons the BBC declared “2014: The Year of Encryption,” it also means attackers will be able to hide easier. The use of SSL and other encrypted traffic is a sign of things to come. Gartner predicts that by 2017, over 50% of all network attacks will use encryption.
The targets for Mask’s operation are reported to include government agencies, foreign-service operations, energy, oil, and gas companies, and private equity. Targets have been identified in Brazil, UK, and United States with Kaspersky’s analysis finding Spain, France, and Morocco among the most commonly targeted in terms of IP addresses and victim IDs.
With such powerful weaponry either enabled by or designed to attack trust established by keys and certificates, it appears at least one of the attacker’s intentions is to impersonate, surveil, collect, and decrypt its targets’ communications and data. And, the attackers intended to keep it that way for a long time to come. Stealing keys and certificates provides permanent access to data or systems until keys are replaced. Unfortunately, this will be years for most attacked organizations. And even worse, SSH keys never expire and will provide Mask’s attackers near perpetual root-level access inside of breached organization.
Immediate Action: Fight Back or Be Owned
For organizations attacked by Mask, action must immediately be taken to respond and remediate the attacks on trust established by keys and certificates. Breached organizations must identify all keys and certificates on networks, in servers, on endpoints, and on mobile devices. Remediation can then proceed to generate new SSL keys and certificates, generate new VPN keys and certificates, and generate new SSH keys and removing previously trusted keys from authorized key lists. However, only with complete intelligence on all keys and certificate can remediation be considered successful.
For all other organizations, Mask is another warning that demonstrates the devastating impact attacks on keys and certificates can have. Organizations must have the ability to identify all keys and certificates, enforce a known good state, detect anomalies, and respond and remediate incidents. Organizations will then be able to change keys and certificates frequently, eliminate human intervention that can open the door for malware to steal keys and certificates, and be able to respond immediately.
March 5, 2014 | Leave a Comment
By Gavin Hill, Director of Product Marketing and Threat Research, Venafi
Before the Snowden breach, the average person rarely thought about encryption. Last year, however, encryption was at the forefront of everyone’s mind. People wanted to know what Edward Snowden disclosed about the National Security Agency (NSA) PRISM, how they could avoid being spied on, and how Snowden was able to compromise what’s believed to be one of the most secure networks in the world. Although not everyone has been paying attention, keys and certificates have actually been at the center of news for the last few years. Adversaries and insiders have long known how to abuse the trust established by keys and certificates and use them as the next attack vector.
One of the first projects I worked on this year with the Ponemon Institute was to understand how organizations are protecting themselves from a Snowden-like breach, resulting from vulnerabilities related to Secure Shell (SSH) keys. The research spanned four regions, which included responses from over 1800 large enterprises that ranged from 1000 to over 75’000 employees. What was very evident from the research is that most organizations are inadequately prepared for or incapable of detecting a security incident related to the compromise or misuse of SSH keys. Some chilling results:
- 51% of organizations have already been compromised via SSH
- 60% cannot detect new SSH keys on their networks or rely on administrators to report new keys
- 74% have no SSH policies or are manually enforcing their SSH policies
- 54% of organizations using scripted solutions to find new SSH keys were still compromised by rogue SSH keys on their networks in the last 24 months
- Global financial impact from one SSH-related security incident was between US $100,000 to $500,000 per organization
Operational versus vulnerability view
More than half (53%) of organizations surveyed lack the ability to define and enforce SSH policies from a central view. As a result, they typically rely on individual teams or application administrators to secure their own keys. Because these organizations do not have visibility into how SSH keys are used within the enterprise network, detecting any security incident related to the misuse of SSH keys is very difficult. Organizations that view SSH key security as an operational problem are clearly missing the point: keys and certificates are fast becoming one of cyber-criminals’ preferred attack vectors because of the trust status they provide.
74% have inadequate SSH security policies
74% of organizations either have no SSH policies or are manually enforcing an SSH policies. Using the latest GitHub exposure of more than 600 SSH private keys as an example of application administrator behavior, you can see just how well manual processes are enforced—they’re not. If you are not familiar with this example, enhancements to the GitHub search functionality inadvertently exposed hundreds of application administrators’ private keys that had been stored in GitHub, many by simple mistake. You cannot rely on manual processes to secure and protect SSH keys; mistakes are inevitable.
51% are already compromised
Last year the Ponemon Institute published the 2013 Annual Cost of Failed Trust Report. In this report, the most alarming key and certificate management threat was SSH. In the SSH research conducted in 2014, Ponemon Institute found that 51% of organizations across four regions had a security incident related to the compromise or misuse of SSH keys. More alarming is that 50% of the compromised organizations used homegrown scripted solutions to manage SSH keys. This clearly shows that scripted solutions cannot detect the anomalous usage of SSH keys or rogue SSH keys used nefariously. Moreover, 60% of organizations surveyed rely on application administrators to manually detect rogue SSH keys.
A never-ending nightmare
As the research suggests, organizations have limited visibility into how SSH keys are used in the enterprise network and no ability to apply policies to SSH keys. However, you would think that even organizations using manual, disparate SSH key management would provide guidelines for rotating SSH keys. After all, SSH keys have no expiration date. According to Ponemon Institute research, 50% of organizations do not have an SSH key rotation plan in place. At Venafi we’ve encountered a number of organizations that have SSH keys assigned to ex-employees on critical servers, and these ex-employees left the organization more than five years ago. Considering that SSH bypasses host-based controls and provides elevated privileges, every organization should make rotating keys a priority!
Time to respond
When asked how quickly their organization could identify and respond to a security incident related to compromised or misused SSH keys, nearly half (45%) of the respondents could mitigate the threat in one day or more. The length of time it takes to respond to a security incident, directly increases the financial burden organizations need to bear from the security incident. The financial impact for United Kingdom, Germany, and Australia ranged from US $100,000 to $250,000. US-based organizations were more significantly impacted, ranging from US $500,000 to $1000,000.
By using a stolen SSH private key, an adversary can gain rogue root access to enterprise networks and bypass all the security controls. Because organizations have no policies, visibility into SSH vulnerabilities, or ability to respond to an SSH-related attack, cyber-criminals are turning to SSH as an attack vector at an ever-increasing rate. Every organization needs to stop viewing SSH keys and the management thereof as an operational matter that can be resolved with a few simple discovery scripts or relying on individual application administrators to self-govern. You wouldn’t do that with domain credentials, so why treat SSH keys—which enable elevated root privilege—any differently?
Every organization needs to have central visibility into the entire SSH key inventory, understand how SSH keys are used on the enterprise network, and apply SSH policies. Only then will an organization be able to quickly detect security incidents related to SSH and immediately remediate them.
Want to learn more about SSH vulnerabilities? Download the Ponemon 2014 SSH Security Vulnerability Report Infographic now.
March 4, 2014 | Leave a Comment
By Gavin Hill
Global organizations are under attack, and the attackers are more dangerous and persistent than ever. While the motivations vary, the goal of today’s cybercriminal is to become and remain trusted on targeted networks in order to gain full access to sensitive, regulated and valuable data and intellectual property, and circumvent existing controls.
Among the fundamental security controls enterprises rely on to protect data and ensure trust is secure shell (SSH). Yet, according to new research by the Ponemon Institute, system and application administrators—not IT security—are responsible for securing and protecting SSH keys, which exposes critical security vulnerabilities.
The research also found nearly half of all enterprises never rotate or change SSH keys. This makes their networks, servers, and cloud systems owned by the malicious actors in perpetuity when SSH keys are stolen, and represents IT’s dirty little secret, which leaves known and open back doors for cyber-criminals to compromise networks.
Data loss prevention, advanced threat detection solutions and next-generation firewalls cannot consume SSH encrypted traffic, making it easy for adversaries to steal information—over extended periods—without detection. And unlike digital certificates, SSH keys never expire, leaving the vulnerabilities and figurative back doors open indefinably.
This exclusive new infographic provides you with the analysis needed to understand the breach and how it could impact you and your organization.