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.

This post describes the Windows vulnerability I showed during my Black Hat USA 2011 workshop “Easy and Quick Vulnerability Hunting in Windows”.

The Windows security update for Visual C++ 2005 SP1 Redistributable Package (MS11-025) is a security patch for a binary planting vulnerability. This kind of vulnerability occurs when someone opens or executes a file and this file (or the application used to open the file) has dependencies (like DLL files) that will be loaded and executed from the current folder or other folders than can be attacker controlled. This particular vulnerability allows an attacker to execute arbitrary code by tricking a victim user into opening a file from a network share. When the victim user opens the file, the application associated with the file is executed, and an attacker-crafted DLL file is loaded and executed by the application.

It’s either funny or scary (you choose) that the Windows security update meant to fix the above-described vulnerability is also vulnerable to the same kind of vulnerability it fixes, and it can be exploited to elevate privileges.

When installing the security update on 64-bit Windows 7, the file vcredist_x64.exe is downloaded and then executed under the System account (the most powerful Windows account, it has full privileges) with some command line options:

C:\Windows\SoftwareDistribution\Download\Install\vcredist_x64.exe" /q:a /c:"msiexec /i vcredist.msi /qn

After being run, vcredist_x64.exe tries to launch the msiexec.exe process from the C:\Windows\Temp\IXP000.TMP\ temporary folder, which is where the vcredist.msi used in the command line option is located, but because msiexec.exe doesn’t exist there, vcredist_x64.exe will fail to run it. Then vcredist_x64.exe launches msiexec.exe from C:\Windows\SysWOW64, where msiexec.exe is located by default on 64-bit Windows 7.

There is an obvious vulnerability and it can be exploited by low-privilege Windows users since the C:\Windows\Temp\IXP000.TMP\ temporary folder DACL has write permissions to the Users group, so any Windows user can place in that temporary folder a file named msiexec.exe and execute arbitrary code under the System account when they attempt to install the vulnerable security update.

While this is an interesting vulnerability, it’s not critical at all. First, to be vulnerable you have to have the vulnerable package installed and without the security update applied. Second, for an attacker to exploit this vulnerability and elevate privileges, the option “Allow all users to install updates on this computer” must be enabled. This option is enabled on some systems, depending on configuration settings about how Windows updates are installed.

This presents an interesting paradox in that you're vulnerable if you haven’t applied the vulnerable patch and you're not vulnerable if you have applied the vulnerable patch. This means that the patch for the vulnerable patch is the vulnerable patch itself.

The following links provide some more technical details and video demonstrations about this vulnerability and how it can be exploited:

• 11 Win Update Vulnerability

• 12 Win Update Temp Folder Permissions

• 13 Win Update Exploit Code

• 14 Win Update exploiting

References

• Microsoft

• Microsoft Support

View the slides here.
View video demos here.