Hackthissite: Basic Challenge

Overview

HackThisSite.org is an online platform that provides a legal and safe environment for individuals to improve their cyber security skills through a variety of challenges and Capture the Flag (CTF) events.

level 1

• Vulnerability Description: Hardcoded password

• On inspect there was a password in elements tab where the password was commented

Solution

remove the comment section which contains such a credentials from the code.

Level 2

• Vulnerability Description: No password file

• Just entering with blank password solve the level 2

  

  

The potential error can be missing the password file, the file might not be uploaded

Error

If the script is poorly written, it might not properly handle the case where the password file is missing. for example:

• the script might compare with empty string (””) or null

• It doesn’t check for the valid password

• A logic error in the script could allow empty or incorrect inputs to bypass authentication

  • e.g. if (user == password_from_file) without checking the password_from_file is valid

Solution

To fix this issue and prevent unauthorized access, the following steps should be taken:

1. Ensure the Password File Exist:

   • Upload the password file to correct location on the server

   • Verify that the script can read the file

2. Add Error Handling

   • Modify the script to handle case where the password file is missing or unreadable. For example

    $password_file = 'path/to/file'
    if (!file_exists($password_file)) {
        die("Error: Password file not found. Contact the administrator");
    }
    $real_password = trim(file_get_contents($password_file));
    if (!$real_password){
        die("Error: Password file is empty or corrupted.");
    }

3. Secure Password Storage

   • Store the password in hash and avoid using plan text which is insecure. You can use algorithms like bcrypt, argon2

   • Then convert the input password to the hash and compare with the hash files to identify if it is valid or not

4. Prevent Empty Input

   • Add validation to ensure the user cannot submit an empty password.

    if (empty($_POST['password'])) {
        die('Error: Password file cannot be empty');
    }

5. Secure File Storage

   • If a file must be used, it must be outside the web root (e.g. /var/secure/password.txt) to prevent direct access via the browser.

   • Set strict file permission e.g chmod 600 password.txt to ensure script can be read only

6. Test the script with varity of inputs.

Level 3

• Vulnerability Description: Location of password hidden in source code

We are already seeing the problem with this

This shows the potential vulnerability in the script. The issue likely stems from a Local File Inclusion(LFI) vulnerability

The presence of hidden input field name file with value password.php suggest that the script may use the file named password.php .

Error

1. Improper Password File Handling

   • The password file might be stored in a web-accessible directory, allowing direct access

     

Here while visiting https://www.hackthissite.org/missions/basic/3/password.php we simply get the password of the file

Solution

• Remove and Sanitize the file Parameter

  • Eliminate the file hidden input from the form unless it’s absolutely necessary. Hardcode the password file path in the script to prevent user manipulation

  • Keep the file outside the web root

      $password_file="/secure/path/to/password.txt"
    

  • If file parameter is required for some reason, validate and sanitize it strictly:

      $allowed_files = ['password.php']; // Whitelist allowed files
      $file = $_POST['file'];
      if (!in_array($file, $allowed_files)) {
          die("Error: Invalid file specified.");
      }
    

• Prevent local File Inclusion:

  • Avoid using user input directly in file operations like include, require or file_get_content

      $password_file = "/var/secure/password.txt"; // Not in web-accessible directory
      if (!file_exists($password_file)) {
          die("Error: Password file not found.");
      }
    

Level 4

• Vulnerability Description: Hardcoded credentials within application

• Here while inspecting we see a send password to Sam

• While using burpsuite and intercepting the request we obtain the Request

• Here, just modifying the to=sam%40hackthissite.org to our own email we get a mail providing the password for the site

  

Error

1. Insecure Direct Object Reference (IDOR)

2. Improper input validation

3. Flaw in Password Handling

Solution

1. Remove the Hardcode in to field

   • If the password has to go to the sam@hackthissite.org then remove the to field from the form, this prevent attackers from modifying the recipient email address.

2. Implement Authentication and Authorization

   • Require user to authenticate before they can trigger the password email functionality

       session_start();
       if (!isset($_SESSION['user_id']) || $_SESSION['user_id'] !== 'sam') {
           die("Error: Unauthorized access.");
       }
     

3. Validate and Sanitize Input

   • If to field is necessary then validate for e.g

       $allowed_emails = ["sam@hackthissite.org"];
       $to = $_POST['to'];
       if (!in_array($to, $allowed_emails)) {
           die("Error: Invalid email address.");
       }
     

Level 5

The error in this challenge is same as the Level4

Level 6

• Vulnerability Description: Week encryption

Here,

Given 9d67hgg; to decrypt using ASII Table

We get for 9d67hgg; as,

Answer → 9c44dba4

Level 7

• Vulnerability Description: Command Injection

Here we have a Command Injection problem

The ; in the input section is just a command separator that executes multiple commands sequentially

