Mystery Git ransomware appears to blank commits, demands Bitcoin to rescue code Programmers say they've been hit by ransomware that seemingly wipes their Git repositories' commits and replaces them with a ransom note demanding Bitcoin. An unusual high number of developers have griped online about the effects of the software nasty, with at least two reports seen by El Reg referencing the freeware …
This post has been deleted by its author
Tell that to Coca-Cola or Colonel Sanders
To be fair, neither of those are actually secret. William Poundstone discusses both in Big Secrets or one of its sequels.
The Coca-Cola and KFC "secret recipes" are marketing gimmicks.
RC4 is another famous trade secret that didn't stay secret very long.
That said, I think the previous poster's generalization is relatively useless, like all generalizations.1
1"We all generalize from a single example. I know I do." (Steven Brust)
Since I have been using code repositories starting with Visual SourceSafe in 90s, through several others to GIT now I pretty much always use a GUI to check in my commits - I find GUIs make it much easier to review all of the changes I am committing
> I find GUIs make it much easier to review all of the changes I am committing
Diffs are definitely easier with GUI tools.
However for everything else cli is more powerful. Knowing the git cli means there is a lot more help available when you need to do something that is a little unusual.
Depends on how good the GUI is - not all of them are equal.
I can drop to the command line if I need to, but as 99% of the time I don't need the extra cli provides as workflows are quite simple I just stay in preferred GUI as it works well for me.
We are only using GIT because project team wanted it on their CV and never used any of the power of GIT (one conversation went they hadn't check in code yet as waiting for testing to finish )
Depends on how you define easier. Easier to me is path of least resistance. Using a terminal, I can diff files extremely quickly and with the precise logic I need meaning I don't have to scroll through endless diffs I don't care about.
It's more complicated, sure, but is it harder? After practice, no.
http://man7.org/linux/man-pages/man1/diff.1.html
A CLI is great when you know ahead of time what information you want to be displayed (and any bulk, or repetitive tasks).
A GUI is better for more investigative tasks (ie problem solving) where you don't know that you need something until you look at it.
The both have their place, and which you use most is more down to what your job involves.
Example of why not to use GUI: "Push merge immediately to Master" checkbox. Also when committing a large number of, for example, vendor files don't you just want to do $git add vendor/* instead of clicking all the down the list and then realising that you accidentally added something else as well?
Diffs are definitely easier with GUI tools.
For some, perhaps. Personally, I loathe GUI diff viewers.
Of course, whenever someone declares one way of working is "definitely" easier, or better, or more efficient, it's likely you won't have to go far to find a counterexample. Rhetorically, "definitely" is an adverb meaning "I can't be bothered to give this much thought".
How is it more productive than the CLI? Or better yet an IDE with GIT integration? I'm not extremely old school, but I'm not exactly new to dev either (20 years).
Introducing an additional tool seems wasteful and slow to me.
E.g. if I wanted to commit a change and push it to staging for testing I can do that with two or three quick commands from a single window on the CLI from the desktop session I'm already in.
With a GUI I have to faff around connecting to the remote box, firing up my GUI of choice, drilling down the branches etc and then pull the changes in.
Ok, I understand that few here know how git works ....
anybody who clones a git repo has all the commits ever pushed to the repo at the time he last cloned, fetched, pulled. These braindead are like, hey, lets delete something on the git server, and then ask for money, hehehehe ... where every single dev on the project has all the data, almost ... the guy who fetch/pull'd last and the guy who pushed the last commit have all the data, combined.
I have read the article:
The netizen added that the ransom note they received referenced gitsbackup[dot]com, and demanded about $560 in crypto-currency to un-fsck the repo.
They have apparently attacked [FL]OSS repos as well.
As for publishing the code, I guess the attackers are a bit thick, who do you think would trust them ? They could just as well come back every month and demand payment.... do not reward scum or you will attract more ...
https://security.stackexchange.com/questions/209448/gitlab-account-hacked-and-repo-wiped
See first update.
The more exposure the better
Was that with or without the rewritten commit inserting a nasty banking trojan into your project, with you listed as author?
In all seriousness, the largest threat I see here is lost chain of trust / integrity. The codebase would need a thorough external audit after being "recovered" by paying the hackers, and I guarantee next to no one would pay for that, especially not the small time commercial developers likely to be hit by this with no offline backups in the first place.
And if malware injection were to happen this way in a commercial application, would the bar be high enough to legally convict the developers on some form of negligence when downstream customer computers are infected? Especially if the code wasn't recovered from backups and compared or an external auditor paid with paper trail?
I wouldn't be paying - just resetting and uploading a clean copy.There are 4 of us that keep full repositories and we all work entirely via the CLI. We also keep more than one remote on different hosts.
None of us do any auto updates either - all done manually, barely any slower and much safer.
What this means to me is that the attacker doesn't have the code and there's no threat of them going over the source code for sensitive data or of making the code public.
His conclusion doesn't actually follow on.
The fact they've simply munged head means he hasn't lost data (despite their attempt to make it look otherwise).
But, that has no bearing on whether they have or haven't walked off with a copy of the codebase. Assuming it was the client they compromised, it'd be fairly trivial for them to have a push actually
- push to their servers, with those servers dynamically creating a reponto house it in
- munge head
- Do a force fast-forward push to the original origin to push the munged head
- Remove references to their server
I'm not saying that has happened. But nothing mentioned in the article is evidence enough to conclude they don't have the code
It is more likely though that those affected have had their credentials to the various hosting services leaked.
Could it be the case that someone has cracked some of the hashed passwords on the Linked-In leak and found themselves enough working GitHub credentials to make it worth their while?
I have recently had many, many emails about my degenerate porn habits with faked headers set to look like the mail came from my email account as proof of the successful hack. Those spam mails were citing an actual password, which was indeed the mail+password I used for linked-in and other on-line trash accounts "back then".
The LinkedIn breach was very productive for the criminal hacker community, but it was just one of many credential pools posted on Pastebin and other public platforms. We can also thank serial privacy violators/privateers like Equifax for their "contributions" to the resources now available to these new startups. Commercial software vendors, as usual, are all form and little function when it comes to countermeasures, because they feel safe in their assumption customers have no where else to go. Of course the greatest praise should be reserved for the leading national intelligence services whose seed money in the form of outsource contracts and leaked toolkits, not to mention inaction in the midst of attacks on the citizenry they're supposed to protect, has made life so much easier for these operators.
One recent study found on average nearly 1800 unique private keys leaked per day on github. I hate to employ the word "epidemic", which has lost all force as a metaphor thanks to misuse, but leaving sensitive data in public repositories is a widespread and serious problem.
/// Why this was not done before, I have no idea ///
Hello,
This is to inform you that the gitsbackup[.]com domain was suspended. It has been placed on the clientHold status and locked to prevent modifications in our system.
Thank you for letting us know about the issue.
------------------------
Regards,
Alex B.
Legal & Abuse Department
Namecheap Team
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
