Live data from Hacker News

Tailscale didn't stop the Hugging Face intrusion

tailscale.com

171–180 of 239 posts

Re: Tailscale didn't stop the Hugging Face intrusion

#171

Earlier quoted context omitted.

(Tailscale CEO) You have posted here multiple times that "none of the code has had a security audit" and that the SOC2 audit "is not the same thing." It's true that those two audits aren't the same thing. However, the SOC2 auditor confirms, in the published report, that Tailscale has regular and ongoing security audits including penetration tests and many kinds of code reviews. The security audit report, which you pe…

Read Skimmed the report (and cheers for not gating it behind request-to-obtain) and I'm a bit surprised to not see any mentions of pentests which I'd expect given the large surface you host. What gives?

(it seems they list it under the contract with Latacora, disregard)

Re: Tailscale didn't stop the Hugging Face intrusion

#172

How are you folks handling secrets in a simple way? - sops , ansible vault and similar seems too weak given the agent is gonna read them at some point if you have the pass available. - proxy injection seems too complicated and doesn’t cover all use cases.

Try not to: use AWS short-term credentials for anything there, federate with GitHub/GitLab job credentials where possible, etc. It’s easier and you never worry about rotation again.

If you can’t avoid it, use an automatically-rotated store and inject them as late as possible so an attacker needs to be able to get them out of a running process.

In all cases, look into restrictions: not just least privilege access but things like network restrictions so an attacker can’t just use the key on their own systems.

Re: Tailscale didn't stop the Hugging Face intrusion

#174
The problem with the long lived credentials is that they were not bound to origin/destination. Even though the origin for a CI pool should be a small number of CI orchestration boxes, and the destination should be a CI box. In Tailscale config, the should be scoped to machines with a "ci_node" property.

Since CI nodes should be dynamically provisioned VMs, they should have a unique CI ticket identity. A partial hash of ticket and node number in the DNS name, and as a tailnet property, would allow tight scoping. Alternatively, provision in a scoped IP subnet.

Bind your tokens to names linked to tickets. Programmatic infrastructure should always allow enumeration of the computation data flow graph.

Re: Tailscale didn't stop the Hugging Face intrusion

#175
post #129

Earlier quoted context omitted.

This all has the -aire of theatre. OH NOES THE POWERFUL AI GOT OUT Then everyone coming out with humbled determination about working together to responsibly use and contain this powerful technology for the greater good (and profit margin). I will not believe marketing gimmickry is not a large part of what's going on with every one of these "incidents".

I think part of it is we need to stop looking at the 'oh no it got out' and the 'what did it do with the prompt when no one is looking'. At the end of the day the probability that an AI gets out is unity, what it does while out is far more important. The fact they are hacking into systems at superhuman levels, or writing cryptominers on their own hacked internal systems is a much more interesting and telling story of…

I'm not really surprised that it hacked so many systems.

It was told via the prompt to act like a hacker and "solve" hacking problems, so treating every obstacle it faced as part of the problem isn't a wild tangent.

If it had been told to do something innocent, and decided the best way to succeed was the maliciously compromise other companies then I'd be more interested and worried.

Re: Tailscale didn't stop the Hugging Face intrusion

#176

Wow, this article is super smart marketing by tailscale. Not only do they list all the nice and expensive features, that can help in such a situation but they also show that someone at huggingface made a very stupid thing by writing a reusable auth key in an env file. Everyone using mesh VPNs like tailscale, netbird etc. knows that this is like leaving the keys right at the door.

Wait are people really do this so often this isn't even the default tailscale setup method.

I am quite surprised people consider this to be business as usual.

Huggingface for a serious service has never felt truly serious to me for reasons like these.

Re: Tailscale didn't stop the Hugging Face intrusion

#177

Earlier quoted context omitted.

This article is just an ad / public-service-announcement for various paid Tailscale features, though?

And you're under the impression that the purpose of a company blog is WHAT, exactly?

I don't think anyone is faulting Tailscale for using their blog to advertise, and no one is faulting Tailscale for how they handled this situation in general, or their response to it.

The issue is acting like their response is 'brave' in anyway, or altruistic. It can be considered admirable only to the extent any company doing a good job running its business can be.

This is a good, smart response to what happened. They are approaching this incident as a way to improve their product and offer a better service to their customers. That is good, and it is fine to reward them with your business in response. There is nothing wrong with making good business decisions, but it isn't something that we need to unduly respect.

Re: Tailscale didn't stop the Hugging Face intrusion

#178

Earlier quoted context omitted.

The majority of your security bulletins are as the result of third-party reports to you. Which, by definition, means they are not done by you, which means you don't know when they will be done or how much of your code base they are looking at. I think you know full well what I mean by a security audit. If you don't, go look at, for example, the ones that Mullvad publish for their software https://mullvad.net/en/blog/…

(Tailscale CEO) I don't know what to tell you. The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing. They don't need bulletins. Bugs that are found by other people are found, by definition, after release. They are therefore more likely to need a bulletin.

> The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing.

Either you didn't mean what you wrote, or you are saying that you never find problems internally after release.

Re: Tailscale didn't stop the Hugging Face intrusion

#179

> No “vulnerabilities” in Tailscale were found or exploited, and that might make it even more uncomfortable for us. [...] But, we're a security tool. Their intrusion is our intrusion, and it's our job to take it seriously. im a happy customer of tailscale, so i am obviously biased, but i have a lot of respect for this. they could have just stayed quiet and i dont think anyone would have bat an eye.

“How can we make this thing, that has nothing to do with us, about us and how good we are?”

(top story on HN)

I get it, Tailscale is great and all, but, are we being serious right now?

Re: Tailscale didn't stop the Hugging Face intrusion

#180

> No “vulnerabilities” in Tailscale were found or exploited, and that might make it even more uncomfortable for us. [...] But, we're a security tool. Their intrusion is our intrusion, and it's our job to take it seriously. im a happy customer of tailscale, so i am obviously biased, but i have a lot of respect for this. they could have just stayed quiet and i dont think anyone would have bat an eye.

Agreed its a tool, and it does not looks like any vulnerability was exploited on their end. However part of the blog is confusing to me. Long lived keys vs short lived have their own space in discussion, there are use cases, pros & and cons for the same. However it is not very clear how a short lived credential would have prevented the exploit in this case?
Post reply on HN