TAZ: TheTAZZone Network » security hacking tutorials

Cracking WEP with Windows(no clients + easy)

admin — Thu, 16 Jul 2009 00:27:11 +0000

ORIGINALLY POSTED BY LIMESEED FOR THETAZZONE/TAZFORUM HERE

Do not use, republish, in whole or in part, without the consent of the Author. TheTAZZone policy is that Authors retain the rights to the work they submit and/or post…we do not sell, publish, transmit, or have the right to give permission for such…TheTAZZone merely retains the right to use, retain, and publish submitted work within it’s Network

I know i’ve been annoying and spamming a lot of people with questions and shit, so its time for me to make up for it by making a tutorial helping all of the people with problems with injecting with commview. Enjoy!
Sorry i could not put this under the tutorials section, it wouldn’t let me
moved by DaFoxx
Things You Need:
- 2 Wireless Network Adapters (one has to be compatible with commview for wifi and work with packet sending a.k.a. go to this page and make sure you have one adapter that is not listed under “old 802.11b adapters”

http://www.tamos.com/products/commwifi/adapterlist.php

: I use AR5006EX mini pci express adapter (built in with my laptop), and for about 20$ including shipping i bought this

http://cgi.ebay.com/Linksys-Wireless-B- … dZViewItem

)
seller has 100% positive so you can bid wit confidance!! lol
- Commview for Wifi (

http://www.box.net/shared/vzts630u80

)
- Aircrack-ng (

http://www.aircrack-ng.org

)
_____________________________________________

Time to start tutorial

1) Unzip and install Commview, then paste the included “cv.exe” to the directory you installed it to (c:\program files\commviewwifi)

2) Open commview and install the commview drivers to a card. It should prompt you about your card and than automatically install the driver. It is important that you have 1 card that works with commview or else the rest of the tutorial will not work

3)now go to the “rules” tab and check “enable advanced rules”

4)type in the box labled formula “tods=1 and dmac=FF:FF:FF:FF:FF:FF” then type a name for your formula in the box labled name and than click add/edit.

5)it should now appear in the upper box. if it is not checked, check it.

6)now click settings>options>memory usage and turn maximum packets in buffer to 20000 (max). If it prompts you to restart it, do so. There are three funnel looking things on the main menu bar of commview. uncheck all but the first one (one labled “capture data packets”)

7) now click the play button and scan for the network you want to crack.

once you have found it, drag the channel menu down to the desired channel and click capture.

9) now using your other adapter thats not capturing, connect to the password protected network. when it asks you for key, type in something random, i used 1234567890.

10) it should now say connected with limited connectivity. (same as being associated!!)

11)go back to your commview menu and click on the packets tab. you should see a couple of packets.

12) looking at the protocol column, you should see a couple labled IP/UDP, ARP REQ, and a couple of others. Right click on any packet labled “ARP REQ” and than click send packet, and selected. A mini menu should now appear.

13) on the mini menu, change packets per second to 2000, and rather than 1 time(s), click continuously, and Then click send.

14) now go back to the main commview window and go to the rules tab, and uncheck the rule you made.

15) You are now injecting and you should see the number of packets rising really fast. it has been around 1 min and 30 seconds and i have around 29000 data packets already!!

16)to save the packets, you have to save every 20000 packets, click file, save and than in the save dialogue, remember where you saved it, and instead of saving it as an ncf file, save it as a “dump” .cap file.

17) configure aircrack-ng (there are millions of tutorials on how to do this im not going to show you how.)

18)open aircrack-ng-GUI and select the files you saved, and than click launch.

19)Look at the list of IV’s you have, and select the network you want to crack , there should be a list of alot of them, chose the one with the most ivs.

20)viola! It should begin cracking and i usually get around 200000-250000 ivs and it cracks in around 0 seconds with a 64 bit key!! congrats you can now crack WEP without annoying unstable aireplay-ng!!

*for people who are not novices to commview for wifi, instead of saving every 20000, because that gets annoying, you can configure autologging as it will let you make 100MB files with around 100,000 packets, so you only need 2 files, you will have to manually open these and convert them from ncf to cap files!!

questions, just reply, i tend to write these too fast and leave out something so just ask! Let me know any improvements!

Tutorial – Cross posted SQL injection measures

admin — Wed, 08 Jul 2009 00:22:30 +0000

ORIGINALLY POSTED BY NTSA FOR THETAZZONE/TAZFORUM HERE

[quote="Shippwreck"]…I find that SQL Injection is one of those things that everyone agrees poses a major security risk, but if i ask the question what techniques to use to combat it or what are the key/most common things to look out for in your coding that leave you wide open the room goes eerily quiet…[/quote]

Well, here’s what I do…

The ContainsSQL function below accepts a string value and checks for a ‘;’ character (that’s required for SQL stuffing) outside of string deliminators.

Let’s say your script uses a variable as a modifier for an SQL command. The variable is collected from the request string and is called “Variable” – so to get the value in code you’d request(”Variable”).

Your code might look like this:
[code]
sqlq = "select * from '"& request("Variable") &"'"
sql.execute(sqlq)
[/code]

A black hat might fill in the Variable field with “A Variable.’;[sql exploit here]“. The sql injection would mean that the SQL statement you executed would read like this:

[code]select * from 'A Variable.';[sql exploit here][/code]

because the use of the ‘;’ begins a new line in the SQL parser.

To check this you’d call the function from your (asp) code like this:
[code]
<%
if object.ContainsSQL(CSTR(Request("Variable"))) then
response.write "

Thank you.

"
response.write "Your IP address has been logged.
"
response.write "Please step away from the computer,
"
response.write "place your hands behind your head
"
response.write "and await the arrival of a local law
"
response.write "enforcement official."
end if
%>[/code]

[b]The function[/b]
[code]
Private Function ContainsSQL(tValue As String) As Boolean

Dim l, n

ClearError
On Error GoTo 10

ContainsSQL = False

' Ensure the statement does not contain ; outside of string deliminators (')
' (To 'stop SQL stuffing exploits)
l = 1
For n = 1 To StringsCls.CountInString(tValue, ";")
l = InStr(l, tValue, ";")
If (StringsCls.OddEven(StringsCls.CountInString(Left(tValue, l), "'")) = 0) Then
ContainsSQL = True
Exit Function
End If
l = l + 1
Next

10:
If Not Err.Number = 0 Then
'stop
mError.Number = Err.Number
mError.Description = Err.Description
SendTrace "ContainsSQL", "Error #" & Err.Number & ": " & Err.Description
End If

End Function
[/code]

TUTORIAL – Cracking WEP (WinXP, intel pro 3945ABG) easy+pics

admin — Sat, 04 Jul 2009 00:16:01 +0000

ORIGINALLY POSTED BY DIESELPOWER FOR THETAZZONE/TAZFORUM HERE

As this is a very popular card in new laptops and almost all people with this card are having dificulties with it to crack a wep key heres a tutorial.

1. DRIVER
————–
First you will have to downgrade the drivers of your network car, assuming you have the latest driver. The driver version we are downgrading to is 10.5.1.72 or 10.5.1.75. If someone has a server i can send them..

When you have the drivers go to your wireless connections, select your card > configure > driver > update driver > ‘install them from a specific location’ > ‘dont search..’ > have disk’ and then select the driver.

2. OMNIPEEK
—————-
Install Omnipeek Personel (

http://products.wildpackets.com/?v=ybwh9mhz4e440035&s=6

)
This program includes wildpacket drivers for your card enabling it to go into ‘monitor mode’. Note: When the program is running you will not be able to get on the internet, but this is restored when you close it..

Once installed, open the program and click on ‘new capture’

Next hit ‘802.11′ and select where you want to capture from (channel, BSSID=MAC-adress, ESSID= network name, or scan channels) and click OK.

Now hit ‘Capture’ and it should start capturing packets..

When you think you have enough packets click ’stop capture’.
Goto File>Save all packets and save it as a .dmp file. Close Omnipeek.

3. WINAIRCRACK
—————-
Okay so now we should have a .dmp file with the packets.
- Open WinAircrack
- Click ’select capture file’ and load the .dmp file you captured before.

- On the general tab select the encryption type (i only know how it works with wep..)
- On the WEP tab you can choose the key size (not necessairy)
- On the advanced tab you can enable the use of dual processor (not necessairy)
- Click ‘Aircrack the key’
- A command box will show up and ask you for the target network.

Choose the right one and voila it will begin cracking.

