Chapter 4. Social Engineering

As patching becomes more routine and secure coding practices are adopted more, the chances of getting 1337H4XX are reducing significantly. However, as we all know, there's no patch for stupidity or admin oversight. Social engineering will always be a relevant skill; it's telling that most companies don't test for it because they know that there's nothing that can be done. For the time being anyway, the singularity is always around the next corner and I, for one, welcome our new robot overlords.

The ability to convince other people to do something on your behalf is not to be sniffed at. It's also pretty difficult to practice. I'd love to give you a method of conning people into doing things in a controlled environment, but it's pretty difficult to do. Once a person is aware of the potential for them to be socially engineered, they act differently and it defeats the point of the test. You may argue that security personnel, who are usually the people we want to...

Scenario 1 – maxss your haxss

This scenario will allow you to create a very basic application that will accept input from a user and return it in the HTML code of another page. This should indicate to you that it's likely to be a cross-site scripting (XSS) attack. I'm going to give you some very boring-looking code, and you can dress it up later if you wish.

A section on attacks against users and social engineering wouldn't be complete without even a brief mention of XSS—that most basic and pervasive of attacks. The merest mention of vulnerability to this attack used to make information security officers sweat; now they barely nod. It is accepted that one of the first things that a hacker or computer deviant learns is how to perform XSS. For those that don't know, XSS is the act of forcing JavaScript into the HTML of a web page and using it to perform actions. It can be used to deface websites and generally cause mischief and upset; however, its most widespread use is to steal unprotected...

Scenario 2 – social engineering: do no evil

The difficulty with social engineering training is that one of the core reasons social engineering works is that no one believes it will happen to them. Very few people believe that anyone is capable of talking them out of their millions (or thousands or whatever) but it does get done. They think 419 scammers and the like, while really social engineers look just like normal people with normal jobs and normal lives; they just occasionally talk their way into a little bit extra. This lack of belief from the majority of people makes social engineering training actually easier to do in a live environment than in a test environment, as a role player will know they are to be social engineered and will hold onto whatever secret information they have with tooth and claw. There are, however, some methods of simulating a live environment.

It's important to note that it is incredibly unethical to social engineer private information out of people for further...

Scenario 3 – hunting rabbits

A rabbit trail is a simulated chain of unintentional leaks and links inevitably leading to something secret. It's designed to test the ability of open source intelligence (OSINT) operatives to find out information about their targets and their target's intended activities. It can also be used to simulate the reconnaissance phase of a penetration test. During specific types of tests, it may be necessary to find out about individuals involved in the target company, and when assigned this task, few know what to do short of googling the individual's name. There's a great deal of skill that goes into effectively finding people on the Internet and uncovering their secrets (OkCupid is mild for the kind of people the world holds).

We're going to create a chain of social media accounts and open pages to lead the testers from one location to a completely different one that contains our key. We'll also set some ground rules for this kind of test. It's important that when...

Scenario 4 – I am a Stegosaurus

Steganography is the practice of hiding information. It can be performed through a variety of means. The historic method that gets quoted a lot comes from the Roman Empire. Commanders would tattoo the heads of soldiers sent to escort diplomats with secret messages to be relayed at the other end. As the journeys were long and would take several months, the hair would grow back, hiding the message. I can only assume that until their hair reached a respectable length, they just wore hats or something.

This scenario isn't really a scenario. It's more of a set of ways to hide information in pictures and audio that can be used in other scenarios, notably in the rabbit trail. We are going to cover the use of some tools and a few other tips.

Visual steganography

There are a few easy ways to hide content in images, the simplest and most obvious of which is to edit the Exif data. The Exif data is extra information that sits within a file detailing various things, for example...

Exploitation guides

The following are exploit guides for the scenarios created in this chapter. These are guidelines and there are more ways to exploit the vulnerabilities.

Scenario 1 – cookie theft for fun and profit

The brief provided for this exploitation guide is assumed to be: steal the admin user's cookie from <IP>/input.php. Perform the following steps for this scenario:

1. The first thing to do is to the browse the website. We can see that we have an input box.

2. The brief says, "steal a cookie", so we can assume this is a cross-site scripting attack. We can add test messages to see whether the input is returned to us. As it doesn't return the input, we must assume that it's being passed to the admin somewhere as the brief suggests that an admin can see it. This means that trying the standard <script>alert(1);</script> code won't work.

3. However, we can make a call back to our own server with cross-site scripting. This is achieved by first enabling Apache on our server with...

Summary

In this chapter, we created cross-site scriptable code, designed tenuous links across the Internet, challenged some people best left inside to go outdoors, and generally covered skills that right-minded people wouldn't teach hackers. We established ground rules for these types of tests and hopefully hammered home that ethics before hacks is the right way to go. Your testers, having completed these tests, should feel comfortable performing attacks against users and prepared to at least start forays into the world of social engineering. Past a certain point though, it can only be done live.

The next chapter covers cryptography. I'm not a cryptographer by trade, so don't expect to see too many algorithms explained or bit-wise calculations. As with most things in this book, it'll be raw, unfiltered hackery with some bad commentary thrown in for good measure. We'll cover some ways to encode your data to mask it at least slightly, some outdated crypto-methods, and maybe one or two broken...