Monthly Archives: August 2016

Intruders Pilfered Over 68 Million Passwords In 2012 Dropbox Breach

Intruders Pilfered Over 68 Million Passwords In 2012 Dropbox Breach

But all passwords were hashed and salted and no evidence they have been misused, company says.

Reports this week that as many as 68 million email addresses and passwords were leaked online as the result of a 2012 breach of Dropbox has grabbed wide attention for its sheer scope. But the fact that all of the passwords were hashed and salted makes the incident less severe for users than it otherwise might have been.

In a seemingly routine email, Dropbox last week said that users who had signed up for the service prior to 2012 and had not changed their password since then would be prompted to reset it when they next attempted to sign in.

It also encouraged individuals who used their Dropbox password to log into other sites to change passwords to those sites as well, and recommended that they enable two-factor authentication as an additional security measure for protecting access to their accounts.

The company described the move to proactive reset user passwords as a purely preventive measure and not because there was any indication of accounts being breached. “Our security teams are always watching out for new threats to our users,” said Patrick Heim, head of trust and security at Dropbox in the email.

As part of these efforts, the company learned about a set of email addresses, together with hashed and salted passwords, that were illegally obtained in a 2012 security incident and subsequently leaked online.

“Based on our threat monitoring and the way we secure passwords, we don’t believe that any accounts have been improperly accessed,” Heim said. In comments to Motherboard, he said Dropbox initiated the reset to ensure that passwords from prior to 2012 cannot be used to access user accounts. Motherboard, which examined the leaked data, said about half of the passwords appear to have been hashed using the bcrypt hashing function, and the rest were protected via SHA-1.

Dropbox had originally described the 2012 security incident as one in which someone had used a stolen password to access an employee account that contained a document with user email addresses. At the time, Dropbox had said the incident only involved a small number of email addresses.

This week’s sudden broadening scope of the breach triggered many familiar recommendations from security experts on what users need to be doing to mitigate fallout from breaches like this.

“This has become a common enough occurrence that people should be taking all of the most common precautions with their user accounts and passwords when using online services,” said Nathan Wenzler, principal security architect at independent security consulting firm AsTech Consulting in a statement.

Breaches like this show why it is important for users never to reuse passwords across sites and to ensure passwords are long enough and complex enough to make them difficult to guess via brute force methods.

“There’s a reason why companies have their employees change their passwords regularly. Employ the same practice for your personal accounts and credentials, too,” he said.

The breach is an important reminder why passwords alone are no longer sufficient as a form of user authentication said Ryan Disraeli, co-founder and vice president of mobile identity company TeleSign.  

“Dropbox appeared to practice good user data security protections, encrypting the passwords and updating the encryption standards.” But as the breach shows, even when good protections are used, passwords alone cannot provide enough protection, he said in a statement.

Meanwhile, DropBox’s failure so far to disclose why it took the company more than four years to discover the true scope of the breach drew criticism from some quarters.

The fact that user accounts taken in an incident in 2012 are only now coming to light is significant, said Chris Roberts, chief security architect at advanced threat detection vendor Acalvio.

It would interesting to know why Dropbox didn’t do more to determine the true scope of the 2012 intrusion until someone actually leaked the hacked accounts, he said in a statement. “It would be good to work out or understand why Dropbox didn’t put its hand up and admit the issue back in 2012.”

Related Content:


 


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

More Insights

from Dark Reading – All Stories http://ubm.io/2bTd08h
via IFTTT

More Than 40% Of Attacks Abuse SSL Encryption

More Than 40% Of Attacks Abuse SSL Encryption

New report shows risk of not inspecting encrypted packets.

There’s an important caveat about encrypted traffic from new research released this week: Encryption works so well that hackers are using it as cover.

A new study from A10 and the Ponemon Institute found that 80% of respondents say their organizations have been the victim of a cyberattack or malicious insiders in the past year — and 41% of the attacks have used encryption to evade detection. In addition, 75% say malware hidden within encrypted traffic is a risk to their organizations.

At issue: The report found that SSL encryption not only hides data from would-be hackers but also from common security tools.

“Hackers are using SSL encryption to slide by standard perimeter defenses,” says Chase Cunningham, director of cyber operations at A10 Networks.

Cunningham says companies need to start thinking about using technologies that can inspect SSL packets and quarantine the bad or malicious packets. He adds that it’s going to become even more important as organizations move encrypted data out to the cloud – companies need to know if all those encrypted packets out in the cloud are secure.

The three main reasons organizations don’t decrypt encrypted traffic, according to the report: lack of enabling security tools (47%), insufficient resources (45%), and performance degradation (45%). 

Another 53% of the respondents admit that their security solutions are collapsing under growing SSL bandwidth demands and key lengths.

Kevin Bocek, vice president of security strategy and threat intelligence at Venafi, says the A10 research validates what they’ve been saying for the past several months about the dangers lurking inside encrypted traffic. He points out three aspects to inspecting encrypted traffic.

First, companies must focus on key management for inbound traffic. Bocek says they need to know where the keys are and use automated tools that keep them regularly updated.

Second, companies need to set up a trusted authority for outbound traffic so when the system initiates a new connection, a new certificate is created. Bocek says most security tools have these kinds of capabilities.

Finally, the same kind of key management a company sets up for inbound traffic must be used for internal (East-West) traffic. “Basically for East-West traffic the company controls the end, whether it’s one data center to another data center or one network segment to another network segment,” he adds.

Bottom line: Security managers need to understand that encrypted packets represent a legitimate threat that must be managed and inspected regularly. 

Related Content:



Steve Zurier has more than 30 years of journalism and publishing experience, most of the last 24 of which were spent covering networking and security technology. Steve is based in Columbia, Md. View Full Bio

More Insights

from Dark Reading – All Stories http://ubm.io/2crH6Ss
via IFTTT

2016 DDoS Attack Trends By The Numbers

CVE-2013-7445

Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b…

CVE-2015-4948

Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660

Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003

Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333

Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.


from Dark Reading – All Stories http://ubm.io/2bRGy3f
via IFTTT

OneLogin SecureNotes Breach Exposes Data in Cleartext

Single sign-on company OneLogin began notifying customers this week that an attacker was able to take advantage of a bug in its system and view sensitive notes posted by users, thought to be secure.

The company, whose authentication technology secures cloud-based applications, confirmed the incident Tuesday in a blog post.

The compromised feature, Secure Notes, enables customers to store information, usually with “multiple levels of AES-256.” OneLogin encourages users to use the service to securely store information such as license keys and firewall passwords. A bug in a system the company uses for log storage and analytics apparently undermined that security.

According to OneLogin’s Chief Information Security Officer Alvaro Hoyos, the bug caused all notes – for at least one month this summer – to be stored in cleartext. Specifically, the bug caused notes entered from July 25 to Aug. 25, to be visible in OneLogin’s logging system before they were encrypted.

To make matters worse an attacker was able to compromise the password of a OneLogin employee and gain access to the logging system where the notes were being saved.

It’s unclear whether there was a connection between the cleartext logging bug and the employee email compromise; OneLogin did not immediately return a request for comment on Wednesday.

Based on the wording of OneLogin’s description of the incident, it sounds as if the cleartext logging bug may have affected the system as early as the beginning of June. Hoyos warns OneLogin users in the blog post that the attacker may have had access to the system as early as July 2 and that if a customer tried saving a note from June 2 to July 24, it could have been read as well.

While more than 12 million people use OneLogin’s services, the company didn’t specify the exact number of users affected but instead stressed the bug only compromised a small subset of its users.

The company said it fixed the bug the same day it was discovered, and that it reset passwords in external systems that don’t support SAML, or Security Assertion Markup Language, a XML-based standard for web browser single sign-on. Going forward access, to the company’s log management system can only be accessed via SAML-based authentication and via a limited set of IP addresses, according to Hoyos.

The company began notifying affected customers via email on Monday, and Hoyos claims OneLogin will keep them posted as its investigation continues.

from Threatpost – English – Global – thr… http://bit.ly/2c54PEE
via IFTTT

FTC Warns Travelers About Cybersecurity Risks Of Rental Cars

FTC Warns Travelers About Cybersecurity Risks Of Rental Cars

The Federal Trade Commission has recommendations for consumers to protect their personal data when driving rental vehicles.

Driving a rental car this summer? Your personal information may be at risk, warns the Federal Trade Commission (FTC).

The FTC yesterday released an alert warning car rental customers to safeguard their personal data when using vehicles that include network connectivity. Drivers may be unknowingly making their data vulnerable, as cars continue to store information after they are returned.

Many connected cars are equipped with infotainment systems that work with a driver’s personal devices so he or she can navigate, stream music, and use hands-free calling and texting from behind the wheel.

These systems can store data like previously entered GPS locations, which could include a driver’s home or work address. They may also keep mobile phone numbers, contacts, call logs, or text messages.

The FTC shed some light on precautions rental car customers can take to ensure the safety of their information when driving connected cars.

  • Drivers should avoid connecting their phones or electronic devices to an infotainment system for the sole purpose of charging. If your phone is low on battery, it’s better to use a cigarette lighter adapter to charge instead of the USB port, which may automatically transfer and store data.
  • If you do connect a device to the infotainment system, it may display a screen to ask which types of information you want the system to know. In this case, be sure to only grant access to necessary information; for example, don’t share your contacts if you only want the system to play music.
  • Finally, delete all personal data from the infotainment system before returning the vehicle. Within the system’s settings, you should be able to locate a list of devices connected with the system and follow instructions to delete data. If the process proves tricky, the car’s manual or rental company should be able to give more information.
  • If drivers don’t delete this data before the car is returned, they risk the possibility of sharing it with future renters, rental car employees, or cybercriminals.

As part of its rental car alert, the FTC encouraged rental car customers to heed security advice from the United States Computer Emergency Readiness Team (US-CERT), which published a security tip on the vulnerability of all electronic devices to cyberattacks.

The US-CERT’s advice may seem like common sense to security pros, but it’s worth remembering as more connected devices make their way into everyday life. Some of its tips include keeping device software up to date, encrypting files when storing personal and corporate information, disabling remote connectivity, and using caution with public wifi networks.

Car hacking has been in the spotlight for a while and researchers are working to build tools for discovering vulnerabilities in vehicles. In June 2016, French researchers announced plans to release CANSPY, a tool for testing weaknesses in a car’s local communications network.

Related Content:



Kelly is an associate editor for InformationWeek. She most recently reported on financial tech for Insurance & Technology, before which she was a staff writer for InformationWeek and InformationWeek Education. When she’s not catching up on the latest in tech, Kelly enjoys … View Full Bio

More Insights

from Dark Reading – All Stories http://ubm.io/2bCuXUP
via IFTTT

How one man could have owned GitHub, and what happened next…

A spot of cryptographic bother is unfolding in Mozilla’s security policy discussion forum at the moment.

It’s one more thing to worry about when someone asks you, “How do I know when to trust an HTTPS certificate?”

HTTPS is the protocol that puts the padlock into your browser’s address bar, and it does two equally important things:

  • Keeps your HTTP browsing secure against snooping and modification. Even if all you are doing is reading Naked Security, that’s no one else’s business.
  • Gives you confidence you’re on the right website. An encrypted connection is no use if you’re talking to an imposter at the other end.

In cryptographic language, that gives you confidentiality and integrity, meaning that the data you see is both private and correct.

Very greatly simplified, HTTPS uses an encryption protocol called TLS, short for Transport Layer Security, and it works roughly like this:

  • Your browser connects to a server, which sends back an encryption key to use for confidentiality and a digital certificate to vouch for its right to run the site you’re visiting.
  • The certificate is digitally signed by an organisation called a Certificate Authority (CA), which vouches for the first company’s claim to own the website site you are visiting.
  • The CA is vouched for in turn by your browser or operating system, which ships with a list of CAs that are already trusted to vouch for other people.

(There my be more than three steps up to the browser’s built in trust list, but the idea is the same: a chain of trust exists that is supposed to give you confidence in the authenticity of your connection.)

You can see what the TLS chain of trust looks like in an earlier article we wrote about a certificate blunder made by a French CA.

CA danger

A rogue CA, one that will sign certificates with its own trusted-by-all-browsers root certificate while knowing them to be false, is an obvious and significant danger to the entire internet.

But sloppy CAs can cause just as much trouble if their certificate signing process is riddled with errors, and that’s what has led to the brouhaha in the Mozilla community right now.

The slapdash CA in this case is a Chinese outfit called WoSign, and the problems exist with its free certificate-issuing service.

Signed TLS certificates that vouch for other organisations are supposed to involve some sort of check that the applicant has the right to make the request, to prevent just anyone acquiring a certificate with which they can pretend to be running someone else’s site.

If there were no verification at all, crooks could easily get hold of a certificate identifying them as the legitimate owners of a financial website; at this point, they could run a phishing attack by means of a fake site that was apparently “certified” to be the real thing.

Free certificates, which are considered an important part of helping website owners who otherwise wouldn’t bother with HTTPS to start using it, don’t involve enormous amounts of checking (they’re free of charge, after all), but they’re nevertheless not supposed to be a free-for-all.

