This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Showing posts with label Fuzzing. Show all posts
Showing posts with label Fuzzing. Show all posts

Viproy - VoIP Penetration Testing and Exploitation Kit


Viproy Voip Pen-Test Kit provides penetration testing modules for VoIP networks. It supports signalling analysis for SIP and Skinny protocols, IP phone services and network infrastructure. Viproy 2.0 is released at Blackhat Arsenal USA 2014 with TCP/TLS support for SIP, vendor extentions support, Cisco CDP spoofer/sniffer, Cisco Skinny protocol analysers, VOSS exploits and network analysis modules. Furthermore, Viproy provides SIP and Skinny development libraries for custom fuzzing and analyse modules.

Current Version and Updates
Current version: 4.1 (Requires ruby 2.1.X and Metasploit Framework Github Repo)
Pre-installed repo: https://github.com/fozavci/metasploit-framework-with-viproy

Homepage of Project
http://viproy.com

Talks

Black Hat USA 2016 - VoIP Wars: The Phreakers Awaken
https://www.slideshare.net/fozavci/voip-wars-the-phreakers-awaken
https://www.youtube.com/watch?v=rl_kp5UZKlw

DEF CON 24 - VoIP Wars: The Live Workshop
To be added later

Black Hat Europe 2015 - VoIP Wars: Destroying Jar Jar Lync
http://www.slideshare.net/fozavci/voip-wars-destroying-jar-jar-lync-unfiltered-version
https://youtu.be/TMdiXYzY8qY

DEF CON 23 - The Art of VoIP Hacking Workshop Slide Deck
http://www.slideshare.net/fozavci/the-art-of-voip-hacking-defcon-23-workshop
https://youtu.be/hwDD7K9oXeI

Black Hat USA 2014 / DEF CON 22 - VoIP Wars: Attack of the Cisco Phones
https://www.youtube.com/watch?v=hqL25srtoEY

DEF CON 21 - VoIP Wars: Return of the SIP
https://www.youtube.com/watch?v=d6cGlTB6qKw

Attacking SIP/VoIP Servers Using Viproy
https://www.youtube.com/watch?v=AbXh_L0-Y5A

Current Testing Modules
  • SIP Register
  • SIP Invite
  • SIP Message
  • SIP Negotiate
  • SIP Options
  • SIP Subscribe
  • SIP Enumerate
  • SIP Brute Force
  • SIP Trust Hacking
  • SIP UDP Amplification DoS
  • SIP Proxy Bounce
  • Skinny Register
  • Skinny Call
  • Skinny Call Forward
  • CUCDM Call Forwarder
  • CUCDM Speed Dial Manipulator
  • MITM Proxy TCP
  • MITM Proxy UDP
  • Cisco CDP Spoofer
  • Boghe VoIP Client INVITE PoC Exploit (New)
  • Boghe VoIP Client MSRP PoC Exploit (New)
  • SIP Message with INVITE Support (New)
  • Sample SIP SDP Fuzzer (New)
  • MSRP Message Tester with SIP INVITE Support (New)
  • Sample MSRP Message Fuzzer with SIP INVITE Support (New)
  • Sample MSRP Message Header Fuzzer with SIP INVITE Support (New)

Documentation

Installation
Copy "lib" and "modules" folders' content to Metasploit root directory.
Mixins.rb File (lib/msf/core/auxiliary/mixins.rb) should contains the following lines
require 'msf/core/auxiliary/sip'
require 'msf/core/auxiliary/skinny'
require 'msf/core/auxiliary/msrp'

Usage of SIP Modules
https://github.com/fozavci/viproy-voipkit/blob/master/SIPUSAGE.md

Usage of Skinny Modules
https://github.com/fozavci/viproy-voipkit/blob/master/SKINNYUSAGE.md

Usage of Auxiliary Viproy Modules
https://github.com/fozavci/viproy-voipkit/blob/master/OTHERSUSAGE.md


ansvif - An Advanced Fuzzing Framework Designed To Find Vulnerabilities In C/C++ Code.


ansvif, written primarily in C++, is designed to find code bugs by throwing garbage input at programs to see how they react. This is great for finding bugs, because not every type of input is always handled, and buffers are not always checked, etc. It also comes in handy when writing (and protecting against), buffer overflow exploitation, as well as string input validation vulnerabilities (the %s bug).

Dependancies:
automake autoconf-archive zlib1g-dev libcrypto++ g++ gcc

Compliation:
Linux:
$ aclocal && autoconf && automake -a && ./configure && make

Or, if you would like to play with the syscall fuzzer:

$ aclocal && autoconf && automake -a && ./configure --enable-syscalls && make

OpenBSD:
$ AUTOMAKE_VERSION=`ls /usr/local/bin/automake-* | head -n 1 | sed -e 's/.*-//'`\
AUTOCONF_VERSION=`ls /usr/local/bin/autoconf-* | head -n 1 | sed -e 's/.*-//'`\
aclocal && AUTOMAKE_VERSION=`ls /usr/local/bin/automake-* | head -n 1 | sed -e 's/.*-//'`\
AUTOCONF_VERSION=`ls /usr/local/bin/autoconf-* | head -n 1 | sed -e 's/.*-//'`\
autoconf && AUTOMAKE_VERSION=`ls /usr/local/bin/automake-* | head -n 1 | sed -e 's/.*-//'`\
AUTOCONF_VERSION=`ls /usr/local/bin/autoconf-* | head -n 1 | sed -e 's/.*-//'` automake -a\
&& CXX=eg++ ./configure && make
Windows:
Windows binaries are now desgined to be compiled with MinGW-W64 (since we use threading download a version of MinGW-W64 g++ with seh).
(Go to where you installed MinGW-W64 and click mingw-64.bat)
g++.exe src/common.cpp src/win/bin2hex.cpp src/win/bin2hex_pc.cpp src/win/popen2.cpp src/win/main.cpp src/win/help.cpp src/match_seg.cpp src/win/sys_string.cpp src/win/sys_string_pc.cpp src/win/man_read.cpp src/randomizer.cpp src/trash.cpp -I./ -I./include -std=c++11 -lstdc++ -lpthread -O2 -o ansvif.exe -static -static-libgcc -static-libstdc++
gcc src/win/printf.c -o printf.exe
Note: cygwin .dll external files are no longer required as we now compile with g++ from MinGW. In Windows 7 Powershell v2 is installed by default, however, this program requires atleast Powershell v5. Windows 10 includes powershell v5. You can go to Microsoft's site and download the Windows Management Framework (which includes newer Versions of Powershell here:
https://www.microsoft.com/en-us/download/details.aspx?id=50395

Testing:
If you would like to try out the example code, you can compile faulty.c with:
$ gcc faulty.c -o faulty
Using the example code: You can point the memory back at address \xff\x05\x40\x00\x00\x00\x00\x00 (the subroutine containing the code that spawns bash) with: $ ./faulty -a $(perl -e 'print "A"x24;print "\x00\xff\x05\x40\x00\x00\x00\x00\x00"') The address may be a little different under your distro, check gdb if you really want to try it out. The code above /should/ drop you at a bash prompt. If the code is set to a mode where all are able to execute as another user, it will attempt to spawn a root shell. or simply run make test .

Usage:
Important note: Windows users will have to run ansvif.exe from Powershell for it to work!
$ ./find_suid /usr/bin/ /bin/ /sbin/
$ ./ansvif -[tm] [template/manpage] -c /path/to/executable -b buffersize

Examples:
Linux/BSD:
$ echo "Marshall" ./ansvif -t examples/template -c ./faulty -b 64
$ ./ansvif -m mount -c /bin/mount -e examples/mount_e.txt -x examples/mount_o.txt\
-f 8 -b 2048
$ ./ansvif -t examples/blank.txt -F tmp/tmphtml -x examples/htmltags.txt -c /usr/bin/iceweasel -b\
128 -A "file:///home/username/src/ansvif/tmp/tmphtml" -f 2 -n -R "sleep 3 && killall\
iceweasel" -S ">"
$ cat examples/linux_syscalls_implemented.list | xargs -P \
`cat examples/linux_syscalls_implemented.list | wc -l` -I {calls} ./ansvif -t examples/space.txt \
-B "{calls} " -c ./syscalls -o syscall_crash -f 1 -z -d -b 16
Windows:
PS C:\ansvif\bin\ansvif_win> .\ansvif -t ..\..\examples\space -F ..\..\tmp\tmphtml -x `
..\..\examples\htmltags -c `
'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe' `
-b 128 -A "file:///C:\\Users\marsh\OneDrive\Documents\Code\ansvif\tmp\tmphtml" `
-f 2 -n -S ">" -R "sleep 2 ; Stop-Process -Name chrome"

Options:
  -t This file should hold line by line command arguments as shown in the example file.
