Information Security Today Home

New Books

Security Software Development: Assessing and Managing Security Risks
Architecting Secure Software Systems
Mobile Device Security: A Comprehensive Guide to Securing Your Information in a Moving World
Information Technology Control and Audit, Third Edition
Building an Effective Information Security Policy Architecture

Exploiting Software Vulnerabilities

Maura A. Van der Linden

Once you understand the identity, goals, and motivations of potential attackers, you need to understand the various ways for software exploits to be delivered as an attack and some of the issues that surround those delivery mechanisms. The most clever and talented of attackers with an innovative exploit still have to find a way to get that exploit to the systems they wish to attack. Because these are only the delivery mechanisms, the actual content delivered varies greatly.


A Trojan in software security means a seemingly attractive or innocuous program that hides malicious software inside. Trojans aren't typically capable of spreading themselves, but instead they require a separate method of distribution, and that usually consists of the file containing the Trojan being transmitted to potential victims using methods like e-mail, instant messaging, IRC, ICQ, etc. When the potential victim opens the file, the Trojan is installed. Trojans can also be staged on download sites and disguised as utility programs, games, etc., and the victim is tricked into downloading them because they look like a useful program the victim might want to use.

Trojan Horse Virus
This is a hybrid between a Trojan and a virus. Most Trojan horse viruses infect like a Trojan in that they need to be run or executed by the victim (still typically by opening a file), and then the virus behavior takes over and the Trojan horse virus automatically spreads itself to other systems. So, it spreads like a biological virus. Sometimes it sends itself to your address book or your IM contact list, etc.


A computer virus is a program, typically malicious, that reproduces by adding itself to other programs, including those belonging to the operating system. It cannot run independently but needs a "host" program to be run in order to activate it. The source of the name is a reference to biological viruses that are not considered alive in the usual sense and can't reproduce independently, but rather invades host cells and corrupts them into producing more viruses.

Boot Sector Viruses
A boot sector virus is one that infects the boot sector of hard disks, floppy disks, CDs, DVDs, USB drives, etc. Despite the infection being located in the boot sector, these do not require that the victims boot their system from the infected media to infect it. These viruses often stay resident in memory and infect floppies and other media when they are being written by the infected system. Once relatively common, such viruses are becoming ever more rare as the use of floppy disks continues to decrease.

Master Boot Record (MBR) Viruses
A master boot record virus behaves very similarly to the boot sector viruses, except that it infects the master boot record instead of the boot sector.

File Infector Viruses
The file infector viruses infect executable files such as .EXE and .COM files. Some of these viruses will stay resident in memory and carry on continuously infecting files, but others only infect the system when their host file is executed.

Macro Viruses
A macro virus uses some sort of scripting language, often Visual Basic or JavaScript, and infects types of datafiles from applications that support that scripting language. This is most well known from the incidents of infections among the various datafiles of Microsoft Office suite.

Multi-Partite Virus
This is simply a virus that exhibits the characteristics of more than one of the types of viruses.


A worm is a program that can copy a fully functional version of itself to other machines across a network without intervention. It doesn't usually require another program in order to run, but worms can, and do, sometimes hide behind other programs. The source of the name is a derivative of "tapeworm," which is a parasitic organism that lives inside a host and saps the host's resources in order to maintain itself.

Logic Bomb

This is a piece of code that sits and waits for some piece of program logic to be activated and then activates the bomb's payload. Date bombs are the most common type of logic bomb, but the trigger could be anything from a message to the deletion of a file or directory, or a file size. Logic bombs don't replicate themselves but instead have to be specifically targeted to the recipient. These are sometimes attached to a delivery mechanism that will install the logic bomb on a user's system. Although this is really a trigger rather than a delivery mechanism or method of spreading, I've listed it here because it's generally delivered with one of the other listed delivery mechanisms.

The Role of Social Engineering

There are probably as many definitions of what "social engineering" is as there are security specialists, maybe more. My own favorite definition is that social engineering is a clever manipulation of the natural human tendency to trust in order to persuade people to do as the manipulator wishes them to.

All trust is misplaced. It's a human tendency to grant trust far too easily, and that makes the human factor the weakest link in the chain of security. The goals of social engineering, as applied to software security, are similar to that of the various programs and tools - to gain unauthorized access to systems or information to commit data theft, disruption, industrial espionage, etc.

Social engineering plays a huge role in many security exploits, often as the initial attack vector. There are multiple psychological reasons why social engineering is so successful and most of them simply boil down to aspects of human nature. The quandary with social engineering is that user education only goes so far, and you can't issue a patch for people to insure they cease whatever risky behaviors they have been exhibiting or to increase their skepticism.