Code: Select all: EDIT: To filter a network out: -click start monitor in omni -rightclick on the network u want -click make filter -give the filter a name -do what i explained in the tutotial, but before u click capture first go to 'filters' in the list -put a cross next to the filter u made This will make you capture only the data from a specific network (no more huge lists of networks with only one iv.

The end!

Tutorial – NMAP Scanning and PortSentry Evasion

admin — Thu, 25 Jun 2009 23:54:54 +0000

ORIGINALLY POSTED BY STRIEK FOR THETAZZONE/TAZFORUM HERE

Intrusion Detection
NMAP scanning and PortSentry Evasion

This paper will discuss the methods used to circumvent intrusion detection technology employed by Psionic’s PortSentry software. It will look at normal modes of operation where PortSentry binds itself to monitored ports at a userland level, and stealth modes, where it operates with raw sockets at a kernel level. The discussion of advanced stealth scan detection and the implications, pros and cons of auto-blocking portscanning attackers, as well as more advanced IDS systems, are beyond the scope of this paper. A basic undertanding of the OSI model and the TCP/IP suite of protocols, including UDP, is assumed, as well as the ability to effectively read tcdump output and syslog generated messages. Scans have been conducted using nmap 3.50 against Portsentry version is 1.2. Scanning machine is a P166 64 MB RAM, 1GB HD running Slackware 9.1 (kernel version 2.6.7) without X windows, at IP address 10.0.0.15. The victim machine is a P2.4Ghz 512 MB RAM 80 GB HD running Slackware 10.0 (kernel version 2.6.8.1) with X windows, at 10.0.0.10. Neither the attacker nor victim have the iptables (or any other firewall, stateful or not) service running. This paper may contain facutal errors to a minor degree. I welcome any corrections and/or criticisms you may deem relevant.

Our first scan will be a normal TCP connect() scan against the default range of ports. We will be scanning a machine which is currently unprotected by PortSentry. The TCP connect() scan simply attempts to connect to a number of predetermined ports. If a connection is made, the port is listening. If no connection is made, that port is closed. The connection is then terminated to avoid SYN flooding the machine we are attempting to scan.

Given the command:nmap -sT 10.0.0.10

We see the following output:

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 17:54 EDT
Interesting ports on 10.0.0.10:
(The 1656 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
631/tcp open ipp
6000/tcp open X11
Nmap run completed — 1 IP address (1 host up) scanned in 2.909 seconds

Three ports are open. This is provided only as a refence so we may better understand the operation of PortSentry.
We will now activate PortSentry in its most basic mode, TCP detection only and no stealth capabilities yet. We will also turn off the auto-blocking feature. After activating PortSentry on the victim machine and running the same scan, we arrive at the following output:

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 17:54 EDT
Interesting ports on 10.0.0.10:
(The 1634 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
1/tcp open tcpmux
11/tcp open systat
15/tcp open netstat
22/tcp open ssh
79/tcp open finger
111/tcp open rpcbind
119/tcp open nntp
143/tcp open imap
540/tcp open uucp
631/tcp open ipp
635/tcp open unknown
1080/tcp open socks
1524/tcp open ingreslock
2000/tcp open callbook
6000/tcp open X11
6667/tcp open irc
12345/tcp open NetBus
12346/tcp open NetBus
27665/tcp open Trinoo_Master
31337/tcp open Elite
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
32773/tcp open sometimes-rpc9
32774/tcp open sometimes-rpc11
54320/tcp open bo2k

Nmap run completed — 1 IP address (1 host up) scanned in 2.960 seconds

Well isn’t that strange? There are actually more open ports with our shiny new PortSentry IDS running than there are without it. This is because portsentry binds itself to every port which it monitors instead of running raw sockets, which do not need to be bound to a specific port. When PortSentry starts, it informs the TCP/IP stack on the host machine that is wants to listen on the list of ports it has been given. Now when a connection request arrives on that port, the stack will complete the request and forward the data for PortSentry. This method, as opposed to using raw sockets, has two major drawbacks:
PortSentry gives an attacker that there is a plethora of open ports available for exploitation on the victim machine. While this is not true, it will certainly pique interests and make the machine a more tempting target. The attacker may also realize that this machine is being guarded by PortSentry by noticing which ports are open; this is far more than most machines on the Internet today. This will tell the attacker which ports are tripwired. By using more advanced scanning techniques which could circumvent the PortSentry IDS, the attacker could determine exactly which ports to avoid scanning with ‘louder’ techniques, choosing instead to probe ports which he/she knows PortSentry is not guarding.
If other services are already bound to these ports, PortSentry is unable to monitor them. This can be seen in the following excerpt from my /var/log/messages file:

Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 15
Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 22
Oct 8 00:14:22 picard portsentry[4094]: adminalert: ERROR: could not bind TCP socket: 22. Attempting to continue
Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 79

As you can see, PortSentry is unable to monitor port 22 because the ssh service is already listening on that port. A machine with a large number of available services could render PortSentry useless. Also, If we cannot detect port scans against open ports, we are missing the whole point of having an IDS in the first place. PortSentry is therefore much more valuable on a machine with no services running such as a border router or a firewall, and not on a webserver or mailserver.

However, all is not lost. On a machine running PortSentry, I am unaware of any known scanning method which could be used to differentiate between the zombie ports opened by PortSentry and real ports opened by a legitamite service — at least not without triggering an alert. This will at least slow down most attacks, since PortSentry can be set with a hair trigger which will log an alert when someone attempts to connect to any port on its watch list, even once. This is another excerpt from my /var/log/messages file showing the log entries during the time of the scan:

Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 40421
Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 49724
Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 54320
Oct 8 00:47:28 picard portsentry[4240]: adminalert: PortSentry is now active and listening.
Oct 8 00:47:29 picard sshd[4241]: Did not receive identification string from 10.0.0.15
Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 49724
Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 79
Oct 8 00:47:30 picard portsentry[4240]: attackalert: Host: 10.0.0.15 is already blocked. Ignoring

Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 143

As you can see, PortSentry reacts rather quickly to this portscan. Only two ports have been probed before PortSentry logs it as an attack. As we discussed previously, when PortSentry establishes a connection with a remote host, it immediately tears it down. Most legitamite services will wait for some kind of input from you before doing so. In this manner, an attacker could telnet to ports reported open by his/her scanner and see if they have services running behind them. In this case, PortSentry recognizes even one attempt to connect to a tripwired port as an attack and reacts accordingly. By the second attempt, PortSentry logs a notice saying action has already been taken and it is now ignoring this activity. This kind of aggressive reporting may generate a lot of false positives, but it will also keep a lot of attackers away from you.
We will now attempt a SYN stealth scan against the victim computer. A SYN stealth scan sends an initial SYN packet to the victim machine, but does not respond to the SYN,ACK packet, instead sending a REST packet, terminating the connection attempt. This can be seen in the following tcpdump output on the victim machine:

01:12:49.885153 IP 10.0.0.15.55064 > picard.sympatico.ca.ssh: S 3369530623:3369530623(0) win 2048
01:12:49.885179 IP picard.sympatico.ca.ssh > 10.0.0.15.55064: S 3492815075:3492815075(0) ack 3369530624 win 5840
01:12:49.885405 IP 10.0.0.15.55064 > picard.sympatico.ca.ssh: R 3369530624:3369530624(0) win 0

We can see the SYN packet from the attacker, and send the usual SYN,ACK packet back. However, the attacker then sends a REST packet, and never completes the connection. Since PortSentry is currently monitoring for connections on its watch list, it ignores these attempts since no connection is actually made. The attacker, however, receives a SYN,ACK packet, showing him/her that there is a service responding on this port. While the presence of PortSentry, as previously deterrmined, will give the appearance of services where none exist, PortSentry will not detect this scan. Based on the specific set of responses received, a set that is unique to the default installation of PortSentry, this will alert the attacker to the presence of our IDS on this machine without revealing him/herself. The command nmap -sS 10.0.0.10, issued from the attacking machine, will generate the same results as nmap -sT 10.0.0.10, but will remain undetected.
An attacker could also choose to use UDP scans agains a victim machine. With PortSentry currently monitoring only for TCP activity, this type of scan will pass through undetected. Several vulnerable services operate on UDP, such as snmp, tftp, NFS, and others. Because UDP communication is connectionless, no reply can be solicited from the victim. Another technique must be employed. Null UDP packets (0 byte packets) are sent to the victim machine. A host receiving a UDP packet destined for a closed port should issue an ICMP port unreachable message, as seen in the following tcpdump output:

02:47:31.374353 IP 10.0.0.15.47613 > picard.sympatico.ca.ariel3: UDP, length: 0
02:47:31.374414 IP picard.sympatico.ca > 10.0.0.15: icmp 36: picard.sympatico.ca udp port ariel3 unreachable
02:47:32.176119 IP 10.0.0.15.47613 > picard.sympatico.ca.671: UDP, length: 0
02:47:32.176180 IP picard.sympatico.ca > 10.0.0.15: icmp 36: picard.sympatico.ca udp port 671 unreachable

If no response is received, the port is assumed to be open. Unfortunately, without stealth mode activated, PortSentry binds to the ports it is monitoring and they appear open when scanned. The pros and cons of UDP scans against PortSentry protected hosts are remarkably similar, therfore, to those of TCP connect() scans. Quite often, ICMP port unreachable messages are blocked from leaving a local network. UDP scans can also become excruciatingly slow, due to a suggestion in RFC 1812 (4.3.2. which limits the rate of ICMP error message generation, upon which these scans rely. For this reason, and the lack of documentation in RFC 768, UDP scans can be quite slow and inaccurate, and are not generally used by attackers. However, once a host has been compromised, it can be used to launch effective UDP scans from within a local network, since no error messages ever leave and latency is quite low. PortSentry will therefore be more effective when UDP scan detection is used as a means to detect compromised hosts or with internal attacks. At the network perimiter, although PortSentry does a fine job of detecting UDP scans (when told to with the command portsentry -udp), implement a firewall rule preventing ICMP port unreachable messages from leaving, thereby rendering external UDP scans useless.
We will now place PortSentry in stealth mode. In this mode, PortSentry operates using raw sockets. This does not require the binding of PortSentry to individual ports to see traffic coming in on them. It does, however, require root (or administrator) privileges, because we are now operating at a kernel level, examining packets before TCP does. The following is the output of the command nmap -sT 10.0.0.10 agains a PortSentry protected machine running in stealth mode:

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 18:14 EDT
Interesting ports on 10.0.0.10:
(The 1656 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
631/tcp open ipp
6000/tcp open X11

Nmap run completed — 1 IP address (1 host up) scanned in 4.381 seconds

Because PortSentry does not complete the connection when the request is made, only ports with actual services running behind them are shown as open (that’s because they are open). PortSentry is also able to detect SYN stealth scans in stealth mode, since it is now monitoring for connections requests at a kernel level and not connection establishments at a userland level. A SYN scan will reveal the same information as a connect() scan, and although it is harder to detect, PortSentry does its job here quite admirably, as shown in the following /var/log/messages excerpt:

Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 32774
Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 40421
Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 49724
Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 54320
Oct 8 03:30:10 picard portsentry[4569]: adminalert: PortSentry is now active and listening.
Oct 8 03:30:24 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 32772
Oct 8 03:30:29 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 32774
Oct 8 03:30:29 picard portsentry[4569]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring
Oct 8 03:31:46 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 143
Oct 8 03:31:46 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 27665
Oct 8 03:31:46 picard portsentry[4569]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring

PortSentry detects the SYN scan, and differentiates it from a normal connect() scan. This type of scan is more indicative of malicious intent, as a normal service request nearly always completes a connection. This scan does not.
When placed into UDP stealth mode, PortSentry does much the same thing as above, although it does not add any detection capabilities. In this mode, it is much more difficult for the attacker to realize that PortSentry is running on the victim machine. See the output below:

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 23:44 EDT
All 15 scanned ports on 10.0.0.10 are: closed

Nmap run completed — 1 IP address (1 host up) scanned in 9.989 seconds

Although PortSentry is listening on a set number of ports, no indication of this is given in the scan output. It does, however, detect and log the scan:

Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 32774
Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 31337
Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 54321
Oct 8 03:44:41 picard portsentry[4662]: adminalert: PortSentry is now active and listening.
Oct 8 03:44:43 picard portsentry[4662]: attackalert: UDP scan from host: 10.0.0.15/10.0.0.15 to UDP port: 161
Oct 8 03:44:44 picard portsentry[4662]: attackalert: UDP scan from host: 10.0.0.15/10.0.0.15 to UDP port: 31335
Oct 8 03:44:44 picard portsentry[4662]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring

Here PortSentry picks up the UDP scan on the first packet and reacts accordingly. We have successfully detected the attack from the attacker’s machine and given no indication that PortSentry even exists here.

We will now initiate some more advanced scans. We will start with the ACK scan. In this scan, an arbitrary packet is sent to the victim with the ACK flag set. In all cases, the victim host should respond with a RST packet, unless of course the ACK packet never reaches the host due to a firewall. If we solicit a response with an ACK packet that we cannot achieve with a SYN packet, we know that there is a firewall between us and the host which is dropping SYN packets. If we know the target host exists and neither packet gets through, we are dealing with a stateful firewall. If only the ACK packet gets through, we are dealing with a simpler packet-filtering device. This is the output from a TCP ACK scan against the victim machine:

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-08 00:01 EDT
All 1659 scanned ports on 10.0.0.10 are: UNfiltered

Nmap run completed — 1 IP address (1 host up) scanned in 8.914 seconds

And the responsible TCP traffic looks like this:

04:01:31.871139 IP picard.sympatico.ca.sfs-config > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.871494 IP 10.0.0.15.62029 > picard.sympatico.ca.nced: . ack 2844304146 win 4096
04:01:31.871543 IP picard.sympatico.ca.nced > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.871899 IP 10.0.0.15.62029 > picard.sympatico.ca.9992: . ack 2844304146 win 4096
04:01:31.871937 IP picard.sympatico.ca.9992 > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.872270 IP 10.0.0.15.62029 > picard.sympatico.ca.pdap: . ack 2844304146 win 3072
04:01:31.872309 IP picard.sympatico.ca.pdap > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
04:01:31.872636 IP 10.0.0.15.62029 > picard.sympatico.ca.724: . ack 2844304146 win 2048
04:01:31.872684 IP picard.sympatico.ca.724 > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0

This is not surprising, as I do not have a firewall running on this victim machine. We can see here the RST packets being sent in reply to the unexpected ACK packets the victim is receiving. If the victim here had never received these ACK packets, he/she would not be able to send an RST in reply. This would indicate a firewall dropping the packets somewhere along the way.
Note, however, that PortSentry did not pick up this scan. This scan could be used to determine firewall rulesets against a PortSentry protected firewall bastion host, if one only knows the address of the firewall or any machine behind it. While not revealing any open ports on any hosts, we can determine which packets to send through later to make our scans more effective.
XMAS, NULL, and FIN scans work by sending illegal flag combinations. According to RFC 793 (page 64),

“If the state is CLOSED (i.e., TCB does not exist) then

all data in the incoming segment is discarded. An incoming
segment containing a RST is discarded. An incoming segment not
containing a RST causes a RST to be sent in response. The
acknowledgment and sequence field values are selected to make the
reset sequence acceptable to the TCP that sent the offending
segment.”

” If the state is LISTEN then

first check for an RST

An incoming RST should be ignored. Return.”

Open ports are required to ignore these packets, while closed ports must respond with an RST packet. With a FIN scan, only the FIN bit is set. With the XMAS scan, the FIN, URG, and PUSH flags are all activated. In a normal communication exchange, no packet will ever have these three flags on simultaneously. Therefore, the host should respond with an RST packet, signalling its intention to immediately terminate this connection, which it believes to be fubared. A NULL scan turns off all flags; either the SYN or the ACK flag is always set during normal communications. The victim then responds with an RST flag.
The previous three scans (ACK, XMAS, and NULL) were not detected by PortSentry. This is because PortSentry is monitoring for half-finished connection attempts, in which an SYN,ACK was sent in reply to a SYN packet but an RST was received in place of an ACK packet. Since these three scans never send a SYN packet through, no connection is ever half-open and therefore we pass by PortSentry like reality passes by George Bush.
As a final note, if PortSentry is left in non-stealth mode, we will present an attacker with a multitde of supposedly open ports. We still have not found a way to differentiate between PortSentry zombie ports and ports with actual services running behind them without triggering an alarm.

References:

nmap 3.5 manpages Insecure.Com LLC
RFC 768 – User Datagram Protocol J. Postel
RFC 793 – Transmission Control Protocol prepared for the Defense Advanced Research Projects Agency
by the Information Sciences Institute, University of Southern California
RFC 791 – Internet Protocol prepared for the Defense Advanced Research Projects Agency
by the Information Sciences Institute, University of Southern California

This paper is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License, available at http://creativecommons.org/licenses/by-nc-sa/2.5/ca/

Tutorial- Aircrack on Backtrack with clients (WEP)

admin — Sun, 21 Jun 2009 23:50:51 +0000

ORIGINALLY POSTED BY JAYMILL230 FOR THETAZZONE/TAZFORUM HERE

Ok, this tutorial should be pretty straightforward and easy, then again, thats the entire idea behind a tutorial right? Anyway, to business, this tutorial will show you how to crack WEP very quickly using the aircrack on the backtrack security liveCD, that you can find here;
http://www.remote-exploit.org/backtrack.html

**quick note, cracking WEP with no clients will be out tonight/sometime real soon**

We will go over
1) Putting your atheros based card into monitor mode
2) Getting packet injection ready
3) injecting/sniffing
4) Cracking the WEP

This is the easier method, the one where the WEP has clients present, and you can use a deauth attack on them. Ok, enough talk, to business!

Monitor Mode

The first thing to do is boot up backtrack, basically by booting to a CD like you normally would, if you can’t figure this out, ask down below, or go use google. login to backtrack under root (password ‘toor’), and then type “startx” into the command line to start out GUI.

Sweet, now we are running *nix, and we can start the good stuff. Open up a command line, but clicking on the icon that looks like one on the bottom next to the ’start’ type thingy (let me know if I get to technical )

Now, we need to enter this into the command line;

Code: Select all: $ airmon-ng start wifi0 6 **starts wifi0 on channel 6, change for the channel of the network you are attacking, use kismet for this, not covered in this tutorial**
$ wlanconfig ath0 destroy $ ifconfig ath1 up $ iwconfig ath1 mode monitor 6

Sweet, now we have our card in monitor mode, and we can move onto bigger and better things.

Start up Airodump and getting some info ready

ok, lets start airodump so we can get some info out of it, and then we can just leave it running.

Code: Select all: $ airodump-ng --ivs --write bob --channel 6 ath1
**basically heres what each thing means; --ivs= only write the weak IV's, not every packet --write= the prefix of the file we are writing to, so bob.ivs --channel= the channel to scan on ath1= our network device**

Now that airodump is running, we need to snag a couple pieces of information from it, 1) The MAC address of the AP we are attacking, it’ll be in the first column. 2) the MAC address of a computer connected to that network.

Now, open up a new terminal (DON”T CLOSE AIRODUMP). type these lines in;

Code: Select all: $ export AP=mac_of_ap $ export MAC=mac_of_connected_computer

This basically just stored those as variables, so you don’t have to type them a bunch of times in the coming steps.

Getting everything ready

Good, now we have airodump running, and we can move onto getting packet injection ready. In the new console we opened up to export things into our new variables type in the following, but do NOT run it yet;

Code: Select all: $ aireplay-ng -0 10 -a $AP -c $MAC ath1
ok, we are running aireplay-ng attack 0 ten times ("-0 10"), which is a death attack, it means we will kick them off the network, so we can steal their ARP packets, to replay them. "-a" is the MAC address of the AP we are attacking that we stored before, -c is the client we are deauthing, and again ath1 is our interface

Now, lets get aireplay ready to snag those ARP packets we are going to get;

Code: Select all: $ aireplay-ng -3 -b $AP -h $MAC ath1
really quickly, this is attack number 3, it will wait until it finds an arp packet it can replay, it will ask you if you want to use the packet it finds, say yes (type in y, press enter), and it will replay them, getting you alot of IV's

Good, everything is ready, on to the actual thing!

The Attack!

Now, we have 2 attacks just chillin there ready to go, and airodump still in the background running. Start attack number 3 (the replay) first, then run your deauth attack. The replay attack will eventually find a packet, and it will ask if you want to use that one, say yes (type in y). Now look at airodump!

Your #data column should be shooting up on the AP you are attacking! It took me about 3 minutes to collect 100k data, more then enough for a 64bit WEP key. Now, to crack the key, we need to type in one more command, and wait less then a minute. You don’t have to close anything, or stop airodump/aireplay.

Go to the window we used for the deauth attack, and type in this command;

Code: Select all: aircrack-ng -n 64 -b $AP *.ivs

poof, aircrack should start, and in a few moments, you should have your WEP key! If not, wait a bit longer, and try again. If all else fails, it might be a 128 bit, and you will need about a million #data’s, and change “-n 64″ to “-n 128″, and try again. If you don’t get it then, I don’t know what to tell you!

I hope you learned something/got an idea of something, and you enjoyed yourself! Remember, Soon I will be posting cracking WEP on a network with no clients present.

**Obligatory Disclaimer; This tutorial was written as an education piece, cracking into somebody else’s network is illegal and punishable by fine/jail. Don’t be stupid**

2007 A Hacking Odessey Part 2 – Network Scanning & Nmap

admin — Fri, 05 Jun 2009 23:04:55 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

[size=150][b][u]2007 A Hacking Odyssey: Part Two – Network Scanning & Nmap Part 1[/b][/u]
[/size]

[quote]Due to post size limits I have had to split this paper into two halves. Please find the second half here:
http://tazforum.thetazzone.com/viewtopic.php?t=5766[/quote]

If you have followed part one you will have most of the information needed to allow you to progress on to the second phase of your attack/Pen test.

You can find part one here:
http://tazforum.thetazzone.com/viewtopic.php?t=5445

The second phase can be generically summed up as ‘Scanning’. To even start this phase we need of an absolute minimum one thing; an IP address. If you have not been able to glean and IP address during your reconnaissance phase, then you will need to go back and persevere with it, because until you get one you will not be able to do anything else….you can’t scan something if you don’t know where it is.

Scanning typically involves all or some of the following:

Covered in this paper:
War Driving
War Dialling
Network Mapping
Port Scanning

Covered in Part 3:
Vulnerability Scanning
IPS and IDS detection and evasion
Firewall ‘auditing’
PBX scanning

Scanning a network is a very unique activity as all networks are different; they are configured in different ways, secured in different ways, use different hardware, have different services running, respond differently to various scans and use different software/OS’s – to name but a few of the variations. For this reason it is impossible to write a step by step paper along the line of ‘enter this command and you will get this output, now enter this command and you have exploited the service’. It just won’t work this way.

What I will do however is explain the theory of how it all works and explain how to use the most common tools for doing this; the most common of these common tools being Nmap, hence a large part of this paper will be devoted to it.

I will briefly cover War Dialling and War Driving first though, as they are not terribly hard to understand.

**Before I go on I need to point out that the scanning phase is the complete opposite to the reconnaissance phase in terms of exposing yourself to the target network. Reconnaissance when done properly is nearly completely passive and is entirely legal. Scanning on the other hand is not passive in any way shape or form and is for the most part illegal. You WILL leave log entries on the remote system when scanning it. Whether these look suspicious to an administrator or are suspicious enough to set off an IDS alarm is entirely up to you and the methods you chose to adopt**

[b]War Dialling [/b]

Pretty much everyone has heard of War Dialling in today’s cyber world. It was probably made famous by the film War Games – where a young teenager connects to a government network via a Modem.

This film was released in the early 80’s and the technique used in it is still valid today…

Before VPN’s and Remote Access software were readily available the only feasible way for an employee to connect to the corporate LAN or indeed for an administrator to connect to a remote system was via a Modem; which they would ‘Dial in’ to.

Even though there are a lot more secure methods for remote access in today’s world, it does not mean that remote access via a modem does not still exist anywhere. A lot of people use the ‘if it is not broke, then don’t fix it’ philosophy. Couple this with the price of a modem (£5) and you have a very quick and extremely cheap remote access solution, albeit not a very efficient one but a working one all the same.

Think of your own dial up connection (everyone over the age of 10 must have been unlucky enough to of had a dial up connection at some point). You dial out onto the internet, usually to your ISP, enter a user name and password and viola you are connected to the Internet.

Obviously data flows both ways through this connection. If used in the conventional sense the data coming back is return traffic to one of your legitimate requests, i.e. a web page you have requested to see.

However what if the return traffic is not legitimate…….how does your modem know this……well, it doesn’t.

To use a dialup connection you must have a phone line, right? If you have a phone line then you will have a phone number. If someone dials this phone number and the line is connected to your modem…..what will they dial in to? Yep you guessed it; your modem and in effect your computer.

A very popular procedure amongst employees was to install some remote control software such as VNC and set it to listen on the COM port that the modem was using.
Then when they go home, they can dial in to the line attached to their computer and be greeted with the VNC login prompt.

In modern times (modern from an IT point of view) there is a plethora of remote control software available to any user for free or for very cheap. And all they need is a phone line installed by their desk. Chances are they will already have a phone next to their desk….so when they leave at night they connect this up to their modem, go home and dial their own number, connect to the free edition of VNC they have installed and start working from home. As far as they are concerned they are doing the company a favour as they can get more work done and it hasn’t cost the company a penny……what do they care about network security, that’s the job for they guy who keeps saying no to them whenever they ask for something……..sod him, right?

Unfortunately it is not just clueless end users who do this; Routers, switches and firewalls used to be remotely managed via a dialup link into them, with basic authentication. How often does a network infrastructure get upgraded? Not very often……..

Sadly in my experience of pen testing, 60% of the unsecured modems I find are attached to routers and not to end user work stations. System Admins come and go and they have a lot more to think about than one poxy phone line coming into an old router…….

