[HackerNotes Ep.93] A Chat with Dr. Bouman - Life as a Hacker and a Doctor

Hacker TLDR;

• Hacking on Amazon: After spending 6+ years consistently on one program, Jonathan and Justin had a few tips when it comes to identifying and picking a target to hack long term on:

  • Tips for long-term hunting

  • Jonathan has multiple avenues of work/hobbies which he uses to his advantage. When burnout is approaching with one area, switch to focus on another area to rest and relax.

  • Focus on hacking for fun and the process of finding bugs instead of the end results.

  • Try to find a bug bounty partner that you can trust - collaborating with a partner long term and having a mutual understanding, communicating with them and splitting stuff.

  • Tips for picking a program

  • Finding an attack surface which excites you OR an attack surface you can fully access is a big factor when unlocking an attack surface and hunting long-term. Forcing yourself through a target you don’t enjoy or can’t fully access will probably mean you won’t hang around on it for long.

  • If you have no prior experience and you’re unsure of the program quality, try submitting a few reports to get a feel for 1. their team and 2. their threat model and what they care about. Both of these factors can make or break a program.

  • Are you familiar with any specific technologies, integrations or languages? Try to find a target that lets capitalize off this prior experience you’ve made.

  • Check out some other tips I mentioned in a prior episode here on this topic.

• SSTI on FileSender: A bug 6+ years old. If you haven't heard of FileSender before, it was made in 2007 as an open-source project as a means to securely transfer large files and is heavily used in education and healthcare. After digging around in a B64 error message being rendered, Jonathan identified an SSTI allowing him to dump config variables ranging from DB to S3 creds. Best of all, this was an unauthenticated bug, resulting in CVE-2024–45186 being issued. Check out the full research here.

• SSTI & Peripheral Scopes: Jonathan has uncovered a bunch of SSTI in his time hunting and has a few tips to help automate some of the processes:

  • Customize Burp Scanner Profiles for Targeted Vulnerabilities: Instead of running Burp Scanner with all its default checks - which can be time-consuming and generate excessive noise - create custom scanning profiles focused on specific vulnerability classes like SSTI. By tailoring the scanner to look only for SSTI-related issues, you increase efficiency and the likelihood of uncovering relevant vulnerabilities.

  • Filter Checks Based on Application Technologies: Burp Scanner offers checks tailored to specific programming languages and frameworks. If you know the target application uses a particular technology (e.g., Python with Jinja2 templates), adjust your scanning profile to include checks pertinent to that technology. This ensures you're not wasting resources on irrelevant tests and are focusing on vulnerabilities that are more likely to exist in the target. Equally, the more noise you make when hunting the worse it is for you, as you’ll likely get snagged by a WAF.

  • Understand and Identify the Templating Engine Used: Knowledge of the templating engine (like Jinja2, Thymeleaf, or Smarty) used by the application can significantly aid in crafting effective SSTI payloads. Look for telltale signs of template syntax in error messages or page content. Use Burp Suite's search functionality to scan through your project data for common template expression patterns (e.g., {{ }}, <% %>, ${ }). This can help you pinpoint injection points that might otherwise be overlooked.

  • Uncover Hidden Parameters with Param Miner: Hidden or undocumented parameters can be gateways to vulnerabilities. Incorporate the Param Miner extension into your workflow to automatically discover these parameters. Once identified, systematically test them for SSTI and other injection flaws. The workflow typically involves:

    • Running Param Miner to find hidden parameters.

    • Injecting SSTI payloads into these parameters.

    • Analyzing responses for signs of successful injection or error messages indicating template processing.

The White House has recently banned the use of Kaspersky products across the United States, citing concerns over potential data access risks and allegations of incorporating "backdoors" in their software.

Learn More About the ThreatLocker® Cyber Health Report Here

Hacking on Amazon

Jonathan Bouman's background is quite unique. Not only is he a doctor, but he’s also an elite-level hacker in the Live Hacking Event (LHE) scene. Throughout his bug bounty career, he has focused primarily on one program—Amazon—and he dives into why that is.

Jonathan is a strong advocate of hacking Amazon; he’s been doing so for around six years now.

His journey began with an attempt to get rich quickly from Amazon by creating a custom integration, hoping to earn through the affiliate program. Unfortunately, after just four days, he was banned from the affiliate program, and that plan fell through.

This setback eventually led him to discover a bug by dissecting the Amazon Android app, resulting in a cross-site scripting (XSS) vulnerability. This is one of the few bugs he has publicly disclosed from Amazon, dating back to when their program was still a Vulnerability Disclosure Program (VDP). The discovery and write-up are quite interesting, and you can check it out here (from 2018): Reflected Client XSS @ Amazon.com

After some continued success on the Amazon program and being noticed for some of his findings, Amazon eventually reached out to him asking if he wanted to be part of their early beta version of what is now, their bug bounty program.

Back then, they gave out certificates for hitting certain bounty thresholds. I must admit, these certificates do look pretty neat and would be one to show the grandkids. This is the one issued to ZSeano:

That's where Jonathan and ZSeano's collaboration journey kicked off. When Jonathan got the number two certificate instead of the top spot, he dug around and found out that it was actually ZSeano who snagged first place on Amazon. This discovery led them to team up, and they've been collaborating ever since.

If you were at the latest LHE in Edinburgh, you already know these two totally smashed it with Amazon. They came in first and third, respectively.

Jonathan did go into some detail as to why he’s stuck this long with Amazon as a program; complexity, they care about their attack surface, and a lot of active development.

One of the key things that makes Amazon stand out is consistency in the program - how do you apply CVSS, how do you rate certain bugs, and what do you do with these edge case bugs?

Despite having new leadership and new teams changing over the years, they’ve managed to maintain their quality and ethos throughout managing the program.

If you’re still finding your feet and trying to settle in on a program, we’ve got some tips for you. From my experience so far, I’ve seen that not every program is for every hunter - every program has a unique threat model and attack surface, and every hunter is unique.

It can be a bit of a process, but let’s dive into them:

Tips for long-term hunting

• Jonathan has multiple avenues of work/hobbies which he uses to his advantage. When burnout is approaching with one area, switch to focus on another area to rest and relax.

• Focus on hacking for fun and the process of finding bugs instead of the end results.

• Try to find a bug bounty partner that you can trust - collaborating with a partner long term and having a mutual understanding, communicating with them and splitting stuff.

Tips for picking a program

• Finding an attack surface which excites you OR an attack surface you can fully access is a big part. Forcing yourself through a target you don’t enjoy will probably mean you won’t hang around on it for long.

• If you have no prior experience and you’re unsure on the program quality, try submitting a few reports to get a feel for 1. their team and 2. their threat model and what they care about. Both of these factors can make or break a program.

• Are you familiar with any specific technologies, integrations or languages? Try to find a target that lets you capitalize off this prior experience you’ve made.

• Check out some other tips I mentioned in a prior episode here too: https://blog.criticalthinkingpodcast.io/p/hackernotes-ep-91-zero-to-lhe-in-9-months-feat-gr3pme#:~:text=my%20hacker%20development!-,Picking%20a%20Target,-For%20a%20while

SSTI on FileSender

A bug 6+ years old. If you haven't heard of FileSender before, it was made in 2007 as an open-source project as a means to securely transfer large files. Jonathan covers this on his writeup ‘…The idea for FileSender was born in 2007 during a task-force meeting of the pan-European network for the research and education community GÉANT. Its main goals were to facilitate painless sharing of arbitrarily large files with a private audience through a trusted intermediary.’

FileSender is also used at Jonathan’s University and is even known across healthcare and multiple education institutes, so it’s safe to say that any major bugs on this would be pretty impactful.

If you haven’t used it before, it’s pretty extensive. It supports things such as SSO, and support for S3 and offers just about every feature you’d want for quick and painless file transfers.

With Jonathan being a known hunter, the University got in contact with him and asked about testing a new version of FileSender they were implementing. It had been pentested already and they asked him to take one last look at it to be safe.

While looking around some of the unauthenticated attack surfaces, some error messages kept cropping up in a B64 format within a query parameter. When decoding the B64 error messages, he noticed the B64 was used in conjunction with the templating happening on the application:

The reason they used templating is for templating different universities’ logos, template messaging; and everything needed to make it custom per implementation.

If you see something B64 encoded, it naturally perks your interest. Jonathan also had access to the source which helped pinpoint exactly where and how this error was being generated and used. In the source code, there was a config template variable that was used for the server paths.

It also turns out he was able to control the error message associated with the exception that was being rendered. The B64 error would be concatenated with the template and subsequently rendered. This, of course, results in Server-side template injection (SSTI).

With access to the source and looking at what was available from this context and at other config variables in the templates, he identified DB and S3 variables in use. Calling these in his SSTI injection point, he could render and pull the creds!

This led to CVE-2024-45186 being born. Looking at Git commits, he determined this was around for 10 years!

• Research: https://medium.com/@jonathanbouman/cve-2024-45186-unauthenticated-ssti-bug-in-filesender-exposes-mysql-s3-credentials-and-other-463a9efc1478

• Source: https://github.com/filesender/filesender/blob/development/templates/exception.php

Hacking the Dutch Healthcare System

This is one of those findings where it emphasises that each app/client has a unique threat model.

Working in healthcare and being an ethical researcher, approaching a target that has no vulnerable disclosure or VDP can become quite tricky. As Jonathan is known in his space and the company was founded by doctors, Jonathan used his advantage to approach them and hope for a doctor/ethical doctor-friendly response.

We also all know that healthcare is a big target for ransomware attacks at the moment. Being a critical service that has historically paid ransomware, attackers have and do approach healthcare through any means necessary to ransomware them.

He actually found 3 bugs in one here, but the ransomware-related bug allowed him to upload arbitrary files (such as .exes) to doctors’ notes and achieve RCE on the doctor’s device when they open and subsequently execute the attachment within the notes.

The thing with this one is, that any user can sign up and contact their healthcare professional which subsequently allows you to send and raise doctors’ notes through your appointment, which also means any attacker could do the same.

This is a proof of concept of what a doctor would see when someone attaches evidence to their appointment notes but it is in fact an exe:

Straight forward but effective; understand your target, and their threat model and figure out what could hurt them.

• Research: https://medium.com/@jonathanbouman/bricks-huisarts-v2-3-12-94166-vulnerable-to-executable-uploads-in-e-consultation-send-by-patients-631f6152cf8e

SSTI & Peripheral Scopes

If you listened to the pod or looked at Jonathan’s research, you’d probably notice a common pattern around Server-side template injection finds.

Jonathan uses some automation around these finds when fuzzing, and breaks them down on the pod. There are probably some nice quality-of-life type things you could take away to help add some additional checks to your hunts at little to no overhead. Let’s jump in:

• Customize Burp Scanner Profiles for Targeted Vulnerabilities
  Instead of running Burp Scanner with all its default checks—which can be time-consuming and generate excessive noise—create custom scanning profiles focused on specific vulnerability classes like SSTI. By tailoring the scanner to look only for SSTI-related issues, you increase efficiency and the likelihood of uncovering relevant vulnerabilities.

• Filter Checks Based on Application Technologies
  Burp Scanner offers checks tailored to specific programming languages and frameworks. If you know the target application uses a particular technology (e.g., Python with Jinja2 templates), adjust your scanning profile to include checks pertinent to that technology. This ensures you're not wasting resources on irrelevant tests and are focusing on vulnerabilities that are more likely to exist in the target. Equally, the more noise you make when hunting the worse it is for you, as you’ll likely get snagged by a WAF.

• Understand and Identify the Templating Engine Used
  Knowledge of the templating engine (like Jinja2, Thymeleaf, or Smarty) used by the application can significantly aid in crafting effective SSTI payloads. Look for telltale signs of template syntax in error messages or page content. Use Burp Suite's search functionality to scan through your project data for common template expression patterns (e.g., {{ }}, <% %>, ${ }). This can help you pinpoint injection points that might otherwise be overlooked.

• Uncover Hidden Parameters with Param Miner
  Hidden or undocumented parameters can be gateways to vulnerabilities. Incorporate the Param Miner extension into your workflow to automatically discover these parameters. Once identified, systematically test them for SSTI and other injection flaws. The workflow typically involves:

  • Running Param Miner to find hidden parameters.

  • Injecting SSTI payloads into these parameters.

  • Analyzing responses for signs of successful injection or error messages indicating template processing.

In one instance, Jonathan discovered an RCE using the Perl scanning profile. You can check out a full writeup for that one here: https://medium.com/@jonathanbouman/remote-code-execution-at-ws1-aholdusa-com-compromising-logins-of-ahold-delhaize-usa-employees-c7c9aca7e05d 

To be honest, this type of thing is never something I would have tried on a bug bounty target because of all the problems and noise Burp can make. Historically, I would only ever do this on a pentest, but I’ll be trialling a few specific scan profiles going forward to see if they can improve my workflow at all.

Peripheral scopes

Another thing Jonathan does that effectively expands his attack surface is by leveraging peripheral scopes, particularly mobile applications. Here are a few tips on how he does it, along with tips on how to reduce friction when doing so in your workflow:

1. Modify Mobile Apps for HTTPS Inspection

   • Use apk-mitm for Android Apps: Jonathan utilizes apk-mitm, a CLI tool that automatically modifies Android APK files to disable certificate pinning. This allows the interception of HTTPS traffic using Burp Suite.

   • Set Up a Jailbroken iOS Device: For iOS apps, he uses a jailbroken iPad with the checkra1n jailbreak (note: the correct spelling is "checkra1n") to bypass security restrictions and inspect app traffic.

2. Prepare a Robust Testing Environment

   • Have Multiple Devices: Jonathan recommends having two jailbroken devices for each platform (iOS and Android). This ensures continuity if one device becomes unstable or bricks—a common risk when jailbreaking.

   • Maintain Cross-Platform Systems: Having both iOS and Android systems allows you to choose the easier platform to work with for a particular target, maximizing your testing efficiency. Equally, there are cases where different APIs are used for different platforms, potentially opening up additional attack surfaces.

That’s it for this week.

As always, keep hacking!