Penetration Testing mailing list archives
RE: verify HTTPS 'vulnerabilities'
From: Omar Herrera <oherrera () prodigy net mx>
Date: Thu, 21 Jul 2005 19:13:29 -0500
Hi Dan, According to SSL protocol, the client is the one that tells the server first the cipher-suite that it supports (in order of preference), from that list, the Server chooses the suite to be used (as long as one of them is also supported by the server). Therefore, you need to specifically propose to the server a list of weak cipher suite combinations, which is what the Nessus script is probably doing (a successful connection with a list that contains only weak cipher suites would mean that the server is "vulnerable"). A tool like Stunnel (client mode) should be helpful to establish this kind of connection manually. Just specify a list of weak cipher suites; check the RFCs for information on these. Also, remember that the server's only sin here is to accept weak encryption algorithms proposed by clients; a badly configured client (or one that has only support for weak ciphers, which should be pretty old in my opinion), needs to be used here for the vulnerability to be exploitable (during the time of the connection). Also take a look at the source code of the Nessus script reporting this vulnerability to understand more clearly how it is being tested. The basic authentication thing also looks interesting. I know many use SSL to compensate basic authentication encoding (BA simply sends user:password B64 encoded, not encrypted), but this allows for MITM attacks to be used (Even if only strong cipher-suites were allowed by the server, it looks like MITM would still be possible using BA). Not to diminish the importance of weak encryption support on the server, but with current phishing schemes, a MITM attack looks more critical and likely. Check if a recommendation on this matter applies to your client (it will depend on the purpose and visibility of the server). Since they already use user/password authentication, it would seem that client authentication configured on the server, using digital certificates, would be a much better option to secure access. I hope this helps. Regards, Omar Herrera
-----Original Message----- From: Dan Rogers 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)?
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)