MythicAgents / Athena

178 stars 38 forks source link

OSX requires Code signing #53

Open tr41nwr3ck opened 10 months ago

tr41nwr3ck commented 10 months ago

Big Sur requires executables to be signed to be run on M1. dotnet publish -r osx-arm64 will produce unsigned binaries. You will need to sign the published binary before it will run (Unless you are running with Apple SIP disabled and in developer mode).

You can sign the binaries with the Apple codesign tool. A simple adhoc signature would be sufficient for you to test. codesign -s - .

We will need to document this somewhere. It is possible we should have the dotnet publish notify the user of the need to sign the apphost.

This probably needs to be transferred back to the SDK if we want to change publish behavior.

richlander commented 10 months ago

It seems like overkill to notify the user on every publish what the rules are for macOS. I also don't think that it is the responsibility of a developer SDK to tell people this. It's a generic macOS requirement. This feels like the role of docs.

Doc on this topic: https://learn.microsoft.com/dotnet/core/install/macos-notarization-issues

Yes, this is a pain.

checkymander commented 9 months ago

One of the oracles! Thanks for your input!

Unfortunately due to the nature of this specific program, we can't not include the apphost since it's something that needs to be able to just be downloaded and executed with limited interaction from the user.

We'll need to figure out some way to handle signing of the app bundle, whether it's letting the person building the agent specify a code signing cert to do so, or just generating a self-signed one, and letting the operator figure out how to get it on box.

richlander commented 9 months ago

Is this a case where you have multiple people building this code and distributing binaries on macOS? In the more typical case, you'd provide an official build for macOS that satisfied the OS rules, and call it good. I assume lots of projects do that. I'm guessing that this model isn't sufficient for your needs. Is that correct?

checkymander commented 9 months ago

Yep exactly.

checkymander commented 9 months ago

This is a repo for an offensive security tool, which could be labeled as malware lol.

I don't want to get a MacOS signing cert, and make it easy for malicious people to run malware on MacOS devices/get blacklisted due to people using my signed software for malicious purposes.

richlander commented 9 months ago

Hah! Fun.

If folks build the tool on their own machine, it should work.

$ dotnet new console -o app
$ cd app
$ dotnet publish -o published
$ ./published/app 
Hello, World!
$ uname -a
Darwin Richs-MacBook-Air.local 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:34 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T8103 arm64

This works on my machine. I'm assuming that this approach isn't sufficient.

checkymander commented 9 months ago

Yeah so imagine a simulated phishing scenario, where a red teamer wanted to deploy this agent on a target mac user. The mac might not have dotnet installed, so they'd push a bundle file for the user to execute. Currently the mac wouldn't allow that bundle to execute until it's signed.

I just need to figure out an easy way to support an operator signing this bundle so that it can be executed. Either that or just inform them that they would need to get it signed before sending it to their target.

blowdart commented 9 months ago

You're discovering why we don't sign our runners, not even on Windows, but leave it as an exercise for the reader :)

richlander commented 9 months ago

I see. I think you need to play with codesign. I don't think we've documented this scenario since it's a bit off the beaten path and also probably not the thing that should appear in official docs since it is a bit subject to abuse.

checkymander commented 9 months ago

yeah, I think that's the route we'll likely end up going. I just need to put some cycles into figuring out, and documenting the flow

blowdart commented 9 months ago

If this were an official engagement @checkymander one approach I've seen as, as part of the contact and setup, that a test certificate should be used so a blue team would know they've discovered a test implant, rather than a real one. Group Policy/Intune is often used to push those out into trusted stores on multiple OSes. Then you generate the temp cert, provide it. and away you go.

checkymander commented 9 months ago

Thanks for the idea, I'll bring it up with my bt and see what they think