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:
Check out the documentation at docs.fairwinds.com
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!
Enjoying Polaris? Check out some of our other projects:
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 (Open Firmware Reverse Analysis Konsole) is a binary analysis and modification platform. OFRAK combines the ability to:
OFRAK supports a range of embedded firmware file formats beyond userspace executables, including:
OFRAK equips users with:
See ofrak.com for more details.
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.
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.
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
.
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.
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.
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).
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
.
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.
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.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.
myapp.firebaseio.com
then it will check if https://myapp.firebaseio.com/.json
returns something or gives permission denied.Check if the google API keys are publically accessible or not.
Duplicate
.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.
git clone https://github.com/mzfr/slicer
cd slicer
python3 slicer.py -h
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.
python3 slicer.py -d path/to/extact/apk -c config.json
The extractor module used to extract URLs and paths is taken from apkurlgrep by @ndelphit
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 :)
If you'd like you can buy me some coffee: