Tuesday, January 31, 2012

[DIY] Tools - Using Hping


Here's a quick hping usage tutorial.

From the man page:
hping3 is a network tool able to send custom TCP/IP packets and to display target replies like ping program does with ICMP replies. hping3 handle fragmentation, arbitrary packets body and size and can be used in order to transfer files encapsulated under supported protocols. Using hping3 you are able to perform at least the following stuff:
- Test firewall rules
- Advanced port scanning
- Test net performance using different protocols, packet size, TOS (type of service) and fragmentation.
- Path MTU discovery
- Transferring files between even really fascist firewall rules.
- Traceroute-like under different protocols.
- Firewalk-like usage.
- Remote OS fingerprinting.
- TCP/IP stack auditing.
- A lot of others.
Refer to man hping3 and hping3 --help for detailed options & switches.

Let's start with some common base options which are pretty self-explanatory & then move on to modes et all:
root@victor:xd# hping3 --help
usage: hping3 host [options]
-h --help show this help
-v --version show version
-c --count packet count
-i --interval wait (uX for X microseconds, for example -i u1000)
--fast alias for -i u10000 (10 packets for second)
--faster alias for -i u1000 (100 packets for second)
--flood sent packets as fast as possible. Don't show replies.
-n --numeric numeric output
-q --quiet quiet
-I --interface interface name (otherwise default routing interface)
-V --verbose verbose mode
-D --debug debugging info

...snip...
I would like to mention one switch in the IP options category: --rand-source. This hping switch selects the source address of all packets randomly. This can therefore, be used to do (stress) testing stateful firewalls. But it can also potentially fill up the state table, in turn causing legit users & traffic to drop off. So, need to keep this when using this option.

Okay, moving on.

By default, hping sends TCP packets with no tcp flags set, and target host's port 0, continuously. A target system will respond with a RST packet, confirming that it is live.

root@victor:xd# hping3 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): NO FLAGS are set, 40 headers + 0 data bytes
len=40 ip=172.72.5.139 ttl=128 id=32996 sport=0 flags=RA seq=0 win=0 rtt=13.4 ms
len=40 ip=172.72.5.139 ttl=128 id=32997 sport=0 flags=RA seq=1 win=0 rtt=0.7 ms
len=40 ip=172.72.5.139 ttl=128 id=32998 sport=0 flags=RA seq=2 win=0 rtt=0.4 ms
^C
--- 172.72.5.139 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/4.8/13.4 ms

There are several modes that we can use hping in. Default mode is TCP.
root@victor:xd# hping3 --help
usage: hping3 host [options]
...
snip
...
Mode
  default mode TCP
  -0 --rawip RAW IP mode
  -1 --icmp ICMP mode
  -2 --udp UDP mode
  -8 --scan SCAN mode.
                   Example: hping --scan 1-30,70-90 -S www.target.host
  -9 --listen listen mode

...
snip
...

RAW IP mode sends the packets without a TCP or UDP headers. To send raw IP packets to target, use the -0 or --rawip switch:
root@victor:xd# hping3 --rawip 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): raw IP mode set, 20 headers + 0 data bytes
^C
--- 172.72.5.139 hping statistic ---
19 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms


As we see here, the target (& most systems) silently drops the raw ip packets.

With ICMP mode, hping sends ICMP packets to the target. By default, ICMP echo-requests are sent.

root@victor:xd# hping3 --icmp 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): icmp mode set, 28 headers + 0 data bytes
len=28 ip=172.72.5.139 ttl=128 id=309 icmp_seq=0 rtt=3.8 ms
len=28 ip=172.72.5.139 ttl=128 id=310 icmp_seq=1 rtt=0.6 ms
len=28 ip=172.72.5.139 ttl=128 id=311 icmp_seq=2 rtt=0.4 ms
^C
--- 172.72.5.139 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/1.6/3.8 ms
We can easily set other ICMP type/code by using -K / --icmptype or -C / --icmpcode switches.
root@victor:xd# hping3 --help
usage: hping3 host [options]...
snip
...
ICMP
  -C --icmptype icmp type (default echo request)
  -K --icmpcode icmp code (default 0)
      --force-icmp send all icmp types (default send only supported types)
      --icmp-gw set gateway address for ICMP redirect (default 0.0.0.0)
      --icmp-ts Alias for --icmp --icmptype 13 (ICMP timestamp)
      --icmp-addr Alias for --icmp --icmptype 17 (ICMP address subnet mask)
      --icmp-help display help for others icmp options

...
snip
...

For example to use --icmptype as Timestamp / icmp type 13 code 0:
root@victor:xd# hping3 -c 3 --icmptype 13 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): icmp mode set, 28 headers + 0 data bytes
len=40 ip=172.72.5.139 ttl=128 id=321 icmp_seq=0 rtt=0.9 ms
ICMP timestamp: Originate=78180467 Receive=1459333124 Transmit=1459333124
ICMP timestamp RTT tsrtt=1
len=40 ip=172.72.5.139 ttl=128 id=322 icmp_seq=1 rtt=0.4 ms
ICMP timestamp: Originate=78181468 Receive=1056942084 Transmit=1056942084
ICMP timestamp RTT tsrtt=1
len=40 ip=172.72.5.139 ttl=128 id=323 icmp_seq=2 rtt=0.5 ms
ICMP timestamp: Originate=78182468 Receive=637774084 Transmit=637774084
ICMP timestamp RTT tsrtt=1
--- 172.72.5.139 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.6/0.9 ms

Or use --icmpcode switch:

root@victor:xd# hping3 -c 2 --icmpcode 0 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): icmp mode set, 28 headers + 0 data bytes
len=28 ip=172.72.5.139 ttl=128 id=341 icmp_seq=0 rtt=0.5 ms
len=28 ip=172.72.5.139 ttl=128 id=342 icmp_seq=1 rtt=0.4 ms
--- 172.72.5.139 hping statistic ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.5 ms
Of course, above example shows a ping [icmp type 8 code 0].


Similarly for UDP mode, -2 or --udp switch is used. By default, packets will be sent to target host's port 0.
root@victor:xd# hping3 -c 2 --udp 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): udp mode set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=172.72.5.139 name=UNKNOWN
status=0 port=1067 seq=0
ICMP Port Unreachable from ip=172.72.5.139 name=UNKNOWN
status=0 port=1068 seq=1
--- 172.72.5.139 hping statistic ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.6/500.5/1000.3 ms
So, we receive ICMP Port Unreachable, since there is no UDP service running / listening on the target.

Next is the Scan Mode. We can turn to scan mode by using the -8 or --scan switch. A port or range of ports or an alias is expected as an argument. There are 2 aliases supported currently - all and known. 'all' means all ports 0-65535; 'known' will use all the ports listed in /etc/services file.

root@victor:xd# hping3 -8 21,22,23,135,139,445 172.72.5.139
Scanning 172.72.5.139 (172.72.5.139), port 21,22,23,135,139,445
6 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
All replies received. Done.
Not responding ports:
We did not receive any service identification or confirmation response back from the target host. Or at least we do not know the response details yet.

We can use -V switch to get the response info.
root@victor:xd# hping3 -8 21,22,23,135,139,445 172.72.5.139 -V
using vmnet1, addr: 172.72.5.1, MTU: 1500
Scanning 172.72.5.139 (172.72.5.139), port 21,22,23,135,139,445
6 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
   21 ftp : ..R.A... 128 44033 0 40
   22 ssh : ..R.A... 128 44289 0 40
   23 telnet : ..R.A... 128 44545 0 40
  135 loc-srv : ..R.A... 128 44801 0 40
  139 netbios-ssn: ..R.A... 128 45057 0 40
  445 microsoft-d: ..R.A... 128 45313 0 40
All replies received. Done.
Not responding ports:
Okay, it appears, that the target host is simply sending a RST ACK to all our scan packets.

