Toxy - Hackable Http Proxy To Simulate Server Failure Scenarios And Network Conditions

Toxy is a fully programmatic and hackable HTTP proxy to simulate server failure scenarios and unexpected network conditions , built for node.js / io.js .

It was mainly designed for fuzzing/evil testing purposes, when toxy becomes particularly useful to cover fault tolerance and resiliency capabilities of a system, especially in disruption-tolerant networks and service-oriented architectures, where toxy may act as MitM proxy among services.

toxy allows you to plug in poisons, optionally filtered by rules, which essentially can intercept and alter the HTTP flow as you need, performing multiple evil actions in the middle of that process, such as limiting the bandwidth, delaying TCP packets, injecting network jitter latency or replying with a custom error or status code. It operates only at L7 (application level).

toxy can be fluently used programmatically or via HTTP API . It was built on top of rocky , a full-featured middleware-oriented HTTP proxy, and it's also pluggable in connect / express as standard middleware.

Requires node.js +0.12 or io.js +1.6

Features

• Full-featured HTTP/S proxy (backed by rocky and http-proxy )
• Hackable and elegant programmatic API (inspired on connect/express)
• Admin HTTP API for external management and dynamic configuration
• Featured built-in router with nested configuration
• Hierarchical and composable poisoning with rule based filtering
• Hierarchical middleware layer (both global and route scopes)
• Easily augmentable via middleware (based on connect/express middleware)
• Supports both incoming and outgoing traffic poisoning
• Built-in poisons (bandwidth, error, abort, latency, slow read...)
• Rule-based poisoning (probabilistic, HTTP method, headers, body...)
• Supports third-party poisons and rules
• Built-in balancer and traffic interceptor via middleware
• Inherits API and features from rocky
• Compatible with connect/express (and most of their middleware)
• Able to run as standalone HTTP proxy

Introduction

Why toxy?
There're some other similar solutions like toxy in the market, but most of them do not provide a proper programmatic control and usually are not easy to hack, configure or are directly closed to extensibility.
Furthermore, the majority of the those solutions only operates at TCP L3 level stack instead of providing high-level abstractions to cover common requirements in the specific domain and nature of the HTTP L7 protocol, like toxy tries to provide
toxy brings a powerful hackable and extensible solution with a convenient abstraction, but without losing a proper low-level interface capabilities to deal with HTTP protocol primitives easily.
toxy was designed based on the rules of composition, simplicity and extensibility. Via its built-in hierarchical domain specific middleware layer you can easily augment toxy features to your own needs.

Concepts
toxy introduces two directives: poisons and rules.
Poisons are the specific logic which infects an incoming or outgoing HTTP transaction (e.g: injecting a latency, replying with an error). One HTTP transaction can be poisoned by one or multiple poisons, and those poisons can be also configured to infect both global or route level traffic.
Rules are a kind of match validation filters that inspects an HTTP request/response in order to determine, given a certain rules, if the HTTP transaction should be poisioned or not (e.g: if headers matches, query params, method, body...). Rules can be reused and applied to both incoming and outgoing traffic flows, including different scopes: global, route or poison level.

How it works

↓  ( Incoming request )  ↓
↓          |||           ↓
↓    +-------------+     ↓
↓    | Toxy Router |     ↓ -> Match the incoming request
↓    +-------------+     ↓
↓          |||           ↓
↓ +--------------------+ ↓
↓ |   Incoming phase   | ↓ -> The proxy receives the request from the client
↓ |~~~~~~~~~~~~~~~~~~~~| ↓
↓ |  ----------------  | ↓
↓ |  |  Exec Rules  |  | ↓ -> Apply configured rules for the incoming request
↓ |  ----------------  | ↓
↓ |        |||         | ↓
↓ |  ----------------  | ↓
↓ |  | Exec Poisons |  | ↓ -> If all rules passed, then poison the HTTP flow
↓ |  ----------------  | ↓
↓ +~~~~~~~~~~~~~~~~~~~~+ ↓
↓        /      \        ↓
↓        \      /        ↓
↓ +--------------------+ ↓
↓ |  HTTP dispatcher   | ↓ -> Forward the HTTP traffic to the target server, either poisoned or not
↓ +--------------------+ ↓
↓        /      \        ↓
↓        \      /        ↓
↓ +--------------------+ ↓
↓ |   Outgoing phase   | ↓ -> Receives response from target server
↓ |~~~~~~~~~~~~~~~~~~~~| ↓
↓ |  ----------------  | ↓
↓ |  |  Exec Rules  |  | ↓ -> Apply configured rules for the outgoing request
↓ |  ----------------  | ↓
↓ |        |||         | ↓
↓ |  ----------------  | ↓
↓ |  | Exec Poisons |  | ↓ -> If all rules passed, then poison the HTTP flow before send it to the client
↓ |  ----------------  | ↓
↓ +~~~~~~~~~~~~~~~~~~~~+ ↓
↓          |||           ↓
↓ ( Send to the client ) ↓ -> Finally, send the request to the client, either poisoned or not

Usage

Installation

npm install toxy

Examples
See examples directory for more use cases.

var toxy = require('toxy')
var poisons = toxy.poisons
var rules = toxy.rules

// Create a new toxy proxy
var proxy = toxy()

// Default server to forward incoming traffic
proxy
  .forward('http://httpbin.org')

// Register global poisons and rules
proxy
  .poison(poisons.latency({ jitter: 500 }))
  .rule(rules.probability(25))

// Register multiple routes
proxy
  .get('/download/*')
  .forward('http://files.myserver.net')
  .poison(poisons.bandwidth({ bps: 1024 }))
  .withRule(rules.headers({'Authorization': /^Bearer (.*)$/i }))

// Infect outgoing traffic only (after the server replied properly)
proxy
  .get('/image/*')
  .outgoingPoison(poisons.bandwidth({ bps: 512 }))
  .withRule(rules.method('GET'))
  .withRule(rules.timeThreshold({ duration: 1000, threshold: 1000 * 10 }))
  .withRule(rules.responseStatus({ range: [ 200, 400 ] }))

proxy
  .all('/api/*')
  .poison(poisons.rateLimit({ limit: 10, threshold: 1000 }))
  .withRule(rules.method(['POST', 'PUT', 'DELETE']))
  // And use a different more permissive poison for GET requests
  .poison(poisons.rateLimit({ limit: 50, threshold: 1000 }))
  .withRule(rules.method('GET'))

// Handle the rest of the traffic
proxy
  .all('/*')
  .poison(poisons.slowClose({ delay: 1000 }))
  .poison(poisons.slowRead({ bps: 128 }))
  .withRule(rules.probability(50))

proxy.listen(3000)
console.log('Server listening on port:', 3000)
console.log('Test it:', 'http://localhost:3000/image/jpeg')

Poisons
Poisons host specific logic which intercepts and mutates, wraps, modify and/or cancel an HTTP transaction in the proxy server. Poisons can be applied to incoming or outgoing, or even both traffic flows.
Poisons can be composed and reused for different HTTP scenarios. They are executed in FIFO order and asynchronously.

Poisoning scopes
toxy has a hierarchical design based on two different scopes: global and route .
Global scope points to all the incoming HTTP traffic received by the proxy server, regardless of the HTTP method or path.
Route scope points to any incoming traffic which matches with a specific HTTP verb and URI path.
Poisons can be plugged to both scopes, meaning you can operate with better accuracy and restrict the scope of the poisoning, for instance, you might wanna apply a bandwidth limit poisoning only to a certain routes, such as /download or /images .
See routes.js for a featured example.

Poisoning phases
Poisons can be plugged to incoming or outgoing traffic flows, or even both.
Incoming poisoning is applied when the traffic has been received by proxy but it has not been forwarded to the target server yet.
Outgoing poisoning refers to the traffic that has been forwarded to the target server and when proxy recieves the response from it, but that response has not been sent to the client yet.
This means, essentially, that you can plug in your poisons to infect the HTTP traffic before or after the request is forwarded to the target HTTP server or sent to the client.
This allows you apply a better and more accurated poisoning based on the request or server response. For instance, given the nature of some poisons, like inject error , you may want to enable it according to the target server response (e.g: some header is present or not).
See poison-phases.js for a featured example.

Built-in poisons

Latency

Name	latency
Poisoning Phase	incoming / outgoing
Reaches the server	true

Infects the HTTP flow injecting a latency jitter in the response
Arguments :

• options object
  • jitter number - Jitter value in miliseconds
  • max number - Random jitter maximum value
  • min number - Random jitter minimum value

toxy.poison(toxy.poisons.latency({ jitter: 1000 }))
// Or alternatively using a random value
toxy.poison(toxy.poisons.latency({ max: 1000, min: 100 }))

Inject response

Name	inject
Poisoning Phase	incoming / outgoing
Reaches the server	false (only as incoming poison)

Injects a custom response, intercepting the request before sending it to the target server. Useful to inject errors originated in the server.
Arguments :

• options object
  • code number - Response HTTP status code. Default 500
  • headers object - Optional headers to send
  • body mixed - Optional body data to send. It can be a buffer or string
  • encoding string - Body encoding. Default to utf8

toxy.poison(toxy.poisons.inject({
  code: 503,
  body: '{"error": "toxy injected error"}',
  headers: {'Content-Type': 'application/json'}
}))

Bandwidth

Name	bandwidth
Poisoning Phase	incoming / outgoing
Reaches the server	true

Limits the amount of bytes sent over the network in outgoing HTTP traffic for a specific time frame.
This poison is basically an alias to throttle.
Arguments :

• options object
  • bytes number - Amount of chunk of bytes to send. Default 1024
  • threshold number - Packets time frame in miliseconds. Default 1000

toxy.poison(toxy.poisons.bandwidth({ bytes: 512 }))

Rate limit

Name	rateLimit
Poisoning Phase	incoming / outgoing
Reaches the server	true

Limits the amount of requests received by the proxy in a specific threshold time frame. Designed to test API limits. Exposes typical X-RateLimit-* headers.
Note that this is very simple rate limit implementation, indeed limits are stored in-memory, therefore are completely volalite. There're a bunch of featured and consistent rate limiter implementations in npm that you can plug in as poison. You might be also interested in token bucket algorithm.
Arguments :

• options object
  • limit number - Total amount of requests. Default to 10
  • threshold number - Limit time frame in miliseconds. Default to 1000
  • message string - Optional error message when limit is reached.
  • code number - HTTP status code when limit is reached. Default to 429 .

toxy.poison(toxy.poisons.rateLimit({ limit: 5, threshold: 10 * 1000 }))

Slow read

Name	rateLimit
Poisoning Phase	incoming
Reaches the server	true

Reads incoming payload data packets slowly. Only valid for non-GET request.
Arguments :

• options object
  • chunk number - Packet chunk size in bytes. Default to 1024
  • threshold number - Limit threshold time frame in miliseconds. Default to 1000

toxy.poison(toxy.poisons.slowRead({ chunk: 2048, threshold: 1000 }))

Slow open
Name: slowOpen

Name	slowOpen
Poisoning Phase	incoming
Reaches the server	true

Delays the HTTP connection ready state.
Arguments :

• options object
  • delay number - Delay connection in miliseconds. Default to 1000

toxy.poison(toxy.poisons.slowOpen({ delay: 2000 }))

Slow close

Name	slowClose
Poisoning Phase	incoming / outgoing
Reaches the server	true

Delays the HTTP connection close signal (EOF).
Arguments :

• options object
  • delay number - Delay time in miliseconds. Default to 1000

toxy.poison(toxy.poisons.slowClose({ delay: 2000 }))

Throttle

Name	throttle
Poisoning Phase	incoming / outgoing
Reaches the server	true

Restricts the amount of packets sent over the network in a specific threshold time frame.
Arguments :

• options object
  • chunk number - Packet chunk size in bytes. Default to 1024
  • delay object - Data chunk delay time frame in miliseconds. Default to 100

toxy.poison(toxy.poisons.throttle({ chunk: 2048, threshold: 1000 }))

Abort connection

Name	abort
Poisoning Phase	incoming / outgoing
Reaches the server	false (only as incoming poison)

Aborts the TCP connection. From the low-level perspective, this will destroy the socket on the server, operating only at TCP level without sending any specific HTTP application level data.
Arguments :

• options object
  • delay number - Aborts TCP connection after waiting the given miliseconds. Default to 0
  • next boolean - If true , the connection will be aborted if the target server takes more than the delay param time to reply. Default to false
  • error Error - Custom internal node.js error to use when destroying the socket. Default to null

// Basic connection abort
toxy.poison(toxy.poisons.abort())
// Abort after a delay
toxy.poison(toxy.poisons.abort(1000))
// In this case, the socket will be closed if
// the target server takes more than
// 2 seconds to respond
toxy.poison(toxy.poisons.abort({ delay: 2000, next: true }))

Timeout

Name	timout
Poisoning Phase	incoming / outgoing
Reaches the server	true

Defines a response timeout. Useful when forward to potentially slow servers.
Arguments :

• miliseconds number - Timeout limit in miliseconds

toxy.poison(toxy.poisons.timeout(5000))

How to write poisons
Poisons are implemented as standalone middleware (like in connect/express).
Here's a simple example of a server latency poison:

var toxy = require('toxy')

function customLatency(delay) {
  /**
   * We name the function since toxy uses it as identifier to get/disable/remove it in the future
   */
  return function customLatency(req, res, next) {
    var timeout = setTimeout(clean, delay)
    req.once('close', onClose)

    function onClose() {
      clearTimeout(timeout)
      next('client connection closed')
    }

    function clean() {
      req.removeListener('close', onClose)
      next()
    }
  }
}

var proxy = toxy()

// Register and enable the poison
proxy
  .get('/foo')
  .poison(customLatency(2000))

