Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

hackernoon.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#41

Post by mike_hearn »

KekDemaga wrote: post #40
mike_hearn wrote: post #35

Earlier quoted context omitted.

Well, from my blog post three days ago, discussed here: https://news.ycombinator.com/item?id=15321015 "I put it to you that it’s impossible to write secure web apps."

This is like saying "It's impossible to perfectly secure a bike on a city steet" when it gets stolen because you forgot to engage the lock. I have fuzzers that would of likely found this pretty quickly.

I doubt that. What sort of fuzzer is going to create an Ethereum smart contract of a very specific type, insert JavaScript into the contract title, insert the contract into the Ethereum block chain, synthesise the correct URL (which doesn't contain any JavaScript) and then detect that data from the backend was emitted unescaped?

Someone else in this thread said, well, serves them right, they should have used CSP, and then someone else pointed out that doesn't work for inline scripts, and there was a reply of the form "only stupid people use inline scripts" although this is news to me, as nearly every website I see uses inline scripts of some form or another. This whole discussion looks like people in denial.

The problem here is that XSS is so easy to create. A jungle of half-broken workarounds, mitigations, static analysis tools, fuzzers etc doesn't change the basic truth that the web is a fundamentally unsound platform on which to do secure coding. Data and code bleed together far, far too easily - by design.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#42

Post by KekDemaga »

mike_hearn wrote: post #41
KekDemaga wrote: post #40

Earlier quoted context omitted.

This is like saying "It's impossible to perfectly secure a bike on a city steet" when it gets stolen because you forgot to engage the lock. I have fuzzers that would of likely found this pretty quickly.

I doubt that. What sort of fuzzer is going to create an Ethereum smart contract of a very specific type, insert JavaScript into the contract title, insert the contract into the Ethereum block chain, synthesise the correct URL (which doesn't contain any JavaScript) and then detect that data from the backend was emitted unescaped? Someone else in this thread said, well, serves them right, they should have used CSP, and…

I misunderstood the design then. I assumed the XSS was done via an input on the page not an input in Ethereum itself.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#43

Post by mike_hearn »

KekDemaga wrote: post #42
mike_hearn wrote: post #41

Earlier quoted context omitted.

I doubt that. What sort of fuzzer is going to create an Ethereum smart contract of a very specific type, insert JavaScript into the contract title, insert the contract into the Ethereum block chain, synthesise the correct URL (which doesn't contain any JavaScript) and then detect that data from the backend was emitted unescaped? Someone else in this thread said, well, serves them right, they should have used CSP, and…

I misunderstood the design then. I assumed the XSS was done via an input on the page not an input in Ethereum itself.

The article was updated. Apparently there were two different XSS at the same time.

One is the exploit I describe above: data taken from the block chain was not escaped properly.

Another is a more "traditional" XSS. It was possible to format a URL such that it contained script tags that were injected into the page.

https://github.com/etherdelta/etherdelta.github.io/issues/14...

The reason is, the data after the hash was not escaped.

Perhaps a fuzzer would have caught that. But a good tool would make it hard to make such mistakes by default. A desktop app would not have suffered from such errors, by construction. The web is not a good tool.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#44

Post by KGIII »

flashmob wrote: post #39
KGIII wrote: post #38

Earlier quoted context omitted.

This very thread is about a negative. Would you rather they just ignore it?

Ignore? No. I found the story interesting myself & there's some nice discussion on here. News would be boring if it wasn't for the negative stuff. All I'm saying that one should always question the motives of the media & not necessarily conclude a general opinion just by reading a bunch of articles that landed on the front page. As for the exploit itself, it's hard to believe that in this day and age XSS is still a p…

I'm not sure what is worse, the XSS or that the system allows transfer of assets without human intervention. Probably the latter, actually. Why would a coin system even allow that? That is, shall we say, not the best idea.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#45

Post by KekDemaga »

mike_hearn wrote: post #43
KekDemaga wrote: post #42

Earlier quoted context omitted.

I misunderstood the design then. I assumed the XSS was done via an input on the page not an input in Ethereum itself.

The article was updated. Apparently there were two different XSS at the same time. One is the exploit I describe above: data taken from the block chain was not escaped properly. Another is a more "traditional" XSS. It was possible to format a URL such that it contained script tags that were injected into the page. https://github.com/etherdelta/etherdelta.github.io/issues/14... The reason is, the data after the hash w…

>A desktop app would not have suffered from such errors, by construction. The web is not a good tool.

While you are correct it would not of suffered from this particular vulnerability, a improperly utilized malloc for example could have similar if not more disastrous effects and would be exploitable under the same threat model. Yet I wouldn't call it a bad tool, just a tool used by an inexperienced carpenter.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#46

Post by foota »

AgentME wrote: post #15
foota wrote: post #12

Don't you also have to trust that the person running EtherDelta hasn't modified what's running on the site...?

If you use EtherDelta through MetaMask or Mist, then EtherDelta doesn't have direct access to your private keys, and you're given a prompt outside of EtherDelta's control to confirm any action you take, so you're much less vulnerable to malicious behavior from the EtherDelta admin.

Aw, so there's some local client you run that you use to do the cryptographic bits, and the web client is just used to display results and let you navigate things?

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#47

Post by mhluongo »

KGIII wrote: post #25
mhluongo wrote: post #24

Earlier quoted context omitted.

What are you having trouble figuring out? Happy to help people into crypto

Basically, how to bet that it is going to plummet in value and make money on that process. I figure it's a bubble and there's going to be a popping, even if it is done by force of law. These ICOs are starting to make powerful people angry. Thefts like this one are starting to get regular media coverage. At some point, probably soon, the governments are going to come and clamp down on it. Is there a way to long-term s…

A long term way that doesn't bankrupt you first? I doubt it, but I don't know your financial situation.

Plenty of exchanges will offer you shorts if you're that confident, though. BitFinex and Kraken come to mind.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#48

Post by AgentME »

codedokode wrote: post #31
AgentME wrote: post #19

I'm surprised and disappointed that EtherDelta doesn't use Content-Security-Policy headers. They pretty much solve XSS. Google has a good introduction to using them here: https://csp.withgoogle.com/

You will need to disable inline scripts which is inconvenient. CSP looks more like as hack for broken sites.

Personally and from experience, I think inline scripts are generally a bad idea often abused for hacky one-off tweaks, so the fact that CSP blocks them by default is a bonus to me. But for the cases that they do make sense, there are ways to allow them with the nonce property.

CSP doesn't mean that people should forget about proper HTML encoding of user input, but it means that when a developer messes that up somewhere, the issue is generally a minor formatting glitch rather than an exploitable flaw that lets attackers do whatever they want with users' browsers within your domain (like steal thousands of dollars). It's some invaluable defense-in-depth.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#49

Post by AgentME »

foota wrote: post #46
AgentME wrote: post #15

Earlier quoted context omitted.

If you use EtherDelta through MetaMask or Mist, then EtherDelta doesn't have direct access to your private keys, and you're given a prompt outside of EtherDelta's control to confirm any action you take, so you're much less vulnerable to malicious behavior from the EtherDelta admin.

Aw, so there's some local client you run that you use to do the cryptographic bits, and the web client is just used to display results and let you navigate things?

Optionally yes, but EtherDelta specifically does let you instead use it in a normal browser if you give it an Ethereum private key. The hack only affected people who used it that way.

Re: XSS Attack Embedded in an ERC20 Token Contract Steals Thousands

#50

Post by mike_hearn »

KekDemaga wrote: post #45
mike_hearn wrote: post #43

Earlier quoted context omitted.

The article was updated. Apparently there were two different XSS at the same time. One is the exploit I describe above: data taken from the block chain was not escaped properly. Another is a more "traditional" XSS. It was possible to format a URL such that it contained script tags that were injected into the page. https://github.com/etherdelta/etherdelta.github.io/issues/14... The reason is, the data after the hash w…

>A desktop app would not have suffered from such errors, by construction. The web is not a good tool. While you are correct it would not of suffered from this particular vulnerability, a improperly utilized malloc for example could have similar if not more disastrous effects and would be exploitable under the same threat model. Yet I wouldn't call it a bad tool, just a tool used by an inexperienced carpenter.

Yes, but modern desktop apps tend to be written in GCd and bounds checked languages.
Post reply on HN