Yes, that’s right! Mr. Upset did not post ‘I am hating my new job’ as it appears in Figure 2, instead he wrote ‘I am loving my new job’. Then how did it happen and who did it? This article aims at addressing these questions. We fabricate a case where a person is an object of a Man In the Middle Attack and subsequently analyze victim’s device to corroborate the facts and trace the perpetrator. The paper is divided into two sections. Section 1 demonstrates how did the attacker tamper the original message posted on LinkedIn by using Man In The Middle (MITM) attack. In section 2, we will dissect the forensic side of it to determine if Mr. Upset (victim) is making a reasonable claim.
1 Section I – MITM Attack
It is assumed that Mr. Upset’s mobile device i.e. iPod touch is already compromised by the bad guy which involves installation of malicious certificate or profile (Figure 3) and changing the proxy settings on the device (Figure 4). By modifying the proxy setting, the victim’s device is prepared to direct the IP traffic towards the attacker. With the Charles proxy tool (acting as a proxy server), bad guy is able to capture and monitor IP packets coming to and from Mr. Upset’s device. The Charles SSL CA certificate is assumed to be already added into the list of trusted root certificates on the victim’s iPod that will help the attacker to decrypt the encrypted SSL packets.
Given below is the detail of the steps that attacker follows to intercept the LinkedIn communication and alter the original message using Charles proxy tool.
1- The bad guy launches Charles proxy tool and starts eavesdropping and noticing victim’s activity. He observes LinkedIn URL touch.www.linkedin.com in the host column illustrated in Figure 5. This leads him to believe that victim is using LinkedIn application.
2- He adds that LinkedIn URL into SSL list under SSL tab in the Proxy Settings, refer to Figure 6 and Figure 7. Note that the port number 443 is entered for https traffic.
3- Next, he applies the break point on POST (Proxy -> Breakpoints). Notice that scheme is POST, protocol is https and host is touch.www.linkedin.com. Since he is interested in holding request packets, therefore he selected Request type, as shown in Figure 8. Now, as soon as Mr. Upset posts a message, he is able to hold these packets before they set out to the LinkedIn server, edits them and let them go to the server.
4- Now is the real show time for the bad guy. The breakpoint is active and in the meanwhile Mr. Upset posts a comment ‘I am loving my new job’ on his LinkedIn account as shown in Figure 1. Soon as he hits the Share button, POST request packets are sent to LinkedIn server. But the man in the middle gets to see and modify the packet(s) before it reaches to final destination i.e. LinkedIn server. The attacker tampers the packet by hitting the Edit request from top menu and selects Form display option at the bottom (Figure 9).
He replaces the word loving with hating as depicted by Figure 10.
5- Finally, he removes the breakpoint by tapping the red button at the top and hit Execute. This will let the packets leave the proxy server towards LinkedIn server and complete victim’s POST action.
2 Section II – Forensics
In section 1, we demonstrated a simple MITM attack. What is next? How can one prove that Mr. Upset did not post that message but was interfered. In order to determine this, in this section, we are going to examine the victim’s device i.e. iPod touch.
One can start the investigation of an iOS device by looking at the files listed below.
- TrustStore.sqlite3 [/var/Keychains/TrustStore.sqlite3]
- preferences.plist [/private/var/preferences/SystemConfiguration/preferences.plist]
- dynamic-text.dat [/var/mobile/Library/Keyboard/dynamic-text.dat]
Note that the name and/or location of the file(s) might change with the iOS version number. The given name and paths are validated on iOS 5.1.1 and 6.1.3.
TrustStore.sqlite3 contains profile information. For example in this case, Figure 11 spots the sign of installed Charles SSL certificate. Modified time of this database changes after installing a new certificate, therefore this time could be critical in drawing a timeline especially if the malicious certificate is the last installed certificate.
The preferences.plist file typically stores network preferences. Since we are investigating a MITM attack and after the traces of proxy setting on the device, this file could be our smoking gun. In this case (Figure 12), we observed a proxy server IP 192.168.0.10 which is the potential malicious proxy server address. It is worth noticing that this file saves history of previously configured proxies.
Though dynamic-text records the keystrokes of an iOS user in random fashion, but still some times if you are lucky, you may find complete sentences or words enough to make sense. Thus examining the content of this file is a good idea especially for a given case where we need to know if the user did type hating or loving. Chances are one might find out the exact word in the sentence. When we examined the file we found ‘lovingmynew’ as shown below in Figure 13. This indicates that the user typed ‘lovingmynew’.
2.4 Inquisitive Aspect
Based on the above analysis, few questions that can be addressed are as follows.
2.4.1 Are there any signs of compromise in victim’s device?
Yes, there are signs of malicious activities on the device – un-trusted certificate and proxy setting.
2.4.2 Did Mr. Upset actually post what appears on his LinkedIn account?
More likely, Mr. Upset did not post the word hating.
2.4.3 What is the origin of attack?
In this example scenario, we found the involvement of a proxy server of IP 192.168.0.10. In real world case, this could be a public IP or a private IP leading to remote or an insider attack. Whatever be the case, the next potential step is to trace the IP and proceed with the investigation.
FYI: After the analysis, Mr. Upset is not upset anymore🙂
The article attempts to demonstrate how a posted message can be tampered on the fly using MITM attack and the purpose of this article is to apply forensic techniques on a compromised system and unearth the information.
@NOODLEWERK. (2011, October 19). Noodlewerk blog. Retrieved July 25, 2013, from Tutorial: Using Charles proxy to debug HTTP(S) communication between server and iOS apps: http://blog.noodlewerk.com/general/tutorial-using-charles-proxy-to-debug-https-communication-between-server-and-ios-apps/
Charles. (n.d.). SSL Proxying. Retrieved July 20, 2013, from Charles: http://www.charlesproxy.com/documentation/proxying/ssl-proxying/
mit proxy 0.9. (2013). Retrieved July 21, 2013, from How mitmproxy works: http://mitmproxy.org/doc/howmitmproxy.html