CSE509 Spring 2006. Computer Security. Project

CSE509 Spring 2006. Computer Security

Project

Note: If you would like to do a different class project, feel free to come discuss you project ideas with me.

Phase I: A Secure File Server

Write a secure remote file server that supports the following protocol:

where:

Each message in the protocol is terminated by the C characters "\r\n".
USERNAME is an ASCII string.
N, e, C, R, and y are represented as integers in ASCII in base 16 during transmission.
K is transmitted as a hex dump of its bytes, i.e. convert each byte into two hex characters and transmit them.
N and e are represented as integers in ASCII in base 16 in the user's config file, .sfs.
K is represented as a hex dump in the user's .sfs file
The encrypted file is tansferred as raw bytes.
The ", " are literals in the protocol
PASSWD is an ASCII string up to 16 bytes.
PASSWD is padded to 16 bytes by appending 0 bytes when used as a key in AES.
d is represented as an integer in ASCII in base 16 during encryption via AES-CBC.
d is padded to a multiple of 16 bytes by prepending ASCII "0"s
C is represented as an integer in ASCII in base 16 during computation of message R.
FILENAME is a string, up to 240 bytes, in ASCII, excluding the terminating NULL character, in the computation of message R.
The "(", ", ", and ")" are literals in the computation of message R
Whenever the bytes of an ASCII string are re-interpreted as an integer, use big-endian byte order.
S is generated randomly for each request
S is represented as an integer in ASCII in base 16 during computation of message y, without the terminating NULL character.
The server uses PKCS5 padding when encrypting the file using AES/CBC.
The server closes the connection after sending the last byte of Z.
The server listens for connection requests on port 5096.

Example

Suppose (small values are used for convenience, values are not guaranteed to be correct or even make sense)

USERNAME = "rob"
N = 41436197399383046674769
e = 31142868322202020882931
K = 1234567890123456 = AES-CBC("hehe\0\0\0\0\0\0\0\0\0\0\0\0", "26841096087855436504571")
d = 26841096087855436504571
C = 0123456789012345
R = 56789123
PASSWD = "hehe"
FILENAME = "foo/bar"
S = 4235546

Client -> Server "rob\r\n"
Server -> Client "41436197399383046674769, 31142868322202020882931, 1234567890123456, 0123456789012345\r\n"
Client computes m = AES-CBC^-1("hehe\0\0\0\0\0\0\0\0\0\0\0\0", 1234567890123456)
(if things worked, then m = "26841096087855436504571")
d = (parse m to get integer)
t = "(0123456789012345, foo/bar)"
x = (interpret bytes of t as an integer, big-endian)
R = x^d mod N
Client -> Server "56789123\r\n"
Server performs similar computation
Server computes S = random(128-bits)
t = "4235546"
x = (interpret bytes of t as an integer, big-endian)
y = x^e mod N
Z = AES-CBC(S, FILE)
Server -> Client "y, Z"

