search

hashtopolis / server

Hashtopolis - distributed password cracking with Hashcat
GNU General Public License v3.0
1.45k stars 220 forks source link

[FEATURE] Make agent only run list of trusted or verified binaries #581

Open tosiara opened 4 years ago

tosiara commented 4 years ago

Currently the agent will download and run any executable that server instructs it in the response. In case the server gets compromised all the agents will get infected too very easily:

  1. register a malicious cracker
  2. create a task with the new cracker
  3. assign the task to all the agents
  4. agents will download and run the malicious executable

I would suggest the agent to accept only whitelisted hashes of 7z archives. So user can choose during agent installation:

  1. secure mode - provide trusted SHA512 hashes of 7z archives
  2. old insecure mode - disable any checks and run whatever server returns

In this case user is explicitly confirms that the risk is known to him and he is responsible for any damage in case server gets hacked

blazer2x commented 4 years ago

The file hash method won't stop the compromised server from issuing a comprised agent which ignores the hash checking though. Will need something better.

tosiara commented 4 years ago

Sorry, I didn't get your comment

If SHA512 is written into agent's local config during installation then:

  1. agent asks server for a task
  2. server assigns a malicious task with a new cracker
  3. agent downloads cracker's 7z from a specified URL
  4. agent verifies SHA512 of a 7z file and rejects it without even extracting
blazer2x commented 4 years ago

The server can issue a fake update to the agent, with a modified agent which will override the safety check if the server is compromised.

tosiara commented 4 years ago

I didn't know there is a way to update the agent remotely Good that my agent ZIP is owned by different user than pyhton process is running and thus is read-only. I hope this is enough to prevent remote modification of the agent. But I will verify this scenario too, thanks for pointing

H4xl0r commented 4 years ago

I didn't know there is a way to update the agent remotely Good that my agent ZIP is owned by different user than pyhton process is running and thus is read-only. I hope this is enough to prevent remote modification of the agent. But I will verify this scenario too, thanks for pointing

he is on the right and easiest way to implent more sec

roycewilliams commented 4 years ago

I honestly can't tell what a better way to manage this would be. Even code-signing certs would have to be on the server itself in order to sign new clients, which an attacker who compromised the server would have access to. So you'd have to have a process where the server administrator keeps a code-signing cert offline somehow. I don't see that this is worth the trade-off.

More generally, as a friend of @hops once said, "Every distributed computing framework has to have at least one RCE vulnerability." Remote execution is a core feature.

evilmog commented 4 years ago

Honestly by forcing whitelisting you would kill the dynamic capabilities of the system. By installing hashtopolis you are basically making the hashtopolis master the admin of all your systems. Its really designed for a closed network or with machines you trust and control.

I could see hashing all the files but you need an inband or out of band signaling system, I do my sync over rsync so ymmv but really protect your hashtopolis master and assume if its popped then every sub system is popped including your cracking nodes

tosiara commented 4 years ago

By installing hashtopolis you are basically making the hashtopolis master the admin of all your systems

I disagree with this statement. Personally, by installing hashtopolis agent I only give permission to GPU, and that's it. Think about it as a client option similar to Trust agent with secret data which is not on by default on the server side

So it would be nice to allow user explicitly select during agent install: does he want to grant full admin rights to the server or only allow access GPU? This would be very important feature

0xVavaldi commented 3 years ago

By running as a process on the system it has a level of access. That's it. If you don't run the program as admin then it won't gain admin rights but it will still run as the user you run the software as. And as a distributed system program there's fairly little you can do about this. The best you can do is set up a separate system/user/environment for your hashtopolis client and attach the GPU's directly. Such as a VM or K8 with passthrough.

All in all, you have to generally accept the risk to my knowledge. My suggestion is to have a virus scanner / anomaly detection system on all systems to catch anything out of the ordinary.

Nag1bat0r commented 3 years ago

Add a script that compare checksum of hashtopolis hashcat with original hashcat from offsite each time. Client dowload this file manualy and it can not by auto updated. It checksumm is diffrent - "ALARM!!!" and stop executing next string (python3 hashtopolis.zip). Somebody will use it cause of PARANOID MODE ON. Somebody will trust your server and don't need this checks for each time. Just give a choice for your client :)

roycewilliams commented 3 years ago

Pie-in-the-sky idea: add an option to the client to only download hashcat from official sources - hashcat.net or GitHub. (And if the job requires a beta or custom version of hashcat ... you're already in a different threat-model group)

This could pretty much put this argument to rest once and for all.

evilmog commented 3 years ago

I like that route

On Mon., Sep. 27, 2021, 6:51 p.m. Royce Williams, @.***> wrote:

Pie-in-the-sky idea: add an option to the client to only download hashcat from official sources - hashcat.net or GitHub. (And if the job requires a beta or custom version of hashcat ... you're already in a different threat-model group)

This could pretty much put this argument to rest once and for all.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hashtopolis/server/issues/581#issuecomment-928532589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZBQUV2H62AXGEXOO5UF6LUEEGS5ANCNFSM4KFW26KA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Nag1bat0r commented 2 years ago

"add an option to the client"

If i am a EVIL owner of hashtopolis server - i am an owner of the client (hashtopolis.zip) and i can modify it to bypass any protection...

roycewilliams commented 2 years ago

@Nag1bat0r There is usually no requirement that the client be one provided by the server. Both hashcat and the hashtopolis client can be indpendently downloaded and usually Just Work.

Of course, since the entire Hashtopolis model is to pass commands to hashcat on the command line, no amount of client selection hygiene is going to mitigate the fundamental "hey, please run this arbitrary commandline for me" model. :D

But it would at least eliminate the direct-executable tier of the problem.