Yes, if you supply credentials to that URL it will show the BASIC Auth string in the packet and you "could" decode the credentials that way, but there is not a use case for someone accessing that URL in a browser, and in order to actually decode the credentials it would have to be done within that specific environment. Lastly, it isn't an issue also as your trying to use a URL that doesn't do anything and which the iDrac has no need of ever accessing.
Thanks for the reply. Below are the details from the report. Unfortunately, I no longer have active support on this system, so I don't believe calling in would be an option. So I'm trying to figure out on my own how to remediate this. If not, I'll probably have to disable the web server, which is not desirable. Https redirect is enabled on the idrac. But if I navigate to the url noted in the test output, it stays on HTTP and I get a browser pop up for credentials. The iDRAC firmware version is 2.65.65.65. I also have the exact same finding on another iDrac running version 8 firmware 2.82.82.82.
Service: http (80/tcp)
Vulnerability
Cleartext Transmission of Sensitive Information via HTTP Family name: Web application abuses
Observation: The host / application transmits sensitive information (username, passwords) in cleartext via HTTP.
Remediation: Enforce the transmission of sensitive data via an encrypted SSL/TLS connection. Additionally make sure the host / application is redirecting all users to the secured SSL/TLS connection before allowing to input sensitive data into the mentioned functions.
Consequences:
Impact: An attacker could use this situation to compromise or eavesdrop on the HTTP communication between the client and the server using a man-in-the-middle attack to get access to sensitive data like usernames or passwords.
That does help. It also raises a couple other questions if I can impose on you a bit more. When I navigate to that url, before I get the 404 error, I get a browser pop up asking for credentials. The 404 error happens no matter what I put in. But my question is if I were to supply the root credentials for the idrac on that pop up, would I be inadvertently passing them over an unencrypted connection? I realize I'm making a fairly big leap, but we have some strict compliance standards to meet, and I can see auditors asking a question like that while examining this as a false positive.
Also, let's say I wanted to get rid of this finding anyway, just to remove the headache on the reports. Is there any way to do that aside from disabling the web service? Is there some way to disable WSMAN or at least deactivate that URL, via an RACADM command or something? Thanks again
Yeah, I get it. And I'll probably use that to write it off as a false positive. It just makes my life easier if it's not on the report to begin with. But I'm guessing there is no supported method of disabling WSMAN on these idracs so that url doesn't respond at all.
DELL-Chris H
Moderator
•
9.7K Posts
0
September 6th, 2022 11:00
That's a little tricky to answer.
Yes, if you supply credentials to that URL it will show the BASIC Auth string in the packet and you "could" decode the credentials that way, but there is not a use case for someone accessing that URL in a browser, and in order to actually decode the credentials it would have to be done within that specific environment. Lastly, it isn't an issue also as your trying to use a URL that doesn't do anything and which the iDrac has no need of ever accessing.
Let me know if you get what I mean.
DELL-Chris H
Moderator
•
9.7K Posts
0
September 2nd, 2022 13:00
rob-WPI,
Would you be able to provide additional details on what the scanner reported, so that we can more accurately advise?
The other suggestion would be to call in and discuss with the Systems Mgmt team, so they can analyze the issue.
Let me know.
rob-WPI
7 Posts
0
September 6th, 2022 06:00
Thanks for the reply. Below are the details from the report. Unfortunately, I no longer have active support on this system, so I don't believe calling in would be an option. So I'm trying to figure out on my own how to remediate this. If not, I'll probably have to disable the web server, which is not desirable. Https redirect is enabled on the idrac. But if I navigate to the url noted in the test output, it stays on HTTP and I get a browser pop up for credentials. The iDRAC firmware version is 2.65.65.65. I also have the exact same finding on another iDrac running version 8 firmware 2.82.82.82.
Service: http (80/tcp)
Vulnerability
Cleartext Transmission of Sensitive Information via HTTP
Family name: Web application abuses
Observation: The host / application transmits sensitive information (username, passwords) in cleartext via HTTP.
Remediation: Enforce the transmission of sensitive data via an encrypted SSL/TLS connection. Additionally make sure the host / application is redirecting all users to the secured SSL/TLS connection before allowing to input sensitive data into the mentioned functions.
Consequences:
Impact: An attacker could use this situation to compromise or eavesdrop on the HTTP communication between the client and the server using a man-in-the-middle attack to get access to sensitive data like usernames or passwords.
References: URL:https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management URL:https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure URL:https://cwe.mitre.org/data/definitions/319.html
Test Output: The following URLs requires Basic Authentication (URL:realm name): http://10.0.0.34/wsman:"OPENWSMAN"
DELL-Chris H
Moderator
•
9.7K Posts
0
September 6th, 2022 08:00
Rob-WPI,
What you are seeing is a false positive, as
WSMAN does require BASIC authentication. That is true for the iDRAC7/8
If you navigate to the URL it suggests via HTTP or HTTPS, you will get a 404. It doesn't respond to browser requests on iDRAC7/8
WSMAN implementation on any iDRAC doesn't respond with any data to HTTP from any query methods, only HTTPS.
Let me know if this helps.
rob-WPI
7 Posts
0
September 6th, 2022 09:00
Hey Chris,
That does help. It also raises a couple other questions if I can impose on you a bit more. When I navigate to that url, before I get the 404 error, I get a browser pop up asking for credentials. The 404 error happens no matter what I put in. But my question is if I were to supply the root credentials for the idrac on that pop up, would I be inadvertently passing them over an unencrypted connection? I realize I'm making a fairly big leap, but we have some strict compliance standards to meet, and I can see auditors asking a question like that while examining this as a false positive.
Also, let's say I wanted to get rid of this finding anyway, just to remove the headache on the reports. Is there any way to do that aside from disabling the web service? Is there some way to disable WSMAN or at least deactivate that URL, via an RACADM command or something? Thanks again
rob-WPI
7 Posts
0
September 7th, 2022 07:00
Yeah, I get it. And I'll probably use that to write it off as a false positive. It just makes my life easier if it's not on the report to begin with. But I'm guessing there is no supported method of disabling WSMAN on these idracs so that url doesn't respond at all.
DELL-Chris H
Moderator
•
9.7K Posts
0
September 7th, 2022 07:00
Rob,
The only way would be to disable the Web GUI outright.
DELL-Chris H
Moderator
•
9.7K Posts
0
September 7th, 2022 08:00
Happy to help, keep us in mind if you have any other questions or concerns.
Have a good day.
rob-WPI
7 Posts
0
September 7th, 2022 08:00
That's what I thought. Thank you for your insights. Really appreciate it!