INSIGHTS | April 10, 2013

What Would MacGyver Do?

By Sofiane Talmat

“The great thing about a map: it gets you in and out of places in a lot different ways.” – MacGyver

When I was young I was a big fan of the American TV show, MacGyver. Every week I tuned in to see how MacGyver would build some truly incredible things with very basic and unexpected materials — even if some of his solutions were hard to believe. For example, in one episode MacGyver built a futuristic motorized heat-seeking gun using only a set of batteries, an electric mixer, a rubber band, a serving cart, and half a suit of armor.

From that time I always kept the “What would MacGyver do?” spirit in my thinking. On the other hand I think I was “destined” to be an IT guy, and particularly in the security field, where we don’t have quite the same variety of materials to craft our solutions.

But the “What would MacGyver do?” frame of mind helped me figure out a simple way to completely “own” a network environment in a MacGyver sort of way using just a small set of steps, including:

Exploiting a bad use of tools.
A small piece of social engineering.
Some creativity.
A small number of manual configuration changes..

I’ll relate how I lucked into this opportunity, how easy it can be to exploit certain circumstances, and especially how easy it would be to use a similar technique to gain domain administrator access for a company network.

The whole situation was due to the way helpdesk support was provided at the company I was working for. For security reasons non-administrative domain users were prevented from installing software on their desktops. So when I tried to install a small software application I received a very respectful “access denied” message. I felt a bit annoyed by this but still wanted my application, so I called the helpdesk and asked them to finish the installation remotely for me.

The helpdesk person was amenable, so I gave him my machine name and soon saw a pop-up window indicating that someone had connected to my machine and was interacting with my desktop.

My first impression was “Oh cool, this helpdesk is responsive and soon my software will be installed and I can finally start my project.”

But when I thought about this a bit more I started to wonder how the helpdesk person could install my software since he was trying to do so with my user privileges and desktop session rather than logging me out and connecting as an administrator.

And here we arrive at our first Act.

Act #1: Bad use of tools

Everything became clear when the helpdesk guy emulated a Ctrl+Alt+Delete combination that brings up the Windows menu and its awesome Switch User option.

The helpdesk guy clicked the Switch User option and here I saw some magic — namely the support guy logging in right before my eyes with the local Administrator account.

Picture this: the support guy was typing in the password directly in front of my eyes. Even though I am an IT guy this was the first time I ever saw a support person interacting live with the Windows login screen. I wished I could see or intercept the password, but unfortunately I only saw ugly black dots in the password dialog box.

At that moment I felt frustrated, because I realized how close I was to having the local administrator password. But how could I get it?

The magic became clearer when the support guy logged in as an administrator on the machine and I was able to see him interacting with the desktop. That really made my day.

And then something even more magnificent happened while I was watching: for some undefined reason the support guy encountered a Windows session error. He had no choice but to log out, which he did, and then he logged in again with the Domain Administrator account … again right before my eyes!

(I don’t have a domain lab set up right now, so I can’t duplicate the screen image, but I am sure you can imagine the login window, which would look just like the one above except that it would include the domain name.)

When he logged in as the domain administrator I saw another nice desktop and the helpdesk guy interacting with my machine right in front of my eyes as the domain admin.

This is when I had a devious idea: I moved my mouse one millimeter and it moved while this guy was installing my software. At this point we arrive at the second Act.

Act #2: Some MacGyver magic

I asked myself, what if I did the following:

Unplug the network cable (I could have taken control of the mouse instead, but that would have aroused suspicion).
Stop the DameWare service that is providing access to the support guy.
Reconnect the network cable.
Create a new domain admin account (since the domain administrator is the operative account on my computer).
Restart the DameWare service.
Log out of the machine.

By completing these six steps that wouldn’t take more than two minutes I could have assumed domain administrator privileges for the entire company.
Let’s recap the formula for this awesome sauce:

1. Bad use of tools: It was totally wrong for the help desk person to open a domain admin session directly under the user’s eyes and giving him the opportunity to take control of the session.

2. A small piece of social engineering: Just call the support desk and ask them to install some software for you.

3. A small amount of finagling on your part: Use the following steps when the help desk person logs in to push him to log in as Domain Admin:

• Unplug the network cable (1 second).
• Change the local administrator password (7 seconds).
• Log out (2 seconds).
• Plug the network cable back in (1 second).

4. Another small piece of social engineering: Call the support person back and blame Microsoft Windows for a crash. Cross your fingers that after he is unable to login as local admin (because you changed the password) he will instead login as a domain administrator.

5. Some more finagling on your part: Do the same steps defined in step 3 to create a new domain admin account.

6. Success: Enjoy being a domain administrator for the company.

Final Act: Conclusion

At the beginning of my IT security career I was a bit skeptical of the magic of social engineering. But through the years I have learned that social engineering still works and will always work. Even if the social engineering involves the tiniest and most basic request, if you combine social engineering with some imagination you can own a huge company. And if you are conducting a pentest you don’t always have to rely exclusively on your technical expertise in pentesting. You can draw on your imagination and creativity to build a powerful weapon using small and basic tools …. just like MacGyver.

INSIGHTS | December 7, 2011

Automating Social Engineering: Part Three

By Matias Brutti

PHASE 2: Ruses

Once we have enough information about the employees and company in question, we can begin to make some sense of the information and start crafting our ruses. It is worth noting that this stage currently does not have a lot of since it does require a lot of human intuition and information processing. Certainly as we continue developing the tool we will be able to automate more and create some decision making systems capable of creating useful ruses, but for now a key factor of this phase is to look for key ideas and useful information in order to help us generate our attack as realistic and trustworthy as possible.

As previously mentioned, this stage it is not fully automated. Still, EMaily provides several examples and template emails that could help automate some ruses. Having said this, if we want to have high success rates with our attacks, it is still clear that testers will need to craft their own custom built email ruses depending on the data gathered in the previous phase.

Before we move on, there are a few things that are worth discussing before we dig down to the technical tools themselves. Social engineering is about abusing people and abusing their needs, senses, ideas, likes, dislikes, fears, etc. It is basically about selling a good lie- good enough that even you would believe it.

Depending on the feeling or idea we are trying to generate or trigger, we need to use a different ruse or combination of ruses. For example, the list below shows a short list of ruses ordered by specific feeling they try to trigger.

Ruses Examples:

General Templates:

· Facebook invite
· Twitter invite
· Linkedin Invite
· Mail cannot be delivered.
· Etc.

Fear Oriented Templates:

· Virus Found
· Compliance updates
· Popular thread in the news.
· Etc.

Needs or Likes Templates:

· Win an iPad.
· Internships or new internal available positions.
· General Company party.
· New Corporate discounts.
· Etc.

Gossip or Need to Know Templates:

· Latest financial data
· Layoff for next month
· Internal memorandum.
· Etc.

Let’s look at a couple real life examples of such ruses:

Source:

In this case, the person copied a friendship request from Facebook. We can easily change the links, and redirect them to a fake Facebook website, among many other things. Furthermore, we could use other techniques we will discuss later to actually perform internal egressing firewall rules scans by adding fake images to the email.

PHASE 3: Internal Information gathering: Software and Physical networks.

Once we have a target list (emails, names, etc.) and a ruse, we need to begin gathering information about the internal network and infrastructure from within. One possible way of doing this is by sending one or more rounds of emails using specially crafted html templates consisting of several image tags pointing to different ports, as it is shown on the figure below.

EMaily is a command line tool created to send multiple template emails using several servers at the same time. It contains many templates, but users can create their own templates and populate them as needed. It is worth noting that EMaily is also an expandable ruby library that can be called from any other ruby script or application.

Once we have a list of ports we want to scan from an internal perspective, we do not need to generate the entire list. EMaily will automatically generate the list and populated with the corresponding email using the template system as it is shown on the following code snippet, by simply using the %%payload[port 1, … ,port n]%%

You may ask, “but what is to gain from generating this random set of images?” The short answer is lots of information. We will not only be able to confirm that the firewall in the company we are trying to attack is not properly filtering the particular port, but also whenever an application makes an HTTP request, it sends lots of useful information back to the attacker.

As we can see from the output generated by EMaily, this will test egressing rules, obtain information such as operating system, email client used, IP addresses, etc…

Basically, Emaily works as a reverse scanner, allowing people to send their “payloads” to victims, which will render the images and will generate a list of request that will be served by the Emaily web server process, allowing us to gather all kinds of information, as it is shown in the figure below.

Now we have emails and hopefully tons of information tight to each address such as egressing rules, operating system name and version, browser or mail client name and version, mobile phone information, etc. We have enough to start using the more interesting ruses and correctly targeting the victims using the correct payloads (since we know the OS and mail client version), and open ports allowing us to connect back to us. In the next phase we will discuss how to use all that information to successfully compromise the company being tested.

This is part three of a four-part social engineering post. The next and final entry will discuss compromising machines.

INSIGHTS | November 8, 2011

Automating Social Engineering: Part Two

By Matias Brutti

As with any other type of penetration test, we need to gather information. The only difference here is that instead of looking for operating system types, software versions, and vulnerabilities, we’re searching for information about the company, their employees, their social networking presence, et cetera.

Given that we’re performing an assessment from a corporate perspective, there are some limitations with regard to privacy and employees’ private life, but the truth is that real attackers won’t abide by such limitations. So, you should assume that any information made public or available on the Internet will be considered usable. (Disclosure: consultants/employees should talk to your client/employer and lawyers to define the scope for any penetration test prior to information gathering.)

As stated in the comic, information gathering is really simple and there’s only one rule: There is never enough information; the more you have the better. Everything is relevant in some way or another—everything from company icons, images, and documents all they way down to where an employee went to dinner last week and with whom.

Luckily for us, Mark Zuckerberg (creator of Facebook) and corporate America have made people’s lives public and easy to follow by convincing them that they’re supposed to forget about privacy and share as much information as they can with as many people and services as they can, because it is “good” for them.

The type of data we need depends on the type of attack we’re performing. Given that we are currently discussing social engineering assessments in a corporate context, we will surely need to gather corporate email accounts and plenty of names. There are many tools capable of performing Open Source Intelligence (OSINT) including the Harverster, Maltego, and, of course, ESearchy.

Esearchy is project that I began a few years go as a small Ruby library with a proof-of-concept CLI tool capable of searching the internet for email addresses and people from a specific domain or company. Currently, the supported search plug-ins include but are not limited to:

Search Engines

– Google

– Bing

– Yahoo

– AltaVista

Social Engines

– LinkedIn

– Google Profiles

– Naymz

– Classmates

– Spoke

– Google+

Other Engines

– PGP servers

– Usenets

– GoogleGroups Search

– Spider

– LDAP

In addition to that, ESearchy is capable of downloading—upon request—several types of files and searches their contents for emails. File types supported include but are not limited to:

PDF

DOC

DOCX

ODP

ODS

ODB

XLSX

PPTX

TXT

ODT

ASN

With this simple introduction, we’re now going to install the tool and test a few of the information gathering concepts described above. ESearchy is currently hosted as a Ruby gem at https://rubygems.org, so by fetching the gem in any Linux, OSX, or Windows environment, it will install all the necessary dependencies and binaries.

Note: Ubuntu users will need to add the Ruby path to their $PATH in order to run esearchy.

$> sudo gem install esearchy

Once ESearchy is installed, we are ready to start gathering information. As previously mentioned, the application supports several types of searches using the esearchy CLI command and/or by creating custom scripts using the ESearchy library—that is, they requireesearchy.

Using the tool is straightforward; for example:

$> esearchy -q @company.com –enable-google –enable-pgp

$> esearchy -q @company.com -c “Company Inc” –enable-linkedin