The most common application used for War Dialling is probably THC-Scan (The Hackers Choice – http://www.thc.org/thc-scan/). It runs on pretty much anything that has a kernel and an emulator (yes even a MAC) and is extremely easy to use.

Obviously the final thing we need is a range of phone numbers right? If you have read part one you may have noticed the first two things we ever learnt about the target……its phone numbers and office hours. Why are the office hours important? Well we don’t want to try and take over a PC whilst the user is sitting in front of it do we….also if they do plug their phone line into the computer it is going to be so they can work from home….which won’t be in office hours will it?

I won’t cover instructions on how to use it as I don’t want to spend too much time on War Dialling, but there is a very good video tutorial showing how to use it on the above mentioned site and very extensive documentation is included with the download.

So you dial away and look at the log detailing what it found. If you use the Nudge feature of THC you may very well see some banners that can be very informative to use – such as ‘Hi, I’m a PC, or Hi, I am a MAC’. You will need to learn to recognise the return strings from the various modems it finds to be able to know what is listening behind the modem, i.e. VNC, PC Anywhere etc.

Some commercial War Diallers have a database that will tell you this automatically; if you don’t mind paying for them then this is a good choice to go for. PhoneSweep is probably the best commercial one available (http://www.sandstorm.net/products/phonesweep/) you can see a screen shot to better explain what I mean about identifying the system type – THC will just show you the raw output and it will be up to you to trawl through the logs and work out what system is what.

That’s pretty much it for War Dialling, find a modem, dial into it, see what remote control software is listening on the COM port, try and connect to it. The most common software listening will probably be VNC as it is free…..there is also a well publicized exploit for circumventing VNC authorisation……

[b]War Driving[/b]

War Driving derives its name from War Dialling. If War Dialling is phoning every number in a range to find a modem, then War Driving is driving round an area looking for every Wireless Access Points.(WAP). There are subsets of War Driving such as War Walking, War Mountain Biking, War Flying, War sitting on the bench outside the building with my laptop hoping I don’t look suspicious…generically they can all be safely called War Driving.

The chances of finding a WAP in today’s world are much greater that the chances of finding a modem. In the past most security/hacking type books typically confined Wireless LAN (WLAN) hacking to a few pages at the back of the book, however now-a-days it is becoming more and more popular and more and more rewarding in terms of illegally accessing a network. Due to this the newer security and hacking books tend to devote a lot more page space to WLAN hacking.

When conducting a Pen Test, after the reconnaissance phase I usually set up a laptop and leave someone with it to carry out the War Dialling , whilst that is running I will drive around the targets building and War Drive it. By the time I get back we are able to go through the results of both assessments. If we find any ‘miss configurations’ it usually gives us a general impression as to the state of the network and its security.

WLAN’s obviously use radio transmissions to transmit data from one node to another. Our aim as WLAN hackers is to put ourselves within range of these transmissions so we can also receive them and look at the contents being sent.

Before we do this we obviously need to find the Wireless networks.

WLAN’s all have a network name, which is what distinguishes them from each other and helps employees know which one they are meant to connect to. This network name is known as the Extended Service Set Identifier or ESSID. If you open your wireless network properties and search for networks, you will end up with a list of networks that your wireless adaptor is within range of. Each of these will have a name, what you are looking at is the ESSID of each WLAN.

ESSID’s are transmitted in clear to every wireless client that may be listening; this forms part of the ‘beacon’ that is transmitted periodically by the AP and is included on most packets leaving the WAP. Likewise when a client is associated with an AP, this also transmits the ESSID in clear.

It is possible for a wireless client that is not associated with an AP to send a ‘probe request’ to the AP asking for various bits of information. Normally the ESSID is included with these requests and any AP that does not have the same ESSID will drop the packet.

The rules of the various 802.11 protocols say that it must acknowledge a probe request that is using the ESSID configured on the AP OR that has the ESSID parameter set to ‘Any’.

If you re-read the above statement you will see a fairly large whole in the 802.11 implementations that we can exploit: “OR that has the ESSID parameter set to ‘Any’.”….

SO, if we send probe requests and set the ESSID bit to ‘any’…then all WAP’s within range must respond to the requests….. and when the WAP’s send traffic what is included in the packet, yep the ESSID.

Netstumbler (http://www.netstumbler.com/) which is arguably the most popular War Driving tool around uses this ‘flaw’ in the 802.11 protocols. It sends out 100’s of probe requests with the ESSID bit set to any and waits for return traffic. When this traffic comes it extracts the ESSID, sending MAC address, wireless channel and approximate signal strength of the WAP or the wireless client. If your wireless adaptor is set to receive a DHCP IP address (one that is automatically assigned to you) then Netstumbler will also record the IP range in use on that WLAN.

Wireless Access Points can be configured to ignore probe requests with the ESSID bit set to ‘any’, but as we will see later on this does not really increase the WLAN security. They will however defeat Netstumbler static of using the ‘any’ ESSID and will remain hidden to it.

Personally I don’t like Netstumbler due to it being very very noisy…..100’s of probe requests with the ESSID set to ‘any’ will set wireless IDS alarms of in an instant. Couple this with the fact it won’t pick up WLAN’s with the ESSID set to ‘any’ and you are found wanting when conducting an ‘Active Scan’. You set all the IDS’s off and may still not find all the WLAN’s.

It must be mentioned that Netstumbler comes into its element when using it with a GPS and a decent antenna though.

So how do we find the WLAN’s that are ignoring probe requests with the ‘any’ ESSID bit set and at the same time avoid setting off IDS’s?

To accomplish this we need to put of card into Monitor mode (sometimes referred to as rfmon mode)

Most people confuse promiscuous mode with monitor mode. They are two very different things.
Promiscuous mode will listen to all traffic that is sent on a WLAN that it is currently associated with. If it is not associated with a certain WLAN, then it will not accept traffic from it.
Monitor mode on the other hand listens to all WLAN traffic without associating to any WLAN.

Obviously if we have not associated with a WLAN and are not sending any packets to any, then no one will know we are there and no IDS alarms will be raised.

Airodump (http://www.wirelessdefence.org/Contents/Aircrack_airodump.htm) which run on *nix platforms, Airodump-ng (http://www.aircrack-ng.org/doku.php?id=airodump-ng) which runs on Windows platforms and Wellenreitter (http://www.remote-exploit.org/) which is now part of the BackTrack live CD are the most popular tools for this and are all capable of capturing packets in monitor mode. For the anoraks that use a MAC, Kismet will run on your *cough* MAC (http://www.kismetwireless.net/index.shtml) as well as pretty much any other OS too.

See here for a tutorial on using Airodump and indeed how to crack the WEP encryption: http://www.tazforum.thetazzone.com/viewtopic.php?t=2069

There will be a counterpart explaining packet injection with Windows and how to crack WPA-PSK at some point in the near future.

Which ever one you chose to use you will more than likely need extra drivers to put your wireless adaptor into monitor mode. Once in monitor mode you can chose to capture all packets as either an ‘.ivs’ file (for WEP cracking) or a ‘.cap’ file for viewing with applications such as Ethereal or Wireshark as it is now known.

The only occurrence left that we may find is if the WAP has been configured to not reply to probe requests set to ‘any’ and it is not broadcasting the ESSID with its beacons and is not a whole lot of traffic going over it. As long as there are clients associated with it (Airodump will tell us this, as will Wellenreitter) we can force a client off the WLAN and make it have to re-associate again. Commonly referred to as a Deauthentication Attack or Deauth for short, this forces traffic to be sent over the WLAN and will reveal the ESSID to us. It also forms the basis for WPA-PSK hacking.

A deauth attack utilizes yet another weakness with the 802.11 protocols, whereby a client will accept and obey a deauthentication packet that is sent by the AP without any authentication at all. In a nutshell what this means is that if we can send a deauthentication packet to a wireless client and make the packet look like it came from the AP, then the client will disassociate from that WLAN.

To take it one step further if we send the deauthentication packet to the broadcast address of the LAN then all of the wireless clients will disassociate from it.

When the clients re-associate to the LAN they have to broadcast an association packet which contains the ESSID in plain text to announce to the AP that they want to associate with it, otherwise no AP will answer, as if you remember from earlier they will only answer to their own ESSID, (or the ESSID of ‘any’ if configured to do so).

This is a slightly more noisy way of finding the ESSID, but nowhere near as noisy as Netstumbler. You may set IDS alarms off with this too, so use it with caution.

The trick in all of the above is finding the right WLAN for your target as you could be up 10’s of WLAN in the area, so you need to know which one is the right one.

Most companies will name their WLAN something relevant to them or even name it the same as the company name. If this is the case then they have just made your job a lot easier.
If the ESSID does not give you any info and you still have no idea which one belongs to your target you could try using the signal strength to make a best guess as to which WLAN is coming from your targets building, maybe visit the reception of your target and ask for directions to somewhere and then have a look at your WLAN sniffer’s logs to see what network had the strongest signal for the time you were in the building. If this is not providing you with any results you could even try phoning the IT dept up and asking them…..most will tell you the name there and then.

The final things to say are that if you are having trouble picking up the signal, try again at night time or better yet at night time after it has been raining. Wireless signals travel further at night and further still when the ground is damp. If you [i]still[/i] can’t get a signal try using a better antenna.

[b]Mapping the Network[/b]

If we are going to try and gain entry to the network, it is a good idea to know the layout of it. Any half decent attacker will draw out his findings so that he has a diagram with as much information as he can find, which might be a lot or a very little.

It is rather hard to map out networks that use NAT/PAT as our traces won’t get past the border router or firewall – we can’t trace to an internal IP address over the internet. However, if we have managed to find a way in via our War Driving and/or Dialling attempts then we already have access to the internal address space so can trace away to our hearts content. Either way a trace route works the same and the inner workings of it are very simple.

An IP packet has a Time To Live field set in it, commonly referred to as a TTL. Every layer 3 device such as a router or a layer 3 switch will decrement this TTL field by one as it routes the packet.

(See [url=http://tazforum.thetazzone.com/viewtopic.php?p=4793#4793]here[/url] if you are unsure what layer 3 refers to)

Once the frame has passed through enough layer 3 devices to reduce the TTL field to zero, the layer 3 device who reduced it to zero will drop it altogether. Without the TTL theoretically an IP packet would travel around a network for ever….

(According to the RFC the TTL is decremented by one for every second that the router has it. Due to the routing speed of most routers they typically have it for a lot less then a second, so it is safe to say that it will be reduced by one for every router it passes though)

When this last router drops the packet it needs to send something back to the original sender to say that the packet has timed out, as per RFC rules. To do this it will send an ICMP Time Exceeded message (ICMP type 11 as defined in RFC792).

Here is where the trace part comes in:

We now that only a router will send the ICMP time exceeded message.
The source IP address of this times exceeded message will be the routers IP address.
If we know what the original TTL setting was we can determine how many hops away the router that sent the time exceeded message is.

(A hop is considered to be a routing device that the packer passes through, so two hops means it has gone through two routers)

So we set the TTL to one – then send it to the first router, this will decrement the TTL to zero and be forced to drop the packet and send the ICMP message to us – when we receive this message we learn the IP address of the first router.

Then we set the TTL to a value of two – the first router decrements the TTL to one, but then as it is not zero it sends it on to the next router in its path – this router receives it, decrements the TTL to zero and is forced to send the ICMP type 11 message to us – thereby giving us the IP address of the second router.

Then we set the TTL to three and the same process occurs until it gets to the final router.

Setting all thses TTL fields manually can be quite a time consuming task, so MS and *nix have an application that will do it for us. The Microsoft version is called tracert and the *nix version is called traceroute.

Simply open up a command prompt and type ‘tracert’ followed by the destination IP address or Fully Qualified Domain Name (FQDN):

[code]
C:\Documents and Settings\Nokia>tracert google.com

Tracing route to google.com [72.14.207.99]
over a maximum of 30 hops:

1 95 ms 99 ms 99 ms speedtouch.lan [192.168.1.254]
2 241 ms 256 ms 257 ms brnt-bam-2.inet.ntl.com [194.145.148.7]
3 239 ms 248 ms 251 ms brnt-t3core-1a-ge-110-0.inet.ntl.com [213.105.19
9.85]
4 223 ms 227 ms 245 ms bre-bb-a-so-130-0.inet.ntl.com [213.105.174.245]

5 240 ms 255 ms 247 ms gfd-bb-b-so-120-0.inet.ntl.com [213.105.172.150]

6 * 217 ms 226 ms nth-bb-a-so-000-0.inet.ntl.com [62.253.185.97]
7 256 ms 247 ms 245 ms nth-bb-b-so-200-0.inet.ntl.com [213.105.172.194]

8 279 ms 265 ms 248 ms tele-ic-1-as0-0.inet.ntl.com [62.253.184.2]
9 250 ms 278 ms 268 ms 212.250.14.66
10 245 ms 268 ms 277 ms 72.14.238.244
11 319 ms 316 ms 317 ms 216.239.46.112
12 359 ms 352 ms 356 ms 72.14.233.113
13 344 ms 349 ms 337 ms 66.249.94.96
14 343 ms 341 ms 337 ms 66.249.94.118
15 353 ms 349 ms 343 ms eh-in-f99.google.com [72.14.207.99]
[/code]

The numbers on the side indicate what the TTL was for that hop. The next three columns tell us the round trip time and the last part of it tells us the FQDN of the router if there is a DNS entry in existence for that IP address, or it will just tell us the IP address of it.

You can usually tell by the trace route output which routers belong to the same organisation; the first seven hops in my trace all belonged to NTL.

Some times however the routers won’t play by the rules and will be configured to not [i]send[/i] ICMP Time Exceeded messages out. If this is the case you will get some ‘*******’s’ instead of an IP address.

You could also be unlucky enough to come across a router that not [i]allow[/i] ICMP type 11 packets to pass through it. If this is the case you will get all ****’s from this router onwards as the return packets can not get to you hence you can’t trace the routers IP address.

[b]Ping Sweep[/b]

To go hand in hand with traceroute you can also PING a target or a targets subnet to see what hosts are active on it.

There are hundreds of tools available but I suppose the most common is Nmap.
Use the –sP option to Ping Sweep a subnet. For example if we ping sweep the IP addresses adjacent to Google (we found Google’s IP from our trace route) we will be able to see what is alive:

[code]
C:\Documents and Settings\Nokia>nmap -sP 72.14.207.0-255

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-13 20:38 GMT
Standard Time
Host 72.14.207.4 appears to be up.
Host 72.14.207.5 appears to be up.
Host 72.14.207.6 appears to be up.
Host 72.14.207.8 appears to be up.
Host eh-in-f9.google.com (72.14.207.9) appears to be up.
Host eh-in-f19.google.com (72.14.207.19) appears to be up.
Host eh-in-f32.google.com (72.14.207.32) appears to be up.
Host eh-in-f33.google.com (72.14.207.33) appears to be up.
Host eh-in-f34.google.com (72.14.207.34) appears to be up.
Host eh-in-f35.google.com (72.14.207.35) appears to be up.
Host eh-in-f36.google.com (72.14.207.36) appears to be up.
Host eh-in-f37.google.com (72.14.207.37) appears to be up.
Host eh-in-f38.google.com (72.14.207.38) appears to be up.
Host eh-in-f39.google.com (72.14.207.39) appears to be up.
Host eh-in-f40.google.com (72.14.207.40) appears to be up.
Host eh-in-f41.google.com (72.14.207.41) appears to be up.
Host eh-in-f42.google.com (72.14.207.42) appears to be up.
Host eh-in-f43.google.com (72.14.207.43) appears to be up.
Host eh-in-f44.google.com (72.14.207.44) appears to be up.
Host eh-in-f45.google.com (72.14.207.45) appears to be up.
Host eh-in-f46.google.com (72.14.207.46) appears to be up.
Host eh-in-f47.google.com (72.14.207.47) appears to be up.
Host eh-in-f48.google.com (72.14.207.48) appears to be up.
Host eh-in-f49.google.com (72.14.207.49) appears to be up.
Host eh-in-f50.google.com (72.14.207.50) appears to be up.
Host eh-in-f51.google.com (72.14.207.51) appears to be up.
Host eh-in-f52.google.com (72.14.207.52) appears to be up.
Host eh-in-f53.google.com (72.14.207.53) appears to be up.
Host eh-in-f54.google.com (72.14.207.54) appears to be up.
Host eh-in-f56.google.com (72.14.207.56) appears to be up.
Host eh-in-f57.google.com (72.14.207.57) appears to be up.
Host eh-in-f58.google.com (72.14.207.58) appears to be up.
Host eh-in-f59.google.com (72.14.207.59) appears to be up.
Host eh-in-f60.google.com (72.14.207.60) appears to be up.
Host eh-in-f61.google.com (72.14.207.61) appears to be up.
Host eh-in-f62.google.com (72.14.207.62) appears to be up.
Host eh-in-f63.google.com (72.14.207.63) appears to be up.
Host eh-in-f64.google.com (72.14.207.64) appears to be up.
Host eh-in-f65.google.com (72.14.207.65) appears to be up.
Host eh-in-f66.google.com (72.14.207.66) appears to be up.
Host eh-in-f67.google.com (72.14.207.67) appears to be up.
Host eh-in-f68.google.com (72.14.207.68) appears to be up.
Host eh-in-f69.google.com (72.14.207.69) appears to be up.
Host eh-in-f70.google.com (72.14.207.70) appears to be up.
Host eh-in-f71.google.com (72.14.207.71) appears to be up.
Host eh-in-f72.google.com (72.14.207.72) appears to be up.
Host eh-in-f73.google.com (72.14.207.73) appears to be up.
Host eh-in-f74.google.com (72.14.207.74) appears to be up.
Host eh-in-f75.google.com (72.14.207.75) appears to be up.
Host eh-in-f76.google.com (72.14.207.76) appears to be up.
Host eh-in-f77.google.com (72.14.207.77) appears to be up.
Host eh-in-f78.google.com (72.14.207.78) appears to be up.
Host eh-in-f79.google.com (72.14.207.79) appears to be up.
Host eh-in-f80.google.com (72.14.207.80) appears to be up.
Host eh-in-f81.google.com (72.14.207.81) appears to be up.
Host eh-in-f83.google.com (72.14.207.83) appears to be up.
Host eh-in-f84.google.com (72.14.207.84) appears to be up.
Host eh-in-f88.google.com (72.14.207.88) appears to be up.
Host eh-in-f91.google.com (72.14.207.91) appears to be up.
Host eh-in-f93.google.com (72.14.207.93) appears to be up.
Host eh-in-f95.google.com (72.14.207.95) appears to be up.
Host eh-in-f96.google.com (72.14.207.96) appears to be up.
Host eh-in-f97.google.com (72.14.207.97) appears to be up.
Host eh-in-f99.google.com (72.14.207.99) appears to be up.
Host eh-in-f100.google.com (72.14.207.100) appears to be up.
Host eh-in-f101.google.com (72.14.207.101) appears to be up.
Host eh-in-f104.google.com (72.14.207.104) appears to be up.
Host eh-in-f107.google.com (72.14.207.107) appears to be up.
Host eh-in-f112.google.com (72.14.207.112) appears to be up.
Host eh-in-f115.google.com (72.14.207.115) appears to be up.
Host eh-in-f117.google.com (72.14.207.117) appears to be up.
Host eh-in-f121.google.com (72.14.207.121) appears to be up.
Host eh-in-f123.google.com (72.14.207.123) appears to be up.
Host eh-in-f129.google.com (72.14.207.129) appears to be up.
Host eh-in-f133.google.com (72.14.207.133) appears to be up.
Host eh-in-f161.google.com (72.14.207.161) appears to be up.
Host 72.14.207.162 appears to be up.
Host 72.14.207.164 appears to be up.
Host 72.14.207.165 appears to be up.
Host eh-in-f176.google.com (72.14.207.176) appears to be up.
Host eh-in-f177.google.com (72.14.207.177) appears to be up.
Host eh-in-f178.google.com (72.14.207.178) appears to be up.
Host eh-in-f179.google.com (72.14.207.179) appears to be up.
Host eh-in-f180.google.com (72.14.207.180) appears to be up.
Host eh-in-f181.google.com (72.14.207.181) appears to be up.
Host eh-in-f182.google.com (72.14.207.182) appears to be up.
Host eh-in-f183.google.com (72.14.207.183) appears to be up.
Host eh-in-f184.google.com (72.14.207.184) appears to be up.
Host eh-in-f187.google.com (72.14.207.187) appears to be up.
Host eh-in-f190.google.com (72.14.207.190) appears to be up.
Host eh-in-f191.google.com (72.14.207.191) appears to be up.
Host eh-in-f196.google.com (72.14.207.196) appears to be up.
Host eh-in-f212.google.com (72.14.207.212) appears to be up.
Host 72.14.207.221 appears to be up.
Host 72.14.207.222 appears to be up.
Host 72.14.207.224 appears to be up.
Host 72.14.207.225 appears to be up.
Host 72.14.207.227 appears to be up.
Host 72.14.207.228 appears to be up.
Host 72.14.207.230 appears to be up.
Host 72.14.207.231 appears to be up.
Host 72.14.207.233 appears to be up.
Host 72.14.207.234 appears to be up.
Host 72.14.207.236 appears to be up.
Host 72.14.207.237 appears to be up.
Host 72.14.207.251 appears to be up.
Host 72.14.207.252 appears to be up.
Host 72.14.207.253 appears to be up.
Host 72.14.207.254 appears to be up.
Nmap finished: 256 IP addresses (109 hosts up) scanned in 22.328 seconds
[/code]

Oh my, doesn’t Google have rather a lot of servers.

The last thing to note is that just like ICMP time exceeded messages; ICMP replies can also be blocked by routers & firewalls and the actual host can also be configured not to reply to ICMP requests.

[b]Port Scanning[/b]

Port scanning is a very useful tool that is very much in favour of the attackers. If we are to find a way into a network then it will more than likely be through a vulnerable service of some kind.

Most newcomers find ‘ports’ a difficult concept to grasp due to them trying to think of them as physical ports, hence when I say there are 65356 different ports you probably try and picture the back of a computer with all these ports sticking out of it.

The ports are entirely configured in software and in very simple terms all they are is a way of keeping traffic from different services separate.

A service can be a Mail Server, a Web Server, an FTP server etc. If someone sends you an email, you don’t want it going to your web server do you?

So all these services are given their own ports to use by way of a port number. There are 65356 TCP ports and 65356 UDP ports.

Take a SMTP Mail server and an FTP server for example:

An SMTP Mail server usually uses port 25 (TCP) and an FTP server will usually use port 21 (TCP)

If I send you an email, your computer can’t just simply read it and determine it is an email and needs to go to the mail server – likewise if I send you a file via FTP your computer cant read this and know it is a file destined for the FTP service…only the relevant services will know what to do with the data. So we need a way to tell your computer to send the right data to the right service.

To accomplish this we put the destination port number in the packet and then send it to the computer. This way when the data arrives at the computer all it has to do is look for a port number, if it says port 25 then it knows to send it to the service listening on port 25, which will be the Mail server – the mail server receives this traffic, understands what it is and passes it on up to your mail client so you can read it.

If I want to send you a file via FTP I first open up a channel to you on port 21. Your computer receives this data, looks at the destination port number and knows where to send it to, in this case the service listening on port 21.

There is more to it than this, but in essence this is what happens.

The obvious limitation to this is that every service needs to be listening on the correct port – if I am to send an email to you I need to know that your mail server is listening on port 25 for me to put the destination port number in the packet…if you have your mail server listening on port 50, when I send an email to you, your computer will look at the port number (25), see there is no service listening on that port and drop the data. You would also be disrupting the service that [i]should[/i] be listening on port 50.

For this reason the Internet Assigned Numbers Authority (IANA) have a very strict registration process to control which service will listen on which port.

From the IANA web site:

[quote]
The port numbers are divided into three ranges: the Well Known Ports,
the Registered Ports, and the Dynamic and/or Private Ports.

The Well Known Ports are those from 0 through 1023.

DCCP Well Known ports SHOULD NOT be used without IANA registration.
The registration procedure is defined in [RFC4340], Section 19.9.

The Registered Ports are those from 1024 through 49151

DCCP Registered ports SHOULD NOT be used without IANA registration.
The registration procedure is defined in [RFC4340], Section 19.9.

The Dynamic and/or Private Ports are those from 49152 through 65535
[/quote]

In layman’s terms; Well Known ports are used for the most common services specific to network and Internet functionality, such as FTP, SMTP, Telnet, HTTP, DNS etc

Registered Ports are for common services that are not specific for the functionality of a Network or the Internet such as PC games, Kazza, SQL cluster manager, Anti Virus etc – things that are widely used and that others need to know the port number in advance for.

The Dynamic and private ports can be used by anyone for anything.

You can find a constantly updated list of port assignments on the IANA web site:
http://www.iana.org/assignments/port-numbers

So, taking it a step further and looking at it from a bad guy’s point of view, if someone wants to run a mail server and receive email then they need to have a mail server listening on port 25.

If we send a data packet to that port and we get a response back, we know that as per IANA regulations that is has to be a mail server who sent this response. If we don’t get a response back then there is nothing listening on that port, hence there is no service running.

There are two mail types of protocol used for the transmission of data over a network and the Internet; User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). Even though they both do the same job, they do it in very different ways. If you are not to sure about how TCP and UDP works and the differences between the two, please read [url=http://tazforum.thetazzone.com/viewtopic.php?t=473]THIS[/url] before continuing on with this paper as you will need to have a rudimentary understanding of it to understand how a port scan works and the benefits of using different types of scan.

Which brings us nicely on to Nmap….

[b]Nmap (Part 1 of 3)[/b]

Nmap is probably the worlds most famous and useful port scanner. It runs on pretty much every Operating System and is relatively straight forward to use. For Windows there is a graphical version and a command line version, which can both be found here:
http://insecure.org/nmap/download.html

For this paper I shall use the Command Line Interface (CLI) version however if you have never used it before it maybe worth while to use the graphical version until you are comfortable with it.

After installing Nmap and the Winpcap drivers that come with it Windows XP Service Pack 2 users should install the registry file. It can be found in, C:\Program Files\Nmap, simply right click on ‘nmap_performance.reg’ and select merge – the latest release has this as an install option.

You can now use Nmap by typing nmap directly into a command prompt. You need to be an administrator/root of the host you install Nmap on to use all of its features. If you already have Nmap installed use the following command to ensure you have the latest version (Version 4.20 as of this writing): “nmap –version”

If you do not add any option after typing nmap it will display a list of commonly used parameters that you can use for your scan:

[code]
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Nokia>nmap
Nmap 4.03 ( http://www.insecure.org/nmap )
Usage: nmap [Scan Type(s)] [Options] {target specification}
TARGET SPECIFICATION:
Can pass hostnames, IP addresses, networks, etc.
Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
-iL
: Input from list of hosts/networks
-iR : Choose random targets
--exclude : Exclude hosts/networks
--excludefile : Exclude list from file
HOST DISCOVERY:
-sL: List Scan - simply list targets to scan
-sP: Ping Scan - go no further than determining if host is online
-P0: Treat all hosts as online -- skip host discovery
-PS/PA/PU [portlist]: TCP SYN/ACK or UDP discovery to given ports
-PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
-n/-R: Never do DNS resolution/Always resolve [default: sometimes]
--dns-servers : Specify custom DNS servers
--system-dns: Use OS's DNS resolver
SCAN TECHNIQUES:
-sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
-sN/sF/sX: TCP Null, FIN, and Xmas scans
--scanflags : Customize TCP scan flags
-sI : Idlescan
-sO: IP protocol scan
-b : FTP bounce scan
PORT SPECIFICATION AND SCAN ORDER:
-p : Only scan specified ports
Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080
-F: Fast - Scan only the ports listed in the nmap-services file)
-r: Scan ports consecutively - don't randomize
SERVICE/VERSION DETECTION:
-sV: Probe open ports to determine service/version info
--version-intensity : Set from 0 (light) to 9 (try all probes)
--version-light: Limit to most likely probes (intensity 2)
--version-all: Try every single probe (intensity 9)
--version-trace: Show detailed version scan activity (for debugging)
OS DETECTION:
-O: Enable OS detection
--osscan-limit: Limit OS detection to promising targets
--osscan-guess: Guess OS more aggressively
TIMING AND PERFORMANCE:
Options which take are in milliseconds, unless you append 's'
(seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
-T[0-5]: Set timing template (higher is faster)
--min-hostgroup/max-hostgroup : Parallel host scan group sizes
--min-parallelism/max-parallelism : Probe parallelization
--min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout : Specifies
probe round trip time.
--max-retries
: Caps number of port scan probe retransmissions.
--host-timeout : Give up on target after this long
--scan-delay/--max-scan-delay : Adjust delay between probes
FIREWALL/IDS EVASION AND SPOOFING:
-f; --mtu : fragment packets (optionally w/given MTU)
-D : Cloak a scan with decoys
-S : Spoof source address
-e : Use specified interface
-g/--source-port : Use given port number
--data-length : Append random data to sent packets
--ttl : Set IP time-to-live field
--spoof-mac : Spoof your MAC address
--badsum: Send packets with a bogus TCP/UDP checksum
OUTPUT:
-oN/-oX/-oS/-oG : Output scan in normal, XML, s| and Grepable format, respectively, to the given filename.
-oA : Output in the three major formats at once
-v: Increase verbosity level (use twice for more effect)
-d[level]: Set or increase debugging level (Up to 9 is meaningful)
--packet-trace: Show all packets sent and received
--iflist: Print host interfaces and routes (for debugging)
--log-errors: Log errors/warnings to the normal-format output file
--append-output: Append to rather than clobber specified output files
--resume : Resume an aborted scan
--stylesheet : XSL stylesheet to transform XML output to HTML
--webxml: Reference stylesheet from Insecure.Org for more portable XML
--no-stylesheet: Prevent associating of XSL stylesheet w/XML output
MISC:
-6: Enable IPv6 scanning
-A: Enables OS detection and Version detection
--datadir : Specify custom Nmap data file location
--send-eth/--send-ip: Send using raw ethernet frames or IP packets
--privileged: Assume that the user is fully privileged
-V: Print version number
-h: Print this help summary page.
EXAMPLES:
nmap -v -A scanme.nmap.org
nmap -v -sP 192.168.0.0/16 10.0.0.0/8
nmap -v -iR 10000 -P0 -p 80
SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES
[/code]

Some of these options you will use all the time and some you may never use but if you spend a few minutes to read through them it will give you a basic understanding of the way you configure nmap to scan for you.

The syntax is generally ‘nmap’ followed by the scan type and any scan option, followed by the IP address or IP address range, followed by the ports you want to scan (not always required), followed by the output you want i.e. filename and file type:

[code]
Nmap –sT –P0 80.80.80.80 –p 80 –oN scan.doc
[/code]

This simple scan tells Nmap to conduct a TCP connect scan, against 80.80.80.80 on port 80 and to save the results to a file called scan.doc.

**I use the IP address of 80.80.80.80 in this paper purely due to the fact it is quick to type**

The following pages will cover all of the Scan Types, most of the scan options and a few maybe not so well known tips and tricks we can do perform with Nmap.

As this moment in time there are 12 different types of scan you can perform with nmap:

[b]1) TCP Connect –sT[/b]

This is the ‘scan by the rules’ option and will try to establish a full and RFC compliant TCP connection to the remote host on the necessary port. If the connection is successful then the port is reported as being open. Although this is the most reliable scan type it is also the most risky for a would-be attacker as the connection will be recorded by the remote system due to it being a complete connection.

The syntax for this would be: nmap –sT 80.80.80.80. (obviously substitute 80.80.80.80 for the IP address you want to scan)

[b]2) TCP SYN scan -sS[/b]

The SYN scan is a little stealthier than the Connect scan as it does not establish a full TCP connection. Instead of completing the full TCP three-way handshake it will only go through half of it.
If you have read the above paper I linked to you will understand the three-way TCP handshake:

SYN
SYN-ACK
ACK

The initiating host sends a packet marked with a SYN flag, next the receiving host will respond with a SYN-ACK and finally to complete the three-way handshake the initiating host will send an ACK packet. (This ACK is then flagged in all subsequent packets for that connection – remember this for later)

In plain speak the SYN packet saying ‘I have some data for you, do you want it?’ to with the receiving station will send a SYN-ACK which means ‘Yes I do, please send it’ and the initiating host responds with the ACK which means ‘OK, here it comes’.

Now if we send the initial SYN packet and the remote host responds with the SYN-ACK packet as it should BUT we do not send the expected ACK packet, then we have not completed a valid connection. If we send a FIN packet, which tells the remote host to tear down any connection it may have, and then our connection attempt may not get logged due to the connection being terminated before it was complete.

The fact that the remote host responded with a SYN-ACK on the port we sent the SYN packet to is enough to tell us that there is a service listening on that port and that is all we need to find out…

Some modern firewalls and routers will recognise this pattern of packets (SYN, SYN-ACK, FIN) as a SYN scan though and may still log it.

The syntax for a TCP SYN scan is: nmap –sS 80.80.80.80

[b]3)TCP ACK scan -sA[/b]

Following on from the packets we have sent and received so far, it makes sense to try and send an ACK packet and see what we get. This is where we start to break the rules of TCP connections. So far we have complied with the RFC rules that dictate a valid TCP connection starts with a SYN, then has a SYN-ACK and then has an ACK (which we bent a little on the last scan by not sending a final ACK but the connection was still initiated by the book)

By sending an ACK packet first we hope to get past any packet filters that may be filtering our normal SYN/SYN-ACK packets.

Some older non-stateful packet filters base their decision on what packets to allow and what to drop solely on the TCP control bit (the SYN/ACK etc). If you were on an internal LAN that allowed all outgoing traffic but denied all inbound traffic you would not be able to do anything on the Internet as nothing would reach you, i.e. when you wanted to view a web page the data would not get to you as your packet filter would be blocking it all..

To get around this problem non-stateful packet filters such as a border router or a low end firewall will look at the TCP control bit and see if it is a SYN or an ACK; if it is a SYN then it must be someone trying to originate a connection from the Internet, hence it will drop the packet. However if the ACK bit is set, then by the RFC rules it must belong to a connection that is already established, and since it won’t let SYN packets in, only out, the connection must have been established by an internal host therefore it will allow the packet through.

However there is a slight difference with this type of scan – our first two scans (TCP Connect and SYN) will determine if a port is open by the response it receives from the remote host. If a SYN-ACK comes back the port obviously is open and replying to the SYN packet as normal, however when a SYN packet is destined to a port that is closed the remote host will send a RST (Reset) packet back. Nmap will determine the port state by these responses and show you the port as open or closed accordingly.

If you send a packet that does not comply with the RFC rules (such as an ACK packet that does not follow a SYN, SYN-ACK) then it will respond with a RST packet and reset the connection.

Can anyone see where we are going to run into trouble here? If we send a TCP ACK packet to a remote host, as it does not comply with the rules we will get a RST packet back…..but we have just said that if a port is closed a RST packet will also be sent back…..so no matter if the port is open or closed the remote host will always send a RST packet back to an ACK scan probe……….what use is this ACK scan then?

The ACK scan is used to test non-stateful packet filtering rules. So say a border router has been configured to block all packets to ports 100-200 but to allow them on port 80, further to this established connections are allowed on all ports over 1024.

When we scan this with an ACK scan the packet filtering device will drop all packets destined to ports 100 – 200 as this is what it has been told to do – so we will either get no response or an ICMP Destination Unreachable response back, either way Nmap will know the probe failed. When it gets to port 80 the packet filter will let the traffic through and the host on the other side of the packet filter will send a RST packet because as we know an ACK packet is not a valid way to start a TCP connection – if a RST packet comes back Nmap knows the packet filter must have allowed the packet through (otherwise either an ICMP unreachable or nothing at all would have come back) and will mark it as UNfiltered. When it gets to port 1024 and over as the packet filter has been told to allow established connections through (packets with the ACK flag) all of our probes will be allowed to traverse the packet filter and we will get back a load of RST packets – therefore Nmap will flag the ports as UNfiltered.

Going off this output we will be able to determine that port 80 and all ports over 1024 will accept incoming packets that are part of a valid connection.

This type of scan does not actually tell us if a port is open or closed on the remote host; it only tells us if the packet filter device allowed the packet through or dropped them, as even if there was a Web Server running on the host behind the packet filter, it will still send a RST packet back when a probe comes to port 80……likewise if there was no Web Server running then a RST packet will still come back.

The theory of the ACK scan can be quite confusing if you are new to TCP connections and packet filters but just remember that it will only tell us if a packet filter will allow the packets into the network, it will not tell us if the port is actually open on the remote host.

The syntax for the ACK scan is: nmap –sA 80.80.80.80
The output will be something similar to the following:

[code]
PORT STATE SERVICE
53/tcp UNfiltered domain
80/tcp UNfiltered http
443/tcp UNfiltered https
1025/tcp UNfiltered NFS-or-IIS
1026/tcp UNfiltered LSA-or-nterm
1027/tcp UNfiltered IIS
1029/tcp UNfiltered ms-lsa
1030/tcp UNfiltered iad1
1031/tcp UNfiltered iad2
1032/tcp UNfiltered iad3
1033/tcp UNfiltered netinfo
1040/tcp UNfiltered netsaint
[/code]

If there is no mention of the port then it is deemed to be blocked by the packet filtering device, if it says UNFiltered then obviously the packet filter let the ACK packet through.

[b]4) FIN Scan –sF, Xmas-Tree Scan –sX and Null Scan –sN[/b]

So far we have not managed to scan a remote host in a way that is not likely to leave log entries. We have initiated a connection in the proper way and two thirds of the way and the ACK scan will not tell us what ports are open. This is pretty useless to someone who needs to know what ports are open but does not want to leave log entries, a.k.a. an attacker.

Nmap includes a range of stealth scans; they are called stealth scans as they do not open a connection to a remote host in a normal everyday way. They violate the normal TCP protocol rules by sending unexpected packets and packets that are meaningless to a remote host that does not have a valid connection.

The first of these stealth scans is a FIN scan. This sends a packet to a remote host with the FIN flag set. Normally the FIN flag would signal the end of a connection and mark it to be reset, however if we have never setup a valid connection with the remote host we have no need to send a FIN packet.

The TCP protocol state that if an unexpected FIN packet arrives destined to a closed port then a RST packet should be returned and if an unexpected FIN packet arrives on an open port, then nothing should be returned – the packet should be ignored.

Using these TCP connection rules Nmap is able to determine if a port is open or closed by looking to see if a RST packet comes back or not – if it does the port is closed, if it doesn’t the port is open.

It’s important to remember that a FIN scan will not work against a Windows based hosts, as Microsoft do not follow the TCP rules completely and their Operating Systems will return a RST packet in response to a unsolicited FIN packet arriving on a closed or open port. Hence Nmap will think that all ports are closed – however if you run a –sT or a –sS scan on the same target and Nmap reports that there are ports open, it is a safe assumption that you are scanning a Windows box (this method was used a lot until Nmap OS detection was added and improved) – it is worthwhile noting that some Cisco, HP and IRIX equipment also respond to a unsolicited FIN packet in the same way as Windows – there is also one extra little used use for this; if you are scanning a web server that is behind a firewall and only permitting traffic to port 80 and when you scan it with a SYN scan Nmap reports the port as open but a FIN scan comes back as closed, then you know there is a high chance of the web server running on a Windows based machine just from this very quick and easy scan – a fact which can come in very handy when trying to exploit the web server or perform SQL injection.

The syntax for a FIN scan is: nmap –sF 80.80.80.80

[b]5) Xmas Tree Scan –sX[/b]

The Xmas tree scan works in exactly the same way as the FIN scan except that is sets the PSH (Push) and URG (urgent) flag in conjunction with the FIN flag. This may get around some IDS/IPS setups. This scan still has the same effect on the Windows OS as the FIN scan.

The syntax for a Xmas tree scan is: nmap –sX 80.80.80.80.

[b]6) Null Scan[/b]

To follow on from the logical pattern we are using so far the Null scan does the opposite of the Xmas tree scan and does not set any TCP control bits at all. The TCP RFC dictates that a RST packet should be sent from closed ports and an open port should drop the incoming packet – in exactly the same way as the pervious two scans. Again this may defeat some IDS/IPS setups and still has the same effect on Windows.

The syntax for a Null scan is: nmap –sN 80.80.80.80

We have run out of options for the TCP control bits now; we have tried setting the SYN, SYN-ACK, FIN, FIN-URG-PSH TCP control bits and also tried setting none of them. (You may notice that RST is missing, this is because the TCP RFC says that a RST packet is responded to with a RST packet regardless of if the port is open or closed, hence we would be no more the wiser than before we started.)

Wouldn’t it be good if we could play with these TCP control bit’s ourselves and create our own scan parameters to try and find miss configurations in firewalls, IPS’s, Routers and packet filtering devices? …..Well we can and it is very simple to do.

[b]7) Customise your TCP packet[/b]

To customise out own TCP packets we use the ‘–scanflags’ option followed by the TCP control bit(s) we want to set, such as:

Nmap –scanflags FINACKSYN 80.80.80.80.

This will obviously send TCP probes with the FIN, ACK and SYN flags set. You can have some god results with poorly configured network border security devices by using this option. It is an individual trial and error technique though and one you should practise on your own equipment so you can get to understand what works with what type of configuration.

You can specify scan types to tell Nmap how to interpret the responses it receives. By default it uses a –sS.

[b]8) FTP Bounce scan [/b]

In my experience not a lot of people seem to know about the FTP Bounce capabilities of Nmap. The FTP bounce feature exploits a very old feature of FTP servers whereby a client that has connected to an FTP Server can instruct it to send a file to a remote host other than the machine the client is connecting from.

This feature was very useful in the early days when bandwidth and connection speeds could be very low. Instead of having the file transferred to your own machine over a very slow link, you could have it transfer the file to a different machine you knew was using a faster link than yourself.

However, with the advances in technology faster links are a lot more common and bandwidth, or lack of bandwidth to be more exact, is not sure a problem anymore. Due to this (and probably due to Nmap) more and more FTP servers disable the File Forwarding feature and some even do not have the feature available at all.

There are still some FTP server on the Internet that can be used for this or if you manage to take over a remote FTP server that supports File Forwarding you could turn it on and use it to commit your terrible Nmap cyber crimes without bringing the forces of good to your own doorstep.

