Port Scanning

Port scanning is the process of checking for open TCP or UDP ports on a machine. Please note that port scanning is considered illegal in many countries and should not be performed outside the labs. I was once running an Nmap scan during an internal penetration test. Unwittingly, I did not take note of the unusual subnet mask employed on the local network, and ended up running the Nmap scan through a remote up link that was offsite. The routers separating these two remote networks were overwhelmed by the intense scan, and, suffice it to say, bad things happened. Never run a port scan blindly. Always think of the traffic implications of your scans, and their possible outcome on the target machines.

TCP Port Scanning Basics
The theory behind TCP port scanning is based on the three-way TCP handshake. The TCP RFC states that when a SYN is sent to an open port, an ACK should be sent back. So the process of port scanning involves attempting to establish a three-way handshake with given ports. If they respond and continue the handshake, the port is open; otherwise, an RST is sent back. Netcat can be used as a simple port scanner.
The following syntax is used to perform a port scan using Netcat. You’ll scan ports 24–26 on 192.168.0.10:
root@bt:~# nc -vv -z -w2 192.168.0.10 24-26
192.168.0.10: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.0.10] 26 (?) : Connection refused
(UNKNOWN) [192.168.0.10] 25 (smtp) open
(UNKNOWN) [192.168.0.10] 24 (?) : Connection refused
root@bt:~#
Look at the Wireshark dump that was generated due to this scan:


UDP Port Scanning Basics
Since UDP is stateless and does not involve a three-way handshake, the mechanism behind UDP port scanning is different. Try using Wireshark while UDP scanning a lab machine to understand the how UDP port scans work.
Port Scanning Pitfalls

• UDP port scanning is often unreliable because ICMP packets are often dropped by firewalls and routers. This can lead to false positives in your scan, and you’ll often see UDP port scans showing all UDP ports open on a scanned machine. Please be aware of this.
• Most port scanners do not scan all available ports and usually have a preset list of “interesting ports” that are scanned.
• People often forget to scan for UDP services, and stick only to TCP, thereby potentially seeing only half of the equation.

Posted By Bergin A11:18 AM

0

Continue Reading

Little About Nmap

Nmap is probably one of the most comprehensive port scanners to date. Looking at the Nmap usage might be daunting at first. However, once you start scanning you will quickly become accustomed to the syntax. In BackTrack, the Nmap configuration files (such as the default port scan list) are located in /usr/local/share/nmap/.

Note that when running Nmap as a root user, certain defaults are assumed (SYN scans, for instance). Begin with a simple port scan on 192.168.0.110. Note that running this scan as a root user is actually equivalent to running nmap -sS 192.168.0.110 :

