WebApp scan registers a vulnerability with host headers on protected site

Products

• SITEMINDER
• CA Single Sign On Agents (SiteMinder)

Issue/Introduction

We ran a web application vulnerability scan on one of our Siteminder protected sites and found that when we try to inject a host header (with a dummy host) on a protected site, the web agent sets the TARGET URL to the dummy host and tries to redirect or resolve to it.

We have defined a ValidTargetDomain on the agent so as to prevent phishing attacks but are concerned about whether this host header injection presents an issue.

Below is a demonstration of the issue, where foo.bar is a dummy host that is being injected in the host header to a Siteminder protected URL

$ wget --save-headers    -O -   -v --header="Host: foo.bar" https://company.example.com|head

--2022-01-13 08:42:17--  https://company.example.com

Resolving company.example.xx.yy (example.xx.yy)... ###.###.######

Connecting to company.example.xx.yy example.xx.yy)###.###.######|:443... connected.

HTTP request sent, awaiting response... 302 Found

Location: https://logontest7.##.##/SmMakeCookie.ccc?SMSESSION=QUERY&PERSIST=0&TARGET=$SM$https%3a%2f%2ffoo%2ebar%2f [following]

--2022-01-13 08:42:18--  https://logontest7.##.##/SmMakeCookie.ccc?SMSESSION=QUERY&PERSIST=0&TARGET=$SM$https%3a%2f%2ffoo%2ebar%2f

Resolving logontest7.##.## (logontest7.##.##)...###.###.##.####

Connecting to logontest7.##.## (logontest7.##.##)|###.###.##.####x|:443... connected.

HTTP request sent, awaiting response... 302 Found

Location: https://foo.bar/?SMSESSION=NO [following]

--2022-01-13 08:42:18--  https://foo.bar/?SMSESSION=NO

Resolving foo.bar (foo.bar)... failed: No address associated with hostname.

wget: unable to resolve host address ‘foo.bar’

Siteminder probably shouldn’t be using the Host header since it can be injected. Should we consider this as a vulnerability? Has anyone reported this as a vulnerability?

Environment

Release : All

Component : SITEMINDER WEB AGENTS

Resolution

This is not a Siteminder vulnerability.  This type of attack is only possible if DefaultAgentName is set and assigned to a policy realm that allows access.  The way to avoid this is to use only defined agent names (via the AgentName parameter) to handle the expected, legitimate requests.  Set a value for DefaultAgentName, but assign that DefaultAgentName to either no realms or only a realm that denies access (this allows you to leverage responses to display a custom message when an unexpected HOST header is submitted with a request).