Polaris - Validation Of Best Practices In Your Kubernetes Clusters

Polaris is an open source policy engine for Kubernetes that validates and remediates resource configuration. It includes 30+ built in configuration policies, as well as the ability to build custom policies with JSON Schema. When run on the command line or as a mutating webhook, Polaris can automatically remediate issues based on policy criteria.

Polaris can be run in three different modes:

• As a dashboard - Validate Kubernetes resources against policy-as-code.
• As an admission controller - Automatically reject or modify workloads that don't adhere to your organization's policies.
• As a command-line tool - Incorporate policy-as-code into the CI/CD process to test local YAML files.

Documentation

Check out the documentation at docs.fairwinds.com

Join the Fairwinds Open Source Community

The goal of the Fairwinds Community is to exchange ideas, influence the open source roadmap, and network with fellow Kubernetes users. Chat with us on Slack or join the user group to get involved!

Other Projects from Fairwinds

Enjoying Polaris? Check out some of our other projects:

• Goldilocks - Right-size your Kubernetes Deployments by compare your memory and CPU settings against actual usage
• Pluto - Detect Kubernetes resources that have been deprecated or removed in future versions
• Nova - Check to see if any of your Helm charts have updates available
• rbac-manager - Simplify the management of RBAC in your Kubernetes clusters

Or check out the full list

Fairwinds Insights

If you're interested in running Polaris in multiple clusters, tracking the results over time, integrating with Slack, Datadog, and Jira, or unlocking other functionality, check out Fairwinds Insights, a platform for auditing and enforcing policy in Kubernetes clusters.

OFRAK - Unpack, Modify, And Repack Binaries

OFRAK (Open Firmware Reverse Analysis Konsole) is a binary analysis and modification platform. OFRAK combines the ability to:

• Identify and Unpack many binary formats
• Analyze unpacked binaries with field-tested reverse engineering tools
• Modify and Repack binaries with powerful patching strategies

OFRAK supports a range of embedded firmware file formats beyond userspace executables, including:

• Compressed filesystems
• Compressed & checksummed firmware
• Bootloaders
• RTOS/OS kernels

OFRAK equips users with:

• A Graphical User Interface (GUI) for interactive exploration and visualization of binaries
• A Python API for readable and reproducible scripts that can be applied to entire classes of binaries, rather than just one specific binary
• Recursive identification, unpacking, and repacking of many file formats, from ELF executables, to filesystem archives, to compressed and checksummed firmware formats
• Built-in, extensible integration with powerful analysis backends (angr, Binary Ninja, Ghidra, IDA Pro)
• Extensibility by design via a common interface to easily write additional OFRAK components and add support for a new file format or binary patching operation

See ofrak.com for more details.

GUI Frontend

The web-based GUI view provides a navigable resource tree. For the selected resource, it also provides: metadata, hex or text navigation, and a mini map sidebar for quickly navigating by entropy, byteclass, or magnitude. The GUI also allows for actions normally available through the Python API like commenting, unpacking, analyzing, modifying and packing resources.

Getting Started

OFRAK uses Git LFS. This means that you must have Git LFS installed before you clone the repository! Install Git LFS by following the instructions here. If you accidentally cloned the repository before installing Git LFS, cd into the repository and run git lfs pull.

See docs/environment-setup for detailed instructions on how to install OFRAK.

Documentation

OFRAK has general documentation and API documentation. Both can be viewed at ofrak.com/docs.

If you wish to make changes to the documentation or serve it yourself, follow the directions in docs/README.md.

License

The code in this repository comes with an OFRAK Community License, which is intended for educational uses, personal development, or just having fun.

Users interested in OFRAK for commercial purposes can request the Pro License, which for a limited period is available for a free 6-month trial. See OFRAK Licensing for more information.

Contributing

Red Balloon Security is excited for security researchers and developers to contribute to this repository.

For details, please see our contributor guide and the Python development guide.

Support

Please contact ofrak@redballoonsecurity.com, or write to us on the OFRAK Slack with any questions or issues regarding OFRAK. We look forward to getting your feedback! Sign up for the OFRAK Mailing List to receive monthly updates about OFRAK code improvements and new features.

This material is based in part upon work supported by the DARPA under Contract No. N66001-20-C-4032. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the DARPA. Distribution Statement “A” (Approved for Public Release, Distribution Unlimited).

Slicer - Tool To Automate The Boring Process Of APK Recon

A tool to automate the recon process on an APK file.

Slicer accepts a path to an extracted APK file and then returns all the activities, receivers, and services which are exported and have null permissions and can be externally provoked.

Note: The APK has to be extracted via jadx or apktool.

Summary

Why?

I started bug bounty like 3 weeks ago(in June 2020) and I have been trying my best on android apps. But I noticed one thing that in all the apps there were certain things which I have to do before diving in deep. So I just thought it would be nice to automate that process with a simple tool.

Why not drozer?

Well, drozer is a different beast. Even though it does finds out all the accessible components but I was tired of running those commands again and again.

Why not automate using drozer?

I actually wrote a bash script for running certain drozer commands so I won't have to run them manually but there was still some boring stuff that had to be done. Like Checking the strings.xml for various API keys, testing if firebase DB was publically accessible or if those google API keys have setup any cap or anything on their usage and lot of other stuff.

Why not search all the files?

I think that a tool like grep or ripgrep would be much faster to search through all the files. So if there is something specific that you want to search it would be better to use those tools. But if you think that there is something which should be checked in all the android files then feel free to open an issue.

Features

• Check if the APK has set the android:allowbackup to true

• Check if the APK has set the android:debuggable to true.

• Return all the activities, services and broadcast receivers which are exported and have null permission set. This is decided on the basis of two things:

  • android:exporte=true is present in any of the component and have no permission set.
  • If exported is not mention then slicer check if any Intent-filters are defined for that component, if yes that means that component is exported by default(This is the rule given in android documentation.)

• Check the Firebase URL of the APK by testing it for .json trick.

  • If the firebase URL is myapp.firebaseio.com then it will check if https://myapp.firebaseio.com/.json returns something or gives permission denied.
  • If this thing is open then that can be reported as high severity.

• Check if the google API keys are publically accessible or not.

  • This can be reported on some bounty programs but have a low severity.
  • But most of the time reporting this kind of thing will bring out the pain of Duplicate.
  • Also sometimes the company can just close it as not applicable and will claim that the KEY has a usage cap - r/suspiciouslyspecific
    

• Return other API keys that are present in strings.xml and in AndroidManifest.xml

• List all the file names present in /res/raw and res/xml directory.

• Extracts all the URLs and paths.

  • These can be used with tool like dirsearch or ffuf.

Installation

• Clone this repository

git clone https://github.com/mzfr/slicer

• cd slicer
• Now you can run it: python3 slicer.py -h

Usage

It's very simple to use. Following options are available:

Extract information from Manifest and strings of an APK

Usage:
        slicer [OPTION] [Extracted APK directory]

Options:

  -d, --dir             path to jadx output directory
  -o, --output          Name of the output file(not implemented)

I have not implemented the output flag yet because I think if you can redirect slicer output to a yaml file it will a proper format.

Usage Example

• Extract information from the APK and display it on the screen.

python3 slicer.py -d path/to/extact/apk -c config.json

Acknowledgements and Credits

The extractor module used to extract URLs and paths is taken from apkurlgrep by @ndelphit

Contribution

All the features implemented in this are things that I've learned in past few weeks, so if you think that there are various other things which should be checked in an APK then please open an issue for that feature and I'd be happy to implement that :)

Support

If you'd like you can buy me some coffee: