On 06/03/10 14:41 +0100, Hartmut Goebel wrote: > Hi, > > below please find is an analysis about deficits in the current > implementation of pysocket SSL. pysocket is vulnerable to the following > attacks: > > 1) Spoofing of server address > 2) Intercepting an existing, encrypted connection > 3) Silently switching from SSL to non-SSL > 4) Very first connection vulnerable to spoofing > 5) Conclusion and solution > > This analysis is based on codereview for issue223066, patchset 2. > > > 1) Spoofing of server even if server uses SSL > ---------------------------------------------------- > > If an attacker spoofs the server address and does not offer SSL > communication, the client will simply talk unencrypted to the > attacker's server. Since SSL is not used, the identity of the server > can not be checked be the client. > > Reason: The client leaves the decision, whether SSL is to be used, to > the server. > > Rationale: Following the control flow in pysocket.py shows: The client > opens a connection to the server. Then it tries to open a SSL > connection. If this fails, the client will not use SSL, thus will not > check the servers identity. > > Vulnerable: fingerprint, certificates
fingerprint implementation prevents this. > > Solution: The client has to decide whether he wants to use SSL. > > > 2) Intercepting an existing, encrypted connection > --------------------------------------------------------- > > An attacker may intercept an existing, encrypted connection by simply > spoofing the server address. Spoofing the address will break the > connection, but the client will reestablish it while talking to the > attacker's server. If the attacker's server is not offering SSL, the > client does not check the servers identity (see above) and talk to the > attacker's server. > > Reason: The client falls back to non-SSL even if the connection has > been established as SSL earlier. > > Rationale: Following the control flow in netrpc.py and pysocket.py > shows: If the SSL connection is broken, the client tries to > reestablish it (which is a good thing). Now talking to the attacker's > server, which does not offer SSL, the identity of the server is not > checked (see above). > > Vulnerable: fingerprint, certificates fingerprint implementation prevents this. > > Solution: The client has to remember whether the connection uses SSL > at least until the user logs out and must not fall back to non-SSL. > > > 3) Silently switching from SSL to non-SSL > -------------------------------------------- > > If the server is offering SSL but then restarted with SSL set to off, > the client silently switches from SSL to non-SSL. In this case > > a) the user does not get any notification about the change. Only the > "Lock" icon in the lower right corner of the main window will > vanish. But this is overlooked very easy (as experiences from > web-browsers show). > > b) data is transmitted anyway. > > Reason: see 2) > > Rationale: Following the control flow in netrpc.py and pysocket.py > shows: If the SSL connection is broken, the client tries to > reestablish it. Now the server does not offer SSL anymore, the client > uses non-SSL connection. Then the data is sent without notifying the > user about of the change. *After* the data has been sent and the > result has been received, the "lock" icon is removed. > > One may argue, if the real server is switching from SSL to non-SSL, > this requires admin interaction and thus should be okay. But if SSL > connection has been configured first, there is barely no reason to > switch to non-SSL -- especially within working hours. Thus if this > switch occurs, it is a big, big sign that something nasty is going on. > This may be as simple as a server configuration error. But > nevertheless: With a chance o 1:100000 something happened that should > not happen. > > Vulnerable: fingerprint, certificates fingerprint implementation prevents this. > > Solution: Notifying the user (e.g. showing some warning requester) is > not a solution, since the user will simply click "okay" (since he > wants to do his job, as experience shows). So: The client has to > remember whether the connection uses SSL at least until the user logs > out and must not fall back to non-SSL. > > > 4) Very first connection vulnerable to spoofing > ----------------------------------------------------- > > When the client is talking to a server the very first time, this > servers fingerprint is saved for further connections. If at this > moment the client is talking to spoofed server, the spoofed server's > fingerprint is saved. So nobody recognises that the client is talking > to the attacker's server from the very beginning. > > Reason: The client silently saves the fingerprint for new connections > without either checking the identity of the server nor requesting the > user to conform the fingerprint. NB: SSH by default asks the user. > > Rationale: Following the control flow in netrpc.py, pysocket.py and > fingerprint.py shows: For a new host, the fingerprint is saved > silently. > > Vulnerable: fingerprint > > Solution: Add new host keys will be added to the user known host files > only after the user has confirmed that is what they really want to do. > Alternatively find another way to check the server identity. That is true. I think that poping-up an accept button will not fix the issue because users will click ok anyway. For IT guys that want to enforce this can provide a know_hosts file or ca-cert file when installing the Tryton client. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpK2d45lxY6g.pgp
Description: PGP signature
