Website Vulnerabilities and Nikto..!!!

Nikto is an open source Web server vulnerability scanner that performs comprehensive tests for over 6,100 potentially dangerous files/CGIs, checks for outdated versions of over 950 servers, and for version-specific problems on over 260 servers. This article outlines a scenario where Nikto is used to test a company’s Web server for vulnerabilities.
                           

As detailed on www.cirt.net/Nikto2, Nikto, written by Chris Sullo and David Lodge, also checks for server configuration items, such as the presence of multiple index files and HTTP server options, and it attempts to identify installed Web servers and software. Scan items and plugins are frequently updated, and can be automatically updated on your system. Nikto also supports libWhisker’s anti-IDS methods in case you want to test your IDS system. It is available for almost all flavours of Linux, as well as for Microsoft Windows and Mac OS.

Important terms

Asset: A resource of value, such as the data in a database or on the filesystem, a system resource, etc. Threat: A potential occurrence (malicious or otherwise) that may harm an asset. Vulnerability: A weakness or entry point that makes a threat possible. Attack: Hostile action taken to harm an asset. Exploit: A security hole which can potentially allow an attack. Countermeasure: A safeguard that addresses a threat and mitigates risk.

A tale of a website attack

Shree is the CEO of a small business with a global clientele. Early one morning, he received an urgent call from one of his employees, who told him that the company website, which many of Shree’s clients used regularly for business, was being identified by Firefox as a “reported attack page” (Figure 1).

Figure 1: Reported attack page

It appeared that the Web server had been cracked, and was now serving malware to visitors, including Shree’s clients! Worried about the fallout, Shree made an emergency call to his website developers, who immediately brought down the site, and restored a clean backup onto it. For a few hours, things were okay — but then, the site again began to exhibit the same problem. Shree was now a really worried man — the future of his business was at stake.

At this point, he called in his long-time friend, Kedar, a Web security expert, for emergency help. Kedar rushed to Shree’s office  and took charge of the situation. His primary intention was to restore the website to normalcy as soon as possible, while he promised to explain the incident after the site was up again.

Kedar took the precaution of downloading a copy of the compromised website to a local PC at the developer’s office for scanning. (Under Indian cyber law and its amendments, running any scans, including a port scan, against a website can be a criminal offense.) In addition, a local copy meant that there was no Intrusion Detection System to counter, and the scan would finish much faster at LAN speeds than over an Internet connection.

The Nikto scan revealed some interesting information — the site had been attacked using two exploits:
microsoftoffi cewebserver and x-pingback. Here’s the output of the scan, with client-specific references obfuscated:

nikto -host XX.XXX.XXX.XX -vhost www.XXXXXXXX.XXX -p 80 443   - Nikto v2.1.1 --------------------------------------------------------------------------- + Target IP:        XX.XXX.XXX.XX + Target Hostname:  IP.targethostname.com + Target Port:      80 + Virtual Host:     www.XXXXXXXX.org + Start Time:       2010-XX-XX 13:02:35 --------------------------------------------------------------------------- + Server: Microsoft-IIS/6.0 + No CGI Directories found (use '-C all' to force check all possible dirs) + Allowed HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST + Public HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST + Microsoft-IIS/6.0 appears to be outdated (4.0 for NT 4, 5.0 for Win2k, current is at least 7.0) + Retrieved X-Powered-By header: ASP.NET + GET /: Retrieved X-Powered-By header: PHP/4.4.7 + GET /: Uncommon header 'x-pingback' found, with contents: http:/www.XXXXXXXX.XXX/xmlrpc.php + Retrieved microsoftoffi cewebserver header: 5.0_Pub + Uncommon header 'microsoftoffi cewebserver' found, with contents: 5.0_Pub + OSVDB-12184: /index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests which contain specific QUERY strings. + OSVDB-3092: /test/: This might be interesting... + OSVDB-3092: /LICENSE.txt: License fi le found may identify site software. + OSVDB-3092: /xmlrpc.php: xmlrpc.php was found. + /wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version + /readme.html: This WordPress fi le reveals the installed version. + OSVDB-3092: /license.txt: License fi le found may identify site software. + OSVDB-3092: /LICENSE.TXT: License fi le found may identify site software. + 3823 items checked: 14 item(s) reported on remote host + End Time: 2010-03-11 13:47:19 (2684 seconds) + 1 host(s) tested

A Google search revealed that the exploits were related to the popular WordPress publishing platform used for the website, and also revealed possible solutions to the problem. The website was vulnerable to attack because the website developers had not taken the trouble to install updated versions that addressed known vulnerabilities.

After updating the local copy of the site according to the recommendations, Kedar ran another Nikto scan. A few more security vulnerabilities were reported, including a few unnecessary folders on the website. The errors were corrected, and when a final Nikto scan verified that the site didn’t have any known vulnerabilities, it was uploaded to the Web server, overwriting the compromised site. The site has been up and running perfectly till date.

The anatomy of an attack

Now that the website was back up, Kedar explained the details of the incident to Shree from scratch, beginning with defining what Web pages, websites and Web applications were, and the importance of securing them. We’ll skip much of those elementary concepts, however, and move on to the analysis of how website attacks happen.

One of the biggest considerations for websites and Web applications is that they are required to be up and running 24×7. They are potentially accessible to anybody around the world, round the clock. Sensitive information that can be misused for monetary gain, or used to hold the site owners to ransom, coupled with the 24×7 availability of the site, attracts crackers to attack the site to access confidential data.

An attacker’s basic approach to breaking into a Web server is as follows:

1. Survey and assess the potential target: The attackers find out what types of services are being used on the target website, what operating system and Web server software versions it runs, the additional software used, etc., and attempt to find possible vulnerabilities and entry points in supported services and protocols. This information is then used to plan the initial attack.
2. Exploit and penetrate the target: The attackers then use attacks corresponding to the discovered vulnerability to penetrate the site. If the network and host are fully secured, your Web application is the next target for attack. An attacker’s easiest entry to an application is through the same “gate” that legitimate users pass — the application’s login page, or a page that does not require authentication.
3. Escalate privileges (try to gain administrative privileges): After attackers compromise an application or network, they immediately attempt to gain administrative privileges to take over the server itself. Using least-privileged service accounts throughout your application is a primary defensive feature.
4. Maintain access and privileges: Having gained access to a system, attackers try to ensure future access and to cover their tracks. To retain administrative privileges, attackers commonly plant backdoor programs or use an existing account that lacks strong protection.
5. Cover their tracks by clearing logs: Since system logs will reveal unauthorised access to the system, attackers typically clear audit logs of tell-tale signs, and hide their tools and other evidence of their access. Your log files should be secured (preferably, by regularly copying them to a remote system), and should be analysed regularly. This analysis can sometimes reveal an attempted break-in before damage is done.
6. Steal information and distribute malware: Attackers usually try to install programs that may steal confidential information or attack other computers. They may also set up the site to distribute malicious software to visitors who trust the site not to serve them malicious software.
7. Deny service: Attackers who cannot gain access may mount a denial of service (DoS) attack to harass the site owner by preventing legitimate users from connecting to the site. The sheer variety of Web threats and attacks makes it impossible to explain all of them; we have merely looked at a brief outline.

To prevent website falling prey to attackers, your IT team needs to audit your websites for vulnerabilities corresponding to your Web server platform and software. The audit frequency should be every three months, at least, besides immediately after a new vulnerability is reported. Free newsletters from CERT/SANS provide updates about such vulnerabilities from time to time.

You can block attacks by disabling relevant services or patching application code, until the software vendor provides an update that closes the vulnerability. Further, vendors need to pay attention to the website’s design and code, and check whether there are potential entry-points for attackers.

You should also ensure a few very basic — but very important — points:

1. Change default login name
2. Change default password
3. Only use encrypted interface to authenticate yourself to the website (HTTPS/SSH)
4. Make sure the password consists of upper/lowercase alphabets, numbers and special characters.

The Nikto advantage

As a website vulnerability scanning tool, Nikto plays a vital role in keeping your site safe. It can be used very effectively to identify flaws in the design and development of the website, and as an assessment tool to detect possible vulnerabilities in the website. In case of an exploited website, it can also be used to identify the attackers’ entry point, as Kedar did for Shree’s site.

Important Nikto command-line options include:

• -Cgidirs — Scans the specified CGI directories; could also be special keywords all or none.
• -dbcheck — Checks the scan databases for syntax errors.
• -findonly — Only discovers and attempts to connect to HTTP(S) ports, does not perform a security scan. Reports the server header.
• -host — Specifies the host(s) to scan
• -id — Specifies basic host authentication in id:password format
• -port — TCP port(s) to scan; comma-separated list (80, 443, 8080 ) or port range (80-90)
• -update — Updates the plugins and databases from cirt.net.

Other command-line options let you fine-tune the scan, including:

• -mutate — To combine tests and to guess values. Under the -mutate commands, various parameters can be provided to guess common password file names, guess common file extensions, try to discover valid user names by using Apache exploits if UserDir setup is misconfigured, exploit flaws in cgiwrap to discover valid user names, and more.
• -Tuning — Tunes the scan tests used against a target.
• -Format — Specifies the output file format: TXT, HTM, XML or CSV.

See the documentation for more information on these topics, and other options.

Nikto’s configuration file is typically /etc/nikto.conf. You can set commonly-used settings in this file, to cut down on the length of command lines for each scan. See the documentation for more information.

Nikto can also be integrated with Nessus and OpenVAS,two of the best vulnerability scanners available.

Now, returning to Shree, whose website had suffered the attack — he was amazed at the technical complexities of what he had thought was the simple Internet, but was grateful to Kedar for the quick and decisive solution to the problem. At Kedar’s instruction, Shree modified his company’s security policy to include a monthly Nikto scan of the website for vulnerabilities. Shree is a happy person again, since his website is running well, and he hopes Nikto will help him stay ahead of the bad guys!