It all works by Nmap sending a request to the FTP server and telling it to send a file to X.X.X.X IP address on port X. If the FTP server comes back and says that it was unable to establish a connection on that port then Nmap will show the port as closed. If the FTP server is able to make a connection on the specified port, it will come back as able to establish a connection but unable to transfer the file – hence Nmap will list the port as open.

The benefits of this are that in so far as the target machine (the one you port scanned) all the connection attempts came from the FTP server. For anyone to find out that it was in fact you port scanning the target machine they would have to find the owner of the FTP server and ask him to look through his logs – and if the admin of the FTP server is slack enough to allow File Forwarding through his FTP server than chances are he may not even keep logs..…

It can be time consuming to find an FTP server that allows File Forwarding but if you do find one be sure to keep the IP Address to yourself to ensure it stays configured that way for as long as possible. If half the world starts using it for FTP Bounce scans pretty soon the admin is going to figure out what is going on and configure it correctly.

To find one, use the “-p” switch, this is a feature of Nmap which I will cover later on that allows you to specify which port you want to scan. Then chose a subnet and scan them all of port 21 (FTP). Once you find some hosts listening on port 21 try and use them to conduct your FTP Bounce scan…..if it works your in luck, if it doesn’t then you will have to keep looking.

Nmap 123.123.123.0-255 –p21 – This will scan all hosts from 123.123.123.0 right through to 123.123.123.255 on port 21 only, looking for a live FTP Server.

Once you have found an FTP server try connecting to it to see if it allows Anonymous logons. (Use the user name ‘anonymous’ and anything for the password). If it does you’re in look and can try an Nmap bounce scan straight away. If it doesn’t allow anonymous logons you can either try and find a valid user name and password with a program such as [url=http://www.hoobie.net/brutus/brutus-download.html]Brutus[/url] or [url=http://hydra.hellug.gr/download.html]Hydra[/url], or move on to another FTP server. I will cover how to use Brutus in a separate paper.

Once you have found either a valid logon for an FTP server or one that allows anonymous logons, use the following command to launch your FTP Bounce scan:

nmap –b username:password@IP_of_FTP_server IP Address to scan

So:

nmap –b nokia:taz@123.123.123.123 80.80.80.80

Would logon to 123.123.123.123 with the user name of nokia, the password of taz and then attempt to port scan 80.80.80.80

The following shows the result of a successful logon to an FTP Server that I use for FTP Bounce scans

[code]
C:\Documents and Settings\Nokia>nmap -v -b nokia:si£u31@X.X.X.X 81.80.80.80
Hint: if your bounce scan target hosts aren't reachable from here, remember to u
se -P0 so we don't try and ping them prior to the scan

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-17 19:11 GMT Stan
dard Time
Resolved ftp bounce attack proxy to X.X.X.X (X.X.X.X).
DNS resolution of 1 IPs took 0.22s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF:
0, TR: 1, CN: 0]
Attempting connection to ftp://nokia:si£u31@X.X.X.X
Connected:220 ProFTPD 1.2.5rc1 Server (*******************0

If Nmap manages to successfully logon to an FTP server but you receive the following:

“Your ftp bounce server doesn’t allow privileged ports, skipping them.”

It means the FTP server is configured to not send anything to ports 0-1024 less for port 20 & 21 – this was an early way of preventing such things as Nmap from connecting to ‘well known’ ports except for 20 & 21 – which is mostly the only ports it will need to connect too to send a file.

If your FTP Bounce server does not allow it to act as a proxy at all, eventually you will get the message:

[quote]
Your ftp bounce server sucks, it won’t let us feed bogus ports!
[/quote]

You may find more false positives with this type of scan than any other for obvious reasons, so you should try and verify your results with another type of scan if possible.

The mort astute of you and those that think for themselves rather than blindly following a tutorial may have realised another use for this type of scan.

The FTP server will more than likely be sitting on a LAN with a fully routable internet IP address…….if we can find out the IP range in use on the internal LAN we can use this method to port scan internal hosts by specifying an internal IP at the end of the Nmap command, or even try scanning 127.0.0.1 (localhost A.K.A itself). If you find port 80, 25 etc open the odds are that this could be acting as an FTP, Web and Mail server – even though the external IP addresses maybe different for these three services a firewall can translate them all to the same internal host.

This method could be used as a long-winded ping seep method also – if you can find out the internal IP range in use you can try a port scan each host in that range and see what positives you get back. If you get a positive back the host must be alive so you have the IP address of a valid internal machine. The FTP server will usually be on a DMZ so theoretically you can find the internal hosts of the DMZ, work out what ports are open and try and tie these in with the external IP’s in use. As mentioned in the previous paragraph if port 25 is open on an internal host you know there is a mail server – if you have taken the time to [url=http://www.tazforum.thetazzone.com/viewtopic.php?t=5445]conduct a reconnaissance[/url] then you will know the external IP for the mail server….chances are you have just found the internal IP of it.

A lot of people write-off FTP bounce scans as being dated and useless in today’s world, yet I do occasionally come across susceptible servers during Pen testing and they can be a very good path into a network and help you understand the topology better. If you happen to stumble upon a susceptible public FTP server, be sure to keep it as quiet as possible…..

[quote]Due to post size limits I have had to split this paper into two halves. Please find the second half here:
http://tazforum.thetazzone.com/viewtopic.php?t=5766

Additionally if you liked this article, please Digg it [url=http://digg.com/security/2007_A_Hacking_Odyssey_Part_2_Network_Scanning_Nmap]here[/url][/quote]

2007 A Hacking Odessey Part 2 – Continued

admin — Mon, 01 Jun 2009 23:02:19 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

[img]http://www.tazforum.com/images/TAZBANNERab.gif[/img]

[quote]I had to split this paper in to two parts due to post size limits; please find the first half of this paper here:
http://tazforum.thetazzone.com/viewtopic.php?t=5764[/quote]
[b]9) Idle Scanning -sI[/b]

Idle scanning is perhaps a more realistic way of obscuring your real location on the www. Although FTP bounce scans will work, there are a lot of variables that have to fall into place. Wouldn’t it be better if we could use something that does not require logon details? Well, luckily for us there is a way we can use another host to bounce our probes off without anyone knowing we are doing it.

A little knowledge of TCP and IP is needed to totally understand how an Idle Scan works; if you are not too familiar with these protocols I would suggest you read [url=http://tazforum.thetazzone.com/viewtopic.php?t=473]THIS[/url] to allow you to follow the following few paragraphs more closely.

Part of an IP header includes the IP ID. This is used in case any fragmentation occurs whilst this packet is on its travels around the LAN/Internet.
For example; say you send an email, following the rules of OSI this will go through all the various layers until it ends up as a frame and ready to be place on the Ethernet cables as voltages and sent to wherever it is destined for.

During its trip down the OSI model it will pass the IP part of the Network layer – here, amongst other things, if will be assigned a unique identifier called the IP ID. We will say our email fits into on packet and this packet is assigned the IP ID of 3333.

This packet becomes a frame when it reaches layer 2, and it converted to bits and sent on to the actual cable at layer one.

On its travels it bumps into a router. This router decides that the packet is too big to be routed and sent any further, so decided to fragment the packet in to two parts and send it on its way.

Now, without the IP ID, when the receiving station received these two packets it would have absolutely no way to tell that they were originally part of the same packet and hence the same email, resulting in your email not being delivered.

What would have happened (in layman’s terms) is when the router decided to fragment the packet it will have added one to the IP ID, so IP ID + 1. The IP ID was 3333 for our packet, so the router will have left the first packets IP ID as 3333 but will have incremented the other packets to 3333-1, if it had fragmented it into three the thirds IP ID will be 3333-2 on so on.

Now when the packet arrives at the receiving host it looks at the IP ID, sees that the two packets have the same IP ID, looks for the incremented on (3333-1) and reconstructs the packet – sends it on its way up the OSI resulting in the email being displayed on your screen.

** It is a bit more complicated than this as things like Fragment Offsets are used – the ‘-1’ is not literally added to the IP ID but you get the general idea**

But how does all this help us scan a target?

As I mentioned, the IP ID is a unique identifier to that packet and as such the next packet the host sends must have a new IP ID. Windows, FreeBSD and some Linux boxes all increment the IP ID by a set variable for each packet. So after sending our email with the IP ID of 3333, if the set variable was one, our next email will have the IP ID of 3334, etc. (For the remainder of this chapter we will say it increments by one)

As we know from the previous chapters, if a SYN packet arrives out of the blue then the receiving host will presume that someone wants to open a TCP connection to it and will respond with a SYN|ACK. However if a SYN|ACK arrives out of the blue then a RST packet is sent back to the initiating host. Finally, if a RST packet arrives out of the blue then the packet is to be dropped and nothing is to be returned. – remember this!

If we were to spoof the source IP address of our probe and send a SYN packet to our target, following the above reasoning the target would have to send a SYN|ACK packet back to whatever the IP address is we spoofed in the probe. Obviously our spoofed host did not send the initial SYN packet in the first place, so will be forced to respond with to the unsolicited SYN|ACK packet with a RST packet.

Again following the above mentioned rules, if we send a SYN packet to our target with a spoofed source IP address but the port is closed, then the target will send a RST packet back to our unsuspecting host – however as a RST packet required no further action our spoofed host will not need to send any packets back to the target machine.

Some of you may have already worked out how we can abuse these rules of TCP and make them work to our advantage.

If we send a SYN|ACK packet to the host we want to use as a zombie (the IP address we are going to spoof), when it replies with a RST packet we are able to see the IP ID it uses. If we then send another SYN|ACK packet, the zombie will again reply to it and we will see the new IP ID – simple maths will tell us by how much it has incremented. We can carry on doing this until we are positive we have worked out how much it will increment by.

[quote]
192.168.5.10 –> 192.168.5.15 TCP; D=80 S=59242 SYN ACK=9995679210 SEQ=153927672 LEN=0 WIN=3042
192.168.5.15 –> 192.168.5.10 TCP; D=59242 S=80 RST WIN=0 [b]ID=4532[/b]

192.168.5.10 –> 192.168.5.15 TCP; D=80 S=61347 SYN ACK=9995679210 SEQ=153927495 LEN=0 WIN=3042
192.168.5.15 –> 192.168.5.10 TCP; D=61347 S=80 RST WIN=0 [b]ID=4533[/b]
[/quote]

If you look at the above [edited] output you can see that 192.168.5.10 sent a packet to 192.168.5.15, the packet was [b]TCP[/b] the [b]d[/b]estination port was [b]80[/b], the [b]s[/b]ource port was [b]59242[/b], it was a [b]SYN ACK[/b] packet with a [b]seq[/b]uence number of [b]153927672[/b]

Then as we know a RST packet should be sent in reply to an unsolicited SYN|ACK.

192.168.5.15 sent a packet to 192.168.5.10 which was [b]TCP[/b] [b]d[/b]estined to port [b]59242[/b] with a [b]s[/b]ource port of [b]80[/b], it was a [b]RST[/b] packet and had the [b]IP ID of 4532[/b]

The second trace shows the same types of packets but note that the IP ID has gone up by one. We do this as many times as is necessary to determine that a) the host is idle and b) we are sure what the IP ID is incremented by.

If the IP ID shows no set pattern and increments by a seemingly random amount each time, then chances are the host is not idle – Nmap will very helpfully tell us if this happens.

So, after working out that our zombie host is indeed idle and that the IP ID is incrementing by one each time we probe it; we then send a SYN packet to out TARGET but with source IP of our ZOMBIE – the target responds to the SYN request with a SYN|ACK and send this to our zombie, the zombie receiving this SYN|ACK out of the blue will respond with a RST packet – therefore increasing its IP ID by one. If we now send a SYN|ACK to our zombie the RST packet the is sent by way or a reply to us will have an IP ID +2 from when we last probed it as it has just sent a RST packet to our target.

If the port on our target is closed it will send a RST packet to our zombie and as we know the zombie will not reply to that RST packet, so when we probe it again the IP ID will increase by +1 and not +2.

[u] Learn the IP ID[/u]
[code]
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1000) <---<---<-+ +
+++++++++++++ ++++++++++++++

