STE WILLIAMS

Mirai Evolves From IoT Devices to Linux Servers

Netscout says it has observed at least one dozen Mirai variants attempting to exploit a recently disclosed flaw in Hadoop YARN on Intel servers.

Researchers from Netscout Alert have discovered what they believe are the first non-IoT versions of Mirai malware in the wild.

The new versions are very similar in behavior to the original version of Mirai written for Internet of Things devices, but they are tailored to run on Linux servers instead. Unlike the original Mirai, the new versions do not try and propagate in a worm-like fashion. Instead, attackers are delivering them via exploits in a more targeted manner.

Netscout researchers say they have observed what appears to be a relatively small number of threat actors attempting to deliver the malware on Linux servers by exploiting a recently disclosed vulnerability in Hadoop YARN. The YARN vulnerability is a command injection flaw that gives attackers a way to remotely execute arbitrary shell commands on a vulnerable server. Many of the servers running Hadoop YARN are x86-based.

Netscout has been tracking attempts to exploit the flaw using its global network of honeypots. It says it has observed tens of thousands of exploit attempts daily. In November alone, Netscout observed attackers attempting to deliver some 225 unique malicious payloads via the Hadoop YARN vulnerability.

Of that, at least one dozen of the malware samples were Mirai variants. One was a variant that labeled itself as VPNFilter, though it had nothing to do with the destructive VPNFilter bot that infected more than a half-million small and home office routers earlier this year, the security vendor said.

Unlike typical Mirai IoT variants, which first try and determine a victim machine’s CPU architecture to deliver a suitable executable, the Mirai variant that Netscout inspected recently only delivers the x86 variant of the bot. “This version assumes the Hadoop YARN service is running on a commodity x86 Linux server,” Netscout says in its report. “Once gaining a foothold, Mirai on a Linux server behaves much like an IoT bot and begins brute-forcing telnet usernames and passwords.”  

Matthew Bing, a security research analyst at Netscout, says the main takeaway for organizations is that threat actors who were once focused on exploiting IoT devices are now also targeting vulnerable Linux servers with the same types of bots. “Servers make an attractive target for DDoS bots for their network speed and hardware resources, compared to relatively underpowered IoT devices,” Bing says.

The sources that are launching the attacks appear to be operating across a variety of different countries and networks with little overlap between them. “That suggests this is the work of at least a few groups or individuals,” he says.

Related Content:

 

Black Hat Europe returns to London Dec 3-6 2018  with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/mirai-evolves-from-iot-devices-to-linux-servers/d/d-id/1333329?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Hackers erase 6,500 sites from the Dark Web in one attack

One of the most popular Dark Web hosting services – Daniel’s Hosting – was slaughtered last week when attackers hosed it clean of about 6,500 hidden services. The admin says they’re gone for good: he hasn’t even figured out where the vulnerability is yet.

The administrator at Daniel’s Hosting is a German software developer named Daniel Winzen, who acknowledged the attack on the hosting provider’s portal. Winzen said that it happened on Thursday night, a day after a PHP zero-day exploit was leaked.

The service will likely be back in December, he said, but even the “root” account has been deleted, and all the data on those 6,500 sites are toast:

There is no way to recover from this breach, all data is gone. I will re-enable the service once the vulnerability has been found, but right now I first need to find it.

Backups? Forget it. This is the Dark Web. Winzen told ZDNet that there ain’t no such thing as backups on Daniel’s Hosting, by design:

Unfortunately, all data is lost and per design, there are no backups.

As of last week, Winzen said his priority was to do a full analysis of the log files. He had determined that the attacker(s) had gained administrative database rights, but it’s looking like they didn’t get full system access. Some accounts and files that weren’t part of the hosting setup were left “untouched,” he said.

Other than the root account, no accounts unrelated to the hosting were touched and unrelated files in /home/ weren’t touched either. As of now there is no indication of further system access and I would classify this as a “database only” breach, with no direct access to the system. From the logs it is evident that both, adminer and phpmyadmin have been used to run queries on the database.

Who cares?

According to Dark Owl, when the attacker(s) took out Daniel’s Hosting, they erased over 30% of the operational and active hidden services across Tor and the Invisible Internet Project (I2P) – an anonymous network layer that allows for censorship-resistant, peer-to-peer communication. ZDNet’s Catalin Cimpanu tweeted on Monday night that this pretty much matched his own calculations.

