Penetration Testing mailing list archives
RE: verify HTTPS 'vulnerabilities'
From: "Carl" <carl () agenda-security co uk>
Date: Fri, 22 Jul 2005 10:32:27 +0100
Dan, Can't help you with the ciphers, but it should be simple to verify the internal IP leakage. Using a tool called 'stunnel' you can create a transparent SSL tunnel from your PC to the target, such that: nc localhost 443 will connect to stunnel (listening on port 443 on your box). Stunnel will then setup an SSL encrypted session with the target. You can then 'talk' HTTP as normal, and stunnel will transparently encrypt/decrypt the SSL traffic to the server. For example: [root@localhost ~]# nc localhost 443 GET /exchange HTTP/1.0 HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.0 Date: Fri, 22 Jul 2005 09:28:47 GMT WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="192.168.0.1" Content-Length: 24 Content-Type: text/html Error: Access is Denied. You can see here that because you've not specified a 'Host:' header, the IIS server uses its own IP address for the realm info. This typically happens when a server is hidden behind a NAT gateway. Hope that helps, Cheers, Carl Network Security Consultant Agenda Security Services T: UK 08456 44 55 46 F: UK 08456 44 55 47 W: http://www.agenda-security.co.uk -----Original Message----- From: Dan Rogers [mailto:pentestguy () gmail com] Sent: 21 July 2005 16:06 To: pen-test () securityfocus com Subject: verify HTTPS 'vulnerabilities' List, Simple question: I have a report from Nessus telling me that a web server is offering 'export class' cyphers for it's SSL/TLS service. Nessus also managed to obtain an internal IP address from the host (which is correct). Only HTTPS is open. However the target host requires basic authentication, and I don't have any credentials to obtain access. I would like to verify these manually, and would usually just use something like wfetch. However, I'm not getting the usual prompt that my encryption is too weak. Instead in the response I can see a message saying the page cannot be displayed. There is also no sign of the internal IP address. Can anyone tell me how they would prove that they are not false positives (I know the IP address is correct, but the client may want to replicate the vulnerability so they can be sure when they go to fix it)? thanks Dan DISCLAIMER Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited.
Current thread:
- verify HTTPS 'vulnerabilities' Dan Rogers (Jul 21)
- RE: verify HTTPS 'vulnerabilities' Daniel Grzelak (Jul 21)
- RE: verify HTTPS 'vulnerabilities' Omar Herrera (Jul 21)
- Re: verify HTTPS 'vulnerabilities' Thomas Springer (Jul 26)
- Re: verify HTTPS 'vulnerabilities' Michael Sierchio (Jul 26)
- <Possible follow-ups>
- RE: verify HTTPS 'vulnerabilities' Jarmon, Don R (Jul 21)
- RE: verify HTTPS 'vulnerabilities' Jordan Del-Grande (Jul 21)
- RE: verify HTTPS 'vulnerabilities' Carl (Jul 22)
- RE: verify HTTPS 'vulnerabilities' Todd Towles (Jul 26)