Go typosquatting package relays info to tech firm(portswigger.net)
portswigger.net
Go typosquatting package relays info to tech firm
https://portswigger.net/daily-swig/suspicious-finds-researcher-discovers-go-typosquatting-package-that-relays-system-information-to-chinese-tech-firm
11 comments
Kudos for removing the nation from the title to neutralize the bait and keep it technical. I know this comment doesn't contribute much, just wanted to acknowledge the effort.
Code intake technique aside, in this case "typosquatting", the root of the problem is developers that are tasked with writing code choose instead just use others existing work without EVER reviewing nor understanding every line of that 'copied' code. While this code reuse technique has existed in many forms since the very first software languages were created the internet has just exacerbated the code sharing problem. As the world is coming to learn day after day that easy is not secure and if you copy code one better "trust but verify" however most people are just lazy. Here is a post I made 11 years ago and rest assured this "people are lazy" security compromise technique has been around a lot longer and will continue to prevail well into the future.
https://www.codeproject.com/Articles/30803/A-R-Live-Support-...
https://www.codeproject.com/Articles/30803/A-R-Live-Support-...
What's the first step in solving this?
Maybe list out my dependencies and spend one day a week auditing the most-risky, least-popular ones? Random audits where I make sure that my vendored dependencies or files like Cargo.lock haven't changed when I wasn't looking?
Do something like Firefox did with Graphite, and compile as many dependencies as possible into a webasm sandbox so they can't do I/O?
Years ago I thought "Haskell's I/O discipline is cool, but man it looks inconvenient..." Now I wonder if that will become the mandate for new languages. I imagine it's hard to enforce in native code. At least Rust has a strong foundation for both running, and running as, wasm, so maybe in the future it'll be easy to say "Run this function / these functions in a sandbox, nevermind the cost, and write all the glue code for me."
Ironicially, a webasm runtime, especially if it has a JIT, is far too large a project for me to audit on company time... but at least it's also very popular.
Maybe list out my dependencies and spend one day a week auditing the most-risky, least-popular ones? Random audits where I make sure that my vendored dependencies or files like Cargo.lock haven't changed when I wasn't looking?
Do something like Firefox did with Graphite, and compile as many dependencies as possible into a webasm sandbox so they can't do I/O?
Years ago I thought "Haskell's I/O discipline is cool, but man it looks inconvenient..." Now I wonder if that will become the mandate for new languages. I imagine it's hard to enforce in native code. At least Rust has a strong foundation for both running, and running as, wasm, so maybe in the future it'll be easy to say "Run this function / these functions in a sandbox, nevermind the cost, and write all the glue code for me."
Ironicially, a webasm runtime, especially if it has a JIT, is far too large a project for me to audit on company time... but at least it's also very popular.
If one does not take the time needed to review ALL copied code which is to be included in a project then is that particular individual held responsible for the entirety of an impacting negative result should that code be the source of said impact? The individual was tasked with 'complete this portion of the project' and instead of writing the code and bettering their understanding of said project, of which they will very likely be a source of knowledge to support, the individual saved themselves the mental effort and included copied code. I have also seen the exact same “corner cutting” in the M$ world where developers submit an expense report in which they purchased a component library without ANY consideration of the licensing or the production costs around that components production architectural deployment. As to my latter point you will find the Payment Card Industry (PCI) planning or soon requiring third party assertions on black box code components used in a system but as a multi decade payments entrepreneur/architect/developer this is pure foolishness because if you do not own all the code AND understand it there is no way to know what it may do in the future.
Would you consume candy from a stranger? Would you pick up a piece of candy off the ground which appears unaltered and consume it? When one applies logic to other life safety situations hopefully some can see the analogous similarities to just picking up code off the ground and putting it into one's mouth.
This sh!t storm is just getting started as more and more “no code” businesses are introduced and industries adopt the “easy way” in fear of missing out on “exponential” income. Most are taught at a very young age that fire is hot but until one gets burned the concept of hot is not personally comprehended. The majority of people are lazy and will always take the easy route but as the world comes to learn from more and more catastrophic global breaches, easy is very often not secure.
Now consider critical to life medical device companies that copy code without review.
Trust but verify.
Would you consume candy from a stranger? Would you pick up a piece of candy off the ground which appears unaltered and consume it? When one applies logic to other life safety situations hopefully some can see the analogous similarities to just picking up code off the ground and putting it into one's mouth.
This sh!t storm is just getting started as more and more “no code” businesses are introduced and industries adopt the “easy way” in fear of missing out on “exponential” income. Most are taught at a very young age that fire is hot but until one gets burned the concept of hot is not personally comprehended. The majority of people are lazy and will always take the easy route but as the world comes to learn from more and more catastrophic global breaches, easy is very often not secure.
Now consider critical to life medical device companies that copy code without review.
Trust but verify.
It's worth noting that Haskell has escape hatches for doing IO from outside the IO monad, so that wouldn't exactly solve this problem.
> The fact that developers have to explicitly write out which module to import in every file where they want to use an external package makes it less likely that any confusion can happen
Feels to me like they are joking.
When you have to type out the name in every single file you have a chance of making the mistake every single time you're typing it; while a centralised approach allows one to concentrate on the added import.
One of the vectors of attack using this library is to create a Merge Request that slightly changes the name of the import in one of the N files you are changing. Good luck spotting that as a reviewer.
Feels to me like they are joking.
When you have to type out the name in every single file you have a chance of making the mistake every single time you're typing it; while a centralised approach allows one to concentrate on the added import.
One of the vectors of attack using this library is to create a Merge Request that slightly changes the name of the import in one of the N files you are changing. Good luck spotting that as a reviewer.
There would also (by necessity) be a change in the centralized `go.mod` file (and `go.sum`) that corresponds to the addition of the new, almost-duplicate package being imported. Definitely spottable. Unless someone is using the deprecated GOPATH functionality, in which case things might be harder to spot. However, the author specifically pointed out how rare this attack seems to be in the Go ecosystem.
If the author identified malicious repos on user accounts that were created solely to make those malicious repos... it seems like something the author should have reported to GitHub. I wonder if GitHub would actually do anything, though.
If the author identified malicious repos on user accounts that were created solely to make those malicious repos... it seems like something the author should have reported to GitHub. I wonder if GitHub would actually do anything, though.
By the time it’s in your go.mod, the malicious software has already been downloaded and installed on your machine, though. Damage may already have been done at that point.
Ah, thanks for clearing this up - I've thought I had no idea what I was speaking about.
It's a bit silly that people fuss over go package path names.
Any non-trivial app would use a preprocessor to manage the import lines. This problem was solved 40 years ago.
Any non-trivial app would use a preprocessor to manage the import lines. This problem was solved 40 years ago.
I think I just made an example of receiving a merge request somewhere on Github, where you don't have access to the preprocessor or are not running it yourself. It is easy to accept the change when the change looks so much like lines in other files.
The issue was resolved by the comment on the same level, however your comment added 0 to the discussion.
The issue was resolved by the comment on the same level, however your comment added 0 to the discussion.