KnC Miner : Security hacked - UPDATE with TOOL admin remove plz

[bitpop]

Op owes no one anything, he could have changed all your pools to his

Second who the hell opens the ports?

[steve15]

Op owes no one anything, he could have changed all your pools to his

Second who the hell opens the ports?

The KnC itselfs opens port 80 by default.
Some really dumb (or unknowing of course!) users also enable "ssh", and "CGMiner Remote Management Enabled" to make it even more easy to exploit them.

Can you image they can't check their miner on their iPad? Better to open all ports!! ;-)

[bitpop]

Op owes no one anything, he could have changed all your pools to his

Second who the hell opens the ports?

The KnC itselfs opens port 80 by default.
Some really dumb (or unknowing of course!) users also enable "ssh", and "CGMiner Remote Management Enabled" to make it even more easy to exploit them.

Can you image they can't check their miner on their iPad? Better to open all ports!! ;-)

Yeah but that port should never open to the wan

[mtbitcoin]

Just as a heads up .. I've had one these boxes compromised. I've now firewalled the entire box.

However, I suspect there is might a scheduled script to restart the miner in preconfigured intervals to point to a specific pool. Any ideas as to where I should be looking to see if there were any backdoors or schedule scripts/jobs?

Cheers

[steve15]

Just as a heads up .. I've had one these boxes compromised. I've now firewalled the entire box.

However, I suspect there is might a scheduled script to restart the miner in preconfigured intervals to point to a specific pool. Any ideas as to where I should be looking to see if there were any backdoors or schedule scripts/jobs?

Cheers

I did notice lots of miners already infected with a remote login called "nobody" in their configuration files.

It basically uses the same exploit, and totally took control over several miners.

It's mining at eligius, once I stumble upon that specific hacker again, I'll post his pool address.

Knc however, does not responds at all, let alone patch up their firmwares to protect the users.

Note, even my Jupiter has been hacked and infected by this eligius pool at specific times.

Execute code: userdel nobody in ssh.

Do not factory reset, as al these files are also infected.
It's not up to me to post details about how to remove this hacker, that's up to Knc, who clearly does not give a f*CK about it.

[steve15]

Edit, he just gained access to my miner again.

[mtbitcoin]

Edit, he just gained access to my miner again.

Cell phone screen shot of the hacker's pool

Do you have entire box firewalled? Or are there still specific ports open to the public. I've blocked of all incoming ports and so far so good

[steve15]

Edit, he just gained access to my miner again.

Cell phone screen shot of the hacker's pool

Do you have entire box firewalled? Or are there still specific ports open to the public. I've blocked of all incoming ports and so far so good

I let him gain access, on my turn, I'll abuse his details.
I'm waiting for his next login attempt now.

But there is a big issue with the miners.

Knc takes no action on this matter.

[steve15]

As far as I can see on my cell, it's a complete automated script. I think your firewall will be useless to this, since your box is already infected by it.

It will execute it's code again, keep checking your ssh en cgminer terminal closely.

Can you confirm it was the same elegius user?

[padrino]

I did notice lots of miners already infected with a remote login called "nobody" in their configuration files.

It basically uses the same exploit, and totally took control over several miners.

It's mining at eligius, once I stumble upon that specific hacker again, I'll post his pool address.

Knc however, does not responds at all, let alone patch up their firmwares to protect the users.

Note, even my Jupiter has been hacked and infected by this eligius pool at specific times.

Execute code: userdel nobody in ssh.

Do not factory reset, as al these files are also infected.
It's not up to me to post details about how to remove this hacker, that's up to Knc, who clearly does not give a f*CK about it.

nobody is a user and is there for running unprivileged items, standard Unix construct across distros.. If it's shell was changed from /nonexistant than one needs to worry about it but the user definitely exists on un-compromised boxes and is not an indication the box was compromised.. With that said I don't see it being used on any running binaries so it may not be needed on this box, just came as part of the busybox setup along with many of the other users..





Given some of the information kicking around this thread I decided to take a closer look at my Jupiters...

My Jupiters are completely behind a firewall so I can't say for sure but this conversation made me wonder what might be going on outside of a possible SSH or HTTP compromise... The basic security profile of the boxes is rather open but at it's heart it's no different than a Linux distro with a default username/password, Windows, etc. Although KnC should do more in their documentation to discuss changing things there are no actually vulnerabilities, just a weak security posture.

By default cgminer is open read/write for any address and in one of the recent firmware updates I think KnC enabled it by default..

Perhaps it's direct cgminer connections on the cgminer port?

Two options exist to mitigate:

- Disable cgminer remote management on the mining page.

- Another is a manual edit of the cgminer.conf file (manual mode) to disable world wide remote write access will take care of it, change   "api-allow": "W:0/0" to something more restrictive, for example W:192.168.0/24 if you only need access from 192.168.0.x addresses.

[Sophokles]

Steve is helping here.  He could have easily done this without posting anything and made a good amount of coin. Give the guy a break.

A tip is also welcome :-D

Post a tip address in your signature then  . You certainly did a big service to the (KnC-) mining community. Thumbs up from me.

[philipma1957]

 Well as annoyed as I was about the op's posting.  I will concede more then likely he is not the person that has crashed my groups 2 miners.

  Fact remains we have 1100gh dead in the water.  Since I don't run the gear and am A part owner I did direct our groups managers to this thread.

  We are still not hashing  I have to think our gear was hacked in the method described above.

 We were hacked  before this was posted so I can't say the op helped a hacker via this post to be able to attack us and my apology for my complaint against you. Since I just own a piece of the 1100gh pie I don't have full access to the records I can only say I have been told it hashes and nothing gets reported to our account.