The attacker(s) also deleted over six million documents that DarkOwl – a provider of darknet content and tools, as well as cybersecurity defenses – had archived on the Dark Net.

This is what the world lost when Daniel’s Hosting went belly-up, Dark Owl says:

  • 657 of the hidden services had the title “Site Hosted by Daniel’s Hosting Service” and little else (but may have been used for something other than serving web content).
  • Most (over 4900) were in English, 54 were in Russian and two of the oldest were in Portuguese.
  • 457 of the hidden services contain content related to hacking and/or malware development.
  • 304 have been classified as forums.
  • 148 of them are chatrooms.
  • 136 include drug-specific keywords.
  • 109 contain counterfeit-related content.
  • 54 specifically mention carding-specific information.
  • Over 20 contain content including weapons and explosive-related keywords.

For better or worse, the takedown of Daniel’s Hosting means that a “pillar of the darknet community” that’s served up a chatroom and online-link list for years, free of charge, has been demolished, Dark Owl says.

For example, his online-link list is referenced by nearly 500 other hidden services, making it the second most commonly referred to directory listing (behind Fresh Onions) and providing a foundational starting point for new users navigating Tor.

Dark Owl has some theories about who could have been behind the attack. It could have been Russian hackers, who’ve recently outlined the technical details of exploiting PHP’s imap_open() function to extract password hashes for privileged accounts, as an alternative to brute-force mining.

Then again, it could have been anybody who’s against easy posting and sharing of child abuse images. Dark Owl reports that Winzen, back in 2016, made life easier for people to share such images on Tor without potentially exposing their identities:

As a result, Daniel’s LE-Chat code became a popular platform for the darknet pedophilia community, and the home for many well-known Child Pornography sharing chatrooms such as Tabooless, Camp Fire, and Child Priori.

There are also theories about the portal being taken down by law enforcement. For one thing, a chatroom, Daniel’s Chat, quietly resurfaced on Saturday, but it lacked the member database and credentials that had enabled users to verify chat participants’ identities.

Or perhaps Daniel had been arrested, and it’s not even really him who’s posting on the site and sending email to news outlets? As it is, the providers’ hidden services experienced what Dark Owl said was “extreme” distributed denial of service (DDoS) attacks leading up to the attack, “similar to other law enforcement-led darknet seizure operations.”

Those are just some of the theories.

The attack shows how surprisingly centralised the Dark Web really is, and that there are no ironclad promises that its potent anonymity features will shield you.

Whether it’s law enforcement catching drug dealers with a fake Bitcoin exchange or simple misconfigurations that expose server IP addresses, you have to take heed: just because you’re using Tor doesn’t necessarily mean you’re safe, whether you’re a criminal or somebody seeking anonymity for noncriminal reasons.

There are many ways to get busted on the dark web.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/3bbbq5vsaF8/

Big breach, Creep-O-Meter and Black Friday [PODCAST]

This week on the podcast: musings about keyloggers and the Vision Direct data breach; a holiday gift guide Creep-O-Meter; and the dangers of Black Friday for online shoppers (and every other day of the year)!

With Paul Ducklin, Anna Brading, and Mark Stockley.

If you enjoy the podcast, please share it with other people interested in cybersecurity, and give us a vote on iTunes and other podcasting directories.

Listen and rate via iTunes...
Sophos podcasts on Soundcloud...
RSS feed of Sophos podcasts...


Thanks to Purple Planet Music for the opening and closing music.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/ZNNM4VO6ixQ/

Microsoft’s MFA is so strong, it locked out users for 8 hours

On 19 November at 04:39 UTC (23:39 EST), Microsoft Office 365 and Azure Active Directory users started reporting that they were unable to access the multi-factor authentication (MFA) system or reset passwords, locking them out of their accounts.

When Microsoft’s cloud authentication is working correctly, users should be able to authenticate their username and password credentials via text message, phone call, app verification code, or push request.

This, it turned out, was no mere hiccup, with problems for users across Europe, Asia-Pacific and the Americas continuing for at least eight hours – a long time for users to be unable to log into such an important business platform.

Microsoft eventually offered an explanation:

Preliminary root cause: A recent update to the MFA service introduced a coding issue that prevented users from being able to sign in or carry out self-service password resets when using MFA for authentication.

Twitter complaints soon rolled in on a scale ranging from annoyed to angry:

