Social Engineering: The Art of Human Hacking

I just got done reading Christopher Hadnagy's Social Engineering: The Art of Human Hacking. If you are interested in the social aspects of information security, this provides an in-depth view of the actual techniques and science behind social engineering. While books like Kevin Mitnick's The Art of Deception and The Art of Intrusion tell amusing and noteworthy stories of social engineering hacking, Hadnagy's book tells you why and how it works. Hadnagy's exposure all reveals the most important lesson -- how to defend against the attacks.

Hadnagy takes you through all the steps of a social engineering exploit -- from information gathering to the exploit. He discusses techniques like elicitation (extracting information from a target), influence (getting them to do what you want), pretexting (developing the back story that makes the attack believable), micro-expressions (control the subtle muscle movements that can give you away), and neuro-linguistic programming (the exact way you say things can make a big difference).

It doesn't matter if you're blue team, trying to protect your valuable assets against attack, or red team, trying to get in there, but it's critical you know how to exploit the human element of security. After all, the devil you know is better than the devil you don't.

The segmentation fault occurred where?!?

I recently ran into a C++ problem where a segfault was occurring in code in a stable library that hadn't been changed in a while. For a while, I couldn't figure out what would have broken in that library, and the call site looked perfectly fine. Before I give away the answer, let's take a quick quiz. What does the following code output? (And yes, this is somewhat compiler dependent, so let's pretend we're talking about how g++ works.)

#include <cstdio>
class Foo {
    char *name;
    void whatami() {
      printf("I am a Foo.\n");
    void whoami() {
      printf("I am %s.\n", name);
int main(int argc, char **argv){
  Foo *f = NULL;

My first instinct was to say "Segmentation Fault" and nothing else, because line 17 is going to dereference a NULL pointer. It turns out, of course, it's not that simple -- it'll actually print the "I am a Foo" before segfaulting. Clearly, then, the segfault must be on line 18, right? Wrong. Line 11 is where we give up, as f is not dereferenced until then. To see why this is, let's think about the equivalent C code:

#include <stdio.h>
typedef struct {
  char *name;
} Foo;
void Foo_whatami(Foo *self) {
  printf("I am a Foo.\n");
void Foo_whoami(Foo *self) {
  printf("I am %s.\n", self->name);
int main(int argc, char **argv) {
  Foo *f = NULL;

As we can see here, the pointer is actually unused by the method "Foo_whatami". But wait, you say, don't we need the address of Foo to resolve the location of the method? No, as whatami and whoami are not virtual methods! Their addresses can be determined by the compiler at compile time. Virtual methods, on the other hand, need a pointer from within the data area of the object to the vtable to resolve addresses. Change whatami to a virtual method, and you'll crash much more efficiently.

So remember, even if the code looks like you're dereferencing the pointer, it may well not be dereferenced until much later!

MITM on KVM Guests

I run a KVM virtualization system as part of my test lab.  I often want to redirect traffic to an intermediate application (such as sslsniff) on the host.  Supposing I have a guest on interface vnet7, bridged to br10, with the host running on the following ebtables & iptables magic gets the job done:

ebtables -t broute -A BROUTING -p IPv4 -i vnet7 --ip-proto tcp --ip-dport 443 -j redirect --redirect-target DROP
iptables -t nat -A PREROUTING -i vnet7 -p tcp --dport 443 -j DNAT --to-destination

Note that you can't use -j REDIRECT, as that's (roughly) equivalent to DNAT to the IP of the incoming interface, but bridged virtual network interfaces (vnet7) have no IP address.

2 Weeks at Google

Two weeks at Google have been... amazing.  There's a lot that I can't talk about, but I can feel comfortable in confirming some of the things you hear about Google:

  • The people are insanely smart.
  • The scale blows your mind as a Noogler (new Googler).
  • The food is great.
  • It has culture.

I'm a "Site Reliability Engineer" which is a job title that may not exist anywhere else.  It's basically production-oriented operational engineering: keeping production systems running and making them run better.

Ann and I have found a new place, so we'll be moving there from the corporate housing next week.  It'll be nice to get our stuff back and get settled in.

(All opinions expressed here are mine and not my employers.  I will not comment on or discuss Google policy, unreleased products, or other proprietary information.)

The End of a Chapter

I'm not usually one for reflective personal blog entries, but some events require a brief mention: today was my last day at KSU, and it was an incredibly surreal day.  Though I've known this day was coming for over a month, it is still hard to believe that it got here.  In many ways, today felt like any other day: the work was similar, things needed to get done.  In other ways, there was an 800 pound gorilla in the room: everyone knew that tomorrow I wouldn't be coming to work.  When I finally cleared out my office, the finality of what was going on really hit me.

There are friends I have made at KSU that are like none other, and I will genuinely miss them.  I hope we will stay in contact and I hope to get back to the Atlanta area sometime and visit them, or perhaps they will make it out to the bay area.  Unfortunately, friendships seem to have a tendency to dissolve too easily with distance, but one can always hope that things will be different.

Today, one chapter of my life closes.  For now, a brief interlude to relocate to the Bay Area, and then a new chapter begins in 12 short days!