root@bt:~# nmap 192.168.0.110
Starting Nmap 5.21 ( http://www.insecure.org/nmap/ ) at 2010-10-28 16:24 GMT
Interesting ports on 192.168.0.110:
Not shown: 1664 closed ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
119/tcp open nntp
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
563/tcp open snews
…
7007/tcp open afs3-bos
MAC Address: 00:0C:29:C6:B3:23 (VMware)
Nmap finished: 1 IP address (1 host up) scanned in 1.524 seconds
root@bt:~#

The scan identified many open ports on 192.168.0.110. Next, try port scanning all of the available ports on this machine by explicitly specifying the ports to be scanned:

root@bt:~# nmap -p 1-65535 192.168.0.110Starting Nmap 5.21 ( http://www.insecure.org/nmap/ ) at 2010-10-28 16:28 GMTInteresting ports on 192.168.0.110:Not shown: 65517 closed portsPORT STATE SERVICE21/tcp open ftp25/tcp open smtp80/tcp open http119/tcp open nntp135/tcp open msrpc139/tcp open netbios-ssn443/tcp open https445/tcp open microsoft-ds563/tcp open snews…7007/tcp open afs3-bos8328/tcp open unknown30001/tcp open unknown50203/tcp open unknownMAC Address: 00:0C:29:C6:B3:23 (VMware)Nmap finished: 1 IP address (1 host up) scanned in 3.627 secondsroot@bt:~#

Notice how you’ve discovered some open ports that were not initially scanned because they are not present in the Nmap default port configuration file (/usr/local/share/nmap/nmap-services).

Posted By Bergin A11:15 AM

0

Continue Reading

Dynamic Memory & The Heap

Dynamic Linux Memory
In this article we will take look at how the heap works on the Linux operating system. This includes structure, allocation, functions, clean-up and other important details. Feel free to ask questions in comments as the topics ahead are rather complex compared to that of stack-based memory.
We will go through how dynamic memory differs from stack memory and analyse the aspects of its management.

Memory – The Heap
When memory space is needed and that size is fixed by the programmer, the stack may be the best choice to hold that data. You commonly see functions making use of the stack segment to pass constant sized variables to other called functions, often with the goal of receiving a return value of some sort. Once a function is complete, control is returned to the calling function. Functions that are given memory on the stack have a finite lifetime and use a Last in First out (LIFO) manner of handling itself. For example, the main () function is allocated memory on the stack. As functions are called from main (), the memory is allocated on the stack on top of main () and grows from higher memory addressing towards lower memory addressing. Thus when you are allocating space on the stack, you are actually subtracting the desired amount of space from the ESP register as it grows. The stack has a benefit in where it automatically cleans up after itself once a function is complete. This is not the same as with a heap.
When the data is of a variable amount, must be accessible by multiple functions, is large and/or does not necessarily have a finite lifetime, the heap may be the best location for that data. During program runtime, the loader loads segments of data into memory such as the code segment and data segment. Also created at program runtime are the stack and heap segments. Global and static variables such as that in the .data and .bss segments are often placed after the code segment and before the heap, although it can be argued that these sections are in fact part of the process heap. The kernel requests memory using system calls such as sbrk() and mmap(), These calls allocate a large block of data and do not make the most efficient use of memory, thus we want a way to manage memory more efficiently using something that sits between the program and the system call. In the C programming library there are a group of functions under malloc() that divide up the memory allocated by the system calls brkf), sbrkf) or mmap() into chunks that are more efficient and manageable.
With the heap, allocated memory is not automatically cleaned up as with the stack. The stack has a calling convention that automatically takes care of popping values off the stack and returning control to the calling function. The heap, on the other hand, requires the programmer to call a function to free the memory allocated. Failure to free the memory on the heap can result in problems including memory leakage, resource exhaustion, and fragmentation. When a user opens up a web browser, the developers of the browser have no way of knowing how many tabs the user will open, what types of pages will be visited, how much memory space is required for each site, etc. . It is this that makes the heap a more desirable location for the data than the stack.

Posted By Bergin A11:13 AM

0

Continue Reading

The Phases of an Attack

Both malicious attackers and professional penetration tester/ ethical hackers apply various phases in their attacks. Attacks are often separated into these phases:

Reconnaissance is the process of investigating target organization to gather information about it from publicly available sources, such as domain registration services, websites, and so on. Some people include techniques such as social engineering and dumpster diving in the recon phase.
Scanning is the process of finding openings in the target organization, such as Internet gateways, wireless access points, available systems, listening ports, and vulnerability lists. In the Exploitation phase, attackers exploit target systems to compromise them, possibly getting control of them or causing a denial of service attack.
While legitimate tests often include the phases listed above, malicious attackers often go further than the rules of engagement allow for a professional penetration test. The next phase, often used by malicious attacker to maintain access and control of a target machine, involves setting up the compromised machine so the attacker can keep control over it, with techniques such as installing backdoors and planting rootkits. Malicious attackers also often use a final phase, Covering the Tracks, in which they employ log editing, file hiding, and covert channels lo hide their activities on a system.
Please note that the best of the attackers (both the good guys and the evil ones) are pragmatists. They don’t always proceed from reconnaissance to scanning to gaining access and so on. Sure, they use these steps, but they are very likely to jump around between them as events and discoveries warrant. For example, during the recon phase, attackers may discover an exploitable flaw that they will use to gain access directly, temporarily bypassing scanning  Then, once they gain access to one machine, they may go back and start scanning.
From a professional testing perspective, though, be careful when jumping out of order between these steps, making sure that you return to the earlier phases to conduct a comprehensive test.

Posted By Bergin A11:12 AM

0

Continue Reading

Google Hacking

Prior to an attack, I spend some time browsing the web and looking for background information about the organization I’m about to attack. First, I usually browse the organizational website and look for general information such as contact information, phone and fax numbers, emails, company structure, and so on. I also usually look for sites that link to the target site or for organizational emails floating around the web. Sometimes the small details give you the most information: how well designed is the target website? How clean is their HTML code? This might give you a clue about their budget when they erected their site, from which, in turn, you may intuit their budget to secure it.

Google has proven to be one of the best and most comprehensive search engines to date. Google will violently spider websites, inadvertently exposing sensitive information on that web site due to various web server misconfigurations (such as directory indexing). Such exposure results in huge amounts of data leaking into the web and, even worse, leaking into the Google cache.
In early 2000 this gave birth to a new field, Google Hacking. Google hacking was first introduced by Johnny Long, who has since published a couple of books about it— a “must read” for any serious Googlenaut. Johnny Long’s book, “Google Hacking For Penetration Testers” can be found on Amazon at: http://www.amzn.com/1931836361.
The general idea behind Google hacking is to use special search operators in Google to narrow down search results and find very specific files, usually with a known format. You can find basic usage information here: http://www.google.com/help/basics.html
Advanced Google Operators The advanced search operators allow you to narrow down your searches even more, and to pinpoint target searches to exactly what you are looking for. A list of Google operators can be found at http://www.google.com/help/operators.html. Using these operators you can search for specific information that might be of value during a pen test.
As a web server owner, I can strongly relate to the following example. I often make backups of my MySQL database because I am a prudent web server owner. The MySQL dumps usually have a .sql suffix, and they usually have the string MySQL dump at the top of the
file. mysql dump filetype:sql
This search reveals all the exposed MySQL backups that have been subjected to Google, and often these dumps contain juicy information like usernames, passwords, emails, credit card numbers, and the like. This information may just be the handle you need to gain access to the server/network.
There are literally hundreds (if not thousands) of interesting searches that can be made, and most of them are listed in the “Google Hacking” section of the Exploit Database. The GHDB organizes these searches into categories such as usernames and passwords, and even rates each search by popularity.`

Posted By Bergin A11:11 AM

0

Continue Reading

Listening on a TCP/UDP Port with Netcat

•  To listen on port 4444 and accept incoming connections,

type: Computer 1 (local computer – 192.168.8.74)
root@bt:~# nc -lvp 4444
                 listening on [any]4444

• From a different computer connect to port 4444 on your local machine:

Computer 2 (Windows box – 192.168.9.158)

C:\>nc -v 192.168.8.74 4444
192.168.8.74: inverse host lookup failed: h_errno 11004: NO_DATA
(UNKNOWN) [192.168.8.74] 4444 (?) open
HI, HOW ARE YOU!
fine thanks, you?
I’M DOING GREAT!

Posted By Bergin A11:10 AM

0

Continue Reading

Netcat

Netcat is a wonderfully versatile tool that has been dubbed the “hackers’ Swiss army knife.” The simplest definition of Netcat is “a tool that can read and write to TCP and UDP ports.” This dual functionality suggests that Netcat runs in two modes: client and server.

Connecting to a TCP/UDP port can be useful in several situations:

• To check if a port is open or closed
• To read a banner from the port
• To connect to a network service manually

Please take time to inspect Netcat’s command line options:
root@bt:~# nc -h
[v1.10-38]
connect to somewhere: nc [-options] hostname port[s] [ports] …
listen for inbound: nc -l -p port [-options] [hostname] [port]
options:
-c shell commands as `-e’; use /bin/sh to exec [dangerous!!]
-e filename program to exec after connect [dangerous!!]
-b allow broadcasts
-g gateway source-routing hop point[s], up to 8
-G num source-routing pointer: 4, 8, 12, …
-h this cruft
-i secs delay interval for lines sent, ports scanned
-k set keepalive option on socket
-l listen mode, for inbound connects
-n numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r randomize local and remote ports
-q secs quit after EOF on stdin and delay of secs
-s addr local source address
-T tos set Type Of Service
-t answer TELNET negotiation
-u UDP mode
-v verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-z zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive];
hyphens in port names must be backslash escaped (e.g. ‘ftp\-data’).
root@bt:~#

Posted By Bergin A11:09 AM

0

Continue Reading

Basics Of Web App Attack

In this article we’ll define how web applications are associated with network penetration testing and ethical hacking. In this up-front overview, we’ll also define web applications.Some of the most widespread web application vulnerabilities found today are Cross-Site Request Forgery (XSRF), Cross-Site Scripting (XSS), SQL Injection etc,


In the penetration testing and ethical hacking field, network tests are often considered a separate kind of project from web application tests. The skills associated with each kind of test are, for the most part, distinct and specialized. Some testers focus on network tests, dealing with finding flaws in network-accessible services and clients. Other testers specialize in finding flaws in web applications. A smaller number of testers work both sides, dealing with network tests and web app tests.
Even if you focus exclusively on network penetration tests, you still need to be familiar with various web application vulnerabilities and tools for testing web apps. Sometimes, we are asked in a network test to perform a cursory review of a web app. Other times, we need to interact with web app pen testers to share findings and cooperate in a given attack. And, for some of us, we need to be able to perform both network tests and web app tests.
Before we get into the guts of web application vulnerabilities and testing, let’s start out by defining a web application. There are two fundamental properties that define a web application. First, the web app is accessed via HTTP or and/or HTTPS across the network. Secondly, web apps involve a web server. Those are the only two crucial properties that make a web application a web application.
Most (but not all) web applications involve a browser or related client that sends, receives, and renders HTML via HTTP and/or HTTPS. The browser may be a full-fledged browsing application, such as Internet Explorer or Firefox. Or, it could be a more specialized program, such as the iTunes music player. Furthermore, many (but not all) web apps involve a back end database that stores information for the web application. The most popular database back-ends to web apps are Microsoft SQL Server, Oracle, and MySQL.
Most attacks in the wild today deal with finding flaws in these three components and the way that they interact with each other: the logic of the web application on the web server, the web server and web browser’s interactions, and the web server and database’s interactions.

Posted By Bergin A11:08 AM

0

Continue Reading

Transferring Files with Netcat

Netcat can also be used to transfer files, both text and binary, from one computer to another. To send a file from Computer 2 to Computer 1, try the following:
Computer 1: Set up Netcat to listen to and accept the connection and to redirect any input into a file.

root@bt:~# nc -lvp 4444 > output.txt
listening on [any] 4444 …
Computer 2: Connect to the listening Netcat on computer 1 (port 4444) and send the file:

C:\>echo “Hi! This is a text file!” > test.txt
C:\>type test.txt
“Hi! This is a text file!”
C:\>nc -vv 192.168.8.74 4444 < test.txt
192.168.8.74: inverse host lookup failed: h_errno 11004: NO_DATA
(UNKNOWN) [192.168.8.74] 4444 (?) open

Because Netcat doesn’t give any indication of file transfer progress, wait for a few seconds and then
press Ctrl+C to exit Netcat.
On Computer 1 you should see:

root@bt:~# nc -lvp 4444 > output.txt
listening on [any] 4444 …
192.168.9.158: inverse host lookup failed: Unknown server error : Connection timed out
connect to [192.168.8.74] from (UNKNOWN) [192.168.9.158] 1027
^C root@bt:~#

Now check that the file was transferred correctly:
Computer 1
root@bt:~# file output.txt
output.txt: ASCII text, with CRLF line terminators
root@bt:~# cat output.txt
“Hi! This is a text file!”
root@bt:~#

Posted By Bergin A11:06 AM

0

Continue Reading

Forward Lookup Brute Force

The idea behind this method is to try to guess valid names of organizational servers by trying to resolve a given name. If the name resolves, the server exists. Here’s a short example using the host command:
root@bt:~# host www.checkpoint.com
www.checkpoint.com has address 216.200.241.66
root@bt:~# host idontexist.checkpoint.com
Host idontexist.checkpoint.com not found: 3(NXDOMAIN)
root@bt:~#
Notice that the DNS name www.checkpoint.com resolved and the host command (which acts as a DNS client) returned the IP address belonging to that FQDN. The name idontexist.checkpoint.com did not resolve and you received a “not found” result.
Taking this idea a bit further, with a bit of bash scripting you can automate the process of discovery. Next, compile a short list of common server names and enter them into a file: dns-names.txt (a more complete list of DNS names is available in /pentest/enumeration/dnsenum/dns.txt):
www
www2
firewall
cisco
checkpoint
smtp
pop3
proxy
dns
…
You can now write a short bash script (dodns.sh) that will iterate through this list and execute the host command on each line:
#!/bin/bash
for name in $(cat dns-names.txt);do
host $name.checkpoint.com
done
The output of this script is raw and not terribly useful:
root@bt:~# ./dodns.sh
www.checkpoint.com has address 216.200.241.66
Host www1.checkpoint.com not found: 3(NXDOMAIN)
www2.checkpoint.com is an alias for www.checkpoint.com.
www.checkpoint.com has address 216.200.241.66
Host firewall.checkpoint.com not found: 3(NXDOMAIN)
Host cisco.checkpoint.com not found: 3(NXDOMAIN)
Host checkpoint.checkpoint.com not found: 3(NXDOMAIN)
smtp.checkpoint.com is an alias for michael.checkpoint.com.
michael.checkpoint.com has address 194.29.32.68
pop3.checkpoint.com is an alias for michael.checkpoint.com.
michael.checkpoint.com has address 194.29.32.68
Host proxy.checkpoint.com not found: 3(NXDOMAIN)
Host dns.checkpoint.com not found: 3(NXDOMAIN)
Host dns1.checkpoint.com not found: 3(NXDOMAIN)
ns.checkpoint.com has address 194.29.32.199
root@bt:~#
Try cleaning up the output to show only the lines that contain the string “has address”:
#!/bin/bash
for name in $(cat dns-names.txt);do
host $name.checkpoint.com |grep “has address”
done
The output of this script looks much better and shows only hostnames that have been resolved:
root@bt:~# ./dodns.sh
www.checkpoint.com has address 216.200.241.66
www.checkpoint.com has address 216.200.241.66
michael.checkpoint.com has address 194.29.32.68
ns.checkpoint.com has address 194.29.32.199
root@bt:~#
To get a clean list of IPs, you can perform further test manipulation on this output. Cut the list and show only the IP address field:
#!/bin/bash
for name in $(cat dns-names.txt);do
host $name.checkpoint.com |grep “has address”|cut -d” ” -f4
done
The output is now limited to a list of IP addresses:
root@bt:~# ./dodns.sh
216.200.241.66
…
194.29.32.68
194.29.32.68
root@bt:~#

Posted By Bergin A11:05 AM

0

Continue Reading

DNS Reconnaissance

DNS is one of my favorite sources of information gathering. DNS offers a variety of information about public (and sometimes private!) organization servers, such as IP addresses, server names, and server functions.
Interacting with a DNS Server
A DNS server will usually divulge DNS and mail server information for the domain for which it is authoritative. This is a necessity because public requests for mail server addresses and DNS server addresses make up the basic internet experience.
You can interact with a DNS server using various DNS clients such as host, nslookup and dig. Let’s examine nslookup first. By simply typing nslookup, you are put in an nslookup prompt, and you forward any DNS request to the DNS server, which is set up in your TCP/IP settings.
For example:
root@bt:~# nslookup
> www.checkpoint.com
Server: 24.224.127.143
Address: 24.224.127.143#53
Non-authoritative answer:
Name: www.checkpoint.com
Address: 216.200.241.66
>
In this example, you’ve connected to the local DNS server (24.224.127.143) and asked it to resolve the A record for www.checkpoint.com. The DNS server replies with the address 216.200.241.66.
MX Queries
To identify the MX server (mail servers) belonging to an organization, you can simply ask the DNS server to show all the MX records available for that organization’s domain:
> set type=mx
> checkpoint.com
Server: 24.224.127.143
Address: 24.224.127.143#53
Non-authoritative answer:
checkpoint.com mail exchanger = 12 cale.checkpoint.com.
checkpoint.com mail exchanger = 15 usmail-as.zonelabs.com.
Authoritative answers can be found from:
checkpoint.com nameserver = ns8.checkpoint.com.
checkpoint.com nameserver = ns6.checkpoint.com.
cale.checkpoint.com internet address = 194.29.32.199
ns6.checkpoint.com internet address = 194.29.32.199
ns8.checkpoint.com internet address = 216.228.148.29
>
Notice the two mail servers that were listed: mfnbm2 cale.checkpoint.com and usmailas. zonelabs.com. Each server has a “cost” associated with it—12 and 15, respectively. This cost indicates the preference of arrival of mails to the mail servers listed (lower costs are preferred). From this you can assume that cale is the primary mail server and that the other is a backup in case cale fails.
NS Queries
With a similar query, you can identify all the DNS servers authoritative for a domain:
> set type=ns
> checkpoint.com
Server: 24.224.127.143
Address: 24.224.127.143#53
Non-authoritative answer:
checkpoint.com nameserver = ns8.checkpoint.com.
checkpoint.com nameserver = ns6.checkpoint.com.
Authoritative answers can be found from:
ns6.checkpoint.com internet address = 194.29.32.199
ns8.checkpoint.com internet address = 216.228.148.29
This query identifies two DNS servers serving the checkpoint.com domain: ns6 and ns8. This information can be useful later when you attempt to perform zone transfers.

Posted By Bergin A11:03 AM

0

Continue Reading