The day is coming where something very, very similar to the below will be put forth:
From the desk of Ken Fitzsimmons, operator of Bitconnect.ei.ei.o
For immediate release.
There are a lot of unanswered questions floating around on the Bitcoin
forum and other places about the recent Mtgox password leak, and theft
from the MyBitcoin system.
I will attempt to answer as many of the questions and concerns as best
as I can in order to silence the rumor-mill once and for all.
As many of you already know, Mtgox was hacked and its password file was
leaked. As soon as we heard about the leak we were closely monitoring
the system for abnormal activity, and we didn't see any.
At first glance, we didn't see any hard evidence that a password leak
had even occurred. There was just a lot of speculation to an SQL
injection vulnerability in Mtgox's site. A few clients of ours had
informed us of the forum threads, and we watched them carefully.
The following morning a client of ours sent us the download link to the
leaked Mtgox password file. We prompty downloaded the file, put up a
warning on the main page, and disabled the login.
We attempted to line up usernames from the leak, and we found a lot of
matching ones. We started locking down all of those accounts using a
script that we had to have written at a moment's notice. It was during
this time that we noticed a flurry of spends happening. Yes, even with
the site disabled.
The attacker had active sessions open to the site. We quickly flushed
them and the spends stopped abruptly. We disabled the SCI, all payment
forwarding, and all receipt URL traffic on all of the usernames in the
Mtgox leak.
We proceeded to change the password on every account where the username
matched our system's database. PGP-signed emails went out to all of the
accounts that we changed the password on. If an account didn't have an
email address or had already been compromised we put up a bulletin.
(Email addresses were mandatory when we opened our service initially,
but people complained that it wasn't truly anonymous so we made them
optional. Unfortunately this makes contacting a security-compromised
customer impossible.)
An investigation was conducted at that time, and we determined that the
attacker had opened up a session to each active user/password pair ahead
of time, solved the captcha, and used some sort of bot to maintain a
connection so our system wouldn't timeout on the session. It was likely
his intent to gain access to more accounts than he did, but as soon as
he noticed that we had changed the main page of the site he sprung into
action by sending a flurry of spends.
(Before you ask: no, we don't limit logins per IP address. We can't. We
have a lot of users that come in from Tor and I2P that all appear to
share the same source IP address.)
We've concluded that around 1% of the users on the leaked Mtgox password
file had their Bitcoins stolen on MyBitcoin. It is unfortunate, and a
horrible experience for the Bitcoin community in general.
The IP address that the attacker used was a Tor exit node and the spends
were to an address that is outside of our system.
Now to address the rumors:
No, our database wasn't compromised. We had a 3rd party company audit
our site for SQL injection attacks and we passed. (We did, however, have
one XSS hole in the address book page last month that would allow an
attacker to insert fake entries into a customer's address book. It was
promptly fixed and offending address book entries were purged. Not a
single customer had spent to the fake address book entries.) Every line
of code was audited last month. Literally line by line audited by
professionals, and it was deemed safe.
No, this site isn't being ran by some amateur that just learned how to
program computers. It was created by seasoned programmers that
understand security.
Yes, we use password encryption. We are currently using SHA-256, but
since the recent Mtgox hack we will be upgrading that to something
stronger. It's surprising how many sites still use MD5, even though it
was broken years ago. It is my personal opinion that MD5 be deprecated
from modern operating systems.
We also use whole-disk level encryption on every single one of our
servers. When you fail a disk in a NOC and a level 1 technician replaces
it does he wipe the disk before the RMA/tossing it in the garbage? Not
usually! We know these mistakes happen, so we take precautions. Any and
all servers with an IP KVM on them are ran in secure console mode. The
root passwords are required even for single user mode. All disk keys are
held off-site and were never generated anywhere near the internet. All
server passwords are unique per server and per user, of course. Only two
technicians have access to the secure servers. This access is over a VPN
and we only use secured workstations running Linux and BSD to access
them.
We use BSD servers with MAC, immutable flags, jails, PAX, SSP,
randomized mmap, secure level, a WAF, a DDoS mitigation and alert system
- -- the works. Like I said earlier. We are not amateurs. In fact,
combined we have over 30 years of experience in the payment
processing (credit card arena) industry.
A large amount of the Bitcoin holding is in cold (offline) storage. We
only have a percentage of the holding available hot. This is done for
obvious reasons.
Going forward we are implementing a 2-factor login system,
user-configurable spend limits, better session token tumbling, and a
bunch of new SCI features.
Wishing the Bitcoin community all the best and a swift recovery, and
sincerely yours,
Ken Fitzsimmons