Challenge 50 ☆☆

Welcome to challenge Challenge 50. You need to guess the secret that is hidden in Java, Docker, Kubernetes, Vault, AWS or GCP.

Hiding in binaries revisited: .NET self contained runtime

It is super easy to find a secret in a DLL, but when you are on MacOS or Linux it is much harder. So I am sure we can keep one there right?

Show us that we should not do that! Can you find the secret in wrongsecrets-dotnet (or wrongsecrets-dotnet-arm, wrongsecrets-dotnet-linux)?

Answer to solution :

This challenge is specifically looking at a secret in a .NET8 binary

You can solve this challenge using the following alternative solutions:

  1. Find the secrets with ILSpy.

    • obtain the wrongsecrets-dotnet-<platform> binary, for this you can:

    • retrieve it from the Docker image

    • download it from the Wrongsecrets Binaries

    • Install .NET8 and .NET8 SDK

    • Install ilspycmd

    • optionally: Install sfextract: dotnet tool install -g sfextract

    • Unpack the self-contained binary: sfextract wrongsecrets-dotnet -o \./tmp. or use ilspy: mkdir tmp && ilspycmd -d wrongsecrets-dotnet-linux -o ~/tmp

    • Go to the tmp folder and do ilspycmd dotnetproject.dll to decompile the dll and find the secret. Don’t want to install the tools? check the WrongSecrets Desktop container!

Why Using binaries to hide a secret will only delay an attacker.

With beautiful free Reverse engineering applications like ILSpy, not a lot of things remain safe. Anyone who can load the executable in such tools can easily do reconnaissance and find secrets within your binary.

Encrypting the secret with a key embedded in the binary, and other funny puzzles do delay an attacker and just make it fun finding the secret. Be aware that, if the secret needs to be used by the executable, it eventually needs to be in memory ready to be executed.

Still need to have a secret in the binary? Make sure it can only be retrieved remotely after authenticating against a server.


Previous
Go the main page
Next
0