Remember that by default, hping will NOT set any TCP flags - SYN, ACK, RST, PSH, URG, FIN. Let's set the SYN flag and scan again.
root@victor:xd# hping3 -8 21,22,23,135,139,445 172.72.5.139 -V -S
using vmnet1, addr: 172.72.5.1, MTU: 1500
Scanning 172.72.5.139 (172.72.5.139), port 21,22,23,135,139,445
6 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
   21 ftp : .S..A... 128 50177 64240 44
   22 ssh : ..R.A... 128 50433 0 40
   23 telnet : ..R.A... 128 50689 0 40
  135 loc-srv : .S..A... 128 50945 64240 44
  139 netbios-ssn: .S..A... 128 51201 64240 44
  445 microsoft-d: .S..A... 128 51457 64240 44
All replies received. Done.
Not responding ports:
Alright, with SYN packets, we now find that the target responds back with SYN-ACK for some ports and RST-ACK for other ports.
A SYN-ACK implies that the ports [21,135,139,445] are open, whereas a RST-ACK for ports 22, 23 tells us they are closed / no ssh or telnet on the target box.

Now try using the aliases:


root@victor:xd# hping3 -8 known 172.72.5.139 -S
Scanning 172.72.5.139 (172.72.5.139), port known
317 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
  135 loc-srv : .S..A... 128 25860 64240 44
  139 netbios-ssn: .S..A... 128 26628 64240 44
  445 microsoft-d: .S..A... 128 34820 64240 44
   21 ftp : .S..A... 128 774 64240 44
All replies received. Done.
Not responding ports:


root@victor:xd# hping3 -8 all 172.72.5.139 -S
Scanning 172.72.5.139 (172.72.5.139), port all
65536 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
21 ftp : .S..A... 128 9127 64240 44
135 loc-srv : .S..A... 128 38311 64240 44
139 netbios-ssn: .S..A... 128 39335 64240 44
445 microsoft-d: .S..A... 128 33214 64240 44
52111 : .S..A... 128 8910 64240 44
All replies received. Done.
Not responding ports: (3130 icpv2) (3131 ) (3132 ) (3133 ) (3134 ) (3135 ) (3136 ) (3137 ) (3138 ) (3139 ) (3140 ) (3141 ) (3142 ) (3143 ) (3144 ) (3145 ) (3146 ) (3147 ) (3148 ) (3149 ) (3150 ) (3151 ) ...snip...

Final mode is the Listen mode, activated by -9 or --listen switch. Basically, when started in listen mode, hping waits] for an incoming packet. hping expects a signature in the incoming packet. Once it finds the signature, hping then dumps the packet, starting -from- the signature -to- the packet end.

For example, on my *nix box, I start hping in listen mode and set the signature as 'JackP0t'. Note that in listen mode, we need to specify the interface to listen on [in case there are multiple interfaces on your box]. Next on the Windows target box, I start hping and give it the file 'confidential_file' as the data input. Remember this data file content will be 'prepended' with the signature 'JackP0t' when it goes out in the packet.
root@victor:xd# hping3 --help
usage: hping3 host [options]...
snip
...
Common
  -d --data data size (default is 0)
  -E --file data from file
  -e --sign add 'signature'
  -j --dump dump packets in hex
  -J --print dump printable characters
  -B --safe enable 'safe' protocol
  -u --end tell you when --file reached EOF and prevent rewind
  -T --traceroute traceroute mode (implies --bind and --ttl 1)
  --tr-stop Exit when receive the first not ICMP in traceroute mode
  --tr-keep-ttl Keep the source TTL fixed, useful to monitor just one hop
  --tr-no-rtt Don't calculate/show RTT information in traceroute mode

