Google Online Security Blog: 6월 2022

Security Blog

The latest news and insights from Google on security and safety on the Internet

Game on! The 2022 Google CTF is here.

2022년 6월 21일

Posted by Jan Keller, Technical Entertainment Manager, Bug Hunters

Are you ready to put your hacking skills to the test? It’s Google CTF time!

The competition kicks off on July 1 2022 6:00 PM UTC and runs through July 3 2022 6:00 PM UTC. Registration is now open at http://goo.gle/ctf.

In true old Google CTF fashion, the top 8 teams will qualify for our Hackceler8 speedrunning meets CTFs competition. The prize pool stands similar to previous years at more than $40,000.

We can’t wait to see whether PPP will be able to defend their crown. For those of you looking to satisfy your late-night hacking hunger: past year's challenges, including Hackceler8 2021 matches, are open-sourced here. On top of that there are hours of Hackceler8 2020 videos to watch!

If you are just starting out in this space, last year’s Beginner’s Quest is a great resource to get started. For later in the year, we have something mysterious planned - stay tuned to find out more!

Whether you’re a seasoned CTF player or just curious about cyber security and ethical hacking, we want you to join us. Sign up to expand your skill set, meet new friends in the security community, and even watch the pros in action. For the latest announcements, see g.co/ctf, subscribe to our mailing list, or follow us on @GoogleVRP. Interested in bug hunting for Google? Check out bughunters.google.com. See you there!

Google

SBOM in Action: finding vulnerabilities with a Software Bill of Materials

2022년 6월 14일

Posted by Brandon Lum and Oliver Chang, Google Open Source Security Team

SBOMs2021 Executive Order on CybersecuritySecure Software Development Frameworkmaking progress on methodscriticalOSV: Connecting SBOMs to vulnerabilitiesbomOpen Source Vulnerabilities (OSV) databaseGithub Advisory Database (GHSA)Global Security Database (GSD)spdx-to-osvpublicly available

# Download the Kubernetes SPDX source document

$ curl -L https://sbom.k8s.io/v1.21.3/source > k8s-1.21.3-source.spdx

spdx-to-osv

# Run the spdx-to-osv tool, taking the information from the SPDX SBOM and mapping it to OSV vulnerabilities

$ java -jar ./target/spdx-to-osv-0.0.4-SNAPSHOT-jar-with-dependencies.jar -I k8s-1.21.3-source.spdx -O out-k8s.1.21.3.json

# Show the output OSV vulnerabilities of the spdx-to-osv tool

$ cat out-k8s.1.21.3.json

…

{

"id": "GHSA-w73w-5m7g-f7qc",

"published": "2021-05-18T21:08:21Z",

"modified": "2021-06-28T21:32:34Z",

"aliases": [

"CVE-2020-26160"

"summary": "Authorization bypass in github.com/dgrijalva/jwt-go",

"details": "jwt-go allows attackers to bypass intended access restrictions in situations with []string{} for m[\"aud\"] (which is allowed by the specification). Because the type assertion fails, \"\" is the value of aud. This is a security problem if the JWT token is presented to a service that lacks its own audience check. There is no patch available and users of jwt-go are advised to migrate to [golang-jwt](https://github.com/golang-jwt/jwt) at version 3.2.1",

"affected": [

{

"package": {

"name": "github.com/dgrijalva/jwt-go",

"ecosystem": "Go",

"purl": "pkg:golang/github.com/dgrijalva/jwt-go"

…

CVE-2020-26160
Suggestions for SBOM tooling improvements

To get the spdx-to-osv tool to work we had to make some minor changes to disambiguate the information provided in the SBOM:

In the current implementation of the bom tool, the version was included as part of the package name (gopkg.in/square/go-jose.v2@v2.2.2). We needed to trim the suffix to match the SPDX format, which has a different field for version number.

The SBOM created by the bom tool does not specify an ecosystem. Without an ecosystem, it's impossible to reliably disambiguate which library or package is affected in an automated way. Vulnerability scanners could return false positives if one ecosystem was affected but not others. It would be more helpful if the SBOM differentiated between different library and package versions.

These are relatively minor hurdles, though, and we were able to successfully run the tool with only small manual adjustments. To make the process easier in the future, we have the following recommendation for improving SBOM generation tooling:

SBOM tooling creators should add a reference using an identification scheme such as Purl for all packages included in the software. This type of identification scheme both specifies the ecosystem and also makes package identification easier, since the scheme is more resilient to small deviations in package descriptors like the suffix example above. SPDX supports this via external references to Purl and other package identification schemas.

SBOM in the future

It’s clear that we’re getting very close to achieving the original goal of SBOMs: using them to help manage the risk of vulnerabilities in software. Our example queried the OSV database, but we will soon see the same success in mapping SBOM data to other vulnerability databases and even using them with new standards like VEX, which provides additional context around whether vulnerabilities in software have been mitigated.

Continuing on this path of widespread SBOM adoption and tooling refinement, we will hopefully soon be able to not only request and download SBOMs for every piece of software, but also use them to understand the vulnerabilities affecting any software we consume. This example is a peek into a possible future of what SBOMs can offer when we bridge the gap to connect them with vulnerability databases: a new normal of worrying less about the risks in the software we use.

A special thanks to Gary O’Neall of Source Auditor for creating the spdx-to-osv tool and contributing to this blog post.

Google

Announcing the winners of the 2021 GCP VRP Prize

2022년 6월 3일

Posted by Harshvardhan Sharma, Information Security Engineer, Google
record-breaking yearGoogle Cloud Platform (GCP)announcedFirst PrizeBypassing Identity-Aware ProxySecond PrizeGCE VM takeover via DHCP floodThird PrizeRemote Code Execution in Google Cloud DataflowFourth PrizeThe Speckle Umbrella story — part 2(Remember, you can make multiple submissions for the GCP VRP Prize and be eligible for more than one prize!)Fifth PrizeRemote code execution in Managed Anthos Service Mesh control planeSixth PrizeCommand Injection in Google Cloud Shell

New Details About 2022 GCP VRP

We will pay out a total of $313,337 to the top seven submissions in the 2022 edition of the GCP VRP Prize. Individual prize amounts will be as follows:

1st prize: $133,337
2nd prize: $73,331
3rd prize: $31,337
4th prize: $31,311
5th prize: $17,311
6th prize: $13,373
7th prize: $13,337

If you are a security researcher, here's how you can enter the competition for the GCP VRP Prize 2022:

Find a vulnerability in a GCP product (check out Google Cloud Free Program to get started).
Report it to bughunters.google.com. Your bug needs to be awarded a financial reward to be eligible for the GCP VRP Prize (the GCP VRP Prize money will be in addition to what you received for your bug!).
Create a public write-up describing your vulnerability report. One of the goals behind the GCP VRP Prize is to promote open research into cloud security.
Submit it here.

Make sure to submit your VRP reports and write-ups before January 15, 2023 at 23:59 PT. VRP reports which were submitted in preceding years but fixed only in 2022 are also eligible. You can check out the official rules for the prize here. Good luck!

Google

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms

Security Blog

Game on! The 2022 Google CTF is here.

SBOM in Action: finding vulnerabilities with a Software Bill of Materials

Announcing the winners of the 2021 GCP VRP Prize

태그

Archive

Feed