-e This file should hold line by line environment variables as shown in the example
file. You can usually get these by doing something like:
$ strings /bin/mount | perl -ne 'print if /[A-Z]=$/' > mount_envs
-c Specifies the command path.
-p Specifies the manpage location (as an integer, usually 1 or 8)
-m Specifies the commands manpage.
-D Dumps whats found in the manpage.
-f Number of threads to use. Default is 2.
-b Specifies the buffer size to fuzz with. 256-2048 Is usually sufficient.
-r Uses only random garbage data.
-o Writes output to log file.
-z Randomize the buffer size from 1 to what is specified by -b.
-x Other junk to put in. Usernames and such can go here.
-S Seperator between options.
-s Omitted character specification. Defaults are <>\\n |&\[]\()\{}:;\ and newline is mandatory.
-T Timeout for threads.
-W Timeout for threads.
-L Unpriviledged user to run as if root.
-A Always put whats after this after command to run.
-B Always put whats after this before the command to run.
-F File to feed into the program that -x along with normal fuzzing data will be put in.
-n Never use random data in the fuzz.
-R Run this command after each fuzz.
-C A Non standard error code to detect.
-V Use Valgrind if installed.
-1 Try to make it fault once, if it doesn't happen, throw error code 64. Useful for scripting.
-P Use % to represent binary in fuzz.
-M Max arguments to use in the fuzz.
-y Short for -b 0 and usually only useful with -A or -B
-K Keep fuzzing after a crash in the target.
-v Verbose.
-d Debug data.
-h Shows the help page.

Recommendations: It is recommended that if you are doing long fuzzes or file fuzzing, if possible put the files (including the binary you are fuzzing if possible) in memory. This means, put them somewhere like /var/run/shm where disk thrash will be minimal, and fuzzing will be somewhat faster, especially if large files are being handled. Be warned however: You will lose your fuzzed files if they are in shm and you reboot the machine!

DO NOT RUN THIS CODE IN A PRODUCTION ENVIRONMENT! If you try setting faulty.c's output to suid(0) then PLEASE do it in a virtual machine. or atleast a machine that you don't care about. Other than that, just play around and have fun!

Notes:
Windows users must have ansvif running from Powershell. Linux and Windows code should be relatively stable. Syscall fuzzing under linux is under heavy development.

Grinder - System to Automate the Fuzzing of Web Browsers


Grinder is a system to automate the fuzzing of web browsers and the management of a large number of crashes. Grinder Nodes provide an automated way to fuzz a browser, and generate useful crash information (such as call stacks with symbol information as well as logging information which can be used to generate reproducible test cases at a later stage). A Grinder Server provides a central location to collate crashes and, through a web interface, allows multiple users to login and manage all the crashes being generated by all of the Grinder Nodes.

System Requirements

A Grinder Node requires a 32/64 bit Windows system and Ruby 2.0 (Ruby 1.9 is also supported but you wont be able to fuzz 64bit targets).
A Grinder Server requires a web server with MySQL and PHP.

Features

Grinder Server features:
  • Multi user web application. User can login and manage all crashes reported by the Grinder Nodes. Administrators can create more users and view the login history.
  • Users can view the status of the Grinder system. The activity of all nodes in the system is shown including status information such as average testcases being run per minute, the total crashes a node has generated and the last time a node generated a crash.
  • Users can view all of the crashes in the system and sort them by node, target, fuzzer, type, hash, time or count.
  • Users can view crash statistics for the fuzzers, including total and unique crashes per fuzzer and the targets each fuzzer is generating crashes on.
  • Users can hide all duplicate crashes so as to only show unique crashes in the system in order to easily manage new crashes as they occur.
  • Users can assign crashes to one another as well as mark a particular crash as interesting, exploitable, uninteresting or unknown.
  • Users can store written notes for a particular crash (viewable to all other users) to help manage them.
  • Users can download individual crash log files to help debug and recreate testcases.
  • Users can create custom filters to exclude uninteresting crashes from the list of crashes.
  • Users can create custom e-mail alerts to alert them when a new crash comes into the system that matches a specific criteria.
  • Users can change their password and e-mail address on the system as well as view their own login history.
Grinder Node features:
  • A node can be brought up and begin fuzzing any supported browser via a single command.
  • A node injects a logging DLL into the target browser process to help the fuzzers perform logging in order to recreate testcases at a later stage.
  • A node records useful crash information such as call stack, stack dump, code dump and register info and also includes any available symbol information.
  • A node can automatically encrypt all crash information with an RSA public key.
  • A node can automatically report new crashes to a remote Grinder Server.
  • A node can run largely unattended for a long period of time.

Grinder Screenshots