One Packet For Each IPv4

We need a program to send out a packet for every possible IPv4 address to a specific destination address. Sounds simple enough, right. Crafted up a quick bash script, uses four for loops that increment each octet of the ip address. Then the address is passed to netwox, where it sends out a tcp packet for each address.
3 Days later – This is still running, what’s the deal? Few calculations:
Total IPv4 addresses 2^32 = 4,294,967,296
Transmission rate ~ 500 packets per second (seems fast)
Total Time for completion ~ 99 days
Wow, we don’t have that much time!

Should of started off in C, why am I so lazy all the time. So here it is a C program to send one packet for each IPv4 address. The program actually uses UDP packets, we did not want to clog the network with SYN/ACK packets. The point of the test was to test the logging capabilities of a hardware device. The device classifies received packets into separate categories based on IP address. We are using the libnet libraries, I am including a link to good article that tells how to use libnet, also it was compiled on Fedora Core 6, with newest libnet installed. I hard coded the mac addresses so that an ARP would not have to be performed (speeds up performance). This program was able to exhaust the IPv4 space in less than 3 days. Again the formatting of code is a little off after pasting into the blog, so review the code before using. What about IPv6 - good luck being able to do this in less than a year :)

#include "libnet.h" /* replace " with <> */

int main(void)
{
libnet_t *l;
libnet_ptag_t t1, t2, i1, i2, e1, e2;
char errbuff[LIBNET_ERRBUF_SIZE];
u_char src_eth[6] = {0x00, 0x0B, 0xDB, 0x1E, 0x55, 0x74}; // source mac change these
u_char dst_eth[6] = {0x00, 0x0B, 0xDB, 0x1E, 0x58, 0x0C}; //dest mac
u_long src_ip = 0, dst_ip = 0x02046E0A; //dst_ip network byte order format
u_short src_port = 23456, dst_port = 80, payload_s = 0;
char *payload = NULL;
int c;

l = libnet_init(
LIBNET_LINK,
NULL,
errbuff);

t1 = libnet_build_udp(
src_port,
dst_port,
LIBNET_UDP_H + payload_s, /*size*/
0, /*checksum */
payload,
payload_s,
l, /*libnet handle*/
0);

i1 = libnet_build_ipv4(
LIBNET_IPV4_H + LIBNET_UDP_H + payload_s,
0,
242,
0,
48,
IPPROTO_UDP,
0,
htonl(src_ip),
dst_ip,
NULL,
0,
l,
0);

e1=libnet_build_ethernet(
dst_eth,
src_eth,
ETHERTYPE_IP,
NULL,
0,
l,
0);
c = libnet_write(l);


while (src_ip < 0xffffffff)
{
src_ip++;
i2=i1;
i1 = libnet_build_ipv4(
LIBNET_IPV4_H + LIBNET_UDP_H + payload_s,
0,
242,
0,
48,
IPPROTO_UDP,
0,
htonl(src_ip),
dst_ip,
NULL,
0,
l,
i2);

c = libnet_write(l);

}
libnet_destroy(l);
printf ( "all done\n");
return(0);
}

Nmap - not for every occasion

Nmap, if you are a practitioner in the computer security field, then you know about nmap. Basically nmap is free quick and easy to use port scanner. I have no qualms about the program, but what people must learn is that there is a time to use nmap and a time not to.

Just to give some background, computers have software ports, these ports are used to map data to a particular process on a computer. For example, when you browse the web your computer uses port 80 to query web servers in order to receive the web pages. For every process that you have running on your computer that transmits and receives data across the network, there is a specific port associated with it. So in theory using a port scanner allows us to determine the processes that are running. This in turns allows us to determine if any vulnerable services are running. Now port scanning is performed on TCP and UDP ports, because these are the two protocols designated by IP

