Most of the public and media interest in computer security is focused on network, Web, and e-mail security. Here and there we see articles about application security, but this is an area of computer security that is neglected by administrators and developers both.
This chapter will cover the security of web applications, regular applications, and embedded applications, pointing out possible security problems and how to solve them.
This chapter will make use of the following concepts that were discussed earlier in the book:
• Virtual private networking (Chapter 12)
• Firewalls (Chapter 11)
• Antivirus software (Chapter 16)
• Network Access Translation (Chapter 16)
• Public Key Infrastructure (Chapter 6)
• MD5 (Chapter 6)
Chapter 16 reviewed web server security as it is possible to hack the web server. This section deals with web application security, because hackers can also make use of insecure web applications in order to hack or deface a web site.
There are several security issues regarding web applications to be considered:
• SQL injection
• Forms and scripts
• Cookies and session management
• General attacks
NOTE In this chapter, the term server-side scripts will refer to any available server-side programming technology, such as Java, ASP, PHP, or CGI.
SQL (structured query language) is standardized by ANSI, and it serves as a common language for communicating with databases. Every database system adds some proprietary features to the basic ANSI SQL.
SQL injection is a technique to inject crafted SQL into user input fields that are part of web forms—it is mostly used to bypass custom logins to web sites. However, SQL injection can also be used to log in to or even to take over a web site, so it is important to secure against such attacks.
I’ll start with the most basic form of SQL injection—bypassing a login to a web site. The victim web site has a simple login form (see Figure 22-1):
FIGURE 22-1 A typical login form for a web site
This page requests two pieces of information from the user (username and password), and it submits the information in the fields to login.asp. The login.asp file looks like this:
This script takes the entered username and password and places them into a SQL command that selects data from the users table based on the username and password. If the login is valid, the database will return the user’s record. If not, it will return an empty record.
NOTE SQL injection is demonstrated here with ASP and ADO, but it’s a general problem that is not limited to these technologies.
I’ll use SQL extensively in this section, so I’ll briefly go over the SQL table structure. An SQL table definition contains the list of fields the table holds, and each field can contain data of a certain type only (as specified in the field definition) and a field may be part of an index. For the following examples, our users table will contain two fields, username and password, and each can hold a string value up to 20 characters long. The table will look like this:
The following SQL statement is built when a user enters admin as the username and somepassword as the password (as shown in Figure 22-2):
Let’s go over the query:
• select * means “give me all the data”
• from users means “take it from the table called users”
• where username= ‘admin’ and password= ‘somepassword’ means “find a row where both the username is admin and the password is somepassword
FIGURE 22-2 A user signing in using the login web form
The username and password are placed inside the SQL string without any sanity checks. (Sanity checks are performed to make sure user input doesn’t contain any characters a hacker could use to modify the SQL statement.) This means that a hacker can inject custom code into the user input fields without being detected.
In this case, the hacker will enter ’a’ or “1”=”1” for the username, and any password at all, because it will be ignored (see Figure 22-3). The resulting SQL looks like this:
FIGURE 22-3 A hacker attacking the login web form with SQL injection
The -- stands for a code remark, which means that everything that follows will be disregarded (for example, the trailing apostrophe (‘) will be ignored). This SQL phrase will always return data because “1”=“1” is always true. The server will have to evaluate the statement “false and false or true,” and because it will evaluate the “and” statement first, it’ll become “false or true,” which is true—the hacker will get access into the system.
This attack was made possible because the programmer didn’t filter the apostrophe (‘) inside the user input fields, which allowed the hacker to break the SQL syntax and enter custom code.
The following code solves this problem by filtering the apostrophes (every occurrence of ‘ in the user input is removed):
The previous example was very straightforward, but sometimes the SQL phrase is not so simple. Most login scripts check information in the user record: can the user log in, what is the level of subscription, and so on? A typical SQL login phrase can look like this:
This SQL phrase looks for users that are also administrators and are active; the SQL in the previous example simply identified a user and didn’t pay attention to whether the user was active or an administrator.
Usually hackers don’t know the exact format of the SQL phrase (unless they managed to view the server-side script using a web server exploit) so they need to submit bad SQL in order to gain more information. For example, they might submit someusername for the username and a’bla (or any other value that isn’t part of the SQL syntax) for the password. The resulting SQL is invalid, and it will be rejected by the SQL server, and will send back an error that may look like this:
Now the hacker can see the SQL phrase and can craft better input, like someusername for the username and ‘a’ or ‘3’=‘3’ for the password, which will be interpreted like this:
The hacker can use built-in stored procedures (functions supplied by the database to perform administrative and maintenance tasks) to write or read files, or to invoke programs in the database’s computer. For example, the xp_cmdshell stored procedure invokes shell commands on the server’s computer, like dir, copy, move, rename, and so on. Using the same scenario from the last section, a hacker can enter someusername as the username and a’ exec master..xp_cmdshell ‘del c:\winnt\system32\*.dll’ as the password, which will cause the database to delete all DLLs in the specified directory. Table 22-1 lists some stored procedures and SQL commands that can be used to further elevate an attack.
TABLE 22-1 Common SQL Server Stored Procedures That Are Abused by Hackers
There are many forms of SQL injection, but they require extensive knowledge of the database server and are beyond the scope of this book. Excellent analyses of SQL injection can be found at www.nextgenss.com/papers/advanced_sql_injection.pdf and www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf.
Developers and administrators can take a number of different steps in order to solve the SQL injection problem.
These are some solutions for developers:
• Filter all input fields for apostrophes (‘) to prevent unauthorized logins.
• Filter all input fields for SQL commands like insert, select, union, delete, and exec to prevent server manipulation. (Make sure you do this after filtering for the apostrophes.)
• Limit input field length (which will limit hackers’ options), and validate the input length with server-side scripts.
• Use the option to filter “escape characters” (characters that can be used to inject SQL code, such as apostrophes) if the database offers that function.
• Place the database on a different computer than the web server. If the database is hacked, it’ll be harder for the hacker to reach the web server.
• Limit the user privileges of the server-side script. A common practice is to use the administrative user when logging in from the server-side script to the database, but this can allow a hacker to run database tasks (such as modifying tables or running stored procedures) that require the administrative user. Assign a user with minimal privileges for this purpose.
• Delete all unneeded extended stored procedures to limit hackers’ possibilities.
Unlike developers, the administrator has no control over the code and can’t make changes on behalf of the programmers. However, the administrator can mitigate the risks by running some tests and making sure that the code is secure:
• Make sure the web server returns a custom error page. This way the server won’t return the SQL error, which will make it harder for the hacker to gain data about the SQL query. (A custom error page should not contain any information that might aid the hacker, unlike the regular error page, which will return part of the SQL statement.)
• Deploy only web applications that separate the database from the web server.
• Hire another company to perform penetration tests on the web server and to look for SQL injection exploits. SQL injection is best discovered using manual penetration tests, not automatic scans. Because no two sites are alike, because SQL injection exploits result from programmers’ mistakes, and because no server-side scripts are the same, human intervention is required to find those exploits.
• Deploy security solutions that validate user input and that filter SQL injection attempts. (Sanctum and KaVaDo are two companies that provide such solutions.)
Forms are used to allow a user to enter input, but forms can also be used to manage sessions (discussed in the “Cookies and Session Management” section, later in this chapter) and to transfer crucial data within the session (such as a user or session identifier). Hackers can exploit the data embedded inside forms and can trick the web application into either exposing information about another user or to charge a lower price in e-commerce applications. Three methods of exploiting forms are these:
• Disabling client-side scripts
• Passing parameters in the URLs
• Passing parameters via hidden fields
Some developers use client-side scripts to validate input fields in various ways:
• Limit the size of the input fields
• Disallow certain characters (such as apostrophes)
• Perform other types of validation (these can be specific to each site)
By disabling client-side scripting (either JavaScript or VBScript), this validation can be easily bypassed. A developer needs to validate all fields at the server side!
A form has two methods of passing data:posting and getting. The command, post sends the data using a special HTTP POST command, and the command, get sends the data in the URL.
Suppose we have this kind of form:
Let’s assume the user enters someusername as the username and somepassword as the password. The browser will be redirected to this URL:
This specific example can’t be used by hackers (unless someone sent this kind of URL to other people), but there are other types of data passed in URLs that can be used to hack into a server.
A hacker can exploit this type of URL by simply modifying the URL’s data (in the browser’s address bar); this method is mostly used in e-commerce sites to change the prices of items. For example, look at the following URL:
The hacker could simply change the value of “totalprice” and perform a checkout that has a lower price than was intended. This can be done simply by changing the URL like this:
The web application will perform the checkout, but with $50 as the total price (instead of $100).
Another scenario is that, after the login, the user identification is sent using get, allowing a hacker to modify it and perform actions on another user’s behalf. An example is shown in the following URL:
The hacker could change the value of “user” and will get the data of that user (if the user exists).
The post method sends the data using the POST HTTP command. Unlike get, this method doesn’t reveal the data in the URL, but it can be exploited rather easily as well. Consider the following form:
This form transmits the user identifier using POST. A hacker can save the HTML, modify the UserID field, modify the checkout.asp path (to link to the original site, like this: <form action=“http://example/checkout.asp”…), run it (by double-clicking on the modified local version of the HTML page), and submit the modified data.
The developer can prevent hackers from modifying data that is supposed to be hidden by managing the session information, by using GUIDs, or by encrypting the information.
Managing Session Information Most server-side scripting technologies allow the developer to store session information about the user—this is the most secure method to save session specific information because all the data is stored locally on the web server machine.
Using GUIDs A globally unique identifier, or GUID, is a 128-bit randomly generated number that has 2128 possible values. GUIDs can be used as user identifiers by the web application programmer. Assuming a web server has 4 billion users (about 232, which is more than the number of people who have Internet access), this means there are on average 296 possible values per user 
. Since 296 is approximately 7 followed by 28 zeros, the hacker will have no chance of guessing, and thus accessing, a correct GUID.
Encrypting Data The developer can pass encrypted data rather than passing the data in cleartext. It should be encrypted using a master key (a symmetric key that is stored only at the web server, and used to store data at the client side), because if it’s per session key (a symmetric key that is a derivative of unique information taken from the session like IP, and other user information)—it makes more sense just to save the relevant data per session as well. If a hacker tries to modify the encrypted data, the client will detect that someone has tampered with the data.
NOTE Never use a derivative of the user’s information as a hidden identifier, such as an MD5 hash of the username. Hackers will try and find such shortcuts and exploit them.
Web sessions are implemented differently by each server-side scripting technology, but in general they start when the user enters the web site, and they end when the user closes the browser or the session times out. Sessions are used to track user activities, such as a user adding items to their shopping cart—the site keeps track of the items by using the session identifier.
Sessions use cookies (data sent by the web site, per site or per page, stored by the user’s browser). Each time the user visits a web site that sent a cookie, the browser will send the cookie back to the web site. (Although cookies can be used to track users’ surfing behavior and are considered a major privacy threat, they are also the best medium for session management.) Sessions use cookies to identify users and pair them with an active session identifier.
Hackers can abuse both sessions and cookies, and this section will deal with the various risks:
• Session theft
• Managing sessions by sending data to the user
• Web server cookie attacks
• Securing sessions
Suppose that a user logs into a web site that uses sessions. The web site tags the session as authenticated and allows the user to browse to secure areas for authenticated users. Using post or get in order to save a weak session identifier or other relevant identifying data (like e-mail addresses) was discussed in Chapter 21. Instead, the web site can use cookies in order to save sensitive data, but a hacker can exploit this as well.
Let’s assume the web site uses e-mail addresses as the identifying data. After the user has logged in, the system will send the browser a cookie containing the user’s e-mail address. For every page this user will visit, the browser will transmit the cookie containing the user’s e-mail address. The site checks the data in the cookie and allows the user to go where their profile permits.
A hacker could modify the data in the cookie, however. Assume the cookie contains someemail@site.com, and each time we access the site we can automatically access restricted areas. If the hacker changes the e-mail address in his cookie (located on his computer) to be someotheremail@site.com, the next time the hacker accesses the site, it will think he is the user someotheremail and allow him to access that user’s data.
NOTE Amazon saves user information in a cookie, and allows users to see their recent activities (without logging in). However, Amazon encrypts the content of the cookie, making it harder for a hacker to hijack a session.
Some users disable cookies (to protect their privacy), which means they also don’t allow session management (which requires cookies). Unless the site is using the less secure get or post methods to manage sessions, the only way to keep track of users is by using their IP address as an identifier. However, this method has many problems:
• Some users surf through Network Address Translation (NAT), such as corporate users, and they will share one or a limited number of IP addresses.
• Some users surf through anonymous proxies, and they will share this proxy IP address (though some proxies do send the address of the client, thus allowing the web site to use it for session management).
• Some users use dial-up connections and share an IP address pool, which means that when a user disconnects, the next connected user will get that IP address. (This problem can be solved with a short IP timeout, so that after the time expires, the IP address will not be linked to a session.
NOTE Don’t be afraid to require cookies on your site in order to perform actions that require session tracking—remember, your web site’s security comes first.
The best way to secure session tracking is to use a hard-to-guess identifier that is not derived from the user’s data, such as a strong encrypted string or GUID, and to tie this identifier to the IP address of the user (in case multiple users share an IP address, the session identifier can be used to distinguish them).
In addition, a short timeout can be used to delete an active session after the time limit has elapsed. This means that if the user doesn’t close the browser gracefully (as in the case of a computer or browser crash), the session is closed by the server.
A hacker can exhaust the resources of a web server using cookie management by opening many connections from dedicated software. Since this software will not send “close” events as a browser does when it is closed, the session will not be deleted until a timeout elapses. During this time, the session’s information is saved either in the memory or in the hard drive, consuming resources.
The solution to this problem is to configure a firewall so that it does not allow more than a particular number of connections per second, which will prevent a hacker from initiating an unlimited number of connections.
Some attacks aren’t part of any specific category, but they still pose a significant risk to web applications. Among these are vulnerable scripts, the possibility of brute forcing logins, and buffer overflows.
Some publicly used scripts (which are basically web applications) contain bugs that allow hackers to view or modify files or even take over the web server’s computer. The best way to find out if the web server contains such scripts is to run a vulnerability scanner, either freeware or commercial. If such a script is found, it should either be updated (with a non-vulnerable version) or replaced with an alternative script.
An example of such a bug discovery of a script can be found at http://lists.insecure.org/lists/bugtraq/2003/Mar/0443.html—the script fails to filter user input for <script> tags, allowing hackers to insert JavaScript that will run at every browser that will visit the relevant page. (The actual script can be downloaded at: http://www.icthus.net/CGI-City/scr_cgicity.shtml#CCGUEST.)
A hacker can try to brute force the login (either a standard web login, or a custom ASP) using a dictionary. There are a number of ways to combat brute-force attacks:
• Limit the number of connections per second per IP address (either define this at the firewall level or at the server-side script level).
• Force users to choose strong passwords that contain upper- and lowercase letters and digits.
NOTE A strong password is a password that can’t be found in a dictionary, that isn’t constructed out of the user’s information, and that isn’t a sequence of letters (such as abcdefghi). For instance, it wouldn’t be smart for a user named Todd to choose a username such as todd1979 if 1979 is his birth year; a hacker might try that permutation. Use a password longer than seven characters that includes apparently random digits.
Buffer overflows (explained in detail in Chapter 16) can be used to gain control over the web server. The hacker will send a large input that contains assembly code, and if the script is vulnerable, this string will be executed and usually will run a Trojan that will allow the hacker to take over the computer.
Web applications are harder to secure than regular applications because, unlike web servers that have four or five major vendors, there are a huge number of web applications and custom scripts, and each may contain a potential exploit. The best way for developers to secure their applications is to use the proposed security measures and use software that scans code and alerts you to potential security problems. Administrators need to periodically scan their web sites for vulnerabilities.
Application security is mostly determined by the developer of the application. The administrator can tighten the security for some applications, but if the application is not secure by nature, it’s not always possible to secure it.
Writing a secure application is difficult, because every aspect of the application, like the GUI, network connectivity, OS interaction, and sensitive data management requires extensive security knowledge in order to secure it. Most programmers don’t posses this knowledge or are just careless about it.
From the administrator’s point of view there are a number of security issues to keep in mind:
• Running privileges
• Administration
• Integration with OS security
• Adware and spyware
• Network access
An administrator should strive to run an application with the fewest privileges possible. Doing so protects the computer against several threats:
• If the application is exploited by hackers, they will have the privileges of the application. If the privileges are low enough, the hacker won’t be able to take the attack further.
• Low privileges protect the computer from embedded Trojans (in the application), because the Trojan will have fewer options at its disposal.
• When an application has low privileges, the user won’t be able to save data in sensitive areas (such as areas belonging to the OS), or even to access key network resources.
NOTE While developing an application, programmers tend to make assumptions in order to cut development time. Some of these assumptions result in applications that require administrative privileges to work. This may cut programming time, but it reduces the ability of the administrator to keep systems secure. When ordinary users are given administrative privileges, they can remove or go around security configurations, thus subverting any security that might be in place.
When installing an application, it’s usually necessary to have higher privileges or even administrative privileges, because the installer may need to access sensitive OS directories and make registry and hardware changes.
NOTE It’s best to install the application on a testing computer that has a similar configuration to the actual computer that requires the installation. This way you can see if any problems arise before installing the application on a live computer.
If an application requires administrative privileges but there is no obvious reason why it needs them, or if you just don’t trust the application, you can run it within a sandbox. A sandbox is a security application that intercepts the system calls of the application that it is running and makes sure the application will have access only to the resources the administrator has allowed. Thus, sandboxes can limit access to the registry, OS data directory, and network usage. This isolates the application from sensitive OS areas and other user-defined locations, such as those containing sensitive data.
NOTE My favorite sandbox application, which is more than a sandbox, is VMware (www.vmware.com). VMware allows you to set up an OS within your current working OS (you can install any OS you want). You can install you current OS, and run an application within that. If something goes wrong it will only affect the OS in the sandbox and not the actual OS running the computer. However, network-propagating viruses will not stop at the VMware boundary and may infect the local network. Another option is to use a central computer to run insecure applications via Citrix MetaFrame or terminal services.
Most applications offer some interface for administration (mostly for application configuration), and each administration method posses security risks which must be addressed, such as these:
• INI/Conf file
• GUI
• Web-based control
The most basic method of administrating an application is to control it via text-based files. To secure such an application, the administrator needs to limit access to the configuration files using either built-in OS access management, if the files are stored locally, or by using authentication to log into the remote storage place (making sure the authentication method is secured).
Most applications have GUI interfaces for administrating them. Besides security at the GUI level, the communications between the GUI and the application should be secured, as well.
When the GUI is physically located on the same computer as the application, the administrator should give the GUI the least possible privileges (the application can run with higher privileges if necessary).
NOTE Windows 2000 (and higher) has an application called RunAs.exe, which allows the user to run an application in the security context of another user (which may have higher or lower privileges).
When the GUI controls a remote system, the most important issue is how the GUI controls the application; this topic will be discussed in the “Remote Administration Security” section of this chapter.
A popular way to allow application administration is via a web interface, which doesn’t require a dedicated client and can be used from multiple platforms. Web interface remote administration is in the “Remote Administration Using a Web Interface” section of this chapter.
When an application is integrated with OS security, it can use the security information of the OS, and even modify it when needed. This is sometimes required by an application, or it may be supplied as an optional feature. There are both advantages and disadvantages to OS security integration.
OS security integration allows an application to either import or access in real-time the OS’s list of users and their privileges. Imagine a company with a thousand employees that need access to a central enterprise resource planning (ERP) application. The administrator could manually enter all the thousand users into the ERP’s administrative console, along with their privileges, but this method is time consuming and will require double management afterwards. If the company has more then one central system that requires manual user entry, this scenario would be even worse.
An application may allow the administrator to import all the user information and use it to manage authentication for the application. Although this method may speed up application deployment, there is still double administration afterwards. For example, when an employee leaves the company, the administrator has to delete the user both from the company’s user list, and from the application list.
Another issue to consider is how the application stores its user information. Is it protected? Encrypted? Stored in cleartext? If you don’t trust your application’s data storage security, you can encrypt the entire hard drive as proposed in the “Don’t Rely on OS Security” sidebar.
Automatic integration of security information allows the application to query the OS in real time for user credentials. This way, both the initial deployment time and the double administrative issues are solved. There are two problems with this option, though:
• If the OS’s user database is deleted or lost, the application can’t be accessed.
• The network connection between the application and the OS user database should be secured to prevent hackers either eavesdropping on the line or using a fake server to gain information about users’ credentials.
An application can use OS security to authorize sessions. In this scenario, the application sets up a special directory or resource (like shared memory, a mail slot, name pipes) that can be accessed only by users who possess certain privileges and OS protects access to that directory or resource.
The problem with this method is that it shouldn’t be used in Internet environments, since it requires features that are usually blocked for Internet users (such as NetBIOS). A VPN connection to the corporate network can solve this problem.
Sometimes it’s necessary to deploy a small application that will be used by only one or two users—consider what will happen if the application forces us to integrate with the OS security (using one of the methods discussed) in a corporation with a thousand users. It will only decrease the security (if it uses an insecure method) and decrease deployment speed (because we have only one or two users). Also, the administrator may be reluctant to give an application the ability to modify or even damage the user directory.
It’s crucial to keep today’s applications up to date with the latest security patches, but the majority of systems aren’t updated on a sufficiently frequent basis, allowing hackers and viruses to use old known exploits to gain entry or to propagate. There are many reasons why there are so many unpatched applications.
This section will cover some mechanisms for easily updating applications:
• Manual updates
• Automatic updates
• Semi-automated updates
• Physical updates
Manual updates require the administrator to physically download a file (or use a supplied media, like a CD) and install the update on the relevant system. This option is the least preferable, since it forces administrators to spend extra time to patch a working system. Manual updates are very common for open source programs (such as Apache).
When an application uses automatic updates, it checks with its web site every so often for an update, and if one exists, it downloads it and installs it on the system. There are two problems with this method:
• Bandwidth usage Consider a company with a thousand computers that run the same antivirus software, which updates itself daily. Every day, a thousand copies of the same update are downloaded to each computer running this program.
• Installing problematic patches Sometimes patches (software updates released by the vendor to fix security problems and bugs) can cause more harm than good, because patches are made in a hurry to solve a critical issue. The developers can’t foresee all possible environment scenarios, and the patch may stop the application or cause it to behave improperly.
NOTE When dealing with major patches, like service packs, I prefer to wait a couple of days to make sure there are no bugs in the patch when others install it. Only after no problems are reported do I install it. I wait on application updates, as well, but the importance of this is debatable.
Some applications (such as Symantec AntiVirus Enterprise Edition) allow the administrator to decide when to download an update. After the update is downloaded, the application distributes the update to all the connected clients.
It’s possible to update the system using an update received physically (as with the service packs that Microsoft sends to its MSDN subscribers). A motivated hacker can create a “fake” patch by forging an update that looks just like the original, but containing a Trojan or other malicious software. To secure against this kind of attack, the administrator can check for the size and CRC32 signature of the update at the vendor’s site and compare it to the physical copy.
NOTE Physical media may seem to be “authentic” because the hacker will take many steps in order to send such a forged update: forge the package and sender’s address, forge the CD-ROM’s look, and forge the installation process. A hacker can do all that forgery, but they will have to be very motivated (or be paid by someone else) to conduct such a hack.
Some shareware or P2P applications install a variety of spyware or adware applications that are used to send unsolicited advertisements and even keep track of a user’s activities.
Adware is used to deliver advertisements to either the Internet browser or to the hosting application. Spyware tracks the Internet activities of the user and sends targeted advertisements.
Some applications can be used for free in exchange for viewing advertisements, and since their makers wish to make money, their solution is to install adware that will deliver advertisements to the user.
Beside invading our privacy and wasting bandwidth, these applications don’t pose a security risk yet. However we are soon likely to see adware and spyware with Trojans embedded.
Filtering spyware and adware traffic is almost an impossible task, since they use regular web traffic in order to communicate with their servers. There are possible solutions, but none offers perfect protection:
• The best defense is a good offense The best way to combat adware and spyware is to remove them from your computer. A popular application that scans your computer and deletes various types of unwanted applications is Ad-aware by LavaSoft (www.lavasoft.de).
• Blocking targeted sites Advertisements come from known locations, so an administrator can set up the corporate firewall to block access to and from these sites.
• Have an installation policy Adware and spyware come with P2P software like Kazaa, IMesh, and Gnutella clients. A company should have a policy that forbids users from installing such applications (they pose more problems than adware and spyware).
Adware and spyware aren’t installed only by P2P applications or shareware. I investigated an application on my computer that I didn’t recognize, and after some investigation I found that it was spyware installed by my sound card vendor (Creative, Vibra128). I wasn’t the only person with this spyware. After further research, I found out that the installation program’s disclaimer gives the vendor the permission to install such spyware on my computer. The following paragraph contains the installation license agreement with the relevant sections in boldface:
EXCEPT AS STATED ABOVE IN THIS AGREEMENT, THE SOFTWARE IS PROVIDED AS-IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE. CREATIVE IS NOT OBLIGATED TO PROVIDE ANY UPDATES, UPGRADES OR TECHNICAL SUPPORT FOR THE SOFTWARE.
This license agreement may be standard, but it gives the vendor power to install spyware on the buyer’s computer. It’s known that P2P software (like Kazaa) installs spyware, but I hadn’t expected a respected hardware vendor to do so.
Credentials can’t limit network access—you can keep an application’s privileges to a minimum, but it can still access the network and accept incoming connections (on allowed ports).
The only solution available today for allowing only specific applications to access the network is to use a personal firewall. However, personal firewalls require the user to distinguish between “good” and “bad” applications—knowledge the user doesn’t usually possess—and the user becomes the point of failure in this solution.
There are so many applications out there, and not all of them are secure (I would even say most are insecure). Securing insecure applications can be time-consuming to impossible, because of that fact and the variety of available applications it’s best to base the purchasing decision on the security aspect as well.
Embedded applications are usually referred to as being hardware-based, and they are used extensively in our computing environments. Basically, an embedded application is any closed device (computer or hardware) that comes fully installed and administrators don’t have direct access to it (like they would to a regular computer)—they must use an administration interface. Such devices include routers, firewalls, and other security devices.
Some vendors boast that their embedded appliances are more secure. However, some embedded applications are actually an embedded version of an OS, such as embedded Windows XP or Linux. In these cases, the embedded application is a version of the OS that can be partially installed (without all the required components) and it is not hardware-based. It’s possible that a component that has an exploit (such as Linux or Windows XP) is used in the specific configuration.
NOTE It can be argued that even “true” embedded applications can be hacked, but I still prefer “true” embedded applications. If someone wants to sell an application that is based on embedded Linux or Windows XP, that’s fine, but it shouldn’t be called hardware-based.
Embedded applications are considered more secure than regular applications, but is this really true? Sometimes it is true, and sometimes there’s no real advantage over regular applications.
The major difference between the two types of applications is that embedded applications usually have no local control mechanism, and the administrator has to access them remotely via the network or another physical connection. This connection needs to be secure and has the same security problems as a regular application does. However, setting up a VPN on a hardware device may require another computer in front of it to act as the VPN server, since there is no access to the device’s internal controls.
Embedded applications use an OS—it can be Windows XP, Linux, or another type of embedded OS. Each OS has its own exploits, but using a less common OS can add to security because hackers generally put less effort into exploiting them. (An embedded OS can be secure if it is hardened correctly, but it’s more feasible for a hacker to install embedded Windows XP or Linux and test its components for exploits than to deal with some unknown OS.)
NOTE Embedded Windows XP licenses limit its usage and forbids hosting an application that can harm lives if it fails. To me this limitation is a big red flag both for security and reliability.
Embedded applications and hardware devices aren’t inherently secure. An embedded application may be very secure, or it may be exploited even faster than a regular application. Make sure you keep your embedded applications up to date with the latest security patches (most respected vendors allow administrators to update the application through the administrative interface) and secure its administrative connection.
Most of today’s applications offer remote administration as part of their features, and it’s crucial that it be secure. If a hacker manages to penetrate the administration facilities, all the other security measures are useless.
Remote administration is needed for various reasons:
• Relocated servers An administrator needs an interface to administrate any relocated web servers (computers that belong to a company but that are physically located at the ISP).
• Outsourced services Managing security products requires vast knowledge that most companies don’t posses, so they often outsource their entire security management to a firm specializing in that area. In order to save costs, that firm needs to manage all the security products through the Internet.
• Physical distance An administrator may need to manage a large number of computers in the company. Some companies span several buildings (or cities) and physically attending the computers can be a tedious and time-consuming task.
Using a web interface to remotely administrate an application or a computer has many advantages, but like any good thing, it has its costs, and some advantages are also disadvantages.
These are some advantages of remote web administration:
• Quick development time Developing a web interface is faster then developing a GUI client, in terms of development, debugging, and deployment.
• OS support A web interface can be accessed from all the major OSs by using a browser (unless the developers used an OS-specific solution, like ActiveX, which only runs on Windows).
• Accessibility A web interface can be accessed from any location on the Internet. An administrator can administrate even if he’s not in the office.
• User learning curve Since it’s presumed that an administrator knows how to use a browser, the learning curve for the administrator will be shorter.
Although remote web administration has some disadvantages, they are usually not critical for most administrators. However, they should be noted:
• Accessibility Due to the fact that web administration is accessible from anywhere on the Internet, it’s also accessible to a hacker who may try to hack it.
• Browser control Because a browser controls the interface, a hacker doesn’t need to deploy a specific product control GUI (which might be hard to come by).
When connecting to the remote web administration interface, the first hurdle to pass is the authentication process. If the authentication is weak, a hacker can easily bypass it and take control of the application or computer.
Before delving into the problem of remote administration, it’s important to go over the current methods available to authenticate HTTP connections:
• Basic authentication When a page requires basic authentication (see RFC 2617, ftp://ftp.rfc-editor.org/in-notes/rfc2617.txt), it replies to the browser with error code 401 (unauthorized) and specifies that basic authentication is required. The browser encodes the username and password using BASE64 encoding (discussed in Chapter 16) and sends it back to the server. If the login is correct, the server returns message number 200, which means everything is OK. If the login fails, it replies with the same 401 error as before.
• Digest authentication Digest authentication (see RFC 2617, ftp://ftp.rfc-editor.org/ in-notes/rfc2617.txt) uses MD5 to hash the username and password, using a challenge supplied by the web server.
• NTLM NTLM is Microsoft’s proprietary authentication scheme, which can also be used for web authentication. More information about NTLM can be found at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/microsoft_ntlm.asp, www.innovation.ch/java/ntlm.html, and http://squid.sourceforge.net/ntlm/. NTLM is used to authenticate users using their Windows login and password.
NTLM is not a HTTP authentication scheme; it’s one of their authentication processes which can be used by IE to authenticate to IIS which has Windows integrated authentication turned on… and I’m curious as to why they don’t reference MS’s documents on NTLM? It’s a proprietary authentication scheme; why not direct people to the source, and then add the others as well?
• SSL SSL can be configured to require a client certificate (optional) and authenticate a user only if they have a known certificate.
• Encrypted basic authentication Basic authentication can be used in conjunction with regular SSL, thus encrypting the entire session, including the BASE64 encoded username and password.
The two most popular unencrypted authentication methods are basic authentication and NTLM, and they can be hacked. An eavesdropping hacker (on the LAN or wireless network) can intercept basic authentication, and since it has no protection over the username or password, the hacker can easily discover them. NTLM is a bit more secure, but it can be brute forced (in a reasonable amount of time, which may encourage hackers to try).
The best solution for securely logging in to a web-administrated server is to either use SSL, which checks for client certificates, or to use encrypted basic authentication. (SSL can also authenticate the server against a third party CA to ensure it is the server you meant to connect to.) Another option is to use secured custom logins (implemented with server-side scripts), but they may contain web exploits that were discussed earlier in the chapter.
NOTE For the ultimate security, a VPN infrastructure can be used to secure remote administration, relying upon the Extensible Authentication Protocol (EAP), which may require a smart card to be used at the user’s end.
Some applications are controlled remotely via a GUI interface or through console applications, such as SQL Server, Exchange Server, firewalls, and IDSs. An application may also control clients with probes, as IDS does. Proprietary network connections have a few security issues that need to be addressed (as web connections do). Just like remote web administration, custom remote administration has both advantages and disadvantages.
These are the advantages of custom remote administration:
• Complex graphics Sometimes the console needs to display complex graphics that can’t be shown using a regular web administration interface.
• Authentication and encryption The application may use either a stronger authentication or encryption method to secure the session (perhaps using a greater key length that isn’t supported by SSL).
• Availability Since the application can only be controlled from a dedicated GUI, the hacker will need to install it at his computer (and accessing or installing it may not be possible).
NOTE A hacker can hack an application without its GUI, but it’s far easier when the GUI is installed at the hacker’s computer.
Although custom remote administration has some disadvantages, they usually are not critical for most administrators. However, they should be noted:
• Specific OS Some vendors will require a specific OS to run the controlling GUI, and the administrator will have to install it if it isn’t already installed (this may involve additional costs if the OS is not free).
• Unavailability The application can be administrated only from computers on which the GUI is installed, and if the administrator is not in the office, it may not be possible to administrate it from other computers.
It’s important that the session between the client (GUI or console) and the application be secure. Otherwise hackers may be able to gain information, credentials, or even conduct a replay attack. If the session is known to be insecure, the administrator can easily relay it through a VPN or a secure tunnel (SSH).
It’s important that authentication take place and that it isn’t based upon easily forged assumptions, like the IP or MAC address of the computer.
The sequence of the authentication process is also critical: Is the session secured before the credentials are sent? Are the credentials sent in cleartext format? The best way to exchange login information is either after the session is secured, or using a known method like EAP for insecure sessions (discussed in Chapter 12).
Some applications use OS networking services, such as remote procedure calls (RPC) or Distributed Component Object Model (DCOM), which allows the administrator to add data integrity, encryption, and authentication. If you don’t trust the OS security measures, you can tunnel the network connection through a VPN connection.
To conclude this section, just like web application connectivity, we can’t force an application to communicate securely if it doesn’t support the option. The solution is either to use a VPN or to tunnel the data session through a secure session (SSH).
Unlike network role security, which is relatively easy to fix by using vulnerability scanners and applying service packs and patches, application security is much harder to achieve.
Every programmer who writes an application, whether web-based or regular, and who isn’t experienced enough can open the application to outside hackers. Because application security problems mostly result from human factors (the programmers) the best solution is education. Unfortunately, education is more expensive than applying patches and service packs; hence the major problem of application security.
