So the other day while talking with Slurpgeit the following issue came up:
During a scan nmap reported 1000 ports filtered for the host, but wireshark told us otherwise a RST was received for a few ports but with a delay of ~18 seconds
Hmm that’s interesting, so that means that if wireshark hadn’t been monitored during the scan, the closed ports would have been missed or even worse what if open ports had been missed? The RTT to the host however were within normal ranges, also a simple ping worked fine without any delay whatsoever. Which brings us to an ancient saying about hacking:
Never trust your tools completely, always verify your results! Then verify them again and finally check that they are correct.
Since this is (assumed) something that doesn’t occur that often, you most probably want to automate the verification step. Unless you love looking at scrolling packets in your wireshark window. We can do it actively (real time sniffing) or passively (pcap) after the scans are done. I choose to implement the latter, the passive and after-the-facts verification. Reason being that all you most probably want is to check if something has gone wrong, if not just continue hacking your target. So let’s setup a lab environment to reproduce this issue and then let’s write a script for it using scapy.
I chose to just create two virtual machines within the same subnet, one being the attacker and one being the victim. To delay the traffic on the victim side I used netem since I didn’t manage to do it with iptables. I delayed one port with the following lines I found on the interwebs:
sudo tc qdisc add dev eth0 root handle 1: prio
sudo tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 5s
sudo tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip sport 22 0xffff flowid 1:1
This will effectively delay all outgoing packets from port 22 with 5 seconds, which is more then enough to make nmap think it’s a filtered port. Fun fact: while playing with netem, if you apply the delay to all packets then nmap won’t even begin to scan the host, since according to it’s arp scan the host is down. Let’s fire up nmap and take a look at the output:
Continue reading “Verifying Nmap scans”
uhh firewalking, what’s that?
To quote the original paper (1998):
A Traceroute-Like Analysis of IP Packet Responses to Determine Gateway Access Control Lists
Now that sounds pretty neat right or not if you usually only focus on open ports and ignore all other relevant information that a network scan can give you. The paper does a pretty good job of explaining the technique, so I’m not going to repeat that. Let’s just see if we understood it correctly by doing a manual test and then let’s see how we can use nmap to automate this. In case you are wondering why I don’t use the original Firewalking tool, it’s cause I prefer to not have a lot of fragmented tools unless I really need them. I mean nmap is a great tool and it just saves you a lot of time if you can just perform all (or as much as possible) of the network mapping with nmap.
Let’s setup a little lab which roughly looks like this:
So basically the attacker wants to enumerate the firewall rules that are in place on vyatta. As said, let’s start with grasping the concept of firewalking, by testing if we can proof the following configuration:
Continue reading “Firewalking with nmap”
This is just some quick script I hacked up to scan TCP ports using different source ports. The aim of the script is to find badly configured firewalls that allow traffic from certain source ports. This is for instance explained in the NMAP book. I’ve done it in scapy (yeah I know python ones again) and still admire scapy, it’s a wonderful piece of software. Here are some nice references if you decide to write your own networking stuff in scapy:
# – http://www.secdev.org/projects/scapy/doc/usage.html
# – http://www.secdev.org/conf/scapy_pacsec05.pdf
# – https://cs.uwindsor.ca/~rfortier/CRIPT/uploads/slides/Python_Scapy.pdf
You can find the source here.
I chose manual output analysis, this means that the script doesn’t have any logic whatsoever and you will have to decide, if it allows or doesn’t allow traffic from different source ports yourself. Example output:
Received 34 packets, got 8 answers, remaining 28 packets
srcport, dstport, flags, humanflags
Hope it’s also useful for someone out there.
I have been intrigued by nmap’s feature to scan a target using an idle zombie pc which has an incremental ip id. I have also been intrigued by scapy. Finally I have also been intrigued by metasploit. At first I combined nmap and metasploit and the end result was, that I was not able to get the IPIDSEQ module to work. So I turned to scapy and tried porting the metasploit module to python. It was fun and I finally employed python for something besides playing with it to learn.
I’ve also finally learned why it’s nice to prepend your output with “[*]”, since I’ve been lazy with the verbose output I have just used the one from scapy to know if my script should output or shouldn’t output verbose messages. This means that the output gets cluttered. So by prepending “[*]” you can just grep the results to have a clear view of what the script is doing without the scapy stuff in between it.
Finally scapy is a real nice toy. I had to implement 0.0 code to support cidr notation. So when you for example want to scan a /24 range you can just go like: “microsoft.com/24”. isn’t that neat? Hope you enjoy it and find a way to use it. For me it was more fun to write it and learn a lot along the way, then the actual goal I wrote it for. oh btw the non-verbose output looks like:
[*] 220.127.116.11 = Randomized
oh a second btw I recommend putting the timeout/waittime on 5 or something like that.