Web Application Vulnerability Assessments | Critical Incident Management

< Day Day Up >

One of the most attractive business frontiers is E-commerce. For the first time in history, a business can have its doors open to the entire world where users can make purchases with nothing more than their credit cards in hand. Businesses are drawn to E-commerce to disseminate company information, sell products and services, provide customer service, and gain a competitive advantage. Most organizations with a presence on the World Wide Web have installed preventive and detection controls in the form of installing DMZs, firewalls, and intrusion detection equipment, and hiring competent employees. Senior managers are surprised at what an attacker can do with a Web-browser and a little creativity.

Auditors must be aware there are logical steps in reducing risks, but the majority of vulnerabilities are found in faulty programming, misconfiguration, and absent systems monitoring.

Auditors must be aware that risks are controlled by:

Knowing the organization's critical assets
Knowing threats and vulnerabilities
Implementation and compliance with policies, procedures, and standards; primary concerns include but are not limited to:
- Change control management
- Code development and maintenance
- Quality assurance testing
- User acceptance testing
Effective and continuous audits
Continuing risk management

HTML Examination

As a logical first step, auditors should carefully examine the HTML, HyperText Markup Language, composition of the organization's Web site. Attackers examine the Web page coding as one of their first steps to gaining as much knowledge as possible about their targets. Basically, auditors should download all the pages comprising the organization's Web site and examine the HTML coding. Often there are valuable programmer comments, passwords, telephone numbers, names, contractor's information, and business addresses, commonly placed within the HTML. For example:

  <HTML>  <HEAD>  <TITLE> Welcome to the XYZ Corporation HomePage </TITLE>  <BODY> BGCOLOR = "#0000FF" TEXT = #FFFFF">  </Body>  </HTML>  <! - Any problems call Alice Doe at ABC Web Design, Waterfront,  San Diego, CA, XXX-555-1234 or e-mail me at alicedoe@ABCWebDe-  sign.com - >

An examination of this Web page HTML reveals the XYZ Corporation is using an outsource Web design firm, and the page designer has listed her name and contact information. This information could be very useful to an attacker who was interested in doing a bit of social engineering with Alice Doe or her employer.

Testing for Indexed Directories

