Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSX requires Code signing #53

Open
tr41nwr3ck opened this issue Jan 5, 2024 · 12 comments
Open

OSX requires Code signing #53

tr41nwr3ck opened this issue Jan 5, 2024 · 12 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@tr41nwr3ck
Copy link
Collaborator

tr41nwr3ck commented Jan 5, 2024

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.

@checkymander checkymander added documentation Improvements or additions to documentation enhancement New feature or request labels Jan 5, 2024
@richlander
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

Yep exactly.

@checkymander
Copy link
Collaborator

checkymander commented Jan 29, 2024

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
Copy link

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
Copy link
Collaborator

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
Copy link

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

@richlander
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants