iDRAC9 Information Disclosure vulnerability

Oh dear, the bogus concept of security by obscurity strikes again.

Hello 946one,

Is the iDRAC and BIOS firmware versions up to date?

Do you have a CVE number I can reference?

The vast majority of these are concerning the use of extremely old TLS 1.0 encryption standards.

Nearly all of these “Vulnerabilities” are addressed by updating the Idrac firmware to latest which removes TLS 1.0 entirely.

Yes, we are at the latest BIOS and iDRAC release. iDRAC firmware is 5.10.00.00. We have TLS Protocol set to TLS 1.2 and higher. This fining was from a penetration test, and don't have a CVE in the report

Hello 946one,

Could you please provide this information - How to Report a Security Vulnerability:

When reporting a potential vulnerability, we ask that you include the below information  to help us better understand the nature and scope of the reported issue:

• Product name and version containing the vulnerability
• Environment or system information under which the issue was reproduced (for example: product model number, operating system version, and other related information.)
• Type and/or class of vulnerability (for example: XSS, buffer overflow, and RCE)
• Step-by-step instructions to reproduce the vulnerability
• Proof-of-concept or exploit code
• Potential impact of the vulnerability

If it contains private information then you can send it to me in a Private Message

• Product name and version containing the vulnerability = iDRAC9 firmware version 5.10.00.00
  
• Environment or system information under which the issue was reproduced = iDRAC9 in PowerEdge R640, OS Server 2016
  
• Type and/or class of vulnerability=CWE-200:Exposure of Sensitive Information to an Unauthorized Actor
  • Penetration test discovered the following when testing the iDRAC IP address:
  • Header on tcp port 80 http = Apache (302-https://x.x.x.x:443/ )

    Header on tcp port 443 https = Apache ( 302-https://x.x.x.x/restgui/start.html )

• This is in a high security environment, we are required to mitigate all findings. I understand there isn't a CVE for this, but am reaching out for any information you can provide.

Thank you for that information.

Was it flagged on previous firmware version? Or just 5.10.00.00?

What was the last version you had that did not flag?

5.10.00.00 added a host header check. You can try disable it with racadm command and scan again.

racadm set idrac.webserver.HostHeaderCheck 0

This was flagged on previous version as well.

I will try your suggestion and have have the iDRAC retested. I'll post the result

I tried your suggestion of "racadm set idrac.webserver.HostHeaderCheck 0." The Penetration test was run last night. TCP ports 80 and 443 on the iDRAC still return http-server-header: Apache.  Any suggestions will be appreciated

Hello 946one,

Could you please also check this KB article:

 https://dell.to/3nVwHQQ

By default, iDRAC9 will check the HTTP / HTTPS Host Header and compare to the defined 'DNSRacName' and 'DNSDomainName'. When the values do not match, the iDRAC will refuse the HTTP / HTTPS connection. In iDRAC9 5.10.00.00, this Host Header enforcement can be disabled with the following RACADM command.
 

#Disable host header check
racadm set idrac.webserver.HostHeaderCheck 0

Note: Only set the HostHeaderCheck value to '0' when manual Host Record exists within DNS environment.

When the HTTP / HTTPS Host Header check is enabled (more secure), iDRAC can be accessed using the IPv4/IPv6 address, the RAC Name and/or the defined iDRAC FQDN (DNSRacName.DNSDomainName). If end-user is accessing with hostnames that iDRAC may not be aware of (such as a manual DNS entries added in DNS records), iDRAC9 5.10.00.00 firmware version introduced a new attribute 'ManualDNSEntry'. This new setting can be updated with up to 4 IP addresses / host names / FQDNs to provide an allow-list of Host Headers. This ensures that incoming requests are not dropped when the HTTP / HTTPS Host Header carries one of the entries in the 'ManualDNSEntry' setting.
 

# Add manual entry to allow list
racadm set idrac.webserver.ManualDNSEntry 192.168.20.30
racadm set idrac.webserver.ManualDNSentry 192.168.20.30,idrac.mydomain.com 

This additional configuration is required in cases such as when:
 

• End-user is using manual DNS configuration to access iDRAC (Manual DNS Host Record
• Subject Alternative Name/Wild card certificate is used to access the iDRAC
• Accessing iDRAC using host IP address directly (via ISM)

Please let us know if you have any questions,

Thanks

Thank you for that information. I have read the KB Article, but it doesn't seem to apply
The KB Article states that Host header check compares the defined 'DNSRacName' and 'DNSDomainName'.
Our issue is that our penetration testing software is checking the header response from the iDRAC on ports 80 and 443.
The part of the header response we are trying to remove is:
server: Apache

I disabled the host header check with "racadm set idrac.webserver.HostHeaderCheck 0" and the test
still returned "server: Apache" I also enabled the host header check with "racadm set idrac.webserver.HostHeaderCheck 1"
and the tests returned "server: Apache"

I'm working in a high security environment, we have to address any CVE's , as well as weaknesses. This does not have a CVE, but it is a weakness as defined in CWE 200 at https://cwe.mitre.org/data/definitions/200.html
The webserver information has appeared in the header on ports 80 and 443 for at least these versions:
5.10.00.00, A00 08 Dec 2021 ( currently installed)
5.00.10.20, A0005 Oct 2021
5.00.00.00, A0021 Jun 2021

Thank you for the update.

Did you ever get a CVE number?

This could help us look into it ; Can you let me know which version started reporting this vulnerability or the last one that did not?

Your current version 5.10.00.00

This page list previous versions:

https://dell.to/3qZYPV7

>Other Available Versions (at the bottom of the page)

5.00.20.00

5.00.10.20

5.00.00.00

4.40.40.00

4.40.10.00

Or older

I had it lab tested but they didn't see hostname.. There is an attribute for hostname but they say it's an empty placeholder. No data.

The scanner should provide specifically what is producing the host name. 

Would you be able to provide the scan results?

Thank you for testing in a lab. Our issue isn't the hostname, it is the "http-server-header: Apache" response. Below is the portion of the scan result with names redacted. We are looking to remove "Apache" from the http headers, the rest is good:

PORT STATE SERVICE VERSION
443/tcp open ssl/http Apache httpd
_Requested resource was https://XXXXXXXX/orgainizationName=XXXXXXXX
Subject Alternative Name: DNS:XXXXXXXX
http-server-header: Apache
_ssl-date: TLS randomness does not represent time