Due: Thursday, May 17
A web server requires each user to log in. However, the implementers of the web site are worried about storing passwords on the server, since they are afraid someone might break in and steal them. Therefore, they decide to use a clever idea. When a user creates an account, the account number is stored on the server and the user's password is stored in a cookie on the user's machine. Then, when the user tries to log in later, the server compares the password typed in by the user with the password stored in the user's cookie.
<HTML> <BODY> --- Headers --- <DIV ID="msg"> --- Verbatim Email Message --- </DIV> </BODY> </HTML>
Suppose a spammer sends spam email from IP address a.b.c.d. This IP address is quickly added to a blacklist and mail servers ignore all emails from this IP address.
Recall that SMTP is an interactive protocol. An SMTP transcript looks as follows:
Sender: MAIL FROM: <firstname.lastname@example.org> Mail Serv: 250 Ok Sender: RCPT TO: <email@example.com> Mail Serv: 250 Ok Sender: DATA Mail Serv: 354 End data with
. Sender: Some message data Second line . Mail Serv: 250 Ok ... and the message is delivered.
You may assume that the SMTP PIPELINING extension is allowed by the mail server.
In class we discussed an authentication method called challenge-response for authenticating a user to a server. At a high level, the basic mechanism works as follows:
Browser Server ------- I am user Alice ------ ------------------> pwd Nonce N pwd <----------------- MAC(pwd, N) ------------------> check MACThe following questions ask whether various attackers can impersonate the user and login to the server on behalf of the user.
Kb = (pwd) || (client-ssl-session-key)where || denotes concatination and client-ssl-session-key is the SSL session key currently used by the browser. The server checks the MAC using the following key:
Ks = (pwd) || (server-ssl-session-key)where server-ssl-session-key is the SSL session key currently used by the server. Is the resulting protocol vulnerable to your attacks from part (b)? If so explain how; if not explain why not.
Consider a company, example.com, with the following network topology:
To enforce the policy, the administrators set up a single machine, gatekeeper.example.com, that can talk both to internal company machines and to the rest of the Internet. Employees can log into gatekeeper from internal machines using SSH and their hardware authentication device. From gatekeeper, they can SSH to the rest of the Internet. All other machines at the company are on a separate subnet (188.8.131.52/24) and can exchange packets with gatekeeper but not with the outside world. Machines on the outside Internet should not be able to SSH to gatekeeper.
Describe how to enforce this policy with stateless packet filtering on Router A and/or Router B. Describe the precise packet filtering rules you would put in place at each router. You may assume that the routers only forward IPv4 traffic.
After several days of this new policy, employees become annoyed that many applications seem to lock up for periods of a minute or so. People suspect that the problem is caused by attempts to create TCP connections to the outside world, which instead of failing instantly take approximately one minute. After all, clients' TCP implementations treat packets dropped by the firewall policy just the same as packets dropped because of congestion--they back off and keep trying.
To solve the problem, the administrators re-configure their routers not just to drop packets silently, but in certain cases to send packets back to the source of a dropped packet. Describe precisely what the routers can send back to make prohibited outgoing TCP connections fail quickly. (Assume they cannot make any changes to the TCP implementation on clients.)
After the fix from the previous part, things improve somewhat, but applications are still locking up. It is determined that the problem is DNS lookups to the outside world, which are also taking a long time to fail. To solve the problem, the administrators run a caching resolver on gatekeeper, and configure all the internal clients to use gatekeeper as their DNS nameserver. The administrators figure that since DNS is a read-only protocol, it is safe to allow internal machines to query for IP addresses of hosts anywhere on the Internet, as long as any actual communication to those IP addresses is blocked by the routers.
Where is the flaw in the administrators' logic? Explain how a clever Trojan horse with access to the secret source code on client.example.com can collude with another machine on the Internet to leak the source code, even without access to the hardware authentication device.