Application Attack Vectors

Before we go into the actual vulnerabilities, or intrusion points, we should discuss attack vectors. Attack vectors consider both the targets of attacks, and the strategy or methodology an attacker or miscreant uses to exploit the software systems in use. In some cases, the miscreant doesn't have to break in or get access to your information in order to cause damage.

Some of the common attack vectors are

• Information disclosure/information capture

• Remote logins/ unprotected user accounts

• Network services and vulnerable processes

• Vulnerable local processes

• Unprotected/exploitable privileged users

• Unprotected files

Information Disclosure/Information Capture

The first thing a miscreant will do is determine what systems you have, what is running on these systems, and what types of services are offered as entry points. Example services may include domain name system (DNS) servers, mail servers, database servers, application services, or web servers/applications/content.

Before a miscreant may attack these services, he or she needs to know what type of service it is and often how it has been configured. Additionally, this often includes determining what platform or operating system the service is running on.

In some cases, this information is easy to obtain; in other cases it may be much harder. The harder you make it to determine, (in many cases) the more time you have to fix problems once they are discovered and before they can be exploited. Determining the platform and applications that are available, which is often called fingerprinting, may be very simple for some services. Often all that is required (for example, with many web servers and mail servers) is to open a socket connection directly to the port the service or program is bound to, issue a known or common command, and observe the response. The service often reveals the program name, version number, and in many cases the platform or operating system and processor/architecture. In most cases, display of this information was designed to be helpful to legitimate applications and network services that need to talk to each other, and as a way for developers to debug or identify which software was running on a particular system. As you will see, this information also helps malicious users.

For example, look at the output of the connection to xyzcompany's (real company name hidden to protect the innocent) mail server (mail.xyzcompany.dom), as compared with the output from a better protected local mail server here at our office (or somewhere in cyberspace ).

 telnet mail.xyzcompany.dom 25 220 mail.xyzcompany.dom ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2653.13) ready ehlo leak 250 xyz-pdc.corp.xyzcompany.com Hello [somehost.example.com] 250-XEXCH50 250-HELP 250-ETRN 250-DSN 250-SIZE 0 250-AUTH LOGIN 250 AUTH=LOGIN 

Next, follow the connection to our mail relay system (for inbound SMTP mail transport).

 telnet inbound.postal.example.com 25 220 mx.example.com - Example MTA is ready for action; fire away. (got TLS?) ehlo leak 250-mx.example.com 250-PIPELINING 250-SIZE 51200000 250-ETRN 250-STARTTLS 250-XVERP 250 8BITMIME 

See the differences? You can see from the first listing, xyzcompany's mail server is running (or purports to be running) Microsoft Exchange Internet Mail Service. You can tell further from the version number listed on the first line (the "I'm here, what do you want?" response) that this is the version that comes with Microsoft Exchange 5.5a pretty old version by Microsoft's standards. It even tells you which subversion or patch/ hotfix /service pack version it likely is. Further, because Microsoft only writes "server software" for its own operating system platforms (primarily Windows-based systems), you can almost guarantee this system is a Windows server likely running Windows NT 4.0 or Windows 2000. This is a lot of information to give away for just one simple connectionno mail client or actual delivery of e-mail was required. Compare this output with that of our mail server and note that it reveals far less. For example, our software is "Example MTA is ready for action; fire away (got TLS?)." What software is that? What platform or operating system is used? A quick Google search for "Example MTA" didn't reveal any hits for any known software packages. This likely isn't the real name of the software program being usedthe "hello" string has been changed. Many of the mail server packages allow the user or administrator to change this display information by modifying a configuration file, or worst case, as with the open source packages, you can modify the source code to change the setting.

This is a simple example, but hopefully it explains the common technique used. Whois records, DNS records, port scanners , and the like are usually all that is needed to identify a potential target. See Chapters 1315 of this book for more information on this subject.

Remote Logins/Unprotected Accounts

Is the system or attack target running services that provide remote logins? These often include services such as Remote Desktops, or command (shell) logins. Telnet, Secure Shell (SSH), Windows Remote Desktop, Citrix services, Virtual Network Computing (VNC) services, and X-windows are just a few of the common choices. In some cases certain web-based applications also let you run remote commands, and these are essentially remote shells or command services that need to be protected by user accounts.

