- Hijacking the Binary
- Injecting Fraudulent Activity
- Unveiling the Untrusting
- Summary of Parts 1 and 2
Injecting Fraudulent Activity
While we were analyzing the log posting process, we noticed that the interaction between the client and the server was via unencrypted HTTP requests. As we previously mentioned, this alone presents a security threat that could expose the account information. However, we also noticed that there was little in the way of session management. To illustrate, let's recap how the program works:
- Send HTTP GET request to server that includes the username and password of the account owner.
- Receive a session ID value, which is the same as the login ID.
- Send HTTP POST request to server that includes the login ID and the log contents.
- Receive a success/fail message.
What we didn't tell you is that the session ID you receive after a successful login is a numerical value that is assigned to your account. In addition, these session IDs are created incrementally. For example, we created an account on one day and received a sID value in the 900s. The next day we created a new account and got a value in the 1000s.
So, what would happen if we simply created a web form that we could enter any session ID along with a field for any URL and sent that data to mobile-spy.com (Figure 1)?
Figure 1 Spoofing a URL log posting to a random account
We shall let the results speak for themselves in Figure 2.
Figure 2 Results of spoofed injection
Now just imagine the consequences of someone creating a script that iterates through account numbers 500-2000 and posts spoofed URL, SMS, or phone records. A malicious person could create all sorts of confusion and chaos.
Obviously, mobile-spy.com holds some accountability to the security of their system. The customer is placing a lot of trust in mobile-spy.com that the results they see in the web application are actual logs from the targets phone. By allowing spoofed content into the database, the integrity of all the captured logs is called into question.