This lead us to a new page where at the bottom we see the list of the files in that directory

Now while visiting to this k1kh31b1n55h.php like https://www.hackthissite.org/missions/basic/7/k1kh31b1n55h.php we obtain the password

Solution

1. Disable Directory Listing

   • Directory listing allows attackers to view the contents of a directory by accessing it via a browser or command

   • Manage Web Server Configuration

     • For Apache, add Options -Indexes in the .htaccess file or the main configuration file to disable directory indexing.

     • For Nginx, ensure the autoindex directive is set off

2. Secure File Storage

   • Store sensitive files outside the root

   • Use strong file permissions e.g. chmod 600 file

   • Avoid hardcoding credentials in configuration files. Instead, use environment variables

3. Prevent Command Injection

   • Input Validation and Sanitization: Use allowlists for acceptable inputs rather than blocklists.

   • Use Safe APIs: Avoid using functions like exec(), system(), or eval() in code that processes user input.

   • Escape User Input: If commands must be executed, escape special characters

   • e.g.

       $input = escapeshellarg($user_input);
     

   • Web Application Firewall (WAF): Deploy to detect and block command injection

Level 8

• Vulnerability Description: Server-Side include (SSI) injection

On looking at the task and reading the prompt it looks something like SSL attack so I went to a website of OWAP where I sound some payloads and tried on them

Suprisingly, it worked and listed a series of file inside a parent directory

visiting the [https://www.hackthissite.org/missions/basic/9/](<https://www.hackthissite.org/missions/basic/9/>)au12ha38vc.php provide us with the password

Solution

1. Disable Server-Side Includes(SSL)

   • Disable SSL in the configuration file by removing or commenting out the Includes option in the Options directive:

       <Directory /var/www/>
           Options -Includes
       </Directory>
     

   • Similarly for nginx,

       ssl off;
     

2. Sanitize and Validate User Input

   • Strict Input Validation: Implement an allowlist to accept only expected input patterns, rejecting anything containing SSI-like syntax (e.g., <!-- or #exec).

       if (preg_match('/<!--|-->|#exec|#include/i', $user_input)) {
           die("Invalid input detected");
       }
     

   • Escape Special Characters: Encode or escape user input to neutralize SSI directives before rendering it in HTML or passing it to the server.

3. Secure file and Directory Permission

   • Change the mode of the files and folders using the command chmod

Level 9

• Vulnerability Description: Server-Side include (SSI) injection

Here we get the credentials form level 8 by uploading

<!-- #exec cmd="../../9/" -->

We visited the link https://www.hackthissite.org/missions/basic/9/p91e283zc3.php and obtain password

Solution

The solution is all for level 8

Level 10

• Vulnerability Description: Incorrect implementation of Cookies

Viewing page source code was not use full in this level so I visited every tab of the inspect section

There was this level10_authorized in cookies section of Application tab. Initially, it has the value no but when I changed it to yes and refresh the page the challenge was complete

Error

The potential error here might be:

1. Lack of Server-Side Validation

2. Unprotected Cookies

3. Insecure Authorization Logic

Solution

1. Secure Server-Side Authorization

   • Store authorization state in a server-side session or database, not in client-side cookies.

2. Secure Cookie with Cryptographic Protection

   • Use a cryptographic signature to ensure the cookie’s integrity. For example, append an HMAC (Hash-based Message Authentication Code) to the cookie value and verify it on the server.

       const cookie = require('cookie-signature');
       const secret = 'your-secret-key';
       // Sign the cookie
       res.cookie('level10_authorized', cookie.sign('yes', secret), { httpOnly: true });
       // Verify on server
       if (cookie.unsign(req.cookies.level10_authorized, secret) !== 'yes') {
           throw new Error('Invalid cookie');
       }
     

   • Set secure cookie attributes (HttpOnly, Secure, Samesite )

       res.cookie('level10_authorized', 'yes', {
           httpOnly: true,
           secure: true,
           sameSite: 'Strict'
       });
     

3. Use secure session management

   • Use a session management framework (e.g., PHP’s session_start(), Express.js express-session, or Django sessions) to handle authentication and authorization.

   • Generate a random, unpredictable session ID and store it in a secure cookie.

   • If possible use the JWT token in backend to get session ids.

Level 11

• Vulnerability Description: Unprotected .htaccess files

Here we need to enumerate the url using tools like gobuster , FFuF

we get this credentials in /e/l/t/o/n/DaAnswer

available was the password for /missions/basic/11/index.php

Conclusion

In conclusion, we found several vulnerabilities in the “Basic” web challenge from HackThisSite.org. These vulnerabilities include hardcoded passwords, no password file, location of the password file hidden in the source code, hardcoded credentials, weak encryption, and command injection. These vulnerabilities could potentially lead to a breach of confidentiality, integrity, and availability.