ex0dus-0x/binsec

Binary (In)security tool

binsec's Issues

Analyze executable by process ID

Configuration consumption support

Allow users to construct YAML/TOML-based configurations that define the binaries to be analyzed, and the specific mode of execution mode they would like the detector to analyze it under.

Miscellaneous enhanced checks

Add other checks that can't be grouped and organized together.

This can include:

• Calling home using HTTP routines/syscalls or presence of URLs
• Presence of cryptocurrency addresses, strings or library calls
• May contain some type of polyglot embedded within the binary
• ..etc!

Incorporate opinionated security recommendations for binary harden checks

If specified with a flag like --opinion, return compiler flags that can be harnessed in order to mitigate any security features that are not set for the specific instance. Ie with partial RELRO for ELF binaries, we can recommend the following to upgrade to a full RELRO to prevent jumps to dynamically linked symbols:

-Wl,-z,relro,-z,now

If flag is set, this output should be incorporated in all output formats that are emitted.

Enhance bulk executable consumption and output

If we take in several executables at once and specify the output to be some type of serializable format, have some type of configuration to concatenate all of them together and output as one unit rather than seperate ones at once.

Make the use of kernel and rule-based checks optional and available as features

Some users may simply want to use binsec at its core to detect security features for binaries, without the burden of the other unused functionalities and their dependencies. If set, ie as kerncheck and rulecheck features, we can make them optional during installation.

Revamp: binsec for CI/CD

This started out as a learning lesson for parsing binaries with goblin and recognizing exploit protection primitives. However, there can be a much stronger push for this as an integration into software supply chain security mitigations.

binsec should be fully CI/CD ready for GitHub Actions, trigger detections on binary artifact releases and recommending additional compilation steps (as per #62). Not only does this create actionable security items for devs, but also a point of transparency for security researchers looking for vulns.

Check binaries for ASAN / UBSAN

Additional Windows PE and Kernel Checks

Good series of posts with information about different Windows mitigations:

• https://www.crowdstrike.com/blog/state-of-exploit-development-part-1/
• https://www.crowdstrike.com/blog/state-of-exploit-development-part-2/

For binary checks:

• Legacy ASLR
• ACG
• Authenticode
• CET / Return flow guarding

Data Research

• Generate datasets for features of all built-in binaries for specific operating systems
• Delivery report / visualization for built-ins or binaries in the wild
• Malware too??

Add LICENSE and publish on crates.io

Project Roadmap

Here are potential ideas for what to implement down the road:

• Multi-Platform Support - Windows and macOS binary security features
• Check security features on procs
• Recommended compiler flags to pass to enforce better security
• Use case - integration with automated CI/CD security pipeline to solve CTF challenges, or patch compiled unit tests.
• Potential malware detection support (integrate in YARA) ??
• Other binary security features I missed out on