If only the company behind VSCode, the company behind NPM and the company behind GitHub could get together and figure out a solution to this.
i mean, then you say it like that…
GitHub confirms breach of 3,800 repos via malicious VSCode extension
81–90 of 488 posts
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#82[dead]
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#83Earlier quoted context omitted.
> I built my own extensions if I needed them. You're a programmer, right? The whole point of extensibility is that you, or your company, can program what you need from your IDE, Dude, get real. We don't all have the luxury of being able to engage in endless IDE extension programming side quests just to do our day jobs. And even if we did, there's the reality that whatever you produce is probably not nearly as feature…
> just to do our day jobs. Ah, there it is. The root of most problems in the software industry: people who hate programming and avoid doing it as much as possible, because they only got into it for the money. I have no problem writing extensions in my spare time because programming is fun. Because I know how to program, like, actually program and not just copypaste stuff off StackOverflow, it doesn't take years to wr…
bait
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#84Earlier quoted context omitted.
As others have said it's just a fraction. I'm in a medium size tech-related company and we have 7500+ in one Github org. We have two orgs, so altogether easily 10K+. Of course most of it is stale, obsolete, sandbox, personal tools, etc. I wouldn't be surprised if Github would have 100K+ internal repos or even more.
no pruning of repos?
No OP but I used to work at a large company with a similar number of repos.
When I left about a year ago, we had just started (after being on Github for almost 8 years) an ongoing project of first archiving old/outdated repos in place, and then moving them to an "archived" sub-org, and waiting to see if anyone complained.
Previously no one wanted to outright delete or remove repos because of the risk that someone somewhere was relying on it, and also there was no actual downside to just leaving them there (no cost savings, no imminent danger other than clutter, etc), so resources were never allocated to do it. There was always something more important to work on.
In an org with a higher floor of engineering management, a proactive program for removing unused or outdated repos would absolutely be expected though I think.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#85i'd love to be able to use fine grained tokens with gh and not expose every repo and org that i am connected to on github, but you can't see the results of a github actions check that way (no 'Checks' permission available). hoping these breaches push things in the direction of access being less annoying to manage.
The problem is that the main target for these repos are the internal IaaS type repos that contain much of the juicy information.
A fine grained token is likely to have read access to the IaaS repo as that is likely the very repo they are operating on when the malware compromises them.
3800 repos up for blackmail may make a good headline but it's likely that Github don't really care about 3798 of those repos being made public. It'd be annoying for those 3798 to be made public but they can deal with that. It's the 2 repos that contain really important stuff that they really don't want to be made public. You can't rely on fine grained tokens to limit the leak of these things as, at some point, someone with that very access will get compromised.
Limiting TTL on tokens/auth isn't a perfect solution either. If the token is leaked via some malware it can be used to clone repos within minutes (even seconds) of being leaked. No-one wants to have to perform 2FA every few seconds in order to get on with their day.
IP based restrictions may help, but then the malware would probably evolve to include a tailscale/wireguard key so that the clone/exfiltration is done from the existing IP address and then the data is proxied away separately.
Future dev environments are going to be heavily sandboxed in terms of "do github stuff in this sandbox, copy files to another sandbox to do package updates, vet everything coming back, etc"
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#86Has there been any confirmation of this from a source other than X? It's weird that that's the only source, and therefore makes me distrust the entire story.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#87Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#88And now, the hackers will be able to scan the repos for more vulnerabilities. Vulnerabilities all the way down.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#89i'd love to be able to use fine grained tokens with gh and not expose every repo and org that i am connected to on github, but you can't see the results of a github actions check that way (no 'Checks' permission available). hoping these breaches push things in the direction of access being less annoying to manage.
I was noodling around with personal access tokens today on GitHub and found out that you actually can restrict tokens to specific repositories, orgs, etc. Not sure if actions is a scope that is available or not.
Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension
#90Earlier quoted context omitted.
> If companies continue to not pay the ransom then we're going to get a lot more things published Paying the ransom means your data still gets leaked and now you're out of money and embarrassed. Why would they ever, ever, delete the data?
If paying the ransom doesn't stop your data getting leaked, nobody will pay the ransom. There is a rational basis for the ransomers to follow through with the deletion. Even the mob did provide "protection" when they coerced you into paying for it.
This sounds like a naive presumption. Are ransomware distributors well known for operating within strict hierarchies bound by culturally-ingrained traditions, or acting in the best interests of their own “greater good”?
Last I heard, teenagers can deploy ransomware with minimal technical knowledge or skill.