Analyze the backdoor program and decrypt the whole backdoor session from the tcpdump file.
HKD$300 Data Bank book couple and a certificate will be presented to the winner. In return, the winner will give a brief presentation of how he/she decrypt the session.
Submission deadline: No deadline
Submit your work to shlam@ie.cuhk.edu.hk
Before we solve this problem, let’s review the ssh 1 protocol:
1. SSH server sends its host key and server key (which changes every hour) to client. The cline compares the received host key against its own database of know host keys.
2. SSH server normally accepts the keys of an unknown host and store in its database of future reference.
3. The client generates a 256 bit random number as the session key and then encrypts this session key using both the host key and the server key, and sends the encrypted key to the server. The purpose of the host key is to bind the connection to the desired server host (only the server can decrypt the encrypted session key). The hourly changed second key, the server key, is used to make decrypting recorded historic traffic impossible in the event that the host key becomes compromised and it is never saved on disk. The host key is normally a 1024 bit RSA key, and the server key is 768 bits.
4. The server decrypts the RSA encryption and recovers the session key. Both parties start using the session key and the connection is now encrypted.
For more information of the ssh 1 protocol spec, please see
http://www.snailbook.com/docs/protocol-1.5.txt
Now the challenge is:
We have the full ssh session tcpdump file and the ssh host key but we do not have the ssh server key (unless we have core dump the ssh daemon at that time as the ssh server key changes hourly and is never saved on disk). In order to recover the session key for the ssh session decryption, we need to recover the 768-bit server key first. It seems that the only way to recover the server key is to apply brute-force attack on the 768-bit server key.