Others raised the issue of powerless admins:

Which is to say, admins couldn’t even temporarily turn off MFA for users as they were locked out by the same issue.

In theory, only organisations hosting Azure MFA on their own servers rather than through Microsoft’s infrastructure would have been unaffected by this.

Microsoft publishes advice on gaining emergency access to Azure AD accounts, including when MFA is unavailable.

It’s unclear whether this also applies when Microsoft’s own cloud authentication is not working (the documentation assumes this never happens).

What’s more, even if this is a viable workaround, implementing an emergency account comes with overheads, as the advice makes clear:

An account password for an emergency access account is usually separated into two or three parts, written on separate pieces of paper, and stored in secure, fireproof safes that are in secure, separate locations.

A memorably bad day eventually came to an end by around 21:30 UTC when MFA access returned to normal after Microsoft applied some “hotfix” medicine.

All of this matters because adopting multi-factor authentication is one of the most useful security upgrades you can make (it combats phishing, password reuse and weak passwords), but it’s one that users are already reluctant to make.

So is this a knock for the MFA cause? Maybe, but it shouldn’t be.

While it’s true that losing MFA hosted by a cloud provider as fundamental as Microsoft is bad news, the same could be said when losing access to any service, whether hosted in the cloud or not – the issue is downtime, not the merits of MFA.

MFA remains a good idea. So is having a plan B.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/KNlpzfwtmaw/

Fancy Bear hacker crew Putin dirty RATs in Word documents emailed to govt orgs – report

Russian state-backed hacking crew Fancy Bear (aka APT28) is distributing malware-riddled files with a suggested link to the recent Lion Air crash in order to dupe government workers into downloading software nasties – and has developed a new remote-access trojan called Cannon, according to Palo Alto Networks.

Researchers from the firm spotted a Word file being targeted at “several government entities around the globe” called crash list(Lion Air Boeing 737).docx. The filename refers to the recent fatal crash in October of a nearly-new Boeing 737 Max 8, Lion Air flight 610, which killed all 181 aboard in October.

“This document appeared to be targeting a government organization dealing with foreign affairs in Europe via spear-phishing. Once the user attempts to open the document, Microsoft Word immediately attempts to load [a] remote template containing a malicious macro and payload,” said Palo Alto in a report about the dodgy doc, which it pointed out did not “contain any pertinent content to the Lion Air tragedy theme seen in the filename”.

Those governmental orgs included ones located in “North America, Europe and a former USSR state”.

The remote template is downloaded from a command ‘n’ control server run by the attackers. If that server is offline, the document fails to download anything and so appears mostly innocuous. Palo Alto found that even once the user downloaded and executed the macro, nothing happened until the user closed Word, thanks to the malware author’s use of Word’s AutoClose macro function.

“The macro executes this payload in a rather interesting way by loading the dropped ~temp.docm document and calling a function within its embedded macro to run the payload,” added Palo Alto. “We believe the creator of this delivery document chose to run the payload from the dropped file as an evasion technique.”

Having downloaded a variant of the Zebrocy trojan as its payload, the malware, then maps whatever storage devices the host machine has connected, screenshots its system info and beams all that back to the C2 server.

Yup, it’s the Russians again

The Cannon trojan, identified by Palo Alto in a variation of the first payload file, carries out much the same functions as Zebrocy, though it relies on talking to email servers hosted in the Czech Republic for its command and control functions.

Summing up, Palo Alto said: “The Sofacy [APT28] threat group continues to target government organizations in the EU, US, and former Soviet states to deliver the Zebrocy tool as a payload. In these attacks, the delivery documents used to install Zebrocy used remote templates, which increases the difficulty to analyse the attack as an active C2 server is needed to obtain the macro-enabled document.”

APT28, referred to by Palo Alto in its report as Sofacy, is a Russian state-backed hacker crew that is increasingly well known by Western cybersecurity firms and state organisations. The group is active and prolific, cranking out new strains of malware that keep the infosec sector on its toes. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/11/21/apt_28_cannon_trojan_palo_alto/

Technical foul: Amazon suffers data snafu days before Black Friday, emails world+dog

Updated Amazon has suffered a data snafu just days before Black Friday – and the company was tight-lipped about whether it had notified the British data protection authorities.

