Media- and file-based attacks

It’s been pretty busy at work so I’ve only been able to finish How to Break Software only last week in one of the nights when we had to do overtime work for our demo project. Anyway, there was this section on media-based and file-based attacks. In previous web projects, we had’t considered these as extensively as we had done in JV. In JV, the client’s machine is the environment so we had to be more conscious of the files and folders s/he uses.

Media-based attacks

  1. See if your software can handle a full storage medium. Fill up the hard drive and then force the software to perform file operations (by opening, moving, and saving files).
  2. See if the software can gracefully deal with a busy file system. Some applications don’t have the proper timeout/waiting mechanisms, so they can fail when the file system is busy serving a request from another application. Force the software to perform file operations in conjunction with background applications that are also performing file operations.
  3. Try forcing the software through file operations with a damage medium. Applications with weak fault handling code will often fail in this scenario.

File-based attacks

  1. Try assigning invalid file names to the application’s data files, temporary files, and read-only files. Then force the software to use those files.
  2. Change the access permissions of the application’s data files. User permissions and read-write-execute-delete permissions are often ignored by the developers.
  3. See if the software can handle corrupt data in a file. Since most data corruption results in a failed cyclical redundancy check, Canned HEAT is the perfect mechanism to inject such a faults. Otherwise, use a hex/text editor to change the contents of a file and then force the software to open the file or read from it.

In addition, some other stuff I consider:

  • Try using a removable drive for storing some files. See what happens when the drive has been removed properly or removed in the middle of an operation.
  • Try using a remote location when specifying some files to be used as the program’s input. I encountered cases wherein the behavior hadn’t turned out as expected when I specified \machine-named$filename.

Some elaborations…

Media-based attacks

1. See if your software can handle a full storage medium. Fill up the hard drive and then force the software to perform file operations (by opening, moving, and saving files).

For this, I created a small partition in my hard drive. Alternatively, I use my meager 512mb thumb drive.

2. See if the software can gracefully deal with a busy file system. Some applications don’t have the proper timeout/waiting mechanisms, so they can fail when the file system is busy serving a request from another application. Force the software to perform file operations in conjunction with background applications that are also performing file operations.

Sometimes consecutively clicking on a function button (e.g., Save, Delete) twice or thrice can already expose some faults.

3. Try forcing the software through file operations with a damage medium. Applications with weak fault handling code will often fail in this scenario.

This is something I personally haven’t tried. Our sysads might kill me if I do this.

File-based attacks

1. Try assigning invalid file names to the application’s data files, temporary files, and read-only files. Then force the software to use those files.

For testing a flex application, some special characters turn out to be problematic especially non-ascii ones and even the sharp “#” character. So we try to inject test cases using Asian characters, accented characters and special characters whenever possible.

2. Change the access permissions of the application’s data files. User permissions and read-write-execute-delete permissions are often ignored by the developers.

Being used to Windows XP, I encountered a related bug when trying the same program in a Windows Vista environment. Our program had to revise an entry in the registry. However, for Vista, the default rights just wouldn’t suffice so we get an exception.

3. See if the software can handle corrupt data in a file. Since most data corruption results in a failed cyclical redundancy check, Canned HEAT is the perfect mechanism to inject such a faults. Otherwise, use a hex/text editor to change the contents of a file and then force the software to open the file or read from it.

Since our project makes use of XML files, we try cases involving invalidating the XML file in order to see whether our program could detect it and make the needed replacements. For one other instance, I had added some unicode characters into an XML file. While it hadn’t triggered an error in the maintenance screen which read and wrote on the XML file, it triggered an exception in a conversion function which also read from the same file.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s