Is your Lenovo laptop vulnerable to cyberattack?

Here’s what to know about vulnerabilities in more than 100 Lenovo consumer laptop models and what you can do right away to stay safe – all in under three minutes

The post Is your Lenovo laptop vulnerable to cyberattack? appeared first on WeLiveSecurity

/by

How can we support young people in harnessing technology for progress?

Young people are not passive victims of technology or helpless addicts. They are technology creators and agents with diverse backgrounds and interests.

The post How can we support young people in harnessing technology for progress? appeared first on WeLiveSecurity

/by

When “secure” isn’t secure at all: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops

ESET researchers discover multiple vulnerabilities in various Lenovo laptop models that allow an attacker with admin privileges to expose the user to firmware-level malware

The post When “secure” isn’t secure at all: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops appeared first on WeLiveSecurity

/by

How to SLSA Part 3 – Putting it all together

Posted by Tom Hennen, software engineer, BCID & GOSST 


In our last two posts (1,2) we introduced a fictional example of Squirrel, Oppy, and Acme learning to SLSA and covered the basics and details of how they’d use SLSA for their organizations. Today we’ll close out the series by exploring how each organization pulls together the various solutions into a heterogeneous supply chain.

As a reminder, Acme is trying to produce a container image that contains three artifacts:

  1. The Squirrel package ‘foo’
  2. The Oppy package ‘baz’
  3. A custom executable, ‘bar’, written by Acme employees.

The process starts with ‘foo’ package authors triggering a build using GitHub Actions. This results in a new version of ‘foo’ (an artifact with hash ‘abc’) being pushed to the Squirrel repo along with its SLSA provenance (signed by Fulcio) and source attestation. When Squirrel gets this push request it verifies the artifact against the specific policy for ‘foo’ which checks that it was built by GitHub Actions from the expected source repository. After the artifact passes the policy check a VSA is created and the new package, its original SLSA provenance, and the VSA are made public in the Squirrel repo, available to all users of package ‘foo’.

Next the maintainers of the Oppy ‘baz’ package trigger a new build using the Oppy Autobuilder. This results in a new version of ‘baz’ (an artifact with hash ‘def’) being pushed to a public Oppy repo with the SLSA provenance (signed by their org-specific keys) published to Rekor. When the repo gets the push request it makes the artifact available to the public. The repo does not perform any verification at this time.

An Acme employee then makes a change to their Dockerfile, sending it for review by their co-worker, who approves the change and merges the PR. This then causes the Acme builder to trigger a build. During this build:

  • bar is compiled from source code stored in the same source repo as the Dockerfile.
  • acorn install downloads ‘foo’ from the Squirrel repo, verifying the VSA, and recording the use of acorn://foo@abc and its VSA in the build.
  • acme_oppy_get install (a custom script made by Acme) downloads the latest version of the Oppy ‘baz’ package and queries its SLSA provenance and other attestations from Rekor. It then performs a full verification checking that it was built by ‘https://oppy.example/slsa/builder/v1’ and the publicized key. Once verification is complete it records the use of oppy://baz@def and the associated attestations in the build.
  • The build process assembles the SLSA provenance for the container by:
    • Recording the Acme git repo the bar source and Dockerfile came from, into materials.
    • Copying the reported dependencies of acorn://foo@abc and oppy://baz@def into materials and adding their attestations to the output in-toto bundle.
    • Recording the CI/CD entrypoint as the invocation.
    • Creating a signed DSSE with the SLSA provenance and adding it to the output in-toto bundle.

Once the container is ready for release the Acme verifier checks the SLSA provenance (and other data in the in-toto bundle) using the policy from their own policy repo and issues a VSA. The VSA and all associated attestations are then published to an internal Rekor instance. Acme can then create an SBOM for the container leveraging data about the build as stored in Rekor. Acme then publishes the container image, the VSA, and the SBOM on Dockerhub.

Downstream users of this Acme container can then check the Acme issued VSA, and if there are any problems Acme can consult their internal Rekor instance to get more details on the build allowing Acme to trace all of their dependencies back to source code and the systems used to create them.
Conclusion

