ITSE exercise session 5: Design Problems

Transcription

1 ITSE exercise session 5: Design Problems Exercise 1 Design Foobar Inc. is a company selling a high security Instant Messaging application for enterprises. All communications go through a secure server and are encrypted with SSL. The application uses X.509 certificates to authenticate its users. For licensing reasons, the customers (users and servers) are not allowed to use their own PKI. At the root of the PKI is the certificate of Foobar Inc. (let's call it foobar-root.pem). This certificate is hard-coded into the application software (client and server). The corresponding private key (foobar-root.key) is known by Foobar only. When a customer, ACME SA, want to install the solution, they generate two certificates: one for their server (acme-srv.pem), and an intermediate authority for creating users (acmeadmin.pem). They then send both certificates to Foobar, who signs them with foobarroot.pem. (Foobar Inc. will only do so if the license fees have been paid). The server software, as well as the user management software, will only run if these certificates have a proper signature from foobar-root.pem. To create a new user, the client s software generates a certificate for the user (for instance, acme-user01.pem). The administrator uses the user management software to sign acmeuser01.pem with acme-admin.pem. The client software is configured by the administrator to connect to the right server. When a client connects to the server, the server checks that the user certificate has been signed by acme-admin, and if so, accepts the identity of the client certificate as a valid user ID. The client only checks that the server certificate has been signed by foobar-root. Then, the server and the client can communicate over an encrypted channel. Questions 1. Find the flaw in this PKI mechanism (a trust link is missing). Hint: what happens when Foobar sells the solution to more than one customer? 2. The flaw is not exploitable par an attacker, as long as all the customers trust Foobar to behave honestly, and as long as the client software follows an additional policy. What is this policy? 3. Find another way to fix the flaw that does not require applying such a policy. Hint: you need to change the trust relationships between the various certificates. Why would this be better than the policy approach?

2 Exercise 1 Solutions 1. The client software verifies that the server certificate is signed by foobar-root.pem, but that does not prove that the server is the correct one; if Foobar has several customers, one customer could attack another and redirect their clients to its own server, the server could accept the client certificates, the clients would see a server certificate signed by foobar-root.pem, but they still connect to a malicious server. 2. If Foobar checks the identities (CNs) of the server certificates it signs, and if the client software checks that the server certificate name matches the connected host (as done by SSL, for instance), then the flaw cannot be exploited. However, the customers must then set the server name in stone and have foobar-root resign the certificate if that ever changes. In addition, the customer is then obligated to reveal the server name to Foobar, which may raise a privacy concern. 3. This can also be addressed by using an intermediate authority per customer, that will be signed by foobar-root, and signs the server certificates. The client then needs to check that the server certificate has been signed by this intermediate authority; this fixes the flaw without the privacy concerns of the previous solution. Another possibility is also to provide the server certificate directly to the client software (which is then harder to change than with an intermediate authority, but easier than having Foobar sign a new certificate).

3 Exercise 2 Design VerySecureSoftware Inc. (a competitor of Foobar Inc.) has come up with a concurrent solution for secure messaging. They are more geared towards classical messaging ( ) than instant messaging. VSI software is free to download, either as a standalone executable or as a Java applet. When the user first starts it, the software asks for an address and a passphrase. The software then generates a new PGP keypair, using the passphrase to encrypt the private key, and uploads both the public key and the encrypted private key to a central server. The server also stores the sha256 hash of the passphrase for authentication. When the user wants to login, he provides the address and the passphrase to the software. The client software authenticates to the server by sending the hash of the passphrase (the server then compares it directly with the stored hash), then downloads the encrypted private key and uses the passphrase to decrypt it. Once logged in, the client software can send encrypted messages to other users, by fetching their public keys from the server, and sending PGP-encrypted messages to the server, where they are stored in the user's inbox. Message encryption and decryption happen on the client, and the encrypted messages are shown to the user before sending, so that the user can verify that the messages are indeed encrypted. Whenever a new encrypted messages arrives to the inbox, the server sends a notification to the corresponding address, with a link to the application login page, so that the user can login and check the message. All communications with the server happen over HTTPS, with a properly signed certificate, using an SQL-over-HTTP bridge (the client software can issue SQL requests that are transformed into HTTP POST requests, and the results are sent back in JSON format). In order to avoid problems, SQL requests go through a simple filter; for instance, queries that do not contain the WHERE clause are forbidden. Questions 1. Why do you think the private key is stored on the server? Is this goal consistent with the security they are trying to achieve? 2. Assuming current crypto algorithms (AES, SHA256, DH, Elgamal) are not broken, and key sizes are appropriate. Is this application more secure than an SSL-based webmail? 3. What if, instead of using the passphrase to encrypt the PGP key, they used the sha256 hash of the passphrase? 4. What if, instead of sending the hash of the passphrase, they sent the passphrase in clear?

4 5. PGP encrypts its private keys by taking the passphrase, iterating a hash function over it 2 16 times, then using the result as a cipher key. The repeated iteration is here to make the brute force more expensive. Assuming that you can get the encrypted private key, you have a way to test if the decryption succeeded, and can hope to brute force the passphrase. Within this application, is the repeated iteration effective or not? Why? 6. Which core security engineering principle is violated by their SQL request filtering? Can you find a trivial way around it?

5 Exercise 2 Solutions 1. This is most likely to bring location independence: you can login from anywhere and access your secure mailbox, without having to install or configure the application. Arguably, there is little point to using PGP encryption if you allow users to connect from untrusted machines that may very well run keyloggers or screen capture programs. 2. If an attacker can break SSL (either through forged certificates, or PEBKAC failure to understand certificate validation), OR break into the server, he can fully break the SSL webmail. With this scheme, the attacker will only get the hash of the passphrase, and needs to break it to get access to the encrypted messages. But he can still use the hash as-is to authenticate, and do operations not requiring the private key (sending s, deleting received s...). 3. Then the security would be equivalent to that of SSL, since the attacker, by intercepting the hash, would also be able to get and decrypt the private key, and decrypt the messages, even though the passphrase is not known; and someone breaking into the server would have access to all the hashes, all the private keys, and thus all the messages. 4. Then someone breaking into the server would not be able to decrypt the private keys of all the users, since the server only stores the hash. However, with a MITM attack, the attacker would be able to recover the cleartext passphrase and subsequently decrypt the messages, so this scheme is worse than the original. 5. No, it is not effective. It can also be completely broken if the iteration was using the same hash as the authentication (fortunately this is not the case). Its purpose is to slow down brute force, as the high number of hash iterations takes time. But if the attacker can get the encrypted private key (either by MITM or by a server break-in) he already knows the passphrase sha256 hash, and can use this to brute force the passphrase without doing the iteration. 6. Fail-safeness is violated since the filtering relies on a forbidding bad requests; if the filter fails to identify a bad request, the failure is unsafe (You could also say it violates Least Privilege, if you consider the filtering errors to be a default in the policy rather than in the code). In this case, the filter is especially ineffective; a simple WHERE 1=1 is enough to fool this filter.