+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1001 <---<---<--+ +
+++++++++++++ ++++++++++++++

+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1002) <---<---<-+ +
+++++++++++++ ++++++++++++++
[/code]

[u]If the port is open[/u]

Once we have learnt the IP ID and that it increments by one, we can launch our Idle Scan against the target.

[code]
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->->SYN(Fake source IP 192.168.5.10)->->+ Target +
+192.168.1.1+ +192.168.5.15+
+ + + +
+++++++++++++ ++++++++++++++
Step 2 SYN|ACK | |
To spoofed IP SYN ^
Responding to ACK |
Our SYN packet | RST---
| | |
++++++++++++++ |
+ + |
+ Zombie + |
+192.168.5.10+ |
+ + |
++++++++++++++ |
|
|---------------------------
Step 3 RST
The Zombie responds to the SYN|ACK with a RST, thereby increasing its IP ID by one. If we now send a SYN|ACK direct to the Zombie we can look at the IP ID and see if it has been incremented or not. If it has incremented a RST must have been sent, indicating the port on the target is open.

[/code]

Now we probe out zombie to learn the IP ID:

[code]
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1004) <---<---<-+ +
+++++++++++++ ++++++++++++++
[/code]

We left the IP ID at 1002, it is now 1004 which indicates that a packet has been sent in response to our probe directed towards out target. This tells Nmap that a SYN|ACK came from the target to the zombie and that the port is open.

[u]If the port is closed[/u]

[code]
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->->SYN(Fake source IP 192.168.5.10)->->+ Target +
+192.168.1.1+ +192.168.5.15+
+ + + +
+++++++++++++ ++++++++++++++
Step 2 RST |
To spoofed IP RST
Responding to |
our SYN packet |
as the port is |
closed ++++++++++++++
+ +
+ Zombie +
+192.168.5.10+
+ +
-------------------------------- ++++++++++++++
As we know nothing is sent in response to an unsolicited RST packet therefore our Zombie does not reply and the IP ID does not increment by one.

+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1003) <---<---<-+ +
+++++++++++++ ++++++++++++++
[/code]

We left the IP ID at 1002, as it is now 1003 we know that it could not have possibly replied to the target host indicating a RST packet was sent to the zombie in response to our SYN packet. This tells Nmap that the port was closed and it will report it to you as such.

**If you do not tell Nmap to not ping the host (-P0, covered later) then it will first send an ICMP request to the host from [i]your real IP address[/i]. So consider using the –P0 option, however Nmap does use ICMP to determine scan speeds etc so it may lead to more unreliable results**

You should be able to better understand why the host has to be idle for this scan to work; if it is not we will not be able to tell the IP ID incremented due to our probe to the target machine or due to normal traffic.

There are more uses for this type of scan, or to log the IP ID of a host to be more exact as it can be used to gauge how busy the client is, if there is a cluster of nodes using a virtual IP; in fact Fyodor posts an example of this on his site using hping:

[quote]
# hping2 -c 10 -i 1 -p 80 -S beta.search.microsoft.com.
HPING beta.search.microsoft.com. (eth0 207.46.197.115): S set, 40 headers + 0 data bytes
46 bytes from 207.46.197.115: flags=SA seq=0 ttl=56 id=57645 win=16616 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=1 ttl=56 id=57650 win=16616 rtt=21.4 ms
46 bytes from 207.46.197.115: flags=RA seq=2 ttl=56 id=18574 win=0 rtt=21.3 ms
46 bytes from 207.46.197.115: flags=RA seq=3 ttl=56 id=18587 win=0 rtt=21.1 ms
46 bytes from 207.46.197.115: flags=RA seq=4 ttl=56 id=18588 win=0 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=5 ttl=56 id=57741 win=16616 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=RA seq=6 ttl=56 id=18589 win=0 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=7 ttl=56 id=57742 win=16616 rtt=21.7 ms
46 bytes from 207.46.197.115: flags=SA seq=8 ttl=56 id=57743 win=16616 rtt=21.6 ms
46 bytes from 207.46.197.115: flags=SA seq=9 ttl=56 id=57744 win=16616 rtt=21.3 ms
[/quote]

As you can see for the [IP] ID there are obviously two different hosts sitting on that particular IP.

Idle scanning can also be used to test out firewall rules that only allow access from certain IP addresses. Obviously you will need to find out what the allowed IP address is. If you scan a target that is located behind a firewall that is only allowing packets from a certain IP address to reach it, your probes will all be dropped (Nmap will show them as filtered), however if you spoof the source IP to an allowed one your probes will get through and you can check the host who does actually have the real IP you spoofed to see if the IP ID is incrementing or not.

There are a lot of variables that need to be known and fall into place to allow the above to happen, but nonetheless it is possible.

IP ID detection is also used in OS detection too, as certain OS’s increment it by certain amounts.

The syntax for an idle scan is: namp –sI zombie IP > Target IP

Nmap –sI 192.168.5.10 192.168.5.15

[b]10) Window Scan –sW[/b]

If you take a closer look at the above trace outputs and the descriptions I gave of each field you may notice I didn’t describe what the WIN=xxxx field is for. This is because I wanted to talk about it here instead.

