http://cgi.ebay.com/ebaymotors/Ford-F-150-/140436971572
Warning: mysql_result() [function.mysql-result]: Unable to jump to row 0 on MySQL result index 4 in /home1/wheelki1/public_html/server/ad5.php on line 591
2010年8月8日星期日
Directory Traversal Cheat Sheet
You can use this cheat sheet for exploiting web servers and application servers for directory traversal.
This is eight level of deep Directory Traversal. There are 880 variants of Directory Traversal attack signatures.
To use this list effectively, you need to replace the "(Filename)" phrase to the desired file - Depending by the attacked web server OS.
Be my guest to suggest more variants to this awesome list.
Enjoy ;-)
http://narkolayev-shlomi.blogspot.com/2010/04/directory-traversal-fuzz-list.html
This is eight level of deep Directory Traversal. There are 880 variants of Directory Traversal attack signatures.
To use this list effectively, you need to replace the "(Filename)" phrase to the desired file - Depending by the attacked web server OS.
Be my guest to suggest more variants to this awesome list.
Enjoy ;-)
http://narkolayev-shlomi.blogspot.com/2010/04/directory-traversal-fuzz-list.html
2010年7月27日星期二
A Lazy Pen Tester’s Guide to Testing Flash Applications
Yesterday, I received a post in the Pen-Test mailing list requesting for tips/resources on penetration testing of flash applications. While there are some tools and white papers available, I could not find many authoritative resources which wraps the entire spectrum of flash security testing of RIA applications. So here is an endeavor to detail out the steps of testing. I will keep this post only to outline the essential steps or points. Please feel free to recommend additional inclusion of tools and techniques. The idea is to come up with a comprehensive paper which can be used by pen-testers to test flash based Rich Internet Applications (RIA).
A short unnecessary introduction on Flash RIA
Adobe Flash (formerly Macromedia Flash) is a multimedia platform originally acquired by Macromedia and currently developed and distributed by Adobe Systems. Since its introduction in 1996, Flash has become a popular method for adding animation and interactivity to web pages. Flash is commonly used to create animation, advertisements, and various web page Flash components, to integrate video into web pages, and more recently, to develop rich Internet applications. Source: en.wikipedia.org/wiki/Adobe_Flash
Conventionally, RIA developed with Adobe Flash technology consists of a frontend application compiled as an SWF/AIR object to be executed by the Flash Plugin inside the User’s Browser or the AIR Platform installed on the User’s System. This interactive application provides a user Interface to the end-user and in turn communicates with a backend server for its business logic over protocols like HTTP/AMF, HTTP/SOAP, HTTP/REST etc.
The security angle..
Similar to any widely used web application and software, a RIA can also be a victim of most common and dangerous security Issues. For example, since most Flash based RIAs are backed by an application for its business logic which in turn uses a database, a Flash based RIA might also be vulnerable to common application vulnerabilities like SQL Injection if user input is not sanitized properly. Quite logical huh?. Attackers can also utilize Flash to execute mass exploitation, for example backdoors or malware entirely written in Flash/ActionScript or BOFs against player/plugin or browser.
It is quite general to deduce that security flaws may also be present in the core environment (which includes the OS and web browsers) that can be exploited regardless of the applications (including Flash Player) running in that environment. A recent paper from Adobe suggests that the approach of Adobe is to implement robust security within its own products while “doing no harm” to the rest of the environment (in other words, to introduce no exposures to the rest of the environment, nor allow any avenues for additional exploitation of any existing platform security weaknesses). This provides a consistently high level of security for what Flash applications can do (as managed within Flash Player), regardless of the platform. Because Adobe products are also designed to be backwards-compatible when possible, some environments may be more vulnerable to weaknesses in the browser or operating system, or have weaker cryptography capabilities. Ultimately, users are responsible for their choices of platforms and maintenance of appropriate operational environments.
Vulnerabilities in flash RIA can be broadly classified under two categories: client side vulnerabilities and server side vulnerabilities. Let’s review each one of these very quickly:
Client Side Vulnerabilities:
Amongst the various vulnerabilities that might affect a Flash Application on the client side, some of the most common ones are:
Flash parameter Injection: It might be possible for an attacker can inject global Flash parameters when the movie is embedded in a parent HTML page. These injected parameters can grant the attacker full control over the page DOM, as well as control over other objects within the Flash movie. There is nice detailed paper by the IBM Rational guys on this vulnerability. You can download it here.
Cross Domain Privilege Escalation: Cross Domain inter-mixing of content and data is done based on access policy defined in crossdomain.xml of the serving domain for the SWF object. If the access policy is too open, then under certain circumstances, it might be possible for an attacker to supersede the original SWF object with his own malicious version or access the DOM of the hosting domain.
Cross Site Scripting: Depending on access policy, a Flash SWF can access its host DOM for various functional use cases. A Flash SWF can in turn modify the DOM of its host and if it does so based on un-sanitized user input, it might be possible to perform a conventional XSS attack on the host DOM.
Cross Site Flashing: Cross Site Flash (XSF) occurs when an SWF objects loads another SWF Object. This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form. XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie methods are used. OWASP has a testing guide for XSF. Although not comprehensive, still it is a very good point to start. Read it here.
Server Side Vulnerabilities
Flash Applications seldom makes remote calls to a backend server for various operations like looking up accounts, retrieving additional data and graphics, and performing complex business operations. However, the ability to call remote methods also increases the attack surface exposed by these applications. Flash Applications built with Adobe Flex SDK usually use AMF Objects exchanged over HTTP Protocol as a method of communication. AMF Remoting calls are essentially RPC like calls where the Flash Application is calling a given method defined on the server on a specific AMF Endpoint. An attacker can intercept and tamper the AMF data to compromise the server.
In most of the cases the application server responsible for providing Business Logic to a Flash RIA frontend is a standard web application and can be affected by the very same vulnerabilities as any other web application like as described by the WASC Threat Classification Project.
Testing Flash Applications: Objectives and Approach
A Flash Security Testing exercise for a Flash Based RIA is conducted with the following objectives:
Identify the application entry points and test for possible vulnerabilities in the SWF Object itself.
Identify the remote server with which the application might communicate for its business logic requirements.
Identify the protocol with which the SWF Object is communicating with its back-end server. In most of the cases, the protocol will either be SOAP/REST or AMF.
Identify and enumerate all the functionalities exposed by the back-end application.
Penetration Testing of the individual functionalities exposed by the back-end application for standard application security vulnerabilities.
Client Side Testing
Client side primarily relates to static analysis of the flash application. The idea of static analysis of a Flash SWF Object is to decompile the SWF file and attempt to do a white box testing approach by looking into the source code of the Flash SWF File. Basic approach to test client side vulnerabilities is :
Decompile SWF files into source code (ActionScript) and statically analyzes it to identify security issues such as information disclosure (hard coded).
Audit third party applications without requiring access to the source code.
Common vulnerabilities includes hard coded login credentials, internal IP disclosure, etc.
Apart from analyzing the SWF file, it is also important to analyze the code responsible for generating the HTML file that embeds the SWF object. Under certain circumstances in might be possible to manipulate the FlashVars variable through which SWF inputs can be influenced.
There are however automated tools like HP SWFScan available to do this job upto a certain degree.
Server Side Testing
The best straightforward way to do a server side testing for flash based RIA applications are as follows:
1. Extract Gateway
Load the flash e.g http://foo.com/bar.swf in a browser with service capture/burp proxy/charlesproxy running .
Decompile the SWF using swfdump and grep the gateway patterns. Also get a list of all the urls in SWFdump.
2. Enumerate service/methods
Try amfphp.DiscoveryService on all gateways using Pinta.
Use Pinta for AMF calling even if the services and methods are manually entered and hence can be helpful in testing remote methods.
If it fails try extracting them using regex from SWFDump using the following regular expression.
Services:
–"\"([a-zA-Z0-9_]*)\"“ with filter as “service” (conventional)–"destination id=\"([\\w\\d]*)\"“3. Make AMF calls
Use Pinta to call remote methods using different test parameters.
Single quote (SQL injection), neighbor parameters (Direct Object Reference).
Testing the backend application once the exposed functionalities are enumerated should be more or less conventional to standard web application security testing methodology just that a different protocol (AMF serialized calls in this case) is used for interacting with the server and invoking the functionalities.
Checklist of Vulnerabilities to be tested
Cross Site Scripting
Malicious Data Injection
Insufficient Authorization Restrictions
Secure Transmission
SWF Information Leak
Minimum Stage Size for Anti-ClickJacking
SWF Control Permission
Untrusted SWF in Same Domain
Clickjacking
Privilege Seperation
Cross Domain Policy Audit
Uninitialized Variable Scanning
Remote Method Enumeration
Business Logic Testing
This is a brief guide to testing flash applications. Comments are welcome to make it better and more comprehensive. At the end, we intend to publish a freely available whitepaper to pen testers for testing flash based RIA. Additional sections included in the paper will also carry due credits as received in the comments section below.
http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt
http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt
A short unnecessary introduction on Flash RIA
Adobe Flash (formerly Macromedia Flash) is a multimedia platform originally acquired by Macromedia and currently developed and distributed by Adobe Systems. Since its introduction in 1996, Flash has become a popular method for adding animation and interactivity to web pages. Flash is commonly used to create animation, advertisements, and various web page Flash components, to integrate video into web pages, and more recently, to develop rich Internet applications. Source: en.wikipedia.org/wiki/Adobe_Flash
Conventionally, RIA developed with Adobe Flash technology consists of a frontend application compiled as an SWF/AIR object to be executed by the Flash Plugin inside the User’s Browser or the AIR Platform installed on the User’s System. This interactive application provides a user Interface to the end-user and in turn communicates with a backend server for its business logic over protocols like HTTP/AMF, HTTP/SOAP, HTTP/REST etc.
The security angle..
Similar to any widely used web application and software, a RIA can also be a victim of most common and dangerous security Issues. For example, since most Flash based RIAs are backed by an application for its business logic which in turn uses a database, a Flash based RIA might also be vulnerable to common application vulnerabilities like SQL Injection if user input is not sanitized properly. Quite logical huh?. Attackers can also utilize Flash to execute mass exploitation, for example backdoors or malware entirely written in Flash/ActionScript or BOFs against player/plugin or browser.
It is quite general to deduce that security flaws may also be present in the core environment (which includes the OS and web browsers) that can be exploited regardless of the applications (including Flash Player) running in that environment. A recent paper from Adobe suggests that the approach of Adobe is to implement robust security within its own products while “doing no harm” to the rest of the environment (in other words, to introduce no exposures to the rest of the environment, nor allow any avenues for additional exploitation of any existing platform security weaknesses). This provides a consistently high level of security for what Flash applications can do (as managed within Flash Player), regardless of the platform. Because Adobe products are also designed to be backwards-compatible when possible, some environments may be more vulnerable to weaknesses in the browser or operating system, or have weaker cryptography capabilities. Ultimately, users are responsible for their choices of platforms and maintenance of appropriate operational environments.
Vulnerabilities in flash RIA can be broadly classified under two categories: client side vulnerabilities and server side vulnerabilities. Let’s review each one of these very quickly:
Client Side Vulnerabilities:
Amongst the various vulnerabilities that might affect a Flash Application on the client side, some of the most common ones are:
Flash parameter Injection: It might be possible for an attacker can inject global Flash parameters when the movie is embedded in a parent HTML page. These injected parameters can grant the attacker full control over the page DOM, as well as control over other objects within the Flash movie. There is nice detailed paper by the IBM Rational guys on this vulnerability. You can download it here.
Cross Domain Privilege Escalation: Cross Domain inter-mixing of content and data is done based on access policy defined in crossdomain.xml of the serving domain for the SWF object. If the access policy is too open, then under certain circumstances, it might be possible for an attacker to supersede the original SWF object with his own malicious version or access the DOM of the hosting domain.
Cross Site Scripting: Depending on access policy, a Flash SWF can access its host DOM for various functional use cases. A Flash SWF can in turn modify the DOM of its host and if it does so based on un-sanitized user input, it might be possible to perform a conventional XSS attack on the host DOM.
Cross Site Flashing: Cross Site Flash (XSF) occurs when an SWF objects loads another SWF Object. This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form. XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie methods are used. OWASP has a testing guide for XSF. Although not comprehensive, still it is a very good point to start. Read it here.
Server Side Vulnerabilities
Flash Applications seldom makes remote calls to a backend server for various operations like looking up accounts, retrieving additional data and graphics, and performing complex business operations. However, the ability to call remote methods also increases the attack surface exposed by these applications. Flash Applications built with Adobe Flex SDK usually use AMF Objects exchanged over HTTP Protocol as a method of communication. AMF Remoting calls are essentially RPC like calls where the Flash Application is calling a given method defined on the server on a specific AMF Endpoint. An attacker can intercept and tamper the AMF data to compromise the server.
In most of the cases the application server responsible for providing Business Logic to a Flash RIA frontend is a standard web application and can be affected by the very same vulnerabilities as any other web application like as described by the WASC Threat Classification Project.
Testing Flash Applications: Objectives and Approach
A Flash Security Testing exercise for a Flash Based RIA is conducted with the following objectives:
Identify the application entry points and test for possible vulnerabilities in the SWF Object itself.
Identify the remote server with which the application might communicate for its business logic requirements.
Identify the protocol with which the SWF Object is communicating with its back-end server. In most of the cases, the protocol will either be SOAP/REST or AMF.
Identify and enumerate all the functionalities exposed by the back-end application.
Penetration Testing of the individual functionalities exposed by the back-end application for standard application security vulnerabilities.
Client Side Testing
Client side primarily relates to static analysis of the flash application. The idea of static analysis of a Flash SWF Object is to decompile the SWF file and attempt to do a white box testing approach by looking into the source code of the Flash SWF File. Basic approach to test client side vulnerabilities is :
Decompile SWF files into source code (ActionScript) and statically analyzes it to identify security issues such as information disclosure (hard coded).
Audit third party applications without requiring access to the source code.
Common vulnerabilities includes hard coded login credentials, internal IP disclosure, etc.
Apart from analyzing the SWF file, it is also important to analyze the code responsible for generating the HTML file that embeds the SWF object. Under certain circumstances in might be possible to manipulate the FlashVars variable through which SWF inputs can be influenced.
There are however automated tools like HP SWFScan available to do this job upto a certain degree.
Server Side Testing
The best straightforward way to do a server side testing for flash based RIA applications are as follows:
1. Extract Gateway
Load the flash e.g http://foo.com/bar.swf in a browser with service capture/burp proxy/charlesproxy running .
Decompile the SWF using swfdump and grep the gateway patterns. Also get a list of all the urls in SWFdump.
2. Enumerate service/methods
Try amfphp.DiscoveryService on all gateways using Pinta.
Use Pinta for AMF calling even if the services and methods are manually entered and hence can be helpful in testing remote methods.
If it fails try extracting them using regex from SWFDump using the following regular expression.
Services:
–"\"([a-zA-Z0-9_]*)\"“ with filter as “service” (conventional)–"destination id=\"([\\w\\d]*)\"“3. Make AMF calls
Use Pinta to call remote methods using different test parameters.
Single quote (SQL injection), neighbor parameters (Direct Object Reference).
Testing the backend application once the exposed functionalities are enumerated should be more or less conventional to standard web application security testing methodology just that a different protocol (AMF serialized calls in this case) is used for interacting with the server and invoking the functionalities.
Checklist of Vulnerabilities to be tested
Cross Site Scripting
Malicious Data Injection
Insufficient Authorization Restrictions
Secure Transmission
SWF Information Leak
Minimum Stage Size for Anti-ClickJacking
SWF Control Permission
Untrusted SWF in Same Domain
Clickjacking
Privilege Seperation
Cross Domain Policy Audit
Uninitialized Variable Scanning
Remote Method Enumeration
Business Logic Testing
This is a brief guide to testing flash applications. Comments are welcome to make it better and more comprehensive. At the end, we intend to publish a freely available whitepaper to pen testers for testing flash based RIA. Additional sections included in the paper will also carry due credits as received in the comments section below.
http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt
http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt
methods-of-quick-exploitation-of-blind
SQL Injection vulnerabilities are often detected by analyzing error messages received from the database, but sometimes we cannot exploit the discovered vulnerability using classic methods (e.g., union). Until recently, we had to use boring slow techniques of symbol exhaustion in such cases. But is there any need to apply an ineffective approach, while we have the DBMS error message?! It can be adapted for line-by-line reading of data from a database or a file system, and this technique will be as easy as the classic SQL Injection exploitation. It is foolish not to take advantage of such opportunity! In this paper, we will consider the methods that allow one to use the database error messages as containers for useful data
PDF Silent HTTP Form Repurposing Attacks
This paper sheds light on the modified approach to trigger web attacks through JavaScript protocol handler in the context of browser when a PDF is opened in it. As we have seen, the kind of security mechanism implemented by Adobe in order to remove the insecurities that originate directly from the standalone PDF document in order to circumvent cross domain access. The attack is targeted on the web applications that allow PDF documents to be uploaded on the web server. Due to ingrained security mechanism in PDF Reader, it is hard to launch certain attacks. But with this technique an attacker can steal generic information from website by executing the code directly in the context of the domain where it is uploaded. The attack surface can be diversified by randomizing the attack vector. On further analysis it has been observed that it is possible to trigger phishing attacks too. Successful attacks have been conducted on number of web applications mainly to extract information based on DOM objects. The paper exposes a differential behavior of Acro JS and Brower JavaScript.
PDF
NMAP Trivia ANSWERS: Mastering Network Mapping and Scanning
Three weeks ago I published the NMAP Trivia challenge. Thanks to all ISC readers that submitted their responses! A special mention goes to the winning entry from Jason DePriest, an extensive and elaborated submission, available here. Congratulations! The prize (technical book) is on his way! ;)
Jon Kibler provided an in-progress nmap idea for a new features, a scan proxy engine equivalent to the FTP bounce scan to scan through HTTP or SOCKS.
Now... it is time for the answers:
1. What are the default target ports used by the current nmap version (4.76)? How can you change the target ports list? What (nmap) options can be used to speed up scans by reducing the number of target ports and still check (potentially) the most relevant ones? How can you force nmap to check all target ports?
Fyodor performed a thorough port scan research this last summer to identify the most common ports available on the Internet [1]. The current nmap version scans by default the 1000 most popular ports. The popularity of each port is coded inside the nmap-services configuration file (by default under /usr/local/share/nmap).
...
unknown 4/tcp 0.000477
rje 5/udp 0.000593 # Remote Job Entry
unknown 6/tcp 0.000502
echo 7/tcp 0.004855
echo 7/udp 0.024679
unknown 8/tcp 0.000013
...
Nmap provides an option for quick scans, "-F". It scans the 100 most popular ports, reducing the default load in one order of magnitude. Additionally, you can decide how many popular ports you want to scan through the "--top-ports N" option, where "N" is the top number of ports.
# ./nmap -F scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:44 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
Not shown: 95 filtered ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp closed smtp
53/tcp open domain
80/tcp open http
113/tcp closed auth
Nmap done: 1 IP address (1 host up) scanned in 4.04 seconds
# ./nmap --top-ports 5 scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:44 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
21/tcp filtered ftp
22/tcp open ssh
23/tcp filtered telnet
80/tcp open http
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 8.56 seconds
Finally, nmap allows you to define the specific set of ports to scan through the "-p" option, as in "-pT:22,80,443,U:53,69,514". All ports, including port 0, can be scanned by providing the "-p0-" option, meaning from 0 till the end of the range, that is, port 65535. You need to specify if they are TCP or UDP ports, or both ("-sSU").
# nmap -p0- scanme.nmap.org
[1] http://insecure.org/presentations/BHDC08/
2. How can you force nmap to scan a specific list of 200 target ports, only relevant to you?
If you don't want to scan the most popular ports, you can tell nmap what particular list of ports to scan by specifying them with the "-p" option, one by one or in ranges, like in "-p 20-23,25,80,443". Because this can be too tedious for long lists of ports, the recommended way is to copy and edit the "nmap-services" file and create a custom version containing your list of interesting ports. The new custom file can be referenced using the "--servicedb" (for individual files) or "--datadir" (for the configuration files directory) options, as in:
# nmap --datadir ./myconfig scanme.nmap.org
If your custom file contains more than 200 target services, then you can use the "--top-ports 200" option again. The specific file and directory search order followed by nmap is detailed on page 370 of the nmap book: http://nmap.org/book/data-files-replacing-data-files.html.
3. What is the default port used by nmap for UDP ping discovery (-PU)? Why? If you don't know it from the top of your head ;), how can you easily identify this port without using other tools (such as a sniffer) or inspecting nmap's source code?
By default, nmap sends an empty UDP packet to port UDP/31338 for the UDP ping discovery method ("-PU"). The reason is that there is a high chance this random high port is closed. This is the preferred state expected by nmap trying to elicit an ICMP port unreachable packet in return and, as a result, identify the existence of a new host. The port number is defined in nmap.h, specifically in the DEFAULT_UDP_PROBE_PORT_SPEC constant. Did you notice it is 31337 plus 1, the elite port (31337 in haxor speech) plus one.
Currently, nmap provides the "--packet-trace" option to gather detailed information about the network traffic and individual packets sent and received during its operations. Effectively, this option acts as a built in sniffer, very useful to get details about what nmap is doing on the backstage.
# nmap -PU --packet-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:58 GMT
SENT (0.6580s) UDP 192.168.166.166:59676 > 64.13.134.52:31338 ttl=58 id=45958 iplen=28
SENT (1.6560s) UDP 192.168.166.166:59677 > 64.13.134.52:31338 ttl=59 id=46599 iplen=28
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 2.68 seconds
4. When nmap is run, sometimes it is difficult to know what is going on the backstage. What two (nmap) options allow you to gather detailed but not overwhelming information about nmap's port scanning operations? What other extra (nmap) options are available for ultra detailed information?
The first of the options has been mentioned and used on the previous question, "--packet-trace". It allows to get a tcpdump-like output about packets sent and received. Additionally, nmap provides the "--reason" option to display the reason why a port has been clasiffied on an specific state: open, closed, filtered, etc.
# nmap -F -sSU --reason scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:00 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
Not shown: 99 open|filtered ports, 96 filtered ports
Reason: 194 no-responses and 1 admin-prohibited
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack
25/tcp closed smtp reset
53/tcp open domain syn-ack
80/tcp open http syn-ack
113/tcp closed auth reset
Nmap done: 1 IP address (1 host up) scanned in 7.95 seconds
# nmap -F -sU --reason scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:02 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
Not shown: 99 open|filtered ports
Reason: 99 no-responses
PORT STATE SERVICE REASON
520/udp filtered route admin-prohibited from 192.168.15.1
Nmap done: 1 IP address (1 host up) scanned in 15.90 seconds
For those interested on gathering as much information as possible about nmap's operations, the "-v" verbosity option, or the "-dN" debugging option are available. These options specify nmap to be verbose (multiple verbosity levels are allowed), or the nmap debug level for troubleshooting purposes, where N can have a value between 1 and 9. Be careful when you use it! Try it and be ready for a Matrix-like output 8-)
# nmap -p80 -sS -v scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:07 GMT
Initiating Ping Scan at 11:07
Scanning 64.13.134.52 [2 ports]
Completed Ping Scan at 11:07, 0.24s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:07
Completed Parallel DNS resolution of 1 host. at 11:07, 0.24s elapsed
Initiating SYN Stealth Scan at 11:07
Scanning scanme.nmap.org (64.13.134.52) [1 port]
Discovered open port 80/tcp on 64.13.134.52
Completed SYN Stealth Scan at 11:07, 0.26s elapsed (1 total ports)
Host scanme.nmap.org (64.13.134.52) appears to be up ... good.
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
80/tcp open http
Read data files from: .
Nmap done: 1 IP address (1 host up) scanned in 6.13 seconds
Raw packets sent: 3 (112B) | Rcvd: 2 (72B)
# nmap -p80 -sS -d1 scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:08 GMT
--------------- Timing report ---------------
...
---------------------------------------------
Initiating Ping Scan at 11:08
Scanning 64.13.134.52 [2 ports]
...
Nmap done: 1 IP address (1 host up) scanned in 0.74 seconds
Raw packets sent: 3 (112B) | Rcvd: 2 (72B)
Try it by your own! ;)
5. What are the preferred (nmap) options to run a stealthy TCP port scan? Particularly, try to avoid detection from someone running a sniffer near the person running nmap and focus on the extra actions performed by the tool (assuming the packets required to complete the port scan are not detected)?
Most current network IDS can detect the default packets generated by nmap when port scanning a target. We are assuming here these cannot be detected, so a stealthier scan can be launched by using the "-n" option (not used in any of the Nmap Trivia examples), that is, disable all reverse DNS resolution at the nmap level. Most Unix-based security tools provide this same option for the same purpose.
# nmap -F -n scanme.nmap.org
However, this way you lose the sometimes valuable DNS information. You can use the "--dns-servers" option to indicate the DNS recursive servers to use as DNS proxies when analyzing the target IP address.
More stealthier details on answer number 12.
6. Why port number 49152 is relevant to nmap?
Port 49152 is the first of the ephemeral ports for dynamic usage based on IANA. However, the port assignment depends on the implementation of your tools or operating system. See http://www.iana.org/assignments/port-numbers:
- The Well Known Ports are those from 0 through 1023
- The Registered Ports are those from 1024 through 49151
- The Dynamic and/or Private Ports are those from 49152 through 65535
7. What is the only nmap TCP scan type that classifies the target ports as "unfiltered"? Why? What additional nmap scan type can be used to discern if those ports (previously identified as "unfiltered") are in an open or closed state?
The only nmap scan type that can show a port in the "unfiltered" state is the TCP ACK scan, "-sA" option. The reason is because this scan cannot differentiate between an open and closed port, as a target hosts (if unfiltered) will always reply with a RST packet. This is the standard behaviour for a closed port, and is also standar for an open port for which there is not a previously established connection to map the ACK packet to. Therefore, nmap's ACK scan cannot be considered a port scan, as it cannot differentiate between port states, but a host discovery scan.
The TCP Window scan, "-sW" option, is similar to the TCP ACK scan, but it can differentiate between open and closed ports is some scenarios.
8. When (and it what nmap version) the default state for a non-responsive UDP port was changed on nmap (from "open" to "open|filtered")? Why?
The default state for a non-responsive UDP port was changed (from "open" to "open|filtered") on nmap version v3.70 in 2004. The reason was accurancy, as extensive use of filtering devices by that time made filtered UDP ports always appear as open in previous nmap versions.
9. What is the default scan type used by nmap when none is specified, as in "nmap -T4 scanme.nmap.org"? Is this always the default scan method? If not, what other scan method does nmap default to, under what conditions, and why?
The current nmap version performs a TCP SYN scan ("-sS" option) by default when no scan type is specified. However, this is only the default behavior when nmap is launched as a privileged user (eg. root in Linux). The TCP connect scan, "-sT" option (connect() syscall), is used by default with non-privileged users as these cannot send raw packets (used by the SYN scan) or if there are IPv6 targets.
# ./nmap -PN -p80,81 --packet-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:22 GMT
...
SENT (0.3730s) TCP 192.168.166.166:56464 > 64.13.134.52:80 S ttl=50 \
id=8102 iplen=44 seq=1698869517 win=3072
SENT (0.3740s) TCP 192.168.166.166:56464 > 64.13.134.52:81 S ttl=43 \
id=48226 iplen=44 seq=1698869517 win=4096
RCVD (0.6120s) TCP 64.13.134.52:80 > 192.168.166.166:56464 SA ttl=48 \
id=0 iplen=44 seq=2849983456 win=5840 ack=1698869518
RCVD (1.9570s) TCP 64.13.134.52:80 > 192.168.166.166:40972 SA ttl=48 \
id=0 iplen=44 seq=2805666242 win=5840 ack=2103880733
SENT (2.5730s) TCP 192.168.166.166:56465 > 64.13.134.52:81 S ttl=55 \
id=14744 iplen=44 seq=1698935052 win=4096
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
80/tcp open http
81/tcp filtered hosts2-ns
Nmap done: 1 IP address (1 host up) scanned in 3.79 seconds
$ ./nmap -PN -p80,81 --packet-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:25 GMT
...
CONN (0.1290s) TCP localhost > 64.13.134.52:80 => Operation now in progress
CONN (0.1290s) TCP localhost > 64.13.134.52:81 => Operation now in progress
CONN (2.3510s) TCP localhost > 64.13.134.52:81 => Operation now in progress
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
80/tcp open http
81/tcp filtered hosts2-ns
Nmap done: 1 IP address (1 host up) scanned in 3.57 seconds
10. What nmap features (can make or) make use of nmap's raw packet capabilities? What nmap features rely on the OS TCP/IP stack instead?
Nmap makes use of the raw packet capabilities by default, "--send-eth" option, as demonstrated in the previous question for some features, such as TCP and UDP port scans launched by privileged users (except for the connect scan and the FTP bounce scan), or fragmentation probes. Other features like the Nmap Scripting Engine and version detection relay on the OS TCP/IP stack.
11. Nmap's performance has been sometimes criticized versus other network scanners. What (nmap) options can you use to convert nmap into a faster, stateless scanner for high performance but less accurate results?
If the congestion controls and packet loss detection algorithms are omitted, a scanner will run faster. Nmap can achieve a similar behaviour as stateless scanners, no code to track and retransmit probes, using the following options:
# ./nmap --min-rate 1000 --max-retries 0 ...
These indicate nmap to send at least 1000 packets per second (if your system or wire can) and disable retransmission of timed-out probes. However, take into account the impact this might have in the accurancy of the results.
# ./nmap -PN -n --min-rate 1000 --max-retries 0 -F scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 12:08 GMT
Warning: Giving up on port early because retransmission cap hit.
Interesting ports on 64.13.134.52:
Not shown: 95 filtered ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp closed smtp
53/tcp open domain
80/tcp open http
113/tcp closed auth
Nmap done: 1 IP address (1 host up) scanned in 1.06 seconds
12. What relevant nmap feature does not allow an attacker to use the decoy functionality (-D) and might reveal his real IP address?
Apart from the previously mentioned "-n" option to run stealthier scans and avoid IDS detection, there are other related options, such as "--data-length", to change the default empty packet used for some probes, "--ttl" to modify the TTL on the sent packets, timing options ("-T"), "--randomize-hosts" to change the order the target hosts are scanned, or "-D" to launch a decoy scan (simulate the scan is coming from multiple hosts).
Decoys are used in the ping discovery, port scanning, and remote OS detection phases. However, this feature does not apply when DNS queries or service version detection ("-sV" or "-A") are used, being the source IP address disclosed.
13. What are the (nmap) options you can use to identify all the steps followed by nmap to fingerprint and identify the Web server version running on scanme.nmap.org?
# ./nmap -sSV -p80 --version-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 12:17 GMT
...
SCRIPT ENGINE: Initiating script scanning.
SCRIPT ENGINE: Script scanning scanme.nmap.org (64.13.134.52).
SCRIPT ENGINE: Initialized 4 rules
SCRIPT ENGINE: Matching rules.
SCRIPT ENGINE: Running scripts.
SCRIPT ENGINE: Script scanning completed.
Scanned at 2009-01-21 12:17:57 GMT for 8s
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.2 ((Fedora))
Final times for host: srtt: 238764 rttvar: 179294 to: 955940
Read from .: nmap-rpc nmap-service-probes nmap-services.
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.17 seconds
The "-sSV" option allows you to focus on a TCP scan type (SYN scan in this case, "-sS"), and fingerprint the service ("-sV"). In order to just target the web server (supposing HTTP (TCP/80) is the target port, and not HTTPS (TCP/443)), the "-p80" option must be used.
The "--version-trace" option is similar to the "--packet-trace" option, but instead of dumping the network traffic, it dumps all the actions or steps performed by nmap during the execution of the service fingerprinting modules. Additionally, other debug options ("-dN") can be added to gather further details.
14. As an attacker, what port number would you select to hide a listening service backdoor trying to avoid an accurate detection by nmap's default aggressive fingerprinting tests? Would it be TCP or UDP? Why? What additional (nmap) options do you need to specify as a defender to fingerprint the hidden service backdoor?
If a port in the range of TCP/9100-9107 is selected for a backdoor, due to the fact these are common ports for printer services, nmap won`t fingerprint the service. These ports are excluded by default on the service fingerprinting tests ("-sV") or aggressive scan options ("-A") trying to save the planet, trees and forests specifically, by not making printers dump dozens of pages full of nmap probes and garbage as a result of the stimulous received from the scan.
If you want to enable service fingerprinting on all ports, there are two options. The "--allports" option can be specified, as in "nmap -A --allports", or the nmap-service-probes file can be modified to enable these ports by removing the "Exclude" directive.
15. What is the language used to write NSE scripts, and what two other famous open-source security tools/projects currently use the same language?
Nmap uses the LUA (www.lua.org) programming language. LUA (pronounced LOO-ah) means "Moon" in Portuguese, or "Luna" in Spanish ;) Other famous open-source security tools, like Wireshark and Snort use LUA to extend their capabilities.
16. What Linux/Windows command can you use to identify the list of NSE scripts that belong to the "discovery" category and will execute when this set of scripts is selected with the "--script discovery" nmap option?
By default, NSE scripts are available under the "scripts" directory (however, nmap searched in other locations too: --datadir, $NAMPDIR, etc), with the ".nse" file extension. All NSE scripts belong to one or more categories, define inside the script, and indexed by the scripts/script.db database (if updated through the "--script-updatedb" option).
Therefore a couple of options to search for discovery scripts in Linux are:
# grep discovery scripts/*.nse
scripts/ASN.nse:categories = {"discovery", "external"}
scripts/HTTP_open_proxy.nse:categories = {"default", "discovery", "external", "intrusive"}
scripts/HTTPtrace.nse:categories = {"discovery"}
...
# grep discovery scripts/script.db
Entry{ category = "discovery", filename = "HTTPtrace.nse" }
Entry{ category = "discovery", filename = "rpcinfo.nse" }
Entry{ category = "discovery", filename = "SMTPcommands.nse" }
...
You can perform a similar search in Windows using the built-in search capabilities (searching by "A word or phrase in the file" to look inside the directory) or the find or findstr commands (to search within a file or set of files).
17. How can you know the specific arguments accepted by a specific NSE script, such as those accepted by the whois.nse script?
In order to identify the arguments that can be passed through the "--script-args" option to a NSE script, eg. whois.nse, check the documentation or code within the script file. If it is properly documented, search by "-- @args" to go to the arguments documentation section.
Finally, a couple of extra questions for the real nmap-lovers:
How can you get in real-time the open ports discoverd by nmap before the final report is displayed?
What happens when you run nmap in verbose mode on September 1?
That's all folks! Happy nmap discovery and scanning!
Jon Kibler provided an in-progress nmap idea for a new features, a scan proxy engine equivalent to the FTP bounce scan to scan through HTTP or SOCKS.
Now... it is time for the answers:
1. What are the default target ports used by the current nmap version (4.76)? How can you change the target ports list? What (nmap) options can be used to speed up scans by reducing the number of target ports and still check (potentially) the most relevant ones? How can you force nmap to check all target ports?
Fyodor performed a thorough port scan research this last summer to identify the most common ports available on the Internet [1]. The current nmap version scans by default the 1000 most popular ports. The popularity of each port is coded inside the nmap-services configuration file (by default under /usr/local/share/nmap).
...
unknown 4/tcp 0.000477
rje 5/udp 0.000593 # Remote Job Entry
unknown 6/tcp 0.000502
echo 7/tcp 0.004855
echo 7/udp 0.024679
unknown 8/tcp 0.000013
...
Nmap provides an option for quick scans, "-F". It scans the 100 most popular ports, reducing the default load in one order of magnitude. Additionally, you can decide how many popular ports you want to scan through the "--top-ports N" option, where "N" is the top number of ports.
# ./nmap -F scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:44 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
Not shown: 95 filtered ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp closed smtp
53/tcp open domain
80/tcp open http
113/tcp closed auth
Nmap done: 1 IP address (1 host up) scanned in 4.04 seconds
# ./nmap --top-ports 5 scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:44 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
21/tcp filtered ftp
22/tcp open ssh
23/tcp filtered telnet
80/tcp open http
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 8.56 seconds
Finally, nmap allows you to define the specific set of ports to scan through the "-p" option, as in "-pT:22,80,443,U:53,69,514". All ports, including port 0, can be scanned by providing the "-p0-" option, meaning from 0 till the end of the range, that is, port 65535. You need to specify if they are TCP or UDP ports, or both ("-sSU").
# nmap -p0- scanme.nmap.org
[1] http://insecure.org/presentations/BHDC08/
2. How can you force nmap to scan a specific list of 200 target ports, only relevant to you?
If you don't want to scan the most popular ports, you can tell nmap what particular list of ports to scan by specifying them with the "-p" option, one by one or in ranges, like in "-p 20-23,25,80,443". Because this can be too tedious for long lists of ports, the recommended way is to copy and edit the "nmap-services" file and create a custom version containing your list of interesting ports. The new custom file can be referenced using the "--servicedb" (for individual files) or "--datadir" (for the configuration files directory) options, as in:
# nmap --datadir ./myconfig scanme.nmap.org
If your custom file contains more than 200 target services, then you can use the "--top-ports 200" option again. The specific file and directory search order followed by nmap is detailed on page 370 of the nmap book: http://nmap.org/book/data-files-replacing-data-files.html.
3. What is the default port used by nmap for UDP ping discovery (-PU)? Why? If you don't know it from the top of your head ;), how can you easily identify this port without using other tools (such as a sniffer) or inspecting nmap's source code?
By default, nmap sends an empty UDP packet to port UDP/31338 for the UDP ping discovery method ("-PU"). The reason is that there is a high chance this random high port is closed. This is the preferred state expected by nmap trying to elicit an ICMP port unreachable packet in return and, as a result, identify the existence of a new host. The port number is defined in nmap.h, specifically in the DEFAULT_UDP_PROBE_PORT_SPEC constant. Did you notice it is 31337 plus 1, the elite port (31337 in haxor speech) plus one.
Currently, nmap provides the "--packet-trace" option to gather detailed information about the network traffic and individual packets sent and received during its operations. Effectively, this option acts as a built in sniffer, very useful to get details about what nmap is doing on the backstage.
# nmap -PU --packet-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:58 GMT
SENT (0.6580s) UDP 192.168.166.166:59676 > 64.13.134.52:31338 ttl=58 id=45958 iplen=28
SENT (1.6560s) UDP 192.168.166.166:59677 > 64.13.134.52:31338 ttl=59 id=46599 iplen=28
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 2.68 seconds
4. When nmap is run, sometimes it is difficult to know what is going on the backstage. What two (nmap) options allow you to gather detailed but not overwhelming information about nmap's port scanning operations? What other extra (nmap) options are available for ultra detailed information?
The first of the options has been mentioned and used on the previous question, "--packet-trace". It allows to get a tcpdump-like output about packets sent and received. Additionally, nmap provides the "--reason" option to display the reason why a port has been clasiffied on an specific state: open, closed, filtered, etc.
# nmap -F -sSU --reason scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:00 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
Not shown: 99 open|filtered ports, 96 filtered ports
Reason: 194 no-responses and 1 admin-prohibited
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack
25/tcp closed smtp reset
53/tcp open domain syn-ack
80/tcp open http syn-ack
113/tcp closed auth reset
Nmap done: 1 IP address (1 host up) scanned in 7.95 seconds
# nmap -F -sU --reason scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:02 GMT
Interesting ports on scanme.nmap.org (64.13.134.52):
Not shown: 99 open|filtered ports
Reason: 99 no-responses
PORT STATE SERVICE REASON
520/udp filtered route admin-prohibited from 192.168.15.1
Nmap done: 1 IP address (1 host up) scanned in 15.90 seconds
For those interested on gathering as much information as possible about nmap's operations, the "-v" verbosity option, or the "-dN" debugging option are available. These options specify nmap to be verbose (multiple verbosity levels are allowed), or the nmap debug level for troubleshooting purposes, where N can have a value between 1 and 9. Be careful when you use it! Try it and be ready for a Matrix-like output 8-)
# nmap -p80 -sS -v scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:07 GMT
Initiating Ping Scan at 11:07
Scanning 64.13.134.52 [2 ports]
Completed Ping Scan at 11:07, 0.24s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:07
Completed Parallel DNS resolution of 1 host. at 11:07, 0.24s elapsed
Initiating SYN Stealth Scan at 11:07
Scanning scanme.nmap.org (64.13.134.52) [1 port]
Discovered open port 80/tcp on 64.13.134.52
Completed SYN Stealth Scan at 11:07, 0.26s elapsed (1 total ports)
Host scanme.nmap.org (64.13.134.52) appears to be up ... good.
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
80/tcp open http
Read data files from: .
Nmap done: 1 IP address (1 host up) scanned in 6.13 seconds
Raw packets sent: 3 (112B) | Rcvd: 2 (72B)
# nmap -p80 -sS -d1 scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:08 GMT
--------------- Timing report ---------------
...
---------------------------------------------
Initiating Ping Scan at 11:08
Scanning 64.13.134.52 [2 ports]
...
Nmap done: 1 IP address (1 host up) scanned in 0.74 seconds
Raw packets sent: 3 (112B) | Rcvd: 2 (72B)
Try it by your own! ;)
5. What are the preferred (nmap) options to run a stealthy TCP port scan? Particularly, try to avoid detection from someone running a sniffer near the person running nmap and focus on the extra actions performed by the tool (assuming the packets required to complete the port scan are not detected)?
Most current network IDS can detect the default packets generated by nmap when port scanning a target. We are assuming here these cannot be detected, so a stealthier scan can be launched by using the "-n" option (not used in any of the Nmap Trivia examples), that is, disable all reverse DNS resolution at the nmap level. Most Unix-based security tools provide this same option for the same purpose.
# nmap -F -n scanme.nmap.org
However, this way you lose the sometimes valuable DNS information. You can use the "--dns-servers" option to indicate the DNS recursive servers to use as DNS proxies when analyzing the target IP address.
More stealthier details on answer number 12.
6. Why port number 49152 is relevant to nmap?
Port 49152 is the first of the ephemeral ports for dynamic usage based on IANA. However, the port assignment depends on the implementation of your tools or operating system. See http://www.iana.org/assignments/port-numbers:
- The Well Known Ports are those from 0 through 1023
- The Registered Ports are those from 1024 through 49151
- The Dynamic and/or Private Ports are those from 49152 through 65535
7. What is the only nmap TCP scan type that classifies the target ports as "unfiltered"? Why? What additional nmap scan type can be used to discern if those ports (previously identified as "unfiltered") are in an open or closed state?
The only nmap scan type that can show a port in the "unfiltered" state is the TCP ACK scan, "-sA" option. The reason is because this scan cannot differentiate between an open and closed port, as a target hosts (if unfiltered) will always reply with a RST packet. This is the standard behaviour for a closed port, and is also standar for an open port for which there is not a previously established connection to map the ACK packet to. Therefore, nmap's ACK scan cannot be considered a port scan, as it cannot differentiate between port states, but a host discovery scan.
The TCP Window scan, "-sW" option, is similar to the TCP ACK scan, but it can differentiate between open and closed ports is some scenarios.
8. When (and it what nmap version) the default state for a non-responsive UDP port was changed on nmap (from "open" to "open|filtered")? Why?
The default state for a non-responsive UDP port was changed (from "open" to "open|filtered") on nmap version v3.70 in 2004. The reason was accurancy, as extensive use of filtering devices by that time made filtered UDP ports always appear as open in previous nmap versions.
9. What is the default scan type used by nmap when none is specified, as in "nmap -T4 scanme.nmap.org"? Is this always the default scan method? If not, what other scan method does nmap default to, under what conditions, and why?
The current nmap version performs a TCP SYN scan ("-sS" option) by default when no scan type is specified. However, this is only the default behavior when nmap is launched as a privileged user (eg. root in Linux). The TCP connect scan, "-sT" option (connect() syscall), is used by default with non-privileged users as these cannot send raw packets (used by the SYN scan) or if there are IPv6 targets.
# ./nmap -PN -p80,81 --packet-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:22 GMT
...
SENT (0.3730s) TCP 192.168.166.166:56464 > 64.13.134.52:80 S ttl=50 \
id=8102 iplen=44 seq=1698869517 win=3072
SENT (0.3740s) TCP 192.168.166.166:56464 > 64.13.134.52:81 S ttl=43 \
id=48226 iplen=44 seq=1698869517 win=4096
RCVD (0.6120s) TCP 64.13.134.52:80 > 192.168.166.166:56464 SA ttl=48 \
id=0 iplen=44 seq=2849983456 win=5840 ack=1698869518
RCVD (1.9570s) TCP 64.13.134.52:80 > 192.168.166.166:40972 SA ttl=48 \
id=0 iplen=44 seq=2805666242 win=5840 ack=2103880733
SENT (2.5730s) TCP 192.168.166.166:56465 > 64.13.134.52:81 S ttl=55 \
id=14744 iplen=44 seq=1698935052 win=4096
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
80/tcp open http
81/tcp filtered hosts2-ns
Nmap done: 1 IP address (1 host up) scanned in 3.79 seconds
$ ./nmap -PN -p80,81 --packet-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:25 GMT
...
CONN (0.1290s) TCP localhost > 64.13.134.52:80 => Operation now in progress
CONN (0.1290s) TCP localhost > 64.13.134.52:81 => Operation now in progress
CONN (2.3510s) TCP localhost > 64.13.134.52:81 => Operation now in progress
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE
80/tcp open http
81/tcp filtered hosts2-ns
Nmap done: 1 IP address (1 host up) scanned in 3.57 seconds
10. What nmap features (can make or) make use of nmap's raw packet capabilities? What nmap features rely on the OS TCP/IP stack instead?
Nmap makes use of the raw packet capabilities by default, "--send-eth" option, as demonstrated in the previous question for some features, such as TCP and UDP port scans launched by privileged users (except for the connect scan and the FTP bounce scan), or fragmentation probes. Other features like the Nmap Scripting Engine and version detection relay on the OS TCP/IP stack.
11. Nmap's performance has been sometimes criticized versus other network scanners. What (nmap) options can you use to convert nmap into a faster, stateless scanner for high performance but less accurate results?
If the congestion controls and packet loss detection algorithms are omitted, a scanner will run faster. Nmap can achieve a similar behaviour as stateless scanners, no code to track and retransmit probes, using the following options:
# ./nmap --min-rate 1000 --max-retries 0 ...
These indicate nmap to send at least 1000 packets per second (if your system or wire can) and disable retransmission of timed-out probes. However, take into account the impact this might have in the accurancy of the results.
# ./nmap -PN -n --min-rate 1000 --max-retries 0 -F scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 12:08 GMT
Warning: Giving up on port early because retransmission cap hit.
Interesting ports on 64.13.134.52:
Not shown: 95 filtered ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp closed smtp
53/tcp open domain
80/tcp open http
113/tcp closed auth
Nmap done: 1 IP address (1 host up) scanned in 1.06 seconds
12. What relevant nmap feature does not allow an attacker to use the decoy functionality (-D) and might reveal his real IP address?
Apart from the previously mentioned "-n" option to run stealthier scans and avoid IDS detection, there are other related options, such as "--data-length", to change the default empty packet used for some probes, "--ttl" to modify the TTL on the sent packets, timing options ("-T"), "--randomize-hosts" to change the order the target hosts are scanned, or "-D" to launch a decoy scan (simulate the scan is coming from multiple hosts).
Decoys are used in the ping discovery, port scanning, and remote OS detection phases. However, this feature does not apply when DNS queries or service version detection ("-sV" or "-A") are used, being the source IP address disclosed.
13. What are the (nmap) options you can use to identify all the steps followed by nmap to fingerprint and identify the Web server version running on scanme.nmap.org?
# ./nmap -sSV -p80 --version-trace scanme.nmap.org
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 12:17 GMT
...
SCRIPT ENGINE: Initiating script scanning.
SCRIPT ENGINE: Script scanning scanme.nmap.org (64.13.134.52).
SCRIPT ENGINE: Initialized 4 rules
SCRIPT ENGINE: Matching rules.
SCRIPT ENGINE: Running scripts.
SCRIPT ENGINE: Script scanning completed.
Scanned at 2009-01-21 12:17:57 GMT for 8s
Interesting ports on scanme.nmap.org (64.13.134.52):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.2 ((Fedora))
Final times for host: srtt: 238764 rttvar: 179294 to: 955940
Read from .: nmap-rpc nmap-service-probes nmap-services.
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.17 seconds
The "-sSV" option allows you to focus on a TCP scan type (SYN scan in this case, "-sS"), and fingerprint the service ("-sV"). In order to just target the web server (supposing HTTP (TCP/80) is the target port, and not HTTPS (TCP/443)), the "-p80" option must be used.
The "--version-trace" option is similar to the "--packet-trace" option, but instead of dumping the network traffic, it dumps all the actions or steps performed by nmap during the execution of the service fingerprinting modules. Additionally, other debug options ("-dN") can be added to gather further details.
14. As an attacker, what port number would you select to hide a listening service backdoor trying to avoid an accurate detection by nmap's default aggressive fingerprinting tests? Would it be TCP or UDP? Why? What additional (nmap) options do you need to specify as a defender to fingerprint the hidden service backdoor?
If a port in the range of TCP/9100-9107 is selected for a backdoor, due to the fact these are common ports for printer services, nmap won`t fingerprint the service. These ports are excluded by default on the service fingerprinting tests ("-sV") or aggressive scan options ("-A") trying to save the planet, trees and forests specifically, by not making printers dump dozens of pages full of nmap probes and garbage as a result of the stimulous received from the scan.
If you want to enable service fingerprinting on all ports, there are two options. The "--allports" option can be specified, as in "nmap -A --allports", or the nmap-service-probes file can be modified to enable these ports by removing the "Exclude" directive.
15. What is the language used to write NSE scripts, and what two other famous open-source security tools/projects currently use the same language?
Nmap uses the LUA (www.lua.org) programming language. LUA (pronounced LOO-ah) means "Moon" in Portuguese, or "Luna" in Spanish ;) Other famous open-source security tools, like Wireshark and Snort use LUA to extend their capabilities.
16. What Linux/Windows command can you use to identify the list of NSE scripts that belong to the "discovery" category and will execute when this set of scripts is selected with the "--script discovery" nmap option?
By default, NSE scripts are available under the "scripts" directory (however, nmap searched in other locations too: --datadir, $NAMPDIR, etc), with the ".nse" file extension. All NSE scripts belong to one or more categories, define inside the script, and indexed by the scripts/script.db database (if updated through the "--script-updatedb" option).
Therefore a couple of options to search for discovery scripts in Linux are:
# grep discovery scripts/*.nse
scripts/ASN.nse:categories = {"discovery", "external"}
scripts/HTTP_open_proxy.nse:categories = {"default", "discovery", "external", "intrusive"}
scripts/HTTPtrace.nse:categories = {"discovery"}
...
# grep discovery scripts/script.db
Entry{ category = "discovery", filename = "HTTPtrace.nse" }
Entry{ category = "discovery", filename = "rpcinfo.nse" }
Entry{ category = "discovery", filename = "SMTPcommands.nse" }
...
You can perform a similar search in Windows using the built-in search capabilities (searching by "A word or phrase in the file" to look inside the directory) or the find or findstr commands (to search within a file or set of files).
17. How can you know the specific arguments accepted by a specific NSE script, such as those accepted by the whois.nse script?
In order to identify the arguments that can be passed through the "--script-args" option to a NSE script, eg. whois.nse, check the documentation or code within the script file. If it is properly documented, search by "-- @args" to go to the arguments documentation section.
Finally, a couple of extra questions for the real nmap-lovers:
How can you get in real-time the open ports discoverd by nmap before the final report is displayed?
What happens when you run nmap in verbose mode on September 1?
That's all folks! Happy nmap discovery and scanning!
Certificate-based Client Authentication in WebApp PenTests
http://www.radajo.com/2009/10/sqlninja-metasploit-demo.html
One of the key attack tools to perform effective Web Application Penetration Tests (WebApp PenTest) are interception proxies, allowing the analyst to inspect and modify all the requests and responses exchanged between the web browser and the target web application. Some of the most popular ones are developed in Java, such as Paros, Webscarab or Burp, being the Java platform a prerequisite to run.
Sun/Oracle has recently released new updates for Java: Java 6 Update 19 on March 2010, fixing 27 security issues, and Java 6 Update 20 on April 2010, including a couple of fixes. If you have updated the Java version of your pentesting system (You did, didn't you?), you must be aware that your interception proxies won't be able to audit web applications that make use of client X.509 certificates for authentication. This specifically affects pentests on e-government and e-banking web applications making use of client certificates, such as those stored on smart cards (like some European national identity cards); in particular for Spain, dozens of websites integrate authentication through the electronic national id card, "DNI electronico" (DNIe).
The reason is that Java 6 Update 19 includes a fix for the famous SSL/TLS renegotiation vulnerability from November 2009 (CVE-2009-3555). The SSL/TLS renegotiation feature is specifically used by certificate-based client authentication, and the fix disables SSL/TLS renegotiation in the Java Secure Sockets Extension (JSSE) by default. As a result, when you try to access a web resource that requires certificate-based client authentication through the interception proxy, it generates the following Java SSL/TLS error message (javax.net.ssl.SSLException): "HelloRequest followed by an unexpected handshake message".
Webscarab error message:
Burp error message:
However, it is still possible to re-enable the SSL/TLS renegotiation in Java by setting the new system property sun.security.ssl.allowUnsafeRenegotiation to true before the JSSE library is initialized. The following Windows command line launches Burp with SSL/TLS renegotiation enabled:
C:\>java -jar -Xmx512m -Dsun.security.ssl.allowUnsafeRenegotiation=true "C:\Program Files\burpsuite_pro_v1.3\burpsuite_pro_v1.3.jar"
Keep your WebApp PenTests rolling!
Shameless plug: Interested on learning the art of WebApp PenTesting? I will be teaching SANS SEC542, "Web Application Penetration Testing and Ethical Hacking", in London (May 10-15, 2010) in English and in Madrid (September 20-25, 2010) in Spanish.
One of the key attack tools to perform effective Web Application Penetration Tests (WebApp PenTest) are interception proxies, allowing the analyst to inspect and modify all the requests and responses exchanged between the web browser and the target web application. Some of the most popular ones are developed in Java, such as Paros, Webscarab or Burp, being the Java platform a prerequisite to run.
Sun/Oracle has recently released new updates for Java: Java 6 Update 19 on March 2010, fixing 27 security issues, and Java 6 Update 20 on April 2010, including a couple of fixes. If you have updated the Java version of your pentesting system (You did, didn't you?), you must be aware that your interception proxies won't be able to audit web applications that make use of client X.509 certificates for authentication. This specifically affects pentests on e-government and e-banking web applications making use of client certificates, such as those stored on smart cards (like some European national identity cards); in particular for Spain, dozens of websites integrate authentication through the electronic national id card, "DNI electronico" (DNIe).
The reason is that Java 6 Update 19 includes a fix for the famous SSL/TLS renegotiation vulnerability from November 2009 (CVE-2009-3555). The SSL/TLS renegotiation feature is specifically used by certificate-based client authentication, and the fix disables SSL/TLS renegotiation in the Java Secure Sockets Extension (JSSE) by default. As a result, when you try to access a web resource that requires certificate-based client authentication through the interception proxy, it generates the following Java SSL/TLS error message (javax.net.ssl.SSLException): "HelloRequest followed by an unexpected handshake message".
Webscarab error message:
Burp error message:
However, it is still possible to re-enable the SSL/TLS renegotiation in Java by setting the new system property sun.security.ssl.allowUnsafeRenegotiation to true before the JSSE library is initialized. The following Windows command line launches Burp with SSL/TLS renegotiation enabled:
C:\>java -jar -Xmx512m -Dsun.security.ssl.allowUnsafeRenegotiation=true "C:\Program Files\burpsuite_pro_v1.3\burpsuite_pro_v1.3.jar"
Keep your WebApp PenTests rolling!
Shameless plug: Interested on learning the art of WebApp PenTesting? I will be teaching SANS SEC542, "Web Application Penetration Testing and Ethical Hacking", in London (May 10-15, 2010) in English and in Madrid (September 20-25, 2010) in Spanish.
订阅：
博文 (Atom)
博文