https://bitcointalk.org/index.php?topic=334360.msg4310852#msg4310852


You know as fucking paranoid as BTC has made me I would not be surprised if a  KNC  employee did this.  Does not matter the fact remains that more then 1 jup   was attacked in more then 1 location.  oh well.

[kikikuku]

thank you !!!

[bitpop]

Well as annoyed as I was about the op's posting.  I will concede more then likely he is not the person that has crashed my groups 2 miners.

  Fact remains we have 1100gh dead in the water.  Since I don't run the gear and am A part owner I did direct our groups managers to this thread.

  We are still not hashing  I have to think our gear was hacked in the method described above.

 We were hacked  before this was posted so I can't say the op helped a hacker via this post to be able to attack us and my apology for my complaint against you. Since I just own a piece of the 1100gh pie I don't have full access to the records I can only say I have been told it hashes and nothing gets reported to our account.

https://bitcointalk.org/index.php?topic=334360.msg4310852#msg4310852


You know as fucking paranoid as BTC has made me I would not be surprised if a  KNC  employee did this.  Does not matter the fact remains that more then 1 jup   was attacked in more then 1 location.  oh well.

Your paranoia should lead you to the group leader. This thread was just a coincidence.

[steve15]

WARNING

I just found out that ANY miner with remote CGMINER enabled can be controlled remotely!!
I will NOT post how, but it seems that already lot's of hackers found out this exploit.

Nothing difficult, it uses a default cgminer script on your rig.

By default, enable cgminer options is activated on KnC rigs. In the cgminer configuration files, this is default to accept connections from any IP, worldwide.

I made a simple script, removing every user from the pools, adding my own pool, and set priority to 0.
This script loops every 2 seconds, making sure that nobody else mines on the rig except me.


Unvisible to the KnC user, he will only notice his pool does not add up.
I can even play safe, and make it schedule every X time.

Now, if i can make this script, so can anybody else!

!!! PLEASE DISABLE 'Enable cgminer remote' OPTION !!!

This can be used WITHOUT security, worldwide, by ANYONE !!

You have been warned...


Disclaimer: i did NOT use or abuse any rig except mine !!
Feel free to tip me for saving your multiple coins 

[padrino]

WARNING

I just found out that ANY miner with remote CGMINER enabled can be controlled remotely!!
I will NOT post how, but it seems that already lot's of hackers found out this exploit.

Umm, look at my post further up the thread from two days ago, I discuss this possibility and how to mitigate it..

[Phoenix1969]

Thanks alot for exploiting every KNC customer...   You went about this totally wrong.
although I appreciate the "heads up"... should have been given to Ckilovas and the KNC code boys when they return on the 7th
You literally just taught 1000 hackers how to steal....  great job   uuuuuggh

[ncs0ne]

This security issue concerns HTTP-Digest authentication via plain HTTP in general.
Even mentioned in the corresponding RFC somehow.

Digest Authentication offers no confidentiality protection beyond protecting the actual password. All of the rest of the request and response are available to an eavesdropper.

...

Many needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs TLS or SHTTP are more appropriate protocols. In particular Digest authentication cannot be used for any transaction requiring confidentiality protection.

...

Both Digest and Basic Authentication are very much on the weak end of the security strength spectrum.

I'm wondering whether KnCMiner will reply at all to the OP, as their reseller portal and their forum doesn't make use of HTTPS as well.
It's not that they are not aware of it, it seems more like they do not want to spend time and money on this.

http://forum.kncminer.com/forum/resellers-affilicates/general-questions/761-https-for-the-forum
http://forum.kncminer.com/forum/resellers-affilicates/general-questions/23414-ssl-please

This one has been removed from the KnC forum as it seems, check post 12.1:
http://webcache.googleusercontent.com/search?q=cache:07UiAUGwVhYJ:forum.kncminer.com/forum/main-category/hardware/21601-saturn-hacked-btcguild-account-hacked-be-careful-guys


And therefore I do not expect a reaction or change.

Sam
KnC Administrator

    Join Date: Aug 2013
    Posts: 12

#5
9th September 2013, 10:04 AM
SSL is on its way

Hope is gone, as I send an email myself some weeks ago concerning this.

[padrino]

This security issue concerns HTTP-Digest authentication via plain HTTP in general.
Even mentioned in the corresponding RFC somehow.

Digest Authentication offers no confidentiality protection beyond protecting the actual password. All of the rest of the request and response are available to an eavesdropper.

...

Many needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs TLS or SHTTP are more appropriate protocols. In particular Digest authentication cannot be used for any transaction requiring confidentiality protection.

I'm not sure what you are trying to imply here.. The use of HTTP digest and lack of HTTPS isn't a security issue by itself.

The data available in the web page does not require confidentiality, there isn't really any reason of value to protect it.

Digest provides protection against the password being read if someone is packet sniffing. Replay attacks are still possible if lighttpd does not use timestamps but even then someone would need to be in a position to packet sniff the segments between the user and the miner and also implement a replay attack. It's unlikely.

[ncs0ne]

At least for privacy reasons I'd prefer in general some data to be send encrypted.
Like my stats and worker-logins (in case of eligius the payout address).
In addition I prefer to be secure against skript-kiddy MITM attacks while I'm on travel.

Next gen of HTTP (2.0) is discussed to be encrypted by default as far as I know.
Why, there's no need to encrypt your traffic while you read the news or whatever.