- Spying on FlexiSPY
- Security Vulnerabilities in FlexiSPY
- Injecting Spoofed Content into the Backend
- FlexiSPY Ass-u-mes Log Files Integrity
The FlexiSPY product also suffers from an issue that many other web-enabled applications deal with — a vulnerable backend. As we previously mentioned, the FlexiSPY program posts the logged data to a web server so the phone's "owner" can remotely monitor what the target is up to. This lends itself to one major issue — the spying party must trust the content they are viewing on the website.
But what if that content could be spoofed? If someone could inject false content into the logs, the entire system is in question. Not only is the integrity of the system at stake but false logs could also lead to many undesired consequences, both legal and personal.
So, how is this possible? It all comes down to the simple fact that there are no authentication requirements needed to post a log file other than knowing the IMEI (serial number) of the cell phone, which can be easily obtained from the target's cell phone.
Once you have this, a spoofed HTTP POST can be created to inject phone call logs, SMS logs, and email logs directly to FlexiSPY's server. The following outlines the details to make such a post.
First a header must be created:
POST /service HTTP/1.1 Accept: */* Content-Type: application/octet-stream User-Agent: CeHttp Host: mobile.flexispy.com Cache-Control: no-cache Content-Length: 182
Next come a few bytes that can be static:
00 27 01 00
This is followed by the IMEI number:
123456789012345 (not a real IMEI number)
Then a string of null bytes 38 bytes long, which is followed by a log type (we believe) and the number of entries.
01 00 00 00 02 00 00 00
At this point, we are at the beginning of the actual message.
The first byte is the log entry number. Next an identifier field is specified (0x01 for date/time), which is followed by the length of this field. After this the actual date/time are included in the file.
Then comes an unknown byte (0x01), followed by three more null bytes. After this the second part of the message is included, which includes another identifier field (0x08), its length, and the content. The content could be a phone number or text referencing a contacts name in the targets phone book.
This is followed with several more null bytes, thus finalizing the message.
01 00 00 00 08 00 0a 37 31 37 35 35 35 31 32 31 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Altogether we end up with something like the following (as created in Burp; see Figure 1). And as Figure 2 illustrates, text can also be entered.
Figure 1 Burp Injection/p>
Figure 2 Spoofed logs/p>