You may work in teams of 2. You must not share code or ideas with other teams. You are encouraged to test your programs with programs written by other teams to check that you adhere to the specification (i.e. you can test whether your client can work with another team's server and vice-versa). You should implement 3 programs:

Server
Client
K-generator

The K-generator program should take as input a file containing N, e, and d, and a password read from the user, and generate a .sfs file. K-generator does not need to generate N,e,d triples. As a test input, you may use (N, e, d, one per line):

f669601b3ea0491a3d46c47c9cc7604a3ba39d42b99f9bf0c5b8da261bb01e1ff2c1c0708fb65ee71517e94a37de8087e3471cb669e17bf3d2a88e65a5ffa220591b29bdc6104ddf7ba0715ec2cd631d254d3938e0ea6b5655dfe942034d7731941dbfba7c50ebfbadbd0ea28f67cb867d4ab6f7ffc911a29ec9e86588b409fd404345230a594235393135871e04ed6b060cc02a25b826c53a1699f25da9f7babfe5aa0bdd78a3e6c7a4b293ca7057ea152f81c6d2fc0b222939c145fc1c87cfc865c3693e7eb8a91664bf3000b109339da732808f87cfe3bf4946bcc55bb2e5055ac88bb187ff161a4de89cad8dcaf71d5e82309ec8b5a4cca117c3eec7493
b54e844d004bf9da4c355eda6892ed35c68ebae79e95e2d99db74c2dd0b76c4636c00c0f234fd7d1565c42ca745904be44cb3b50dfa2f691b23cb76102a52a255a84237c00a0a8af697e8aa846b6dc319e4f4b060f8923a430278929a7a52690720c649f7161e94f368feb7da8a1a0def400ced7e75c4705a894d64868d6ee827e4214530e7bd6a32e9ada3623373f7126f06bccdffcfdba6c8073d7af1acf1a403137ce30eb6dd582a08bdeff6e651ed82986f13268a4b68cf4f6dba361d52a38e893e5f1b26bd823a8f56746367eda68924546d7c958fddaebb4322eedcdc8a959adbd29d74da4c2b2cbefc097b991f94b8bc588f5f783e74cc102fa7145f
ec4b669a69a01a47ea445aaa9c4449769413ef8b4121ad327e96cdcc4364762697d9f2eb0119af1e29b6169817f26eb9fe3a59d1a650365027c40e522847bde4607b6d1d8731a79af5dfcf30b2a763eec740374e83aefee17352c763f09696aba6d5a787ae04b5f4746f47112730c1c82edec636da1d9be9e8228b70d53ecd94cc7384be2f36581dfa3c69ddf937d4548e4e66a6f4ac26579b2be030b2b16ca4dcb50b977be5affa9f411865ed5f2debc85d5c40273c1a63e12d6e13fac498148cba3071409227bfb7b3898b08f46f5b95e839358a3a55e826d7e637b68babfd8d8a938ad3aaeca66a0deea7afda37de79a6d36c967025dbc6063e5a832c4df

You do not need to implement AES, or CBC mode of AES. You do not need to implement modular multiplication, but you should implement your own modular exponentiation. You are encouraged to use existing libraries for AES, CBC mode, and basic modular arithmetic of big integers (see Java BigInt class or the GNU MP Bignum library). For testing purposes, your code should run on the departmental machine minix.cs.sunysb.edu.

You should also write a 1-page description of the security goals this server should maintain.

Phase II

Your team will be given the servers written by 2 other teams. Find as many security bugs as you can in their implementation. Security bugs are not limited to simple programming bugs like buffer overflows. Any attack you can develop that violates a security goal of the server and that the server could be modified to prevent is acceptable.

You should analyze each project for all the relevant security bugs you can find. Note that there are bugs in the above protocol, and you may write up a description of those bugs as a seperate report. However, don't include protocol bugs in your report on the implementation. You should look for things like buffer overflows, format string bugs, timing attacks, etc. For each bug you find, please include a 1 paragraph description. Your description should include:

The location of the bug in the source code (e.g. "server.c:1024")
The nature of the bug (e.g. "stack overflow")
An explanation for why you think it is exploitable (e.g. "The source of the strcpy is the filename provided by the user.")
A description of input that could trigger the bug (e.g. "The attacker can send a long filename with embedded shell-code.")
Any prerequisites for exploiting the bug (e.g. "The attacker must have a valid account on the victim machine in order to get the filename decrypted correctly by the server.")
The security goal that can be violated using this bug (e.g. "The attacker can gain root access on the server.")

If you find several similar bugs in a project, then you can combine those into one paragraph. Describe one of the bugs as above, and add a comment indicating that you think the rest are similar. If you can't find any security holes in a project, then write a 1/2-1 page report on your methodology for analyzing the project and your conclusions about its security.

Deadlines

4/4: Project status meeting
4/18: Server, client, and K-generator due
5/4: Code Analyses due