User-Generated Content FAQ

  • Updated
Follow

Before submitting to the User-Generated Content (UGC) program, please be sure to review this FAQ in detail. All information requested in the submission form, as well as the expected details for the actual submission, are covered here. 

How to Build a Vulnerable Virtual Machine

The basic premise of a vulnerable virtual machine is to host any vulnerable application (web or non-web) and create a scenario whereby the software can be exploited. Skills learned on academic programs or through practical experience contribute heavily to the quality of your build. 

The build process can be summed up with the following:

  • Collect information regarding your proof of concept (PoC) build, including the vulnerable software, operating system, and other requirements
  • Build your virtual machine (VM) by installing the operating system and the vulnerable software
  • Set the hostname of your VM
  • Test your vulnerable software to confirm that the exploit chain is working
  • Review your build and implement fixes where needed
  • Add in your local and proof.txt flag files
  • Add in any required firewall rules
  • Clean up any leftover and old log files
  • Clean up the bash history for all users using the following command:
    cat /dev/null > /home/lowprivuser/.bash_history && history -c && exit
    cat /dev/null > /root/.bash_history && history -c && init 0
  • Create your walkthrough and all other required documentation
  • Submit your machine for review and acceptance onto the OffSec Community platform by completing the submission form

This breaks down the high-level process you will use to create your submission. We will go into detail on these concepts and the specific items required for a successful submission in this FAQ entry. 

Grouped and Chained Machines

NEW for February 2021, OffSec is now accepting "Grouped" and "Chained" machine concepts.

A "Grouped" set of machines refers to two or more machines which are passively interdependent. 

  • One or more machines of a "grouped" set will require the attacker to find crucial information on another member of the set. 
  • Trivial Grouped concept example:
        • ALICE is exploited via an independent remote vulnerability 
        • ALICE contains a text file containing a password for BOB
        • The only way to compromise BOB is by finding the password file on ALICE
  • These machines are considered "passively interdependent" because there is no network interaction between them.
  • In other words, they can be explored by a learner one by one. The two machines do not need to be online at the same time.

A "Chained" set of machines refers to two or more machines which are actively interdependent.

  • One or more machines of a "chained" set will required the attacker to find crucial information only accessible by observing networked interaction
  • Trivial Chained concept example:
        • A user on CAROL is visiting a web server or DAVE
        • CAROL can be exploited by employing a Client Side attack via DAVE
        • DAVE can only be compromised after successfully infiltrating CAROL
  • These machines are considered "actively interdependent" because there must be network interaction between them
  • In other words, the machines must be explored in tandem. The two machines must be online at the same time for the intended attacks to work properly. 

Automatically Declined Submissions

Your submission may not contain any of the following:

  • Hate speech or any forms of discrimination 
  • Plagiarized content 
  • Copyrighted content of any nature
  • Adult/sexual/lewd content
  • Profanity in passwords or applications  

Failure to adhere to these stipulations will result in an automatic rejection of your submission.

Base System Requirements

We understand that virtual machines have different specifications and resource requirements based on the functionality they provide. Some may need more RAM, others more HDD space. However, please ensure your system does not exceed these maximum specs:

  • 2 x CPU
  • 2048MB RAM
  • 20GB HDD
  • open-vm-tools must be installed, not VMWare Tools

In addition to the virtual machine, you need to submit documentation. The documentation is grouped into the following build essentials:

  • META-Data Archive: passwords, installers, vectors build guides, and walkthroughs
  • MITRE map alignment

Difficulty and Flags

The difficulty of the target is a matter of the skill set of the attacker; you may rate a machine as easy where others may find it hard. OffSec will determine the assigned difficulty based on other content in the OffSec content library. Each submission must contain a method to determine the “success” of compromise. This is done via the use of flags.

  • If your machine is a direct-to-root box, meaning there is no privilege escalation, then we only need one flag located in /root/proof.txt.
  • If your machine requires privilege escalation, your submission requires two flags. One flag is for the user in the location where we land after the initial exploit, and the other in the root folder. For example:
    • Low priv flag: /home/lowprivuser/local.txt 
    • Root flag: /root/proof.txt

The contents of both flags should only be a unique MD5 value. It can be anything, but we recommend you use a date stamp and convert that to MD5. We also require the following permissions to be set on the flags:

  • local.txt should have chmod 0644 set and chown of the low priv user that can read the file
  • proof.txt should have chmod 0700 set and chown to root only

META-Data:

Within the submission, you need to include a few files in a compressed archive. Below is a brief description of what we need:

  • Build script
  • Build guide
  • VM hosted for download location
  • Walkthrough
  • Passwords
  • Difficulty and flags

Build Script

Ideally, your submission will include a build script that we can use to build your machine. This script needs to handle all the software installations, updates, and other configuration changes that your system requires to operate correctly. We have included a sample build script here. Please use this guide as a reference while you complete your submission.

Build Guide

This is a detailed document in Markdown format outlining all the steps needed to build your machine. Unlike the build script, this guide should contain the manual steps we need to take when rebuilding your machine.   

Walkthrough

Every vulnerable machine needs a walkthrough that can be used as a reference for our learners should they require some additional help while attempting to exploit it. We require a detailed walkthrough that will properly explain the enumeration, discovery and exploitation of all the vulnerable vectors on your submission. 