...
snip
...
On *nix box:
root@victor:xd# hping3 --listen JackP0t -I vmnet1
hping3 listen mode
[main] memlockall(): Success
Warning: can't disable memory paging!
Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.
<--- content in the file 'confidential_file' which we sent in the packets. hping listener sees the signature 'JackP0t' and then dumps bytes that follow.
From Windows system:
C:\Documents and Settings\Administrator\Desktop\hping2.win32>hping --data 100 --file confidential_file.txt -e JackP0t 172.72.5.1 -V --end <--- we have set a data size of 100 bytes, specified the file 'confidential_file.txt' as data input, set 'JackP0t' as the signature, used a Verbose option to see responses and lastly, used the --end option to tell us when the file reaches EOF.
using AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport, addr: 172.72.5.139, MTU: 1500
HPING (XPSP2) 172.72.5.1 (AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport 172.72.5.1): NO FLAGS are set, 40 headers + 100 data bytes
[main] memlockall(): No error
Warning: can't disable memory paging!
EOF reached, wait some second than press ctrl+c
len=46 ip=172.72.5.1 ttl=64 DF id=0 tos=0 iplen=40
sport=0 flags=RA seq=0 win=0 rtt=16.0 ms
seq=0 ack=141 sum=7441 urp=0
EOF reached, wait some second than press ctrl+c
len=46 ip=172.72.5.1 ttl=64 DF id=0 tos=0 iplen=40
sport=0 flags=RA seq=1 win=0 rtt=0.0 ms
seq=0 ack=26600 sum=17da urp=0

Do note that hping does NOT allow us to scan or send packets to a range of IP addresses. However, we can automate it using a bit of shell scripting.

Let's say we want to send 1 single SYN packet to all 'known' alias ports on all hosts in 172.72.5.0/24 network. This can be done as follows:
for i in `seq 1 255`; do hping3 --count 1 -8 known -S 172.72.5.$i; done
.....

Monday, January 30, 2012

[Quick Notes] Various network scan types

A pentester performs several types of network scans during a test. These are usually sequential in nature, that is, we proceed with each scan, collect information and the move on to the next scan. With each scan, we gather specific information about our target environment.

1. Network Sweeps: Objective is to identify any live IP addresses in the target range - think, ping <IP> or nmap -sn <IP>.

2. Network Tracing: Here we try to determine the target network topology & create a network map - think, traceroute or nmap --trace <IP>.

3. Port Scanning: As the name suggests, we attempt to identify any open, listening TCP and UDP ports on target hosts. At this step, a pentester gets a fair idea on what kind of applications & services are running in the environment. If any of the services is/are known to be vulnerable, a tester has a potential avenue of compromising the vulnerable host.

4. OS fingerprinting: Now that we have identified the running services, we must identify the platform it is running on. Is the target a Solaris server, or is it RHEL or a Microsoft Windows 2008 server? Our exploits, other attacks and more importantly, the overall attack process for a host running a vulnerable service, for example, will vary based on what is the host OS. Once a target OS is known, a tester can research for known OS vulnerabilities, exploits & potential security controls in place. The actual attack surface on the host, hence, becomes clear with the knowledge of target OS.

Simply use nmap to fingerprint the OS (Active OS fingerprinting): nmap -O <IP> / or use p0f3 (Passive OS fingerprinting).

5. Version Scans: This scan attempts to confirm what versions of services are running on the end hosts. Knowing the service versions can also, in some cases, immediately tell a tester if a vulnerable service is implemented in the target environment. An example is SSH v1, which has known vulnerabilities. With nmap, service scan is: nmap -sV <IP>.

6. Vulnerability Scanning: At this point, we know the live IPs, listening ports, what services are running on the ports, what is the operating system and platform of the targets, and what are the versions of services running on them. This scanning phase confirms if any of the identified hosts & services have known vulnerabilities. Most vulnerability scanners today also tell if there are any known, publicly-available exploits present for an identified vulnerability, whether certain services are using no authentication or weak auth (think, default or no MSSQL 'sa' account), CVE-ID, etc.

Monday, January 23, 2012

Hack Safaribooks video downloads



I have a safaribooks account. A few hours back, I was going through a video series on safari & I thought I should download it for offline reference. Makes it easier to study.


But there is no option to download videos! That sucks on part of Safari. They expect users to be online to be able to watch the video packages? wtf!

I decided to take a look at the site just to make sure the option is not hidden somewhere. Nope. No download option for videos. Fast forward a 10-15 minutes, I find myself checking the source code; crazy amounts of AJAX code in there.

After another 15 minutes or so, here I am, watching the videos offline & writing this post.

I followed through post AJAX, carefully looked at the site & the options available for us, the users; & identified a way. No 'testing' involved, just a knowledge of site & flow was needed. As of today, this is probably the 'only' way to download the undownloadable videos from Safari.


Please do note you or someone else needs to be a user - Individual or Corporate - for being able to 'know' the location of content on Safari.

Login to Safari & access the study resource.


Scroll down past the table of contents.


Switch to Mobile Version.



Proceed with 'Start Watching'. Meanwhile, notice that the link to 'Start Watching' for this item is:
m.safaribooksonline.com/clip?isbn=XXXXX&linkid=a01
This is the next screen when you click on 'Start Watching'.


The original request goes to m.safaribooksonline.com/clip?isbn=XXXXX&linkid=a01 which then redirects to the actual download link:

http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a01.mp4?AccountId=XXXXX&UserId=YYYYY&e=1327343958&Fpid=BBBBB&ClipId=a01&source=mui&h=ZZZZZ&source=mui&e=AAAAA&h=ZZZZZ&ClipId=a01&AccountId=XXXXX&UserId=YYYYY&Fpid=BBBBB



You can now use FlashGet to download it.



For other parts of the video series, simply modify the parameters in the download URL:
http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a01.mp4?AccountId=XXXXX&UserId=YYYYY&e=1327343958&Fpid=BBBBB&ClipId=a01&source=mui&h=ZZZZZ&source=mui&e=AAAAA&h=ZZZZZ&ClipId=a01&AccountId=XXXXX&UserId=YYYYY&Fpid=BBBBB
For video #2, the URL becomes:
http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a02.mp4?AccountId=XXXXX&UserId=YYYYY&e=1327343958&Fpid=BBBBB&ClipId=a02&source=mui&h=ZZZZZ&source=mui&e=AAAAA&h=ZZZZZ&ClipId=a01&AccountId=XXXXX&UserId=YYYYY&Fpid=BBBBB

And so on...


Actually, as you will find out eventually, that FlashGet can download the file, without needing any URL parameters:

http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a03.mp4 

You can also use Firefox or Opera. Both of them do NOT ask for any authentication when the video URL is entered.

You can use any firefox video downloader extension like Ant Video Downloader to download the video.

This implies that if one can gain knowledge of a URL, perhaps from someone who has an account on Safari, and who can access a video resource, anyone may be able to download the videos.

Also, since we were able to strip off all parameters such as AccountId, UserID etc, and still got a proper file as server response when using a different browser afresh - firefox/opera, how might safari be tracking whether the request was legit or not, i.e. was the request sent by an authenticated AND an authorized user? Certainly doesn't look like they do! A review of AAA controls of the download site could be a start for Safari.

Update: A reader provided additional info on how to apparently turn the download of mobile version (read: low quality encoded for mobile version) into HD quality.
>>> Just remove the H264 parameter in the URL.

Thanks..
.....

KG

Saturday, January 21, 2012

Passed GIAC GWAPT Exam

Hi dears,

I just wanted to share first update of this year.

I sat for & passed the SANS GIAC Web Application Penetration Testing - GWAPT - exam on January 14, 2012. I found the exam was pretty tough as compared to the previous GIAC exams I had attempted - GPEN, GCIH, and GREM.

I have been doing web app pentesting for a while. So, most of the tested topics were not new to me. I did a self-study for this exam. I used the following study resources to prepare:

1. SANS GPEN course material
2. OWASP - this site has a lot of good, relevant information on a majority of web app topics.

5. Backtrack - Specifically for any or all related tools - load it up & practice various web app testing related tools on this dist.
6. Google - Yeah, search out specific topics, terms, video tutorials, tool demonstrations. This is significant especially if you choose to take the self-study route.
7. Misc Notes - some random, personal notes on various topics.

I know it's not easy to take out 4000+ usd for official course materials. I hope this info will help someone planning self-study to tame this beast.

As always, let me know if you have any questions. I will be glad to help.

KG

Disclaimer

The views, information & opinions expressed in this blog are my own and do not reflect the views of my current or former employers or employees or colleagues.