In 2013, a mysterious group of hackers that calls itself the Shadow Brokers stole a few disks full of NSA secrets. Since last summer, they've been dumping these secrets on the Internet. They have publicly embarrassed the NSA and damaged its intelligence-gathering capabilities, while at the same time have put sophisticated cyberweapons in the hands of anyone who wants them. They have exposed major vulnerabilities in Cisco routers, Microsoft Windows, and Linux mail servers, forcing those companies and their customers to scramble. And they gave the authors of the WannaCry ransomware the exploit they needed to infect hundreds of thousands of computer worldwide this month.

After the WannaCry outbreak, the Shadow Brokers threatened to release more NSA secrets every month, giving cybercriminals and other governments worldwide even more exploits and hacking tools.

Who are these guys? And how did they steal this information? The short answer is: we don't know. But we can make some educated guesses based on the material they've published.

The Shadow Brokers suddenly appeared last August, when they published a series of hacking tools and computer exploits­ -- vulnerabilities in common software -- ­from the NSA. The material was from autumn 2013, and seems to have been collected from an external NSA staging server, a machine that is owned, leased, or otherwise controlled by the US, but with no connection to the agency. NSA hackers find obscure corners of the Internet to hide the tools they need as they go about their work, and it seems the Shadow Brokers successfully hacked one of those caches.

In total, the group has published four sets of NSA material: a set of exploits and hacking tools against routers, the devices that direct data throughout computer networks; a similar collection against mail servers; another collection against Microsoft Windows; and a working directory of an NSA analyst breaking into the SWIFT banking network. Looking at the time stamps on the files and other material, they all come from around 2013. The Windows attack tools, published last month, might be a year or so older, based on which versions of Windows the tools support.

The releases are so different that they're almost certainly from multiple sources at the NSA. The SWIFT files seem to come from an internal NSA computer, albeit one connected to the Internet. The Microsoft files seem different, too; they don't have the same identifying information that the router and mail server files do. The Shadow Brokers have released all the material unredacted, without the care journalists took with the Snowden documents or even the care WikiLeaks has taken with the CIA secrets it's publishing. They also posted anonymous messages in bad English but with American cultural references.

Given all of this, I don't think the agent responsible is a whistleblower. While possible, it seems like a whistleblower wouldn't sit on attack tools for three years before publishing. They would act more like Edward Snowden or Chelsea Manning, collecting for a time and then publishing immediately­ -- and publishing documents that discuss what the US is doing to whom. That's not what we're seeing here; it's simply a bunch of exploit code, which doesn't have the political or ethical implications that a whistleblower would want to highlight. The SWIFT documents are records of an NSA operation, and the other posted files demonstrate that the NSA is hoarding vulnerabilities for attack rather than helping fix them and improve all of our security.

I also don't think that it's random hackers who stumbled on these tools and are just trying to harm the NSA or the US. Again, the three-year wait makes no sense. These documents and tools are cyber-Kryptonite; anyone who is secretly hoarding them is in danger from half the intelligence agencies in the world. Additionally, the publication schedule doesn't make sense for the leakers to be cybercriminals. Criminals would use the hacking tools for themselves, incorporating the exploits into worms and viruses, and generally profiting from the theft.

That leaves a nation state. Whoever got this information years before and is leaking it now has to be both capable of hacking the NSA and willing to publish it all. Countries like Israel and France are capable, but would never publish, because they wouldn't want to incur the wrath of the US. Country like North Korea or Iran probably aren't capable. (Additionally, North Korea is suspected of being behind WannaCry, which was written after the Shadow Brokers released that vulnerability to the public.) As I've written previously, the obvious list of countries who fit my two criteria is small: Russia, China, and­ -- I'm out of ideas. And China is currently trying to make nice with the US.

It was generally believed last August, when the first documents were released and before it became politically controversial to say so, that the Russians were behind the leak, and that it was a warning message to President Barack Obama not to retaliate for the Democratic National Committee hacks. Edward Snowden guessed Russia, too. But the problem with the Russia theory is, why? These leaked tools are much more valuable if kept secret. Russia could use the knowledge to detect NSA hacking in its own country and to attack other countries. By publishing the tools, the Shadow Brokers are signaling that they don't care if the US knows the tools were stolen.

Sure, there's a chance the attackers knew that the US knew that the attackers knew -- ­and round and round we go. But the "we don't give a damn" nature of the releases points to an attacker who isn't thinking strategically: a lone hacker or hacking group, which clashes with the nation-state theory.

