Dan Robinson

This account is verified. Learn more

@danlovesproofs

Detail, prev Heap

detail.dev Joined January 2013

320 Following 4.3K Followers 948 Posts

Latest posts 5

Pinned post

Dan Robinson @danlovesproofs 2d

We built the vuln scanner we wanted to use but couldn't find.

Introducing Vuln Scans in Detail!

It uses the same abliterated models attackers are using to create havoc across the internet right now.

Under the hood we are:
- Spinning up your dev environment in a sandbox
- Throwing an enormous amount of abliterated model tokens at trying to hack your code
- Cross-checking your supply chain with cve/.now from Sazabi, to find any supply chain vulns that are exploitable in your app

This is all happening within a cloud dev environment. We will not hack your prod system.

The abliterated models are scary good. We're finding nasty issues in every repo we scan. We've found 13k vulns so far, and the majority are already fixed.

We see the current moment as an all-hands-on-deck situation. Agent swarms are stringing together minor-seeming vulns across different apps to hack systems in new and unexpected ways. We all need to find and patch an enormous number of vulns, fast, or the internet is in trouble.

You don't even have to be a target to get hacked right now. Your entire product might be a stepping stone in an attack aimed somewhere else.

We can remediate findings for you (i.e. send you PRs that fix the vulns), or you can consume them via your agent of choice, or in your ticket tracker of choice.

If you need help or advice on getting your system secure fast, please get in touch. We have helped teams of all sizes adapt to the current moment. DM me.

We're delivering these scans at-cost, because it's all-hands-on-deck. We hope you'll get one today.

1:26

Dan Robinson @danlovesproofs 2d

I actually learned about this from our own vuln scanner.

The abliterated models kept finding vulnerabilities like these, where a third party could inject malicious code straight into a customer's deploy.

I thought this was our agent being stupid. (Why are you finding vulns in people's CI??)

Took a few examples for me to realize this is a very real weakpoint and almost nobody is robust to it yet.

But the good news is it's very easy to fix once you know about it.

Dan Robinson Verified account @danlovesproofs 3d

Hack vector we're seeing in almost every customer codebase: github actions that aren't pinned to specific versions.

Github actions are build steps that run in CI and in deploy workflows. There are third party actions that do all kinds of utility operations: list changed files, log in to Docker, deploy to github pages... etc. Everyone uses them.

The problem is that their behavior can change. This is code that runs in your CI that can change under you at any time. It isn't versioned by your own version control. A third party can change what these actions do whenever they want.

A lot of very widely used utilities are managed by solo devs on their personal github accounts: peaceiris/actions-gh-pages, dorny/paths-filter, appleboy/ssh-action.

If these github accounts get taken over, the attacker can run arbitrary code within your github runners: exfiltrate your code, steal whatever secrets are in CI, even inject code changes into deploys.

A lot of github workflows pin to a version, like dorny/paths-filter@v3. This is not good enough, because those version tags can be changed at any time to point to new commits. You need to pin to a specific sha, like dorny/paths-filter@0e4a8c6effa4802afeda77dc8d303f8176d7dfad.

This happened last year. Attackers compromised a popular github action. (A simple util that listed files changed in a PR.) They shipped a malicious version of the github action, and then they retroactively changed version tags like "v1.0.0" to point to that compromised code. They used this to steal secrets from 23,000 repos.

This is a really broad amplification vector that will take you very little effort to avoid upfront. I'm not sure if this category of vuln even has a name, but it's a ticking timebomb.

What we're doing for our own code:
1. Switch all github actions to pinned shas
2. Add a lint rule that makes sure all github workflows use pinned shas, not any other kind of version tag

Both of these are oneshot-able in your agent of choice.
View quoted post on X

Dan Robinson @danlovesproofs 3d

Hack vector we're seeing in almost every customer codebase: github actions that aren't pinned to specific versions.

Github actions are build steps that run in CI and in deploy workflows. There are third party actions that do all kinds of utility operations: list changed files, log in to Docker, deploy to github pages... etc. Everyone uses them.

The problem is that their behavior can change. This is code that runs in your CI that can change under you at any time. It isn't versioned by your own version control. A third party can change what these actions do whenever they want.

A lot of very widely used utilities are managed by solo devs on their personal github accounts: peaceiris/actions-gh-pages, dorny/paths-filter, appleboy/ssh-action.

If these github accounts get taken over, the attacker can run arbitrary code within your github runners: exfiltrate your code, steal whatever secrets are in CI, even inject code changes into deploys.

A lot of github workflows pin to a version, like dorny/paths-filter@v3. This is not good enough, because those version tags can be changed at any time to point to new commits. You need to pin to a specific sha, like dorny/paths-filter@0e4a8c6effa4802afeda77dc8d303f8176d7dfad.

This happened last year. Attackers compromised a popular github action. (A simple util that listed files changed in a PR.) They shipped a malicious version of the github action, and then they retroactively changed version tags like "v1.0.0" to point to that compromised code. They used this to steal secrets from 23,000 repos.

This is a really broad amplification vector that will take you very little effort to avoid upfront. I'm not sure if this category of vuln even has a name, but it's a ticking timebomb.

What we're doing for our own code:
1. Switch all github actions to pinned shas
2. Add a lint rule that makes sure all github workflows use pinned shas, not any other kind of version tag

Both of these are oneshot-able in your agent of choice.

Dan Robinson @danlovesproofs Oct 31

Northflank hacked today. All environment variables stolen.

Railway, TiDB Cloud last week. OpenCode the week before.

These are good teams. They are not clowns. What they have in common is that they contain enormous numbers of keys, which makes them huge targets.

The defensive tools aren't good enough right now for small engineering teams to defend themselves against that kind of ferocious attention. Even very competent teams.

If you want to keep your product safe, the meta right now appears to be: avoid amplification vectors.

If a service is run by a small team, and hacking that service lets an attacker hit a large number of downstream targets, that's a magnet for hackers. A defender with small-company resources is not set up to succeed. We're going to keep seeing these kinds of attacks that target amplification vectors.

That means:
- Use BYOC infra products, not PaaS. Host your app directly. Host your sandboxes directly. (This is a lot easier than it was a year ago!)
- Remove your third party js, or pin changes to it.
- Stay on top of your code-level deps. (I like cve.now.)

I'm cautiously optimistic that the tools for defenders are going to get better really fast and we're going to be able to use PaaS again, but right now anything that has a lot of keys and isn't run by a team with hyperscalar-level resources seems like an unacceptable risk.

cve.now cve.now: a free CVE feed for agents A free CVE feed for agents.

Dan Robinson @danlovesproofs Oct 30

Hacktober is going to create a lot of FUD around new SaaS products. We need a new kind of certification that software is safe to use.

Huge opportunity to build that right now and displace SOC 2, which has been a bit of a polite fiction for quite some time now.

We need whitehat agent swarms with a certification on top.

As a buyer living in Black October, I want to be able to answer questions like: "is this vendor going to get hacked by an agent swarm tomorrow?" A SOC 2 report does not remotely answer this question.

But I would trust a document from a trusted tester that says: "we threw a sophisticated agent swarm at this vendor for a week, trying everything from hacking their infra to phishing their employees, here's how they did."

Give me a pentest for your whole org. One that simulates the threat we're waking up to, and evolves as the threats evolve.