Multiple Register readers forwarded us emails sent from Amazon’s UK tentacle informing them that the online sales site had “inadvertently disclosed [their] name and email address due to a technical error”.

The email from Amazon, which included an HTTP link to its website at the end, read:

Hello,

We’re contacting you to let you know that our website inadvertently disclosed your name and email address due to a technical error. The issue has been fixed. This is not a result of anything you have done, and there is no need for you to change your password or take any other action.

Sincerely, Customer Service

Amazon breach email, as seen by a reader

Amazon’s UK press office acknowledged that the email was genuine, saying only: “We have fixed the issue and informed customers who may have been impacted.”

The company did not answer our questions as to how many customers had been affected, whether it had informed the Information Commissioner’s Office, what the cause of the breach was or how or when it had been spotted.

The ICO acknowledged our phone call seeking comment but has yet to get back to us.

Meanwhile, out in the badlands of Twitter, people from across the world were wondering whether they’d been spammed or whether the email was genuine:

Alden gives his location in his Twitter profile as Phoenix, Arizona, which is in the US. Others tweeting about it include folk in the Netherlands and what appears to be South Korea. ®

Update @ 1630 GMT

After we repeatedly poked Amazon’s UK press office with a pointy stick, they eventually agreed to say that this is not a breach in the sense of a hack while maintaining that the snafu is an inadvertent technical error and that they emailed customers from an abundance of caution.

The ICO eventually got round to telling us that it’s shrugging its shoulders.

“Under the GDPR,” said the data protection regulator, “organisations must assess if a breach should be reported to the ICO, or to the equivalent supervisory body if they are not based in the UK. It is always the company’s responsibility to identify when UK citizens have been affected as part of a data breach and take steps to reduce any harm to consumers. The ICO will however continue to monitor the situation and cooperate with other supervisory authorities where required.”

Meanwhile, Amazon’s customer service department initially thought the firm’s own notification email to affected customers was a phishing attempt. A suspicious reader, wondering whether the shonky-looking email was legitimate, sent it to Amazon customer services asking whether it was real, and got the response: “The e-mail you received wasn’t from Amazon.co.uk, and we’re investigating the situation … We can’t tell how phishers came to target your e-mail address.”

Amazon customer service thinks Amazon's own email is a phishing message

Click to enlarge

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/11/21/amazon_data_breach/

3 is the magic number (of bits): Flip ’em at once and your ECC protection has been Rowhammer’d

Researchers in the Netherlands have discovered that error-correcting code (ECC) protections can be thwarted to perform Rowhammer memory manipulation attacks.

The Vrije Universiteit Amsterdam crew of Lucian Cojocar, Kaveh Razavi, Cristiano Giuffrida, and Herbert Bos today said they have developed a method to precisely alter bits in server RAM chips without triggering ECC’s correction mechanism, giving them the ability to tamper with data, inject malicious code and commands, and change access permissions so that passwords, keys, and other secrets can be lifted.

The findings are significant because ECC has long been considered a tried-and-true method for preventing Rowhammer attacks. Thus, a baddie who can leverage the team’s technique on a server to sidestep ECC, could extract information from these high-value targets using Rowhammer. Said miscreant would have to first get into a position where they can flip bits on the vulnerable machine, likely using malware already on the device.

What’s Rowhammer?

Back in 2015, Google’s Project Zero found that it was possible to alter the values of individual memory cells by repeated charging and discharging the cells in adjacent rows. If an attacker knew precisely which locations to target, they could alter specific locations to inject instructions or commands into memory or grant access to restricted portions that contain sensitive information.

ECC protection (which was developed before Rowhammer to deal with memory errors) theoretically stopped this by detecting and correcting changes to individual bit values.

The magic number

The VU Amsterdam team confirmed that the way ECC checks for errors creates an exploitable loophole: when one bit was changed, the ECC system would correct the error. When two were found, ECC would crash the program.

But if three bits could be changed simultaneously, ECC would not catch the modification. This much folks have known about, though the key thing now is that it can be shown to allow Rowhammer attacks through.

Crucially, the researchers found something akin to a race condition that would let them check that a RAM address could be usefully manipulated by the triple-flip technique.

“Simply put: it will typically take measurably longer to read from a memory location where a bitflips needs to be corrected, than it takes to read from an address where no correction was needed,” the team explained.