You can optionally extend the build-in poisons with your own poisons:

toxy.addPoison(customLatency)

// Then you can use it as a built-in poison
proxy
  .get('/foo')
  .poison(toxy.poisons.customLatency)

For featured real example, take a look to the built-in poisons implementation.

Rules
Rules are simple validation filters which inspects an incoming or outgoing HTTP traffic in order to determine, given a certain rules (e.g: matches the method, headers, query params, body...), if the current HTTP transaction should be poisoned or not, based on the resolution value of the rule.
Rules are useful to compose, decouple and reuse logic among different scenarios of poisoning. Rules can be applied to global, route or even poison scope, and it also applies to both phases of poisoning .
Rules are executed in FIFO order. Their evaluation logic is equivalent to Array#every() in JavaScript: all the rules must pass in order to proceed with the poisoning.

Built-in rules

Probability

Name	probability
Poison Phase	incoming / outgoing

Enables the rule by a random probabilistic. Useful for random poisoning.
Arguments :

• percentage number - Percentage of filtering. Default 50

var rule = toxy.rules.probability(85)
toxy.rule(rule)

Time threshold

Name	timeThreshold
Poison Phase	incoming / outgoing

Simple rule to enable poisons based on a specific time threshold and duration. For instance, you can enable a certain poisons during a specific amount of time (e.g: 1 second) within a time threshold (e.g: 1 minute).
Arguments :

• options object
  • duration number - Enable time inverval in miliseconds. Default to 1000
  • threshold number - Time threshold in miliseconds to wait before re-enable the poisoning. Default to 10000

// Enable the poisoning only 100 miliseconds per each 10 seconds
proxy.rule(toxy.rules.timeThreshold(100))
// Enable poisoning during 1 second every minute
proxy.rule(toxy.rules.timeThreshold({ duration: 1000, period: 1000 * 60 }))

Method

Name	method
Poison Phase	incoming / outgoing

Filters by HTTP method.
Arguments :

• method string|array - Method or methods to filter.

var method = toxy.rules.method(['GET', 'POST'])
toxy.rule(method)

Content Type
Filters by content type header. It should be present
Arguments :

• value string|regexp - Header value to match.

var rule = toxy.rules.contentType('application/json')
toxy.rule(rule)

Headers

Name	headers
Poison Phase	incoming / outgoing

Filter by request headers.
Arguments :

• headers object - Headers to match by key-value pair. value can be a string, regexp, boolean or function(headerValue, headerName) => boolean

var matchHeaders = {
  'content-type': /^application/\json/i,
  'server': true, // meaning it should be present,
  'accept': function (value, key) {
    return value.indexOf('text') !== -1
  }
}

var rule = toxy.rules.headers(matchHeaders)
toxy.rule(rule)

Response headers

Name	responseHeaders
Poison Phase	outgoing

Filter by response headers from target server. Same as headers rule, but evaluating the outgoing request.
Arguments :

• headers object - Headers to match by key-value pair. value can be a string , regexp , boolean or function(headerValue, headerName) => boolean

var matchHeaders = {
  'content-type': /^application/\json/i,
  'server': true, // meaning it should be present,
  'accept': function (value, key) {
    return value.indexOf('text') !== -1
  }
}

var rule = toxy.rules.responseHeaders(matchHeaders)
toxy.rule(rule)

Body

Name	body
Poison Phase	incoming / outgoing

Match incoming body payload by a given string , regexp or custom filter function .
This rule is pretty simple, so for complex body matching (e.g: validating against a JSON schema) you should probably write your own rule.
Arguments :

• match string|regexp|function - Body content to match
• limit string - Optional. Body limit in human size. E.g: 5mb
• encoding string - Body encoding. Default to utf8
• length number - Body length. Default taken from Content-Length header

var rule = toxy.rules.body('"hello":"world"')
toxy.rule(rule)

// Or using a filter function returning a boolean
var rule = toxy.rules.body(function contains(body) {
  return body.indexOf('hello') !== -1
})
toxy.rule(rule)

Response body

Name	responseBody
Poison Phase	outgoing

Match outgoing body payload by a given string , regexp or custom filter function .
Arguments :

• match string|regexp|function - Body content to match
• encoding string - Body encoding. Default to utf8
• length number - Body length. Default taken from Content-Length header

var rule = toxy.rules.responseBody('"hello":"world"')
toxy.rule(rule)

// Or using a filter function returning a boolean
var rule = toxy.rules.responseBody(function contains(body) {
  return body.indexOf('hello') !== -1
})
toxy.rule(rule)

Response status

Name	responseStatus
Poison Phase	outgoing

Evaluates the response status from the target server. Only applicable to outgoing poisons.
Arguments :

• range array - Pair of status code range to match. Default [200, 300] .
• lower number - Compare status as lower than operation. Default to null .
• higher number - Compare status as higher than operation. Default to null .
• value number - Status code to match using a strict equality comparison. Default null .
• include array - Unordered list of status codes to match. Useful to specify custom status. Default null

// Strict evaluation of the status code
toxy.rule(toxy.rules.responseBody(200))
// Using a range of valid status
toxy.rule(toxy.rules.responseBody([200, 204]))
// Using relational comparison
toxy.rule(toxy.rules.responseBody({ higher: 199, lower: 400 }))
// Custom unordered status code to match
toxy.rule(toxy.rules.responseBody({ include: [200, 204, 400, 404] }))

Third-party rules
List of available third-party rules provided by the community. PR are welcome.

• IP - Enable/disable poisons based on the client IP address (supports CIDR, subnets, ranges...).

How to write rules
Rules are simple middleware functions that resolve asyncronously with a boolean value to determine if a given HTTP transaction should be ignored when poisoning.
Your rule must resolve with a boolean param calling the next(err, shouldIgnore) function in the middleware, passing a true value if the rule has not matches and should not apply the poisoning, and therefore continuing with the next middleware stack.
Here's an example of a simple rule matching the HTTP method to determine if:

var toxy = require('toxy')

function customMethodRule(matchMethod) {
  /**
   * We name the function since it's used by toxy to identify the rule to get/disable/remove it in the future
   */
  return function customMethodRule(req, res, next) {
    var shouldIgnore = req.method !== matchMethod
    next(null, shouldIgnore)
  }
}

var proxy = toxy()

// Register and enable the rule
proxy
  .get('/foo')
  .rule(customMethodRule('GET'))
  .poison(/* ... */)

You can optionally extend the build-in rules with your own rules:

toxy.addRule(customMethodRule)

// Then you can use it as a built-in poison
proxy
  .get('/foo')
  .rules(toxy.rules.customMethodRule)

For featured real examples, take a look to the built-in rules implementation

Programmatic API
toxy API is completely built on top the rocky API . In other words, you can use any of the methods, features and middleware layer natively provided by rocky .

toxy([ options ])
Create a new toxy proxy.
For supported options , please see rocky documentation

var toxy = require('toxy')

toxy({ forward: 'http://server.net', timeout: 30000 })

toxy
  .get('/foo')
  .poison(toxy.poisons.latency(1000))
  .withRule(toxy.rules.contentType('json'))
  .forward('http://foo.server')

toxy
  .post('/bar')
  .poison(toxy.poisons.bandwidth({ bps: 1024 }))
  .withRule(toxy.rules.probability(50))
  .forward('http://bar.server')

toxy
  .post('/boo')
  .outgoingPoison(toxy.poisons.bandwidth({ bps: 1024 }))
  .withRule(toxy.rules.method('GET'))
  .forward('http://boo.server')

toxy.all('/*')

toxy.listen(3000)

toxy#get(path, [ middleware... ])
Return: ToxyRoute
Register a new route for GET method.

toxy#post(path, [ middleware... ])
Return: ToxyRoute
Register a new route for POST method.

toxy#put(path, [ middleware... ])
Return: ToxyRoute
Register a new route for PUT method.

toxy#patch(path, [ middleware... ])
Return: ToxyRoute

toxy#delete(path, [ middleware... ])
Return: ToxyRoute
Register a new route for DELETE method.

toxy#head(path, [ middleware... ])
Return: ToxyRoute
Register a new route for HEAD method.

toxy#all(path, [ middleware... ])
Return: ToxyRoute
Register a new route for any method.

toxy#poisons => Object
Exposes a map with the built-in poisons. Prototype alias to toxy.poisons

toxy#rules => Object
Exposes a map with the built-in poisons. Prototype alias to toxy.rules

toxy#forward(url)
Define a URL to forward the incoming traffic received by the proxy.

toxy#balance(urls)
Forward to multiple servers balancing among them.
For more information, see the rocky docs

toxy#replay(url)
Define a new replay server. You can call this method multiple times to define multiple replay servers.
For more information, see the rocky docs

toxy#use(middleware)
Plug in a custom middleware.
For more information, see the rocky docs .

toxy#useResponse(middleware)
Plug in a response outgoing traffic middleware.
For more information, see the rocky docs .

toxy#useReplay(middleware)
Plug in a replay traffic middleware.
For more information, see the rocky docs

toxy#requestBody(middleware)
Intercept incoming request body. Useful to modify it on the fly.
For more information, see the rocky docs

toxy#responseBody(middleware)
Intercept outgoing response body. Useful to modify it on the fly.
For more information, see the rocky docs

toxy#middleware()
Return a standard middleware to use with connect/express.

toxy#host(host)
Overwrite the Host header with a custom value. Similar to forwardHost option.

toxy#redirect(url)
Redirect traffic to the given URL.

toxy#findRoute(routeIdOrPath, [ method ])
Find a route by ID or path and method.

toxy#listen(port)
Starts the built-in HTTP server, listening on a specific TCP port.

toxy#close([ callback ])
Closes the HTTP server.

toxy#poison(poison)
Alias: usePoison , useIncomingPoison
Register a new poison to infect incoming traffic.

toxy#outgoingPoison(poison)
Alias: useOutgoingPoison , responsePoison
Register a new poison to infect outgoing traffic.

toxy#rule(rule)
Alias: useRule
Register a new rule.

toxy#withRule(rule)
Aliases: poisonRule , poisonFilter
Apply a new rule for the latest registered poison.

toxy#enable(poison)
Enable a poison by name identifier

toxy#disable(poison)
Disable a poison by name identifier

toxy#remove(poison)
Return: boolean
Remove poison by name identifier.

toxy#isEnabled(poison)
Return: boolean
Checks if a poison is enabled by name identifier.

toxy#disableAll()
Alias: disablePoisons
Disable all the registered poisons.

toxy#getPoison(name)
Return: Directive|null
Searchs and retrieves a registered poison in the stack by name identifier.

toxy#getIncomingPoison(name)
Return: Directive|null
Searchs and retrieves a registered incoming poison in the stack by name identifier.

toxy#getOutgoingPoison(name)
Return: Directive|null
Searchs and retrieves a registered outgoing poison in the stack by name identifier.

toxy#getPoisons()
Return: array<Directive>
Return an array of registered poisons.

toxy#getIncomingPoisons()
Return: array<Directive>
Return an array of registered incoming poisons.

toxy#getOutgoingPoisons()
Return: array<Directive>
Return an array of registered outgoing poisons.

toxy#flush()
Alias: flushPoisons
Remove all the registered poisons.

toxy#enableRule(rule)
Enable a rule by name identifier.

toxy#disableRule(rule)
Disable a rule by name identifier.

toxy#removeRule(rule)
Return: boolean
Remove a rule by name identifier.

toxy#disableRules()
Disable all the registered rules.

toxy#isRuleEnabled(rule)
Return: boolean
Checks if the given rule is enabled by name identifier.

toxy#getRule(rule)
Return: Directive|null
Searchs and retrieves a registered rule in the stack by name identifier.

toxy#getRules()
Return: array<Directive>
Returns and array with the registered rules wrapped as Directive .

toxy#flushRules()
Remove all the rules.

toxy.addPoison(name, fn)
Extend built-in poisons.

toxy.addRule(name, fn)
Extend built-in rules.

toxy.poisons => Object
Exposes a map with the built-in poisons.

toxy.rules => Object
Exposes a map with the built-in rules.

toxy.VERSION => String
Current toxy semantic version.

ToxyRoute
ToxyRoute exposes the same interface as Toxy global interface, it just adds some route level additional methods .
Further actions you perform againts the ToxyRoute API will only be applicable at route-level (nested). In other words: you already know the API.
This example will probably clarify possible doubts:

var toxy = require('toxy')
var proxy = toxy()

// Now using the global API
proxy
  .forward('http://server.net')
  .poison(toxy.poisons.bandwidth({ bps: 1024 }))
  .rule(toxy.rules.method('GET'))

// Now create a route
var route = proxy
  .get('/foo')
  .toPath('/bar') // Route-level API method
  .host('server.net') // Route-level API method
  .forward('http://new.server.net')

// Now using the ToxyRoute interface
route
  .poison(toxy.poisons.bandwidth({ bps: 512 }))
  .rule(toxy.rules.contentType('json'))

Directive(middlewareFn)
A convenient wrapper internally used for poisons and rules.
Normally you don't need to know this interface, but for hacking purposes or more low-level actions might be useful.

Directive#enable()
Return: boolean

Directive#disable()
Return: boolean

Directive#isEnabled()
Return: boolean

Directive#rule(rule)
Alias: filter

Directive#handler()
Return: function(req, res, next)

HTTP API
The toxy HTTP API follows the JSON API conventions, including resource based hypermedia linking.

Usage
For a featured use case, see the admin server example.

const toxy = require('toxy')

// Create the toxy admin server
var admin = toxy.admin({ cors: true })
admin.listen(9000)

// Create the toxy proxy
var proxy = toxy()
proxy.listen(3000)

// Add the toxy instance to be managed by the admin server
admin.manage(proxy)

// Then configure the proxy
proxy
  .forward('http://my.target.net')

