The worst passwords of 2019: Did yours make the list?

These passwords may win the popularity contest but lose flat out in security

The post The worst passwords of 2019: Did yours make the list? appeared first on WeLiveSecurity

/by

Week in security with Tony Anscombe

ESET’s Cybersecurity Trends 2020 report is out – New Chrome feature boosts account security – Hundreds of thousands of birth certificate applications leaked online

The post Week in security with Tony Anscombe appeared first on WeLiveSecurity

/by

2FA: Double down on your security

The second authentication factor might be a minor inconvenience, but it provides a major security boost

The post 2FA: Double down on your security appeared first on WeLiveSecurity

/by

Chrome now warns you if your password has been stolen

The browser’s latest version also aims to up the ante in phishing protection

The post Chrome now warns you if your password has been stolen appeared first on WeLiveSecurity

/by

Better password protections in Chrome – How it works

Posted by Patrick Nepper, Kiran C. Nair, Vasilii Sukhanov and Varun Khaneja, Chrome Team

Today, we announced better password protections in Chrome, gradually rolling out with release M79. Here are the details of how they work.

Warnings about compromised passwords
Google first introduced password breach warnings as a Password Checkup extension early this year. It compares passwords and usernames against over 4 billion credentials that Google knows to have been compromised. You can read more about it here. In October, Google built the Password Checkup feature into the Google Account, making it available from passwords.google.com.

Chrome’s integration is a natural next step to ensure we protect even more users as they browse the web. Here is how it works:

  • Whenever Google discovers a username and password exposed by another company’s data breach, we store a hashed and encrypted copy of the data on our servers with a secret key known only to Google.
  • When you sign in to a website, Chrome will send a hashed copy of your username and password to Google encrypted with a secret key only known to Chrome. No one, including Google, is able to derive your username or password from this encrypted copy.
  • In order to determine if your username and password appears in any breach, we use a technique called private set intersection with blinding that involves multiple layers of encryption. This allows us to compare your encrypted username and password with all of the encrypted breached usernames and passwords, without revealing your username and password, or revealing any information about any other users’ usernames and passwords. In order to make this computation more efficient, Chrome sends a 3-byte SHA256 hash prefix of your username to reduce the scale of the data joined from 4 billion records down to 250 records, while still ensuring your username remains anonymous.
  • Only you discover if your username and password have been compromised. If they have been compromised, Chrome will tell you, and we strongly encourage you to change your password.

You can control this feature in the “Sync and Google Services” section of Chrome Settings. Enterprise admins can control this feature using the Password​Leak​Detection​Enabled policy setting.

Real-time phishing protection: Checking with Safe Browsing’s blocklist in real time.
Chrome’s new real-time phishing protection is also expanding existing technology — in this case it’s Google’s well-established Safe Browsing.

Every day, Safe Browsing discovers thousands of new unsafe sites and adds them to the blocklists shared with the web industry. Chrome checks the URL of each site you visit or file you download against this local list, which is updated approximately every 30 minutes. If you navigate to a URL that appears on the list, Chrome checks a partial URL fingerprint (the first 32 bits of a SHA-256 hash of the URL) with Google for verification that the URL is indeed dangerous. Google cannot determine the actual URL from this information.

However, we’re noticing that some phishing sites slip through our 30-minute refresh window, either by switching domains very quickly or by hiding from Google’s crawlers.

That’s where real-time phishing protections come in. These new protections can inspect the URLs of pages visited with Safe Browsing’s servers in real time. When you visit a website, Chrome checks it against a list stored on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL) to find out if you’re visiting a dangerous site. Our analysis has shown that this results in a 30% increase in protections by warning users on malicious sites that are brand new.

We will be initially rolling out this feature for people who have already opted-in to “Make searches and browsing better” setting in Chrome. Enterprises administrators can manage this setting via the Url​Keyed​Anonymized​Data​Collection​Enabled policy settings.

Expanding predictive phishing protection
Your password is the key to your online identity and data. If this key falls into the hands of attackers, they can easily impersonate you and get access to your data. We launched predictive phishing protections to warn users who are syncing history in Chrome when they enter their Google Account password into suspected phishing sites that try to steal their credentials.

With this latest release, we’re expanding this protection to everyone signed in to Chrome, even if you have not enabled Sync. In addition, this feature will now work for all the passwords you have stored in Chrome’s password manager.

If you type one of your protected passwords (this could be a password you stored in Chrome’s password manager, or the Google Account password you used to sign in to Chrome) into an unusual site, Chrome classifies this as a potentially dangerous event.

In such a scenario, Chrome checks the site against a list on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL). If this check determines that the site is indeed suspicious or malicious, Chrome will immediately show you a warning and encourage you to change your compromised password. If it was your Google Account password that was phished, Chrome also offers to notify Google so we can add additional protections to ensure your account isn’t compromised.

By watching for password reuse, Chrome can give heightened security in critical moments while minimizing the data it shares with Google. We think predictive phishing protection will protect hundreds of millions more people.

/by

Data leak exposes 750,000 birth certificate applications

A variety of sensitive information has been there for the taking due to an unsecured cloud storage container

