A Social Engineering Primer Part 1

Someone once said, “It’s not that computers aren’t secure, it’s that people aren’t.” Someone else once said, “If you take a computer, unplug it from the wall, unplug it from the internet, take it deep into the wilderness, dig a very deep hole, put the computer in it and pour concrete on top of it, fill in the hole and never tell anyone where it is; that computer might be secure… but I wouldn’t bet on it.”
This brings us to my other favorite topic (besides botnets): Social Engineering.
Put a human being in front of a computer and nine times out of ten, that computer is no longer secure. Leaving aside the tenth time for the moment, this is because nine times out of ten, the human being is trying to get some work done. The computer is a tool, just like a hammer and like a computer, the only way to keep a hammer from hurting someone, either by banging a thumb, falling off a bench onto a foot or lying in wait for a toe on the floor, is to bury it and put concrete over it and never tell anyone where it is. It’s a people thing.
Add a third person with malicious intent into the mix and you have a catastrophe waiting for a chance to happen. Social engineering is the equivalent of bumping into the hapless hammer wielder just as he starts his downswing. It’s guaranteed to cause chaos, and if you are trying to break into a system, chaos is a good result.
I touched on social engineering in my last post where a judicious bit of timing coupled with a knowledge of human nature allowed me to raise cash from an ATM. This time I want to dig a little deeper into the unsung hero of the hacker’s toolkit.
For my novel Playing God I created a secure floor at the Microsoft like company Universal Software, where the coding of the “world’s most popular operating system” takes place. It’s armed with all the latest anti-hacker goodies and set up with an internet connection that is outbound only (packets from the outside world stopped dead in their tracks unless there are corresponding outbound packets preceding them.) An impregnable fortress, and rightly so, because in the hands of an expert hacker, the source code for an OS would reveal all sorts of things too numerous to get into here. Now I’m sure a lot of you are calculating esoteric attack vectors that could break this fortress, but let’s assume for the sake of fiction that they wouldn’t work. (The reality is that the more obscure the attack vector, the more bored the general public will get reading about it.) So, with all that in mind, how are we to get our protagonist in to steal uncompiled OS code? Enter (stage left) our unsung hero: Social engineering.
Start with a human resources girl who manages to bend the rules for an ex-boyfriend (our protagonist) and give him a brief tour of the secure floor – a major no no. [*note: I could have scripted a seduction scene with a stranger, a blackmail scheme with an older woman, or any number of other ways to get him on the floor.] Then, armed with a thumb drive he’s loaded an outbound trojan onto (That’s a piece of malware that installs itself and then sends packets to a specified IP address – in this case, our protagonist’s computer.) and a sticky note that reads “thought you should see this before the sh#t hits the fan”, our hero appears to stumble, catches a desk to break his fall and drops off the payload on a programmers desk and leaves. His escape is seamless, because there is no obvious break in or crime. Forensics will later reveal him to our villain and set him on our protagonist’s trail, but it’s too late. He has already followed the outbound packets back inside, downloaded the source code and is on the run. Aside from the trojan, pure social engineering top to bottom.
I’ll break all this down in part 2 and discuss the reasons that it’s so difficult to teach social engineering. I’ll also discuss why it’s necessary to find a way to do so.