proxy
  .get('/slow')
  .poison(toxy.poisons.bandwidth({ bps: 1024 }))

// Handle the rest of the traffic
proxy
  .all('/*')
  .poison(toxy.poisons.bandwidth({ bps: 1024 * 5 }))

console.log('toxy proxy listening on port:', 3000)
console.log('toxy admin server listening on port:', 9000)

For more details about the admin programmatic API, see below .

Authorization
The HTTP API can be protected to unauthorized clients. Authorized clients must define the API key token via API-Key or Authorization HTTP headers.
To enable it, you should simple pass the following options to toxy admin server:

const toxy = require('toxy')

const opts = { apiKey: 's3cr3t' }
var admin = toxy.admin(opts)

admin.listen(9000)
console.log('protected toxy admin server listening on port:', 9000)

API
Hierarchy :

• Servers - Managed toxy instances
  • Rules - Globally applied rules
  • Poisons - Globally applied poisons
    • Rules - Poison-specific rules
  • Routes - List of configured routes
    • Route - Object for each specific route
      • Rules - Route-level registered rules
      • Poisons - Route-level registered poisons
        • Rules - Route-level poison-specific rules

GET /

Servers

GET /servers

GET /servers/:id

Rules

GET /servers/:id/rules

POST /servers/:id/rules
Accepts: application/json
Example payload:

{
  "name": "method",
  "options": "GET"
}

DELETE /servers/:id/rules

GET /servers/:id/rules/:id

DELETE /servers/:id/rules/:id

Poisons

GET /servers/:id/poison

POST /servers/:id/poisons
Accepts: application/json
Example payload:

{
  "name": "latency",
  "phase": "outgoing",
  "options": { "jitter": 1000 }
}

DELETE /servers/:id/poisons

GET /servers/:id/poisons/:id

DELETE /servers/:id/poisons/:id

GET /servers/:id/poisons/:id/rules

POST /servers/:id/poisons/:id/rules
Accepts: application/json
Example payload:

{
  "name": "method",
  "options": "GET"
}

DELETE /servers/:id/poisons/:id/rules

GET /servers/:id/poisons/:id/rules/:id

DELETE /servers/:id/poisons/:id/rules/:id

Routes

GET /servers/:id/routes

POST /servers/:id/routes
Accepts: application/json
Example payload:

{
  "path": "/foo", // Required
  "method": "GET", // use ALL for all the methods
  "forward": "http://my.server", // Optional custom forward server URL
}

DELETE /servers/:id/routes

GET /servers/:id/routes/:id

DELETE /servers/:id/routes/:id

Route rules

GET /servers/:id/routes/:id/rules

POST /servers/:id/routes/:id/rules
Accepts: application/json
Example payload:

{
  "name": "method",
  "options": "GET"
}

DELETE /servers/:id/routes/:id/rules

GET /servers/:id/routes/:id/rules/:id

DELETE /servers/:id/routes/:id/rules/:id

Route poisons

GET /servers/:id/routes/:id/poisons

POST /servers/:id/routes/:id/poisons
Accepts: application/json
Example payload:

{
  "name": "latency",
  "phase": "outgoing",
  "options": { "jitter": 1000 }
}

DELETE /servers/:id/routes/:id/poisons

GET /servers/:id/routes/:id/poisons/:id

DELETE /servers/:id/routes/:id/poisons/:id

GET /servers/:id/routes/:id/poisons/:id/rules

POST /servers/:id/routes/:id/poisons/:id/rules
Accepts: application/json
Example payload:

{
  "name": "method",
  "options": "GET"
}

DELETE /servers/:id/routes/:id/poisons/:id/rules

GET /servers/:id/routes/:id/poisons/:id/rules/:id

DELETE /servers/:id/routes/:id/poisons/:id/rules/:id

Programmatic API
The built-in HTTP admin server also provides a simple interface open to extensibility and hacking purposes. For instance, you can plug in additional middleware to the admin server, or register new routes.

toxy.admin([ opts ])
Returns: Admin
Supported options :

• apiKey string - Optional API key to protect the server
• port number - Optional. TCP port to listen
• cors boolean - Enable CORS for web browser access
• middleware array<function> - Plug in additional middleware
• ssl object - Node.js HTTPS server TLS options .

Admin#listen([ port, host ])
Start listening on the network.

Admin#manage(toxy)
Manage a toxy server instance.

Admin#find(toxy)
Find a toxy instance. Accepts toxy server ID or toxy instance.

Admin#remove(toxy)
Stop managing a toxy instance.

Admin#use(...middleware)
Register a middleware.

Admin#param(...middleware)
Register a param middleware.

Admin#get(path, [ ...middleware ])
Register a GET route.

Admin#post(path, [ ...middleware ])
Register a POST route.

Admin#put(path, [ ...middleware ])
Register a PUT route.

Admin#delete(path, [ ...middleware ])
Register a DELETE route.

Admin#patch(path, [ ...middleware ])
Register a PATCH route.

Admin#all(path, [ ...middleware ])
Register a route accepting any HTTP method.

Admin#middleware(req, res, next)
Middleware to plug in with connect/express.

Admin#close(cb)
Stop the server.

Download Toxy

Read More

Tails 1.7 - The Amnesic Incognito Live System

Tails is a live operating system, that you can start on almost any computer from a DVD, USB stick, or SD card. It aims at preserving your privacy and anonymity, and helps you to:

• use the Internet anonymously and circumvent censorship;
  all connections to the Internet are forced to go through the Tor network;
• leave no trace on the computer you are using unless you ask it explicitly;
• use state-of-the-art cryptographic tools to encrypt your files, emails and instant messaging.  

Tails, The Amnesic Incognito Live System, version 1.7, is out.
This release fixes numerous security issues. All users must upgrade as soon as possible.

New features

• You can now start Tails in offline mode to disable all networking for additional security. Doing so can be useful when working on sensitive documents.
  
• We added Icedove, a rebranded version of the Mozilla Thunderbird email client.
  Icedove is currently a technology preview. It is safe to use in the context of Tails but it will be better integrated in future versions until we remove Claws Mail. Users of Claws Mail should refer to our instructions to migrate their data from Claws Mail to Icedove.
  

Upgrades and changes

• Improve the wording of the first screen of Tails Installer.
  
• Restart Tor automatically if connecting to the Tor network takes too long. (#9516)
  
• Update several firmware packages which might improve hardware compatibility.
  
• Update the Tails signing key which is now valid until 2017.
  
• Update Tor Browser to 5.0.4.
  
• Update Tor to 0.2.7.4.
  

Fixed problems

• Prevent wget from leaking the IP address when using the FTP protocol. (#10364)
  
• Prevent symlink attack on ~/.xsession-errors via tails-debugging-info which could be used by the amnesia user to bypass read permissions on any file. (#10333)
  
• Force synchronization of data on the USB stick at the end of automatic upgrades. This might fix some reliability bugs in automatic upgrades.
  
• Make the "I2P is ready" notification more reliable.
  

Download Tails 1.7

Read More

Security Onion - Linux Distro For Intrusion Detection, Network Security Monitoring, And Log Management

Security Onion is a Linux distro for intrusion detection, network security monitoring, and log management. It's based on Ubuntu and contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, NetworkMiner, and many other security tools. The easy-to-use Setup wizard allows you to build an army of distributed sensors for your enterprise in minutes!

Easy-to-use Setup wizard allows you to build an army of distributed sensors for your enterprise in minutes


Analyze your NIDS/HIDS alerts with Squert


Pivot between multiple data types with Sguil and send pcaps to Wireshark and NetworkMiner


Use ELSA to slice and dice your logs


Access full packet capture with CapMe


Snort/Suricata and Bro compiled with PF_RING to handle lots of traffic


Easy updates

Data Types

• Alert data - HIDS alerts from OSSEC and NIDS alerts from Snort/Suricata
• Asset data from Prads and Bro
• Full content data from netsniff-ng
• Host data via OSSEC and syslog-ng
• Session data from Argus, Prads, and Bro
• Transaction data - http/ftp/dns/ssl/other logs from Bro

Download Security Onion

Read More

ARDT - Akamai Reflective DDoS Tool

Akamai Reflective DDoS Tool

Attack the origin host behind the Akamai Edge hosts and bypass the DDoS protection offered by Akamai services.

How it works...

Based off the research done at NCC: ( https://dl.packetstormsecurity.net/papers/attack/the_pentesters_guide_to_akamai.pdf )

Akamai boast around 100,000 edge nodes around the world which offer load balancing, web application firewall, caching etc, to ensure that a minimal amount of requests actually hit your origin web-server beign protected. However, the issue with caching is that you cannot cache something that is non-deterministic, I.E a search result. A search that has not been requested before is likely not in the cache, and will result in a Cache-Miss, and the Akamai edge node requesting the resource from the origin server itself.

What this tool does is, provided a list of Akamai edge nodes and a valid cache missing request, produces multiple requests that hit the origin server via the Akamai edge nodes. As you can imagine, if you had 50 IP addresses under your control, sending requests at around 20 per second, with 100,000 Akamai edge node list, and a request which resulting in 10KB hitting the origin, if my calculations are correct, thats around 976MB/ps hitting the origin server, which is a hell of a lot of traffic.

Finding Akamai Edge Nodes

To find Akamai Edge Nodes, the following script has been included:

# python ARDT_Akamai_EdgeNode_Finder.py

This can be edited quite easily to find more, it then saves the IPS automatically.

Download ARDT

Read More

Infernal-Twin - This Is Evil Twin Attack Automated (Wireless Hacking)

This tool is created to aid the penetration testers in assessing wireless security. Author is not responsible for misuse. Please read instructions thoroughly.

Usage

sudo python InfernalWireless.py

How to install

$ sudo apt-get install apache2
$ sudo apt-get install mysql-server libapache2-mod-auth-mysql php5-mysql

$ sudo apt-get install python-scapy 
$ sudo apt-get install python-wxtools
$ sudo apt-get install python-mysqldb

$ sudo apt-get install aircrack-ng

$ git clone https://github.com/entropy1337/infernal-twin.git
$ cd infernal-twin


$ python db_connect_creds.py 
dbconnect.conf doesn't exists or creds are incorrect
*************** creating DB config file ************
Enter the DB username: root
Enter the password: *************
trying to connect
username root

FAQ:

I have a problem with connecting to the Database
Solution:
(Thanks to @lightos for this fix)
There seem to be few issues with Database connectivity. The solution is to create a new user on the database and use that user for launching the tool. Follow the following steps.

1. Delete dbconnect.conf file from the Infernalwireless folder
   
2. Run the following command from your mysql console.
   mysql> use mysql;
   mysql> CREATE USER 'root2'@'localhost' IDENTIFIED BY 'enter the new password here';
   mysql> GRANT ALL PRIVILEGES ON \*.\* TO 'root2'@'localhost' WITH GRANT OPTION;
   
3. Try to run the tool again.
   

Release Notes:

New Features:

• GUI Wireless security assessment SUIT
  
• Impelemented
  
• WPA2 hacking
  
• WEP Hacking
  
• WPA2 Enterprise hacking
  
• Wireless Social Engineering
  
• SSL Strip
  
• Report generation
  
• PDF Report
  
• HTML Report
  
• Note taking function
  
• Data is saved into Database
  
• Network mapping
  
• MiTM
  
• Probe Request
  

Changes:

• Improved compatibility
  
• Report improvement
  
• Better NAT Rules
  

Bug Fixes:

• Wireless Evil Access Point traffic redirect
• Fixed WPA2 Cracking
• Fixed Infernal Wireless
• Fixed Free AP
• Check for requirements
• DB implementation via config file
• Improved Catch and error
• Check for requirements
• Works with Kali 2

Coming Soon:

• Parsing t-shark log files for gathering creds and more
  
• More attacks.
  

Expected bugs:

• Wireless card might not be supported
  
• Windodw might crash
  
• Freeze
  
• A lot of work to be done, but this tool is still being developed.
  

Download Infernal-Twin

Read More

LMD - Linux Malware Detect

Linux Malware Detect (LMD) is a malware scanner for Linux released under the GNU GPLv2 license, that is designed around the threats faced in shared hosted environments. It uses threat data from network edge intrusion detection systems to extract malware that is actively being used in attacks and generates signatures for detection. In addition, threat data is also derived from user submissions with the LMD checkout feature and from malware community resources. The signatures that LMD uses are MD5 file hashes and HEX pattern matches, they are also easily exported to any number of detection tools such as ClamAV.

The driving force behind LMD is that there is currently limited availability of open source/restriction free tools for Linux systems that focus on malware detection and more important that get it right. Many of the AV products that perform malware detection on Linux have a very poor track record of detecting threats, especially those targeted at shared hosted environments.

The threat landscape in shared hosted environments is unique from that of the standard AV products detection suite in that they are detecting primarily OS level trojans, rootkits and traditional file-infecting viruses but missing the ever increasing variety of malware on the user account level which serves as an attack platform.

The commercial products available for malware detection and remediation in multi-user shared environments remains abysmal. An analysis of 8,883 malware hashes, detected by LMD 1.5, against 30 commercial anti-virus and malware products paints a picture of how poorly commercial solutions perform.

DETECTED KNOWN MALWARE: 1951
% AV DETECT (AVG): 58
% AV DETECT (LOW): 10
% AV DETECT (HIGH): 100
UNKNOWN MALWARE: 6931

Using the Team Cymru malware hash registry, we can see that of the 8,883 malware hashes shipping with LMD 1.5, there was 6,931 or 78% of threats that went undetected by 30 commercial anti-virus and malware products. The 1,951 threats that were detected had an average detection rate of 58% with a low and high detection rate of 10% and 100% respectively. There could not be a clearer statement to the need for an open and community driven malware remediation project that focuses on the threat landscape of multi-user shared environments.

Features:

• MD5 file hash detection for quick threat identification
• HEX based pattern matching for identifying threat variants
• statistical analysis component for detection of obfuscated threats (e.g: base64)
• integrated detection of ClamAV to use as scanner engine for improved performance
• integrated signature update feature with -u|–update
• integrated version update feature with -d|–update-ver
• scan-recent option to scan only files that have been added/changed in X days
• scan-all option for full path based scanning
• checkout option to upload suspected malware to rfxn.com for review / hashing
• full reporting system to view current and previous scan results
• quarantine queue that stores threats in a safe fashion with no permissions
• quarantine batching option to quarantine the results of a current or past scans
• quarantine restore option to restore files to original path, owner and perms
• quarantine suspend account option to Cpanel suspend or shell revoke users
• cleaner rules to attempt removal of malware injected strings
• cleaner batching option to attempt cleaning of previous scan reports
• cleaner rules to remove base64 and gzinflate(base64 injected malware
• daily cron based scanning of all changes in last 24h in user homedirs
• daily cron script compatible with stock RH style systems, Cpanel & Ensim
• kernel based inotify real time file scanning of created/modified/moved files
• kernel inotify monitor that can take path data from STDIN or FILE
• kernel inotify monitor convenience feature to monitor system users
• kernel inotify monitor can be restricted to a configurable user html root
• kernel inotify monitor with dynamic sysctl limits for optimal performance
• kernel inotify alerting through daily and/or optional weekly reports
• e-mail alert reporting after every scan execution (manual & daily)
• path, extension and signature based ignore options
• background scanner option for unattended scan operations
• verbose logging & output of all actions

Source Data:

The defining difference with LMD is that it doesn’t just detect malware based on signatures/hashes that someone else generated but rather it is an encompassing project that actively tracks in the wild threats and generates signatures based on those real world threats that are currently circulating.

There are four main sources for malware data that is used to generate LMD signatures:

– Network Edge IPS: Through networks managed as part of my day-to-day job, primarily web hosting related, our web servers receive a large amount of daily abuse events, all of which is logged by our network edge IPS. The IPS events are processed to extract malware url’s, decode POST payload and base64/gzip encoded abuse data and ultimately that malware is retrieved, reviewed, classified and then signatures generated as appropriate. The vast majority of LMD signatures have been derived from IPS extracted data.

– Community Data: Data is aggregated from multiple community malware websites such as clean-mx and malwaredomainlist then processed to retrieve new malware, review, classify and then generate signatures.

– ClamAV: The HEX & MD5 detection signatures from ClamAV are monitored for relevant updates that apply to the target user group of LMD and added to the project as appropriate. To date there has been roughly 400 signatures ported from ClamAV while the LMD project has contributed back to ClamAV by submitting over 1,100 signatures and continues to do so on an ongoing basis.

– User Submission: LMD has a checkout feature that allows users to submit suspected malware for review, this has grown into a very popular feature and generates on average about 30-50 submissions per week.

Signature Updates:

The LMD signature are updated typically once per day or more frequently depending on incoming threat data from the LMD checkout feature, IPS malware extraction and other sources. The updating of signatures in LMD installations is performed daily through the default cron.daily script with the –update option, which can be run manually at any time.

An RSS feed is available for tracking malware threat updates: http://www.rfxn.com/api/lmd

Detected Threats:

LMD 1.5 has a total of 10,822 (8,908 MD5 / 1,914) signatures, before any updates. The top 60 threats by prevalence detected by LMD are as follows:

base64.inject.unclassed     perl.ircbot.xscan
bin.dccserv.irsexxy         perl.mailer.yellsoft
bin.fakeproc.Xnuxer         perl.shell.cbLorD
bin.ircbot.nbot             perl.shell.cgitelnet
bin.ircbot.php3             php.cmdshell.c100
bin.ircbot.unclassed        php.cmdshell.c99
bin.pktflood.ABC123         php.cmdshell.cih
bin.pktflood.osf            php.cmdshell.egyspider
bin.trojan.linuxsmalli      php.cmdshell.fx29
c.ircbot.tsunami            php.cmdshell.ItsmYarD
exp.linux.rstb              php.cmdshell.Ketemu
exp.linux.unclassed         php.cmdshell.N3tshell
exp.setuid0.unclassed       php.cmdshell.r57
gzbase64.inject             php.cmdshell.unclassed
html.phishing.auc61         php.defash.buno
html.phishing.hsbc          php.exe.globals
perl.connback.DataCha0s     php.include.remote
perl.connback.N2            php.ircbot.InsideTeam
perl.cpanel.cpwrap          php.ircbot.lolwut
perl.ircbot.atrixteam       php.ircbot.sniper
perl.ircbot.bRuNo           php.ircbot.vj_denie
perl.ircbot.Clx             php.mailer.10hack
perl.ircbot.devil           php.mailer.bombam
perl.ircbot.fx29            php.mailer.PostMan
perl.ircbot.magnum          php.phishing.AliKay
perl.ircbot.oldwolf         php.phishing.mrbrain
perl.ircbot.putr4XtReme     php.phishing.ReZulT
perl.ircbot.rafflesia       php.pktflood.oey
perl.ircbot.UberCracker     php.shell.rc99
perl.ircbot.xdh             php.shell.shellcomm

Real-Time Monitoring:

The inotify monitoring feature is designed to monitor paths/users in real-time for file creation/modify/move operations. This option requires a kernel that supports inotify_watch (CONFIG_INOTIFY) which is found in kernels 2.6.13+ and CentOS/RHEL 5 by default. If you are running CentOS 4 you should consider an inbox upgrade with:

http://www.rfxn.com/upgrade-centos-4-8-to-5-3/

There are three modes that the monitor can be executed with and they relate to what will be monitored, they are USERS|PATHS|FILES.

       e.g: maldet --monitor users
       e.g: maldet --monitor /root/monitor_paths
       e.g: maldet --monitor /home/mike,/home/ashton

The options break down as follows:

USERS: The users option will take the homedirs of all system users that are above inotify_minuid and monitor them. If inotify_webdir is set then the users webdir, if it exists, will only be monitored.

PATHS: A comma spaced list of paths to monitor

FILE: A line spaced file list of paths to monitor

Once you start maldet in monitor mode, it will preprocess the paths based on the option specified followed by starting the inotify process. The starting of the inotify process can be a time consuming task as it needs to setup a monitor hook for every file under the monitored paths. Although the startup process can impact the load temporarily, once the process has started it maintains all of its resources inside kernel memory and has a very small userspace footprint in memory or cpu usage.

Download LMD

Read More

XPL-SEARCH - Search Exploits In Multiple Exploit Databases

XPL SEARCH

Search exploits in multiple exploit databases!
 Exploit databases available:
 * Exploit-DB
 * MIlw0rm
 * PacketStormSecurity
 * IntelligentExploit
 * IEDB
 * CVE

TO RUN THE SCRIPT

PHP Version (cli) 5.5.8 or higher
 php5-cli         Lib
cURL support      Enabled
 php5-curl        Lib
cURL Version      7.40.0 or higher
allow_url_fopen   On
Permission        Writing & Reading

ABOUT DEVELOPER

Author_Nick       CoderPIRATA
Author_Name       Eduardo
Email             coderpirata@gmail.com
Blog              http://coderpirata.blogspot.com.br/
Twitter           https://twitter.com/coderpirata
Google+           https://plus.google.com/103146866540699363823
Pastebin          http://pastebin.com/u/CoderPirata
Github            https://github.com/coderpirata/

"CHANGELOG"

0.1 - [02/07/2015]
- Started.

0.2 - [12/07/2015]
- Added Exploit-DB.
- Added Colors, only for linux!
- Added Update Function.
- "Generator" of User-Agent reworked.
- Small errors and adaptations.

0.3 - [22/07/2015]
- Bugs solved.
- Added "save" Function.
- Added "set-db" function.

0.4 - [05/08/2015]
- Save function modified.
- Added Scan with list.

0.5 - [29/08/2015]
- Added search by Author.

0.6 - [09/09/2015]
- Now displays the author of the exploit.
 * Does not work with IntelligentExploit.
- Changes in search logs.

0.7 - [11/09/2015]
- Added search in CVE.
 * ID.
 * Simple search - id 6.
- Bug in exploit-db search, "papers" fixed.
- Added standard time of 60 seconds for each request.
- file_get_contents() was removed from "browser()".
- Code of milw00rm search has been modified.
- Changes in search logs.
- Added date.

0.7.1 - [17/09/2015]
- Bug in milw00rm solved

0.8 - [05/10/2015]
- Added shebang.
- Commands "save", "save-log" and "save-dir" have been modified.
- Added "no-db" option.
- GETOPT() modified - Thanks Jack2.
- Bug on save-dir solved.
- Others minor bugs solved.

Screenshot

Download XPL-SEARCH

Read More

MobSF (Mobile Security Framework) - Mobile (Android/iOS) Automated Pen-Testing Framework

Mobile Security Framework (MobSF) is an intelligent, all-in-one open source mobile application (Android/iOS) automated pen-testing framework capable of performing static and dynamic analysis. We've been depending on multiple tools to carry out reversing, decoding, debugging, code review, and pen-test and this process requires a lot of effort and time. Mobile Security Framework can be used for effective and fast security analysis of Android and iOS Applications. It supports binaries (APK & IPA) and zipped source code.

The static analyzer is able to perform automated code review, detect insecure permissions and configurations, and detect insecure code like ssl overriding, ssl bypass, weak crypto, obfuscated codes, improper permissions, hardcoded secrets, improper usage of dangerous APIs, leakage of sensitive/PII information, and insecure file storage. The dynamic analyzer runs the application in a VM or on a configured device and detects the issues at run time. Further analysis is done on the captured network packets, decrypted HTTPS traffic, application dumps, logs, error or crash reports, debug information, stack trace, and on the application assets like setting files, preferences, and databases. This framework is highly scalable that you can add your custom rules with ease. A quick and clean report can be generated at the end of the tests. We will be extending this framework to support other mobile platforms like Tizen, WindowsPhone etc. in future.

Documentation

• https://github.com/ajinabraham/Mobile-Security-Framework-MobSF/wiki/Documentation

Queries

• Features Requests: @ajinabraham or @OpenSecurity_IN .
• Open Bugs Here: https://github.com/ajinabraham/YSO-Mobile-Security-Framework/issues

Screenshots and Sample Report

Static Analysis - Android APK

Static Analysis - iOS IPA

Sample Report: http://opensecurity.in/research/security-analysis-of-android-browsers.html

v0.8.8 Changelog

• New name: Mobile Security Framework (MobSF)
• Added Dynamic Analysis
• VM Available for Download
• Fixed RCE
• Fixed Broken Manifest File Parsing Logic
• Sqlite DB Support
• Fixed Reporting with new PDF report
• Rescan Option
• Detect Root Detection
• Added Requiremnts.txt
• Automated Java Path Detection
• Improved Manifest and Code Analysis
• Fixed Unzipping error for Unix.
• Activity Tester Module
• Exported Activity Tester Module
• Device API Hooker with DroidMon
• SSL Certificate Pinning Bypass with JustTrustMe
• RootCloak to prevent root Detection
• Data Pusher to Dump Application Data
• pyWebproxy to decrypt SSL Traffic

v0.8.7 Changelog

• Improved Static Analysis Rules
• Better AndroidManifest View
• Search in Files

v0.8.6 Changelog

• Detects implicitly exported component from manifest.
• Added CFR decompiler support
• Fixed Regex DoS on URL Regex

v0.8.5 Changelog

• Bug Fix to support IPA MIME Type: application/x-itunes-ipa

v0.8.4 Changelog

• Improved Android Static Code Analysis speed (2X performance)
• Static Code analysis on Dexguard protected APK.
• Fixed a Security Issue - Email Regex DoS.
• Added Logging Code.
• All Browser Support.
• MIME Type Bug fix to Support IE.
• Fixed Progress Bar.

v0.8.3 Changelog

• View AndroidManifest.xml & Info.plist
• Supports iOS Binary (IPA)
• Bug Fix for Linux (Ubuntu), missing MIME Type Detection
• Check for Hardcoded Certificates
• Added Code to prevent from Directory Traversal

Credits

• Bharadwaj Machiraju (@tunnelshade_) - For writing pyWebProxy from scratch
• Thomas Abraham - For JS Hacks on UI.
• Anto Joseph (@antojosep007) - For the help with SuperSU.
• Tim Brown (@timb_machine) - For the iOS Binary Analysis Ruleset.
• Abhinav Sejpal (@Abhinav_Sejpal) - For poking me with bugs and feature requests.
• Anant Srivastava (@anantshri) - For Activity Tester Idea

Download Mobile-Security-Framework-Mobsf

Read More

Gping - Ping, But With A Graph

Ping, but with a graph

Install and run
Created/tested with Python 3.4, should run on 2.7 (will require the statistics module though).

pip3 install pinggraph

Tested on Windows and Ubuntu, should run on OS X as well. After installation just run:

gping [yourhost]

If you don't give a host then it pings google.

Why?
My apartments internet is all 4g, and while it's normally pretty fast it can be a bit flakey. I often found myself running ping -t google.com in a command window to get a rough idea of the network speed, and I thought a graph would be a great way to visualize the data. I still wanted to just use the command line though, so I decided to try and write a cross platform one that I could use. And here we are.

Code
For a quick hack the code started off really nice, but after I decided pretty colors were a good addition it quickly got rather complicated. Inside pinger.py is a function plot() , this uses a canvas-like object to "draw" things like lines and boxes to the screen. I found on Windows that changing the colors is slow and caused the screen to flicker, so theres a big mess of a function called process_colors to try and optimize that. Don't ask.

Download Gping

Read More