This is all speculation on my part, based on discussion with others who don't have access to the classified forensic and intelligence analysis. Inside the NSA, they have a lot more information. Many of the files published include operational notes and identifying information. NSA researchers know exactly which servers were compromised, and through that know what other information the attackers would have access to. As with the Snowden documents, though, they only know what the attackers could have taken and not what they did take. But they did alert Microsoft about the Windows vulnerability the Shadow Brokers released months in advance. Did they have eavesdropping capability inside whoever stole the files, as they claimed to when the Russians attacked the State Department? We have no idea.

So, how did the Shadow Brokers do it? Did someone inside the NSA accidentally mount the wrong server on some external network? That's possible, but seems very unlikely for the organization to make that kind of rookie mistake. Did someone hack the NSA itself? Could there be a mole inside the NSA?

If it is a mole, my guess is that the person was arrested before the Shadow Brokers released anything. No country would burn a mole working for it by publishing what that person delivered while he or she was still in danger. Intelligence agencies know that if they betray a source this severely, they'll never get another one.

That points to two possibilities. The first is that the files came from Hal Martin. He's the NSA contractor who was arrested in August for hoarding agency secrets in his house for two years. He can't be the publisher, because the Shadow Brokers are in business even though he is in prison. But maybe the leaker got the documents from his stash, either because Martin gave the documents to them or because he himself was hacked. The dates line up, so it's theoretically possible. There's nothing in the public indictment against Martin that speaks to his selling secrets to a foreign power, but that's just the sort of thing that would be left out. It's not needed for a conviction.

If the source of the documents is Hal Martin, then we can speculate that a random hacker did in fact stumble on it -- ­no need for nation-state cyberattack skills.

The other option is a mysterious second NSA leaker of cyberattack tools. Could this be the person who stole the NSA documents and passed them on to someone else? The only time I have ever heard about this was from a Washington Post story about Martin:

There was a second, previously undisclosed breach of cybertools, discovered in the summer of 2015, which was also carried out by a TAO employee [a worker in the Office of Tailored Access Operations], one official said. That individual also has been arrested, but his case has not been made public. The individual is not thought to have shared the material with another country, the official said.

Of course, "not thought to have" is not the same as not having done so.

It is interesting that there have been no public arrests of anyone in connection with these hacks. If the NSA knows where the files came from, it knows who had access to them -- ­and it's long since questioned everyone involved and should know if someone deliberately or accidentally lost control of them. I know that many people, both inside the government and out, think there is some sort of domestic involvement; things may be more complicated than I realize.

It's also not over. Last week, the Shadow Brokers were back, with a rambling and taunting message announcing a "Data Dump of the Month" service. They're offering to sell unreleased NSA attack tools­ -- something they also tried last August­ -- with the threat to publish them if no one pays. The group has made good on their previous boasts: In the coming months, we might see new exploits against web browsers, networking equipment, smartphones, and operating systems -- Windows in particular. Even scarier, they're threatening to release raw NSA intercepts: data from the SWIFT network and banks, and "compromised data from Russian, Chinese, Iranian, or North Korean nukes and missile programs."

Whoever the Shadow Brokers are, however they stole these disks full of NSA secrets, and for whatever reason they're releasing them, it's going to be a long summer inside of Fort Meade­ -- as it will be for the rest of us.

This essay previously appeared in the Atlantic, and is an update of this essay from Lawfare.

from Schneier on Security http://ift.tt/2qBIqnl

After the discovery and the fixing of a “crazy bad” remote code execution flaw in the Microsoft Malware Protection Engine earlier this month, now comes another MMPE security update that plugs eight flaws that could lead to either remote code execution or to denial of service.

Given that the Microsoft Malware Protection Engine powers a number of Microsoft antimalware software, DoS vulnerabilities should be considered serious, since a successfully exploited vulnerability could prevent the MMPE from monitoring affected systems until the service is restarted.

Microsoft Malware Protection Engine flaws

All these vulnerabilities – CVE-2017-8535, CVE-2017-8536, CVE-2017-8537, CVE-2017-8538, CVE-2017-8539, CVE-2017-8540, CVE-2017-8541, CVE-2017-8542 – have been flagged by Google Project Zero researcher Mateusz Jurczyk, and were discovered through fuzzing.

No specific details were offered about them, except that they can be triggered by a specially crafted file that has to be scanned by an affected version of the MMPE in order for the exploit to work.

Such a file could be offered for download on a website, or delivered via email or instant message. “In addition, an attacker could take advantage of websites that accept or host user-provided content, to upload a specially crafted file to a shared location that is scanned by the Malware Protection Engine running on the hosting server,” Microsoft noted.

The security issues have been fixed in version 1.1.13804.0 of the Microsoft Malware Protection Engine.

The newest version of the engine is usually automatically downloaded and implemented by the security software that uses it.

