CS 4740 / CS 6740 - Network Security

Project 1: Authentication

This project is due at 11:59pm on February 10, 2015.


In this project, you will execute a multi-stage attack against several network services in order to steal some secret flags. Executing this attack will require cracking user passwords, implementing the Needham-Schroeder key exchange protocol, and avoiding a firewall that is protecting a Database. In the end, you will submit the secret flags you have stolen from the Database (along with the answer to a question given below).

Network Setup

The server guldendraak.ccs.neu.edu is running three services that you will target in this assignment.

As you can see, the three services are all linked. You need a username/password to contact the NS Server, the NS Server grants access to the Token Server, and the Token Server returns authentication tokens that are needed to access the Database.


All three of the services on guldendraak.ccs.neu.edu use the same basic network protocol. All ports are TCP, and all servers expect messages in the following format:

where XXXXXXXX is the zero-prefixed string encoding of the 32-bit length of the message, and msg is the message itself. Messages will either be string encoded JSON objects, or base64 encoded, AES encrypted JSON objects. For example, the following is a valid JSON message:
Alternatively, you may see encrypted messages that look like this:

Step 1: Password Cracking

The first step in this assignment is cracking the passwords for three users of the system outlined above. Fortunately, an insider has leaked the password hashes for three users:

aoun $1$HUSKIES!$v/mh7SBLm8/3SBL6w0Z9M1
curry $1$HUSKIES!$xk2VnxpJYAGOxEl0W8uEP0
ryder $1$HUSKIES!$R9bstTQ9eG2Pzql0cq7kd/
Your task is to recover the corresponding passwords for these accounts using the pre-computed table of hash chains in this file. This JSON file contains the start and end values for each chain, the salt known to be used for these three acounts, and the length \(k\) for each chain. The hash function \(H\) is MD5 (hint: check man 3 crypt), while the reduction \(R\) for a hash value of length \(m\) is \[R(x)=r(x_m)|r(x_{m-1})|...|r(x_{m-7})\] where \[r(x)=(x\mod26)+\unicode{x201C}a\unicode{x201D}\] and " \(|\) " means concatenation. In other words, \(R\) takes the last eight digits of a hash value in reverse, and for each character \(x\) produces the \(x\mod26\) lowercase ASCII letter.

Once you have recovered the passwords for these three users, you can use these username/password combos to access the NS Server.

Step 2: Obtaining Authentication Tokens

The second step in this assignment is obtaining authentication tokens. These tokens are necessary to access the Database.

The Token Server stores a unique token for each user in this system, and it will happily tell you the token for a given user... after you authenticate with the NS Server and perform a Needham-Schroeder key exchange. To begin this process, you will need to send a JSON formatted message to the NS Server with the following information:

    "client_id": [a valid username, e.g. "ryder", as a string],
    "server_id": "token_server",
    "nonce" : [a random nonce, as an integer]
As specified in the Needham-Schroeder protocol, the NS Server will return an AES encrypted JSON response. The encryption key is the given user's password. The following pseudocode is used to encrypt messages on the server-side:
function encrypt(password, msg):
    hashed_pw = SHA(password).substring(0, 32)
    iv = [16 random bytes]
    return base64_encode(iv + AES_encrypt(hashed_pw, AES_MODE_CFB, iv, msg))
To decrypt messages, you will need to reverse these steps. Notice that the data is base64 encoded, the first 16 bytes are the salt, and AES is executed in MODE_CFB. Furthermore, AES requires keys that are a power of two long, so raw passwords (like those recovered in step 1) are first hashed using SHA1, and then the first 32 bytes are used as the encryption key.

Once you have decrypted the message from the NS Server, you will be able to complete the Needham-Schroeder key exchange by directly contacting the Token Server. We omit the remaining details of the key echange protocol; you should be able to figure them out ;)

If you successfully complete the Needham-Schroeder key exchange with the Token Server, it will respond with an authentication token that corresponds to the client_id given in the initial JSON request to the NS Server.

Step 3: Stealing the Secret Flags