With SLSA implemented in the ways described in this series, downstream users are protected from many of the threats affecting the software supply chain today. While users still need to trust certain parties, the number of systems requiring trust is much lower and users are in a much better position to investigate any issues that arise.

We’d love to see the ideas in this series implemented, refuted, or used as a foundation to build even stronger solutions. We’d also love to hear some other methods on how to solve these issues. Show us how you like to SLSA. 

/by

Week in security with Tony Anscombe

Ukrainian energy provider targeted by Industroyer2 – ESET helps disrupt Zloader botnets – Where do new ideas come from and how are they spread?

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

/by

ESET takes part in global operation to disrupt Zloader botnets

ESET researchers provided technical analysis, statistical information, and known command and control server domain names and IP addresses

The post ESET takes part in global operation to disrupt Zloader botnets appeared first on WeLiveSecurity

/by

How to SLSA Part 2 – The Details

Posted by Tom  Hennen, software engineer, BCID & GOSST 

In our last post we introduced a fictional example of Squirrel, Oppy, and Acme learning to use SLSA and covered the basics of what their implementations might look like. Today we’ll cover the details: where to store attestations and policies, what policies should check, and how to handle key distribution and trust.

Attestation storage

Attestations play a large role in SLSA and it’s essential that consumers of artifacts know where to find the attestations for those artifacts.

Co-located in repo

Attestations could be colocated in the repository that hosts the artifact. This is how Squirrel plans to store attestations for packages. They even want to add support to the Squirrel CLI (e.g. acorn get-attestations foo@1.2.3).

Acme really likes this approach because the attestations are always available and it doesn’t introduce any new dependencies.


Rekor

Meanwhile, Oppy plans to store attestations in Rekor. They like being able to direct users to an existing public instance while not having to maintain any new infrastructure themselves, and the in-depth defense the transparency log provides against tampering with the attestations.

Though the latency of querying attestations from Rekor is likely too high for doing verification at time of use, Oppy isn’t too concerned since they expect users to query Rekor at install time.

Hybrid

A hybrid model is also available where the publisher stores the attestations in Rekor as well as co-located with the artifact in the repo—along with Rekor’s inclusion proof. This provides confidence the data was added to Rekor while providing the benefits of co-locating attestations in the repository.

Policy content

‘Policy’ refers to the rules used to determine if an artifact should be allowed for a use case.

Policies often use the package name as a proxy for determining the use case. An example being, if you want to find the policy to apply you could look up the policy using the package name of the artifact you’re evaluating.

Policy specifics may vary based on ease of use, availability of data, risk tolerance and more. Full verification needs more from policies than delegated verification does.

Default policy

Default policies allow admission decisions without the need to create specific policies for each package. A default policy is a way of saying “anything that doesn’t have a more specific policy must comply with this policy”.

Squirrel plans to eventually implement a default policy of “any package without a more specific policy will be accepted as long as it meets SLSA 3”, but they recognize that most packages don’t support this yet. Until they achieve critical mass they’ll have a default SLSA 0 policy (all artifacts are accepted).

While Oppy is leaving verification to their users, they’ll suggest a default policy of “any package built by ‘https://oppy.example/slsa/builder/v1’”.

Specific policy

Squirrel also plans to allow users to create policies for specific packages. For example, this policy requires that package ‘foo’ must have been built by GitHub Actions, from github.com/foo/acorn-foo, and be SLSA 4.

scope: ‘acorn://foo’

target_level: SLSA_L4

allow_github_actions {

  workflow: ‘https://github.com/gossts/slsa-acorn/.github/workflows/builder.yml@main’

  source_repo: ‘https://github.com/foo/acorn-foo.git’

  allow_branch: ‘main’

}

Squirrel will also allow packages to create SLSA 0 policies if they’re not using SLSA compliant infrastructure.


scope: ‘acorn://qux’

target_level: SLSA_L0

Policy auto generation


