Topic: [Cross post] BitFunder.com has been hacked and IT IS BitFunder's fault (Read 2906 times)

Ukyo, are you starting to see my point yet?

I warned you about this over a month ago, yet you failed to get back to me. I posted my concerns then, and hate to pull the 'I told you so' card, but really, I told you so.

This incident combined with the other general concerns I've voiced have now firmly convinced me to never set foot in BitFunder. You need to rethink the entire exchange and get someone with the experience required to help you build the code. You need to kill off that wee exchange idea as it's just a silly distraction for both users and you, that adds about as much security as a paper wrapping on a gold bar.

.b

Agreed. I do like Yubikey, and have been talking to them about mobile options as well!

I actually deleted my post before you replied to it - as I didn't want to get into arguing details of the difference between referring to an active session and being made by an active session.

On the quoted part, this is one reason I far prefer Yubikey to Google Authenticator.  There's nothing a trojan can log that allows them to duplicate output from a Yubikey - and no way to force one that's plugged in to generate a code even with full desktop control.  Other reason I prefer Yubikey is it's far faster just to touch it to generate a code than to take my smartphone out of standby (which needs a password as the memory is encrypted), lookup and then type a Google 2FA code.

Downside of Yubikey is you can't use it on smartphones - so users have to turn it off if they plan to access the site via mobile.

As long as the user is logged in, the session is active. Cross-browser or not, it IS being submitted by the active session as the session details are provided.
As you state, it made sure there was an Active session, and it does indeed verify that active session is the one making the POST. What it does not check is if it was a cross site script using that session that was left open by the user, a trojen that runs in the background with hidden browser being used load pages, get proper per-page security tokens, and make requests, etc.

Once the desktop is hacked there are limitations to what can be done. It is not hard to use a background trojan to intercept 2-factor keys either at setup times. This can effect any site.
I have seen many "bot" trojans for games etc that pretend to be the end user and will use active logged in sessions to browse, load pages, even play games for them.

Even banks (I use citibank) now even require you, once logged in, to submit additional security question answers to be able to do most things for this reason.
I am working to add a new level of security that while it may be a bit controversial, will be fully optional, but give one of the most secure methods of protection.

Keep in mind, generating a code per page might stop a cross-browser attack, effectively becoming a per-page 2-factor, but it wont stop infections from generating on and using it.

With this said, you will also see per-page key generation within a few days that all submits will be required to adhere to. Triple checking the functionality on all posts and making sure no other problems are created, and it works exactly as intended are the current main focus right now.

On a side note, I can say that many users (less than 25 users) who were hit with transfers, had one time no-bad-password logins from different ips, who did transfers. We have seen a large user/email/pass list attempt on both bitfunder and weexchange from a botnet which we put some protections in place from. Ultimately, all we can do is try to recognize and ban/block those ips, as well as slow them down, and inform any recognized accounts that they are in danger. We had seen thousands of login attempts that mostly did not work, for accounts that never existed on either site.

-Ukyo

Oh, god, this is so noobish I'll just delete my account... but there's no delete button. Nor any contact info.
Well, I've never used it anyway, I'll just delete the bookmark...

This was why transfers require 2-factor as of weeks ago. A cross site post could not magically come up with a 2-factor code.

As well as putting some per-page protections in place, and doing some additional checks, you will soon see 2-factor as an option for most other requests.

As it stands, BitFunder itself is not "hacked".

The system does indeed check for sessions. The user must have had a recent and still active session.

-Ukyo

Uh, brb.

Other exchanges were not better. I won't say more.

I was pretty much shocked at the amount of attention paid to security for bitcoin web services. Originally I thought MPEx were absolutely crazy, but now that's actually a pretty good method if you expect your users to jump through the hoops.

 

You'd think that if you were creating an exchange, you'd hire someone who knows basic web security principles. This is a step above SQL injection... not very advanced stuff.

The same vulnerability still works, just in a slightly different format, FYI.

Incredibly shocking. BitFunder gets an F for security.

IF you've got money in there, get it out NOW... if this is possible, who knows what other huge, gaping security holes there are.

The flaw in question didn't require the thief to obtain the login for the victims - it just required the victims to visit other websites whilst logged into Bitfunder.  Unless the 2 raised in that thread are actually old-style key-logged password etc that just happened to occur at the same time as the flaw in Bitfunder was being abused.

There were reports of many more than 2 people affected by it.  At the time there was no way to prevent it with 2FA (2FA only applied to logging in which didn't make any difference).  The way to prevent it was not to visit any unknown links whilst logged into Bitfunder (using a different browser for Bitfunder would also prevent the easiest route for attackers but isn't necessarily totally safe) and logging out of Bitfunder before doing anything else.

The problem WAS the result of bad decisions in respect of Bitfunder's design - it accepted POST requests without verifying they originated from a session connected to Bitfunder (so the attacker only had to send the request and it would work if you were logged in - without any need for them to obtain information about your session or even know who you were).  Transfers was just the easiest way to abuse it - not the only way.  The public assets list for Bitfunder was likely very useful to attackers as well - as it allows them to transfer 1 share then work out how many you have left to know how large a transfer to clear the rest, plus also allows them to see what else you hold they can steal.

This post is a cross post. 2 BITFUNER users was victims of a hacker named "htemp" at the same time, please see the story and discussion it here:


https://bitcointalksearch.org/topic/bitfundercom-has-been-hacked-and-it-is-bitfunders-fault-251051