At its core, social engineering is really a confidence (con) game. It's an age-old criminal approach that has now moved into the electronic age with a vengeance and at great benefit to the con artist. The costs to run the con game are far less. The chances of the con artists getting caught are much less because the victims and potential victims don't actually meet the con artists face to face. In fact, they may not even be in the same country as their victims. There is a much larger pool of potential victims that are far easier to approach, and it only takes one or two potential victims to fall for the con to make it all worthwhile.

Social engineering attacks and, really, all security attacks, are not usually a single event that strikes like a bolt from the blue. The attack pattern may include a succession of more and more complex attacks that serve to gather information or probe for weaknesses and lead up to the culminating major attack. If you think of social engineering in particular, you can see that even the release of minor amounts of information that are not seemingly of much use on their own could be used later to form and carry out other information gathering attacks or even damaging attacks.

Imagine that someone persuades you to give him the last four digits of your social security number to "verify your identity," and then you get a call from a very convincing man who says he is from your bank and who tells you that the bank has intercepted a case of suspected identity theft using the social security number it has on file for you. He tells you the last four digits and then asks you to repeat the entire number so he can verify that your number is indeed the one being used and the bank can take action. By the end of the call, if you've fallen for the con game, the con man has your entire social security number and certainly already has your name, address, and phone number. Now the con man has a set of data that can result in identity theft. There are two basic types of social engineering - active and passive.

Active Attacks
In active social engineering, the con artist has direct contact with the potential victim. This could take the form of telephoning the victims to talk them into revealing a password or other private information, and in many ways this resembles one of the more classic telephone scams. This could also be an in-person attack where the con artist shows up at the office door and pretends to be a representative of your company's software vendor, and needs to install an emergency patch on your system. Almost all active attacks depend on one or more of the following methods to gain the information and access the con artist needs:

  • Authority - We are all taught to respect and bow to authority.
  • Befriending - It's human nature to want to trust, and especially to trust those we feel are, or are becoming, friends.
  • Blackmail - We've all done wrong or an impression can be created that we've done wrong, even if it's not actually true.
  • Deception - Flat out lying is always a staple.
  • Flattery - Who doesn't want to think they are special or somehow better?
  • Impersonation - Most often combined with another method, especially authority. Just pretending to be someone they aren't or to represent someone they don't.
  • Intimidation - When in doubt, play on people's fears by intimidating them.
  • Pressure - Don't want to give you any time to think so you're less likely to see through the con.
  • Sympathy - This applies to both seeking and giving sympathy. Who doesn't want to help someone who is in need or in trouble? Who doesn't soften toward someone who seems to sympathize with our own predicament?

Passive Attacks
Passive attacks attempt to obtain information with stealth. They tend to be carried out in bulk so as to maximize the return. After all, why send one or two e-mails (or even fifteen or twenty) when you can send tens of thousands for not much more of an investment? This is true especially if you are using someone else's e-mail server or account.

These passive attacks use some of the same methods as the active attacks but aren't nearly as specific as the latter. They don't have as high a percentage of success, but with the quantity involved and the relative inexpensiveness, only a few successes are needed for them to pay off. They are also more anonymous than the active attacks.

Passive attacks include items like phishing, where many thousands of emails are sent to potential victims claiming that the person needs to change a password or verify a credit card number, and includes a helpful link to click on to do so. This link typically leads to a look-alike site, many of which are quite cleverly done, but entering data on these look-alike sites is the equivalent to handing the attacker your information.

A lot of these links are titled in a way intended to conceal the truth of their origin or exact nature. The hyperlink title may be "eBay Password Change," but if the potential victim hovers over the text to see the URL, they may be able to tell that it doesn't even have a similarity to eBay. Some of the URLs themselves are designed to deceive. A phisher may use a domain very similar to that of the legitimate entity they are masquerading as, for example, "" These links are, however, similar enough to deceive the potential victim who only gives it a quick glance.

Lately, I've even seen some look-alike sites place a false "lock" symbol on their web page to pretend to be an HTTPS site. Because users are taught to look for this lock symbol as a sign that a site is safe, they may see that lock and never even look at the address and see it's not an HTTPS site at all, but rather an HTTP site using a bitmap to deceive them. There is also a play on trust if the e-mail you get happens to claim to be from a company or entity you already use. Most of the time, that is merely a random event because phishing e-mails tend to be "blanket" mails rather than specifically targeted e-mails. E-mail headers are notoriously easy to spoof, but despite that fact being rather well known, many people still believe that the e-mail they receive is indeed from who it claims to be from.

These passive attacks can also include pop-ups and redirects that the potential victim can't verify the source of and which may lead them to believe that they need to enter their name and password again, but that information is really being sent to the phisher instead.

