Topic: BitcoinPool.com open thread - page 6. (Read 29840 times)

If you are referring to, for example, PHP's magic_quotes options then -- NO.  Those kind of options should never, ever be trusted.  They are not locale-aware (and therefore still vulnerable to injection attacks in some circumstances) and can corrupt your data if you're not careful.

Additionally, this would be the wrong place to perform such sanitation.  You should sanitize and escape values before they are used in whatever context you are using them.  For example, magic_quotes will protect against some (yes, some, not all!) SQL injection attacks.  But it will not stop XSS or the like.  SQL-escape user data before it enters the DB, not before it enters the entire script.  HTML-escape user data before you render it to a browser.  Etc.

A better option would be to use parametrized queries, which are by definition invulnerable to SQL injection attacks if the DB itself supports them, since the parameters are sent after the query has already been parsed.

Miner clients code do not related to pool frontend and backend software in term of security.
Passwords and user from miner client used only for user identification for submitted share.
There is no one reason (besides laziness) for hold plain text passwords for user accounts, or reuse the same password and name for user account.


Actually all normal programmers do not use raw sql queries with unescaped input from end user at least 7 years (if not more).
Only very lazy or naive "programmers" continue use this shit.

That's why I introduced separate credentials for account and for workers. Sending plaintext credentials for full account access with getwork request is simply crazy (I mean this globally, I even don't know if bitcoinpool.com use the same password for account and for workers).

With separate credentials for getwork calls, things are quite safe. I don't know any significant type of attack which can be done by stolen getwork password.


Well, I don't have enough info, but most likely the attack was targeted to wrong escaping or handling of sql statements in application itself than exploiting some bug directly in sql server (probably mysql). Bitcoinpool is using native mysql binding for php (mysql_*) and escaping sql manually; it's pretty easy to make a mistake here.

Of course I didn't read complete software stack which I'm using, but you can avoid pretty much common mistakes with using well tested high-level libraries (like ORM, libraries for sanitizing input data, ...) than writing it by self. I read megabytes of source codes (mostly in PHP) from programmers who like to 'do everything under their control' (=don't use high level frameworks) and it's sometimes crazy how easily people are making huge holes to their systems .

+1

Their issue was not with a vulnerability within their DB vendor, it was a SQL Injection problem. SQL Injection vulnerabilities are caused by websites not sanitizing their inputs. You can solve this with a singular change that is global to the entire website that simply places escape characters around any potentially dangerous characters in input strings. This is something that every web page should ALWAYS do. Many web platforms have an option to automatically do this for you.

Agreed




No doubt clients started out with someone, or a few people, hacking some code together and came up with a client. There's at least 1 example on here that I've seen of someone creating a from scratch client. Not many people start out writing their software from a security perspective. Most start out just to make something that works, then optimize it. Security is very often an after thought. Once the pools opened and people started using clients it's hard to change that. How many pool operators are willing to upset the status quo and change the security model of their pool and make people upgrade to a "Secure!" client. Mass conversions are hard when you know all the people involved, nevermind a loose association of people such as mining clients. Someone may be able to code a backward compatible security model into the server, but unless you force people to upgrade not all of them will, and as long as the old model still exists the problem will be there.


Unless you write every line of code yourself you are trusting other people to follow those rules to the level that you think they need to be followed, and many people's definitions vary (especially in the free/open source software community). Simple services can have hundreds of lines of code behind them. Even if all the rules and accepted practices are followed it doesn't mean that someone can't find a way to subvert them and create an exploit.

In their case it was a SQL. No matter which SQL server you are using, it's most likely that you wrote little, if any, code that is running on it. SQL query and security issues are constantly being found and addressed for every SQL vendor. SQL is a pretty big software app with a lot of lines of code and marketing is driven on speed. Very few SQL vendors care to advertise their security in depth unless you're Larry Ellison and willing to make a fool of yourself on stage then have Marketing scramble to CYA.

Secure and Security are precesses, not states.

Every significant pool faced massive DoS attack already. I think operators should be happy that their pool is significant enough that somebody is trying to shut it down .


How so? I think that it's pretty easy to _hurt_ some system (for example by DoS), but full system hack it is pretty complicated when you keep some basic rules while programming.

here here I agree
lest we feed the trolls & their nonsense

 I have been watching mine like a hawk since I started mining just over a week ago and haven't had any problems with payouts except for when they were frozen due to the attacks, and has been resolved.

 Being an admin. It's not really fair to hold DDOS attacks against them. The only reason it would be justified to hold the recent breach against them is if it was gross neglect (which I don't think it was). Even the best admins can't stop someone if they really want to get into a system.

I appear to be missing payments for some blocks too, and have been in contact with the admins about it.  Unfortunately I don't log very much, so I don't have a lot of useful info to give them other than "my historical balance on your site is larger than my payout to date" but I suspect that it may have been the same block(s) that we didn't get paid for.

I can understand the pool messing up for an entire block or for like the last half of the block or something like that. But only one user out of the entire pool not getting paid for a block?

I guess my concern is that it feels like the problem is likely to be much more widespread than has been identified so far.

Have to say that I had hard times with pool payouts, too, so I understand bitcoinpool troubles. Fortunately I'm excessive logging everything, so when bitcoind crashed during payouts (but json results for 'send' commands  were True), I had everything needed to reconstruct all accounts to consistent state.

Depends just on programmer's experience if he covered also very unlikely states of application and if he can recover crash without losing someone's money...

I like deepbit better as everything is in the open now with the history and stuff

I guess since they say it is beta I am not surprised, but I will say that I really like how they have all their information available and does not feel like a black box. I would bet things like this happen on other pools but  good luck tracking it down. They seem honest.

Regan: Trust but verify (if you can)

So people don't have to read the whole thread over there:



How in the world was one user not paid for one of the blocks?

Yep  your a BIG JOKE

Have a nice day with your trolling

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=5

Some people aren't getting paid in certain blocks? I'm definitively stopping mining there! First "malicious attacks" against them and now they don't pay on certain blocks? too fishy for me

I should make a poll.... who is the troll, BobR or nster.... guess what the answer will be  

HINT: https://bitcointalksearch.org/topic/poll-is-bobr-a-troll-or-just-a-dumb-ass-should-he-be-banned-4540 in case your are a, in their words, "dumb ass"


you make quite the argument

I don't want to evolve any kind of conspiration theory, but saying "attacker was from Czech Republic or Russia" has similar weight as "attacker was from USA or Chile, because I know two guys from those countries who may be interested in hurting my little baby". IP ranges, provider companies, language or whatever is completely different in CZ and Russia. Czech Rep was former Soviet union, but it is more than 20 years ago. I'm quite interested in evidence that attacker was from CZ _or_ Russia.

But not too much to register on bitcoinpool forum and ask there (pardon - troll there).

hmmm joint effort from tycho and slush to eliminate the no fee competition? 

it is quite a coincidence though