What’s it like working as a malware researcher? – ProtonMail and the battle for email privacy – Man charged with hacking, trying to extort US sports leagues

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

What’s it like working as a malware researcher? – ProtonMail and the battle for email privacy – Man charged with hacking, trying to extort US sports leagues

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

Beyond the vulnerability in the Android kernel, the monthly round of security patches plugs another 38 security loopholes

The post Google squashes Android zero‑day bug exploited in targeted attacks appeared first on WeLiveSecurity

Security and privacy get a leg up in Proton’s legal challenge against data retention and disclosure obligations

The post Win one for privacy – Swiss providers don’t have to talk appeared first on WeLiveSecurity

Three ESET malware researchers describe what their job involves and what it takes to embark on a successful career in this field

The post What’s it like to work as a malware researcher? 10 questions answered appeared first on WeLiveSecurity

On top of illegally streaming sports games for profit, the man is also believed to have attempted to extort MLB for $150,000

The post Man charged with hacking major US sports leagues to illegally stream games appeared first on WeLiveSecurity


Starting today and for the next 3 months (until January 31 2022), we will pay 31,337 USD to security researchers that exploit privilege escalation in our lab environment with a patched vulnerability, and 50,337 USD to those that use a previously unpatched vulnerability, or a new exploit technique.

We are constantly investing in the security of the Linux Kernel because much of the internet, and Google—from the devices in our pockets, to the services running on Kubernetes in the cloud—depend on the security of it. We research its vulnerabilities and attacks, as well as study and develop its defenses.

But we know that there is more work to do. That’s why we have decided to build on top of our kCTF VRP from last year and triple our previous reward amounts (for at least the next 3 months).

Our base rewards for each publicly patched vulnerability is 31,337 USD (at most one exploit per vulnerability), but the reward can go up to 50,337 USD in two cases:

  • If the vulnerability was otherwise unpatched in the Kernel (0day)
  • If the exploit uses a new attack or technique, as determined by Google

We hope the new rewards will encourage the security community to explore new Kernel exploitation techniques to achieve privilege escalation and drive quicker fixes for these vulnerabilities. It is important to note, that the easiest exploitation primitives are not available in our lab environment due to the hardening done on Container-Optimized OS. Note this program complements Android’s VRP rewards, so exploits that work on Android could also be eligible for up to 250,000 USD (that’s in addition to this program).

The mechanics are:

  1. Connect to the kCTF VRP cluster, obtain root and read the flag (read this writeup for how it was done before, and this threat model for inspiration), and then submit your flag and a checksum of your exploit in this form.
  2. (If applicable) report vulnerabilities to upstream.
    • We strongly recommend including a patch since that could qualify for an additional reward from our Patch Reward Program, but please report vulnerabilities upstream promptly once you confirm they are exploitable.
  3. Report your finding to Google VRP once all patches are publicly available (we don’t want to receive details of unpatched vulnerabilities ahead of the public.)
    • Provide the exploit code and the algorithm used to calculate the hash checksum.
    • A rough description of the exploit strategy is welcome.

Reports will be triaged on a weekly basis. If anyone has problems with the lab environment (if it’s unavailable, technical issues or other questions), contact us on Discord in #kctf. You can read more details about the program here. Happy hunting!

ESET discovers Wslink – Why secure-by-design is a must – Staying cybersecure this Halloween and beyond – Operation Dark HunTOR

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

ESET discovers Wslink – Why secure-by-design is a must – Staying cybersecure this Halloween and beyond – Operation Dark HunTOR

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

At Google, keeping you safe online is our top priority, so we continuously build the most advanced privacy-preserving technologies into our products. Over the past few years, we’ve utilized innovations in cryptographic research to keep your personal information private by design and secure by default. As part of this, we launched Password Checkup, which protects account credentials by notifying you if an entered username and password are known to have been compromised in a prior data breach. Using cryptographic techniques, Password Checkup can do this without revealing your credentials to anyone, including Google. Today, Password Checkup protects users across many platforms including Android, Chrome and Google Password Manager.

Another example is Private Join and Compute, an open source protocol which enables organizations to work together and draw insights from confidential data sets. Two parties are able to encrypt their data sets, join them, and compute statistics over the joint data. By leveraging secure multi-party computation, Private Join and Compute is designed to ensure that the plaintext data sets are concealed from all parties.

In this post, we introduce the next iteration of our research, Private Set Membership, as well as its open-source availability. At a high level, Private Set Membership considers the scenario in which Google holds a database of items, and user devices need to contact Google to check whether a specific item is found in the database. As an example, users may want to check membership of a computer program on a block list consisting of known malicious software before executing the program. Often, the set’s contents and the queried items are sensitive, so we designed Private Set Membership to perform this task while preserving the privacy of our users.

Protecting your device information during enrollment
Beginning in Chrome 94, Private Set Membership will enable Chrome OS devices to complete the enrollment process in a privacy-preserving manner. Device enrollment is an integral part of the out-of-box experience that welcomes you when getting started with a Chrome OS device.

The device enrollment process requires checking membership of device information in encrypted Google databases, including checking if a device is enterprise enrolled or determining if a device was pre-packaged with a license. The correct end state of your Chrome OS device is determined using the results of these membership checks.

During the enrollment process, we protect your Chrome OS devices by ensuring no information ever leaves the device that may be decrypted by anyone else when using Private Set Membership. Google will never learn any device information and devices will not learn any unnecessary information about other devices. ​​To our knowledge, this is the first instance of advanced cryptographic tools being leveraged to protect device information during the enrollment process.

A deeper look at Private Set Membership
Private Set Membership is built upon two cryptographic tools:

  • Homomorphic encryption is a powerful cryptographic tool that enables computation over encrypted data without the need for decryption. As an example, given the encryptions of values X and Y, homomorphic encryption enables computing the encryption of the sum of X and Y without ever needing to decrypt. This preserves privacy as the data remains concealed during the computation. Private Set Membership is built upon Google’s open source homomorphic encryption library.
  • Oblivious hashing is a cryptographic technique that enables two parties to jointly compute a hash, H(K, x), where the sender holds the key, K, and the receiver holds the hash input, x. The receiver will obtain the hash, H(K, x), without learning the key K. At the same time, the input x will be hidden from the sender.

Take a look at how Private Set Membership utilizes homomorphic encryption and oblivious hashing to protect data below:

For a deeper look into the technology behind Private Set Membership, you can also access our open source code.

Privacy properties
By using Private Set Membership, the following privacy properties are obtained:

  • No data leaves the device when checking membership. We designed Private Set Membership using advanced cryptographic techniques to ensure that data never leaves the device in an unencrypted manner when performing membership checks. As a result, the data on your device will be concealed from everyone, including Google.
  • Devices learn only membership information and nothing else. Private Set Membership was designed to prevent devices from learning any unnecessary information about other devices when querying. For each query, devices learn only the results of the membership check and no other information.

Using Private Set Membership to solve more problems
Private Set Membership is a powerful tool that solves a fundamental problem in a privacy-preserving manner. This is just the beginning of what’s possible using this technology. Private Set Membership can help preserve user privacy across a wide array of applications. For example:

  • Checking allow or block lists. In this setting, users check membership in an allow or block list to determine whether to proceed with the desired action. Private Set Membership enables this check without any information about the software leaving the device.
  • Control flows with conditional membership checks. Control flows are a common computer science concept that represent arbitrary computer programs with conditional branching. In many cases, the conditional branches require checking membership of sensitive data to determine the next step of the algorithm. By utilizing Private Set Membership, we enable execution of these algorithms while ensuring data never leaves the user’s device.

We still have a ways to go before Private Set Membership is used for general membership checks by devices. At Google, we are exploring a number of potential use cases to protect your privacy using Private Set Membership. We are excited to continue advancing the state-of-the-art cryptographic research to keep you safe.

Acknowledgements

The work in this post is the result of a collaboration between a large group of current and former Google engineers, research scientists and others including: Amr Aboelkher, Asra Ali, Ghous Amjad, Yves Arrouye, Roland Bock, Xi Chen, Maksim Ivanov, Dennis Kalinichenko, Nirdhar Khazanie, Dawon Lee, Tancrède Lepoint, Lawrence Lui, Pavol Marko, Thiemo Nagel, Mariana Raykova, Aaron Segal, Joon Young Seo, Karn Seth, and Jason Wong.