FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » [CM] Falkvinge: MtGox had custom SSHD written in PHP
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
[CM] Falkvinge: MtGox had custom SSHD written in PHP [message #185206] Tue, 11 March 2014 10:49 Go to previous message
RS Wood is currently offline  RS Wood
Messages: 2
Registered: March 2014
Karma:
Junior Member
From the «That oughta work» department:
Title: Security At MtGox Much Worse Than Originally Imagined
Author: Rick Falkvinge
Date: Mon, 10 Mar 2014 20:06:30 -0400
Link: http://feeds.falkvinge.net/~r/Falkvinge-on-Infopolicy/~3/DNADqqiDLrY/

[image 1]

Cryptocurrency: Revelations of the mismanagement at the now-bankrupt Japanese
bitcoin exchange keep surfacing. When laying the puzzle as pieces keep
coming, it becomes obvious that security at the billion-dollar vault was
practically nonexistent. This adds to previous[2] insights of economic and/or
fraudulent mismanagement.

An interesting blog post from Mark Karpeles resurfaced recently. Mr. Karpeles
was the CEO of the now-imploded Japanese bitcoin exchange MtGox, nicknamed
“Empty Gox” for its previously-rumored insolvency. The blog post reveals a
stunning ignorance of the concept of security, going beyond nonexistent
security and into daredevil-reckless territory.

Jacob Appelbaum, the world-class security researcher and one of the
spokespeople for the anonymity service Tor that has saved many activist lives
worldwide, tweeted sarcastically about the article:

I think this is perhaps the most amusing technical blog post I've read in
ages: http://t.co/uJwtz5xtrU[3]

— Jacob Appelbaum (@ioerror) February 28, 2014[4]

The article in question[5] (gone from the server, but saved by the Internet
Archive) was about how Karpeles had decided to write his own security
mechanisms for remote access to his core servers. This goes against every
grain, every practice, every professionalism of good security that exists.
Security is hard and needs thousands of eyes to find the small but important
bugs – just last week, a bug in Apple’s iOS was discovered where an attacker
could have impersonated any target. And that was from Apple.

Any person who calls themselves a professional in the IT field will end the
conversation with anybody, no matter what title, who boasts that they have
created their own security. You just don’t do it. It’s beyond reckless. It’s
practically a guarantee that you will get broken into tracelessly.

It gets worse. Karpeles didn’t just write his own remote-access security
(“SSH server”). He did so in the programming language PHP, which is a
dangerously unsafe language intended for low-security applications like
displaying web pages. It basically has no error checking or safety nets of
any kind. So not only did Karpeles think it was a good idea to do something
that almost guaranteed MtGox to get hacked, he did so using one of the worst
possible tools imaginable. It wasn’t enough to shoot himself in the foot and
reload, he had to pick a bazooka to do it.

This is not professional behavior. This is completely-over-the-top
amateurish, from somebody who a) doesn’t understand security at all and b) is
so convinced of their own perfection that they dismiss every criticism.
People are even pointing out flaws in his implementation in his own comment
field, and he just dismisses it, despite the fact that these flaws would be
enough for an adversary to assume remote control of his core servers –
“ownage”, as it is called.

Traditional SSH servers too secure for you? Write one in PHP!
http://t.co/v2in7x6NJd[6]

— Kyle Steely (@modalexii) February 28, 2014[7]

When you read these facts, if you understand security, your hairs stand on
your arms, you are pushing away from the screen in balking disbelief, and
your eyes are going wide. This guy had taken on safekeeping of a billion
dollars for his clients?

Let’s be clear: To anybody who is the slightest aware of good security
practices, this article from the principal architect of the bitcoin exchange
is not some government-issue red flare going off in the corner of your eye.
This is a goddamn Betelgeuse[8] going off.

To put it in non-technical terms, this is roughly somebody who claims they
are qualified to be a heart surgeon because they have read the back cover of
“Anatomy for Dummies”. Not just that, but they actually open a heart surgery
practice.

It’s like asking for a hardened veteran infantry officer to lead a batallion
into battle, and having a random guy who has read military comics books show
up for the task.

It’s like asking if somebody can build a complex skyscraper, and somebody
shows up with a grin from face to face explaining that they already found
everything they need for the job in trash bins on the way to the meeting.

Somebody who was utterly not qualified to go near any kind of security job
had built a vault for a billion dollars using a completely unsafe webpage
scripting language. And people were using it, trusting him with their money,
more or less because he said he was honest in the Terms of Service.

[image 9]

It gets worse. The forensic site MtGoxProtest has an interesting inside view[10]
of security practices at the company that stored bitcoin, US Dollars, and
euros for its clients to a value of about a billion dollars (at peak bitcoin
value).

If the product was so thorougly shoddy in terms of security, some very
skilled staff at some very skilled companies are able to mitigate that by
rigorous processes and consistent pride in their work. What about Gox? How
did they relate to security in their daily work?

They didn’t give a shit.

Security alarms would go off, somebody would notice something totally
alarming, and they would basically just ignore it.

On the surface, security looked decent. Clients would log in using two-factor
authentication, not relying on a hackable password alone. Clients could
separate withdrawal security from authentication security, adding a second
security layer when they wanted to get money out of their account.

(This is disregarding all jokes that you couldn’t actually get any money out
of the vault, because it was empty – hence “Empty Gox”.)

But it happened much too frequently that client accounts were emptied anyway
overnight, and provably so by somebody else than the account holder. This
should have set of major alarm bells at the Gox offices; somebody was
apparently and obviously able to circumvent their security layers and access
the servers directly. Mere suspicion of that is cause for a total shutdown
until forensics have cleared out what the hell happened.

So what happened?

They didn’t give a shit. They blamed the customers and went about their daily
business.

Coupled with the above article from Karpeles – who wrote much of the initial
Gox codebase - about how Gox would violate every security practice in
existence and then invent some more just so they too could be violated, it
becomes clear that the strict login procedures were just for show. Gox was
leaking like a bloody sieve, and Karpeles was too incompetent and too proud
to understand the magnitude of the disaster in the making.
[image 11]

This seems a good analogy of the security thinking at Empty Gox. While the
two-factor login procedures appeared to be proper, in hindsight, it should
have been clear that they were also trivially circumventable – like a strong
keylocked and concrete-anchored metal gate surrounded by ankle-height hedge.

According to the insiders’ information, security researchers would regularly
submit alarming reports of gaping security holes that would just as routinely
be completely ignored. And then security researchers did what they do when
companies ignore them, which is publish their findings. So now there was not
only a billion-dollar vault with security holes the size of the Empire State
Building, there were also published research papers on where they were and
how they worked.

And Gox? They continued to not give a shit.

It gets worse. They treated business processes the exact same way as they did
security processes: “It seems to run well and we don’t really care”. I have
hinted[12] in my previous posts that I’ve got stuff that would be
jawdropping; I’m not sure it is anymore, it’s just in line with the total
mismanagement – no, fraudulent operations – that has been going on. They
basically didn’t know anything about contract or finance business, either.

My specific case was that I had been offeredX bitcoin for Y US Dollars on the
exchange webpage, clicked “buy”, and even got a separate confirmation box:
“Do you want to buy X bitcoin for Y US dollars?”. As I clicked “Yes” to that,
that’s entering into a legally binding contract. But I wasn’t delivered X
bitcoin – I was delivered X-56 bitcoin for the Y USD, which is a rather large
difference. As I pointed this out to support, that they had an unfulfilled
obligation of 56 bitcoin to me, they explained patiently how the quote price
was calculated from a technical standpoint, why I had been charged a much
higher price than quoted, and implied that the technology and interface were
working just as designed.

Listen here Karpeles, I don’t care in the slightest why you think the price
should be higher than quoted – if you quote a price and I accept the offer,
you deliver on it, and you deliver exactly what was offered. If you can’t do
so, that’s your problem, not mine.

They didn’t understand these very basics of running a business. They didn’t
understand the concept of offers, accepts, and contracts. Or they just didn’t
care. This 56-coin claim of mine was one of the open items in support threads
when Gox folded, and I was totally prepared to bring that to court. Now it’s
rolled up in my overall bankruptcy claim instead.

It gets worse.

Yesterday, a leak was posted with internal accounting data at MtGox. It
contained every customer balance, their last login timestamp, withdrawal
limits for every customer, and a lot of other client data. Whoever
orchestrated that leak had had complete access to the internalmost servers at
Empty Gox.

But just to drive the point home, the damning leak was posted from Mark
Karpeles’ personal accounts, both on Reddit[13] and in an article[14] on his
own personal blog.

That is such total ownage of somebody’s poor security, there’s nothing left
to say. It’s confirmation of everything from the original article – that this
is a person who didn’t understand the most basic security practices.

Gox appears to have been run on the kind of security that only an idiot would
have on their luggage.

[image 15]

Links:
[1]: http://falkvinge.net/files/2014/03/12345-237x133.png (image)
[2]: http://falkvinge.net/2014/02/28/the-gox-crater-crowd-detectives-reveal-bill ion-dollar-heist-as-inside-job/ (link)
[3]: http://t.co/uJwtz5xtrU (link)
[4]: https://twitter.com/ioerror/statuses/439436901846900736 (link)
[5]: https://web.archive.org/web/20140226001727/http%3A//blog.magicaltux.net/201 0/06/27/php-can-do-anything-what-about-some-ssh/ (link)
[6]: http://t.co/v2in7x6NJd (link)
[7]: https://twitter.com/modalexii/statuses/439445431710281729 (link)
[8]: http://en.wikipedia.org/wiki/Red_giant (link)
[9]: http://falkvinge.net/files/2014/03/headbang.gif (image)
[10]: http://www.mtgoxprotest.com/?p=330 (link)
[11]: http://falkvinge.net/files/2014/03/gatehedge-621x350.jpg (image)
[12]: http://falkvinge.net/2014/02/04/major-bitcoin-exchange-not-executing-withdr awals-now-owes-clients-38m-in-disappeared-money/ (link)
[13]: http://www.reddit.com/r/Bitcoin/comments/1zz21j/mtgox_2014_hack_database_re vealed_live_from_mark/ (link)
[14]: https://web.archive.org/web/20140309174150/http%3A//blog.magicaltux.net/201 4/03/09/mtgox-2014-hack-database-revealed-live-from-mark-karpeless-reddit-a ccount/ (link)
[15]: http://feeds.feedburner.com/~r/Falkvinge-on-Infopolicy/~4/DNADqqiDLrY (image)
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: switch with range of comparisons
Next Topic: readdir lists randomly
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sun Nov 24 06:09:15 GMT 2024

Total time taken to generate the page: 0.04355 seconds