[quote]
192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0 [b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST [b]WIN=0 [/b]ID=5324

192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0 [b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=61513 S=23 RST [b]WIN=0[/b] ID=5325
[/quote]

As we all know TCP is a stateful connection with error checking. The error checking part of this means that both parties involved need to verify that what has been sent is actually what is received.

To ensure complete error checking not only do the individual packets needs to be checked but the amount of packets sent needs to be checked also. It’s no use having a method of checking that packets are intact, if you can’t check you have received all of them in the first place.

TCP packets included a Cyclic Redundancy Check (CRC) commonly referred to as a Checksum which pertains to the integrity of the packet. This is a mathematical algorithm that is derived by the size of the TCP packet – this produces a result which is added to the tail end of the TCP header. When the receiving station receives the TCP packet it will put it through the exact same mathematical algorithm that the sending station used and compare the result with the number in the checksum field. If the data has been altered even minutely the checksum result will be wildly different and a request for the retransmission of the packet is sent.

That takes care of the individual packets, but does not provide anyway of checking if all of the packets have been received. Obviously if we don’t get all of the data the CRC checks will still be valid but the data will be useless to us.

For this reason another option in the TCP header that needs to be set is the Window size (nothing to do with the Windows OS). This Window size tells the sending station how much data to send, before it will need an acknowledgment from the receiving station, or to be more exact how much unacknowledged data can be in the connection flow.

So, say during the initial three-way handshake the window size is set to 64KB. The sending station will send 64KB of data and then stop. It will now wait for an acknowledgment to come from the receiving station to say how much data is has received. If it comes back saying it has received 64KB then all is well and the traffic flow commences for another 64KB. If it comes back saying it has only received 32KB then something has gone wrong and some data needs to be resent – as there is still the 64KB limit for unacknowledged traffic to be sent in the connection the sending station can only send another 32KB until an acknowledgement is needed (the receiving host has only acknowledged 32KB of it, so if any data exceeding 32KB is sent then there will be a violation of the initial 64KB limit that was established)

You may be thinking, that’s very nice but how do this help us port scan a remote host though?

Well, if you study the trace even [i]more[/i] closely you will see a sort of pattern that the different packets follow:

[code]
192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0 [b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST [b]WIN=0 [/b]ID=5324

192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0 [b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=61513 S=23 RST [b]WIN=0[/b] ID=5325
[/code]

See if you can work it out with before reading on……

The WIN sizes of the RST packets are all ‘0’. Why would this be?

As we know from our ACK scan, if an ACK comes in to a port then a RST is sent back regardless of if the port is open or closed, BUT if the port does happen to be closed then no further communications can occur on that port anyway, so why send back a value telling the initiating host how much data it can send before it needs an acknowledgment if the port is closed? There is no need to do this, so the WIN size is 0 on a RST packet from a closed port in response to an ACK. Also, as there is no service sitting behind the port to set the WIN size the default will also be 0.

This tells Nmap that the port is closed.

If the port is open then yes a RST packet is still sent in response to an unsolicited ACK packet, however as there is a service sitting on that port to set the WIN size and further communication is possible, then the WIN size may be set to a non-zero value:

[quote]
192.168.5.10 --> 192.168.5.15 TCP; D=80 S=51876 ACK=0 LEN=0 [b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=51876 S=80 RST [b]WIN=4096 [/b]ID=5378

192.168.5.10 --> 192.168.5.15 TCP; D=8080 S=64281 ACK=0 SEQ LEN=0 [b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=64281 S=8080 RST [b]WIN=4096[/b] ID=5379
[/quote]

So, although a RST is still sent back, there WIN size is 4096 and Nmap will inform us that the port is open.

This method is very similar to the ACK scan mentioned earlier, however as we know the ACK scan can’t determine open or closed ports (as a RST is sent by both) and is mainly used for packet filtering auditing, whereas the WIN scan can make an informed guess by looking at the WIN size to see if the port is open or not.

If you are able to put yourself in front of a host in such a way that you can sniff the traffic going to it, you could use this method to port scan a target with a spoofed IP address that is maybe behind a packet filtering device.

If you sent an ACK scan to a host on a DMZ (behind a packet filtering device) with a spoofed source IP, the responses would go back to the host with the IP you have spoofed. By looking at these responses via sniffing, you will be able to determine if the packets got through to the DMZ host and if the port is open – just by looking at the WIN size of the packet, and of course all logs lead back to the host whose IP you spoofed. The host does not have to be idle either.

Of course this will also work for normal port scans via a spoofed IP as you will be able to see all the responses going back to the host with the real IP – as you have absolutely nothing to do with this host and have never sent a single packet to it, then this is truly an anonymous method of scanning with endless variants on port scanning techniques.

Sadly once again Nmap becomes a victim of its own success. Since there are literally hundreds of papers out there detailing how the various Nmap scans work, it was relatively simple for manufactures to make the RST packet from a closed port include a non-zero WIN value, which in effect ‘breaks’ this type of scan.

That being said, there are still a large number of un-patched/legacy machines out there that are susceptible to this type of scan.

The syntax for a Window scan is: nmap –sW ip address

Nmap –sW 80.80.80.80

[b]11) Maimon scan –sM[/b]

Lastly for those who want to scan BSD boxes the Maimon scan may come in useful.

Uriel Maimon discovered that sending a FIN/ACK probe to a BSD box resulted in the probe being dropped if the port was open, and a RST being returned by a closed port, whereas non BSD boxed would return a RST regardless of the port state.

The syntax for this scan is: nmap –sM ip address

Nmap –sM 80.80.80.80

That covers all available ‘type of scan’ available to Nmap users when scaning TCP ports, there are a lot of options to use in conjunction with these scan types which I will cover shortly after I have explained UDP scanning.

[u][b]12)UDP Scanning[/b][/u]

Due to the nature of User Datagram Protocol (UDP) and its connectionless method of data transmission it is very hard to reliably scan the UDP stack of ports.

We already know that a TCP session requires a three-way handshake, ergo if we send a SYN packet we will get a SYN|ACK back from an open port.

UDP does not have anything in its rules to say it has got to send a single thing back in response to a packet arriving at an open port.

If we send a packet to a closed port we may get an ICMP type 3 code 3 reply – port unreachable. If this happened Nmap will inform us that the port is closed.

If any other ICMP type 3 messages are returned such as Host unreachable (code 1), Protocol unreachable (type 2) etc then Nmap will mark the port down as filtered – meaning something is receiving the probes but it may not be the interned target, i.e. it may be a packet filter of some kind, hence Nmap can’t say if the port is open or closed.

If no reply is received from the probe then the port is displayed as open|filtered which means that Nmap was unable to confirm the port was definitely closed hence could be open or be behind a packet filter of some kind.

As you can see due to the unreliable nature of UDP port scanning via empty USP datagram’s is a fairly unreliable method to use.

It is usually the service that replies on a UDP port – take port 53 for example which is the DNS port. If you send an empty UDP probe to it (which is what Nmap will do with the default USP scan) then the DNS server is never going to reply to it – why should it as there are no rules such as those in TCP to say it has to.

However if you conduct a ‘version scan’ ,which I will cover next, then Nmap will try to connect to the service that listens on the port by default.

So take our DNS service on port 53 for example – Nmap knows DNS uses UDP:53 so by carrying out a version scan Nmap will consult its database, look for a nslookup query and send it out to the target on port 53. If a reply comes back to this DNS query then Nmap will inform you that the port was open.

As you can see, for UDP ports it is the actual service that will reply to Nmap, but to get it to reply we need to give it information it can understand, not just a blank UDP packet. For this reason usually a version scan is conducted in conjunction to the UDP scan.

Timing is another issue with UDP scanning, as most operating systems (especially Linux) will limit the rate that the ICMP type 3 messages can be sent out at. Most set it to one every second but this can be changed manually by the user of the machine. If nmap has to wait one second for every probe on every port and you are scanning all 65,536 ports then you are going to be in for a long wait…….

The syntax for a UDP scan is: nmap –sU ip address

nmap –sU 80.80.80.80

It is possible to conduct a TCP scan and a UDP scan at the same time:

nmap –sT –sU 80.80.80.80

[b][u]Version Scanning[/b][/u]

All of the above is great providing that any services are using the port number they are meant to, i.e. the mail server is listening on port 25 and the FTP server is listening on port 21 etc.

There is however nothing illegal about setting your FTP server to use port 54321 and setting your mail server to use port 60000. In fact some companies do this to certain services and PAT/Port Forward them on to the correct port internally.

[code]
+++++++++++++ ++++++++++
+ + +Firewall+
+ Us +FTP logon request port 54321 + +
+81.81.81.81+--->--->--->--->--->--->-->-->+>--> +
+ + ftp someftpserver.com:54321 + V +
+++++++++++++ + | +
+ V +
+ | +FTP request port 21
+ >-->-->-->-->- ++++++++
++++++++++ + +
+ +
The firewall will take the FTP traffic destined for 54321 + FTP +
and will be configured to Port Forward the request to +Server+
the FTP server on Port 21. To our knowledge the FTP Server + +
is listening at ‘someftpserver.com:54321’. A basic port scan + +
will only tell us that port 54321 is open, it won’t say what ++++++++
is listening behind it, which is where the version scan comes
in handy as we will now know there is an FTP service there.
[/code]

So the old security by obscurity technique, whereby reconfiguring the default ports your service listens on to confuse would be attackers, does not really help anymore.

But how does Nmap know it is an FTP server listen on port 54321?

To accomplish this is does something called Banner Grabbing. To demonstrate Banner Grabbing it is best to show it first hand; so if you open up a command prompt (go to Start > Run > type cmd > press enter, if you don’t know how to do this). You will know have a black command window open.

Type: ftp wu-ftpd.org

[code]
C:\Documents and Settings\Nokia>ftp wu-ftpd.org
[/code]

Once you have successfully connected, you will be greeted with some information:

[code]
Connected to wu-ftpd.org.
220 ftp.wu-ftpd.org FTP server ready.
User (wu-ftpd.org:(none)):
530 Please login with USER and PASS.
[/code]

This information is known as the banner and is what Nmap will grab. Once it has this banner it will compare it to an internal database and look for a match, it will also continue to probe the service to solicit as many responses as possible to enable it to get an accurate result.

If you really want to continue logging in to the FTP server with anonymous credentials, you can do like so:
[code]
ftp> user anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
230-Welcome to the FTP server for the WU-FTPD Development Group
230-
230-This server is the primary distribution site for the WU-FTPD daemon.
230-
230-The pub directory contains the distribution and supporting files.
230-
230-If you are uploading contributions; please place them in the incoming
230-directory and email wuftpd-members@wu-ftpd.org announcing your upload.
230-
230 Guest login ok, access restrictions apply.
ftp>
[/code]

Ok, well this is all well and good but what has it got to do with version scanning? Well although we were able to identify this as an FTP server by trying to connect to it via FTP on the default port, what version FTP server is it using? If we wanted to try and exploit it we will need to know the version to know what vulnerabilities it has.

It may also be of interest to know if there is anything else listening on it, so let’s give it a quick SYN scan:

[code]
C:\Documents and Settings\Nokia>nmap wu-ftpd.org

Starting Nmap 4.20 ( http://insecure.org ) at 2007-02-24 18:39 GMT Standard Time

Interesting ports on 67.66.8.211:
Not shown: 1692 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
26/tcp open unknown
80/tcp open http

Nmap finished: 1 IP address (1 host up) scanned in 334.140 seconds
[/code]

We can see there are FTP, SSH, Mail and Web servers available to connect to. However Nmap only makes this determination by listing what [i]should[/i] be using those ports – if the mail server was listening on port 80, Nmap would still list is as HTTP. We could telnet and SSH to all the different ports and see if any banners are displayed, however an Nmap version scan will be much more productive for us and tell us exactly what services are using these open ports, which is informative if we want to try and exploit these services.

Go and Google “generic mail server exploit”……… Good luck with that….however if you Google ‘remote exploit Exchange 2003 sp1’ you will get a lot of hits, if you Google ‘remote exploit exchange 2003 sp2’, you will get a different set of hits…..knowing the version and patch state is essential to exploiting any service.

Take a look at port 26…..how are we going to exploit that? Well we could nip over to the IANA web site and see what [i]should[/i] be running on port 26:

http://www.iana.org/assignments/port-numbers

[quote]
# 26/tcp Unassigned
# 26/udp Unassigned
[/quote]

Hmmmm, that’s no help…..

So, let’s fire Nmap up and see if that can tell us more information about port 26 and the others, to enable us to narrow our search for an exploit:

[code]
C:\Documents and Settings\Nokia>nmap -sV wu-ftpd.org

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-24 18:03 GMT St
dard Time

Interesting ports on 67.66.8.211:
(The 1669 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
21/tcp open ftp
22/tcp open ssh SSH 1.2.33 (protocol 1.5)
25/tcp open smtp Postfix smtpd
26/tcp open ssh OpenSSH 3.1p1 (protocol 1.99)
80/tcp open http?
[/code]

Good, so now we know it is an SSH service listening on port 26; version OpenSSH 3.1p1 using protocol 1.99 to be exact. A Google search for ‘remote exploit OpenSSH 3.1p1 protocol 1.99’ will help tremendously if you wanted to try and exploit this service.

So now not only do we know what type of service is listening on the port, we also know the exact version number and patch state of it and can start researching the various vulnerabilities that this service suffers from.

We can see what version Mail Server is on port 23 and that there is a different SSH deamon listening on port 22.

However, we didn’t get lucky with the FTP and Web server this time as the second part of Nmap’s output shows us:

[code]
2 services unrecognized despite returning data. If you know the service/version
please submit the following fingerprints at http://www.insecure.org/cgi-bin/s
vicefp-submit.cgi :
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port21-TCP:V=4.03%I=7%D=2/24%Time=45E07F1C%P=i686-pc-windows-windows%r(
SF:GenericLines,27,"220\x20ftp\.wu-ftpd\.org\x20FTP\x20server\x20ready\.\r
SF:\n")%r(Help,4D,"220\x20ftp\.wu-ftpd\.org\x20FTP\x20server\x20ready\.\r\
SF:n530\x20Please\x20login\x20with\x20USER\x20and\x20PASS\.\r\n");
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port80-TCP:V=4.03%I=7%D=2/24%Time=45E07F18%P=i686-pc-windows-windows%r(
SF:GetRequest,FB8,"HTTP/1\.1\x20200\x20OK\r\nDate:\x20Sat,\x2024\x20Feb\x2
SF:02007\x2017:20:17\x20GMT\r\nServer:\x20Froglegs/104\.75\x20$Unix$\r\n
SF:Last-Modified:\x20Thu,\x2022\x20Jan\x202004\x2012:51:39\x20GMT\r\nETag:
SF:\x20\"3b034b-ebd-400fc75b\"\r\nAccept-Ranges:\x20bytes\r\nContent-Lengt
SF:h:\x203773\r\nConnection:\x20close\r\nContent-Type:\x20text/html\r\n\r\
SF:n SF:/EN\">\r\n\r\n\x20\r\n\x20\x20WU-FTPD\x20Development<br /> SF:\x20Group\r\n\x20\r\n\r\n\x20 SF:NK=\"#0000FF\"\x20VLINK=\"#000080\"\x20ALINK=\"#FF0000\">\r\n\x20\x20 SF:1\x20ALIGN=\"CENTER\">\r\n\x20\x20\x20WU-FTPD\x20Development\x20Group\r
SF:\n\x20\x20

\r\n\r\n

\r\n
\r\n\x20\x20
\r
SF:\nSECURITY\x20VULNERABILITY\x20DISCOVERED!\r\
SF:n
\r\nA\x20vulnerability\x20has\x20been\x20found\x20in\x20the
SF:\x20current\x20versions\x20of\x20WU-FTPD\x20up\x20to\x202\.6\.2\.\x20\r
SF:\nInformation\x20describing\x20the\x20vulnerability\x20is\x20available\
SF:x20from\r\n
\r\n
SF:0,"HTTP/1\.1\x20200\x20OK\r\nDate:\x20Sat,\x2024\x20Feb\x202007\x2017:2
SF:0:17\x20GMT\r\nServer:\x20Froglegs/104\.75\x20$Unix$\r\nContent-Lengt
SF:h:\x200\r\nAllow:\x20GET,\x20HEAD,\x20OPTIONS,\x20TRACE\r\nConnection:\
SF:x20close\r\n\r\n")%r(RTSPRequest,1CC,"HTTP/1\.1\x20400\x20Bad\x20Reques
SF:t\r\nDate:\x20Sat,\x2024\x20Feb\x202007\x2017:20:18\x20GMT\r\nServer:\x
SF:20Froglegs/104\.75\x20$Unix$\r\nConnection:\x20close\r\nContent-Type:
SF:\x20text/html;\x20charset=iso-8859-1\r\n\r\n SF:\x20\"-//IETF//DTD\x20HTML\x202\.0//EN\">\n\n400\x20<br /> SF:Bad\x20Request\n\n
Bad\x20Request
\nYour\x2
SF:0browser\x20sent\x20a\x20request\x20that\x20this\x20server\x20could\x20
SF:not\x20understand\.
\nThe\x20request\x20line\x20contained\x20invalid\
SF:x20characters\x20following\x20the\x20protocol\x20string\.
\n
\n SF:DY>\n");
[/code]

Here is your change to help Nmap’s usefulness with regard to version scanning. It very kindly asks us to go to a URL and submit the fingerprint we received.

The nmap-service-probe file which can be found in your install directory holds all the fingerprints that Nmap can currently use to compare banners and probe responses against. This was last updated on 10th Jan 07 (version 4.21ALPHA2) and is updated on a regular basis only because its users submit fingerprints to be included in it.

The more fingerprints is has, the more reliable it will become. So if you know what the service is, pop along to http://www.insecure.org/cgi-bin/servicefp-submit.cgi and submit your fingerprints that Nmap does not recognise. C+P everything that has an SF: at the beginning of the line.

Likewise if you think that something is being reported wrongly and want to tell the Nmap developers about it, then a URL is provided for this also:

[code]
Service detection performed. Please report any incorrect results at http://insec
ure.org/nmap/submit/ .
Nmap finished: 1 IP address (1 host up) scanned in 192.594 seconds
[/code]

I included the FTP service in this paper to inform of the fingerprint submission page and to encourage you to do it and also to demonstrate the fact that you should not rely on the one tool to do everything for you. Nmap is good but it is not perfect, if it returns a null value for something like a version scan then you can always telnet in to the port and take a look for yourself – Nmap just automates this procedure but may sometimes provide more information then we can get manually due to the large database it has.

Our main lesson here was port 26 – nmap was able to inform us of the service and version of that service to allow us to progress with our assessment/attack further….SSH using a non default port…

This can also be used for the power of good and enable Sys Admins to determine versions of services and their patch state on an internal LAN in a relatively small amount of time.

The final thing to say is that it is always a good idea to include this with a UDP scan to improve the reliability of UDP results.

The syntax for this scan is: nmap –sV ip address

nmap –sV 80.80.80.80

[b][u]Ping Sweeps[/b][/u]

A lot of people don’t understand Nmap’s full potential when it comes to ‘ping’. Typically a ping refers to an ICMP echo request being sent to a host and an ICMP echo reply being sent back to the initiating host. For the majority of people this is enough to determine if a host is up or down.

However, it is considered good security practise in today’s world to block most ICMP types from entering a network – take a PIX firewall for example, by default it will block every ICMP type from coming in to the network it is protecting – so an internal users can send the ICMP echo request out to the Internet but the reply will never get back in, resulting in a **timed out** being displayed to the user.

This can really mess Nmap up if using the default scan options as the first thing it will do is try and ping the host – if no reply is received the scan will be aborted.

To overcome this obstacle we can simply use the –P0 switch in our command, which will tell Nmap to not ping the host we are scanning; a fact which Nmap will helpfully inform us of:

[code]
C:\Documents and Settings\Nokia>nmap -sT 80.80.80.80

Starting Nmap 4.20 ( http://insecure.org ) at 2007-02-25 13:55 GMT Standard Time

Note: Host seems down. If it is really up, but blocking our ping probes, try -P0

Nmap finished: 1 IP address (0 hosts up) scanned in 3.937 seconds
[/code]

With the –P0 option:

[code]
C:\Documents and Settings\Nokia>nmap -P0 -sT 80.80.80.80

Starting Nmap 4.20 ( http://insecure.org ) at 2007-02-25 13:55 GMT Standard Time

Stats: 0:03:16 elapsed; 0 hosts completed (1 up), 1 undergoing Connect() Scan
Connect() Scan Timing: About 72.66% done; ETC: 14:00 (0:01:13 remaining)
Interesting ports on 80.80.80.80:
Not shown: 1696 filtered ports
PORT STATE SERVICE
80/tcp open http

Nmap finished: 1 IP address (1 host up) scanned in 253.344 seconds
[/code]

So either the host is sting behind a firewall of some kind that is blocking ICMP or the host itself is ignoring our ICMP packets.

(Try an ACK scan to see if you can determine if it is behind a packet filter or maybe a stateful firewall, and maybe what it will allow through it)

Nmap does you ICMP response times to judge the speed of its scan, so you may run in to timing issues if you use the –P0 switch.

If you are using the Idle Scan option or spoofing your IP address it is a good idea to use the -P0 option as Nmap will use your real IP address to ping the host before starting the scan – it can’t use the spoofed IP address as it needs to receive the ICMP echo request back.

However, as mentioned Nmap does not always think of ping in the typical ICMP way but we may still need to ping a host that is behind a firewall which is blocking all ICMP types. How can we do this?

Nmap includes a range of non ICMP pings:

Nmap can determine if a host is alive and the latency to that host be sending a variety of TCP packets with different flags set, to a specific port; known as a TCP ping.

[b]TCP ACK:[/b]

In the same way the TCP ACK scan works, Nmap can send a TCP packet to a specific port on a host with the ACK bit set. Just like the ACK scan if a RST packet is returned Nmap will deem the host to be alive, if not RST is received Nmap deems the host to either be ‘dead’ or that the packets where filtered.

So even though ICMP may be blocked we could ping it with a TCP packet instead.

Do not think of this as a port scan as it is not; its sole aim is to detect if a host is alive behind a given IP address that may have ICMP filtering active.

The syntax for it is PA :

nmap 80.80.80.80 –PA25

You can still specify a normal scan option too if you so desire:

nmap –sT 80.80.80.80 –PA25

If you want to ping multiple port simply separate them with a comma.

To prove it works, consider the following output:

[code]
C:\Documents and Settings\Nokia>ping 87.237.61.100

Pinging 87.237.61.100 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 87.237.61.100:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
[/code]

So something is blocking ICMP from reaching that host; lets try the TCP ACK Ping:

[code]
C:\Documents and Settings\Nokia>nmap 81.80.80.34 -PA80

Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-02 20:18 GMT Standard Time

Stats: 0:00:01 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 1.41% done; ETC: 20:18 (0:00:28 remaining)
[/code]

By pressing the space bar we can get Nmap to give us some information to tell us what stage it is at. Notice the ‘0 hosts completed (1 up)’ part – Nmap has successfully pinged the host with a non ICMP packet. ‘(1 up)’.

[b]TCP SYN Ping:[/b]

The TCP SYN Ping is exactly the same as a TCP ACK Ping, except is uses a SYN packet instead of an ACK packet. Stateful firewalls with usually filter out unsolicited ACK packets, hence a TCP ACK Ping may fail. To overcome this we can ping a host on a well known port that we thing may have a chance of getting through a firewall – usually ports 80 and 25.

We will send a SYN packet to make the firewall think we want to establish a valid connection to the service that is listening on that port.

The syntax is:

Nmap -PS
Again separate multiple port numbers with a comma.

[b]UDP Ping:[/b]

A UDP ping works in conjunction with ICMP and relies on an ICMP Port Unreachable message to be retuned by the host if a UDP packet is sent to a closed port.

For this reason you should try and ping a port that has a good chance of not being open, as open UDP ports may drop a packet completely that it does not understand (See UDP port scanning, above, for a more detailed description)

The syntax for a USP ping is:

Nmap -PU
Again, separate the port numbers with a comma if you want to scan multiple ports.

UDP Pinging is an inherently unreliable ping due to it relying heavily on ICMP packets, which as we know are usually filtered out.

ICMP Mask and Tine-Stamp pings:

There are two rather antiquated pings that Nmap still supports called an ICMP Time-Stamp ping and an ICMP Mask ping.

I would strenuously suggest staying away from both of these as, a) the chances of them working are very remote, and b) they stand out like a MAC at a Defcon meeting to someone analysing the packets flowing through a network.

A timestamp request is a prehistoric method for two hosts to synchronize their clocks – now-a-days NTP is the preferred method. There is a small plus to using this method and that is if it works you have a very good chance of successfully attacking the network as anyone who allows there packets to traverse layer 3 devices probably does not understand their job to well.

An ICMP Mask Ping is an ICMP query to a host asking it for it’s subnet mask. If this works then just like the timestamp request the chances of the network not being secured properly are very high, or the OS patching state is not very recent or even that they are using legacy infrastructure hardware on the network.

They syntax for the timestamp request is:

nmap -PP

And the syntax for the Mask Ping is:

nmap -PM

I think this is waaay getting two long now, so will end Part two here.

In Part three I will cover further basic Nmap options, Nmap timing options, OS fingerprinting, real world examples of using all the options and some not so well known tips and tricks for using Nmap.

[quote]I had to split this paper in to two parts due to post size limits; please find the first half of this paper here:
http://tazforum.thetazzone.com/viewtopic.php?t=5764

Additionally if you liked this tutorial then please Digg it [url=http://digg.com/security/2007_A_Hacking_Odyssey_Part_2_Continued]here[/url][/quote]

Tutorial: How to hijack a college library that is firewalled

admin — Sun, 29 Mar 2009 13:41:18 +0000

ORIGINALLY POSTED BY VORLIN FOR THETAZZONE/TAZFORUM HERE

This tutorial is presented as an educational feature on security, neither TheTAZZone nor the author recommends that you use this tutorial for any other purpose than education.

This will cover two things: how to bypass a college library firewall and how to install things so you can run them when the college library computers won’t let you install jack sh*t due to permissions.

So, I’m in the library at college and they only allow you to get to about 4 sites, all related either to the library or the college itself. Well, me being the innovative guy that I am, decided to get around this. Anyone who tells me I can’t do something, well, unless it’s literally impossible, I’m GOING to do it. I can’t tell you how many hot chicks have talked to me (like right now as I write this) after I’ve helped them get ‘around’ things like annoying firewalls, etc.

Firewall:
We’re allowed usb drives, hell, everyone’s got one, so…go download the Putty client. This will allow you to have multiple options for connections like ssh, serial, telnet, etc. Keep in mind, you have to have access either to a telnet server or an ssh server. I run sshd on my home server so it works for me and I’ll be using the setup for that to show how I get outside the college and into my server and then into the mud that I play on (multi-user dungeon).

Since putty comes in a binary .exe already and doesn’t need installing, just put that on your flash/usb drive and you’re good to go. All the computers in here have 2 usb ports so use that to start the program which promptly runs and just put in the server dns name (or IP if you really want to) and the type of connection (mine is ssh since telnet is shut off and that’d be one hell of a long a$$ serial cable if I checked that) then hit connect and you’re in. Since ssh is being used, you’ll have a popup to accept the key which you do, and then you can do what you want from the prompt. Right now, I have about 4 putty windows open, 1 mud, 3 for code/etc.

Similar aspect for installing progs…just install the program you want onto your flash/usb drive and you’ll be able to run it and do what you want. My example is that I installed Winamp on my usb drive because it can play the extensions from di.fm that Windows media player can’t (Windows media player is so gay, I’ll say it, because it can’t play half the stuff I want it to yet it brags about being so good and how much it can do….yeah right, ONLY IF IT’S WINDOWS-BASED SURE). I installed Winamp on the usb drive, started it up by clicky clicky on the techno music I wanted to listen to, it started right up, and that’s that. Nobody’s the wiser because once my ssh windows are up and winamp’s running, I removed the drive (they’re all loaded in memory) and it looks like I’m just putzing around on the internet. That hot chick next to me just told all her friends and now I’m getting crowded (I DON’T MIND!!!) but in about five minutes, they’ll all be out on the net.

Oh yeah, one other thing you can do in this setup here at the library…they didn’t block google so you can use google to redirect to myspace.com or livejournal.com or whatever. I used that to go to aol.com to get aim mobile going HAHA.

And that’s that…

–Vorlin

EDIT ADD: One thing to remember…once you load all the programs from your usb drive and then remove the drive, if you try to change say, the putty settings, it’ll fail and abort that session because it can’t read from the originating place and you’ll have to start all over (which takes all of 10 seconds just about).

EDIT ADD 2: Cancel the above in regards to putty. If you remove the drive, all your sessions will go inactive and you can’t do jack. Winamp works just fine as long as the stream doesn’t die out. Either way, it’s probably a good idea to keep the usb drive in so you don’t have to worry about anything. Nobody’ll care anyways.

Tutorial – Web Exploits – Don’t be a victim

admin — Fri, 27 Mar 2009 21:53:45 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

[code]This excellent tutorial is the work of NTSA, who has very kindly consented to the TAZ hosting it.

Enjoy!
[/code]

[u][b]Web Exploits – Don’t be a victim [/b][/u]

Overview

There are three things to remeber about web programming security that you have to bear in mind when designing your applications. These are, respectively, validation, validation and validation. The first thing a cracker will do to your site is to see where it breaks.

(note: Cracker is the correct use of the term here. Hackers build things, crackers break things)

[quote]Most real hackers think that crackers are lazy, irresponsible and not very bright and object that being able to break security no more makes you a hacker that being able to hotwire cars makes you an automotive engineer
Eric Raymond [/quote]

Common exploitative techniques

First Johnny Cracker will browse your site until he finds a script that accepts GET input in the format:

[code]scriptname.ext?parameter=value[/code]

More experienced crackers will also be able to use the same sort of explotative techniques to attack scripts that accept POSTed variables, so don’t assume that POSTing form data will deter a serious cracker (but it might exclude some of the more lame kiddies). For the examples in this tutorial I’m going to stick to basic GETs however.

Next our cracker will play with the URL to see what he can get to break. For example:

[code]scriptname.ext?parameter=[/code]

If our script does not validate that the parameter has been passed then this will likley generate an error. If our code contains an SQL statement that looks like this:

[code]set myRS = cn.execute("select * from pubs where parameter=" & request("parameter"))[/code]

then the cracker will get an error message containing the SQL statement and probably some infomation about the physical location of the script on the server. These are not good things to be giving out to Johnny Cracker.

TIP: In IIS and Apache it is possible to stop the server sending detailed error messages to the client (in IIS this is under application/debugging). Whenever you are not actively debugging your application you should ensure that this option is checked. Otherwise every error message is a bit more information for Johnny Cracker to work with.

Let’s say our cracker is malicious – They now know that we have a table called pubs in our database. They can now rework the URL to include SQL stuffing like this:

[code]scriptname.ext?parameter=1;delete * from pubs[/code]

Bye-bye pubs table. Our code above will assume that everything after the semi-colon is another SQL query and run it with the same permissions that were set up to run the first query. If those permissions were to the master database of an MSSQL database then the cracker now has access to all the stored procedures, including xp_cmdshell to run programs from the command line, xp_sendmail to mail himself the contents of your tables etc.

TIP:Never connect a web script to the master database of a MSSQL server. Never run your web page scripts from an administrative account.

Overcoming these techniques through validation

In both of these instances we could have stopped these attempts with proper validation. For example if we had nested our SQL statement in the following clause:

[code]IF NOT (Len(request("parameter")>0 AND INSTR(LCASE(request("parameter")),"delete") =0) THEN
...Whatever...
END IF[/code]

then our cracker would not have been able to perform either of the above ‘exploits’.

Now re-writting these validation sequences for each of your scripts is a real waste of time and can really get quite tedious. Me personally I prefer to throw each of my validation sequences into a class that I can re-use time and again.

NTSA’s Validation script

Don’t try to copy and paste this script (not least because it’s taken from one of my ActiveX controls and probably won’t run as is in ASP). I am including it in this tutorial only as an example of what YOUR validation class might include – mine is tied into a number of sub classes that I’m not including here (debugging classes, INI file class,etc), but you can get the gist of what I’m doing. This class encapsulates all my validation routines and on completion allows an array of reported errors to be passed back to the calling script for display to the user.

You would call the routines in this class like this:

[code] Dim ers As Boolean
Dim Er As Variant

ers = False

Validate.ClearErrors
If Not Validate.isvalid("number", tInteger, "1") Then ers = True
If Not Validate.isvalid("password", tPassword, "123456") Then ers = True
If Not Validate.isvalid("Date", tDate, "28/3/75") Then ers = True
If Not Validate.isvalid("Email", tEmail, "si@ntsa.org.uk") Then ers = True
If Not Validate.isvalid("Required", tRequired, "sdgv") Then ers = True
If Not Validate.isvalid("NoSpaces", tNoSpaces, "12345") Then ers = True
If Not Validate.isvalid("Message", tNotHTML, "") Then ers = True
If Not Validate.isvalid("SQL Statement", tNotSQL, "select * from sysobjects") Then ers = True
If Not Validate.isvalid("Card Number", tLUHN, "4121111111119") Then ers = True

Validate.BadWordsINI = "c:\badwords.ini"
If Not Validate.isvalid("Message", tNotObscene, "Message") Then ers = True

If ers = True Then
Er = Validate.GetErrors
For n = 0 To MyArrayCls.uboundc(Er)
Debug.Print Er(n, 0) & Er(n, 1)
Next
End If[/code]

The Class file

[code]Enum etType
tInteger = 0
tDate = 1
tEMAIL = 2
tNoSpaces = 3
tRequired = 4
tPassword = 5
tNotObscene = 6
tNotHTML = 7
tNotSQL = 8
tLUHN = 9
End Enum

Dim Errors()
'Default Property Values:
Const m_def_BadWordsINI = ""
'Property Variables:
Dim m_BadWordsINI As String

Private Sub UserControl_Initialize()
UserControl.Height = 250
UserControl.Width = 250
End Sub

Private Sub UserControl_Resize()
UserControl.Height = 250
UserControl.Width = 250
End Sub

Public Function IsValid(tName As String,
tType As etType,
tValue As String) As Boolean

Tron.Trace "Validate", "Evaluating [" & tValue & "] as type " & _
TypeDescription(CInt(tType))

Select Case LCase(Trim(tType))
Case tInteger
If AllowedChars(tValue, "0123456789.") = True Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " is not a valid number."
End If

Case tDate
If IsDate(tValue) Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " is not a valid date"
End If

Case tEMAIL
If Strings.CountInString(tValue, "@") = 1
And Strings.CountInString(tValue, ".") > 0
And Strings.CountInString(tValue, " ") = 0 Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " is not a valid E-mail address"
End If

Case tNoSpaces
If InStr(tValue, " ") = 0 Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " cannot contain spaces"
End If

Case tRequired
If Len(tValue) > 0 And tValue <> "" Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " cannot be nothing"
End If

Case tPassword
If Len(tValue) > 5 Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " must be at least 6 characters long"
End If

Case tNotObscene
If Not IsObscene(tValue) Then
IsValid = True
Else
ReDimErrors tName, " may contain obscenity"
End If

Case tNotHTML
If Not ContainsHTML(tValue) Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " cannot contain HTML"
End If

Case tNotSQL
If Not ContainsSQL(tValue) Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " cannot contain SQL statements"
End If

Case tLUHN
If LUHNCheck(tValue) Then
IsValid = True
Else
IsValid = False
ReDimErrors tName, " is not a valid credit card number"
End If

End Select

Select Case IsValid
Case True
Tron.Trace "Validate", tName & _
" value [" & tValue & "] is a valid " & _
TypeDescription(CInt(tType)) & " value."
Case false
Tron.Trace "Validate", tName & _
" value [" & tValue & "] is NOT a valid " & _
TypeDescription(CInt(tType)) & " value."
End Select

End Function

Private Sub ReDimErrors(tName As String, tErrDesc As String)

Dim Rec()

' Select Case MyArrayCls.UboundC(Errors)
' Case -1
' ReDim Errors(0, 1)
' End Select

ReDim Rec(1)
Rec(0) = tName
Rec(1) = tErrDesc
Errors = MyArrayCls.AppendRecord(Errors, Rec)

End Sub

Public Function ClearErrors()
Dim nowt()
Errors = nowt
End Function

Public Function GetErrors() As Variant
GetErrors = Errors
End Function

Private Function AllowedChars(CheckString As String,
p_AllowedList As String) As Boolean

Dim l As Integer
AllowedChars = True

For l = 1 To Len(CheckString)
If Not InStr(p_AllowedList, Mid(CheckString, l, 1)) > 0 Then
AllowedChars = False
Exit Function
End If
Next

End Function

Private Function TypeDescription(TypeVal As Integer) As String

Select Case TypeVal
Case 0
TypeDescription = "Integer"
Case 1
TypeDescription = "Date"
Case 2
TypeDescription = "Email"
Case 3
TypeDescription = "NoSpaces"
Case 4
TypeDescription = "Required"
Case 5
TypeDescription = "Password"
Case 6
TypeDescription = "NotObscene"
Case 7
TypeDescription = "NotHTML"
Case 8
TypeDescription = "NotSQL"
Case 9
TypeDescription = "LUHN"
End Select

End Function
Public Property Get BadWordsINI() As String
BadWordsINI = m_BadWordsINI
End Property

Public Property Let BadWordsINI(ByVal New_BadWordsINI As String)
m_BadWordsINI = New_BadWordsINI
PropertyChanged "BadWordsINI"
End Property

'Initialize Properties for User Control
Private Sub UserControl_InitProperties()
m_BadWordsINI = m_def_BadWordsINI
End Sub

'Load property values from storage
Private Sub UserControl_ReadProperties(PropBag As PropertyBag)

m_BadWordsINI = PropBag.ReadProperty("BadWordsINI", m_def_BadWordsINI)
End Sub

'Write property values to storage
Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
Call PropBag.WriteProperty("BadWordsINI",
m_BadWordsINI,
m_def_BadWordsINI)
End Sub

Private Function IsObscene(tValue As String) As Boolean

Dim BWCount As Integer
Dim NoSpaces As String

IsObscene = False
NoSpaces = Strings.JustLetters(tValue)

Tron.Trace "Validate", "Checking message: '" & tValue & "'"

If InStr(NoSpaces, "fuck") > 0 Then
Tron.Trace "Validate", "Found Obscenity!"
Tron.Trace "Validate", "Message contains word 'fuck'."
IsObscene = True
Exit Function
End If

tValue = " " & tValue
lenmesstext = Len(tValue)
badwords = "rudeword1,rudeword2,etc"

If Not Len(m_BadWordsINI) = 0 Then
Tron.Trace "Validate", "Using Bad Words INI file."
If Not INIFile.LoadINIFile(m_BadWordsINI) Then
Tron.Trace "Validate", "Could not load the INI file: " & _
m_BadWordsINI
badword = Split(badwords, ",")
Else
badword = INIFile.GetKey("BadWords")
Tron.Trace "Validate", "Loaded word list from INI File: " & _
m_BadWordsINI
End If
Else
badword = Split(badwords, ",")
End If

INIFile.CloseINI

bwc1 = UBound(badword)

badwords = ""
bwc2 = -1

Tron.Trace "Validate", "Pass 1 - Checking for all words..."
' Pass 1
For BWCount = 0 To bwc1
If InStr(NoSpaces, badword(BWCount)) > 0 Then
Tron.Trace "Validate", "Found what may be: '" & _
badword(BWCount) & "'"
badwords = badwords & badword(BWCount) & ","
bwc2 = bwc2 + 1
End If
Next

If bwc2 > -1 Then
'Pass 2 - Dynamic Array
badwords = Left(badwords, Len(badwords) - 1)
Tron.Trace "Validate",
"Pass 2 - Message may be obscene - Checking: " & badwords
badword = Split(badwords, ",")
For N = 1 To lenmesstext
For BWCount = 0 To bwc2

testbw = " " & badword(BWCount)
NoSpaces = Mid(tValue, N, 1) &
Strings.JustLetters(Mid(tValue, N + 1, lenmesstext))

'Trace( "NoSpaces:" & nospaces)
'Trace( "Testing:" & mid(nospaces,1,len(testbw)))
'Trace( "Against:" & testbw)

If LCase(Mid(NoSpaces, 1, Len(testbw))) = LCase(testbw) Then
Tron.Trace "Validate", "Found Obscenity!"
Tron.Trace "Validate", "Message contains word '" & Trim(testbw) & "'."
IsObscene = True
Exit Function
End If

Next
Next
End If
End Function

Private Function ContainsHTML(tValue As String) As Boolean

If InStr(tValue, "<") > 0 Then
ContainsHTML = True
Else
ContainsHTML = False
End If

End Function

Private Function ContainsSQL(tValue As String) As Boolean

tValue = LCase(tValue)

If InStr(tValue, "delete") > 0 Or InStr(tValue, "select") > 0 & _
Or InStr(tValue, "insert") > 0 Or InStr(tValue, "update") > 0 & _
Or InStr(tValue, "exec") > 0 Or InStr(tValue, "xp_") > 0 Then
ContainsSQL = True
Else
ContainsSQL = False
End If

End Function

Private Function LUHNCheck(CardNumber As String) As Boolean

Dim N, tot, x, chk, checkdigit

If Len(CardNumber) = 0 Then
LUHNCheck = False
Tron.Trace "Validate",
"Card Number [ " & CardNumber & " ] is not a number"
Else

tot = 0
chk = Right(CardNumber, 1)
CardNumber = Left(CardNumber, Len(CardNumber) - 1)

For N = Len(CardNumber) To 1 Step -2
x = CInt(Mid(CardNumber, N, 1)) * 2
If Len(x) > 1 Then
tot = tot + CInt(Mid(x, 1, 1))
'debug mid(x,1,1)
tot = tot + CInt(Mid(x, 2, 1))
'debug mid(x,2,1)
Else
tot = tot + CInt(Mid(x, 1, 1))
'debug mid(x,1,1)
End If
Next

For N = Len(CardNumber) - 1 To 1 Step -2
tot = tot + CInt(Mid(CardNumber, N, 1))
'debug mid(CardNumber,n,1)
Next

'debug tot

checkdigit = CInt(CStr(CInt(Left(CStr(tot), 1)) + 1) & "0") - tot

Tron.Trace "Validate",
"LUHN Checkdigit should be " & checkdigit
Tron.Trace "Validate",
"Actual LUHN Check Digit " & chk

If CInt(chk) = CInt(checkdigit) Then
LUHNCheck = True
Else
LUHNCheck = False
End If

End If
End Function[/code]

Tutorial – Ethical Disclosure

admin — Thu, 19 Mar 2009 21:46:56 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

Code: Select all: Soda_Popinsky has very kindly allowed this tutorial of his to be hosted on the TAZ.

Ethical Disclosure
(at least how I do it)
by Soda_Popinsky

Intoduction
When one comes across a vulnerability, they can do one of four things:

1.Full Disclosure
2.Ethical Disclosure to vendor/author
3.No Disclosure
4.0-Day Exploitation of vulnerability

This is the process I use for disclosure of vulnerability, and it’s pretty simple. I believe that the first party to receive technical information about a vulnerability should be the vendor/author or service responsible for creating the vulnerabilty.

Discovery

First off (after I discover a vulnerability) I confirm that the vulnerability exists so I don’t waste anyone’s time or ruin my own credibiltiy with a false alarm. Afterwards, I make two contacts:

Vendor or author of the asset with vulnerability

Secunia

Why contact Secunia? Because there’s always the chance that the author or vendor won’t have the capacity to handle (or give a shit) about the vulnerability. I make contact with Secunia so they can use their muscle (aka an @secunia.com email address) to convince a vendor to turn their wheels with a fix. This doesn’t happen as much as you might think, however.

I give everything regarding the vulnerability over to Secunia, and they then hold on to the vulnerability information and delay the advisory until I give them the go-ahead to release it. Secunia can obviously be replaced by another advisory service (like iDefense to whore it out), except for something like BugTraq or Full Disclosure mailing lists, but I can’t vouch for their willingness to delay an advisory the way Secunia does. I delay the advisory, and I then move on to the vendor…

Dealing with the Vendor

If you are looking for a place to contact the vendor, first browse the website for any email address that looks at all relevant (developers, security) or general (info, general, contactus@). If that’s a no-go and can’t be found… whois their domain, and look for the abuse contact (usually

abuse@vendor.com

)

http://www.whois.sc

Be prepared to speak over PGP encrypted email. If you don’t have a key, get one (this isn’t a public key tutorial, you figure it out).

http://www.pgp.com/
http://www.gnupg.org/

If possible, ask them to sign their emails so they can’t deny that you contacted them. (You might be talking to a help desk cronie that doesn’t have a clue) Just a precaution for later. Send them whatever is needed (PoC code, text, etc) for them to understand the vulnerability once they ask for it… the quicker they understand, the quicker the response.

If they ask for it, they imply they are in a position to deal with it. Don’t just randomly send off PoC exploits to all the email addresses you can find at a vendor.

If the vendor is cooperative, then delay the release of the advisory until there is an official fix available. Ask them for this time frame and offer your help in the development of the fix.

There is always the possibility that they won’t understand the threat, won’t have a functioning bug reporting system, or are just straight up unresponsive… In that case…

…They Don’t Care!

This is where our contact to Secunia/Wherever is useful. After the initial email to the vendor, I’ll give 2 weeks to the vendor to respond. I’ll then tell Secunia that they aren’t responsive, and Secunia will also attempt to make the contact. (they have connections )

Two weeks later, I’ll tell Secunia to (or Secunia will themselves) release the advisory and the news will travel to Full Disclosure or Bugtraq soon after.

Credit
Getting credit for published advisories is common. For the infosec analyst, an advisory isn’t worth much except for childish/worthless IRC/Forum/Classroom street cred or whatever… unless it’s done responsibly. It has landed me a few jobs and I’m glad I’ve been handling them the way I have. It shows character and proves that an individual is worth trusting.

Conclusion
This process lowers the amount of exploitation to an amount that’s acceptable for my own concious, allows the vendor to respond at their own rate, and gives sysadmins full details of the vulnerability when an official fix is ready (as opposed to dirty hacks, like we saw with the WMF exploit).

Web services are tough… because users can’t apply fixes (such as Antionline). I don’t have the answers for that, but I’ve been lucky to not have to deal with an unresponsive provider in that area.

That’s all I got. I’m sure there will be discussion considering the events that have happened over the past week or so. Regardless, I’m selfish and have a huge ego, so I prefer this method for my own reputation.