[ANN][Pool][Profit-Switch][Optional Auto-Exchange per Coin][Vardiff] ~ Hashcows

[socket]

My guess is SQL injection via unsanitized inputs... I'd imagine if you can get unfettered access to the database that's all you need to accomplish what they did.

[Icon]

Well just an FYI i am still loged in on my Ipad (not on computer) and can check my account balances/etc and shocker they didn't mess with my account address or payout , but i always have payout set at .001.. and i don't mine here anymore.. guess that helped a bit too

But i do hope you guys come back up.. competition is always a good thing.


Icon

[jedimstr]

This thread is starting to sound like this:

1. The color is red.
2. Official Admin Post - Yeah the color is red. We're looking into it after Xmas.
3. Hey, did anyone know the color is red?
4. Just wanted to check here, did anyone notice the color is red.
5. I hate that the color is red.
6. Does anyone know what color it is?
7. *Bangs Head on table* - don't you all read, the color is red dammit!!!
8. Hey, I read every post and couldn't find the answer... Is the color red?
...snip...
10003029. Read my blog post: " the color red vs the color blue, a retrospective"
10003030. You know what, I think... Yes.. It seems the color is red.
10003031. Can someone tell me if the color is red or not?

[renodaret]

yeah i didnt know because i have the coin balances page favorated and its only on the homepage

[jedimstr]

yeah i didnt know because i have the coin balances page favorated and its only on the homepage

It's also on every page of this thread for about 10 or so pages worth and even mentioned on this very page on every single post before yours.  No excuse.  It's like someone staring at a stop sign for an hour and saying, "hey, is that a stop sign?"

[thecoinrunner]

There is one thing that worries me seriously.   
The hack job was not a simple SQL insertion or whatever.
My auto-payout was switched off (never used it) -- I lost a balance of BTC 0.36 (ouch!).
What I noticed after the hack, was that the booking was a regular one, with the AT_DEBIT code and including the BTC 0.0001 fee.
The charge of the fee means that the hacker launched existing scripts, or stored procedures, to perform the transactions. And never mind passwords or PINs, his level of control was too high for that.
Also note the bookings were done in a short amount of time (thus automated). And at a moment everybody was busy with Christmas shopping to minimize the chance of getting caught.
The hacker certainly took his time to prepare all of this and has gain top-level access to the system.
I would suggest that aTriz and nearmiss study very closely what happened, and make sure the hacker lost his control.
Imagine him having access all over Christmas time and work on backdoors... horrible idea.

[mattopia]

There is one thing that worries me seriously.   
The hack job was not a simple SQL insertion or whatever.
My auto-payout was switched off (never used it) -- I lost a balance of BTC 0.36 (ouch!).
What I noticed after the hack, was that the booking was a regular one, with the AT_DEBIT code and including the BTC 0.0001 fee.
The charge of the fee means that the hacker launched existing scripts, or stored procedures, to perform the transactions. And never mind passwords or PINs, his level of control was too high for that.
Also note the bookings were done in a short amount of time (thus automated). And at a moment everybody was busy with Christmas shopping to minimize the chance of getting caught.
The hacker certainly took his time to prepare all of this and has gain top-level access to the system.
I would suggest that aTriz and nearmiss study very closely what happened, and make sure the hacker lost his control.
Imagine him having access all over Christmas time and work on backdoors... horrible idea.

Disagree.  I suspect there's a table of payouts to process, and a script that executes those payouts that runs via cron every few minutes.  All someone would need is a way to add entries to the payout table and a way to update the payout addresses for everyone (one query, possibly...  update blahtable set payout_address='BadGuysBTCAddress' or whatever, exclude a 'where' and it'll update every row).  If sql injection is possible, depending on the design of the database, this would have been quite easy.  It could possibly be done with just two queries.  I have no knowledge of the hashcows db, just thinking of "how i would have built it"

Big companies and financial institutions sniff and log their sql and other interactions between the front-end and back-end, and have lots of rules and regulations they must abide by to be part of the financial system.  As has been said, this is the wild west, anything is possible - there is a high risk, but potential high reward, and this kind of stuff will be happening again and again.

[jerrybusey]