“Thus, we can try each bit in turn, until we find a word in which we could flip three bits that are vulnerable. The final step is then to make all three bits in the two locations different and hammer one final time, to flip all three bits in one go: mission accomplished.”

The researchers said they were able to test and recreate the vulnerability on four different server systems: three running Intel chips and one using AMD. They declined to single out any specific memory brands.

Fortunately, while the attack would be extremely difficult to prevent, it also looks to be very difficult to actually pull off in the wild. Between combing through the various addresses to find vulnerable lines and then actually carrying out the Rowhammer attacks, the VU Amsterdam team said a successful attack in a noisy system can take as long as a week.

The boffins said that their findings should not be taken as a condemnation of ECC either. Rather, it should show admins and security professionals that ECC is just one of several protection layers they should use in combination with things like optimised hardware configurations and careful logging and monitoring.

“ECC cannot stop Rowhammer attacks for all hardware combinations. If the number of bit flips is sufficiently high, ECC will only slow down the attack.”

A paper describing the technique, Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks, will be presented next year at the Symposium on Security and Privacy. The above link to their work should be valid within the next couple of days. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/11/21/rowhammer_ecc_server_protection/

2018 Hacker Kids Gift Guide

Fun gift choices that foster design thinking and coding skills in kids both young and old.PreviousNext

Image Source: Adobe

Image Source: Adobe

We’re in a golden era for teaching kids about science and programming. Gone are the days where experimentation toys are limited to potato-powered electronic kits. Security nerds and hacking experts who want to get their kids into coding and tinkering have a ton of options at their fingertips today, as niche toymakers home in on the foundational skills kids need to excel in computer science, hardware hacking, and more.

The following is a cool mix of holiday gift ideas for getting youngsters excited about hacking.

 

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full BioPreviousNext

Article source: https://www.darkreading.com/2018-hacker-kids-gift-guide/d/d-id/1333324?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

To Stockpile or Not to Stockpile Zero-Days?

As the debate rages on, there is still no simple answer to the question of whether the government should stockpile or publicly disclose zero-day vulnerabilities.

In the post-Snowden years, there has been a fair amount of discussion about the federal government’s efforts to weaken encryption standards, introduce backdoors in commercial software, and hack into commercial organizations for the purpose of data collection. High-profile efforts by federal agents to gain access to an iPhone used by the San Bernardino shooters and an ensuing, albeit short, court battle with Apple has made the encryption issue a dinnertime conversation.

What has received less attention is the government’s use and stockpiling of zero-day exploits. Until recently, the relevant discussion was mostly focused on the process surrounding the vulnerability review. A recent RAND Corporation study introduces academic research on the zero-day stockpiling versus disclosure debate.

The term “zero-day vulnerability” refers to the fact that developers have zero days to address and patch a previous undiscovered vulnerability. To take advantage of such a vulnerability, an exploit needs to be created. The government’s use of zero-day exploits has exploded over the last decade, feeding a lucrative market for defense contractors and others who uncover critical flaws in the software (and hardware), and sell information about these vulnerabilities to the government. For example, the infamous Stuxnet, a digital weapon used to attack Iran’s uranium enrichment program, used four zero-day exploits to spread.

The argument in favor of stockpiling is that the discovery of zero-days is a costly process, but when successful, gives the government an asymmetric advantage versus our adversaries, allowing for practically undetectable intelligence gathering and even the ability to disable or sabotage opponents’ infrastructure.

On the other hand, there is a chance that other parties (including our adversaries) have discovered the same zero-day and could be using it against our governmental and commercial entities. This is the argument in favor of disclosure, which allows affected vendors to patch the vulnerability.

The Disclosure Debate
Almost five years ago, in the wake of Edward Snowden’s leaks, President Obama convened a presidential advisory committee to develop a set of recommendations for how to strike a balance between protecting national security interests, advancing the administration’s foreign policy agenda, and respecting citizens’ privacy and civil liberties. The resulting 308-page report issued by the panel included 46 recommendations, including the topic of zero-day disclosure. Recommendation 30 of the report states, “US policy should generally move to ensure that zero-days are quickly blocked, so that the underlying vulnerabilities are patched on US Government and other networks.” The report continues, “In rare instances, US policy may briefly authorize using a zero-day for high priority intelligence collection, following senior, interagency review involving all appropriate departments.”

It is clear that the panel’s recommendation favors disclosure. In response, the government stated that “there is a [zero-day review] process, there is rigor in that process, and the bias is very heavily tilted toward disclosure.”