Auditors should obtain a list of the indexed Web page directories. The manual process is a slow one, where the browser is used to request specific directories. For this reason, it is more expeditious for the auditor to obtain a list of indexed directories from the Web page administrator. However, if a true outside view is sought, the auditor can deploy her browser in this fashion (http://www.xyzcorporation.com/images).

If the browser returns the images directory, it is important for the auditor to examine each and every file related to the Web site. More than once, auditors have discovered files that were not innocent files.

Experience Note

While conducting an audit of a client's Web site, the auditor began to survey the files accessible from the URL address line of the browser, using the format of www.xzycorporation.com/files. After downloading the files, it was discovered that one of them contained personally identifiable employee information.

Web Server Examination

Auditors may frequently access a company's Web site and determine the presence of specific Web servers. In UNIX and Windows environments, auditors may use the telnet client. By requesting a bogus file, the server file returns an error message and often the Web server will be correctly named. With this knowledge, an attacker merely researches the Internet for known vulnerabilities and executes them. For example:

  # telnet www.xyzcorporation.com 80  Trying 275.xxx.xxx.xxx  Connected to  XYZCorporation.  Escape character is ^  GET/no-such-page.html HTTP/1.0 (At this time the auditor presses  the Enter key twice)  HTTP/1.0 error 404 Not Found  Server: IIS-1.0 (This is the Internet Information Server version  1.0)  Content-Type: text/html  Content-Length: 295

Another useful tool for auditors is found at the Web site www.netcraft.com. This tool is useful whether Web sites are SSL, Secure Sockets Layer, enabled. By completing a few entries, the netcraft tool will display information about the particular Web site of interest including the Web server and operating system.

Experience Note

It is possible that savvy administrators have changed the banners in their server responses, so it is beneficial to verify the information before listing it as a possible finding.

Although this is not considered a high-risk vulnerability, but there are many advantages in concealing system information from attackers. Attackers using techniques to identify the Web server and its version will browse the Internet in an effort to obtain vulnerability information that can be used to exploit the server. So, if they do not have accurate information, they must resort to another means to identify the Web server. It is not a perfect remedy. Efforts to conceal information will often discourage the casual attacker but probably will not dissuade the more-motivated ones.

In a Window's environment, the HTTP server field may be edited via a hex editor in the W3SVC.DLL file and in a UNIX environment, the TCP/IP stack may be changed following the instructions at http://ippersonality.sourcefourge.net. It is suggested that the Web server response should be changed to reflect something nonsensical such as Vital O/S 2003.

There are many advantages in the practice of security through obscurity. Auditors have a variety of tools available when mirroring a Web site. The advantage of mirroring a Web site is that auditors can view it at their leisure and conduct an in-depth review of the HTML as well as its construction. There are Web site mirroring tools at www.webstripper.net, www.esalesbiz.com/extra, and www.softbytelabs.com.

Web site mirroring software will generally follow all links on a Web site and copy discovered files to the auditor's hard drive. In configuring them, rules can be set limiting the software to specific domains or preventing downloading certain file types.

Experience Note

WGET is a UNIX tool to mirror Web sites and may be found at http://wget.sunsite.dk.

Once a Web site has been downloaded, the auditor can open the pages in a simple text editor application, such as Notepad or Vi, and review the HTML content. Auditors should review coding for e-mail addresses, names, addresses, passwords, and other information useful to an attacker.

Accidental Error Messages

It is not unusual for Web servers to mishandle unanticipated user input. They fail to adequately address incorrect input and frequently provide verbose error messages that can provide valuable information to an attacker. For example, if a user incorrectly entered her user name information, the system might respond with an error message such as We were unable to find an account for this user name, click here to enroll. If the user inputs an incorrect password, the system might respond with an error message such as You have entered an incorrect password, you can reset it by clicking here.

Attackers can use overly informative error messages to either launch a denial-of-service attack or attempt to engage a brute-force attack against the password entry. A more appropriate error message is one similar to: There has been a user error; please provide the correct input. Auditors must be mindful that authorized user logons should never be the same as the user names used by the organization's e-mail naming conventions. From an attacker's point of view, the e-mail user naming convention being the same as the user name logon is having half the problem solved for a successful attack.

Some Web sites permit an unlimited number of failed sign-on attempts without being locked out. The vulnerability in this flawed practice is that user accounts can be compromised via brute-force attacks targeting the Web site's password entry.

Brute-force attacks are either manually or automatically performed where alphabetical and numerical combinations are tried as data entries to gain entry. From a preventive control stance, the sign-in policy should be that the user is locked out for a specified time after three failed sign-on attempts.

Experience Note

Remember, even this policy is not without a threat potential in that an attacker can target the sign-on with incorrect data entry and lock out a legitimate user when she attempts entry. Having a viable and acceptable user reactivation policy is an important aspect of this preventive control.

There is a useful password-guessing tool to be found at www.tlsecurity.net/windows/cracker/webcracker.htm. This tool will automatically brute-force passwords in HTTP basic authentication and form-based authentication. Auditors should attempt to gain entry through brute-force methods as a means of testing entry security.

Another method that may have some success in defeating brute-force entry tools is to avoid direct linking to the sign-on function. For example, Web pages found behind the sign-on function should have a referrer field where the originating Web page of the user is checked against the allowed Web page URL, uniform resource locator.

Another method defeating some attacks is the error message, "inactivity timeout." This action causes the user's session to be terminated after a predefined period of inactivity. Auditors may test and verify this procedure by opening a Web page session in a sensitive area such as an E-commerce site where financial or personal information is collected. The server should terminate the session after predetermined period of user inactivity. This step prevents someone from hijacking the user's session.

More Unexpected User Input

There are a variety of ways that user input can be different from what was anticipated by the Web page developers. The size of the input can be too large, or too small. The input's content can be inappropriate in that alternate characters or executable scripts may be used causing the server to execute the input. Developers should incorporate user input screening in their programming routines. These are the types of input that should be filtered:

Metacharacters are special characters that represent something other than what they are themselves. For example, the ; (semicolon) is a command separator and the ? (question mark) is a match for a single character.
HTML delimiter characters such as "<" and ">".
Path redirection such as "/../" or ".." indicate the user is attempting to access the directory structure outside the Web server's Web page. These are known as regular expressions and must be screened before being processed by the server.

Experience Note

User input must always be screened with all improper input denied.

Overflow Vulnerabilities

Improperly validated user input to the Content-Type header can cause a buffer overflow condition. As a result of nonvalidated user input, excessive data copied onto the data stack can overwrite critical parts of the stack frame such as the calling function's return address, potentially permitting remote code execution with root privileges on the Web server. It is important for auditors to determine if user input is checked for correctness and any input other than the expected input merely returns an error message.

Additionally, it is important that not only user-supplied input is screened and verified, but everything coming from the user's browser to the Web server should be filtered. Users can put executable code within the URL address and without proper filtering, it is possible that user input may be executed by the server.

Hidden Form Elements

HTML supports a form element called "hidden." These variables along with their included values are sent to the user by the Web server and in return get embedded into the HTML response to the user. These hidden elements were never intended to be seen by the user nor were they supposed to be changed or manipulated.

Users can alter these HTML elements changing their values causing unexpected input results. It is relatively a simple process for the auditor to download the Web page, change the HTML in a simple text editor, save it and then replace the Web page in the browser and have the page submitted to the Web server. For example:

  <Form Action = " http://www.xyzcorporation.com/cgi-  bin/search.cgi"  Method = "Post">  <TD><Input type = "text" name = "query" size = "30" MAXLENGTH  = "40"  <Value = ""></TD>  <TD align = center><input type = "submit" value = "search"></TD>  <Input type = "Hidden" name = "user name" Value = search"></form>

Users may change the last value statement to [value = "/etc/password"]. It is possible if the user input were not filtered, it could result in the password file being passed from the server to the user's browser. There is a practical rule of thumb, when filtering user input, it is best to define permitted characters and deny everything else as opposed to attempting to predict everything that is not permitted and removing those elements. Basically, the rule is this one, if it is not specifically allowed, it is denied. For example, if a form is requesting a person's telephone area code, nothing more than three numeric digits are acceptable and all other entries are denied resulting in error messages.

Attackers can easily use search engines such as www.Google.com to find potentially vulnerable fields in Web pages. For example, if an attacker were looking for vulnerabilities on the XYZ Corporation Web page, she enters the following in Google: "type = hidden" and "name = price" site: xyzcorporationonline.com. Using search engines with entries similar to this entry will reveal all pages within the domain, xyzcorporationonline.com that contain strings of "type = hidden" and "name = price." These hidden fields are used to pass price information to the Web server. If the user-input information is not screened for correctness, the price paid may be significantly less than the actual price. For example, a Web page that states the purchase information for a particular product. Frequently, the page is downloaded to the user's browser and a request of the user is made to indicate the number of the product the user wishes to purchase. The user downloads the HTML and changes the price of the product from $500 to $5 using a text editor, saves the modified page and submits the page to the server for processing. The order is processed as there is no more field checking in the shopping cart software. With the order shipped, the vendor is shorted $495. It is important that auditors consider that this type of financial attack is possible by testing the shopping software and making certain that all user-inputs are checker for correctness.

Get vs. Post Commands in CGI Forms

Auditors should carefully examine the method used by Web developers to collect and send user-supplied data. In world of HTML and where CGI, common gateway interface scripts are used, there are two methods of transmitting data. In HTML, the default method for form requests is Get so if the developer did not specify the attribute from the Form tag, the system will assume the developer meant Get. The Get method is the easiest request method. It requests a document from the Web server. When the browser uses the Get method to request a document from the Web server, the request looks like this example:

  GET HTTP1.0/index.html

When a form is submitted using the Get method, the URL-encoded data is tacked onto the end of the URL that's requested, with a question mark inserted between them as a separator. So, if the auditor were to submit the data in a form using the Get method, it could look something like:

  GET HTTP/1.0/CGI-BIN/SAMPLE.CGI?USER NAME = ALICE+DOE

The Web server is programmed to send everything after the question mark to the CGI script sample.cgi file for processing. A problem with the Get method is that it does not provide any privacy to the user. Using the Get method has some possible user-related problems:

It exposes user parameter values in the user's Web browser history file.
It exposes user parameter values in the Web server's audit logs.
It exposes user parameter values in the server's proxy logs.
It exposes user parameter values at other Web sites via the HTTP referrer field.

It is possible that using the Get method may cause URLs to contain sensitive information such as account numbers, passwords, user names and addresses. Browser security exploits may permit malicious Web sites to steal the user's browser history file. If an attacker should gain physical access to the user's workstation, it is possible for her to steal the browser's history file and all the user-sensitive information it contains.

From the auditor's point of view, the preferable HTML method for forms is the Post method. The Post method sends the form data back to the Web server after the headers are sent. Using the Post method adds the attribute as:

  METHOD ="POST"

to the Form tag used to create the HTML form. For example:

  user name = Alice+Doe

The Post command tells the server to expect more data after the reset of the header is sent. A blank line is included between the header and the posted data to let the server know when the browser is finished with its header and is starting to send the actual form data. There is a difference between the Get and the Post methods in the way the form data is communicated from the Web server to the CGI program. In the Get method, data is stored in an environment variable, where it can be accessed by the CGI program. In the Post method, the data is submitted to the Web server and from there directly to the input of the CGI script.

So what is the best method for form handling in CGI? For nonsensitive routine matters, Get is an acceptable form handling method. There are many examples of search engines on the Internet that use Get as the form handler. For form data where there should be some expected or required degree of security, the Post method of form handling is the preferred method. Auditors reviewing HTML downloaded from the audit targets Web pages should be looking for these distinctions.

Web Page Referrer Fields

Current versions of HTML support the HTTP referrer header field. When a browser follows a link, the referrer field can contain the URL of the page the user came from. The referrer field can also be present when a form is submitted to the Web server for processing. Web Servers can check the referrer field when receiving a completed form and reject it if it did not come from the permitted URL. If this filtering action is performed, attacks from anywhere other than the specified URL should fail. Auditors should be mindful of referrer fields in the case of sensitive information being provided as form-input.

Unicode Input Attack

Unicode is one the Internet community's attempts at forming a single set of characters across all languages. Web servers such as Microsoft's Internet Information Server, IIS, supports the Unicode character set. Accepting and processing Unicode potentially leads to vulnerability exploits in the IIS Web server's reading and executing the Unicode script supplied by the attacker.

This attack is common and usually one of the first launched by attackers when an IIS Web service is found. There are easily available scripts that can be downloaded from the Internet that do not require the attacker to have any knowledge of their function before using them. The Unicode bug in IIS is basically one where a prohibited Unicode encoding of the "/" allowed users to craft URLs that could jump outside the Web document directory and call the command shell command, cmd.exe inside the Windows file system. The exploit is successful because IIS performs only one security check after the first script decode and as a result performs the request, as there is not a subsequent security check performed after the second decode pass. This vulnerability is run in the URL like this:

http://www.xyzcorporation.com/scripts/…%255c…%255cwinnt/system32/cmd.exe?/c+dir+c:\

The URL causes the IIS Web server to interpret the Unicode characters as back slashes, bypassing the normal Web server filtering for such events, and moves two directory levels above the location of the/scripts/directory, and targets the/winnt'system32/cmd.exe.

Following are some examples of double decode variations:

%255c
%%35c
%%35%63
%25%35%63

These are not the only combinations. Many more are possible. For these reasons, user-input validation becomes very important. Auditors should also examine the system and change controls Web servers receiving the latest update patches as Microsoft currently delivers an IIS patch addressing these vulnerabilities.

Cookie Pal

Cookies are small fields of text data created in a file that a browser stores and uses to maintain its state and to retrieve information from the Web server. However, if an E-commerce site is using cookies, Web servers can be fooled into delivering more information than they should. For reference, there are basically two types of cookies, session and persistent.

Session cookies remain only in the system's memory and are temporary fields of data held in the workstation until the client's browser is closed. Supposedly they are valid for the time the user is using specific Web site services. Session cookies are generally valid for finite periods of time. Unlike session cookies, persistent cookies are held on the workstation's hard disk and are read by the browser when requested to do so. For example, in Microsoft's Internet Explorer, persistent cookies are held in the C:\Documents and Settings\Administrator\Cookies directory.

The Cookie Pal application is a shareware program available at: www.kburra.net/. Cookie Pal permits control of both the session cookie and the persistent cookie before being lodged in memory or recorded on the hard drive. Basically, Cookie Pal intercepts the request in the Web server's response and displays it in a dialogue box.

Remember, cookies frequently hold user information as stored user names, passwords, preferences, mailing addresses, and online identification. It is important to note that often cookies contain a significant amount of information valuable to an attacker. Attackers do not usually have access to cookies unless they can gain access to a user's workstation. Cookie Pal allows an auditor to intercept a cookie and examine its contents. This is an extremely useful technique when auditing the cookies being placed by the organization's Web site.

A possible attacker ploy is to modify the cookie containing the number of times the Web page had been visited by a user. It may be possible to change the cookie reflecting the number of user visits with some exorbitant number of visits possibly causing a server buffer overflow to occur if the user-input is not checked for correctness.

Achilles

Achilles can be one of the more useful tools for actively auditing Web applications. It is a Windows-based utility and is capable of acting like a Web proxy, where information is captured before being sent back to the Web server. It is a free tool and available at: http://www.digizen-security.com/projects.html.

Achilles allows the user to intercept Web page information, modify it, and send it forward to the server. This ability to modify information on the fly is a tremendous ability permitting an attacker to efficiently attempt code-injection or value changes before the information goes on.

Achilles' configuration is fairly straightforward. Click on the "Intercept Server Data (text)" checkbox in Achilles, and then make a request of the Web server. The client's request will get intercepted, as well as the server's reply. The server's reply can reveal the cookies being set, management attempts on the part of the server, and any fields that may be modified later by the user before being sent onto the Web server.

Automated Web Tools

Automated Web site vulnerability tools look for vulnerabilities in CGI scripts and other exploitable areas. Network vulnerability tools sometimes have utilities testing Web site weaknesses. They may simulate attacks in the fashion of Nessus having modules that test areas such as password strength and CGI vulnerabilities.

Whisker

Whisker is a PERL language-based CGI scanner and it is one of the most comprehensive CGI vulnerability tools. It scans a target Web site and compares it against a database of known vulnerabilities. Applicable vulnerability database files are updated from the Whisker Web site. It is configurable and has a default database of script files that is fairly comprehensive. It is available from: http://sourceforge.net/projects/whisker/.

Basically, it is a universal tool and can be used in a UNIX or a Windows environment if PERL is downloaded on the scanning computer. To use Whisker, execute it from the command line and provide a target IP address or host name of the target Web server. It is a bit difficult for someone not comfortable programming in PERL; however, it is considered as one of the best CGI vulnerability scanners available. Using Whisker is run from the command line like this:

  C:\nt\whisker\v1.4>whisker.pl -h 127.X.X.6  whisker/v1.4/rain forest puppy/www.wiretrip.net -   = - = - = - = - =   = Host: 127.X.X.6   = Server: Apache/1.3.0 (Linux 6.2)  200 OK: HEAD/cgi-bin/creditcards  200 OK: HEAD/clearinghouse/

In this case, Whisker identified the Web server as Apache version 1.3.0 running on Linux version 6.2. Whisker identified two important links that could provide temptations for an attacker interested in obtaining credit card information or information about the clearinghouse.

SiteScan

SiteScan is a fairly useful tool for finding Web site vulnerabilities. ^[10] It is a Windows-based tool and is easy to install, configure, and launch. There is a bit of a downside in that this tool is dated. However, many of the exploits identified by this tool are relevant for auditing purposes as Web site administrators frequently fail to keep their systems updated with the latest patches.

Brutus

This is essentially another password brute-force testing tool. ^[11] It is a fairly simple tool to use and delivers an easy way to test authentication mechanisms via brute-force attacks. Brutus is Windows-based and is a tool that is not restricted to HTTP. Brutus can attack FTP, telnet, POP3, and SMB password accounts. Because Web servers were intended to handle large numbers of requests, it is one of the easier areas on which to force an intrusion and gain access.

Experience Note

Automated vulnerability tools are effective and for the most part efficient. However, they should not be used as the sole means of assessing systems. Automated tools are limited to the vulnerabilities listed in their database or the potential passwords located in their dictionaries. They cannot examine policies, procedures, and standards. They are merely tools, among all the tools, available to the auditor and should not be allowed to replace experience and good judgment.

Quality Control Issues

There are quality matters about which auditors should be concerned. Assessments of Web-enabled applications are important and generally require a significant amount of work. Evaluating Web applications is much easier while in the testing phase before they enter the production environment. Web application assessments should be completed after the Quality Assurance Unit has done their job, and before actual User Acceptance Testing, UAT, is commenced especially if real customers are going to be used. It is possible that real customers have malicious intent or they accidentally discover a security flaw during the UAT. Auditors should remember the following:

Test sign-on processes
Test sign-off processes
Test modified user-supplied input
All user input must be filtered at the Web server for proper size and content type before being accepted and acted on by the CGI scripts
All CGI Output in the form of HTML and HTTP must be scrubbed of comments, error messages, sensitive information, and hidden tags that identify the Web server's version and any third-party products
All CGI defaults must be removed or secured before going into a production environment
Test error messages for degree of information
Test logical sequences
Test HTML in Web page content assuring that it does not contain any sensitive information
Web application assessments are dependent on the knowledge and expertise of real people; using a manual and automated approach generally assures accuracy

Reporting Vulnerability Assessment Results

It is recommended that automated vulnerability assessment results occupy a separate section of the audit report. Of course, before any automated tool results are made part of the audit report, auditors must verify the findings of their tools. It is not professionally diligent to take the tool's results and include them in the audit report without further corroboration.

Audit team members must verify reported vulnerabilities. With this being said, once verified vulnerability findings should be ranked relative to their risk and potential for exploitation. Rankings should generally fall in three categories, low, medium, and high. In the realm of exposure, vulnerabilities may be labeled to detail the area required for leveraging the vulnerability usually defined as "remote" or "local." Remote vulnerability permits an attacker to exploit the system's weaknesses from across the network without having prior access to the target system. A local vulnerability requires the attacker to have some type of system access before being able to exploit vulnerabilities. Before completing the report, auditors must answer the question, "how popular is the vulnerability I have found, and if exploited what is its greatest impact?" Many vulnerabilities and corrective actions may be found at these Web sites:

www.sans.org/top20htm
www.cert.org
www.cve.mitre.org
www.securityfocus.com

If the auditor's findings are among the more common vulnerabilities listed at these Web sites, the chances are very good that your vulnerabilities are currently being attacked and have already been exploited or they will be shortly. Auditors should make their findings known to senior managers as soon as possible and recommend which controls should be implemented. Vulnerabilities that are found will likely be listed among the CVEs at www.cve.mitre.org along with their corresponding corrective action. If corrective steps are taken, auditors should verify the corrections making certain they are noted in the final report.

Audit findings detected during the automated vulnerability assessment should be evaluated in the light of their business impact. In other words, they should be gauged according to their potential to adversely affect the organization's critical assets.

High: These findings are the most significant and pose an immediate danger to the security of the company's critical assets. These findings must be addressed before the audit report is drafted. Do not wait. Report these findings to senior managers immediately.
Medium: These audit findings should be addressed according to a specific timeline.
Low: These are low priority findings and should be noted and implemented on a scheduled later date. They do not pose a risk at the present time.

Audit Findings

Audit findings generally have several elements. These elements include a title, risk rating, description, potential risk impact, affected systems, recommendations for corrective action, and references for further details (Exhibit 27).

Exhibit 27: Automated Vulnerability Sample Finding Report

Finding	DNS Cache Corruption Potential
Description	Versions 4.5, and below, of the DNS application known as BIND are vulnerable to attack where individuals cache incorrect name server information on the DNS server. This action allows the attacker to "spoof" the DNS name server and redirect Web access to another Web page. Further, this vulnerability permits the attacker to bypass name-based authentication mechanisms.
Potential business risk	Because the XYZ Corporation uses E-commerce extensively, comprising approximately 89 percent of its current business revenue, this vulnerability permits users to illicitly access the interior File Transfer Protocol, FTP, server, xxx.xxx.xxx.xxx from the Internet. This is a high-priority audit finding and was verbally brought to the attention of Ms. Senior Audit Manager, on 12 December 2002 at approximately 1600 hrs.

Finding

DNS Cache Corruption Potential

Description

Versions 4.5, and below, of the DNS application known as BIND are vulnerable to attack where individuals cache incorrect name server information on the DNS server. This action allows the attacker to "spoof" the DNS name server and redirect Web access to another Web page. Further, this vulnerability permits the attacker to bypass name-based authentication mechanisms.

Potential business risk

Because the XYZ Corporation uses E-commerce extensively, comprising approximately 89 percent of its current business revenue, this vulnerability permits users to illicitly access the interior File Transfer Protocol, FTP, server, xxx.xxx.xxx.xxx from the Internet. This is a high-priority audit finding and was verbally brought to the attention of Ms. Senior Audit Manager, on 12 December 2002 at approximately 1600 hrs.

	Affected System
Name	IP Address	Information
NS1.exampleonline.com	xxx.xxx.xxx.xxx	DNS Server
Recommendation	On 12 December 2002, at approximately 1700 hrs, the BIND DNS server was updated to version 9 with all attendant security patches. This implementation was made as a "clean" installation and was implemented across the XYZ Corporation and its subsidiaries. This recommendation was forwarded to its business partners who were urged to update their systems.
References	CERT Advisory CA-97.22 BIND

Audit Issues

Audit reports should contain possible system issues. Issues are narratives of industry best practices regarding particular risk factors. They should be included in the auditor's report to augment a specific finding or to enhance the overall understanding of a particular topic. For example, an issue may detail best practices for configuring ingress traffic on your exterior router. Issues do not generally have risk ratings and should be presented in professional tones.

^[10]Available at www.hackers.com/html/archive.5.html.

^[11]This tool is a download from www.hoobie.net/brutus.

< Day Day Up >