hacktricks/src/network-services-pentesting/pentesting-web

80,443 - Méthodologie Pentesting Web

{{#include ../../banners/hacktricks-training.md}}

Infos de base

Le service web est le service le plus commun et étendu et de nombreux types différents de vulnérabilités existent.

Port par défaut : 80 (HTTP), 443 (HTTPS)

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  ssl/https

nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0

Web API Guidance

{{#ref}} web-api-pentesting.md {{#endref}}

Methodology summary

Dans cette méthodologie nous allons supposer que vous allez attaquer un domaine (ou sous-domaine) et uniquement celui-ci. Vous devez donc appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert avec un serveur web indéterminé dans le périmètre.

• Commencez par identifier les technologies utilisées par le serveur web. Recherchez des trucs à garder en tête pendant le reste du test si vous parvenez à identifier la tech.
• Existe-t-il une vulnérabilité connue pour la version de la technologie ?
• Utilisez-vous une tech bien connue ? Y a-t-il une astuce utile pour extraire plus d'informations ?
• Un specialised scanner à lancer (like wpscan) ?
• Lancez des general purposes scanners. On ne sait jamais s'ils vont trouver quelque chose ou des informations intéressantes.
• Commencez par les initial checks : robots, sitemap, erreur 404 et SSL/TLS scan (si HTTPS).
• Commencez le spidering de la page web : il est temps de trouver tous les fichiers, folders et paramètres being used. Vérifiez également les special findings.
• Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered.
• Directory Brute-Forcing : Essayez de brute force tous les dossiers découverts en recherchant de nouveaux files et directories.
• Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced.
• Backups checking : Testez si vous pouvez trouver des backups des discovered files en ajoutant des extensions de sauvegarde courantes.
• Brute-Force parameters : Essayez de trouver des paramètres cachés.
• Une fois que vous avez identifié tous les endpoints possibles acceptant des user input, vérifiez tous les types de vulnérabilités qui y sont liés.
• Follow this checklist

Server Version (Vulnerable?)

Identify

Vérifiez s'il existe des vulnérabilités connues pour la version du serveur en cours d'exécution.
Les HTTP headers and cookies of the response pourraient être très utiles pour identifier les technologies et/ou la version utilisée. Nmap scan peut identifier la version du serveur, mais les outils whatweb, webtech ou https://builtwith.com/:

whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2

Rechercher les vulnerabilities of the web application version

Vérifier s'il y a un WAF

• https://github.com/EnableSecurity/wafw00f
• https://github.com/Ekultek/WhatWaf.git
• https://nmap.org/nsedoc/scripts/http-waf-detect.html

Web tech tricks

Quelques astuces pour trouver des vulnérabilités dans différentes technologies bien connues utilisées :

• AEM - Adobe Experience Cloud
• Apache
• Artifactory
• Buckets
• CGI
• Drupal
• Flask
• Git
• Golang
• GraphQL
• H2 - Java SQL database
• ISPConfig
• IIS tricks
• Microsoft SharePoint
• JBOSS
• Jenkins
• Jira
• Joomla
• JSP
• Laravel
• Moodle
• Nginx
• PHP (php has a lot of interesting tricks that could be exploited)
• Python
• Spring Actuators
• Symphony
• Tomcat
• VMWare
• Web API Pentesting
• WebDav
• Werkzeug
• Wordpress
• Electron Desktop (XSS to RCE)

Prenez en compte que le même domaine peut utiliser différentes technologies sur différents ports, folders et subdomains.
Si l'application web utilise une des tech/platform listed before ou toute autre, n'oubliez pas de chercher sur Internet de nouvelles astuces (et tiens-moi au courant !).

Revue du code source

Si le source code de l'application est disponible sur github, en plus d'effectuer par vous-même un White box test de l'application, certaines informations peuvent être utiles pour le Black-Box testing en cours :

• Y a-t-il un Change-log or Readme or Version file ou quoi que ce soit contenant des version info accessible via le web ?
• Comment et où sont stockées les credentials ? Y a-t-il un file (accessible ?) contenant des credentials (usernames ou passwords) ?
• Les passwords sont-ils en plain text, encrypted, ou quel hashing algorithm est utilisé ?
• Utilise-t-il une master key pour chiffrer quelque chose ? Quel algorithm est utilisé ?
• Pouvez-vous accéder à l'un de ces files en exploitant une vulnérabilité ?
• Y a-t-il des informations intéressantes dans github (issues résolues ou non) ? Ou dans l'commit history (peut-être un password introduit dans un ancien commit) ?

{{#ref}} code-review-tools.md {{#endref}}

Scanners automatiques

Scanners automatiques à usage général

nikto -h <URL>
whatweb -a 4 <URL>
wapiti -u <URL>
W3af
zaproxy #You can use an API
nuclei -ut && nuclei -target <URL>

# https://github.com/ignis-sec/puff (client side vulns fuzzer)
node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"

Scanners pour CMS

Si un CMS est utilisé, n'oubliez pas de lancer un scanner, quelque chose d'intéressant peut être trouvé :

Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish
CMSScan: WordPress, Drupal, Joomla, vBulletin sites web pour des problèmes de sécurité. (GUI)
VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart
CMSMap: (W)ordpress, (J)oomla, (D)rupal ou (M)oodle
droopscan: Drupal, Joomla, Moodle, Silverstripe, Wordpress

cmsmap [-f W] -F -d <URL>
wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs

À ce stade vous devriez déjà avoir quelques informations sur le serveur web utilisé par le client (si des données sont fournies) et quelques astuces à garder en tête pendant le test. Si vous avez de la chance, vous avez même trouvé un CMS et lancé un scanner.

Step-by-step Web Application Discovery

À partir de ce point, nous allons commencer à interagir avec l'application web.

Initial checks

Default pages with interesting info:

• /robots.txt
• /sitemap.xml
• /crossdomain.xml
• /clientaccesspolicy.xml
• /.well-known/
• Vérifiez aussi les commentaires dans les pages principales et secondaires.

Forcing errors

Les serveurs web peuvent se comporter de manière inattendue lorsque des données étranges leur sont envoyées. Cela peut ouvrir des vulnérabilités ou entraîner la divulgation d'informations sensibles.

• Accédez à des pages factices comme /whatever_fake.php (.aspx,.html,.etc)
• Ajoutez "[]", "]]", and "[[" dans les valeurs de cookie et les valeurs de paramètres pour provoquer des erreurs
• Générez une erreur en fournissant en entrée /~randomthing/%s à la fin de l'URL
• Essayez différents HTTP Verbs comme PATCH, DEBUG ou incorrects comme FAKE

Check if you can upload files (PUT verb, WebDav)

Si vous découvrez que WebDav est activé mais que vous n'avez pas suffisamment de permissions pour uploading files dans le dossier racine, essayez de :

• Brute Force credentials
• Upload files via WebDav to the rest of found folders inside the web page. You may have permissions to upload files in other folders.

SSL/TLS vulnerabilites

• Si l'application n'impose pas l'utilisation de HTTPS dans une quelconque partie, alors elle est vulnérable à MitM
• Si l'application envoie des données sensibles (passwords) via HTTP. Alors c'est une vulnérabilité élevée.

Use testssl.sh to checks for vulnerabilities (Dans les programmes Bug Bounty probablement ce genre de vulnérabilités ne sera pas accepté) and use a2sv to recheck the vulnerabilities:

./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also

# You can also use other tools, by testssl.sh at this momment is the best one (I think)
sslscan <host:port>
sslyze --regular <ip:port>

Information about SSL/TLS vulnerabilities:

• https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/
• https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/

Spidering

Launch some kind of spider inside the web. The goal of the spider is to find as much paths as possible from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible.

• gospider (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
• hakrawler (go): HML spider, with LinkFider for JS files and Archive.org as external source.
• dirhunt (python): HTML spider, also indicates "juicy files".
• evine (go): Interactive CLI HTML spider. It also searches in Archive.org
• meg (go): This tool isn't a spider but it can be useful. You can just indicate a file with hosts and a file with paths and meg will fetch each path on each host and save the response.
• urlgrab (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
• gau (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
• ParamSpider: This script will find URLs with parameter and will list them.
• galer (go): HTML spider with JS rendering capabilities.
• LinkFinder (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to JSScanner, which is a wrapper of LinkFinder.
• goLinkFinder (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
• JSParser (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
• relative-url-extractor (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
• JSFScan (bash, several tools): Gather interesting information from JS files using several tools.
• subjs (go): Find JS files.
• page-fetch (go): Load a page in a headless browser and print out all the urls loaded to load the page.
• Feroxbuster (rust): Content discovery tool mixing several options of the previous tools
• Javascript Parsing: A Burp extension to find path and params in JS files.
• Sourcemapper: A tool that given the .js.map URL will get you the beatified JS code
• xnLinkFinder: This is a tool used to discover endpoints for a given target.
• waymore: Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
• HTTPLoot (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
• SpiderSuite: Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
• jsluice (go): It's a Go package and command-line tool for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
• ParaForge: ParaForge is a simple Burp Suite extension to extract the paramters and endpoints from the request to create custom wordlist for fuzzing and enumeration.
• katana (go): Awesome tool for this.
• Crawley (go): Print every link it's able to find.

Brute Force directories and files

Start brute-forcing from the root folder and be sure to brute-force all the directories found using this method and all the directories discovered by the Spidering (you can do this brute-forcing recursively and appending at the beginning of the used wordlist the names of the found directories).
Tools:

• Dirb / Dirbuster - Included in Kali, old (and slow) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
• Dirsearch (python): It doesn't allow auto-signed certificates but allows recursive search.
• Gobuster (go): It allows auto-signed certificates, it doesn't have recursive search.
• Feroxbuster - Fast, supports recursive search.
• wfuzz wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ
• ffuf - Fast: ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ
• uro (python): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs.
• Scavenger: Burp Extension to create a list of directories from the burp history of different pages
• TrashCompactor: Remove URLs with duplicated functionalities (based on js imports)
• Chamaleon: It uses wapalyzer to detect used technologies and select the wordlists to use.

Recommended dictionaries:

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt
• Dirsearch included dictionary
• http://gist.github.com/jhaddix/b80ea67d85c13206125806f0828f4d10
• Assetnote wordlists
• https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content
• raft-large-directories-lowercase.txt
• directory-list-2.3-medium.txt
• RobotsDisallowed/top10000.txt
• https://github.com/random-robbie/bruteforce-lists
• https://github.com/google/fuzzing/tree/master/dictionaries
• https://github.com/six2dez/OneListForAll
• https://github.com/random-robbie/bruteforce-lists
• https://github.com/ayoubfathi/leaky-paths
• /usr/share/wordlists/dirb/common.txt
• /usr/share/wordlists/dirb/big.txt
• /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced.

What to check on each file found

• Broken link checker: Find broken links inside HTMLs that may be prone to takeovers
• File Backups: Once you have found all the files, look for backups of all the executable files (".php", ".aspx"...). Common variations for naming a backup are: file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old. You can also use the tool bfac or backup-gen.
• Discover new parameters: You can use tools like Arjun, parameth, x8 and Param Miner to discover hidden parameters. If you can, you could try to search hidden parameters on each executable web file.
• Arjun all default wordlists: https://github.com/s0md3v/Arjun/tree/master/arjun/db
• Param-miner “params” : https://github.com/PortSwigger/param-miner/blob/master/resources/params
• Assetnote “parameters_top_1m”: https://wordlists.assetnote.io/
• nullenc0de “params.txt”: https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773
• Comments: Check the comments of all the files, you can find credentials or hidden functionality.
• If you are playing CTF, a "common" trick is to hide information inside comments at the right of the page (using hundreds of spaces so you don't see the data if you open the source code with the browser). Other possibility is to use several new lines and hide information in a comment at the bottom of the web page.
• API keys: If you find any API key there is guide that indicates how to use API keys of different platforms: keyhacks, zile, truffleHog, SecretFinder, RegHex, DumpsterDive, EarlyBird
• Google API keys: If you find any API key looking like AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project gmapapiscanner to check which apis the key can access.
• S3 Buckets: While spidering look if any subdomain or any link is related with some S3 bucket. In that case, check the permissions of the bucket.

Special findings

While performing the spidering and brute-forcing you could find interesting things that you have to notice.

Interesting files

• Look for links to other files inside the CSS files.
• If you find a .git file some information can be extracted
• If you find a .env information such as api keys, dbs passwords and other information can be found.
• If you find API endpoints you should also test them. These aren't files, but will probably "look like" them.
• JS files: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to monitor each JS file found, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example JSMon.
• You should also check discovered JS files with RetireJS or JSHole to find if it's vulnerable.
• Javascript Deobfuscator and Unpacker: https://lelinhtinh.github.io/de4js/, https://www.dcode.fr/javascript-unobfuscator
• Javascript Beautifier: http://jsbeautifier.org/, http://jsnice.org/
• JsFuck deobfuscation (javascript with chars:"[]!+" https://enkhee-osiris.github.io/Decoder-JSFuck/)
• TrainFuck: +72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.
• On several occasions, you will need to understand the regular expressions used. This will be useful: https://regex101.com/ or https://pythonium.net/regex
• You could also monitor the files were forms were detected, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.

403 Forbidden/Basic Authentication/401 Unauthorized (bypass)

{{#ref}} 403-and-401-bypasses.md {{#endref}}

502 Proxy Error

If any page responds with that code, it's probably a bad configured proxy. If you send a HTTP request like: GET https://google.com HTTP/1.1 (with the host header and other common headers), the proxy will try to access google.com and you will have found a SSRF.

NTLM Authentication - Info disclosure

If the running server asking for authentication is Windows or you find a login asking for your credentials (and asking for domain name), you can provoke an information disclosure.
Send the header: “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=” and due to how the NTLM authentication works, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".
You can automate this using the nmap plugin "http-ntlm-info.nse".

HTTP Redirect (CTF)

It is possible to put content inside a Redirection. This content won't be shown to the user (as the browser will execute the redirection) but something could be hidden in there.

Web Vulnerabilities Checking

Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:

{{#ref}} ../../pentesting-web/web-vulnerabilities-methodology.md {{#endref}}

Find more info about web vulns in:

• https://six2dez.gitbook.io/pentest-book/others/web-checklist
• https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html
• https://owasp-skf.gitbook.io/asvs-write-ups/kbid-111-client-side-template-injection

Monitor Pages for changes

You can use tools such as https://github.com/dgtlmoon/changedetection.io to monitor pages for modifications that might insert vulnerabilities.

HackTricks Automatic Commands

Protocol_Name: Web    #Protocol Abbreviation if there is one.
Port_Number:  80,443     #Comma separated if there is more than one.
Protocol_Description: Web         #Protocol Abbreviation Spelled out

Entry_1:
Name: Notes
Description: Notes for Web
Note: |
https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/index.html

Entry_2:
Name: Quick Web Scan
Description: Nikto and GoBuster
Command: nikto -host {Web_Proto}://{IP}:{Web_Port} &&&& gobuster dir -w {Small_Dirlist} -u {Web_Proto}://{IP}:{Web_Port} && gobuster dir -w {Big_Dirlist} -u {Web_Proto}://{IP}:{Web_Port}

Entry_3:
Name: Nikto
Description: Basic Site Info via Nikto
Command: nikto -host {Web_Proto}://{IP}:{Web_Port}

Entry_4:
Name: WhatWeb
Description: General purpose auto scanner
Command: whatweb -a 4 {IP}

Entry_5:
Name: Directory Brute Force Non-Recursive
Description:  Non-Recursive Directory Brute Force
Command: gobuster dir -w {Big_Dirlist} -u {Web_Proto}://{IP}:{Web_Port}

Entry_6:
Name: Directory Brute Force Recursive
Description: Recursive Directory Brute Force
Command: python3 {Tool_Dir}dirsearch/dirsearch.py -w {Small_Dirlist} -e php,exe,sh,py,html,pl -f -t 20 -u {Web_Proto}://{IP}:{Web_Port} -r 10

Entry_7:
Name: Directory Brute Force CGI
Description: Common Gateway Interface Brute Force
Command: gobuster dir -u {Web_Proto}://{IP}:{Web_Port}/ -w /usr/share/seclists/Discovery/Web-Content/CGIs.txt -s 200

Entry_8:
Name: Nmap Web Vuln Scan
Description: Tailored Nmap Scan for web Vulnerabilities
Command: nmap -vv --reason -Pn -sV -p {Web_Port} --script=`banner,(http* or ssl*) and not (brute or broadcast or dos or external or http-slowloris* or fuzzer)` {IP}

Entry_9:
Name: Drupal
Description: Drupal Enumeration Notes
Note: |
git clone https://github.com/immunIT/drupwn.git for low hanging fruit and git clone https://github.com/droope/droopescan.git for deeper enumeration

Entry_10:
Name: WordPress
Description: WordPress Enumeration with WPScan
Command: |
?What is the location of the wp-login.php? Example: /Yeet/cannon/wp-login.php
wpscan --url {Web_Proto}://{IP}{1} --enumerate ap,at,cb,dbe && wpscan --url {Web_Proto}://{IP}{1} --enumerate u,tt,t,vp --passwords {Big_Passwordlist} -e

Entry_11:
Name: WordPress Hydra Brute Force
Description: Need User (admin is default)
Command: hydra -l admin -P {Big_Passwordlist} {IP} -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'

Entry_12:
Name: Ffuf Vhost
Description: Simple Scan with Ffuf for discovering additional vhosts
Command: ffuf -w {Subdomain_List}:FUZZ -u {Web_Proto}://{Domain_Name} -H "Host:FUZZ.{Domain_Name}" -c -mc all {Ffuf_Filters}

{{#include ../../banners/hacktricks-training.md}}