Hackersmail - Cyber | Information | Cloud Security Blog: testing

VoIP ( Voice Over IP ) Security Assessment Tool :

Viproy :
Voip Penetration and Exploitation Kit is developed to improve quality of SIP penetration testing. It provides authentication and trust analysis features that assists in creating simple tests.
10 different modules with authentication support: options tester, brute forcer, enumerator, invite tester, trust analyzer, proxy and registration tester. All attacks could perform before and after authentication to fuzz SIP services and value added services.

Viproy is a tool for testing SIP servers security, the Session Initiation Protocol is widely used for voice and video calls over IP, the software comes with different modules performing specific tasks, all of the modules support debugging and verbose mode, this is a Linux only command line tool, instructions are included and it should not be difficult for a Linux beginner to understand them. - See more at: http://www.hacker10.com/tag/voip-penetration-testing/#sthash.vcWe7zby.dpuf

Video :

More Info : http://viproy.com/voipkit/

Download Link : https://github.com/fozavci/viproy-voipkit/archive/master.zip

SIPVicious : ( Tools for auditing SIP based VoIP systems )

SIPVicious suite is a set of tools that can be used to audit SIP based VoIP systems. It currently consists of four tools:

svmap - this is a sip scanner. Lists SIP devices found on an IP range
svwar - identifies active extensions on a PBX
svcrack - an online password cracker for SIP PBX
svreport - manages sessions and exports reports to various formats
svcrash - attempts to stop unauthorized svwar and svcrack scans

Download Link : http://code.google.com/p/sipvicious/downloads/list

VAST : ( VIPER Assessment Security Tools )

VAST is a Linux-based security distribution specifically designed for pentesting VoIP and UC networks. It enables security professionals and UC administrators to rapidly perform VoIP security assessments and enumerate vulnerabilities in IP Phones or IP PBX servers in a lab environment. With VAST, a security consultant has every tool necessary to carry out a successful onsite or remote penetration test or vulnerability assessment against a UC network. VAST is built on Mint Linux 13 and includes all of the open source VIPER Lab tools, in addition to some other network pentest tools.

Download Link : http://sourceforge.net/projects/vipervast/files/

SiVuS - VoIP vulnerability scanner

SiVuS is the first publicly available vulnerability scanner for VoIP networks that use the SIP protocol. It provides powerful features to assess the security and robustness of VoIP implementations and it is used by VoIP product vendors, security consultants, network architects, researchers and students. We encourage our community to provide us with feedback so we can enhance the current implementation and support the efforts to strengthen the security of VoIP networks.

More Info : http://nil.uniza.sk/sip/tools/sivus-voip-vulnerability-scanner

Download Link : http://www.voip-security.net/index.php/downloads/security/summary/30/299

FreeSentral :

is a full IP PBX consisting of a Linux Distribution, an IP PBX and a Web Graphical User Interface for easy configuration.

Features

Define, group extensions
Set dial plan
Direct Inward Calling
Set Auto Attendant
Music on hold
Short Dialing
Set call forwarding
Voicemail

For all security audits on VoIP systems, FreeSental can make a quick and easy solution to implement. It can therefore be used as a training platform for testing VoIP vulnerabilities and issues. See here our VoIP tools collection to help you auditing and scanning.

Download Link : http://www.freesentral.com/index.php/Download/Download

Thanks,

RRN Technologies