There is one thing that worries me seriously.    
The hack job was not a simple SQL insertion or whatever.
My auto-payout was switched off (never used it) -- I lost a balance of BTC 0.36 (ouch!).
What I noticed after the hack, was that the booking was a regular one, with the AT_DEBIT code and including the BTC 0.0001 fee.
The charge of the fee means that the hacker launched existing scripts, or stored procedures, to perform the transactions. And never mind passwords or PINs, his level of control was too high for that.
Also note the bookings were done in a short amount of time (thus automated). And at a moment everybody was busy with Christmas shopping to minimize the chance of getting caught.
The hacker certainly took his time to prepare all of this and has gain top-level access to the system.
I would suggest that aTriz and nearmiss study very closely what happened, and make sure the hacker lost his control.
Imagine him having access all over Christmas time and work on backdoors... horrible idea.

Disagree.  I suspect there's a table of payouts to process, and a script that executes those payouts that runs via cron every few minutes.  All someone would need is a way to add entries to the payout table and a way to update the payout addresses for everyone (one query, possibly...  update blahtable set payout_address='BadGuysBTCAddress' or whatever, exclude a 'where' and it'll update every row).  If sql injection is possible, depending on the design of the database, this would have been quite easy.  It could possibly be done with just two queries.  I have no knowledge of the hashcows db, just thinking of "how i would have built it"

Big companies and financial institutions sniff and log their sql and other interactions between the front-end and back-end, and have lots of rules and regulations they must abide by to be part of the financial system.  As has been said, this is the wild west, anything is possible - there is a high risk, but potential high reward, and this kind of stuff will be happening again and again.

It was mentioned a few pages back that before the lockdown addresses were reverting to the attacker's address even after manually changing it. I have no idea about the veracity of that claim.

[thecoinrunner]

That might be simply because db changes were disabled already.
Just guessing :-)

[_Crash_]

Cant register on the site either.

[GoldBit89]

There is one thing that worries me seriously.   
The hack job was not a simple SQL insertion or whatever.
My auto-payout was switched off (never used it) -- I lost a balance of BTC 0.36 (ouch!).
What I noticed after the hack, was that the booking was a regular one, with the AT_DEBIT code and including the BTC 0.0001 fee.
The charge of the fee means that the hacker launched existing scripts, or stored procedures, to perform the transactions. And never mind passwords or PINs, his level of control was too high for that.
Also note the bookings were done in a short amount of time (thus automated). And at a moment everybody was busy with Christmas shopping to minimize the chance of getting caught.
The hacker certainly took his time to prepare all of this and has gain top-level access to the system.
I would suggest that aTriz and nearmiss study very closely what happened, and make sure the hacker lost his control.
Imagine him having access all over Christmas time and work on backdoors... horrible idea.

Bitcointalk Forum,Inputio,KBVE,HASHCOWS and many others---all same person/persons committing the crime......

[jedimstr]

There is one thing that worries me seriously.   
The hack job was not a simple SQL insertion or whatever.
My auto-payout was switched off (never used it) -- I lost a balance of BTC 0.36 (ouch!).
What I noticed after the hack, was that the booking was a regular one, with the AT_DEBIT code and including the BTC 0.0001 fee.
The charge of the fee means that the hacker launched existing scripts, or stored procedures, to perform the transactions. And never mind passwords or PINs, his level of control was too high for that.
Also note the bookings were done in a short amount of time (thus automated). And at a moment everybody was busy with Christmas shopping to minimize the chance of getting caught.
The hacker certainly took his time to prepare all of this and has gain top-level access to the system.
I would suggest that aTriz and nearmiss study very closely what happened, and make sure the hacker lost his control.
Imagine him having access all over Christmas time and work on backdoors... horrible idea.

Bitcointalk Forum,Inputio,KBVE,HASHCOWS and many others---all same person/persons committing the crime......

Possible... Probably behind the Dogecoin Christmas heist too: http://gizmodo.com/millions-of-meme-based-dogecoins-stolen-on-christmas-da-1489819762

[uh60james]

Cant register on the site either.

I wouldn't recommend it anyway until there are some answers and fixes in place.

[socket]

There is one thing that worries me seriously.   
The hack job was not a simple SQL insertion or whatever.
My auto-payout was switched off (never used it) -- I lost a balance of BTC 0.36 (ouch!).
What I noticed after the hack, was that the booking was a regular one, with the AT_DEBIT code and including the BTC 0.0001 fee.
The charge of the fee means that the hacker launched existing scripts, or stored procedures, to perform the transactions. And never mind passwords or PINs, his level of control was too high for that.
Also note the bookings were done in a short amount of time (thus automated). And at a moment everybody was busy with Christmas shopping to minimize the chance of getting caught.
The hacker certainly took his time to prepare all of this and has gain top-level access to the system.
I would suggest that aTriz and nearmiss study very closely what happened, and make sure the hacker lost his control.
Imagine him having access all over Christmas time and work on backdoors... horrible idea.