By way of example, a system has been found that may be running a remote login serviceusually a port scanner is used to find or verify this. Now what? What application and platform are providing this service? Are there any known accounts that may not be protected? A simple Google search for that platform/service/version can often find "default" or common passwords for many systems or insecure configurations. Remember the system doesn't need to be a general use server. It may be a router, switch, IP printer, IP telephone, or some other device on the network with an IP address. These systems can often be used as entry points or a means to collect other information; or they may provide a launch pad to attack other adjacent systems that may be the real target, in which case these platforms are merely being used as a means of subverting firewall rules, for example.

A dictionary attack, or an attack against a username- and password-based authentication mechanism using a pregenerated set of passwords to guess from, may be a common approach if a shell service is found. Automated scanning tools exist, as mentioned, to find open shell ports. In some cases, the algorithms themselves may have known weaknesses and a special attack against these weaknesses may succeed if the dictionary attack fails. Despite these known weaknesses, brute-force attacks or attacks on specific algorithms are usually not required. Unfortunately, dictionary attacks are succeeding far more often than many people would realize.

In order for any password to be secure, it must be nonguessable, and not just nonguessable by a human mind, but by a computer program as well. Random passwords are best, but hard to remember. Random passwords might not even be safe. The reality is, even passwords that were once thought to be very strong are less and less effective. This is because of their insufficient entropy, or the measure of randomness any particular component of the encryption algorithm uses in the composition of the key. A regular password usually consists of a series of alphabetic, numeric, or symbolic characters (there are about 95 printable possibilities in the ASCII character setmore, if you use other character sets or nonprintable characters). Regardless, these combinations still represent far less than the entropy of the algorithms themselveswhat would be possible if the key was truly random. Therefore, the likely keyspace (or total number of combinations that need to be searched using a language/character encoding of the key) is far less than most would expect a true brute-force attack would require. Think of it this way: if you encode every combination of the 95 characters that are possible in the ASCII character set as a password of all possible lengths (then generate a binary XX length key using this data with padding to make a long enough key for the algorithm), the number of key combinations of all these generated language-based keys represents far less then the quadrillions or more that would be required if all possible keys were searched in a typical brute-force attack. Why brute force the key when you know the key is made of Latin characters and symbols? The effectiveness of the algorithm is ultimately weakened by the use of the key generation (using a password to create or represent the key).

There are a lot of passwords out there in production systems and the reality is that users just don't create strong passwords no matter how hard they try. It doesn't matter how long they are, or how obscure the characters used are; with a large enough dictionary and enough time, most if not all passwords can be broken without attacking their underlying algorithms. What's even more frightening is that many PCs now have the capacity to attempt more than ten million combinations per second. There are several common worms and hacking tools in the wild that are known to automatically scan for weak account passwords using dictionary attacks and hybrid dictionary/random/brute-force password attacks, often containing thousands of entries. Those that make guesses over the network execute much slower, of course, as opposed to attacking a password file locally. Network traffic and throttling timers in login systems slow down this kind of remote scanning activity and may even lock down the account in question (locking out the legitimate user also) when a brute-force attempt is detected . Distributed brute-force password cracking/guessing systems are known to exist as well.

In any case, if a remote login is accessible or can be obtained, even if the account is less privileged (not an administrator or super-user), this escalates the attack to local attack vectors. Applications, files, and services that are local to that machine are now vulnerable. Given a remote login, this may also give the miscreant a gateway to other systems, subverting firewall rules or other protections . Think "weakest link."

Network Services/Well-Known Vulnerable Services

Is the system or attack target running services that have been identified to be vulnerable to a known exploit of some kind such as a buffer overflow (sometimes referred to as a buffer overrun )? Is this service remotely reachable over the network? If there is a fix for these services, why have they not been patched or software updated? If not, you have a remote exploit. In many cases, this can be "game over," or in some cases, a local exploit needs to be found subsequent to the remote exploit.

The fact of the matter is that many organizations and individuals are either unaware of vulnerabilities in the software they use, despite patches that may be released, or they are unwilling or don't take the time to patch them diligently. IT or security administrators might use phrases like "We have a firewall, so we are protected." This couldn't be further from the truth. Firewalls are but one aspect of a considered layered security model. And history has shown that ongoing patching is the only way to fix vulnerabilitiesother mechanisms are band -aids to give you time to patch or mitigate the risk for a short period of time. Our systems are becoming more connectedwe have vendors , consultants , employees with e-mail and the ability to download things, and wireless and VPNsall of which become gateways into your network and in many cases subvert your firewalls or IDS/IPS. Computer worms such as Blaster, Slammer, Nachi/Welchia, Sobig, Sasser, Sober, Gaobot, MyDoom, Beagle, you name itall took advantage (in one way or another) of some defect in a computer application or component. They just keep coming and coming. One virus software vendor reported documenting 2,636 new vulnerabilities in 2003, an average of seven per day. Data for 2004 is not yet available from this vendor; however, undoubtedly it will be much higher. These are the ones you hear about and read about in the newsare there any you haven't heard about? Trojans and botnets have only recently received media coverage, though they've been the worst manifestation of malware for years these are the implementations of malware that organizations should most be worried about.

The path of least resistance suggests no one is going to break your proprietary application if the other software you've implemented has a well-known exploit. The ones you have to worry about are the ones you don't know about. If you know about it, fix it, because it probably has been used for months or longer before you found out.

The diagram in Figure 18-1 illustrates the root exploit, a simple remote buffer overflow exploit, in a commonly used piece of software that is running on a system in the network, and the effect of the attacker installing a hidden Trojan that may then be used to give a miscreant access to attack a local service, further increasing the exposure. The diagram details several components, including a command and control (C&C) server, a drone server, and other components that are all used to execute this attack. This root exploit is being used by these components in a distributed attack, or one involving more than one system working together. These distributed attacks are increasing in popularity because they allow the miscreant to both hide and discover vulnerable systems without performing a specific attack on each system, and thereby reducing the exposure of being caught. For further reading, the details of system components including drone servers (zombie servers), backdoors, and Trojans were discussed in Chapter 17. C&C servers are the systems the attacker uses to control (send commands to) drone servers in the field. What is important here is the fact that this exploit is possible because of the root exploitthe buffer overflow, which in this case we are assuming is a well-known vulnerability in the piece of software you are using.

Figure 18-1: Attack through buffer overflow to install Trojan and facilitate local attacks

Vulnerable Local Processes

Many of the systems we run have lots of processes that have the same or similar vulnerabilities as the ones that are customarily made available remotely, such as remote logins, web servers, and so on. Many have a more trusting model for local users who have already gained access (presumably legitimately), in that they run with higher privileges or aren't very restrictive about what files and services they are allowed to access. Why are local users safe? Why do we think they aren't the bad guys?

Local processes are often more susceptible to attack, as local users have more resources or attack vectors to throw at them, especially if the bottom line is just to cause denial of service. Some of these local attack vectors are

• Process Ownership Who owns or is allowed to execute the process? Is the program Set-UID or Set-GID (meaning when it is executed by a user who has permission to execute it, it instead runs as a different effective user (with the rights and privileges of that user), instead of the user who executed it)?

• Process Privileges and Resources What privileges does the process have and what privileges do other users have? Along these lines, you have several different areas of focus:

  • Shared Libraries What shared libraries or dynamic link libraries does it use?

  • Open or Expected File What files does it access or expect to be there?

  • File Ownership Who owns these files and who has read/write access to them?

  • Utility Programs Are there local commands or other utilities that can be used to control the processfor example, startup/shutdown scripts?

  • Local Network Sockets Many programs have ports or sockets that are only used locally on the running system, not on the network connections it may have, and these local sockets behave in the same way as network services for local programs and users. Programs such as Active Ports, Sysinternal's Process Explorer, Foundstone's Fport, Netstat, lsof, and others can often show which files and TCP/IP sockets a program is using.

  • UNIX Domain Sockets In UNIX environments, don't forget about UNIX domain sockets, which are like TCP/IP sockets, but use the filesystem for the connections instead of the IP stack/suite.

The diagram in Figure 18-2 illustrates a common privilege escalation exploit and then the threat on local processes via the files shared or accessed by those programs. The diagram shows how a remote user, using a backdoor or another process that was previously exploited, could then use this vulnerability in a Set-UID program, or one that runs with privileges of the user who owns the program/file versus the user that actually executes it, to access resources that normal local users wouldn't have access to. The diagram further illustrates how normal users access these protected resourcesin this case, some databasethrough the web server and the protected application. Through this local exploit in another local program that is Set-UID root, privileges can be escalated to get access to the resource, which would normally not be possible. In most network operating systems, a root or system administrative user can often access any file or resource regardless of the permissions that may be applied.

Figure 18-2: Privilege escalation and attack on local processes

Unprotected Local Accounts