In addition to detailing the exploit path, your walkthrough should also contain a lessons section, that clearly outlines all the lessons that box is intended to test.

Passwords

We require all the usernames and passwords for all the accounts on the operating system and software on your submission.

Please refrain from using needlessly complex passwords. Combining 3 or 4 words and adding in a few numbers is just as good. Example: ClimbingParrotKickingDonkey321 is a very strong password and easy to retype, unlike SFfd8@$#klowZAq*(.

MITRE Map

Your submission must also include all the relevant MITRE map alignment items that can be found here: https://attack.mitre.org/.  We understand that not every MITRE map item will be relevant to your machine, you simply need to point out the relevant map items.

Example:

  • T1190 - Exploit Public-Facing Application
  • T1059 - Command and Scripting Interpreter
  • T1169 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Virtual Machine Deliverables

To recap, your Virtual Machine submission should include the following at a bare minimum:

  • Build script if possible
  • Detailed build guide in Markdown format.
  • Walkthrough in Markdown format
  • Brief Summary of the exploit path in Markdown format
  • MITRE map alignment
  • Flags and their contents in .txt format

These files should be included in the “submission archive” that you will provide. Please ensure that all files are in plain text (.txt) or markdown (.md) format.

Submission Form

It is crucial that you complete the submission form as accurately as possible, this will avoid possible delays while processing your Virtual Machine. Below, you will find a complete definition of the requested information for the form.

Register an Account with the OffSec Learning Platform (OLP)

You will need to register and activate your OffSec Learning library account here. Submissions without a valid OffSec Community account will NOT be processed.

First and Last Name

We require your legal name and surname as displayed on your ID card or document in order to process your payment should your machine be accepted to our platform.

Community Username

This is the username that you chose when you registered your account on the OffSec Library.

OffSec Community Email Address 

Along with the username, we require the email address you used to register and activate your OffSec Community account.

OSID

This is the student number you receive when you register for one of our academic programs. It is not a mandatory field.

Country

Please select the country where you are legally registered and residing as a citizen. This also allows us to present you with the correct payment options, should your machine be accepted onto our platform.

Home Street Address

For legal reasons we need your complete home address as stipulated on any postal or other form of documentation. 

City

This is the name of the city where your home address is located.  

Territory / Region

This is the region of the country where your home address is located. This could also be the state or province that you reside in. 

Postal Code

We need the official postal or zip code for the area in which you reside. 

Phone Number

This is a working phone number that members of OffSec can contact you on. 

Machine Name

Use this field to specify the name of your virtual machine. Please refrain from using any profanity or vulgarity when deciding on the name.

Submission Archive

This is one of the most important fields on the submission form. You need to ensure that your archive submission contains all the relevant documentation and additional files that we require in our submission guidelines.

There is a 5MB limit on the archive and you need to ensure that it is not password protected.

Submission Archive Contents

Your submission archive needs to contain a number of documents and files. It is vital that you include as many of them as possible to ensure a speedy and effective review of your submission. You can download one of our submission archive files for reference here.

Please ensure that the following items are included in your archive:

  • Build script in Bash or PowerShell
  • Build guide in Markdown format, containing the detailed steps needed to build your VM
  • Walkthrough in Markdown format (.md)
  • Copies of both local and proof.txt files
  • Text file containing the username and passwords for all accounts on the machine 

Here is a sample directory listing of a valid submission archive:

archive-dir.png

Vector 1 Type

This is the primary exploit vector of your virtual machine submission. We categorize this into two subsections, namely web and non-web.

Web Vector

Any vector that relies on a web application for successful exploitation. SQLi, RCE, and arbitrary file uploads are considered web vectors.

Non-web Vector

Non-web vectors are exploits that don’t rely on web applications as the primary ingress point for your machine. This includes Samba, NFS, MySQL, SMTP, or similar services.

Vector 2 Type

This is the vector that you’ve chosen for privilege escalation on your virtual machine. You may use any vector here for your submission. You can enter “Direct to root” if your machine does not contain a privilege escalation vector.

Terms and Conditions

You can download our complete set of Terms and Conditions for User Generated Content here.

Please ensure that you download and review it, as you will need to acknowledge that you’ve read and understood our Terms and Conditions.

Time Frames

OffSec will need time to thoroughly review submitted machines. On average, our submissions review process can take up to four weeks to complete.

Further Communication After Submission

You will receive an initial reply from our team within two business days acknowledging that we have received your submission and that it’s been added to the review process queue. We will contact you via email during the review process should we require any additional or missing information on your submission.

Finally, you can expect an email from our team once the review process has been completed with the final result of your submission review and the next steps needed. 

Compensation

If your submission is accepted, we will contact you about which compensation package your submission has been determined to match and instructions to submit payment details. All payments will be made via wire transfer in your local currency.

Sharing the Virtual Machine

The virtual machine becomes the property of OffSec once we accept your submission and compensate you accordingly. You may not resubmit this machine to any other platform when we accept it to ours. This is detailed in the Terms and Conditions. 

Sharing the Walkthrough

The walkthrough becomes the property of OffSec once we accept your submission and you are not allowed to share the walkthrough with anyone, whether in text, video, or image format. This is detailed in the Terms and Conditions. 

Additional Questions

If you have any additional questions not covered in this FAQ please contact us at ugc(at)offensive-security(dot)com.  Please use this email address before submitting a request at the link below.

Related articles

Powered by Zendesk