The problem with WoSign’s automated certificate checking was that it was plagued by a bug that showed up by mistake.

A WoSign customer wanted to acquire a certificate for the server name med.ucf.edu, a subdomain of the University of Central Florida’s domain ucf.edu.

The customer was duly authorised to run this subdomain, which belongs to the College of Medicine, so WoSign was correct to approve it.

However (and, in hindsight, by good fortune), the customer also accidentally applied for a certificate for http://www.ucf.edu instead, presumably having mistyped http://www.med.ucf.edu.

To his surprise (I am guessing at the customer’s gender here), the second application was approved as well.

This turned out to be more than just a one-off, because the cusotmer did a second test, using a certificate in the name of another domain he had the right to control, namely anaccount.github.com (and anaccount.github.io).

Deliberately following the same faulty path that he had followed by mistake in his previous application, he ended up with a vouched-for certificate for all of github.com, github.io, and http://www.github.io.

As these are the primary servernames for the popular source code hosting service GitHub, this would have been a blunder with very serious consequences if a crook were to have spotted this trick.

This all happened a year ago.

Repairing the damage

WoSign quickly revoked the dodgy GitHub certificate, which was a good start to repairing the damage, but a CA needs to do more than that to convince the community that it has sorted out its sloppiness.

The CA really needs to show, after a blunder, that it can identify all the side-effects of the blunder and deal with those too, and that it won’t repeat the mistake.

A year later, however, the incorrectly issued http://www.ucf.edu certificate apparently still hadn’t been revoked, even though it was obviously caused by the same sort of error that led to the bogus GitHub certificates.

The customer who’d reported the GitHub problem back in 2015 probably assumed that WoSign would not merely paper over the cracks by revoking that one certificate, but look for others issued by mistake due to the same bug, and fix those too.

Mozilla security experts also expressed concerns that WoSign never reported this bug to the TLS community, as it ought to have done, or declared that it had issued incorrect certificates.

Worse still, Mozilla became aware of other blunders made by WoSign (you can read about them in the Mozilla forum) that weren’t reported either, and which still don’t seem to have been taken seriously enough by the CA.

What to do?

The answer seems obvious: remove WoSign from the list of trusted root CAs.

But this is not a step that the TLS community takes lightly, not least because of the knock-on effect on other users, whose correctly-issued WoSign certificates will suddenly start kicking up certificate warnings in everone’s browser.

As a result, the Mozilla team is still undecided:

Taking into account all these incidents and the actions of this CA,
Mozilla is considering what action to take. Your input is welcomed.

What do you think?


from Naked Security – Sophos http://bit.ly/2bCm8u2
via IFTTT

Dropbox hack leads to 68 million passwords dumped online

Earlier in the week, Dropbox forced password resets after stumbling across user credentials online that it believes were stolen in a 2012 breach.

Our security teams are always watching out for new threats to our users. As part of these ongoing efforts, we learned about an old set of Dropbox user credentials (email addresses plus hashed and salted passwords) that we believe were obtained in 2012.

Our analysis suggests that the credentials relate to an incident we disclosed around that time

You’ll need to update your password if you signed up to use Dropbox before mid-2012 and if you haven’t changed that password since then, Dropbox said.

The next time you visit dropbox.com, you may be asked to create a new password. We proactively initiated this password update prompt for Dropbox users who meet certain criteria.

Motherboard reports that it got its hands on files containing the email addresses and hashed passwords for the data set through what the publication says are sources in the database trading community.

It’s obtained four files – around 5GB in size – that contain details on 68,680,741 accounts. A senior Dropbox employee told Motherboard that the data is legitimate.

You’ll know that your Dropbox credentials were caught up in this theft if you receive an email from Dropbox, at the address on your Dropbox account. Plus, those affected can expect to be prompted to update their password the next time they visit dropbox.com.

Dropbox says this is all purely preventative. It’s seen no indication that accounts have been improperly accessed.

How do I protect my Dropbox account?

Dropbox is advising some security precautions that should sound familiar:

  1. Update any passwords you use on other sites, and make sure to use only one, unique password per site.
  2. Make those unique passwords strong. Here’s how.
  3. Consider turning on two-step verification. Here’s how to do it on Dropbox, and here’s why it’s a great idea.
  4. Only sign in to your account from secure devices, and always sign out if accessing your account on a non-personal device.

from Naked Security – Sophos http://bit.ly/2c8T9zI
via IFTTT