Today I met with my supervisor (Dr. Stephen Blott) to discuss the various approaches and possible challenges and to firm up the types of experiments I’d like to conduct as part of this project.
Originally I wanted to set up the phone within DCU as it would provide a larger eco-system as there is a larger user base on the wireless network to record both internal and external network attacks. However, at the moment most students have finished exams and the campus is pretty abandoned with the exception of (foreign) students over to during the summer. I had several concerns with DCU assigning me a static address (to keep consistency i.e. if people return to the honeypot), internal restrictions on the network to other machines (filters) and external access over port 22. Blott suggested speaking with Gary Conway and Information System Services (ISS) to see what is available to me. This lead to development of 3 experiments; 1. Internal Attacks 2. External Attacks and 3. attacks on a home broadband line. I have a static address on my home line which I can utilise for this project.
Approaches to the project were limited due to the device itself and the project spec. Normally, a device has ample space and processing power which is not the cause with the iPhone. This restricts me from setting up Virtualised machines or jailed environments (jail is not part of the base iPhone OS) nor would it be possible to port it over due to time restrictions from an opensource system such as FreeBSD – the architectures have changed too much. This leaves me with two options; Bridged Setup and Local Client.
The bridge set up would be ideal however it removes the need to write a larger amount of code for the device to collect data. The bridge basically works by forwarding all traffic destined towards the iPhone through another system which records all the packet data. This machine is invisible and basically just forwards the data onto along the routed path over the network. However, as I’m hoping to leave the SSH service open, most traffic will be encrypted. This does require either a hacked version of SSH to copy all keystroke data and a method to covertly send the data over the network to a central logging server. It was suggested to do this using UDP and syslog-ng.
The local client idea would remove the necessity of additional network equipment (to set up the bridge) however this approach worries me. Without the ability to set up a jailed environment, once someone logs onto the iPhone device it can no longer be trusted as it has been compromised. If the data is being stored on the device and collected later or sent over the network via syslog, the attacker can easily modify the packets or inject their own to mess up the results. Additionally, nothing is stopping the user from performing a ‘rm -rf /’ trashing the entire device.
The approach decided upon is the use of both methods. A simple login service which records keystrokes and sends them (in real-time) over the network via syslog-ng to a central logging server and the use of the bridge network to collect any additional information focused towards the iPhone. The packeted recorded on the bridge can also be used in a comparative analysis to ensure data which reaches the iphone has actually come through the bridge first. This will remove some false-positives if the attacker attempts to inject their own packets or modify others in transit. Additionally, if the attacker does destroy the contents on the file system, an image will be created which can be blasted onto the device leaving it ready to collect data. This will allow for fast restoration if anything is to go wrong. All additional tools (i.e. tcpdump) will be removed from the phone including the ability to install packages (i.e. dpkg).
In relation to the deadline, 8 weeks is very limited. I have decided to focus on getting *something* up and running to conduct a pilot test over a 24 hour period before firming up the amount of time required for testing and writing. In the meantime the rough times are as follows; Development: 3 weeks, Deployment: – Pilot Test (1 Day), Data Collection (1-2 Weeks) – this includes the 3 experiments detailed above and Write Up/Analysis: remainder of time. I will do up a draft Gnatt Chart this evening detailing this and adjust as necessary after the pilot test has been completed.
iPhone Honeypot Project 