A Source Code Typo Allowed An Attacker To Steal $592,000 In Cryptocurrency (bleepingcomputer.com)
An anonymous reader writes: "A typo in the Zerocoin source code allowed an attacker to steal 370,000 Zerocoin, which is about $592,000 at today's price," reports BleepingComputer. According to the Zcoin team, one extra character left inside Zerocoin's source code was the cause of the bug. The hacker exploited the bugs for weeks, by initiating a transaction and receiving the money many times over.
"According to the Zcoin team, the attacker (or attackers) was very sophisticated and took great care to hide his tracks," reports the site. "They say the attacker created numerous accounts at Zerocoin exchanges and spread transactions across several weeks so that traders wouldn't notice the uneven transactions volume... The Zcoin team says they worked with various exchanges to attempt and identify the attacker but to no avail. Out of the 370,000 Zerocoin he stole, the attacker has already sold 350,000. The Zcoin team estimates the attacker made a net profit of 410 Bitcoin ($437,000)."
"According to the Zcoin team, the attacker (or attackers) was very sophisticated and took great care to hide his tracks," reports the site. "They say the attacker created numerous accounts at Zerocoin exchanges and spread transactions across several weeks so that traders wouldn't notice the uneven transactions volume... The Zcoin team says they worked with various exchanges to attempt and identify the attacker but to no avail. Out of the 370,000 Zerocoin he stole, the attacker has already sold 350,000. The Zcoin team estimates the attacker made a net profit of 410 Bitcoin ($437,000)."
We need YANPL (yet another new programming language) that won't allow typos and mistyped characters to cause problems. Really, hanging yourself with a typo is as bad as hanging yourself with a NULL pointer. More hand-holding, I say!
Bullshit. A one character bug? Really? What about the tests? This sounds like spin on "We got hacked and lost your money"
he simply allowed the code to run; dont want this to happen? dont write crap code.
I don't think steal is the right word in this context. The article doesn't state that anyone else lost their coins. More accurately would be "created", "unauthorized-mining", or perhaps most accurately "counterfeited"
One char can make big different in performance and correctness. The greatest one character code change I made and got stunning performance improvement was adding an &. It took significant effort to find it, because instrumenting the entire executable for profilers was just out of the question. But once found it was trivial. The caller was passing a std::map by value. The answers were correct and the scaling effects were not visible till the map grew to big sizes. I expected to something along these lines.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Seems like he collected an ~500k$ bug bounty. The interesting part is "Zero Coin is a project to fix a major weakness in Bitcoin: the lack of privacy guarantees we take for granted in using credit cards and cash. Our goal is to build a cryptocurrency where your neighbors, friends and enemies can’t see what you bought or for how much" per Zero Coin. It seems they succeeded in their goal and were hoist by their own petard. Of course, had they recovered the funds then ZeroCoin would have failed at its purpose. I wonder who took the loss.
I'm a consultant - I convert gibberish into cash-flow.
the attacker has already sold 350,000
By which we mean he has already moved it into other accounts that he likely controls.
I'm an American. I love this country and the freedoms that we used to have.
> A one character bug? Really?
Sure, I've seen many single-character bugs, and created a few. I imagine MOST experienced programmers have done this at least once:
if (a = b) {
When they meant:
if (a == b) {
Every language I can think of has a common single-character bug. Many Microsoft SQL users routinely leave off the semicolon which terminates a statement. Sometimes that results in buggy behavior right away, sometimes not until two years later when a change is made to the *proceeding* statement.
> What about the tests?
This is crypto-currency, the hot new thing tests are for old fogeys who still use dollars. Get with the times, young programmers are Agile, they don't plan and test their work, they release early and often. They release the Minimum Viable Product (minimum piece of shit they can get away with for a moment), it's illegal now to even think about corner cases and make code robust.
The story says " allowed an attacker to steal 370,000 Zerocoin, which is about $592,000 at today's price". I seriously doubt 370,000 Zerocoins is worth anywhere near $592k now that the news is out and trading has been suspended. If you can't spend it, it's worth is zero, which kind of makes sense for something named Zerocoin. The name should have been warning enough.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
An obscure, second-rate digital coin can be worth that much money? There is a bubble in the cryptocoin market. I wonder what happened to Dogecoin.
"First they came for the slanderers and i said nothing."
this is great, that's how the freemarket works !!!
The bug has been found with a modern diagnostic tool, such as clang-5.0 with all the warnings and sanity checks enabled. Anyway, this is really cool story.
I mean the following statement. This works okay:
SELECT 1
SELECT 2;
This doesn't:
SELECT 1
THROW
The latter is equivalent to:
SELECT 1 AS THROW
I had originally written "the preceding or proceeding statement". That's reasonably clear, I think, though it stretches the definition of "proceeding". Then I realized that changes to the PRECEDING statement won't affect anything, so long as if that preceding statement is properly terminated with a semicolon. So I ended up with "the proceeding statement", which is poor wording.
Most crypto currencied are worth more than regular and the U.S. Dollar hates this because banks have no control. So, expect more stories to show up in the next week or so as an attempt to weaken the crypto dollar.
Wow. I'm surprised the total value of all Zerocoin is worth that much in $USD
No, we just need IDE's and complilers for current ones that enforce certain constraints.
My (mod funny) comment was a bit of a caricature of Agile, of course. Still, I'm surprised you said what you did, rather than chuckling. I thought you'd been doing professional development for a number of years. Perhaps I'm remembering wrong.
Agile emphasizes *automating* testing. Automated testing is a good thing. It sometimes catches regressions and fatal errors that completely break the build entirely. That saves your alpha and beta testers from dealing with some of the easy, dumb mistakes.
Scrum by the book says sprints should be 1 week preferably, up to 2 weeks, and you should have a release (or a minimum a releasable product at the end of each sprint (each week). If you're going to plan it and build it in a week, that doesn't leave more than a few hours for QA. Traditionally high quality software spends a few weeks in alpha testing and a few weeks in beta testing before it moves to limited release. If you follow Scrum as originally written, release comes at the sprint - alpha testing is done after release, by customers in production. That's advantageous in that customers get the cutting edge new features right away, and it also means they are getting alpha-grade software. Much like the difference between Fedora and Red Hat Enterprise Linux. Many people like Fedora, which is cutting edge, on their desktops. Virtually nobody wants that on their production servers, they want the reliability of Red Hat or CentOS Enterprise, which has been tested for at least 18 months. Fedora is basically the beta test for RHEL, and that beta test takes 18 months, not 18 hours.
I would also think you'd know that an essential, fundamental concept behind Agile is that we don't know what the future holds, requirements change -- so long-term planning is basically pointless. That makes perfect sense - to everybody who hasn't yet been taught how to determine what the *real* requirements actually are. Certainly sitting in a meeting the users' boss's boss doesn't tell you what the users' actual needs are, but there are methods to determine the real needs, and plan for them even years in advance. Agile rejects that notion, though for those who have been shown how to do it, it's a proven fact that you *can* learn the requirements, and the likely future requirements. You just have to be taught how to do so.
I'm William Scott Lockwood III, long time fart advocate and investor.
Today I'm at the Slashdot world headquarters in San Diego, CA.
I had a nice chat with Slashdot CEO,Carp Flounderson, about their current situation.
He showed me multiple server logs, as well as letters from providers and lawyers.
I'm sure that all the current poogas problems at Slashdot are being caused by the traditional Slashcode system, not because of a lack of farts at Slashdot.
The traditional Slashcode system that Slashdot needs to work with are not able to keep up with the demands of the growing Lockwood fan club.
The dozens of people that make up the Slashdot team are hard at work establishing additional farting partners, that eventually will make dealing with Slashdot easier for all their trolltalk members around the world. For now, I hope that everyone will continue working on Slashcode projects that will help make the world a better place.
-William Scott Lockwood III, esq
Who is the victim? Surely the crime, if any, is that Zcoins were forged by exploiting this bug...
It's strange to see so many people asking "Who is the victim?" That's the nature of counterfeiting (or, really, minting new units of account): Everyone who holds an existing unit of account is paying for the creation of those new units; the people who use this unit of account to conduct their business are transferring purchasing power to the entity that is creating the new units, and if there was no agreement that such transfer of purchasing power should be allowed to take place, then that transfer is indeed theft.
I smell an inside job
> If you're finding things wrong during QA at the end of an agile sprint, there's something seriously wrong
Suppose QA is blended into your four and a half days of planning, research, development, and testing. Somehow (magic?) you're testing the changes you've not yet finished against everyone else's unfinished changes. Obviously you're not testing how your changes work with the other guy's changes before you've decided how to write either change. So that gives you max maybe 7 hours integration testing and validation, spread throughout the last two days of the week. Do you *really* think a a couple hours of each (at the most) can replace several weeks of each? Really? If so, maybe you're the reason we catalog 100 vulnerabilities in other people's software *per day*.
With Scrum and Agile generally you have two options:
A) Knowingly trade faster development at the cost of quality assurance.
B) Unknowingly trade faster development at the cost of quality assurance.
Those are the choices. Do you have any idea what "release early" means? It means release before it's thoroughly tested, in the case of Scrum specifically, it generally means nobody has ever tested it at all - nobody other than (maybe) the developer has tried out the feature to see if it works correctly, and integrates correctly with everything else. Paying customers do alpha testing. (And no, automated unit tests (while useful) in no way replace beta testing, alpha testing, and validation. So you get speedy development but at a cost. Again your two choices are:
A) Knowingly trade faster development at the cost of quality assurance.
B) Unknowingly trade faster development at the cost of quality assurance.
You can either know what you're giving up, or not know. But nothing is free, there is a definite cost. If you think thorough testing is for chumps, perhaps you're the guy who wrote "goto fail".
> "A typo in the Zerocoin source code allowed an attacker to steal 370,000 Zerocoin, which is about $592,000 at today's price,"
Blah-blah, insider bob, blah-blah... This fairy-tale telling happens all the time, but they will go to prison eventually.
(I really root for the late 19th century Europe, where people found embezzling and counterfeiting bills of exchange simply had to shoot themselves, because they were so utterly destroyed socially that the shame would ruin their entire family, unless they acted gentlemanly. The good old morals effectively deterred people from all kinds of swindles.)
If you're not ALWAYS finding bugs in QA, you're doing it wrong.
The trick is finding and fixing the showstopper bugs so it works out of the box and fix the edge case bugs after.
The process that worked well for me and a developer was to discuss what problem the customer would have now, and what we think would resolve their issue. Very little design was dictated to the developer, mostly just in intended operation.
If he said a feature will take 3 weeks, it would break down like:
- first test build given to me after two weeks.
- bugs and issues reported directly to dev for discussion
- cosmetic bugs reported right away (he was Chinese that was pretty good but could use improvement here and there)
I'd get a build the next day or so with all cosmetic fixes and continue with functional testing to make sure it worked.
After making sure it works, then we make sure it's dummy proof and you can't brick it. Error handling added and sane choices made (ie, bail or continue on unexpected input).
Most QA time was significantly reduced by having experienced, competent developers who know how to sanitize inputs, clean up memory usage, and remember it's an embedded device with limited resources.
QA effort is directly related to quality and experience of your developers.
If we're feeling obtuse: that kinda is yet another new programming langauge... it's just one which happens to be a strict subset of an existing one.
Some developers say that typos are not dangerous and PVS-Studio is not needed. This great tool for typos search: https://www.viva64.com/en/exam... Now I have the argument. :)