SmurfWare SmurfScanner Risk Assessment Case Study

Instructions

This case study presents a real-world architecture and description of a software system. Please read through the description, look at the architecture diagram, and then answer the questions given. Thinking about how the system works (and how your understanding differs from someone else's) will frequently result in finding ways to break it.

SmurfWare SmurfScanner Architecture and Implementation Description

The Smurfs are developing a new biometric authentication device to keep non-Smurfs out of the Smurfland network. The biometric device is being dubbed the SmurfScanner by Papa Smurf. The SmurfScanner is a hardware device that scans a user's skin color for blueness. Since only Smurfs have that unique Saturday morning cartoon blue color, if the device can successfully identify the unique blue, then this will do for making a determination as to whether or not a person really is a Smurf (or at least we make this assumption for the purpose of this exercise, be it based in actual fact or not).

The SmurfScanner is attached to a PC running MicroSmurf Windoze XP via serial port. Along with an all-blue user manual and a blue SmurfWare coffee mug, the SmurfScanner comes with software that allows it to act as the login screen manager in Windoze. To even get to the login screen, a user's Smurfness has to be established by the SmurfScanner. Once calibrated by the manager application, the SmurfScanner returns whether or not a user is sufficiently blue. The software architecture of this system is represented by the diagram in Figure C-1. Each box represents a separate process running on either the PC or the hardware of the SmurfScanner device.

Figure C-1. The SmurfWare SmurfScanner architecture has a number of serious security flaws. Can you identify some?

SmurfScanner Architecture Component Description

SmurfScanner Crypto Helper: Since actual authentication traffic between the scanner and the software has to be encrypted and integrity has to be ensured, the software package provides an API for making encrypted calls, such as IsUserASmurf(), to the SmurfScanner. The caller gets to decide whether to use the proprietary but extensively tested (by two Smurf crypto experts) Smurfcrypto library or the equally solid Microsmurf Windoze implementation of crypto. The Helper exists in both the PC and the SmurfScanner hardware to facilitate two-way integrity and privacy.

SmurfScanner Common Command Layer: The SmurfScanner formats higher-level API calls into a format that the serial driver can understand, be they encrypted or not.

SmurfScanner Manager: Since this application is rarely used, crypto was deemed unnecessary. Instead, the Smurfs hard-coded a hash of Smurfette's body weight in milligrams in both the SmurfScanner and the Embedded I/O Manager so that the SmurfScanner's Embedded I/O Manager would recognize that the privileged commands were coming from only the SmurfScanner Manager application. The Manager application appends this hash to every command sent to the scanner. The Smurfs chose this secret method because Smurfette's body weight is a well-known fact within the entire Smurf community but not known at all outside of it. The Manager application is used to set up the scanner's calibration and to run diagnostics in case it is malfunctioning. The scanner must be calibrated for local light conditions with a sample Smurf before use. The Manager is also used to initialize the Helper apps on both the PC and the scanner with secrets to allow the integrity and privacy functionality to work. The secrets are a hash of the system clock.

SmurfScanner Embedded I/O Manager: This app sorts encrypted versus unencrypted commands and forwards them to either the Helper or directly to the Logic Layer. Commands are sent directly to the Logic Layer when the I/O Manager recognizes the Smurfette body weight shared secret hash.

SmurfScanner Logic Layer: This layer takes the hardware measurement of a user's blueness and compares it to the calibrated value and returns a yes or no, thus performing authentication on a Smurf. The Logic Layer also does other things like calibrate the scanner based on data received from the Manager app, track usage, and run diagnostics.

SmurfScanner Business Application: It is critical to understand the business context in order to estimate impact (in such a way as to answer the "Who cares?" question). In this case, the SmurfScanner is being used to protect SmurfTunes from use by non-Smurfs. SmurfTunes is set up to deliver Saturday morning cartoon theme songs to SmurfPod personal digital listening devices.

Questions

1.	What are the business goals and associated risks for the SmurfTunes system?
2.	What goals could an attacker have in mind when thinking about attacking this system?
3.	What are the implementation bugs and architectural flaws in this system that could be used for attack?
4.	How can these technical problems be stated as risks (and then ranked)?
5.	What ways could an attacker exploit technical weaknesses to achieve attack goals?
6.	Given your answers to the preceding questions, list at least three risks posed by this software system and rank them starting with the greatest first.

Tons of extra credit for performing this exercise by following the risk analysis process from Chapter 5.

DO NOT CHEAT. Work out answers before you look at the ones I provide.

Answers

Some of the questions have more correct answers than the ones listed here.

1.	What are the business goals and associated risks for the SmurfTunes system?
A1:	Provide digital Saturday morning cartoon music with Smurfs only. Loss of digital IP (value). Provide music on demand. Store and retrieve essential Smurf theme song data.
2.	What goals could an attacker have in mind when thinking about attacking this system?
A2:	Theft of Saturday morning cartoon music. Determine what others are listening to. Cause a certain song to become a "hit." Substitute theme song from the Brady Bunch for the Smurf theme song. Deny service to all SmurfTunes.
3.	What are the implementation bugs and architectural flaws in this system that could be used for attack?
A3:	SmurfScanner Manager and the I/O Manager use a hard-coded shared secret that has low entropy and could be reverse-engineered. SmurfScanner Manager commands are not protected from tampering since they use no encryption. The Manager seeds the helper apps with low-entropy system clock output. The software components in the system don't authenticate with each other, hence it would be easy for an attacker to substitute a malicious component on the PC side. The Smurfcrypto is roll-your-own crypto, which is weak, and an attacker app can choose which crypto to use. The SmurfScanner Common Command Layer does not authenticate calls made to it, hence it provides an effective and easy means to a denial-of-service attack.
4.	How can these technical problems be stated as risks (and then ranked)?
A4:	Left as an exercise for the reader. Think about the business goals and risks you already identified.
5.	What ways could an attacker exploit technical weaknesses to achieve attack goals?
A5:	Denial of service using Common Command Layer functionality. Recalibration of the scanner to allow the evil "Red Smurfs" onto the network through reverse-engineering the Manager's secret and recalibrating the scanner on the fly. Substitution of a software component and sniffing to steal usage data. Guessing of the secret seed input to facilitate theft of encrypted data. One could also use this method to make the device return the wrong outputs and hence cause problems for legit Smurf users.
6.	Given your answers to the preceding questions, list at least three risks posed by this software system and rank them starting with the greatest first.
A6:	Again, left as an exercise for the reader. This answer depends on your ranking.