Embedthis has patched a null byte injection vulnerability in GoAhead, the embedded web server deployed in hundreds of millions of devices.
“A specially crafted URL with a %00 character embedded before the extension can cause an incorrect file with a truncated filename to be served,” reads a security advisory on GitHub documenting the bug.
Citing hypothetical URL https://example.com/example%00.html, the advisory says “the %00 is decoded to be a NULL”, resulting in the file handler serving ‘example’ instead of ‘example.html’.
As a result, “remote attackers could gain access to documents with names that are strict subsets of longer valid URLs.”
The advisory nevertheless describes the bug’s severity as ‘low’ since “an exploit requires [either] an additional vulnerability via uploaded malicious files” or a device that has misconfigured file uploads to be permitted “to a directory that also serves content”.
CSP bypass leading to XSS
The flaw was discovered by Luke Rindels, an infosec Master’s student at Carnegie Mellon University, during a PlaidCTF 2021 challenge earlier this month that involved manipulating IoT camera and sensor values.
“The vulnerability abuses the mismatch between route extension parsing and the decoded filename to dupe GoAhead into thinking a file should be sent to the JST [JavaScript Template] handler even when it has an improper extension,” Rindels told The Daily Swig.
“GoAhead should only send .html files to the JST handler, but the vulnerability allows for any file to be sent to the JST handler.
“Using a highly customized and unlikely setup,” his exploit resulted “in a CSP bypass leading to XSS.
“Data leakage and XSS are what I imagine to be the most likely outcomes of successful exploitation, but it all depends on what templates the operator has implemented,” he continued.
However, Rindels conceded a lack of familiarity “with how GoAhead is used in the real world, so I don't really know how popular Javascript Templates are and if they're used in any way that poses a threat”.
Incorrect assumptions
While hunting for evidence of incorrect extension parsing during the CTF, he realized that “the request URL must have been decoded, otherwise it wouldn’t be able to call strrchr() with . and / delimiters”, recounts Rindels in a blog post published yesterday (26 April).
He suspected that a null bytes exploit would fail, possibly because “dangerous URL encodings like %00” wouldn’t be allowed or decoded, resulting in an error being served or an “attempt to serve /example%00.html”.
Alternatively, he speculated, “if the %00 is decoded, in a request for /example%00.html the extension will simply be cut-off. There will be no extension and GoAhead will attempt to serve /example.”
Undeterred, he uploaded a snapshot with the name example containing <script nonce="<% nonce(); %>"> alert(1);</script>, issued a request for /data/snapshot/example%00.html, “and to my amazement the nonce was there!”
Explaining how his “assumptions were incorrect”, he told The Daily Swig: “The route extension is parsed without the null byte interfering (.html), but the filename fetched by GoAhead is truncated because of the null byte (example).”
In the blog post he added that “this is also pretty serious because it [means] any route that depends on an extension to determine the correct handler can be bypassed!”
Incidentally, the exploit failed to secure the CTF flag because Chrome “does not allow encoded null bytes in URLs”.
However, Rindels said he may try to secure his first CVE with the flaw.
Patching
Embedthis has addressed the vulnerability in GoAhead versions 4.1.4 and 5.1.2. Version 2.2 is not affected.
Embedthis “responded very quickly”, patching the flaw on April 5, four days after it was reported, said Rindels.
The vendor says GoAhead is the world’s most popular embedded web server and is used to host “dynamic embedded web applications via an event driven, single-threaded core” within medical devices, networking equipment, and factory automation systems, among other devices.
Comments
Post a Comment