5 reasons why (not only) financial companies struggle with cybersecurity

Why do many organizations have a hard time keeping up with the evolving threat landscape and effectively managing their cyber-risks?

The post 5 reasons why (not only) financial companies struggle with cybersecurity appeared first on WeLiveSecurity

/by

Week in security with Tony Anscombe

A banking trojan masquerades as Clubhouse for Android – The implications of the Verkada breach – A zero-day patched in Chrome

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

/by

7 steps to staying safe and secure on Twitter

Follow these easy steps to prevent your Twitter account from being hacked and to remain safe while tweeting

The post 7 steps to staying safe and secure on Twitter appeared first on WeLiveSecurity

/by

Trust your surveillance? Why hacked cameras are very bad

When a breach captures a part of us that is unchangeable, does it mean that we have allowed technology to pry too deeply into our lives?

The post Trust your surveillance? Why hacked cameras are very bad appeared first on WeLiveSecurity

/by

Trust your surveillance? Why hacked cameras are very bad

When a breach captures a part of us that is unchangeable, does it mean that we have allowed technology to pry too deeply into our lives?

The post Trust your surveillance? Why hacked cameras are very bad appeared first on WeLiveSecurity

/by

FBI: Cybercrime losses topped US$4.2 billion in 2020

The Bureau received over 28,000 reports of COVID-19-themed scams last year

The post FBI: Cybercrime losses topped US$4.2 billion in 2020 appeared first on WeLiveSecurity

/by

Beware Android trojan posing as Clubhouse app

The malware can grab login credentials for more than 450 apps and bypass SMS-based two-factor authentication

The post Beware Android trojan posing as Clubhouse app appeared first on WeLiveSecurity

/by

Announcing the winners of the 2020 GCP VRP Prize

Posted by Harshvardhan Sharma, Information Security Engineer, Google 


We first announced the GCP VRP Prize in 2019 to encourage security researchers to focus on the security of Google Cloud Platform (GCP), in turn helping us make GCP more secure for our users, customers, and the internet at large. In the first iteration of the prize, we awarded $100,000 to the winning write-up about a security vulnerability in GCP. We also announced that we would reward the top 6 submissions in 2020 and increased the total prize money to $313,337.

2020 turned out to be an amazing year for the Google Vulnerability Reward Program. We received many high-quality vulnerability reports from our talented and prolific vulnerability researchers.

Vulnerability reports received year-over-year

This trend was reflected in the submissions we received for the GCP VRP Prize. After careful evaluation of the many innovative and high-impact vulnerability write-ups we received this year, we are excited to announce the winners of the 2020 GCP VRP Prize:

  • First Prize, $133,337: Ezequiel Pereira for the report and write-up RCE in Google Cloud Deployment Manager. The bug discovered by Ezequiel allowed him to make requests to internal Google services, authenticated as a privileged service account. Here’s a video that gives more details about the bug and the discovery process.

  • Second Prize, $73,331: David Nechuta for the report and write-up 31k$ SSRF in Google Cloud Monitoring led to metadata exposure. David found a Server-side Request Forgery (SSRF) bug in Google Cloud Monitoring’s uptime check feature. The bug could have been used to leak the authentication token of the service account used for these checks.
  • Third Prize, $73,331: Dylan Ayrey and Allison Donovan for the report and write-up Fixing a Google Vulnerability. They pointed out issues in the default permissions associated with some of the service accounts used by GCP services.
  • Fourth Prize, $31,337: Bastien Chatelard for the report and write-up Escaping GKE gVisor sandboxing using metadata. Bastien discovered a bug in the GKE gVisor sandbox’s network policy implementation due to which the Google Compute Engine metadata API was accessible. 
  • Fifth Prize, $1,001: Brad Geesaman for the report and write-up CVE-2020-15157 “ContainerDrip” Write-up. The bug could allow an attacker to trick containerd into leaking instance metadata by supplying a malicious container image manifest.
  • Sixth Prize, $1,000: Chris Moberly for the report and write-up Privilege Escalation in Google Cloud Platform’s OS Login. The report demonstrates how an attacker can use DHCP poisoning to escalate their privileges on a Google Compute Engine VM.

Congratulations to all the winners! If we have piqued your interest and you would like to enter the competition for a GCP VRP Prize in 2021, here’s a reminder on the requirements.

  • Find a vulnerability in a GCP product (check out Google Cloud Free Program to get started)
  • Report it to the VRP (you might get rewarded for it on top of the GCP VRP Prize!)
  • Create a public write-up
  • Submit it here

Make sure to submit your VRP reports and write-ups before December 31, 2021 at 11:59 GMT. Good luck! You can learn more about the prize for this year here. We can’t wait to see what our talented vulnerability researchers come up with this year!

/by

Google fixes Chrome zero‑day bug exploited in the wild

The latest update patches a total of five vulnerabilities affecting the browser’s desktop versions

The post Google fixes Chrome zero‑day bug exploited in the wild appeared first on WeLiveSecurity

/by

Google, HTTPS, and device compatibility

Posted by Ryan Hurst, Product Management, Google Trust Services

Encryption is a fundamental building block when you’re on a mission to organize the world’s information and make it universally accessible with strong security and privacy. This is why a little over four years ago we created Google Trust Services—our publicly trusted Certificate Authority (CA).

The road to becoming a publicly trusted certificate authority is a long one – especially if the certificates you issue will be used by some of the most visited sites on the internet.

When we started on this journey, our goal was that within five years our root certificates would be embedded in enough devices that we could do a single transition to our long-term root certificates.

There are still a large number of active used devices that have not been updated with our root certificates.

To ensure as many clients as possible continue to have secure connections when using Google Trust Services certificates, we needed to obtain a cross-sign. A cross-sign allows a certificate authority that is already trusted by a device to extend its device compatibility to another certificate authority.

The rules governing public CA operations require that the CA being cross-signed meet the same strict operational, technological, and audit criteria as the certificate authority providing this cross-sign. Google Trust Services is already a publicly trusted CA that is operated to the highest standards and is in all major browser trust stores, so we already met the requirements for a cross-sign from another CA.. The key was to find one that is already trusted by the devices we wanted to be able to validate our certificates. We worked with GMO GlobalSign for this cross sign because they operate one of the oldest root certificates in wide use today.

Why are we telling you about this now? On December 15, 2021, the primary root certificate we use today (GlobalSign R2 which is owned and operated by Google Trust Services) will expire.

To ensure these older devices continue to work smoothly with the certificates we issue we will start sending a new cross-signed certificate to services when we issue new certificates.

The good news is that users shouldn’t notice the change. This is because the cross-certificate (GTS Root R1 Cross) we’re deploying was signed by a root certificate created and trusted by most devices over 20 years ago.

In summary, when you use certificates from Google Trust Services, you and your customers will continue to get the benefit of the best device compatibility in the industry.

We know you might have some questions about this change. Here are our answers to the most frequent ones:

I am a developer or ISV that uses a Google API. What do I need to do?


Certificate Authorities change which root CA certificates they use from time to time, so we have always provided a list of certificates that we currently use or may use in the future. Anybody using this list won’t have to change anything. If you have not been using this list and updating it based on our published guidance, you will need to update your application to use these roots and regularly update the list you use so future changes go smoothly for your users.

I am a website operator that uses Google Trust Services certificates. Do I need to change anything?

You do not! Google Trust Services offers certificates to Alphabet products and services including many Google Cloud services. This means that those services are the ones responsible for configuring and managing TLS for you.

When will this change go into effect? 


We will begin rolling out certificate chains that use this cross-certificate in March 2021. We will slowly roll these changes out throughout the rest of the year and will complete them before December 15, 2021.

I use a service or product that uses Google Trust Services. Is there anything I need to change? No, this change should be invisible to all end users.

How can I test to see if my devices will trust certificates that rely on this cross-sign? 


We operate a test site that uses the cross-certificate that you can visit here. If you see “Google Trust Services Demo Page – Expected Status: good” and some additional certificate information, the new certificate chain works correctly on your device. If you get an error, the list of trusted roots for the device you’re testing needs to be updated.

When does this cross-certificate expire and what happens when it does? 


The cross-certificate expires January 28th, 2028. Sometime between now and when it looks like it is no longer needed for broad device compatibility, we will stop providing this extra certificate to certificate requesters, as it will no longer be needed.

I use an old device and it does not trust the cross-sign. What should I do? 


Many devices handle root certificate updates as part of their security patching process. If you are running one of these devices, you should make sure you apply all relevant security updates. It is also possible the manufacturer no longer provides security updates for your device. If this is the case you may want to contact your provider or consider replacing your device.

Does this mean you are no longer using the Google Trust Services roots? We are still using the Google Trust Services roots, they are simply cross-signed. When it is no longer necessary to use the cross-sign, we will no longer distribute the cross-sign to certificate requestors.

To learn more, visit Google Trust Services.

/by