Yet another APT group that exploited the ProxyLogon vulnerability in March 2021
The post FamousSparrow: A suspicious hotel guest appeared first on WeLiveSecurity
A few months ago we announced that we started signing all distroless images with cosign, which allows users to verify that they have the correct image before starting the build process. Signing our images was our first step towards fully securing the distroless supply chain. Since then, we’ve implemented even more accountability in our supply chain and are excited to announce that distroless builds have achieved SLSA 2. SLSA is a security framework for increasing supply chain security, and Level 2 ensures that the build service is tamper resistant.
This means that in addition to a signature, each distroless image now has an associated signed provenance. This provenance is an in-toto attestation and includes information around how each image was built, what command was run, and what build system was used. It also includes any special parameters that were passed in, the exact commit the images were built at, and more. This provenance is a useful tool for builds that need to be audited in the future.
Achieving SLSA 2 required some changes to the distroless build pipeline: we set up Tekton Pipelines and Tekton Chains in a GKE cluster to automate building images and generating provenance. Every time a pull request is merged to the distroless Github repo, a Tekton Pipeline is triggered. This Pipeline builds the distroless images, and Tekton Chains is responsible for generating signed provenance for each image. Tekton Chains stores the signed provenance alongside the image in an OCI registry and also stores a record of the provenance in the rekor transparency log.
Don’t trust us?
You can try the build yourself. Because distroless builds are reproducible, all the information to replicate the build is in the provenance, and you or a trusted third party can build the image yourselves and verify the build is correct by matching image digests.
You can verify an attestation for a distroless image with cosign and the distroless public key:
$ cosign verify-attestation -key cosign.pub gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91
Verification for gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91 —
The following checks were performed on each of these signatures:
– The cosign claims were validated
– The signatures were verified against the specified public key
– Any certificates were verified against the Fulcio roots.
…
And you can find the provenance for the image in the rekor transparency log with the rekor-cli tool. For example, you could find the provenance for the above image by using the image’s digest and running:
$ rekor-cli search –sha sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91
af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8
$ rekor-cli get –uuid af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8 –format json | jq -r .Attestation | base64 –decode | jq
{
“_type”: “distroless-provenance”,
“predicateType”: “https://tekton.dev/chains/provenance”,
“subject”: [
{
“name”: “gcr.io/distroless/base”,
“digest”: {
“sha256”: “703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d”
}
},
{
“name”: “gcr.io/distroless/base”,
“digest”: {
“sha256”: “d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce”
}
},
{
“name”: “gcr.io/distroless/base”,
“digest”: {
“sha256”: “2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661”
}
},
{
“name”: “gcr.io/distroless/base”,
“digest”: {
“sha256”: “4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91”
}
},
{
“name”: “gcr.io/distroless/base”,
“digest”: {
“sha256”: “dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980”
}
},
{
“name”: “gcr.io/distroless/base-debian10”,
“digest”: {
“sha256”: “2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661”
}
},
{
“name”: “gcr.io/distroless/base-debian10”,
“digest”: {
“sha256”: “703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d”
}
},
{
“name”: “gcr.io/distroless/base-debian10”,
“digest”: {
“sha256”: “4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91”
}
},
{
“name”: “gcr.io/distroless/base-debian10”,
“digest”: {
“sha256”: “d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce”
}
},
{
“name”: “gcr.io/distroless/base-debian10”,
“digest”: {
“sha256”: “dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980”
}
},
{
“name”: “gcr.io/distroless/base-debian11”,
“digest”: {
“sha256”: “c9507268813f235b11e63a7ae01526b180c94858bd718d6b4746c9c0e8425f7a”
}
},
{
“name”: “gcr.io/distroless/cc”,
“digest”: {
“sha256”: “4af613acf571a1b86b1d3c50682caada0b82024e566c1c4c2fe485a70f3af47d”
}
},
{
“name”: “gcr.io/distroless/cc”,
“digest”: {
“sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”
}
},
{
“name”: “gcr.io/distroless/cc”,
“digest”: {
“sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”
}
},
{
“name”: “gcr.io/distroless/cc-debian10”,
“digest”: {
“sha256”: “4af613acf571a1b86b1d3c50682caada0b82024e566c1c4c2fe485a70f3af47d”
}
},
{
“name”: “gcr.io/distroless/cc-debian10”,
“digest”: {
“sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”
}
},
{
“name”: “gcr.io/distroless/cc-debian10”,
“digest”: {
“sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”
}
},
{
“name”: “gcr.io/distroless/java”,
“digest”: {
“sha256”: “deb41661be772c6256194eb1df6b526cc95a6f60e5f5b740dda2769b20778c51”
}
},
{
“name”: “gcr.io/distroless/nodejs”,
“digest”: {
“sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”
}
},
{
“name”: “gcr.io/distroless/nodejs”,
“digest”: {
“sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”
}
},
{
“name”: “gcr.io/distroless/nodejs”,
“digest”: {
“sha256”: “f106757268ab4e650b032e78df0372a35914ed346c219359b58b3d863ad9fb58”
}
},
{
“name”: “gcr.io/distroless/nodejs-debian10”,
“digest”: {
“sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”
}
},
{
“name”: “gcr.io/distroless/nodejs-debian10”,
“digest”: {
“sha256”: “f106757268ab4e650b032e78df0372a35914ed346c219359b58b3d863ad9fb58”
}
},
{
“name”: “gcr.io/distroless/nodejs-debian10”,
“digest”: {
“sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”
}
},
{
“name”: “gcr.io/distroless/python3”,
“digest”: {
“sha256”: “aa8a0358b2813e8b48a54c7504316c7dcea59d6ae50daa0228847de852c83878”
}
},
{
“name”: “gcr.io/distroless/python3-debian10”,
“digest”: {
“sha256”: “aa8a0358b2813e8b48a54c7504316c7dcea59d6ae50daa0228847de852c83878”
}
},
{
“name”: “gcr.io/distroless/static”,
“digest”: {
“sha256”: “9acfd1fdf62b26cbd4f3c31422cf1edf3b7b01a9ecee00a499ef8b7e3536914d”
}
},
{
“name”: “gcr.io/distroless/static”,
“digest”: {
“sha256”: “e50641dbb871f78831f9aa7ffa59ec8f44d4cc33ae4ee992c9f4b046040e97f2”
}
},
{
“name”: “gcr.io/distroless/static-debian10”,
“digest”: {
“sha256”: “9acfd1fdf62b26cbd4f3c31422cf1edf3b7b01a9ecee00a499ef8b7e3536914d”
}
},
{
“name”: “gcr.io/distroless/static-debian10”,
“digest”: {
“sha256”: “e50641dbb871f78831f9aa7ffa59ec8f44d4cc33ae4ee992c9f4b046040e97f2”
}
}
],
“predicate”: {
“invocation”: {
“parameters”: [
“MANIFEST_SUBSECTION={string 0 []}”,
“CHAINS-GIT_COMMIT={string 976c1c9bc178ac0371d8888d69893145c3df09f0 []}”,
“CHAINS-GIT_URL={string https://github.com/GoogleContainerTools/distroless []}”
],
“recipe_uri”: “task://distroless-provenance”,
“event_id”: “531c282f-806e-41e4-b3ad-b596c4283381”,
“builder.id”: “tekton-chains”
},
“recipe”: {
“steps”: [
{
“entryPoint”: “#!/bin/sh\nset -ex\n\n# get the digests for a subset of images built, and store in the IMAGES result\ngo run provenance/provenance.go images $(params.MANIFEST_SUBSECTION) > $(results.IMAGES.path)\n”,
“arguments”: null,
“environment”: {
“container”: “provenance”,
“image”: “docker.io/library/golang@sha256:cb1a7482cb5cfc52527c5cdea5159419292360087d5249e3fe5472f3477be642”
},
“annotations”: null
}
]
},
“metadata”: {
“buildStartedOn”: “2021-09-16T00:03:04Z”,
“buildFinishedOn”: “2021-09-16T00:04:36Z”
},
“materials”: [
{
“uri”: “https://github.com/GoogleContainerTools/distroless”,
“digest”: {
“revision”: “976c1c9bc178ac0371d8888d69893145c3df09f0”
}
}
]
}
}
As you might guess, our next step is getting distroless to SLSA 3, which will require adding non-falsifiable provenance and isolated builds to the distroless supply chain. Stay tuned for more!
Misconfigurations of cloud resources can lead to various security incidents and ultimately cost your organization dearly. Here’s what you can do to prevent cloud configuration conundrums.
The post Plugging the holes: How to prevent corporate data leaks in the cloud appeared first on WeLiveSecurity
Security is a cat-and-mouse game. As attackers innovate, browsers always have to mount new defenses to stay ahead, and Chrome has invested in ever-stronger multi-process architecture built on sandboxing and site isolation. Combined with fuzzing, these are still our primary lines of defense, but they are reaching their limits, and we can no longer solely rely on this strategy to defeat in-the-wild attacks.
Last year, we showed that more than 70% of our severe security bugs are memory safety problems. That is, mistakes with pointers in the C or C++ languages which cause memory to be misinterpreted.
This sounds like a problem! And, certainly, memory safety is an issue which needs to be taken seriously by the global software engineering community. Yet it’s also an opportunity because many bugs have the same sorts of root-causes, meaning we may be able to squash a high proportion of our bugs in one step.
Chrome has been exploring three broad avenues to seize this opportunity:
- Make C++ safer through compile-time checks that pointers are correct.
- Make C++ safer through runtime checks that pointers are correct.
- Investigating use of a memory safe language for parts of our codebase.
“Compile-time checks” mean that safety is guaranteed during the Chrome build process, before Chrome even gets to your device. “Runtime” means we do checks whilst Chrome is running on your device.
Runtime checks have a performance cost. Checking the correctness of a pointer is an infinitesimal cost in memory and CPU time. But with millions of pointers, it adds up. And since Chrome performance is important to billions of users, many of whom are using low-power mobile devices without much memory, an increase in these checks would result in a slower web.
Ideally we’d choose option 1 – make C++ safer, at compile time. Unfortunately, the language just isn’t designed that way. You can learn more about the investigation we’ve done in this area in Borrowing Trouble: The Difficulties Of A C++ Borrow-Checker that we’re also publishing today.
So, we’re mostly left with options 2 and 3 – make C++ safer (but slower!) or start to use a different language. Chrome Security is experimenting with both of these approaches.
You’ll see major investments in C++ safety solutions – such as MiraclePtr and ABSL/STL hardened modes. In each case, we hope to eliminate a sizable fraction of our exploitable security bugs, but we also expect some performance penalty. For example, MiraclePtr prevents use-after-free bugs by quarantining memory that may still be referenced. On many mobile devices, memory is very precious and it’s hard to spare some for a quarantine. Nevertheless, MiraclePtr stands a chance of eliminating over 50% of the use-after-free bugs in the browser process – an enormous win for Chrome security, right now.
In parallel, we’ll be exploring whether we can use a memory safe language for parts of Chrome in the future. The leading contender is Rust, invented by our friends at Mozilla. This is (largely) compile-time safe; that is, the Rust compiler spots mistakes with pointers before the code even gets to your device, and thus there’s no performance penalty. Yet there are open questions about whether we can make C++ and Rust work well enough together. Even if we started writing new large components in Rust tomorrow, we’d be unlikely to eliminate a significant proportion of security vulnerabilities for many years. And can we make the language boundary clean enough that we can write parts of existing components in Rust? We don’t know yet. We’ve started to land limited, non-user-facing Rust experiments in the Chromium source code tree, but we’re not yet using it in production versions of Chrome – we remain in an experimental phase.
That’s why we’re pursuing both strategies in parallel. Watch this space for updates on our adventures in making C++ safer, and efforts to experiment with a new language in Chrome.
The group used phishing, BEC and other types of attacks to swindle victims out of millions
The post European police dismantle cybercrime ring with ties to Italian Mafia appeared first on WeLiveSecurity
Analysis of Numando banking trojan, steps to mitigate attack surface, and more! – Week in security with Tony Anscombe
The post Week in security with Tony Anscombe appeared first on WeLiveSecurity
The (probably) penultimate post in our occasional series demystifying Latin American banking trojans.
The post Numando: Count once, code twice appeared first on WeLiveSecurity
We recently pledged to provide $100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities. As part of this commitment, we are excited to announce our support of the Open Source Technology Improvement Fund (OSTIF) to improve security of eight open-source projects.
Google’s support will allow OSTIF to launch the Managed Audit Program (MAP), which will expand in-depth security reviews to critical projects vital to the open source ecosystem. The eight libraries, frameworks and apps that were selected for this round are those that would benefit the most from security improvements and make the largest impact on the open-source ecosystem that relies on them. The projects include:
- Git – de facto version control software used in modern DevOps.
- Lodash – a modern JavaScript utility library with over 200 functions to facilitate web development, can be found in most environments that support JavaScript, which is most of the world wide web.
- Laravel – a php web application framework that is used by many modern, full-stack web applications, including integrations with Google Cloud.
- Slf4j – a logging facade for various Java logging frameworks.
- Jackson-core & Jackson-databind – a JSON for Java, Streaming API, and extra shared components and the base for Jackson data-bind package.
- Httpcomponents-core & Httpcomponents-client – these projects are responsible for creating and maintaining a toolset of low-level Java components focused on HTTP and associated protocols.
We are excited to help OSTIF build a safer open source environment for everyone. If you are interested in getting involved or learning more please visit the OSTIF blog.
The most recent Patch Tuesday includes a fix for the previously disclosed and actively exploited remote code execution flaw in MSHTML.
The post Microsoft Patch Tuesday fixes actively exploited zero‑day and 85 other flaws appeared first on WeLiveSecurity
The Facebook-owned messaging service plans to roll out the feature to both iOS and Android users in the coming weeks.
The post WhatsApp announces end‑to‑end encrypted backups appeared first on WeLiveSecurity
Easy Contact
253 Main Ave, Passaic NJ 07055Call 973-777-5656
info@advantagecomputers.com
Fax 973-777-5821
© 2024 ~ All Rights Reserved
Advantage Computer Solutions