Urban Legends
Although not technically a security risk, a look at how urban legends begin and are subsequently spread is an interesting study in some of the aspects of social engineering. Urban legends are cautionary tales couched as tales of actual events that always seem to happen to someone only slightly removed from the alleged writer. Some are true and some are fictitious, but they all share the fact that they play on human fears. Most urban legends are also modern tales - supposedly taking place relatively recently.

These are often spread in e-mail and are typically forwarded to us by a friend, family member, coworker, or online acquaintance. I often see them spread in newsgroups and e-mail lists as well. Although many of these tales seem dubious at best, a surprising number of people will look at the e-mail and immediately begin forwarding them to their friends and e-mail lists without ever attempting to verify the information they contain.

When these people are confronted with information that the e-mail they forwarded is an urban legend and that they should check their information before passing it on, they almost inevitably became defensive. They immediately claim that it has to be true because it came from so-and-so who would never send them something that isn't true. Their defensiveness seems to be dual edged - part "how dare I cast doubt on the integrity of so-and-so" and part feeling embarrassed that they fell for the story and didn't ask questions.

However, the point doesn't seem to get through that I am not casting doubt on so-and-so's integrity. I'm sure that the people who forwarded that mail, all the way up the line to whoever first received it from the original author, sincerely believed that it was true and the cautionary tale, picture, warning, etc., should be passed on to their friends and relatives. Each person in the chain trusted the information's source. The motives of the original author, however, are often a different matter.

All trust is misplaced. Just because someone you know forwards an email to you, never trust that the e-mail is true.

Nigerian (419) Scams
Another case study in social engineering is that of the Nigerian Scam -also called the 419 Scam or the Nigerian Advance Fee Fraud. The 419 refers to a section of the Nigerian penal code that applies to these types of cases. Various sources claim different dates for the start of this fraud - ranging form the late 1970s to the early 1990s. They do agree that it began with paper mail and fax but migrated to e-mail and the Internet relatively quickly. It is now sent almost exclusively by e-mail with occasional cases of instant messenger transmissions.

This well-known and well-publicized con game typically claims that it is from a person or a representative of a person who needs help to transfer large sums of money out of the country or to claim inheritances. There are numerous variations that have different stories such as being the beneficiary of an estate or needing help to claim an unclaimed estate. These are also not at all limited to Nigeria anymore.

If the potential victim asks questions, the con artist always has an answer, typically very apologetic and heartfelt. The con artist will continue to string the potential victim along with a variety of ploys until the potential victim either says no or gives in. Once the victim agrees to whatever deal that particular con artist is trying to pull off, the victim is sent official-looking documents or e-mails, then delays are claimed, and the perpetrators begin to request a transfer of a relatively small amount of money (in comparison to the promised payoff) to do things like bribe officials, set up an appropriate bank account in the local country, etc. As long as the victim pays, the delays and more additional costs are added while the perpetrators keep the carrot of the large payoff in sight. However, the promised payoff will never happen because the funds just do not exist.

All trust is misplaced. If a deal appears to be too good to be true, never trust the sincerity or honesty of the person brokering the deal. The entire 419 scam is a con game - a social engineering scam at its purest.

Lost in the Cracks

A prime place to look for security bugs is in all the "cracks" in and around your product. I consider a crack to be anywhere that control is passed or data is moved between separate functions, modules, applications, or even hardware. You'll see that this is also an area that is focused on in the section on threat modeling. In a way this also goes back to trust. If data has been brought into the system somehow, an implicit trust exists that this data has been validated somehow by whatever brought it into the system in the first place.

All trust is misplaced. Data being passed, even between subsystems of the same project, is not inherently trustworthy. This is especially true as programs, operating systems, and even accessories become more and more interconnected. There may or may not actually be any way to tell how any piece of data entered the system.

Vulnerabilities are also found in between areas of functionality in the same application or product. One module may take data from the UI and pass it to an application programming interface (API) to process. The API doesn't check the incoming data before using it because it trusts that the UI has validated the data and only passed it on to the API after validation. However, if the data was sent to the API by a method other than the UI, that data may be untrustworthy for multiple reasons, including:

  • Business logic rules violated
  • Data boundaries not enforced
  • Unexpected data passed through
  • Source may be spoofed or otherwise untrustworthy

Vulnerabilities are often found in areas of interface between different applications, products, or hardware. One system may take direct user input and save it in a file that is then consumed by another system. In this case the secondary system may not check the file before using it because the first system has been trusted to produce only valid and usable files.

However, the file that was consumed by the second system may be untrustworthy for multiple reasons both inside and outside of the control of the first system. Some examples are:

  • Formats not respected
  • File crafted with malicious code
  • Version changes
  • File modified before use
  • Generator of file unknown

About the Author

Testing Code Security From Testing Code Security by Maura A. Van der Linden . New York: Auerbach Publications, 2007.
Subscribe to Information Security Today

Powered by VerticalResponse

© Copyright 2009-2010 Auerbach Publications