FusionInventoryAgent does not use HTTP Security Headers

[lduczmal]

I have problem with agent, because our company vulnerability detection system reports that http demon used by FusionInventory agent does not use HTTP security headers (X-Frame-Options, X-XSS-Protection, X-Content-Type-Options and Strict-Transport-Security). Is it possible to implement these headers without tampering with the code of Agent?

[g-bougard]

Hi @lduczmal maybe your company vulnerability detection system is just setup too strict and it could include some white listing for FusionInventory agent. The embedded HTTP daemon is a really simple daemon and its purpose is not to server page to a wide range of people and even more nothing critical can be done by this HTTP daemon. Anyway, have you a fully detailed report for one client ? That still could be interesting to investigate but we can't do nothing without knowing what is really checking your detection system.

[lduczmal]

Hi, Yes, I can share detailed report:

HTTP Security Header Not Detected

CAT Value: CGI CVE: n/a Severity: 2 CVSS: None Diagnosis This QID reports the absence of the following HTTP headers according to CWE-693: Protection Mechanism Failure: X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the top level page. X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality. X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type. Strict-Transport-Security: The HTTP Strict-Transport-Security response header (HSTS) is a security feature that lets a website tell browsers that it should only be communicated with using HTTPS, instead of using HTTP. QID Detection Logic: This unauthenticated QID looks for the presence of the following HTTP responses: Valid directives for X-Frame-Options are: X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so. X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself. X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin. Valid directives for X-XSS-Protections are: X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts). X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected. X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report. X-XSS-Protection: 0 disables this directive and hence is also treated as not detected. A valid directive for X-Content-Type-Options: nosniff A valid HSTS directive Strict-Transport-Security: max-age=; [; includeSubDomains][; preload] NOTE: All report-only directives (where applicable) are considered invalid. Result [( port: 62354; protocol: tcp; )] X-Frame-Options or Content-Security-Policy: frame-ancestors HTTP Headers missing on port 62354. GET / HTTP/1.0 Host: x.y.z.v:62354 HTTP/1.1 200 OK Date: Sun, 23 May 2021 22:26:13 GMT Server: libwww-perl-daemon/6.01 Content-Length: 651 Content-Type: text/html X-XSS-Protection HTTP Header missing on port 62354. X-Content-Type-Options HTTP Header missing on port 62354. Consequence Depending on the vulnerability being exploited, an unauthenticated remote attacker could conduct cross-site scripting, clickjacking or MIME-type sniffing attacks.

[lduczmal]

I know, that site presented by Fusion-Inventory Agent is not served for wide range of people, and is accessible only from internal network, but is accessible an it can be used as beachhead for any black-hat. I cannot assure that all my coworkers are trustworthy.

[g-bougard]

Hi @lduczmal

thank you for this report. Can you also tell us what software produced that report ?

it can be used as beachhead for any black-hat.

Here, I don't really see what can do a "black-hat" with an agent, so I'm not fully agree with you. Do you have any specific scenario example in mind ? Indeed, I think you're just following this report explanations which were implemented for poor web site servicing and the agent is not a web site server, but an api server. So I'm really not sure we can apply this report to the agent. Knowing what is your security software could help us to understand what this report is really targeting ?

As I said, the HTTP daemon purpose is really limited for the agent. There's essentially 2 use cases for this interface:

1. you can locally access the agent status looking at http://127.0.0.1:62354. If the "httpd-trust" configuration includes 127.0.0.1, you can even click to immediately start an inventory.
2. as the glpi server ip (resolved from server when set) is also trusted, the GLPI server can trigger the event to run tasks immediately. This is used to "wake up agents" for the network discovery, network inventory or deploy tasks defined in FusionInventory for GLPI plugin for example.

By default, no other IP than GLPI server IP is trusted, so the served page to any other ip is a really basic page without any interaction. I can agree this is still a leak as this tells FusionInventory agent is running on the machine but this is definitively not a breach.

With the new HTTP daemon plugins support feature, the agent can effectively do a little more, but still not many thing and the plugins are justed disabled by default. But, there is still one plugin you can enable to enhance the agent security, this is the SSL support one so the local url becomes https://127.0.0.1:62354.

I'll try anyway to take a deeper look in this report keeping in mind a HTTP daemon plugin could introduce some other attack vectors if security is forgotten during its developement.