So the attack goes: 1) compromise some site to serve arbitrary JS 2) have it serve simple JS that requests other JS that contains the real malicious payload.
And the reason for this two-step architecture is to make it convenient to change the real payload.
And the problem is where to host the real payload. The first idea was Cloudflare, but Cloudflare keeps taking that sort of thing down. So now they host it "on the blockchain" which means it "can’t be blocked".
What I don't understand is who is actually serving the HTTP call that effectively proxies the data from the blockchain. It seems like they (like Cloudflare, or a regular hosting service) are opening themselves up to all sorts of risks by serving arbitrary content.
Because reads from blockchain are "free" (meaning, there is no cryptocurrency payment required to read data from the smart contracts on BSC), this is effectively free storage/hosting for the attacker.
The malicious code is served by BSC web API. According to the Krebs article, BSC "is aware of the malware abusing its blockchain, and is actively addressing the issue." I am not clear if they are taking this situation Very Seriously(TM), but I assume they are.
> In response to questions from KrebsOnSecurity, the BNB Smart Chain (BSC) said its team is aware of the malware abusing its blockchain, and is actively addressing the issue. The company said all addresses associated with the spread of the malware have been blacklisted, and that its technicians had developed a model to detect future smart contracts that use similar methods to host malicious scripts.
Earlier in the article it said
> Due to the publicly accessible and unchangeable nature of the blockchain, code can be hosted ‘on-chain’ without the ability for a takedown... “So you get a free, untracked, and robust way to get your data (the malicious payload) without leaving traces,” Tal said.
Make up your mind...
It's not robust since you have to use an API (i.e. Binance API) to access the blockchain from a compromised website, then Binance can effectively "take it down" by blocking access via the API.
Now if they made the compromised website talk directly to the node on the blockchain network that would be different. Except, why not just host the malware on the website in the first place...
Sounds like we should poison this vector (and IPFS) by uploading copyrighted movie torrents to this free storage system. For a change we’d be doing good.
For the Blockchain reads, someone still needs to host a JSON-RPC server. Most of hosting is commercial SaaS (Infura, QuickNode, LlamaNodes) but Binance provides a free endpoint for better adoption of their chain.
This free endpoint has many abuse protection mechanisms, as free services need (see: Cloudflare). However until today no one was hosting any malicious web payloads.
It's just matter to add a new abuse rule by BNB Smart Chain team to take this down.
I looked at an early flavor of this and spent a while reversing the malware. This was the same malware that hit McClatchy and MediaNews a few years ago (2020, but I remember being concerned about the malware's practice of replacing the DOM with the lure and how that could have been further abused to inject fake content). It ran on many regional media sites like Denver Post, etc. This one did a lot of cleverness like fingerprinting a host via JS to ensure it was legitimate, geolocating an IP, only serving the bait once to an IP, and making sure the referrer header was set-- among other things. They also had a nice pool of domains, but they were discoverable by looking for artifacts specific to the lure. It was an interesting campaign to dig into and watch evolve.
If I recall too, the intermediate domains appeared to all be subdomains from (possibly) compromised godaddy accounts.
> It seems like they (like Cloudflare, or a regular hosting service) are opening themselves up to all sorts of risks by serving arbitrary content.
That's pretty much any website that accepts user input or integrates with an external service. I could post a base64-encoded malware to HN too, it would just get caught a lot faster (wasn't this a real thing on reddit?). I think the trick here is that it doesn't look out of place on a blockchain explorer/gateway because most of that data is opaque binary content to begin with.
IPFS along with ipfs http gateways is also abused like this a lot. It's hopeless to try to take things like this down, but in general taking down domains is hard.
How are you going to stop people from serving arbitrary content though? What appears to one parser as "Alice sent Bob 0.00000006767 BTC" may appear to another parser as malicious code.
So long as there is uncensorable data anywhere, this will always remain possible.
The suffocating irony of this forum being called "Hacker News" when it is filled with comments like this never fails to amaze me. A truly unimaginative bunch.
I really think Monero in particular deserves way more criticism for their practice. Bitcoin is one thing, Monero is created for and marketed towards cybercriminals, you don't need to be a communications expert to get that premise. I haven't seen it used once for any legitimate purpose. Atleast with Bitcoin and Ethereum you can get buy some legitimate things like VPNs or NFTs
The quality of full screen takeover pages seems to have dramatically risen recently. My family members, who don’t know the Escape key exists, accidentally click one from a banner ad every week now taking them to a page like examplefoobar38561.cloudfront.net and the use of elements that imitate browser or OS chrome (generally imitating Windows Defender or similar) has reached near perfection. All browsers should have a setting to permanently block full screen mode for all sites (not “ask”).
Maybe one of these days scammers will release their UI elements as web components or React whatever, so we'll finally get some high-quality JS versions of native UI elements; maybe we could get Electron app developers to use them.
Google probably prefers when you don't fullscreen the video; More ways to have your eyes drawn to ads, recommendations, and comments in the periphery. Maybe this is why they added the different "bigger but still not fullscreen" modes a few years back.
Seriously considering running a JIT-less JavaScript free browser should be the standard for surfing these days, and only whitelisting sites you trust (like your online banking site or Amazon for example). Disabling JS wipes out entire classes of attacks. I know developers assume the user has JS enabled and codes their site to that end, but a small minority disables JS to get rid of various annoyances and for accessibility reasons, and, malware issues in the browser.
This attack can still be pulled off without JS though: using plain old CSS & HTML. It seems these attacks are targeted to the non tech savvy, but even I (tech savvy) get duped by persuasive messages in my browser. This is why I advocate for a Phishing/Malware 101 course which is mandatory for all types of tech-related courses and learning.
I would argue that a world that didn't have JS would make these types of attacks more common, not less common. Because in that world, people would have to download desktop apps for everything, which would make people used to downloading desktop apps from random Web pages, which would make malware easier to distribute.
In fact, we don't have to imagine that world: it was the world of the late 90s.
That's a very real problem, but one would hope that package managers would be a lot more widely adopted in that counterfactual world. Maybe that's a naive hope.
This isn't that complicated. Like everything else in life it's a matter of trust and awareness, not really that technical. I'll never understand why the default stance on HN is always javascript bad.
I don't think it's a matter of trust and awareness, because your browser is already happily executing the javascript payload before you have decided whether to trust the website or not. And users are completely unaware of what the payload is doing unless it's spinning at 100% cpu or throwing UI elements in the user's face. It's a matter of convenience mostly, from my point of view.
The HN population consists for a large part of computer power users and developers who are fully aware of the capabilities of browsers and the dangers of remote code execution. I'll never understand why the default stance on HN still mostly seems to be javascript good, if not for the convenience factor.
>I'll never understand why the default stance on HN is always javascript bad.
I am a web dev, and I agree that JS on the web is bad for pages that should be just documents like a news webpage or wiki page. JS makes sense for applications like a video game, video/audio/level/text editor, or some internal app that your company trust, but for random untrusted document pages JavaScript is a detriment, even if we only consider UX.
Your browser is a platform that downloads and runs arbitrary code on your local hardware. "JavaScript bad" doesn't capture the nuance I read in people's comments here, but history shows that JavaScript is a gaping maw of security nightmares.
It's simple; the web becomes a much nicer place when you block javascript by default. Some things don't work, but they never compromise you, or bog down your computer, and throw huge ads and banners in your face. I could go on. I obviously see that JS can be used for good things, but it seems like people can't constrain themselves to that.
Or alternatively, you can pursue security through compartmentalization. My VM for random browsing has JS enabled, but if I'm hacked, the attacker will not get access to any files. Also the VM is destroyed when the browser is closed.
What’s the threat model here? Javascript sandbox escapes are extremely rare these days (subjectively they happen less frequently that image or video codec bugs).
I get that the angle of BNC here generates views (and outrage and haha blockchain bad).
But the real story is "WordPress websites still hacked in masses".
WordPress, somehow, cannot manage to turn themselves into a secure and tough system. It remains a prime target, it's installations get hacked by the thousands and it's causing real harm at that.
(Yeah, yeah, I know the users, admins, plugins, themes and hosted are to blame. And I know it's possible to truly harden a WP- I've built a WP hosting company that did exactly this. But it's saddening how poor the wider community handles it's security)
To be fair, WordPress core has gotten better. The bigger problem is that there are many WordPress plugins, and many of the plugins can't even pretend to be related to being secure.
Until developers are widely taught how to develop secure software, the problem will just keep moving around. We can't make software development environments where it's impossible to create a vulnerability, and we will never convince users to stop wanting new capabilities. Making things secure in the first place needs to be part of the solution.
Very over the top, but bear with me. For example: if your community of plugin developers cannot produce secure(ish) plugins, then it's probably time to get rid of the plugin system altogether. "Plugins endanger our users, we no longer allow them."
Being a player that powers a vast part of all websites, gives a responsibility. Taking up that responsibility includes making unpopular decisions. While "getting rid of the entire plugin system" is probably a bridge too far (it would kill WP instantly) the system needs overhaul (same for hosting, same for themes), badly. There is an intermediate solution, I am sure¹.
But the starting point must be "our community cannot handle the power we give it, so let's find a solution for that".
¹ I refrain from concrete examples here, bc HN tends to spiral into discussions on why random potential solution X will never work. I want to keep this on a higher level.
Being one of the biggest publishing softwares naturally attracts all of that: more publicity/cases, uninformed users, incentive and a probing/persistence ecosystem for hackers,.
I have to host a few dozen WordPress sites for customers and the ones that got hacked were all backtracked to: enumerating usernames, and some had their password equal that.
You could blame WordPress for not being more strict rejecting those per default.
Being one of the biggest publishing softwares gives a giant responsibility to prevent this.
I am convinced this responsibility isn't taken up by the community or by organisations behind it, seriously enough. Simply because the current status continues to be abysmal. I have many practical ideas how many issues could be solved, most are put forward and put down almost monthly in the community.
The current status is resignment: "well, we are big and this is how things are". No! Things could be better, more secure etc. But for that, things do have to change.
Good. It's bigger now than it ever should have been, and it'll reap what it has sown for it. It should have been a technology on the down-low, it should have been a technology that purposely purported not to attract attention, it should have been a technology that volatility shouldn't have been its primary feature.
Cryptocurrency would have been good, as a technology, if its infrastructure didn't purposely embrace grifters and skepticism.
They could also use ipfs as there are many http proxies for it including cloudflare. All proxies would individually need to blacklist the address.
In general it is going to be impossible to block content. We need to charge for bytes or something like that. But that produces other problems which could be worse
pretty sure that the final solution is going to be the same as email: a bunch of centralized blocklists, like Spamhaus but for IPFS.
There will be occasional false positives and some people would complain, but most IPFS gateway operators would just choose the top blocklist for simplicity.
Browsers cannot talk to blockchain directly, they need to go through some HTTPS server... And that server can block any request.
I am kinda surprised you haven't heard about this already. This has been used in the past to take down NFTs [0] and to make Bitcoins unspendable [1]
It's the famous "on chain only" caveat: all the decentralized systems are only decentralized in the ideal world, if nothing except the chain exists. Once practical reality comes in, there are plenty of levers for centralized control.
to be clear the caveat has a caveat - the centralized control you're talking about is through public (privately hosted) APIs. anyone running a node on the chain can still send and receive whatever they want. unless the majority of the chain chooses to black list addresses, then you have a hard fork because the nodes don't have a consensus on the protocol (open vs black listing).
there's a difference between decentralized transactions and centralized APIs for viewing on-chain data.
a decentralized blockchain cannot block an address from sending or receiving transactions (without a hard fork - like ethereum did some years ago).
however, centralized services (like binancd) run nodes which read and publish on-chain data (transactions and data, like malware, associated with them) through regular HTTP APIs.
anyone running an API can choose to not allow access to data associated with certain addresses. it's their API and they can do what they want with it. the same way the youtube (insert platform) API could decide to block queries for certain channels or topics.
And the reason for this two-step architecture is to make it convenient to change the real payload.
And the problem is where to host the real payload. The first idea was Cloudflare, but Cloudflare keeps taking that sort of thing down. So now they host it "on the blockchain" which means it "can’t be blocked".
What I don't understand is who is actually serving the HTTP call that effectively proxies the data from the blockchain. It seems like they (like Cloudflare, or a regular hosting service) are opening themselves up to all sorts of risks by serving arbitrary content.
This diagram show the full flow of the attack: https://miro.medium.com/v2/resize:fit:1400/format:webp/1*by4...
Because reads from blockchain are "free" (meaning, there is no cryptocurrency payment required to read data from the smart contracts on BSC), this is effectively free storage/hosting for the attacker.
The malicious code is served by BSC web API. According to the Krebs article, BSC "is aware of the malware abusing its blockchain, and is actively addressing the issue." I am not clear if they are taking this situation Very Seriously(TM), but I assume they are.
> In response to questions from KrebsOnSecurity, the BNB Smart Chain (BSC) said its team is aware of the malware abusing its blockchain, and is actively addressing the issue. The company said all addresses associated with the spread of the malware have been blacklisted, and that its technicians had developed a model to detect future smart contracts that use similar methods to host malicious scripts.
Earlier in the article it said
> Due to the publicly accessible and unchangeable nature of the blockchain, code can be hosted ‘on-chain’ without the ability for a takedown... “So you get a free, untracked, and robust way to get your data (the malicious payload) without leaving traces,” Tal said.
Make up your mind...
It's not robust since you have to use an API (i.e. Binance API) to access the blockchain from a compromised website, then Binance can effectively "take it down" by blocking access via the API.
Now if they made the compromised website talk directly to the node on the blockchain network that would be different. Except, why not just host the malware on the website in the first place...
This free endpoint has many abuse protection mechanisms, as free services need (see: Cloudflare). However until today no one was hosting any malicious web payloads.
It's just matter to add a new abuse rule by BNB Smart Chain team to take this down.
If I recall too, the intermediate domains appeared to all be subdomains from (possibly) compromised godaddy accounts.
That's pretty much any website that accepts user input or integrates with an external service. I could post a base64-encoded malware to HN too, it would just get caught a lot faster (wasn't this a real thing on reddit?). I think the trick here is that it doesn't look out of place on a blockchain explorer/gateway because most of that data is opaque binary content to begin with.
So long as there is uncensorable data anywhere, this will always remain possible.
So… https://joshcsimmons.com?
https://arstechnica.com/information-technology/2021/06/moner...
I'm going to tell them that they should no longer use it for any sort of financial work. No banks, no shares, nothing. Ever, for any reason.
This stuff is too good now. Most of us -- and I include the tech-literate, because we all slip eventually -- are basically helpless at this point.
Solution? iOS apps, or, I'm sorry, use a Mac. I know it's not immune to malware but for all practical purposes it might as well be.
Never going to happen, because that's breaking YouTube.
/s
This attack can still be pulled off without JS though: using plain old CSS & HTML. It seems these attacks are targeted to the non tech savvy, but even I (tech savvy) get duped by persuasive messages in my browser. This is why I advocate for a Phishing/Malware 101 course which is mandatory for all types of tech-related courses and learning.
In fact, we don't have to imagine that world: it was the world of the late 90s.
The HN population consists for a large part of computer power users and developers who are fully aware of the capabilities of browsers and the dangers of remote code execution. I'll never understand why the default stance on HN still mostly seems to be javascript good, if not for the convenience factor.
I am a web dev, and I agree that JS on the web is bad for pages that should be just documents like a news webpage or wiki page. JS makes sense for applications like a video game, video/audio/level/text editor, or some internal app that your company trust, but for random untrusted document pages JavaScript is a detriment, even if we only consider UX.
https://addons.mozilla.org/en-US/firefox/addon/noscript/
But the real story is "WordPress websites still hacked in masses".
WordPress, somehow, cannot manage to turn themselves into a secure and tough system. It remains a prime target, it's installations get hacked by the thousands and it's causing real harm at that.
(Yeah, yeah, I know the users, admins, plugins, themes and hosted are to blame. And I know it's possible to truly harden a WP- I've built a WP hosting company that did exactly this. But it's saddening how poor the wider community handles it's security)
Until developers are widely taught how to develop secure software, the problem will just keep moving around. We can't make software development environments where it's impossible to create a vulnerability, and we will never convince users to stop wanting new capabilities. Making things secure in the first place needs to be part of the solution.
Being a player that powers a vast part of all websites, gives a responsibility. Taking up that responsibility includes making unpopular decisions. While "getting rid of the entire plugin system" is probably a bridge too far (it would kill WP instantly) the system needs overhaul (same for hosting, same for themes), badly. There is an intermediate solution, I am sure¹.
But the starting point must be "our community cannot handle the power we give it, so let's find a solution for that".
¹ I refrain from concrete examples here, bc HN tends to spiral into discussions on why random potential solution X will never work. I want to keep this on a higher level.
I have to host a few dozen WordPress sites for customers and the ones that got hacked were all backtracked to: enumerating usernames, and some had their password equal that. You could blame WordPress for not being more strict rejecting those per default.
I am convinced this responsibility isn't taken up by the community or by organisations behind it, seriously enough. Simply because the current status continues to be abysmal. I have many practical ideas how many issues could be solved, most are put forward and put down almost monthly in the community.
The current status is resignment: "well, we are big and this is how things are". No! Things could be better, more secure etc. But for that, things do have to change.
Cryptocurrency would have been good, as a technology, if its infrastructure didn't purposely embrace grifters and skepticism.
In general it is going to be impossible to block content. We need to charge for bytes or something like that. But that produces other problems which could be worse
It contained IPFS url with a login form sending data to some hacked site so this is already a standard practice.
It is also a bit amusing when you host your own mailserver for years.
I read that 25 year ago as a suggested solution to email spam, and it's many times less feasible today than it was back then.
There will be occasional false positives and some people would complain, but most IPFS gateway operators would just choose the top blocklist for simplicity.
How does this work? Can a single entity really just blacklist certain addresses? How is this decentralized?
I am kinda surprised you haven't heard about this already. This has been used in the past to take down NFTs [0] and to make Bitcoins unspendable [1]
It's the famous "on chain only" caveat: all the decentralized systems are only decentralized in the ideal world, if nothing except the chain exists. Once practical reality comes in, there are plenty of levers for centralized control.
[0] https://news.ycombinator.com/item?id=29227119
[1] https://news.ycombinator.com/item?id=30224637
a decentralized blockchain cannot block an address from sending or receiving transactions (without a hard fork - like ethereum did some years ago).
however, centralized services (like binancd) run nodes which read and publish on-chain data (transactions and data, like malware, associated with them) through regular HTTP APIs.
anyone running an API can choose to not allow access to data associated with certain addresses. it's their API and they can do what they want with it. the same way the youtube (insert platform) API could decide to block queries for certain channels or topics.