The post Data leak exposes 750,000 birth certificate applications appeared first on WeLiveSecurity

/by

Cybersecurity Trends 2020: Technology is getting smarter – are we?

With 2019 ending, ESET experts offer their insights into how new innovations will impact our privacy, security and lives in the not so distant future

The post Cybersecurity Trends 2020: Technology is getting smarter – are we? appeared first on WeLiveSecurity

/by

Detecting unsafe path access patterns with PathAuditor

Posted by Marta Rożek, Google Summer Intern 2019, and Stephen Röttger, Software Engineer 

#!/bin/sh
cat /home/user/foo

What can go wrong if this command runs as root? Does it change anything if foo is a symbolic link to /etc/shadow? How is the output going to be used?

Depending on the answers to the questions above, accessing files this way could be a vulnerability. The vulnerability exists in syscalls that operate on file paths, such as open, rename, chmod, or exec. For a vulnerability to be present, part of the path has to be user controlled and the program that executes the syscall has to be run at a higher privilege level. In a potential exploit, the attacker can substitute the path for a symlink and create, remove, or execute a file. In many cases, it’s possible for an attacker to create the symlink before the syscall is executed.

At Google, we have been working on a solution to find these potentially problematic issues at scale: PathAuditor. In this blog post we’ll outline the problem and explain how you can avoid it in your code with PathAuditor.

Let’s take a look at a real world example. The tmpreaper utility contained the following code to check if a directory is a mount point:
if ((dst = malloc(strlen(ent->d_name) + 3)) == NULL)
       message (LOG_FATAL, “malloc failed.\n”);
strcpy(dst, ent->d_name);
strcat(dst, “/X”);
rename(ent->d_name, dst);
if (errno == EXDEV) {
[…]

This code will call rename(“/tmp/user/controlled”, “/tmp/user/controlled/X”). Under the hood, the kernel will resolve the path twice, once for the first argument and once for the second, then perform some checks if the rename is valid and finally try to move the file from one directory to the other.

However, the problem is that the user can race the kernel code and replace the “/tmp/user/controlled” with a symlink just between the two path resolutions.

A successful attack would look roughly like this:

  • Make “/tmp/user/controlled” a file with controlled content.
  • The kernel resolves that path for the first argument to rename() and sees the file.
  • Replace “/tmp/user/controlled” with a symlink to /etc/cron.
  • The kernel resolves the path again for the second argument and ends up in /etc/cron.
  • If both the tmp and cron directories are on the filesystem, the kernel will move the attacker controlled file to /etc/cron, leading to code execution as root.

Can we find such bugs via automated analysis? Well, yes and no. As shown in the tmpreaper example, exploiting these bugs can require some creativity and it depends on the context if they’re vulnerabilities in the first place. Automated analysis can uncover instances of this access pattern and will gather as much information as it can to help with further investigation. However, it will also naturally produce false positives.

We can’t tell if a call to open(/user/controlled, O_RDONLY) is a vulnerability without looking at the context. It depends on whether the contents are returned to the user or are used in some security sensitive way. A call to chmod(/user/controlled, mode) depending on the mode can be either a DoS or a privilege escalation. Accessing files in sticky directories (like /tmp) can become vulnerabilities if the attacker found an additional bug to delete arbitrary files.

How Pathauditor works

To find issues like this at scale we wrote PathAuditor, a tool that monitors file accesses and logs potential vulnerabilities. PathAuditor is a shared library that can be loaded into processes using LD_PRELOAD. It then hooks all filesystem related libc functions and checks if the access is safe. For that, we traverse the path and check if any component could be replaced by an unprivileged user, for example if a directory is user-writable. If we detect such a pattern, we log it to syslog for manual analysis.

Here’s how you can use it to find vulnerabilities in your code:

  • LD_PRELOAD the library to your binary and then analyse its findings in syslog. You can also add the library to /etc/ld.so.preload, which will preload it in all binaries running on the system.
  • It will then gather the PID and the command line of the calling process, arguments of the vulnerable function, and a stack trace — this provides a starting point for further investigation. At this point, you can use the stack trace to find the code path that triggered the violation and manually analyse what would happen if you would point the path to an arbitrary file or directory.
  • For example, if the code is opening a file and returning the content to the user then you could use it to read arbitrary files. If you control the path of chmod or chown, you might be able to change the permissions of chosen files and so on.

PathAuditor has proved successful at Google and we’re excited to share it with the community. The project is still in the early stages and we are actively working on it. We look forward to hearing about any vulnerabilities you discover with the tool, and hope to see pull requests with further improvements.

Try out the PathAuditor tool here.


Marta Rożek was a Google Summer intern in 2019 and contributed to this blog and the PathAuditor tool


/by

5 scam prevention tips for seniors

How can people who didn’t grow up with technology protect themselves against some of the most common types of online fraud?

The post 5 scam prevention tips for seniors appeared first on WeLiveSecurity

/by

Week in security with Tony Anscombe

On the implications of facial recognition for privacy and security – Data privacy tips for businesses – Red flags for cyberbullying. All this in Week in security.

The post Week in security with Tony Anscombe appeared first on WeLiveSecurity

/by