On many systems, once local access is obtained, local accounts that aren't being used or haven't been used in some time may be vulnerable and targets for attack. On many systems, accounts are created that are deemed service accounts or application accounts, but that aren't utilized directly by users, and are only used by the application or service under which they run. In some cases these accounts have passwords that are weaker or may not have a password at all. As often as you've heard administrators criticize users for selecting bad (simple) passwords, we've found administrators themselves to be using the same poor-quality passwords (for these "service accounts") as you'd find selected by an inexperienced computer userfor example, using the same password as their username, leaving the password blank/empty, or creating a password based on the name of the process to be run by the service account. A user with local access may often take advantage of these accounts to seek additional privileges within the system. The diagram in Figure 18-3 demonstrates an attack on local accounts by using access from a backdoor to the system previously discovered and obtained, and then running a password cracking program to attack a password file or database that would store sensitive information for permission to a web application. Once a legitimate account was obtained, the miscreant could use that account and password to access the protected resources, as if he or she were the regular user. The fact that the password file is unprotected and other vulnerabilities existed to allow the miscreant access to the system to attempt to break passwords is the major issue and a common example of the problems that can occur once an attack on local accounts is possible.

Figure 18-3: Privilege escalation and attack on local user accounts

Programs such as crack and johntheripper (a few of many) are popular for performing dictionary attacks on these accounts via stolen/ copied password files or other data capture mechanisms, such as those mentioned in the previous section.

Unprotected Local Files

On many systems, once local access is obtained, files are written to or read from that are not properly protected from read/write access by users who do not need this access. In many cases, programs such as web servers write session information files and other status information to files on the filesystem. If these are not properly protected, they can be used as an attack vector for information discovery, data corruption, denial of service, or in some cases full administrator-level security breaches, such as privilege escalation or code execution.

On many systems, including most UNIX systems, most if not all configuration information is stored in files on the filesystem. These files may contain (and reveal) privileged information that needs to be protected. Included in these are passwords for system accounts and encrypted password files, which can then be attacked by looking for weak passwords that can be brute forced. Many remote login systems also store passwords, certificates, or keys that can then be used to attack other systems or impersonate a user or identity of a trusted system. For example, SSH is often configured to use a mechanism where the mere presence of a private key for a user account (as stored on the file system of both systems) is often enough to log into a remote system via key exchange process without a password. This happens when the user (or administrator) creates a private key (or an "identity") that requires no password to unlock it (a common practice, especially for systems maintenance scripts and automated processes). Essentially, the fact that you have (local file system permission to) the key is enough to ensure you are who you say you are, even when that key could have been stolen or is being used by someone else. All of these are examples of weaknesses in the storage of sensitive information on a system that may be vulnerable to attack if a user has local access to that system.

The diagram in Figure 18-4 demonstrates the attack vector on local filesystem stored data where the SSH key for one system is now used to access the other account.

Figure 18-4: Attack on SSH shared keys for access to other systems

As you can see, one system is being used as a gateway to another. Here is what the data in these files usually looks like, to further explain a typical exploit:

 [webuser@target1 ~]$ locate .ssh /home/george/.ssh /home/frank/.ssh /home/robg/.ssh /root/.ssh $ /usr/local/bin/vuln <shellcode> # id uid=0 (root) gid=0 (root) groups=0 (root) # cat /home/frank/.ssh/known_hosts target2.localdomain,192.168.1.200 ssh-rsa AAAAB3dfdfNzayc2EAAAABIwAAAIEA5OPcbPE 3Z5VV4PS8koqFcPlhk/OhUluv3yWaz7ka+o48RQciIfd34517/7pNXGSOIDncy5ehNBg5tH2zoseCgH/u6EyBALxmetrg+DDdbqaKqh77GtG/ipMc4Qo/X7vIR4akBxleUmrbbKON06vArYqdVKcKtp7gh2WHlJv 7E= # ssh -1 frank -h target2.localdomain -i /home/frank/.ssh/id_rsa [frank@target2 ~]$ 

This is just one oversimplified example. Naturally, a real attacker would likely be a bit more careful about logs that are generated and any audit trail that is left behind. In fact, a more common practice for attackers is to find a way to compromise the system (perhaps through a service account that leverages a compromised key from another system such as the one described earlier that required no password to use the identity as long as the file was available) and then to replace the "SSH" binary/program with a version that records users' passwords used to unlock their identities or log into systems. Then, the attacker will simply collect the log generated by his modified SSH binary and gain access to the systems indicated by the users. We came across a system that had been "root'd" and outfitted with such a modified SSH binary and had been collecting usernames and passwords for corresponding system addresses for the last two years in a university environment. These practices are more common than you think.