Squirrel has an enormous number of existing packages. It’s not feasible to get all those package maintainers to create specific policies themselves. Therefore, Squirrel plans to leverage process mining to auto generate policies for packages based on the history of the package. E.g. “The last 10 times Squirrel package foo was published it was built by GitHub Actions from github.com/foo/acorn-foo, and met SLSA 4 (this is the policy above). Let’s create a policy that requires that and send it to the maintainers to review.”
Policy add-ons

Policy evaluation could do more than just evaluate the SLSA requirements. The same policies that check SLSA requirements are well placed to check other properties that are important to organizations like “was static analysis performed”, “are there any known CVEs in this artifact”, “was integration testing successful”, etc…

Acme is really interested in some of these policy add-ons. They’d like to avoid the embarrassing situation of publishing a new container image with known CVEs. They’re not sure how to implement it yet but they’ll be on the lookout for tools that can help them do so.

Delegated policies

When using delegated verification there’s much less that actually needs to be checked and they can be hard-coded directly in tooling. A minimal delegated verification policy might be “allow if trusted-party verified this artifact (identified by digest) as <package name>”. This can be tightened further by adding requirements on the artifact & its dependencies SLSA levels (data which is available in the VSA). For example, “allow if trusted-party verified this artifact as <package name> at SLSA 3 and it doesn’t have any dependencies less than SLSA 2”.

# Delegated verification implicitly checks that the package name we’re

# checking matches the VSA’s subject.name field.

allow_delegated_verification {

  trusted_verifier: ‘https://delegatedverifier.com/slsa/v1’

  minimum_level: SLSA_L3

  minimum_dependency_level: SLSA_L2

}


Policy storage


When using specific, non-default, policies verifiers need to know where to find the policy they need to evaluate.

Co-located in repo

Squirrel plans to store specific policies as a property of the package in the repository. This makes them very easy for users and their tooling to find. It also allows the maintainer of the package to easily set the policy (they already have write permissions!).

A potential downside is that the write permissions are the same as for the package itself. An attacker that compromises the developer’s credentials could also change the policy. This may not be as bad as it seems. Policies are human-readable so anyone paying attention would notice that package foo’s policy now says that it can be built from github.com/not-foo/acorn-foo. Squirrel plans to notify interested parties (including the maintainer!) when the policy changes, potentially letting them “sound the alarm” if anything nefarious happens.

A similar approach is taken in a number of contact-change workflows. For example, when you change your address with your bank, the bank will send you an email (and a letter to the old address) letting you know the address has been changed. This type of notification would alert the maintainer to a potential compromise.

Squirrel would also consider requiring a second person to review any policy changes for packages with over 10,000 users.


Public canonical Git repo

Another option might be to just create a canonical git repo (e.g. github.com/slsa-framework/slsa-acorn-policies) and let people publish proposed policies there. This has the advantage of using a separate ACL control mechanism from the package repository itself, but the disadvantages of being difficult to ensure the author of the policy is actually allowed to set the policy for that package and not scaling well as the repo grows.

The approach outlined in policy auto generation could help here. Automation in the repo could just look at the last N releases of the package and determine if the proposed policy matches what’s actually been published. Proactive changes to the policy (like deciding to switch from GitHub Actions to CircleCI) would be harder to coordinate however.


Org specific repo

Acme plans to establish their own org specific repo for policy storage. This gives them a single place to store all their policies, regardless of ecosystem type, and lets them provide more specific policies for packages provided by upstream repos. Since Oppy doesn’t have any plans to provide package-specific policies this gives Acme a place to store their own policies for Oppy packages (if they ever get around to it).

Organizations can also use their policy repo to vet any upstream changes to policy and potentially add additional checks (e.g. “doesn’t have any known vulnerabilities”).


Trusted Verifier


Acme wants to use delegated verification and that relies on having trusted verifiers to make decisions for downstream users. Who are these trusted verifiers?

Public verifier

A public repo is in a great position to act as a trusted verifier for their users. Users already trust these repos and they may already be doing verification on import.

