Nmap/Short Course/Lecture 6
From charlesreid1
Main page: Nmap/Short Course
Contents
Summary and Objective
This 30-minute lecture will build upon the previous NSE introduction, focusing specifically on how Nmap can be used to identify known vulnerabilities.
Objective: To teach students how to leverage the Nmap Scripting Engine's vuln category scripts to identify specific known vulnerabilities in services, understand the ethical implications, and learn how to interpret and manage the results.
Notes
Recap & Introduction to Vulnerability Scanning with NSE
Quick Recap of Lecture 5
In our last session, we delved into using the Nmap Scripting Engine (NSE) for advanced reconnaissance. We explored discovery and broadcast script categories, learning how to uncover more detailed network information, enumerate specific services like SMB and SNMP, and customize script behavior using --script-args. This set the stage for using NSE for even more targeted investigations.
What is Vulnerability Scanning?
Vulnerability scanning is the process of proactively identifying security weaknesses (vulnerabilities) in computer systems and networks. The purpose is to find these flaws before malicious actors can exploit them. A vulnerability could be an unpatched piece of software, a misconfiguration, a weak password policy, or an outdated protocol. Identifying these allows organizations to prioritize remediation efforts.
Nmap's Role in Vulnerability Scanning
While Nmap is primarily known as a network mapper and port scanner, its Nmap Scripting Engine significantly extends its capabilities into the realm of vulnerability scanning. It's important to understand that Nmap is not a dedicated, comprehensive vulnerability scanner in the same vein as tools like Nessus, OpenVAS, or Qualys. Those tools have extensive, regularly updated vulnerability databases and sophisticated reporting engines. However, NSE contains a powerful category of scripts specifically designed to check for many common and critical known vulnerabilities. This makes Nmap a versatile first-pass tool for identifying low-hanging fruit and specific flaws.
Ethical Considerations and Authorization (Crucial Reminder!)
This cannot be overstressed: vulnerability scanning, even with Nmap, must only be performed on systems and networks for which you have explicit, written authorization.
Running vuln scripts against unauthorized targets is unethical, illegal, and can have serious consequences. These scripts actively probe for weaknesses and can sometimes be misinterpreted as an attack or even cause instability on fragile systems. All activities in this course are confined to our isolated lab environments. In professional settings, always adhere to the rules of engagement.
Focusing on the vuln Script Category
The vuln category is Nmap's primary collection of scripts for active vulnerability detection.
Deep Dive into the vuln Category
The vuln category in NSE groups scripts that test for specific, known vulnerabilities. Unlike discovery scripts that primarily gather information, vuln scripts actively attempt to determine if a target is susceptible to a particular flaw. This might involve sending specially crafted probes, checking for specific error messages, or verifying version numbers against known vulnerable ones. These scripts are invaluable for quickly assessing if a target is exposed to well-documented exploits.
How vuln Scripts Work (General Principles)
Most vuln scripts operate based on information publicly available about vulnerabilities, such as CVEs (Common Vulnerabilities and Exposures). A script might:
- Connect to a service identified by Nmap's port scan and version detection (-sV).
- Send specific data or commands that would trigger a vulnerable response if the flaw exists.
- Analyze the response (or lack thereof) to determine if the vulnerability is present.
- Report its findings, often including a CVE number, a brief description of the vulnerability, and sometimes links to more information. For example, a script checking for a specific web server vulnerability might send a particular HTTP request and look for an unusual server response or a specific string in the returned page.
Finding and Running vuln Scripts
You can find the available vuln scripts in your Nmap scripts directory (e.g., /usr/share/nmap/scripts/vuln-* on Linux). Nmap's documentation also lists them.
To run all scripts in the vuln category against a target, you can use:
# Run all vulnerability scripts (use with extreme caution and only with authorization) sudo nmap -sV --script vuln <target_IP>
Caution: Running all vuln scripts can be very time-consuming and "noisy" (i.e., generate a lot of network traffic and log entries). It might also include scripts that are more intrusive. It's often better to target specific vuln scripts based on the services you've identified.
Interpreting Output from vuln Scripts
The output from vuln scripts is usually appended to the port/service information for a host. Key things to look for:
- STATE: VULNERABLE: This is a clear indication that the script believes it has found the vulnerability.
- A description of the vulnerability.
- Often, a reference (like a CVE ID) and links to advisories or further details.
- Sometimes, the script might output the evidence it found. It's crucial to read the script's output carefully. Not all findings mean a system is definitively exploitable, but they warrant immediate investigation.
[Instructor: Run 'sudo nmap -sV --script vuln -p <known_vulnerable_port> <your_lab_target_IP_with_a_known_vuln>' and show a generic example of a VULNERABLE state.] PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.2.14 ((Ubuntu)) | http-slowloris-check: | VULNERABLE: | Slowloris DOS attack | State: LIKELY VULNERABLE | IDs: CVE:CVE-2007-6750 | Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. | It accomplishes this by sending partial requests and slowly sending subsequent HTTP headers. | Affected servers are Apache 1.x, Apache 2.x, dhttpd, GoAhead WebServer and Squid. | | Disclosure date: 2009-06-17 |_ References: http://ha.ckers.org/slowloris/
You can see the script ID (http-slowloris-check), the VULNERABLE state, the description, and references.
Targeted Vulnerability Scanning with Specific NSE Scripts
Running all vuln scripts is often inefficient. A more targeted approach is usually better.
Why Target Specific Scripts?
Efficiency: Scanning only for vulnerabilities relevant to the services and versions detected on the target saves significant time.
Reduced Noise: Fewer probes mean less network traffic and fewer log entries, making the scan less conspicuous.
Relevance: Focusing on vulnerabilities known to affect the specific software (e.g., Apache 2.4.x, vsftpd 2.3.4) is more productive.
Safety: Avoids running potentially disruptive scripts on services they aren't designed for.
Using Version Information (-sV) to Guide Script Selection
The service and version detection performed by nmap -sV is crucial input for selecting appropriate vuln scripts. Once you know you have "Apache httpd 2.2.22" running, you can then search for NSE scripts specifically targeting vulnerabilities in that version or family of Apache.
For example, after running sudo nmap -sV <target_IP>, if you identify an old version of vsftpd, you might then specifically run a script checking for a known backdoor in that version.
Examples of Targeted vuln Scripts
Here are some examples of well-known vulnerabilities and the NSE scripts that can check for them:
Web Servers:
- http-vuln-cve2017-5638: Checks for Apache Struts S2-045 RCE.
- http-shellshock: Tests for the Shellshock bash vulnerability via HTTP CGI.
- http-iis-short-name-enum: Enumerates short names of files and directories on IIS, which can reveal sensitive information.
sudo nmap -sV -p80 --script http-shellshock <target_web_server_IP>
SMB (Windows File Sharing / Samba):
- smb-vuln-ms17-010: Checks for the "EternalBlue" vulnerability. Extremely critical.
- smb-vuln-ms08-067: Checks for another infamous Windows RCE vulnerability.
sudo nmap -sV -p139,445 --script smb-vuln-ms17-010 <target_windows_IP>
FTP Servers:
- ftp-vsftpd-backdoor: Checks for the vsftpd 2.3.4 backdoor.
- ftp-vuln-cve2010-4221: Checks for ProFTPD CWD command remote code execution.
sudo nmap -sV -p21 --script ftp-vsftpd-backdoor <target_ftp_server_IP>
SSH Servers:
- ssh-vuln-cve2008-0166: Checks for weak SSH keys generated due to a flaw in Debian OpenSSL.
sudo nmap -sV -p22 --script ssh-vuln-cve2008-0166 <target_ssh_server_IP>
[Instructor: Run a specific, known `vuln` script against a deliberately vulnerable lab VM. E.g., if a VM is vulnerable to MS17-010, run 'sudo nmap -sV -p445 --script smb-vuln-ms17-010 <vulnerable_vm_IP>'.] PORT STATE SERVICE VERSION 445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 (Microsoft Windows NT 6.1) Host script results: | smb-vuln-ms17-010: | VULNERABLE: | Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010) | State: VULNERABLE | IDs: CVE:CVE-2017-0143 | Risk factor: HIGH | Description: | Microsoft Windows SMBv1 servers (versions 1.0 and later) are vulnerable to a remote code execution vulnerability | when handling specially crafted requests. This vulnerability could allow an attacker to execute arbitrary code on | the target system. | | Disclosure date: 2017-03-14 | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143 | https://technet.microsoft.com/en-us/library/security/ms17-010.aspx |_ https://github.com/cqr-cryeye/EternalMoonFramework
This shows a clear "VULNERABLE" finding with details and references. The lab for this lecture will involve students identifying services on their lab targets and then selecting and running appropriate vuln scripts.
Managing Script Updates & Best Practices
Using vuln scripts effectively and responsibly requires ongoing maintenance and careful consideration.
Keeping NSE Scripts Updated (nmap --script-updatedb)
New vulnerabilities are discovered constantly, and the Nmap developers and community work to create NSE scripts to detect them. To ensure your Nmap installation has the latest scripts and their most recent versions (which might include bug fixes or new checks), you should regularly update the script database.
The command to do this is:
sudo nmap --script-updatedb
This will connect to Nmap's servers and download the latest script information. It's good practice to run this periodically, especially before starting a new security assessment.
Understanding Script Risk Levels and Categories
As mentioned, not all NSE scripts are created equal in terms of their potential impact. While many vuln scripts are designed to be safe checks, some might be more intrusive or could, in rare cases, disrupt unstable services.
Always pay attention to a script's categories. If a vuln script is also tagged as intrusive or dos (Denial of Service), it means it performs actions that could potentially affect the stability or availability of the target service. Such scripts should be used with extreme caution, clear understanding, and explicit permission for potentially disruptive testing. For the ICS scenario (Scenario 2 in the course), running any potentially disruptive script is highly discouraged without thorough prior risk assessment.
Verification of Findings: Nmap is a Tool, Not an Oracle
Nmap vuln scripts are excellent tools for identifying potential vulnerabilities, but their findings should always be verified. False positives (where a script reports a vulnerability that isn't actually present) can occur due to unusual service configurations, custom banners, or limitations in the script's logic. False negatives (where a script fails to detect an existing vulnerability) are also possible.
After Nmap flags a potential vulnerability, the next step is to try and confirm it through other means, such as:
- Manually checking software versions against official advisories.
- Using other dedicated vulnerability scanners.
- Attempting safe, non-destructive proof-of-concept exploitation (if authorized and skilled).
- Carefully reviewing system configurations and logs.
The "Do No Harm" Principle
Especially when scanning production environments or sensitive systems like those in Industrial Control Systems (Scenario 2), the "do no harm" principle is paramount. If there's any doubt about a script's potential impact, err on the side of caution. For ICS environments, passive reconnaissance and very carefully selected, non-intrusive discovery scripts are often preferred over broad vuln scanning unless explicitly mandated and understood by the asset owners. Understanding the potential impact is key before running any script that actively probes for vulnerabilities.
Lab
Run selected vuln scripts against targets in the Web/Cloud Infrastructure (Scenario 3). Perform deep service enumeration (e.g., web servers, SMB shares if present) in Scenario 1 and 3. Caution advised for ICS scenario; perhaps only run very safe discovery scripts.
Flags