NAXSI ( Nginx Anti Xss & Sql Injection ) :
is an open source WAF ( Web Application Firewall ) , high performance, low rules maintenance, Web Application Firewall module for Nginx.

  _   _                _ 
 | \ | | __ ___  _____(_)
 |  \| |/ _` \ \/ / __| |
 | |\  | (_| |>  <\__ \ |
 |_| \_|\__,_/_/\_\___/_|

                          goal is to help people to secure their web application against attacks 
such as SQL Injection, Cross Site Scripting, Cross Site Request Forgery, 
Local & Remote file inclusions and such. 
The difference with most WAF (Web Applicative Firewalls) out there is that 
it does not rely on signatures to detect attacks. It is using a simpler model, 
where instead of trying to detect "known" attacks, it will detect unexpected 
characters in the HTTP request/arguments. Each kind of unusual character will 
increase the score of the request. If the request reaches a score that's 
considered "too high", the request will be denied, and the user will be 
redirected to a "forbidden" page. Yes, it works a bit like a spam system.

NAXSI Project:
The NAXSI Project is not so known like the ModSecurity open source project, but has a very interesting approach and features.
NAXSI uses the small and performant reverse proxy engine of Nginx web server instead of the full blown Apache engine used by ModSecurity (and from a security point of view: the lesser code).
Following are the major feature of NAXSI:

Protects from XSS, SQL injections, CSRF, file inclusion
Fast engine
Relative simple configuration
Check GET/POST requests
Check HTTP headers and cookies
Forbid dangerous symbols and SQL keywords
Allows whitelist approach configuration creating a web application baseline
Able to run in learn or production mode
Uses no signature of known attack

Installation

Let’s do a quick installation with ubuntu sever 12.04 LTS. You may also install it from the sources following the Nginx prerequisites for reference. After you’ve installed the basic server with openssh, install NAXSI with:

 sudo apt-get install nginx-naxsi

Initial configuration

In the nginx configuration file (/etc/nginx/nginx.conf) uncomment this line to activate the basic rulesets:

##
# nginx-naxsi config
##
# Uncomment it if you installed nginx-naxsi
##
include /etc/nginx/naxsi_core.rules;

Note that this file is not an attack signature repository but rather a “score rules” set. Let’s configure NAXSI for our website www.scip.ch. To do so edit the Nginx configuration file in /etc/nginx/sites-enabled/default and add following entries in the server context:

server {
        proxy_set_header Proxy-Connection “”;    
        listen   80;

        location / {
                # put your website IP here
                proxy_pass http://80.74.141.2/;

                # put your website FQDN here
                proxy_set_header Host www.scip.ch;

                # Uncomment to enable naxsi on this location
                include /etc/nginx/naxsi.rules;
                }

        # Only for nginx-naxsi : process denied requests
        location /RequestDenied {
                # For example, return an HTTP error code
                return 418;
                }
        }

Now you should be able to start the nginx service that will bring up the NASXI with following command:

sudo service nginx start

Be sure to check for error messages on the console or in the error log found in /var/log/nginx/error.log and verify with sudo netstat -antup that nginx daemon is opening the configured port (tcp/80 in our case). The output should look like this:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address    Foreign Address   State       PID/Program name
tcp        0      0 0.0.0.0:80       0.0.0.0:*         LISTEN      9865/nginx
tcp        0      0 0.0.0.0:22       0.0.0.0:*         LISTEN      8484/sshd
tcp        0      0 127.0.0.1:6010   0.0.0.0:*         LISTEN      9627/0
tcp        0      0 127.0.0.1:6011   0.0.0.0:*         LISTEN      9062/1
tcp        0     32 x.y.z.52:22      x.y.z.36:49749    ESTABLISHED 9046/sshd: anco
udp        0      0 0.0.0.0:68       0.0.0.0:*                     649/dhclient3

To test if it works, start a browser session and point it to the ip address of your test server (x.y.z.52:80) and you should see the website you configured (www.scip.ch) in the config file above. To continue further testing make sure you will proxying all web request to the nginx-NAXSI WAF. To accomplish this you can ether use the web-proxy configuration setting in the browser or fake the testing website ip address in your system hostfile. I prefer to put the ip address in my hostfile:

x.y.z.52     www.scip.ch

Here are the location of the target hosts file (you need admin right to save changes):

OS	Host Configuration File
Windows	`%SYSTEMROOT%\system32\drivers\etc\hosts`
Linux	`/etc/hosts`

Now we can browse to www.scip.ch and be sure that our test NAXSI WAF will inspect the content and remember that by now the configuration is in learning mode; it will only report errors in the nginx error logs (/var/log/nginx/error.log) and not block any bad scored request.

How It Works

The naxsi_core.rules are responsible for scoring the HTTP input and looks like this (excerpt):

MainRule "str:;" "msg:; in stuff" "mz:BODY|URL|ARGS" "s:$SQL:4" id:1008;
#
MainRule "str:<" "msg:html open tag" "mz:ARGS|URL|BODY|$HEADERS_VAR:Cookie"

"s:$XSS:8" id:1302;
#
MainRule "str:&#" "msg: utf7/8 encoding" "mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie"

"s:$EVADE:4" id:1400;
#
MainRule "rx:.ph*|.asp*" "msg:asp/php file upload!" "mz:FILE_EXT"

"s:$UPLOAD:8" id:1500;

Insight this file is the logic configuration used to score the input; the result will be used in /etc/nginx/naxsi.rules to decide if such input may be allowed or not. The format is quite simple:

Define what to look for: string (str:) or regular expression (rx:)
Define message to report into logfiles (msg:)
Put the rule a category (s:)
Assign rule identifier (id:)
Define where to look for (mz:) and short description below

`mz` entry	Look in
URL	URL path
ARGS	HTTP argument
BODY	HTML body entry
$HEADERS_VAR:	HTTP header variable

Now let’s take a look on the second NAXSI config file /etc/nginx/naxsi.rules where the main NAXSI behavior is defined; this is how it looks like:

# config mode section
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl "/RequestDenied";
#
# check rules section
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;

Here is an explanation of the contents:

LearningMode – activates learning mode; in this mode requests aren’t blocked and white lists may be created.
SecRulesEnabled or SecRulesDisabled – to activate or disable NAXSI for this location/section.
DeniedURL – redirect URL for blocked requests; can be an HTTP error code (like 4xx or 5xx) or forward to an HTML site with code to help track false-positives.
CheckRule – per-category check scores; the score we saw above will be evaluated here. If a request hits a score in the naxsi.core.rules, this score will be recorded and added to each category (SQL, XSS, EVADE, ...) if the overall score for any of the categories is reached (8 in SQL per default) the input is treated as bad.

When you use the whitelist (positive secure model) approach you’ll find also the white-list entries (BasicRule statement) in this config file:

# Whitelist '|', as it's used on the /report/ page, in argument 'd'
BasicRule wl:1005 "mz:$URL:/report/|$ARGS_VAR:d";
# Whitelist ',' on URL zone as it's massively used for URL rewritting !
BasicRule wl:1008 "mz:URL";

The entry above will result in disabling some part of the check rule in naxsi_core.rules allowing a specific behavior and eliminate false-positives. BasicRule could be more or less specific at your pace (and security needs).

Information Gathering

At this stage we have our test installation inspecting the HTTP flow and reporting bad things in the /var/log/nginx/error.log file, let’s take a look on how NAXSI error entry looks like:

> error.log <
2012/11/30 04:57:55 [error] 9866#0: *47 NAXSI_FMT: ip=x.y.z.36&

server=x.y.z.52&uri=/testmiztot&total_processed=8589934625&

total_blocked=679029381853280060&zone0=URL&id0=1999&

var_name0=, client:x.y.z.36, server: localhost,

request: "GET /testmiztot HTTP/1.1", host: "x.y.z.52"

As you can see it’s a special error message: it was generated on a “special” HTTP URL GET request and is not a really bad request. To test the functionality on the WAF I’ve created this test-rule in the

/etc/nginx/naxsi_core.rules:

MainRule "str:testmiztot" "msg:foobar test pattern" "mz:URL" "s:$SQL:42" id:1999;

This rule will trigger whenever the testmiztot string is detected in the address part (mz:URL) of the HTTP GET request and score as 42 (s:$SQL:42) in the SQL category. This will be evaluated as bad because the SQL category limit is 8. The msg: text will be shown in the learning mode log used to generate the white-list baseline.

Analyze in detail the meaning of these commands:

LearningMode - Training Mode is enabled. Requests are not blocked, White-shaped leaf.
SecRulesEnabled - NAXSI enabled for this location. If you want to switch off for another location (for example, a protected inner zone), then do it SecRulesDisabled.
DeniedURL - URL redirect for the denied requests.
CheckRule - checking the "penalty points" query by category.
/ Etc / nginx / mynaxsi.rules - generated rules (not yet gener - commented out).

Official Change Log For Naxsi 0.41:-

Feature: added support for FILE_EXT. We can now control file uploads names/extensions as well.
Added a rule for FILE_EXT into naxsi_core.rules
Added unit testing for FILE_EXT feature
Fixed erroneous log messages
Fixed an error on whitelist of types $URL:xxx|URL

To Know More : https://code.google.com/p/naxsi/

To Download : https://code.google.com/p/naxsi/downloads/list

OWASP Naxsi Project : https://www.owasp.org/index.php/OWASP_NAXSI_Project

NAXSI Matrix : https://docs.google.com/spreadsheet/ccc?key=0AjuNPnOoex7SdG5fUkhfc3BCSjJQbVVrQTg4UGU2YVE#gid=0

NAXSI Presentation : http://www.slideshare.net/phdays/naxsi-an-open-source-waf-for-nginx

Monday, September 30, 2013

VoIP Vulnerability Scanner / Penetration Testing Tool