Squirrel plans to make use of this by making VSAs available for each artifact published, publicizing their verifier ID (i.e. ‘https://squirrel.example/slsa-verifier’) and the public key used to sign the VSAs. They even plan to build VSA verification directly into the Squirrel tooling, so that users can get SLSA protection by default.


Org-wide verifier

While Acme is happy to use Squirrel’s verifier (and the verification built into the tooling) they still need their own verifier so they can publish VSAs to Acme customers. So Acme plans to stand up their own verification service and publish their verifier ID (i.e. ‘https://acme.example/private-verifier’) and signing key. Acme customers can then verify the software they get from Acme.

In the future Acme could require all software used throughout the company to be verified with this verifier (instead of relying on public verifiers). They’d do the verification and generate VSAs whenever artifacts are imported into their private Artifactory instance. They could then configure this ID/key pair for use throughout Acme and be confident that any software used has been verified according to Acme policy. That’s not Acme’s highest priority at the moment, but they like having this option open to them.

Key distribution & Trust

Both full and delegated verification depend upon key distribution to the users doing the verification. Depending on the specifics and what’s getting verified this can be a difficult problem.

Org-specific keys

When using delegated verification this could be the easiest case. Squirrel can just build the key they used for delegated verification directly into the Squirrel tooling. Acme can also fairly easily configure the use of their keys through the company using existing configuration control mechanisms.

When using full verification this can be harder. If there are multiple builders that could be accepted the keys that sign the attestations need to be distributed to everyone that might use that builder. For Squirrel this would be really difficult since they plan to allow package maintainers to use whatever builder they want. How those keys get configured would be tricky just for Squirrel, and much more difficult if downstream Squirrel users wanted to do full verification of the Squirrel packages.

The situation is easier, however, for Oppy. That’s because Oppy plans to only accept artifacts built by their autobuilder network. Oppy can configure this network to use a single (or small set) of keys and then publish those keys (and the SLSA level Oppy believes it meets) for downstream users.

Fulcio

Squirrel plans to solve the problem of which keys they accept by leveraging Fulcio. Squirrel will build support for Fulcio root keys into their verifier and then express which Fulcio subject is allowed to sign attestations in the specific policy of each package. E.g. “Squirrel package ‘foo’ must have been built & signed by ‘spiffe://foobar.com/foo-builder, from github.com/foo/acorn-foo, and be SLSA 4”.

scope: ‘acorn://foo’

target_level: SLSA_L4

allow_fulcio_builder {

  id: ‘spiffe://foobar.com/foo-builder’

  source_repo: ‘https://github.com/foo/acorn-foo.git’

  allow_branch: ‘main’

  allow_entrypoint: ‘package.json’

}

The Update Framework (TUF)

The above methods could be further enhanced with TUF to allow the secure maintenance of keys. TUF metadata could include all the SLSA keys, the build services and other entities they’re valid for, and the SLSA levels they’re qualified at. Oppy is considering using TUF to let verifiers securely fetch and update keys used by the Autobuilder network. Oppy would use a TUF delegation to indicate that these keys should only be used for the builder id ‘https://oppy.example/slsa/builder/v1’. Squirrel might do something similar to allow for updating the Fulcio key in its tooling.


Recording & verifying dependencies

Acme wants to record and verify the dependencies that go into its container into the SLSA provenance. Acme would prefer that this functionality were just built-in their build service, but that feature isn’t available yet. Instead they’ll need to do something themselves. They have a few options at their disposal:

Tool wrappers

Since Oppy doesn’t build SLSA into it’s tooling Acme will create wrapper scripts for dependency import/installation that record and verify (using cosign) dependencies as they’re installed. Acme will update their build scripts to replace all instances of Oppy package installation with the wrapper script and then use the recorded results to help populate the materials section of the provenance.

A downside is that this approach, if run in the build itself, is not guaranteed to be complete and cannot meet the “non-falsifiable” requirement (since the results reported by the wrapper could be falsified by the build process), relegating this approach to SLSA 2. Still, it allows Acme to make progress SLSA-fying their builds and provides a starting point for achieving higher SLSA levels.


Built into ecosystem tooling

Since Squirrel does build verification into their tooling, Acme can just use acorn install to verify the dependencies and record what was installed. Acme can use this information to populate the Squirrel packages installed in the materials section of the provenance and it can include the attestations of those dependencies in the in-toto bundle for their container image.

As with tool wrappers, if this method is used in the build itself it cannot meet “non-falsifiable” requirement.

Proxied verification

Acme considered creating a proxy for their existing builder to proxy outbound connections. This proxy could verify everything fetched and use its logs to populate the provenance. Since this proxy is trusted it would be easier to meet “non-falsifiable” requirement. Unfortunately it’s also a lot of work for Acme so they’re going to defer this idea for now.

Next time

In the first two parts of this series, we’ve covered the basics of getting started with SLSA and the details of policy and provenance storage, policy verification, and key handling. In our next post we’ll cover how Squirrel, Oppy, and Acme put this all together to protect a heterogeneous supply chain.

/by

Innovation and the Roots of Progress

If you look back at the long arc of history, it’s clear that one of the most crucial drivers of real progress in society is innovation

The post Innovation and the Roots of Progress appeared first on WeLiveSecurity

/by

How to SLSA Part 1 – The Basics

Posted by Tom Hennen, Software Engineer, BCID & GOSST 

One of the great benefits of SLSA (Supply-chain Levels for Software Artifacts) is its flexibility. As an open source framework designed to improve the integrity of software packages and infrastructure, it is as applicable to small open source projects as to enterprise organizations. But with this flexibility can come a bewildering array of options for beginners—much like salsa dancing, someone just starting out might be left on the dance floor wondering how and where to jump in.

Though it’s tempting to try to establish a single standard for how to use SLSA, it’s not possible: SLSA is not a line dance where everyone does the same moves, at the same time, to the same song. It’s a varied system with different styles, moves, and flourishes. The open source community, organizations, and consumers may all implement SLSA differently, but they can still work with each other.

In this three-part series, we’ll explore how three fictional organizations would apply SLSA to meet their different needs. In doing so, we will answer some of the main questions that newcomers to SLSA have:

Part 1: The basics

  • How and when do you verify a package with SLSA?
  • How to handle artifacts without provenance?

Part 2: The details

  • Where is the provenance stored?
  • Where is the appropriate policy stored and who should verify it?
  • What should the policies check?
  • How do you establish trust & distribute keys?

Part 3: Putting it all together

  • What does a secure, heterogeneous supply chain look like?

The Situation

Our fictional example involves three organizations that want to use SLSA:

Squirrel: a package manager with a large number of developers and users

Oppy: an open source operating system with an enterprise distribution

Acme: a mid sized enterprise.

Squirrel wants to make SLSA as easy for their users as possible, even if that means abstracting some details away. Meanwhile, Oppy doesn’t want to abstract anything away from their users under the philosophy that they should explicitly understand exactly what they’re consuming.

Acme is trying to produce a container image that contains three artifacts:

  1. The Squirrel package ‘foo’
  2. The Oppy package ‘baz’
  3. A custom executable, ‘bar’, written by Acme employees

This series demonstrates one approach to using SLSA that lets Acme verify the Squirrel and Oppy packages ‘foo’ and ‘baz’ and its customers verify the container image. Though not every suggested solution is perfect, the solutions described can be a starting point for discussion and a foundation for new solutions.

Basics

In order to SLSA, Squirrel, Oppy, and Acme will all need SLSA capable build services. Squirrel wants to give their maintainers wide latitude to pick a builder service of their own. To support this, Squirrel will qualify some build services at specific SLSA levels (meaning they can produce artifacts up to that level). To start, Squirrel plans to qualify GitHub Actions using an approach like this, and hopes it can achieve SLSA 4 (pending the result of an independent audit). They’re also willing to qualify other build services as needed. Oppy on the other hand, doesn’t need to support arbitrary build services. They plan to have everyone use their Autobuilder network which they hope to qualify at SLSA 4 (they’ll conduct the audit/certification themselves). Finally, Acme plans to use Google Cloud Build which they’ll self-certify at SLSA 4 (pending the result of a Google-conducted audit).

Squirrel, Oppy, and Acme will follow a similar qualification process for the source control systems they plan to support.

Verification options

Full verification

At some point, one or more of the organizations will need to do full verification of each artifact to determine if it is acceptable for a given use case. This is accomplished by checking if the artifact meets the appropriate policy.

Typically, full verification would take place with SLSA provenance, source attestations, and perhaps other specialized attestations (like vulnerability scan results). While having to coordinate this data for all of its dependencies seems like a lot of work to Acme, they’re prepared to do full verification if Squirrel and Oppy are unable to.

Delegated verification

When Acme isn’t using full verification, they can instead use delegated verification where they check if an artifact is acceptable for a use case by checking if some other trusted party who performed a full verification (such as Squirrel or Oppy) believes the artifact is acceptable.

Delegated verification is easier to perform quickly with limited data and network connectivity. It may also be easier for some users who value if someone they trust verified the artifact is good.

Squirrel likes how easy delegated verification would make things for their users and plans to support it by creating a Verification Summary Attestation (VSA) when they perform full verification.

When to verify

Verification (full or delegated) could happen at a number of different times.

On import to repo

Squirrel plans to perform full verification when an artifact is published to their repo. This will ensure that packages in the repo have met their corresponding policy. It’s also helpful because all the required data can be gathered when latency isn’t critical.

If this were the only time verification is performed, it would put the repository’s storage in the trusted computing base (TCB) of its users. Squirrel’s plans to use delegated verification (and issue VSAs) can prevent this. The signature on the VSA will prevent the artifacts from being tampered with while sitting in storage, even if they’re just SLSA 0. Downstream users will just need to verify the VSA.

Acme also wants to do some sort of verification on the import to their internal repo since it simplifies their security story. They’re not quite sure what this will look like yet.

On install

Acme also wants to do verification when an artifact is actually installed since it can remove a number of intermediaries from their TCB (their repo, the network, upstream storage systems).

If they perform full verification at install then they must gather all the required information. That could be a lot of data, but it might be simplified by gathering the data from external sources and caching it in their internal repo. A larger problem is that it requires Acme to have established trust in all parties that produced that information (e.g. every builder of every package). For a complex supply chain that may be difficult.

If Acme performs delegated verification, they only need the VSA for the packages being installed and to explicitly trust a handful of parties. This allows the complex full verification to be performed once while allowing all users of that package to perform a much simpler operation.

Given these tradeoffs Acme prefers delegated verification at install time. Squirrel also really likes the idea and plans to build install time verification directly into the Squirrel tool.


On use
Verification could also take place each time an artifact is actually used. In this model, latency and reliability are very important (a sudden increase in site traffic may necessitate a scaling operation launching many new jobs).

Time of use verification allows the most context with which decisions can be made (“is this job allowed to run this code and is it free from vulns right now?”). It also allows policy changes to affect already built & installed software (which may or may not be desirable).

Acme wants their users to be able to verify on use without too many dependencies so they plan to provide VSAs users can use to perform delegated verification when they start the container (perhaps using something like Kyverno).

How to handle artifacts without provenance?

Inevitably a build or system may require that an artifact without ‘original’ provenance is used. In these cases it may be desirable for the importer to generate provenance that details where it got this artifact. For example, this generated provenance shows that http://example.com/foo.tgz with sha256:abc was imported by ‘auto-importer’:

Such an artifact would likely not be accepted at higher SLSA levels, but the provenance can be used to: 1) prevent tampering with the artifact after it’s been imported and 2) be a data point for future analysis (e.g. should we prioritize asking for foo.tgz to be distributed with native SLSA provenance?).

Acme might be interested in taking this approach at some point, but they don’t need it at the moment.

Next time

In our next post we’ll cover specific approaches that can be used to answer questions like “where should attestations and policies be stored?” and “how do I trust the attestations that I receive?”

/by

Industroyer2: Industroyer reloaded

This ICS-capable malware targets a Ukrainian energy company

The post Industroyer2: Industroyer reloaded appeared first on WeLiveSecurity

/by