For a full description on the engines supported and all the other possible ESearchy features, please refer to the help command in the ESearchy tool itself, which is:

esearchy –h

Despite now having a list of email addresses related to the company in question, it’s a good idea to continue gathering as much data as possible. We should continue performing searches; we may need to find information regarding the DNS servers and mail servers, as well as other information that is usually collected as part of a standard penetration test. ESearchy currently does not perform these search types , but that functionality will be supported in future versions as separate, standalone tool.

Last but not least, a good way to confirm (and possibly obtain more) email addresses involves checking the SMTP server for vulnerabilities (such as information disclosures) using VRFY or EXPN, et cetera. If present, this information should allow us to confirm our email addresses and possibly even acquire more.

This is part two of a four-part social engineering post. The next entry will discuss using ruses to gather more intrusive information about the internal network.

INSIGHTS | November 1, 2011

Automating Social Engineering: Part One

By Matias Brutti

since the original conceptualization of computer security, and perhaps even before, social engineering has been in existence. One could say that social engineering began when societies began, whether it was realized or not. It is now time to give some of this work to scripts and applications to make it a little more interesting…

As the years passed in the computer security community, network penetration became more and more necessary, but computers were not the only thing getting compromised. Social engineering was part of the hacker subculture, but it was never a service offered by companies.

In recent years—largely due to the fact that they are doing more business online—companies have become more security aware and networks have become more “secure.” Finding remote vulnerabilities on Internet-facing networks that can be exploited is becoming more and more difficult due, in part, to such realities as the increased safety of operating systems, the standardization of automated patching, and the hiring of security personnel. Having said that, many would argue, “What about corporate networks? Do companies secure their networks the same way they secure production servers?”

The short answer, in my experience, is no. Companies have different approaches to and views about internal and external networks: they often don’t think about internal threats. They fail to understand that internal threats don’t necessarily mean an internal employee going rogue; it could easily be an attacker with access to the corporate network who is attacking it from an internal perspective.

For thousands of reasons and excuses, workstations and internal servers are never kept as secure as external servers: they usually lack up-to-date patching schedules, and are loosely and improperly configured. On top of this already insecure network are the human users, which includes IT admins, engineers, and developers. Your employees.
Employees: A group of people who can perform amazing tasks such as infect their computer in less than two hours, install buggy freeware apps, and open all those links that come with explicit warnings such as DO NOT OPEN – VIRUS FOUND.

To make a story short, hackers, spammers, botnets, criminal organizations, and all the other “bad guys” constantly take advantage of the weakest link in all types of security: The Human Factor, or human stupidity. The reality is, it doesn’t matter how much you harden a computer, you can rely on a human to find a way to compromise that computer.

Social engineers are acutely aware of how human psychology operates, and they are well aware of human needs and feelings. Consequently, they will use and abuse these “issues” to craft their ruses and attacks.
Additionally, due to the rise of social networks in personal and corporate environments, people are constantly checking their Facebook, LinkedIn, email, Twitter, Google+, and Gmail—everyone wants to know what is going on within their company. The 21st century human has an addictive need to be informed in real-time. It is human nature to communicate and interact with people, and to be as informed as you can about your environment. Deep down, we all love to gossip.
Before we even start, it’s worth noting that client-side attacks, phishing attacks, social engineering attacks, and social engineering penetration tests have existed for a long time. Due to the ever-tightening security around networking in recent years on one hand, and the expansion and rapid growth of social networks on the other, these attacks have gained strength, and new attack types are appearing daily, abusing the communication channels humans are working so hard to create.

Standard attack types:
• Classic email-driven social engineering attacks
• Website phishing attacks
• Targeted social hacking (Facebook, LinkedIn, Google+, et cetera)
• Physical social engineering
In my next three posts, I will be walking through the steps to perform a social engineering attack from a corporate point of view as a security consultant. I’ll begin with information gathering, the indispensible “homework phase” that every social engineering engagement should begin with.