However, when in April 2014 a new vulnerability dubbed Heartbleed appeared, Bloomberg News reported that the NSA “knew for at least two years” about the flaw and “regularly used it to gather critical intelligence.” Note that the NSA has denied the allegation.

In August 2016, a group calling itself Shadow Brokers released a cache of cyber exploits almost certainly belonging to the NSA. Several were zero-days. Worryingly, these vulnerabilities were in security products produced by Cisco, Juniper, and Fortinet, among others, each widely used to protect US companies and critical infrastructure, as well as other systems worldwide. And those leaks were followed in 2017 by the zero-day leveraged in the crippling WannaCry.

So, did the government take the recommendations of the panel to heart? Should it?

US Director of National Intelligence Dan Coats compares the situation around cyberattacks targeting the United States infrastructure today to the months before September 11, 2001, noting, “Here we are nearly two decades later, and the warning lights are blinking red again.” With that in mind, it would seem that a confidential stockpile could be invaluable for conducting reconnaissance and offensive campaigns, especially against state-sponsored cyberattackers.

On the other side of the spectrum is the commentary from Joe Nye, the veteran national security scholar, who suggested “…if the United States unilaterally adopted a norm of responsible disclosure of zero-days to companies and the public after a limited period, it would destroy their value as weapons — simultaneously disarming ourselves, other countries, and criminals without ever having to negotiate a treaty or worry about verification. Other states might follow suit. In some aspect, cyber arms control could turn out to be easier than nuclear arms control.”

Stockpiling Pros Cons
The question of whether the government should stockpile or publicly disclose zero-days is a difficult one, and the answer is not a simple “yes” or “no.” Enter the RAND Corporation’s fascinating report, “Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits.” It reveals that zero-day exploits and their underlying vulnerabilities have a 6.9-year life expectancy, on average. That’s 2,521 days after the initial discovery, with 25% of those zero-days surviving for more than 9.5 years.

Not only can zero-day exploits enjoy long life spans, but when a vulnerability is discovered, it can be put to work very quickly. When it comes to the time required to create an exploit, RAND found that almost a third are developed in a week or less, with the majority being developed in approximately 22 days.

Most importantly, the report does a deep dive into the issue of stockpiling and hypothesizes that if zero-day vulnerabilities are very hard to find and/or the likelihood of stumbling across the same vulnerability that was discovered by the other party is low, then it makes sense to stockpile. The research estimates that approximately only 5.7% of zero-day vulnerabilities are discovered by an outside entity per year. Hence, the “collision” rate, or the chance of the same vulnerability being discovered independently by multiple parties, is quite low. For that reason, stockpiling rather than disclosing may be beneficial for offensively focused entities.

Still, the 2013 presidential advisory committee’s report referenced above counters RAND’s conclusion: “In almost all instances, for widely used code, it is in the national interest to eliminate software vulnerabilities rather than to use them for US intelligence collection. Eliminating the vulnerabilities — ‘patching’ them — strengthens the security of US Government, critical infrastructure, and other computer systems.”

Which part of the stockpile or disclosure debate are you on? Share your thoughts in the comments.

Related Content:

 

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Nir Gaist is a senior information security expert, ethical hacker, and a gifted individual. He started programming at age 6 and began his studies at the Israeli Technion University at age 10. Nir holds significant cybersecurity experience after serving as a security … View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/to-stockpile-or-not-to-stockpile-zero-days-/a/d-id/1333302?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Amazon Low-Key Reveals Breach of Some Customer Data

‘Technical error’ exposed names and email addresses.

Some Amazon customers have reported receiving a vague email from the company alerting them that the website had exposed their names and email addresses.

The Register first reported that some customers got this email from Amazon:

Hello,

We’re contacting you to let you know that our website inadvertently disclosed your name and email address due to a technical error. The issue has been fixed. This is not a result of anything you have done, and there is no need for you to change your password or take any other action.

Sincerely, Customer Service

The company reportedly confirmed the email, stating: “We have fixed the issue and informed customers who may have been impacted.” An Amazon spokesperson told CNBC that its website and systems were not hacked.

Read more here and here.

 

Black Hat Europe returns to London Dec 3-6 2018  with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/cloud/amazon-low-key-reveals-breach-of-some-customer-data/d/d-id/1333327?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple