Notes/bit about Public Exploits

This is the start of many short publications on my journey through HackTheBox’s Penetration Tester job role path. Public Exploits introduces the importance of publicly searching for existing exploits to applications and services.

These services are identified by knowing the host name and the port which can be gained through the use of the nmap command.

Searchsploit is a command line tool also used to search for these exploits.

The Metasploit Framework (MSF) is an all-in-one pentesting solution which contains these exploits and conveniently, instructions to perform them as well.

My Experience

Initially, I enumerated through the server and found this file http://94.237.54.42:50394/xmlrpc.php, which read back “XML-RPC server accepts POST requests only.” Naturally, I looked for xml-rpc related exploits to no avail. After setting the required options for each exploit, each attempt ended with “the target is not exploitable,” after running check on the target host to see if it is at all exploitable.

I revisited the host page, and the landing page talks about a simple backup plugin 2.7.10 for Wordpress. I looked for any exploits on a simple backup plugin and found one — auxiliary/scanner/http/wp_simple_backup_file_read.

I set the options, discovered check was a success and ran the exploit. It returned a .txt file. To get the flag, I had to set the exploit option, FILEPATH to /file.txt, allowing me to move on.

What I learned

In retrospect, the lab is a relatively simple one, had I started off exploring the most obvious signs. I am happy that I utilized previous techniques like web enumeration using Gobuster to search for clues and to practice what I’ve learned from before. The main takeaway is to begin my attack using the obvious signs first before going down a rabbit hole and exploring more obscure areas — start off simple.

The challenge, found here, can be tackled using any of the three major Cloud providers: AWS, Azure, and GCP.

For me, the Cloud Resume Challenge served as a means to gain hands-on experience with Cloud technologies that one would use on the job. Fresh off obtaining my AWS Solutions Architect — Associate certification, I wanted to further develop my practical skills in a lab-styled format.

Tasks 2/3 — HTML & CSS

These sections involved creating HTML and CSS files for the resume, which would be hosted as a static website in Task 4. Realistically, you can create any content to host but a resume is perfect for motivation and for professional future use. I have programming experience so these tasks provided a fun time for me to reconstruct my PDF resume from scratch.

Task 4 — Static Website

Task 4 was where I got to see the work I put into Tasks 2/3 come to life. I created an S3 bucket with default configurations and uploaded the HTML and CSS files.

At this point, I had my website files stored in an object storage. But that wasn’t enough to display the website. I enabled the Static website hosting configuration of the S3 bucket which can be found at the bottom of the Properties tab of our Bucket.

Enabling it generates an AWS-generated a URL, where I was met with an Access Denied error. One of the core pillars of Cloud technology is Identity and Access Management (IAM) and the crucial step I missed was to apply a Bucket Policy to the S3 Bucket which specifies who can access the bucket (Principal) and what actions they are allowed to perform on it. Afterwards, the link rendered my resume.

Tasks 5/6 — HTTPS/DNS

Next step was to configure the site to use HTTPS. Doing so required the integration of CloudFront, a CDN service that delivers static and dynamic web content, video streams, and APIs around the world, securely and at scale. I generated an SSL certificate, purchased a private domain via Route53 (check out songeugene.com), referenced that custom domain during the CloudFront creation process and provided my S3 bucket as its origin from Task 4.

I thought I was done here but this was where I ran into my first bug when I entered my domain into the browser! Where I made an oversight was not including the Default root object under the Settings tab of the CloudFront distribution I had just created. In addition to declaring your S3 origin, ensure that you put the html file that you want displayed to the user so that CloudFront knows what asset to display.

Note: For Tasks 5/6 and onwards, ‘Static website hosting’ in the S3 bucket settings must be disabled as CloudFront will now act as the point of contact for any user who visits your website.

Tasks 7/8/9/10 — Javascript/Database/API/Python

For these sections, dynamic interactive elements were added to the website so that it does the following when anybody visits it: record each request, update the persistent visitor counter in a DynamoDB database and display it. Python was used to communicate with DynamoDB, while a Lambda function, triggered by an API Gateway, handled the updates. CORS configurations were implemented for internet calls.

I started off by creating a DynamoDB database and referenced it in my Python code. Here we get our first taste of using the library to work with AWS resources, boto3.

As mentioned in the cloud resume challenge documentation, we are not to directly communicate with DynamoDB from the Javascript code so I created a Lambda function, where I imbedded my Python code. Then I set an API Gateway as the trigger to the Lambda function, created an HTTP API to call the Lambda function and finally set CORS configurations because it will be called from the internet. This was a good point to stop and learn the difference between HTTP and REST API (in short, HTTP is a lightweight version of REST API).

The last step was to add the HTTP API endpoint to the Javascript code and to reference the script in the html file so that anytime a request is made to the site, the endpoint is called upon a window load.

Task 11 — Tests

Tests were created to ensure proper functionality of the Lambda function handler, utilizing the moto library. These tests would play a crucial role in future CI/CD pipeline implementation.

Task 12— Infrastructure as Code (IaC)

This section was by far my favorite, involving the recreation of previously manually created AWS resources using Terraform. I chose Terraform as my Infrastructure as Code (IaC) tool for its universal compatibility across Cloud providers.

I learned a vast amount of Terraform, its syntax and the wide array of Terraform providers in its registry. Putting it all together, I was able to spin up and most importantly, destroy an entire infrastructure in a matter of minutes, really showing me the power of Infrastructure as Code.

Having to Terraform my infrastructure taught me the efficiency and granular control offered by IaC, shaping my preference for Terraform in future projects.

Tasks 13/14/15 — Source Control/CI/CD (Backend + Frontend)

In the final stretch, all code was stored in a GitHub repository. GitHub action workflows were created for both frontend and backend components, utilizing the tests from earlier, automating code changes and ensuring synchronized updates across the Terraform-created infrastructure and AWS resources.

This automation marked the culmination of the project, eliminating manual intervention in AWS and enhancing overall workflow efficiency.

In conclusion, the Cloud Resume Challenge provided an invaluable opportunity to deepen my understanding of AWS services, refine my skills in web development and infrastructure management, and embrace automation for improved project workflows. I highly recommend anyone interested in Cloud to get their feet wet in this challenge!