[HackerNotes Ep. 78] Less Writing, More Hacking - Reporting Efficiency Techniques

Weekly security research, WAF bypasses and better reporting. Check it out in this HackerNotes post.

Author

gr3pme
July 05, 2024

Hacker TLDR;

XSS WAF Bypasses - HTML Entities

This was originally tweeted by therceman and highlights some nice multi-character HTML entities that can be abused for WAF bypasses. The original thread can be found here: https://x.com/therceman/status/1803666353892585642:

Essentially, this allows you to use an entity such as fj which will be interpreted as fj by the browser. These aren’t the only ones that exist, however.

Gareth Heyes also responded to the Tweet with a custom Shazzer fuzz which identified a total of 50 of these multi-char HTML entities, which seem to be consistent across browsers: 

&;=&
&;=&
'='
*=*
=⃥==%E2%83%A5
\=\\
:=:
,=
@=@
`=`
$=$
===
!=!
fj=fj
`=`
>=>
>=>
^=^
{={
[=[
{={
_=_
(=(
[=[
<=<
<=<
*=*

=
#=#
>⃒=>%E2%83%92
<⃒=<%E2%83%92
%=%
.=.
+=+
?=?
"="
"="
}=}
]=]
}=}
)=)
]=]
;=;
/=/
	=
_=_
|=|
|=|
|=|

The original fuzz vector can be found here: https://shazzer.co.uk/vectors/667b4120d631543fa1c420a5

Be sure to keep a look out for Shazzer-related content as it’s always relevant and quality research.

NextJS Cache Poisoning

NextJS seems to be a rich patch for research at the moment, with some more dropped on cache poisoning. This is a great read if you aren’t as familiar with this type of bug, but the TL;DR here is 3 different vulnerabilities were found during the research which resulted in some serious bounties.

A brief overview of the bugs:

  • First Vulnerability: A cache-poisoning via the x-middleware-prefetch header in Next.js middleware, allowing empty responses to be cached.

  • Second Vulnerability: The Rsc header in React’s Server Component could be abused to cache the React component server instead of the root page of a web app.

  • Third Vulnerability: The x-invoke-status header could overwrite HTTP status codes, meaning error pages could be cached.

Cache poisoning seems to be a great bug to research if you’re more of a wider recon target. Equally, if you do decide to look at some cache poisoning-based bugs, keep a look out for any form of cache buster header and, if you can, look at the codebase surrounding it. There may be a way to bypass it.

Check out the full research here - there are even tips on how to handle triage with this bug class: https://zhero-web-sec.github.io/research-and-things/nextjs-and-cache-poisoning-a-quest-for-the-black-hole

Polyfil Drama - Supply Chain Attacks

What happens when a domain gets sold which is used for a very popular open-source project? A backdoor gets introduced of course!

Polyfil’s domain was bought and the domain buyer ended up backdooring a lot of Polyfil instances, here’s Naglis's tweet summarising it - https://x.com/galnagli/status/1806095911405371739:

If you’re looking for a Nuclei template to easily detect vulnerable instances of this, Nagli dropped a Nuclei template to detect it here: https://github.com/NagliNagli/Shockwave-OSS/blob/main/attack-surface-cves/polyfill-detect.yaml

If I had to bet, we’d see attacks like this more and more in the future. Purchasing or sponsoring an already reputable project or domain which is widely used is an easy way for a malicious actor to introduce code to a wide audience which is usually considered as ‘trusted’.

Another thing to keep internal teams on their toes.

The life of a security engineer

If you're a hunter and haven’t had any experience of what life is like from the other side of the fence, this blog might be for you.

Lighthearted and quite an amusing read, but implementing fixes and fixing bugs isn’t as straightforward as it always seems.

Give it a read if you want a brief glimpse of what it's like to be on the fixing side of hunting: https://mewy.pw/posts/2024-06-29-why-cant-you-fix-this-one-bug

Reporting Tips

Reporting can take it out of you, especially when you’ve found a tonne of cool bugs and have to write numerous bugs up.

Fortunately, we have some tips for better report writing. Not only will this help you save time over the long term with reporting, but reduce the friction during triage. Quicker and fewer questions asked during triage usually means quicker or even higher payouts, so a good bug writeup will help you out.

Here are some tips for better report writing:

  • POC Video - ALWAYS: Attaching a video of your exploit chain start - finish will MASSIVELY help triage. Even if they can’t accurately reproduce the bug, it will likely still be a quicker process with an attached video.

    • Recording Software: Most OS’s include some form of screen recording now; even the snipping tool on Windows has a record option. If you aren’t a fan of built-in or want some more flexibility, some alternatives are below:

    • Screen recording tips:

      • Embed the video in the report, don’t attach the video as an attachment triagers have to then download and view it separately.

      • OBS Users: Get yourself a pause button (OBS -> Settings -> Output -> Recording -> Encoder to X264 and output filetype to mp4)

  • Screenshots in reports: Having screenshots is essential in almost all writeups. If you want some added functionality to help with editing or highlighting areas of your screenshots, check out the below replacements for the snipping tool:

  • Markdown tips: Get familiar with Markdown and the nuances of the platform you're reporting on. Different platforms implement some custom functionality around markdown. One example of using markdown is via the characters ‘```’ to syntax highlight (including support for HTTP) will make your reports easier to read.

  • Report Templating: Almost all platforms offer this now but report templating can save you a lot of time. Having a generic enough template for each finding type with placeholders to swap out can save you a bunch of time if you’re reporting similar issues over a long period of time. Take some time to craft some good templates (check prior reports if you don’t want to start from scratch!)

  • Writing Reports with AI: AI in report writing has quite a few uses. You could use it to generate templates based on previous reports, you could create a prompt which you provide HTTP requests + responses to generate a report from - the use cases stretch far. Some tools to help this:

  • General hacking tips: Although these are not necessarily reporting, it’s loosely related. Here are some more tips to supplement your hacking and reporting:

    • Removing as much friction as possible: Identifying areas in your hacking where you are context-switching can result in a lot of lost time. Whether you improve processes by templating your reports, using extensions or switching up your toolkit, take some time to identify what areas can be improved upon.

    • Supplemental learning: If you only have an hour of free time here and there, take some time to learn or set up an environment that will save you time and friction when you eventually have a few hours to spend hacking. This compounded overtime will pay massive dividends.

    • Loom videos: If you’re in the zone record on a target and have to stop hacking or do something else, record a video and brain dump exactly where you’re at mentally. Next time you back on the target, listen before hacking and you can drop straight back into the flow state

As always, keep hacking!