Category Archives: Infosec

Information Security

The Hacker Crackdown

It seems like only yesterday, but it’s been 20 years now since a simple bug in a C program brought down much of AT&T’s long distance network and brought on a national phreak hunt.  It was January 15, 1990: a day I’ll never forget because it was my 25th birthday, and the outage made for a rough work day.  But, in retrospect, it offers a great story, full of important lessons.

The first lesson was realized quickly and is perhaps summed up by Occam’s razor: the simplest explanation is often the most likely one.  This outage wasn’t a result of a mass conspiracy by phone phreaks, rather the result of recent code changes: System 7 upgrades to 4ESS switches.

There are obvious lessons to be learned about testing.  Automated unit test was largely unknown back then, and it could be argued that this wouldn’t have happened had today’s unit test best practices been in place.

This taught us a lot about code complexity and factoring, since a break statement could be so easily misaligned in such a long, cumbersome function.  The subsequent 1991 outage caused by a misplaced curly brace in the same system provided yet another reminder.

Finally, this massive chain reaction of failures reminded us of the systemic risk from so many interconnected systems.  That situation hasn’t improved; rather, it’s much worse today.  We don’t call it the internet and the web for nothing.

I was reminded of 1990 when Google recently deployed Buzz: yet another player in our tangled web of feeds and aggregators.  These things are convenient; for example, I rarely login to Plaxo, but it looks as though I’m active there because I have it update automatically from this blog and other feeds.  It makes me wonder if someone could set off a feedback loop with one of these chains.  Aggregators can easily prevent this (some simple pattern matching will do), but there may be someone out there trying to make it happen.  After all, there’s probably a misplaced a curly brace in all that Java code.

Bruce Sterling’s book, The Hacker Crackdown provides an interesting read of the 1990 failure, and he has put it in the public domain on the MIT web site.  If you want a quick partial read, I recommend Part I.

Minum Data Redaction is pleased to announce its new Minum Data Redaction (MDR) product.  MDR provides physical data security for sensitive bank and credit card information, complementing the electronic data security covered by IBM’s just-announced Optim Data Redaction product.  Used together, these products can help you achieve PCI DSS compliance with little or no coding.

IBM’s new Optim Data Redaction automatically removes account data from documents and forms.  You can get that wondrous XXXXXXXXXXX1234 credit card number formatting with little or no effort on your part (apart from buying software, of course).

Our new Minum Data Redaction product extends account number protection to the physical world, protecting the bank cards you carry.  Its super-strong rear adhesive and front opaque covering ensures that your sensitive credit card information stays protected.  It comes in a variety of colors (including duct silver and black), and our Premium version provides extra thickness to cover embossing.

But seriously now, we go to great lengths to protect electronic card information by encrypting it in stored files (56-bit DES isn’t good enough); redacting it on printed receipts, reports, and statements; and setting disclosure requirements that publicly embarrass companies who slip up.  But yet our simple payment process requires that we hand all this information over to any clerk or waiter who usually goes off with it for awhile: certainly long enough to copy it all down.  PCI DSS offers the classic false sense of security.

I was recently a victim of fraud against my Visa card.  A series of small (mostly $5) fraudulent charges hit my account over several days until I closed the account.  From what I learned, the charges where only authorized by account number and expiration date; there was no zip code verification.  I don’t know how the perps got my credit card number, but I doubt they grabbed data from a financial institution in the dark of night, nor devoted the $250,000 and 56 hours required to run an EFF DES crack against it.  It probably came from a clerk or waiter who handled my card.  My cards, like everyone else’s, have account number, expiration date, and CCV printed right on them.  Zip code isn’t there, but anyone who wants it can just ask to see my driver’s license for verification.  It’s a gaping hole.

Until credit cards gain better physical security, there is no “silver bullet.”  But banks and card companies could enlist help from their own customers.  For example, let me specify which types of charges I would allow/authorize.  It would spare consumers the hassles of disputing charges, and would save issuers the dispute processing fees and write-offs.

777 – An Unlucky Number

Fool me twice, shame on… insecurity.

Far too often, Step 1 in deploying a file-manipulating script on Apache is setting wide-open (777) permissions on working directories.  This seems wrong on a few levels, but is often unavoidable.  The security risks of this are often overstated, since most real hosts chroot Apache, or use suEXEC or something like it.  So, hey, chmod -R 777 , why not?  The world may be able to write to my folders but they’ll never get there.

Well, one reason is the ghosts of hacks past have many web hosts configured (mod_php, mod_perl, whatever) to refuse to run scripts that have 777 permissions.  The result is usually an internal server error (500 exception) and, of course, no output from the script itself, since it never even got to run.

I had encountered this before when deploying and customizing a large CiviCRM system, and with some Q&D PHP scripts of my own.  But it was certainly not the first thing on my mind last night.

My wife wanted a new site to display and possibly sell some of her photography.  Her needs matched WordPress’ capabilities well, so I went that route – a WordPress install with a nice FotoFolio template.  But when it came time to generate image thumbnails – nada – just blank and black boxes.  By viewing the HTML source in the browser, I could see that the img tag src’s were calling timthumb.php.  Pasting this into a new browser address bar revealed the source of the problem – the internal server (500) errors.

I rechecked the FotoFolio setup instructions (including the overzealous chmod’s for TimThumb’s sake), and verified the script source.  777, 755, whatever it takes.   This process was made a bit more challenging since I had again lost ssh access to the host, and had to resort to using cpanel’s File Manager.  In frustration, I finally went back to square one and found that it wasn’t the temporary cache directory, parent directory, or template directory that had the offensive 777 permissions, but one at a higher-level.  Apache was refusing to run the script if any parent folder (between itself and document root) had world execute or write permissions.  I can understand the thinking, but wow.  755’ing that puppy fixed the problem and I was off and running at 1:00 am.

While searching for a solution, I saw that others had stumbled into this and found a few FotoFolio-based sites with black box images – telltale signs of the same struggles.  So, I would offer the following suggestions to others who might hit this:

  1. Set the 777 permissions as directed by the instructions, but be prepared to back off if needed.  The FotoFolio instructions included setting 777 on the scripts directory, not just the cache directory.  Doing this doesn’t work and isn’t necessary.
  2. If you see incorrect thumbnails and preview images, view the source in your browser, find the img src bit with the timthumb.php call, and paste it into a browser.  This will reveal if it’s failing.
  3. If you have upload or resize problems with large images, check the error_log file.  If you see memory allocation errors (“allowed memory size exhausted”), you may have to modify the ini_set call in timthumb.php to be under your memory limit.  A phpinfo script will show you your memory limit.  Of course, uploading only reasonably-sized images helps, too.

The site is basically up, so check it out:  FotoFolio is a nice theme and, if things continue to go well, I’ll stick with it, although I will need to customize it for a shopping cart, etc.

Perhaps the moral of this story is that insecurity can be costly. Too often, fear (insecurity) of an exploit can lead to ineffective (insecure) security measures.  In this environment, the 777 restrictions added costs but no benefits.  Hosts and developers should take precise, effective security measures, rather than using a shotgun approach.