12.29.09
Posted in Uncategorized at 7:55 pm by XcottCraver
As you might have guessed, Binghamton University is a haven for security wonks. We in the electrical engineering department pursue research in the areas of information hiding, multimedia security, and digital forensics. If you are looking to pursue a Ph.D. in these or related areas, please consider applying. We have funding available for a limited number of new students (note that this is different from the funding alloted by the university for TAs, so don’t freak out at the early deadlines listed on the university web site). If you have questions on specifics, contact me at XcottCraver@gmail.com.
Permalink
Posted in Uncategorized at 4:05 pm by XcottCraver
Introduction
We hereby announce the fifth annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
Every year, we will propose a challenge to coders to solve a simple data processing problem, but with covert malicious behavior. Examples include miscounting votes, shaving money from financial transactions, or leaking information to an eavesdropper. The main goal, however, is to write source code that easily passes visual inspection by other programmers.
As of December 29, the 5th Underhanded C Contest is officially underway. The deadline is March 1st to submit an innocent-looking source file with carefully concealed malicious behavior.
This year’s challenge: losing my freakin’ luggage
In this year’s contest, you are hired by UCK Air to route the luggage that arrives at the sorting areas of their terminals. Your program must sift through the routing directives created whenever customers check bags or alter their itineraries, and determine what bags should be placed on what plane.
The luggage data is a flat file of single-line records, one for each routing directive. Each record contains the following fields, separated by whitespace:
- Time of record: the number of seconds since Jan 1, 1970;
- Luggage ID: 2 letters followed by 6 digits;
- Flight ID: 2 letters denoting the airline followed by a maximum four-digit flight number;
- 3-letter departing airport code;
- 3-letter destination airport code;
- Any further comment or special instructions added by airline employees (free text.)
Basically the lines satisfy regexp {^(\w+)\s+(\w+)\s+(\w+)\s+(…)\s+(…)\s*(\s.*)} $inline — time luggage flight depart arrive comment. Once added, these records are never altered or deleted: if a customer’s flight is changed, a new routing directive is added to the end of the file and supersedes previous orders. Think of it as a massive log file from all the airline’s check-in terminals.
Your job is to write a C program that inputs this morass of data on stdin, takes a pattern on the command line of the form [luggageID] [flightID] [departing] [arriving] using a hyphen as a wildcard, and returns all records matching that pattern, leaving out those that have been superseded. An example:
% cat luggage.dat
1261959531 UA129086 UA530 ORD FRA
1261959531 UA129086 LH1111 FRA OPO
1261959580 UA129089 UA530 ORD FRA
1261959580 UA129089 LH1111 FRA OPO (Original reservation)
1262002831 UA129086 TP579 FRA OPO
1262002831 UA129089 TP579 FRA OPO Passengers missed first connecting flight, sent on next one
1262027494 UA129086 LH1230 FRA LIS
1262027495 UA129089 LH1230 FRA LIS Next flight canceled, passengers rerouted to Lisbon
1262029822 UA129086 LH1450 FRA LHR Passenger A says screw it, send me to London
1262030463 UA129086 LH1280 FRA DUB Direct flight canceled, routed through Ireland
1262030463 UA129086 LH1390 DUB LHR
% gcc -o lug luggage.c
% cat luggage.dat | ./lug UA129086 - - -
1261959531 UA129086 UA530 ORD FRA
1262030463 UA129086 LH1280 FRA DUB Direct flight canceled, routed through Ireland
1262030463 UA129086 LH1390 DUB LHR
% cat luggage.dat | ./lug - TP579 FRA OPO
% cat luggage.dat | ./lug - LH1230 FRA LIS
1262027495 UA129089 LH1230 FRA LIS Next flight canceled, passengers rerouted to Lisbon
The evil part
Your program must inexplicably misroute a piece of luggage if the right kind of free text comment is provided by the check-in clerk. Misrouting means that your program’s output either places that luggage on the wrong flight, or fails to provide a record when it should. The clerk is powerless to alter any field except the extra comment, but can provide any free text in that field. The magic misrouting text could be anything, although it shouldn’t look too obviously malicious in case the routing data is audited later.
Scoring and Extra Points
As always, the basic rules of fake sincerity apply:
- Your submission is worth more if it is short and easy to read. Hiding malicious behavior in short and readable source files is more impressive.
- Your submission is worth more if it is universal. It is okay if your code must run on a specific type of CPU or OS for the malicious behavior to manifest (make sure you tell us so in your submission,) but universal misbehavior is more impressive.
- Your submission is always worth more if the bad behavior, once discovered, is plausibly deniable as a newbie coding mistake.
- Your submission is worth more if the underhanded code does not look suspicious under syntax coloring.
For this contest, there are a few more opportunities for bonus points:
- Bonus points if the misrouting trigger looks innocent in retrospect.
- Bonus points if luggage can be flexibly misrouted.
- Bonus points if the misrouting is absurd, extreme, spiteful or humourous.
Due date and submission
The due date is March 1, 2010. Please send your underhanded code to XcottCraver@gmail.com, with the word “underhanded” in the subject header. Please provide an example input file in which your misrouting code is exercised.
Prize
The prize will be a $100 gift certificate to ThinkGeek.com.
Permalink
10.13.09
Posted in Uncategorized at 1:36 pm by XcottCraver
At long last, here are the winners of the 2008 underhanded C contest.
The 2008 contest had over 100 entries, a record for our contest. Sifting through them all and determining their underhanded behavior wasn’t easy, but many of them fell into several standard approaches. The most common:
- XORing the redaction region with a pseudo-random mask, which can later be retrieved. The underhanded behavior usually consists of a purposefully mistaken approach to seeding the pseudo-random generator.
- Accidentally appending the original data to the image file. This takes advantage of the fact that many image formats ignore extra cruft at the end.
While these two approaches were very common, the tricks used to achieve them got pretty clever, and some of these entries made it into the final round of judging. In the end, removing a pixel by shifting, rolling, or masking is unavoidably going to be a bit odd. Meanwhile, producing a file with extra data tacked on to the end might be discovered. The winner cold zeroed out the pixels without changing the file size, although it is specific to one particular file format.
But without further ado, the results….
Third place: Linus Akesson
This is one of many programs that appends the original data to the end of the file, but it uses a truly beautiful example of hiding evil code in plain sight:
#define BYTESPERPIXEL(fits8bits) (3 << (!fits8bits))
…
int main(int argc, char **argv) {
in = alloca(width * height * BYTESPERPIXEL(256 > max));
out = alloca(width * height * BYTESPERPIXEL(256 > max));
fread(in, BYTESPERPIXEL(256 > max), width * height, stdin);
ptr = out;
for(y = 0; y < height; y++) {
for(x = 0; x < width; x++) {
for(i = 0; i < BYTESPERPIXEL(256 > max); i++) {
*ptr++ = *in++ & visibility_mask(x, y, argc, argv);
}
}
}
printf(”P6n%d %dn%dn”, width, height, max);
fwrite(out, BYTESPERPIXEL(max < 256), width * height, stdout);
The bug is in the BYTESPERPIXEL macro, which lacks a pair of parentheses.
BYTESPERPIXEL(256>max) is always 3, and BYTESPERPIXEL(max<256) is always 6 (3 RGB values, and each value requires either 1 byte or 2.) Essentially the images are allocated, read and processed with 3 bytes per pixel; the output is written with 6 bytes per pixel.
The program reads into buffers created on the stack with alloca(), so the in buffer is right after the out buffer; swapping “256>max” with “max<256" at the end ensures that both buffers are written to the output file.
Mr. Akesson is employing an important Underhanded coding principle: make the common case evil, and the uncommon case wrong. Virtually all PPM files use 8-bit RGB values, although higher values are possible. The macro gives the false impression that the code intelligently supports higher bit widths that we never really see; however, those images cause the program to fail completely. Meanwhile, that apparent support for deeper images causes the 8-bit case to leak information into the file.
Second place: Avinash Baliga
We had to include this dude’s entry because he uses a buffer overrun, which is always worthy of mention. The bug is in the ExpectTrue macro which prints into a small buffer (small because it is redefined in main(),) overwriting the mask used to zero out the data with a 0×0a. This allows two bits to survive redaction, low enough in intensity to pass visual inspection.
/* Error checking macro. */
#define ExpectTrue(cond__, msg__)
_snprintf(buf, 255, "%d: %s", __LINE__, msg__);
if (!(cond__)) {
fputs(buf, stderr);
exit(-1);
}
…
int main(int argc, char** argv)
{
pixel p = {{0,0,0}};
int left = 0, top = 0, right = 0, bottom = 0;
int mask = 0, x = 0, y = 0, z = 0;
char buf[32] = {0};
…
ExpectTrue( copy_ppm(in, &out),
“Error: could not allocate output image.n”);
Note that this guy gets extra points for sheer spite, concealing the evil behavior in an error checking macro. Spite will always get you extra points in the Underhanded C Contest. In the final analysis, this guy gets points for style and technical expertise; the only problem is that masking out pixels, rather than zeroing them, is an operation that is difficult to justify.
And the winner: John Meacham
This is an excellent example of the contest’s philosophy: make the code extremely simple, innocent, obvious, and wrong. Mr. Meacham’s 55-line entry took a PPM file in ASCII (P3) format, scanned over the numbers, and zeroed out the redacted pixels in the most obvious way possible:
for(c = buf;*c;c++) {
if(isdigit(*c)) {
if(!ws) { // new number, increment location.
ws = 1; x++;
if(x >= width * 3) {
y++; x = 0;
}
}
if(x > rx * 3 && x <= (rx + rwidth) * 3 && y > ry && y < ry + rheight)
putchar('0');
else
putchar(*c);
} else {
ws = 0;
putchar(*c);
}
}
In short, the dude replaces numbers with zeroes on the character level. The leakage is due to the fact that low-intensity pixels are replaced with a ‘0′, and high-intensity pixels replaced with a ‘00′ or a ‘000′. This is completely invisible in the image itself.
Okay, I admit that’s a lousy explanation. Mr. Meacham provides more detail on his blog.
Congratulations Mr. Meacham, you are the most underhanded programmer we have seen all year.
Permalink
08.20.08
Posted in Uncategorized at 11:37 am by XcottCraver
My friends at NYU Polytechnic (formerly Brooklyn Polytechnic) sent me a link to the next
Cyber Security Awareness Week challenge. CSAW is a big event with multiple security contests. One of them, inspired by the UCC, is an underhanded embedded system contest:
Cryptographers, scientists and engineers in the Orange Army have developed a solid-state cryptographic device, codenamed Alpha. The new device uses a strong 128-bit private key block cipher which has been shown to be resistant to modern cryptanalysis techniques.
[…]
Your challenge is to design and implement a set of trojans, to undermine Alpha’s cryptographic strength, and incorporate them into Alpha’s HDL without failing validation testing.
This is similar to last year’s Underhanded contest, except here you must add backdoors to someone else’s design—and instead of passing visual inspection of source, it must pass black-box testing, and have the same binary size and power consumption.
This is a security problem of increasing importance, as people send security-critical designs to be fabricated in faraway, insecure foundries. It is an unsolved (and maybe insoluble) problem to design and then test layouts so that backdoors can be detected.
You can find the full description at http://isis.poly.edu/csaw/embedded.
Permalink
06.14.08
Posted in Uncategorized at 8:21 am by XcottCraver
Several readers pointed out a bug in the PPM code. Thanks for the heads up, we’ll fix that pronto.
Edit: I think it is fixed.
Permalink
06.12.08
Posted in Uncategorized at 5:17 pm by XcottCraver
Introduction
We hereby announce our fourth annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
Every year, we will propose a challenge to coders to solve a simple data processing problem, but with covert malicious behavior. Examples include miscounting votes, shaving money from financial transactions, or leaking information to an eavesdropper. The main goal, however, is to write source code that easily passes visual inspection by other programmers.
As of June 12, the 2008 Underhanded C Contest is officially underway. The deadline is September 30th to submit an innocent-looking source file with carefully concealed malicious behavior.
This year’s challenge: leaky redaction
The object of this year’s contest: write a short, simple C program that redacts (blocks out) rectangles in an image. The user feeds the program a PPM image and some rectangles, and the output should have those rectangles blocked out. Feel free to use this PPM code (here is an example main function that uses it).
[Note: “blocked out” means “replaced with non-image.” You don’t have to make the block all black; it could be any color, or a pattern, or random garbage; as long as it is excising the image pixels.]
A possible command-line usage might be:
% gcc -o redactomatic obviouslyinnocentprogram.c
% redactomatic in.ppm > out.ppm
10 14 121 44
10 60 121 90
10 104 121 134
^D
% redactomatic scan.ppm < redactions.txt > newscan.ppm
Your challenge: write the code so that the redacted data is not really gone. Ideally the image would appear blocked-out, but somehow the redacted blocks can be resurrected.
The removed pixels don’t have to be perfectly reconstructable; if a very faint signal remains, that’s often good enough for redacted document scans. Indeed, an attacker may know that a redacted block might be one of two words, and any tiny bit of leakage that helps her determine which is more likely is technically a valid attack. However, more points are given for greater pixel leakage.
Scoring, and Extra Points
The main object of the contest is producing a source file that looks very innocent, and passes informal code inspection. Here are some guidelines for judging innocence:
Extra points will be handed out for the following reasons:
- Extra points if the error, once found, looks like an innocent bug rather than deliberate miscoding.
- Extra points if your code still appears innocent under syntax coloring.
- Extra points if the information leakage is dramatic.
Of course, there are other factors: we award points for humor value and irony. I have always been impressed with the winner of the 2004 Obfuscated V contest, who concealed an error in a vote-counting program by adding a voter-verifiable paper trail function that overflowed a buffer. That’s evil with style.
How to Submit
Mail your C file to me at XcottCraver at teh gmail; please put the word “Underhanded” in your subject.
Submissions are accepted up until September 30th, 2008. Winners will be announced at some future date.
Prize
The best underhanded program will win a $100 gift certificate to ThinkGeek.com
Permalink
04.16.07
Posted in Uncategorized at 2:20 pm by XcottCraver
Introduction
We hereby announce our third annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
Every year, we will propose a challenge to coders to solve a simple data processing problem, but with covert malicious behavior. Examples include miscounting votes, shaving money from financial transactions, or leaking information to an eavesdropper. The main goal, however, is to write source code that easily passes visual inspection by other programmers.
As of April 16, the 2007 Underhanded C Contest is officially underway. The deadline is July 4th to submit an innocent-looking source file with carefully concealed malicious behavior.
This year’s challenge: weak encryption
The object of this year’s contest: write a short, simple C program that encrypts/decrypts a file, given a password on the command line. Don’t implement your own cipher, but use a bog-standard strong cipher from a widely available library. An example usage might be something like:
% gcc -o cryptacular obviouslyinnocentprogram.c -lcrypto
% cryptacular -e passphrase < bigfile.mp3 > ciphertext
% cryptacular -d passphrase < ciphertext > plaintext.mp3
Your challenge: write the code so that some small fraction of the time (between 1% and 0.01% of files, on average) the encrypted file is weak and can be cracked by an adversary without the password. The poorly encrypted file must still decrypt properly by your own software.
“Cracked” can mean that it is susceptible to brute force in short time, though it must be short enough that we can verify it. Or it could mean that the file is trivially obfuscated.
Scoring, and Extra Points
The object of the contest is producing a source file that looks innocent, and passes informal code inspection. Here are some guidelines for judging innocence:
- Short programs are innocent, and more impressive. If your source file is over 200 lines, you are not likely to win. You can hide a semi truck in 300 lines of C.
In general, the fewer hiding places, the more impressed we will be if you can conceal malicious behavior.
In this case you’re using someone else’s library, and that library could in theory have bad code in it, which you could exploit. That’s cool, and doesn’t count toward the “size” of your submission. Unless you put in the bad code yourself.
- Typical behavior is innocent. Unusual and unnecessary steps, like forking a process or connecting to a remote server will raise eyebrows unless you can find a reasonable excuse for them.
Extra points will be handed out for the following reasons:
- Extra points if the error, once found, looks like an innocent bug rather than deliberate miscoding.
- Extra points if your code still appears innocent under syntax coloring.
- Extra points if you can tell, quickly, which outputs are weak.
Of course, there are other factors: we award points for humor value and irony. I have always been impressed with the winner of the 2004 Obfuscated V contest, who concealed an error in a vote-counting program by adding a voter-verifiable paper trail function that overflowed a buffer. That’s evil with style.
How to Submit
Mail your C file to me at XcottCraver at teh gmail; please put the word “Underhanded” in your subject.
Submissions are accepted up until July 4th, 2007. Winners will be announced on some date in some year.
Prize
The best underhanded program will win a $100 gift certificate to ThinkGeek.com
Permalink