Topic: [ANN][Pool][Profit-Switch][Optional Auto-Exchange per Coin][Vardiff] ~ Hashcows - page 94. (Read 347337 times)

I just set up a new mining rig pointed to Hashcows before leaving home a few days ago.  I forgot to set up remote access first, so I really hope it is still chugging away and I will ACTUALLY get credit for the mining being done... 

An update is overdue, hashing power is gradually dropping.

Hah, I just discovered the site, so 

We were promised to receive an update on Thursday. Well, today is Thursday, where is the update?   

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');

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.

lol last on the internet to know.

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.

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.

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

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.

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

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

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

Cant register on the site either.

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

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.

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.

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.

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?"