Still, users who would like to verify whether the latest version of the MMPE and definition updates are being actively downloaded and installed for their Microsoft antimalware products can do so by clicking on the software’s Help tab, then choosing the “About [that specific software]” option.

from Help Net Security http://ift.tt/2s9vgA4

Welcome back after the holiday weekend! Get yourself up to date with everything we've written in the last seven days - it's weekly roundup time.
from Naked Security http://ift.tt/2rzKjWr

A vulnerability in the free, open source FreeRADIUS server could be exploited by remote attackers to bypass authentication via PEAP or TTLS.

There is currently no indication that the flaw is being exploited in the wild, but as the existence of the flaw has been made public, the likelihood of attacks rises.

The good news is the FreeRADIUS Development Team has plugged the hole in version 3.0.14 of the FreeRADIUS suite (pushed out on Friday), and administrators are advised to upgrade their installation as soon as possible.

About FreeRADIUS

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users who connect and use a network service.

FreeRADIUS the most widely deployed RADIUS server in the world, as it serves as a basis for many commercial RADIUS products and services. It is used widely by big companies, telecoms, ISP, and in the academic community, to manage access to the Internet and a variety of networks.

About the FreeRADIUS authentication bypass vulnerability

“The implementation of TTLS and PEAP in FreeRADIUS skips inner authentication when it handles a resumed TLS connection. This is a feature but there is a critical catch: the server must never allow resumption of a TLS session until its initial connection gets to the point where inner authentication has been finished successfully,” it is explained in the advisory.

“Unfortunately, affected versions of FreeRADIUS fail to reliably prevent resumption of unauthenticated sessions unless the TLS session cache is disabled completely and allow an attacker (e.g. a malicious supplicant) to elicit EAP Success without sending any valid credentials.”

The vulnerability, designated CVE-2017-9148, was first flagged at the beginning of the year by Stefan Winter of the RESTENA Foundation. A fix that was pushed out in February turned out to be incomplete, and the flaw was rediscovered by Luboš Pavlíček of the University of Economics, Prague, in late April. It is now finally fixed.

The problem exists in the TLS session cache, so if upgrading is impossible, admins can disable TLS session caching to temporarily mitigate the risk.

“We believe that this issue affects all versions of FreeRADIUS which use EAP methods based on EAP-TLS,” the Development Team noted.

“We remind users that versions 1.0.x, 1.1.x, 2.0.x, 2.1.x, and 2.2.x are old and unsupported. Patches for those versions will not be released, as the issue can be corrected with a minor configuration change. We also note that prior to version 3, the session cache was disabled by default, and required administrator intervention to enable it.”

from Help Net Security http://ift.tt/2rixEGK

Due to their computing power, quantum computers have the disruptive potential to break various currently used encryption algorithms. Infineon Technologies has successfully demonstrated the first post-quantum cryptography implementation on a commercially available contactless security chip, as used for electronic ID documents.

Quantum computer attacks on today’s cryptography are expected to become reality within the next 15 to 20 years. Once available, quantum computers could solve certain calculations much faster than today’s computers, threatening even best currently known security algorithms such as RSA and ECC.

Various internet standards like Transport Layer Security (TLS), S/MIME or PGP/ GPG use cryptography based on RSA or ECC to protect data communication with smart cards, computers, servers or industrial control systems. Online banking on “https” sites or “instant messaging” encryption on mobile phones are well-known examples.

Chip memory size and computation time are key

Infineon security experts and the Center of Excellence for contactless technologies in Graz, Austria, made a breakthrough in this field. They implemented a post-quantum key exchange scheme on a commercially available contactless smart card chip. Key exchange schemes are used to establish an encrypted channel between two parties.

The deployed algorithm is a variant of “New Hope”, a quantum-resistant cryptosystem also explored successfully by Google on a development version of the Chrome browser.

“The phantom of the quantum computer is keeping academia and the IT industry on high alert,” said Thomas Pöppelmann from Infineon’s Chip Card & Security Division, who has been co-developing the New Hope algorithm. “At Infineon, we are proud to be the first to transfer PQC onto contactless smart cards. Our challenges comprised the small chip size and limited memory capacity to store and execute such a complex algorithm as well as the transaction speed.” Thomas Pöppelmann and his co-researchers received the Facebook Internet Defense Prize 2016 for the development of New Hope.

In a world of quantum computers, post-quantum cryptography should provide a level of security that is comparable with what RSA and ECC provide today in the classical computing world. However, to withstand quantum calculation power, key lengths need to be longer than the usual 2048 bits of RSA or the 256 bits of ECC. Nevertheless, researchers were able to implement New Hope on a commercially available security chip without requiring additional memory space and hence a larger chip size.

Standardization bodies are expected to agree on one or multiple post-quantum cryptography algorithms within the next few years before governments and industries mandate the migration.

from Help Net Security http://ift.tt/2quycty

A new survey conducted by Vanson Bourne asked IT leaders in the U.S., UK, Germany and France about their current data policies to see how well aligned they are with the EU General Data Protection Regulation (GDPR), which comes into force on May 25, 2018.

The survey of 500 IT decision makers did not name GDPR in its questions, but asked about areas of policy that would be impacted by the regulation. It found 54% could not say all personally identifiable information was protected through anonymization and encryption in all digital locations. This alone could mean companies do not meet the “appropriate level of security” requirement specified in Article 32 of the regulation.

Data breaches

In terms of protecting EU citizens from data breaches, the survey found companies do not currently have the processes or technology in place to adequately meet GDPR requirements around data breaches:

• Only 52% of all of the companies surveyed are completely confident that they can report data breaches within 72 hours of discovery to the authorities. Yet, only 55% are “completely confident” they have systems that could identify a breach from an external source, suggesting that a customer’s personal identifiable information could be traded unbeknown to the company or citizen, placing both at greater risk of fraud.
• Companies also admitted they cannot easily identify the data obtained in a breach. Less than half (46%) are completely confident that they could precisely identify the data that had been exposed in a breach.

Working with personal data

GDPR regulations also state that “appropriate technical and organizational measures” should be in place to safeguard personal data and minimize data collection, processing and storage. Asked about key areas of data processing, several weaknesses were identified that could leave companies at risk, if not addressed:

• Only 41% of companies could say that data is automatically geo-fenced “every time” on servers, so it cannot be moved outside of the legal jurisdiction in which it resides.
• Just 48% of all business partners’ storage locations’ security standards are audited by companies.
• 54% of companies check on every occasion whether a customer has given permission for records to move between data processors, such as suppliers and business partners, before moving data.
• Just over a third (37%) of companies claim to have processes that allow them to remove data without delay from live systems and backups. Articles 16 and 17 of the EU GDPR specify the companies must be able to respond to citizen demands for the rectification or erasure or data in one month. 15% are currently building the systems that will give them this functionality.

“The findings show that companies have some way to go over the next 12 months if they are to ensure compliance, and must focus on some security fundamentals such as implementing encryption and data lifecycle protection technology. Compliance is not just a matter of avoiding fines; consumers care deeply about the abuse and loss of their data. The reputational damage from non-compliance can far outweigh the €20 million or 4% of global revenue fine that a company could receive. There is still time to get the technology and processes and place, but complacency is not an option,” said Mark Hickman, COO at WinMagic.

from Help Net Security http://ift.tt/2quoFCX

67% of medical device manufacturers and 56% of healthcare delivery organizations (HDOs) believe an attack on a medical device built or in use by their organizations is likely to occur over the next 12 months.

According to the results of a recent survey, roughly one third of device makers and HDOs are aware of potential adverse effects to patients due to an insecure medical device, but despite the risk only 17 percent of device makers and 15 percent of HDOs are taking significant steps to prevent such attacks.

The study was conducted by the Ponemon Institute, and focused on the North America market. The study surveyed approximately 550 individuals from manufacturers and HDOs, whose roles involve the security of medical devices, including implantable devices, radiation equipment, diagnostic and monitoring equipment, robots, as well as networking equipment designed specifically for medical devices and mobile medical apps.

Other key findings from the study highlight:

• Building secure devices is challenging. 80 percent of device makers and HDOs report that medical devices are very difficult to secure. The top reasons cited for why devices remain vulnerable include accidental coding errors, lack of knowledge/training on secure coding practices and pressure on development teams to meet product deadlines.
• Lack of security testing. Only 9 percent of manufacturers and 5 percent of HDOs say they test medical devices at least once a year, while 53 percent of HDOs and 43 percent of manufacturers do not test devices at all.
• Lack of accountability. While 41 percent of HDOs believe they are primarily responsible for the security of medical devices, almost one-third of both device makers and HDOs say no one person or function in their organizations is primarily responsible.
• FDA guidance is not enough. Only 51 percent of device makers and 44 percent of HDOs follow current FDA guidance to mitigate or reduce inherent security risks in medical devices.

“These findings underscore the cybersecurity gaps that the healthcare industry desperately needs to address to safeguard the well-being of patients in an increasingly connected and software-driven world,” said Mike Ahmadi, global director of critical systems security for Synopsys’ Software Integrity Group.

“The industry needs to undergo a fundamental shift, building security into the software development lifecycle and across the software supply chain to ensure medical devices are not only safe, but also secure.”

from Help Net Security http://ift.tt/2qwqICl