User Interface Spoofing and Its Impact on Security
As you may have seen in James O’Connor’s paper, Attack Surface Analysis of Blackberry Devices, there is a bug/vulnerability in Blackberry devices that allows an attacker to spoof the interface that shows a .jad file's signing properties. A .jad file is a Java package format that is frequently used to distribute applications for mobile phones. This spoofing allows an attacker to make a .jad application appear to be signed by a legitimate user or company. The attacker accomplishes this by using a carefully constructed file with the appropriate amount of spaces within certain strings.
Because the susceptibility to this class of attacks is not unique to the BlackBerry or to .jad files, I thought it might make an interesting blog entry. I originally found something like this with .jad files back in 2005 on the Windows Mobile platform with a commonly shipped third-party J2ME implementation. Others have found similar issues in other applications; for example, in Bluetooth implementations. Also, I recently found a similar issue in the file transfer mechanism of an application.
The core problem stems from the fact that user interface designers and security people don't typically sit next to each other. This results in instances where the user interface doesn't display security information properly. While the crypto code may have been validated till the cows come, home people rarely think of how the information is going to be displayed and thus its attack surface. So when the application displays information to the user that is used in a security decision, and this information can be spoofed, the security of system can be undermined or, in the worst case scenario, compromised.
To demonstrate this vulnerability, and so I don’t have to pick apart one particular implementation, I wrote a demo application in C#:
System.IO.StreamReader myFile = new System.IO.StreamReader("c:\\users\\ollie\\test.txt");System.Security.Cryptography.MD5CryptoServiceProvider myMD5 = new System.Security.Cryptography.MD5CryptoServiceProvider();
string myString = myFile.ReadToEnd();
string myOutput;
byte[] myBytes = System.Text.Encoding.UTF8.GetBytes(myString);
myFile.Close();
myBytes = myMD5.ComputeHash(myBytes);
System.Text.StringBuilder myMD5String = new System.Text.StringBuilder();
foreach (byte myB in myBytes)
{
myMD5String.Append(myB.ToString("x2").ToLower());
}
myOutput = "File Contents:\n" + myString + "\n" + "MD5: " + myMD5String.ToString();
blExample.Text = myOutput;
If our text file contains "HelloBlogWorld," we get the following output in our example application:
To illustrate this example further, for the next test our source data file will contain:
The result is that the application’s MD5 line is pushed down and our user-supplied string is shown in its place. I deliberately allowed the original MD5 line to remain visible (which I’ve highlighted with a red box):
If we add a little more padding and replace the original line with something that looks more in line with what the user expected, we get our forgery:
In this example, apart from the obvious upgrade from MD5 to SHA1, you wouldn’t suspect that the content wasn’t generated by the application.
The best way to protect against this issue is to clearly differentiate between data which is sourced external to the application and that which is generated by the application. The easiest way to do this is to use different fonts or even different font colours if appropriate. This should then be backed up by good input validation—in the example of .jad files, I can’t think of a situation where you would need trailing spaces in the different elements.
Anyway, that’s it from me. As always, have fun, and, well, errr, don’t always trust what you see....