Now for TCP protocol port scanners work really well, because as part of the protocol there exists the three-way handshake. Your computer sends a packet to say hi (SYN) and the other computer answers back ( hi (SYN-ACK), and then your says lets transfer some data (SYN-ACK-ACK). So for TCP port scanning unless a firewall is filtering or blocking the target computer, it will answer back on all open TCP ports to SYN packets.

Now for UDP there is no handshake process, basically a UDP service just accepts all data it receives and processes it with no response back to your computer. So unless the UDP service is set to answer back or the operating system sends a message saying that port is closed, you will never know the status of a UDP port.

Back to my compliant, I deal with computer security people on a daily basis. I am not knocking them, but at least 50% think that nmap is the be all end all in the security world. We receive software to test, we load it up and the first thing they want to do let’s run nmap. My response is why? – for some reason by running nmap makes you some super uber hacker – hey look guys I can run nmap yeah!

Our setup:
- we are in a network lab and not on an operational network, so we have control of all resources on the network
- we are dealing with <3 machines, with admin access to each machine

Remember a port scan is only useful if a port answers back, and we can track that port back to a single process (For uber hackers, at least ensure the software is running when you perform a port scan)

Countless times, I receive responses that this software does not use any network resources, because we ran nmap and there were no ports showed up.
My first two questions:
- Did you have the software running during the port scan? (usually No)
- Is the firewall blocking your scan? (usually I don’t know)
Then the response…But I can run nmap so I am an uber haxor!

So what do I suggest, why not netstat, yes the built-in windows utility (same for linux). If you are in a testing environment, and you only have a few computers to determine open ports – why even consider nmap. Netstat –nb will give you all the open ports and the process that opened it. I know running netstat is not as cool as running nmap, but with netstat you don’t have to rely on the computer to answer you back. So there is no guess work with determining if a port is open.

But ecore what about software that only opens a port every so often to communicate, guess what you can script netstat to run every so often. netstat –nb 5 > log.txt , will write all port information into the log file every 5 seconds (If you are doing this consider using a protocol analyzer.. WireShark).

Point is if you are trying to determine ports on a computer you have admin access to, nmap is not the way to go. Reserve nmap for those remote scans or when you have to test hundreds of computers. Part of being an 31337 uber haxor is knowing when and when not to use your tools.

ICMPv6 Scanning

I have touched on this topic in a previous post, however I would like to revisit the topic. Why would we want to perform ICMP scanning, I say why not. Everybody is always talking about performing port scans but never ICMP scans, I say ICMP should get equal time with TCP and UDP.

I know you probably have not heard of many flaws concerning ICMP but it happens. Example, I was testing an IPv6 stack trying to determine if their were any flaws. Found that by sending the target computer a ICMP Reply caused the target computer to send out an ICMP Request. How does this help an attacker - the target computer was running a firewall and it was set to block ICMP requests coming in, however since the target computer was sending out a ICMP request, the firewall did not block this (You might think the firewall should block random ICMP replies coming in, but it didn't). So this gives an attacker a way to scan the local lan and determine valid addresses of computers.

A little background, ICMP packets are defined by a type and code field. Each field is an 8 bit field meaning there are 256 possible combinations (0-255), so you have 256 codes for each of the 256 types. If you take a look at the RFC's, you will see not all the type and code combinations are valid, or are considered reserved or undefined (More Information). As part of a thorough security test, we should send the computer we are testing every possible combination and see what happens. This does not take up much time, and has very interesting results sometimes.

For this example I am going to concentrate on ICMPv6 scanning. Basic setup is a laptop running Fedora Core 6 (FC6) connected to the target computer through a generic hub. The FC6 computer has wireshark and the THC IPv6 libraries installed. Both computers have IPv6 enabled (you can give the FC6 an ipv6 address by using the ifconfig command). I have talked about performing this scan with NETWOX, however NETWOX will not send out undefined types and codes, so this is why we are using the libraries. Basically we start up wire shark to capture all the packets on the network and then use the THC IPv6 libraries to send out one ICMPv6 packet for each type and code. When performing the scan I usually set a display filter in wireshark to only display responses from the target computer. Note on IPv6, the protocol IPv6 gives the host two addresses a global address and an link-local address (info). The link-local address starts with fe80 and the global is basically everything else. I suggest performing the scan with both link-local and global addresses, you usually find differences.

I am posting the c-code I used to accomplish this scanning, again the formatting of the code gets thrown off when I paste it into the blog - so I apologize. Basically the code sets up two loops in order to scan all types and codes - it should be pretty self explanatory.

My main point is security professionals should be concerned with ICMP scanning instead of leaving it by the wayside. Happy Scanning!

(I scrapped the code together from memory and other sources, because I did not have access to my program when writing this post, however it should be enough to get you started)

#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include "unistd.h"
#include "sys/types.h"
#include "sys/time.h"
#include "sys/resource.h"
#include "sys/wait.h"
#include "stdlib.h"
#include "time.h"
#include "pcap.h"
#include "thc-ipv6.h"
//all the includes are not needed, but I got lazy
//also I replaced the <> with " because blogger kept deleting the includes

int main(int argc, char *argv[]){

unsigned char *src6, *dst6, *dst61, *src61;
unsigned char *src61, *src612, *h;
unsigned char buf[1000];
int pkt_len = 600;
char *interface;
unsigned char *pkt = NULL;
int rawmode = 0, buf_len = 0;
unsigned char *srcmac, *dstmac; //can define as null to auto generate
int type, code, flags=0, checksum=0, i, j=0;
thc_ipv6_hdr *hdr;


//Initializing Variables
rawmode = 1;
interface = "eth0";
// source and destination ipv6 addresses
src6 = "fe80000000000000020bdbfffe1e580c\0";
dst6 ="fe800000000000001c26fea710f768fd\0";

src61 = thc_string2ipv6(src6);
dst61 = thc_string2ipv6(dst6);
printf("Sending Packets to %s\n", dst6);

srcmac = thc_get_own_mac(interface);
dstmac= thc_get_mac (interface, src61, dst61);

for (type=0; type<256;type++)
{
for (code=0; code<256;code++)
{

//build the packet

if ((pkt = thc_create_ipv6(interface, PREFER_GLOBAL, &pkt_len, src61, dst61, 60, 0, 0, 0, 0)) == NULL)
printf ("Packet Creation Failed\n");

//add icmp part
if (thc_add_icmp6(pkt, &pkt_len, type, code, flags, NULL, 0, checksum)<0)
return -1;

//generate packet

if (thc_generate_pkt(interface, srcmac, dstmac, pkt, &pkt_len) <0)
{
printf("generate failed\n");
return -1;
}

// send the packet out

if (thc_send_pkt(interface, pkt, &pkt_len) <0)
printf ("packet not sent \n");

thc_destroy_packet(pkt); //destroy the packet
usleep(1000);

}
}
return 0;
}

Scripting Netwox (IPv6 Port Scanning)

As you may found out there are not currently that many tools for testing IPv6, what does one do when you need to perform a IPv6 port scan? I accomplished this through the use of a tool called Network Toolbox (http://www.laurentconstantin.com/en/netw/netwox/) or simply called NETWOX. This tool supports a variety of protocols including IPv6. On a side note use of the TCP reset tool included in NETWOX is always fun, this will sniff the network and send a TCP RST packet for each TCP connection it detects, effectively closing all TCP connections – Great fun watching the network gurus trying to diagnose that problem.

Back to IPv6 port scanning, so you are required to perform a port scan in IPv6. I know nmap has some IPv6 capabilities but I have not had much luck with it. So basically NETWOX lets you send out a specific packet one at a time. By automating the process we can effectively create a port scanner. Basic methodology is I send out a IPv6 TCP packet with SYN flag set and use a protocol sniffer (wireshark) to capture the response. All I need to do is send out one packet for each port I want to scan and then examine the sniffer file.

I am running a version of linux called BackTrack (http://www.remote-exploit.org/backtrack.html) and using a bash script to automate NETWOX. BackTrack has wireshark builtin, so run it during the script execution and filter by responses from the target (ex. ip.src == ipaddress). I have found this method to be reliable way to port scan IPv6 computers. Here is the bash script for performing this:

#!/usr/bin/bash

source=aaaa::20b:dbff:fe1e:5574;
dest=aaaa::1c26:fea7:10f7:68fd
for ((port=0 ; port<=65535 ; port+=1)); do
netwox 146 --ip6-src $source --ip6-dst $dest --tcp-dst $port --tcp-syn --tcp-window 32000
done

To use, save the file as something then make it executable (chmod 777 filename), replace the source and dest addresses with your correct addresses then ./filename to run. (make sure the line that starts with netwox through –tcp-window 32000 are on the same line – formatting problems in blogspot again) and of course make sure you netwox installed.

Reviewing the capture, any TCP packet for a particular port from the target computer means that port is open, cool huh? (again if you don’t understand, let me know so I can explain better)
Now sometimes you recieve an icmp response, what does that mean depends on the response but probably that the port is closed, so whats next - ICMPv6 port scanner:

#!/usr/bin/bash
source=fe80::20b:dbff:fe1e:5574;
dest=fe80::1c26:fea7:10f7:68fd;
for ((type=129 ; type<=130 ; type+=1)); do
for ((code=0 ; code<=255 ; code+=1)); do
netwox 147 --ip6-src $source --ip6-dst $dest --icmp-type $type --icmp-code $code
done
done

It sends out all possible type and code icmpv6 combinations. However netwox will not send out illegal type and code combinations. For true icmpv6 scanning (illegal combinations) I like to use the thc libraries written about in the IPv6 Firewall testing post (Nov)

This is one for UDP scanning, so any response from the target on specific port means that port is open:

#!/usr/bin/bash

source=8888::20b:dbff:fe1e:5574;
dest=aaaa::1c26:fea7:10f7:68fd;
for ((port=0 ; port<=65535 ; port+=1)); do
netwox 145 --ip6-src $source --ip6-dst $dest --udp-dst $port --udp-src $port
done

So you get the idea, a neat little way to perform port scanning in IPv6. Netwox is neat little collection of tools that is easy to use and very useful (especially the make coffee tool) I have also used it to perform IPv4 ICMP scans, its amazing sometimes what happens when you send some weird ICMP Packets to a computers, sometimes it answers back even if it programmed to not answer ICMP packets!

EtherSnoop Debacle (Parsing an EtherSnoop file)

I just love a good problem in the morning, So I receive a capture file to analyze from a fellow professional. Him not being super familiar with protocol analyzers, asked me to look at it. He could not find any program (WireShark, tcpdump, netmon..) to open this file. It had an .cap file extension and he was told that it was a network capture of UDP packets. Basically the capture file consisted of UDP packets from some type of GPS IP enabled device. Each packet had waypoints and time stamps, and these needed to be extracted. I open the file in notepad, and sure enough, I can pick out longitude and latitude coordinates scrambled in the data. So my task , if I choose to accept, is to get the time stamps and gps data out of each packet, sure why not. Off I go, now of course picking these out by hand was not going to work, there were over 4,000 gps points in this file. And it was not possible to repeat the test with a different known sniffer.

Hey lets try excel and some vba - I know everybody is laughing but excel and vba is some powerful stuff, I have analyzed quite a few capture files this way. I import the file and of course get meaningless crap. I try some manipulations, I notice that "gE#" seems to proceed the data I need (sometimes?), so I write some code to put everything between "gE#" on separate rows and it seems to work kinda of. There is still a lot of useless data in my pseudo packets. Punk go ahead and make my day and lets pull out the big guns.

Here they come, the infamous hex editor specifically my favorite because it is free is Cygnus Hex Editor (http://www.softcircuits.com/cygnus/) . After an hour of staring at the file, it starts to make sense? There seems to always be an "<" or hex 3C after the data. Since I was told the device sends out a standard formatted UDP packet at a set period of time, you would think it would be easy to pick out a pattern. But once I think I got a pattern, the next set of data ruins it. What a mess. ZOWIE!!! (yes like in the batman show) I get an e-mail from the guy that performed the capture, yep you guessed it he used ethersnoop (http://www.arechisoft.com/). Just what I needed , so I download and install ethersnoop and open the file, yep it works and then the realization hits. This capture file is full of extra packets, no filter was used for capturing, so all network traffic for about 4 hours was captured, no wonder the data was not uniform. But I was right packets always start with hex 3C or "<". After realizing the facts, back to excel (why excel - its awesome at manipulating data). Import the file as delimited, but don't specify a delimiter. So you have a spreadsheet with stuff everywhere and the fun starts. First script (I do apologize for the code some reason my formatting keeps getting thrown off): Function clean()

x = 0
For i = 1 To 65535

If Sheet4.Cells(i, 1) = "" Then
x = 1
End If

If Sheet4.Cells(i, 1) = "" Then
Sheet4.Rows(i).Delete
x = 0
End If

If x = 1 Then
Sheet4.Rows(i).Delete
i = i - 1
End If

If Sheet4.Cells(i, 1) = "" Then
Sheet4.Rows(i).Delete
If Sheet4.Cells(i, 1) = "" Then
Exit For
End If
End If
Next i
End Function

This script will get rid of all the non-packet data - data that lies between the Body tags in the file. I have no idea why but you have packets grouped together then a some data . I have no idea what this data is, but it looked useless to me. So after the script is run you have just the packets. Next we want to put each packet on a separate row, to make it easier to parse packets:

Function pullbrackets()

g = ""
v = 1
For i = 1 To 65535

If Sheet4.Cells(i, 1) = "" Then
Exit For
End If

For j = 1 To Len(Sheet4.Cells(i, 1))
y = Mid(Sheet4.Cells(i, 1), j, 1)
b = Mid(Sheet4.Cells(i, 1), j, 1)


If y = "<" Then
Sheet5.Cells(v, 1) = g
v = v + 1
g = ""
End If
g = g & b
Next j
Next i
End Function

The above code looks for "<" and puts all data between successive "<" on one row. Now we have an excel spreadsheet with one packet per row. So that is the basics, of course to use the code you should modify it for your use (change the sheet designations ...) I am thinking if you are reading this you understand vba, but if not leave me a message and I can explain it more. I did write a little more code to get the packets I wanted, but I won't bore you with that (script to sort out UDP packets then pull the data from those packets and get rid of non-ASCII data). But anyway there you go my experiences with EtherSnoop. In my opnion EtherSnoop is lacking since there is no way to export data, but any free program I am not going to bad mouth. But I do prefer WireShark (http://www.wireshark.org/) The next task what can you use to plot out 4,000 GPS points?

Serial Port in WSH (vbs)

Ever Happen to you - Hey we need a program to send AT commands to a modem through the computer's serial port and store the responses to a text file and by the way we perfer a non-compiled language that will run on any windows computer.

So then I thought I know we will use Windows Scripting Host, anybody with a windows computer can run a .vbs file. Did some research, not much documentationon using serial port in a vbs file just some stuff about the MSComm32 - but you have register it ( just seemed annoying). Came across ActiveComport - now this is great. By installing ActiveComport, serial port programing becomes downright simple. So I write out the program and install ActiveComport - bam works perfect. And then discover you have to pay to use ActiveComport, of course there is no money to do that, so back to the drawing board.

Discovered this website http://www.hardandsoftware.net/, which has the NETCommOCX which is an ActiveX control that wraps the functionality of MSComm32.ocx. By the way check out the other cool stuff on the site, there are some neat thins there. NETCommOCX works perfect, and it is a free download with no restrictions. It does need to be installed on the computer you intend on using the program on.

So FYI, here is the program written in vbs, basically it needs two text files command.txt and out.txt already in the directory of the program. Command.txt contains one AT command per line, so the script loads each one into an array, then writes each command to the serial port. The program then waits 300ms for a response and writes the response to the out.txt file and to the screen. The commands are issued in an infite loop until the progam is stopped (Ctrl-c). The time to wait shoud be changed based on the device. There are more advanced ways to control the flow of the program, instead of waiting for specified time it can poll the serial port for data and pause until it recieves data.

program code, should be pretty self-explanatory (hopefully). The program is meant to be run with cscript - c:\cscript program.vbs
---------------------------------------------------
Set objComport = CreateObject( "NETCommOCX.NETComm" )

objComport.CommPort = 1
objComport.Settings = "9600,N,8,1"
objComport.InputLen = 0
objComport.PortOpen = True

wscript.echo "Port is open and ready"

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile("command.txt", 1)

i = 1

Do Until objTextFile.AtEndOfStream
Redim Preserve arrdata(i)
arrData(i) = objtextfile.ReadLine
i = i + 1
Loop

objTextFile.Close

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile("out.txt", 2)

do while (1) ' wscript.stdin.atendofline
for j = 1 to (i-2)
str1 = arrdata(j)
wscript.echo str1
objComport.output = (arrdata(j)) & VBCR
wscript.sleep(300)
str = objComport.InputData
wscript.echo str
wscript.echo "------------"
objTextFile.Writeline ("command: " & arrdata(j))
objTextFile.Writeline (str)
objTextFile.WriteLine ("-------------------")
next
loop

objTextFile.close
objComport.PortOpen = False ' Close the port

Testing Firewalls IPv6

So we have talked before about testing firewalls in IPv4 but what about IPv6. I was recently given the chance to test an IPv6 firewall. So again a testing methodology would be to throw a bunch IPv6 packets at it and see how well it filters. There is a tool called ip6sic (http://ip6sic.sourceforge.net/) that is a derivative of the isic tool used before. But I guess my skills are lacking, because I had problems using this tool (especially just getting the thing to compile). So going back to my great standby, I enlisted the help of google and found The Hacker’s Choice (http://thc.org/ ) – I have to say this is an awesome website and should be bookmarked as there is always some cool thing posted on the site. THC has some libraries (http://freeworld.thc.org/thc-ipv6/) THC-IPV6 that allows one to quickly develop a program to send out IPv6 packets. Using this library I was able to craft together some quick code to test the firewall. Basically the code created blank IPv6 packets and filled the fields and data with random bits. I then checked firewall logs and the sniffer capture files to determine if any packets snuck through. Guess what, IPv6 icmp packets with type codes not defined were allowed to pass even if it was told to filter out all ICMPv6. Even stranger certain type and code ICMPv6 packets caused the Firewall to send out an ICMP IPv6 reply packet. Just makes my day when I get to go back to developers and show my results, of course I get the standard answer, who would ever send the firewall non defined type and code ICMPv6 packets- who knows.

Testing Firewalls IPv4

How do we go about doing this? That was my question. The general game plan was lets generate some packets on the external side, setup a sniffer on the internal side and see what makes it through. I was lucky and was given a default configuration of the firewall rules that would be implemented.

Now how about that packet generator - ????. Fumbling around in C with some libnet libraries might sound like fun but we were pressed for time. After some google searches, came across IP Stack Integrity Checker (ISIC) – http://www.packetfactory.net/Projects/ISIC/. This tool is awesome – here is the description from the website:

ISIC is a suite of utilities to exercise the stability of an IP Stack and its component stacks (TCP, UDP, ICMP et. al.) It generates piles of pseudo random packets of the target protocol. The packets be given tendencies to conform to. Ie 50% of the packets generated can have IP Options. 25% of the packets can be IP fragments... But the percentages are arbitrary and most of the packet fields have a configurable tendency.

We setup ISIC to send random IP packets with random source addresses at the firewall. While sending packets WireShark was used peform packet captures on the internal network. The capture file was reviwed to determine if the packets that made it through conformed to the firewall rules. We ran the test over a weekend (~3.5 days) and it passed, no leak packets - so we are done right?

Maybe for normal network security people, but we are uber security guys – so whats next? Lets just pick on the ports that we know that are open and bombard them with packets. Lets go back to isic and use specific ports and protocols – usually just started up isic (tcpsic, udpsic) and let it run and see if we notice anything. Wow when hitting one particular udp port; the firewall stops responding completely and when we stop it goes back to normal. Little more tweaking in ISIC playing with IP options (setting the percentages to 100% or 0%) we found out it’s the fragmented packets causing the problem. Back to our C programming using libnet libraries write a quick program, and voila we have a working program that can cause a DoS on this type of firewall. Are we done yet? – Are you kidding, firewalls are complex things that have to track a variety of variables, which of all have network attack surfaces – but how much can you get done, when you are given a week to test something.