SQL Exploits Everywhere

Bruce Schneier says that if you are going to be a successful defender of technology, you need to look from the attacker's point of view.

In this case, I wanted to detail how a small system I found on my campus, could attack a much larger one, potentially proving to be disastrous.

There is a small, unsecured, system that is used by an office at my university to check out technological items to professors that need them. While in the office that developed this application, I saw that one of the employees was having trouble entering a "comment" for a checkout, it turned out, the comment was evidently being put in to a SQL statement un-escaped. The server that does this is web-facing.

I also happen to know that the developers for the campus' programs are (excuse me when I say this, if any of you ever read this) incredibly poor programmers. They can never decide who owns a bug. Each is locked in to their own specialty and can't see things from another perspective, and little testing is done before products are released (because I've experienced large bugs in the stable versions). No two developers have overlapping knowledge of any one product (if one leaves, and the software goes haywire, it stays that way, even if it is totally unusable, until the key developer comes back).

There are even flaws that allow you to view content that shouldn't be available to you, by incrementing numbers in address bars, or editing content through boolean values in cookies...there are bound to be hundreds of overlooked flaws in the software the university pumps out, as developers tire of the old and switch to the new, only re-visiting the old when they decide to write from scratch again.

I also know, that some systems developed take up to 24 hours for users to sync from one DB to another...meaning users and passwords (as hashes are unlikely in such large systems of software varying in age from nearly twenty-ish years old to now to be implemented, and if they are, they are likely nothing more than md5sums) We even use MSCHAP for network authentication (which was broken a long time ago, and is trivially easy to do now with even the smallest of CPUs on the market)

This leads to the conclusion, that user integrity could be easily compromised through one application. All you need is one break, and the user-names and passwords could be flowing...SSNs, DOBs, bank accounts, relative's names, email addresses, all part of a standard University's collection of data.