Disagree.  I suspect there's a table of payouts to process, and a script that executes those payouts that runs via cron every few minutes.  All someone would need is a way to add entries to the payout table and a way to update the payout addresses for everyone (one query, possibly...  update blahtable set payout_address='BadGuysBTCAddress' or whatever, exclude a 'where' and it'll update every row).  If sql injection is possible, depending on the design of the database, this would have been quite easy.  It could possibly be done with just two queries.  I have no knowledge of the hashcows db, just thinking of "how i would have built it"

Big companies and financial institutions sniff and log their sql and other interactions between the front-end and back-end, and have lots of rules and regulations they must abide by to be part of the financial system.  As has been said, this is the wild west, anything is possible - there is a high risk, but potential high reward, and this kind of stuff will be happening again and again.

It's the easiest most common attack vector.  99.9% of all attacks these days are SQL injection and/or XSS.  Zero day remote code execution (buffer overflows and the like) wouldn't be used for something like this.

[rascal777]

hashcows needs to wipe their computers and reload their software.

I lost .3 BTC.  I was not mining for days there.  What irritates me was that when I stopped looking at hashcows, they were auto paying out every day.

Same payout address  13R87ropkDKzDEuVeQoX64kkcLvPWVdTKH

[hotwired007]

https://blockchain.info/address/13R87ropkDKzDEuVeQoX64kkcLvPWVdTKH

Current balance is  40.78672487 BTC and every transaction for the address (755) was the 24th Dec by the looks of it.

[socket]

Also, consider that if it was a root level compromise why not just clear out the hot wallet in one transaction? The attacker had to work inside the website's withdrawal system.. again likely an injection attack that targeted the tables for payout address and manual payout queue.

[kalus]

Cant register on the site either.

lol last on the internet to know.

[mattopia]

Also, consider that if it was a root level compromise why not just clear out the hot wallet in one transaction? The attacker had to work inside the website's withdrawal system.. again likely an injection attack that targeted the tables for payout address and manual payout queue.

Exactly.  Why go through the trouble of using "the system" to payout from each individual account if you have a greater level of access.  As far as the lock-down, it looks to me like they just set the relevant database tables to read only in some way (either by granting read only privileges to the frontend's database user, or, simply making the db files read only..)  An appropriate response until they find and patch the vulnerability. 

No amount of anything in the front end (two factor, pin codes, etc) will mitigate it if the database is easily compromised via sql injection.  I am hoping a re-design of the database is in the cards - there are ways to build the back-end to mitigate or eliminate these types of possibilities.

[Tasweb]

As far as the lock-down, it looks to me like they just set the relevant database tables to read only in some way (either by granting read only privileges to the frontend's database user, or, simply making the db files read only..)  An appropriate response until they find and patch the vulnerability. 

No amount of anything in the front end (two factor, pin codes, etc) will mitigate it if the database is easily compromised via sql injection.  I am hoping a re-design of the database is in the cards - there are ways to build the back-end to mitigate or eliminate these types of possibilities.

I agree with you however if the whole database is read only why are they still encouraging us to mine? This is the bit that is worrying me and the reason I have moved my one little miner elsewhere.

On your second point, it is the front end design that allows sql injection attacks to happen, not database design. The database just does whatever it is told to do by the website or a command line interface. If this was an injection attack then it was either a coding error in the website or an out of date/misconfigured PHP installation that allowed the "hackers" to most likely dump the database and then go through the tables to identify the payout addresses and the mechanism used to initiate manual payouts. They would have done this by manipulating the address bar in a browser by adding special characters or by experimenting with special characters or buffer overflows with very long entries in text entry fields on the website. All of this would be captured in the access logs for the website unless they were able to gain shell access and modify/delete the logs.

I suspect the reason the site is still locked down is because the guys are still working out how the attack happened and the best way to prevent it from happening again.

Note that the site code doesn't look particularly professional. Should we really be able to view the password policy?

 password1: {
          minlength: 6,
          maxlength: 20,
          required: true

Hmmm, nice use of language there!!

$('#accountTab a').bind('click', function (e) {
           e.preventDefault()
        //alert('fuuuuck');

And again..

$('#statsTab a').bind('click', function (e) {
           e.preventDefault()
        //alert('fuuuuck');