The final step in this assignment is to obtain the secret flags from the Database. The Database expects to receive clear-text JSON messages in the following format:

    "command" : "AUTH",
    "client_id" : [a valid username, e.g. "ryder", as a string],
    "token" : [the token associated with the given username, as a string]
The Database will respond to these queries with the secret flag for the given user. However, the Database is running behind a firewall that will drop all packets containing "AUTH" commands. To obtain the secret flags, you will need to figure out a way around the firewall...

What You Need to Turn In

To receive credit on this assignment, you will need to turn in all your code, as well as a file named secrets.json that contains the following JSON formatted data:

    "aoun_secret": [aoun's secret flag, as a string],
    "curry_secret": [curry's secret flag, as a string],
    "ryder_secret": [ryder's secret flag, as a string],
    "table_efficiency": [float]
You can use the following Python commands to test whether your file is valid JSON:
% python
>>> import json
>>> json.loads(open('secrets.json').read())
If you see an exception, then your file is not formatted correctly (or your file couldn't be found).

Question 1: Table Efficiency

The provided hash chain table contains a number of collisions that reduces its theoretical maximum coverage of the password space \(c = n \times k \) where \(n\) is the number of chains. Compute the table's actual coverage of the password space \(c'\) and its efficiency \(\frac{c'}{c}\). Put this number in your secrets.json file.

Language and Libraries

You can write your code in whatever language you choose, as long as your code compiles and runs on unmodified CCIS Linux machines on the command line. Do not use libraries that are not installed by default on the CCIS Linux machines. Similarly, your code must compile and run on the command line. You may use IDEs (e.g. Eclipse) during development, but do not turn in your IDE project without a Makefile. Make sure you code has no dependencies on your IDE.

You may use whatever libraries you wish in this project, provided they are on the CCIS Linux machines. This includes libraries for base64 encoding/decoding, any necessary encryption routines, cryptographic hashing, etc.

Submitting Your Project

If you have not done so already, register yourself for our grading system using the following command:

$ /course/cs6740sp15/bin/register-student [NUID]
NUID is your Northeastern ID number, including any leading zeroes.

Before turning in your project, you and your partner(s) must register your group. To register yourself in a group, execute the following script:

$ /course/cs6740sp15/bin/register project1 [team name]
This will either report back success or will give you an error message. If you have trouble registering, please contact the course staff. You and your partner(s) must all run this script with the same [team name]. This is how we know you are part of the same group.

To turn-in your project, you must submit your code along with a file named secrets.json that contains the secrets obtained from the Database, as well as the answer to Question 1 given above. Your secrets.json file and source code should all be placed in a directory. You submit your project by running the turn-in script as follows:

$ /course/cs6740sp15/bin/turnin project1 [project directory]
[project directory] is the name of the directory with your submission. The script will print out every file that you are submitting, so make sure that it prints out all of the files you wish to submit! The turn-in script will not accept submissions that are missing the secrets.json file. Only one group member needs to submit your project. Your group may submit as many times as you wish; only the last submission will be graded, and the time of the last submission will determine whether your assignment is late.


This project is worth 13 points. If you submit the corrects secret flags and the answer to Question 1 then you will receive full credit. We will randomly check student's code to make sure that it works correctly. All student code will be scanned by plagarism detection software to ensure that students are not copying code from the Internet or each other. Students who are caught cheating will receive a zero on the assignment, and will be reported to OSCCR.

Is This Protocol Realistic?

Astute students may question whether the system described in this assignment is realistic or secure. The answer is that no real system should be build this way. First off, Needham-Schroeder is known to be vulnerable to replay attacks, and should not be used in practice. Second, the Token Server returns tokens via an encrypted, secure channel (which is good), but then you must send the token in-the-clear to the Database, which negates the benefits of using an encrypted distribution channel. Ideally, interactions with the Database should also occur over an encrypted, authenticated channel, just like interactions with the Token Server. We are purposely using a less secure setup in this assignment because the firewall that is guarding the Database cannot analyze encrypted packets.