Exploring the Mental Processes of Dark Minds

by Walt Stoneburner
"Deep down, one just really has to admire the cunning of Lex Luthor."


Improving Software Security

In terms of improving software security, it helps to not only understand how software has been compromised in the past but also the mental process that lead to the ah-ha experience of a new compromise.

Take war, for instance. Most countries throughout history are always prepared defend themselves against the tactics of the last war. This is akin to closing the barn door after the horse escaped, and it also assumes your enemy is foolish enough to attack in similar manner. Most successful campaigns relied on developing a new solution that the opponent had not anticipated.

This is why it is not only important in software to understand how someone who's intent on compromising your software thinks. A sloppy, lazy, or inexperienced coder will fall victim to past mistakes. An expert programmer must not fall victim to new ones.

With that said, we won't be covering details of buffer overflows, protocol attacks, and such here. Instead we'll look at real-world compromises and the ah-ha experiences that led to finding them. From these the reader can draw analogies to the software world.

Unfortunately, I can't take bragging rights for the compromises listed below. But if you have any you'd like to contribute, please pass them to the author.

Magic, Cons, and Scams

Penn and Teller perform a trick called "Looks Simple" and in it they blatantly reveal the Seven Principles of Magic: Palm, Switch, Simulation, Misdirection, Load, Steal, and Ditch. These tools work because they work in conjunction to compromise our perceptions.

Fundamentally, compromising security works the same way. Security exists as a system, a set of procedures that are implemented in a trusted, reliable, and tangible form. A fault can exist by poor design or poor implementation, one small weakness found by the persistent is all it takes to topple things. Sadly, most software resources that cover security spend too much time looking at implementation, and not enough at design.

Unauthorized Entry

The common example of "locks do no good" is the lock on the window to keep the burglar out. All a persistent burglar has to do is break the window to gain entry. Failing that, a chainsaw to the drywall next to the window is also effective. The trade off here is noise, visible damage, and left over evidence.

Ah-Ha Experience: "What if I wasn't a burglar, but someone who was authorized to do house construction, like a siding contractor? That would attract less attention because the activity isn't out of place."

The more elaborate the deception, the less attention it arouses.


Conversely, if the front door isn't locked or another window is left open, entry can be gained from bypassing the window with the security on it.

Ah-Ha Experience: "Just because there exists a lock here does not imply everything is locked."

If you can't invoke a program, perhaps you can invoke its library of functions to do your dirty work.


In fact, a persistent burglar may try dozens and dozens of windows, doors, and garages before finding access to an unauthorized entrance.

Ah-Ha Experience: "It can be easier to look for lack of security than to try to compromise security."

It is easier to look for an error in human behavior than it is to thwart technology. Additionally, if the sample space is small enough, all solution combinations can be exhaustively tried.


Since locks are usually designed to keep people out, not people in, multiple points of escape now present themselves.

Lessons Learned: If picking a lock looks difficult, breaking it will suffice. If breaking it is difficult, access can be gained by going around the lock. It only takes one unlocked entry to make all other security points worthless, no matter how expensive or elaborate they were. Slip ups in security can be found by trial and error and playing the numbers.


Unlocking the Window, From the Inside

The assumption, of course, is that both you and the burglar start on even ground. He'll examine your security passively. If he can't compromise it, he'll give up. This kind of assumption needs dispelling, there are no rules.

The burglar simply has to look at the window, see that it's locked, and say to himself, "this would be a lot easier if that window were unlocked." He now has two options. Get you to do it, or do it himself.

To get you to do it simply requires giving you a reason or motivation to do so. This could be as simple as slipping a skunk through the doggie door, which invites you to air out the house. But even better, if he can do it himself.

Scenario: you've locked your windows, but right as you are ready to retire a pizza delivery person arrives with a pizza. You explain you didn't order a pizza, and he's now concerned he got the wrong address. He goes to dial the store on his cell phone, but it's dead. Can he borrow yours? You let him. He calls, and after a moment he says that the error was his, they're sending another driver out to that customer, and the manager said you could have this pizza for him disturbing you. As the delivery person hangs up he asks if he can use your restroom. And while in there, unlocks the window. He now has cased the joint and has instant access.

Ah-Ha Experience: "By changing the goal from access to opening a window, the problem shifts to how you can get temporary authorized access."

Guest access is still access. Security inside a computer system is usually more lax than security providing access to the system.


Corporate spies visiting or using restrooms can unlock, jam, and prop open doors for later access.

Lessons Learned: Don't trust that the person is who they say they are. Don't trust they they don't have alternate intentions. Don't trust your environment after it is visited.


The Elevator Key

What high school student doesn't long for possession of the coveted elevator key? That too is easily obtainable. Find someone with long term access to it, such as the student on crutches. Offer to do a good deed at the end of the business day, such as moving A/V equipment between floors and return the key the next day after duplication.

Ah-Ha Experience: "Access to what you want can fall into your hands, into the hands of someone you know, or can be obtained temporarily for a side purpose. Once a token is obtained, it can readily be duplicated."

A secret once exposed remains exposed.


Lessons Learned: When passing out a token for access to a public resource, use a disposable token.

Passwords that work today should not work tomorrow, especially if there's no means of identifying the user during access.


Roof Access

Some buildings have access to the roof via a ladder bolted to the side of the wall and a trap door with a padlock sealing the access. It's surprising to note how many times the hinges are on the inside and that a simple flat-head screwdriver removes the hinge pins.

Ah-Ha Experience: "When part of the protection mechanism is exposed, the whole overall security is compromized. Don't go for the lock if going for the operating mechanisms is easier."

Why crack the protection mechanism if the executables (or source) are right in front of you and can be tampered with?


Forging Credentials

I once had a friend who could come and go at school at will. I asked him how he did it, and he responded that he wrote himself his own excuse notes.

The first time he was legitimately sick, his mother wrote him a fairly wordy excuse. He diligently copied that note when he got to school in his best handwriting. He then presented the note to administration. Naturally, they questioned it, and called his mother in front of him. They read the note to her, and she acknolwedged that was her note. Their conclusion was that she had pretty bad handwriting and put the note on file to be compared against future samples. The ruse was easily renewed when mom sent future legitimate notes to the school by the same practice.

Ah-Ha Experience: "They don't have authentication on file and this sample is about to be used for that purpose. I'll substitute it for something I can produce on demand."

This represents the classic man-in-the-middle attack.



SlingCode Search Results About     Articles     Links     Search Tips  
SEARCH: