Sathyan Catari's Weblog
Simple Tips to secure your Web Servers.
1). Introduction
2). Scope
Major security forums (e.g., SysAdmin(2), Security (SANS) Institute(3) and the Open Web Application Security Project (OWASP)(4)) do a good job of constantly updating the community in great detail about security threats and mitigation techniques. The following are some well known and most often used vulnerabilities that pave the way for attacks against an organization's web server.
- Communication programs such as Instant Messaging.
- non-existent/poorly administered backup and logging mechanisms.
- weak/no/default passwords
- Cross site scripting(XSS).
- Unchanged default installation and configuration.
- Lazy programming techniques.
- File sharing applications.
3). Administrators role in securing web servers.
Let us look at the some of the of simple techniques that a web server administrator to secure web servers.
3.1). Configure to prevent DOS attacks:
It is important to configure web servers appropriately and not rely on the default configuration. Configured correctly, it is possible even to prevent Denial-of-service attack from reaching the web-server. Denial-of-Service (DoS) attack is an explicit attempt to prevent legitimate users from using a service by some malicious users of the Server. Such an attack can be launched by sending continuous requests to the server for a particular web resource. Most of the web servers of recent times do provide easy mechanism to prevent such attacks. For example Sun Java System Web Server(5) can detect DoS attack by monitoring frequently accessed URI and denying request, if the request frequency is considerably high. It is very easy to tweak the server to prevent Denial-Of-Service attacks by configuring request limits and monitoring maximum number of connections per virtual server.
3.2). Configure not to reveal HTTP headers:
The more information web servers provide about themselves to the outside world, the more vulnerable they are to be attacked. Hackers are always looking for information to exploit vulnerabilities. HTTP response headers are information that is sent from a web server to its client applications(predominantly a web browser). A poorly configured web server might reveal information such as “web server version, operating system name and version” etc., Web server software like other software products have bugs in them and usually the vendors publicly alert their users of such bugs and strongly encourage them to apply fixes/patches to resolve them. If the version of the web server and the operating system it runs on is known to a hacker, it is easy to find out open bugs/vulnerabilities from its vendors site and base their attacks. Freely available programs such as websniffer (6) reveal http response header information. Below is a sample output gathered from hotmail.com web site where the web server version is visible.
HTTP/1.1·302·Found
Connection:·close
Date:·Mon,·10·Mar·2008·19:49:52·GMT
Server:·Microsoft-IIS/6.0
X-Powered-By:·ASP.NET
X-AspNet-Version:·1.1.4322
Pragma:·no-cache
Location:·http://mail.live.com/
Cache-Control:·no-cache
Pragma:·no-cache
Expires:·-1
Content-Type:·text/html;·charset=utf-8
Content-Length:·138
The vendors do not turn off such header information as such information could benefit statistical companies such as Netcraft to gather data, but there are documented ways that an administrator could use to turn them off. As an administrator it is important to follow such post installation configuration to make web server more secure.
3.3). Configure to prevent attacks leveraging search engines:
Search engines are so powerful to penetrate deep into web server during their preparation of index database. Popular ones such as Google uses sophisticated queries to get more information about a web site and unfortunately hackers just leverage the same mechanism. It is quite easy for an average surfer to peek into other people's websites using exploits in search engine mechanism. This type of attacks are very simple to execute but often could cause severe damages.(7) Though these type of attacks using search engines are collectively called as “Google Hacking”, the popular search engine Google is most often used. Network printers, VNCs, Automated cameras are some of the quite common targets of such attacks by average surfers. To avoid such attacks, an Administrator should configure “robots.txt” file correctly preventing search engine access to confidential and sensitive information. If the page has already been picked up by Google and has been cached, then tools such as as Google automatic URL removal system(8) should be used to secure web server. Google also provides other options for removing such information(9).
3.4). Coordinate placement of information and scripts
on the web server with appropriate authorities to prevent from URL manipulation attacks.
3.5). Avoid installing unnecessary tools, samples and 3rd party software
that comes with web server installation. Most of such tools do not follow the same security standard as the web server and hackers often exploit the server through them. Some of the scripts part of the samples are often used by hackers to stage an attack.
3.6). Administer the server with a good patch management system.
It is important to stay up-to-date with the vendor on fixes for bugs in web server. Wherever possible this process should be automated. Good auditing tools such as(showrev on Solaris(10)) will come handy to detect the status of the system.
4). Developers role in securing web servers.
- Attack on a large bank in 2000 by manipulating the account number in URL.
- Acme Art Inc.,'s web site was hacked in October 2001 revealing all credit card information.
- In 2002, a Swedish company's turnover report was accessed by manipulating the year numbers in the URL.
- A simple attack on Harvard Business School's website by prospective students enabled them to check their admission status in 2002.
- Famous pet supply retailer Petco and fashion Label Guess were attacked in June 2003 exposing customers credit card information. These attacks used a technique called SQL Injection.
- In 2004 attack on web servers through the worm named “Santy”.
- In november 2004, SCO's website logo was replaced by the text “We own all your code, pay us all your money”.
4.1). Parameter Manipulation:
Parameter Manipulation is a simple technique hackers use to exploit vulnerabilities in web applications and cause severe damage. This technique modifies data that is being sent from a web browser to a web server. Hackers modify the values of Form Fields, Cookies, URL Query Strings, HTTP Headers and Cookies to their advantage to attack. It is important for the web application developer to understand these sources of attack and take preventive mechanism as part of the application design and development.
4.1.1) Form Fields Manipulation:
This is the easiest of attack that can be performed on a poorly designed/written web application. The functionality provided by almost all of the web browsers on the market “the ability to read the html source” is mis-used by hackers to their advantage. HTML forms use visible and hidden form fields to accept user input and pass them to the web server to be used. Hidden form fields serve the purpose of hiding the values from users are most of the times used by web developers to conveniently store local variables required for the application. This is a very bad design as the attacker could simply read the file, find out the hidden field and manipulate the values before sending it to the server .
Mitigation Techniques: Hidden form fields should be avoided and their usage should be replace by session variables if possible. Other approach would be to encrypt and decrypt the values to be hidden programmatically on the browser and server side respectively using a well known encryption mechanism such as MD5.
4.1.2). Cookie Manipulation:
The protocol used widely in internet HTTP is stateless, meaning that it cannot be used for conversational style of communication. Cookies are used to achieve this. Cookies store data to enable such communication. They store data temporarily for a session or permanently depending on the application needs. There are tools such as Winhex(12) to modify the local data. The following example shows a simple modification that can fool a poorly written web application to execute with “administrator” rights. “Cookie: lang=en-us; ADMIN=no; lvar=1 ; “ can be easily modified to “Cookie: lang=en-us; ADMIN=Yes; lvar=1 ;”.
Mitigation Techniques: Cookies should be avoided to the extent possible and replaced with session variables. In some cases where cookies need to be used, they should be encrypted and validated against session information stored on the server side.
4.1.3). HTTP Headers Manipulation:
HTTP headers hold control information on HTTP request coming from a web client to a web server. Though it is not easy to modify the headers, hackers sometimes make programmatic alterations to the headers often times to take control of the web site or to act as a precursor for other manipulation attacks. One of the field in HTTP header that has been known to get altered is the REFERER field. Simple tools such as modifyheaders(13) makes the job of hackers easy.
Mitigation Techniques: As a web application developer, never rely on REFERER field.
4.1.4). URL Manipulation:
HTML forms are submitted to the server using one of GET or POST http methods. When GET is used, the parameters and values passed to the server are added as part of the URL. This enables malicious users to modify the URL and alter the parameter values to their advantage to orchestrate an attack.
4.2). Cross-site scripting(XSS):
This type of attack is enabled by vulnerabilities in web applications wherein malicious code can be injected(could be html or client-side application) to carry out the attack. Most common way of XSS attack is to bypass access controls. Generally another script or executable is invoked as part of the malicious code to cause damage.
Mitigation Techniques: Simple programming techniques such as filtering out dangerous characters as part of the validation will help. XSS vulnerability scanners come handy during development of such web applications.
4.3).SQL Injection:
SQL Injection attacks are done by injecting SQL strings to access database through web applications. This is an easy attack to carry out if the application that is the target of the attack dynamically creates SQL Queries based on user entered parameters that are not validated. For example, a basic HTML form might have two input fields to allow users to log in to a Web site with a username and password. If the database query that looks up the information relies on the user's input for its variables, without validating that input, the database can be compromised by adding a string to the password input field. For example the query SELECT * FROM Users WHERE UserName ='" + txtuid.Text + "'", conn); that is hardcoded in the web application, can be easily altered as txtuid is user input value. The modification could be changes to the parameter values to cause destruction or appending destructive SQL command(s) to the end of the query strings by using malicious input field values.
It is also important to test the application during development using automatic SQL injection tools. For example SQLMap(14) is one such automatic blind SQL injection tool. SQLNinja(15) is another one.
Golden Rules to follow:
1).Never trust input, especially user input, always validate input.
2).Do Not Make Security Decisions Based on Parameters Accessible on the Client-Side.
3).Follow well established/tested security standards.
4).Use scanning tools: Most of the parameter manipulation attacks can be prevented if developers use scanning tools. A lot of scanning tools are available to identify such vulnerabilities during web application development period itself. Leveraging such tools combined with awareness and intelligent coding would prevent most of parameter manipulation attacks. Some of the popular web application scanners are listed here
1).Scando Web application scanner from Kavado
2).WebInspect from SPI Dynamics
3).Web Vulnerability Scanner from Acunetix.
4).AppScan from watchfire.
Conclusion:
References:
(1): http://news.netcraft.com/archives/2006/04/06/april_2006_web_server_survey.html
(2): http://www.samag.com/
(3): http://www.sans.org/
(4): http://www.owasp.org
(5): http://docs.sun.com/app/docs/doc/819-2629/gdhhn?l=en&a=view&q=denial+of+service
(6):http://web-sniffer.net/
(7):http://www.theregister.co.uk/2001/11/28/the_google_attack_engine/
(8):https://www.google.com/support/bin/topic.py?topic=360
(9):http://www.google.com/support/webmasters/bin/topic.py?topic=8459
(10):http://docs.sun.com/app/docs/doc/816-5166/6mbb1kqf8?a=view
(11): http://www.acunetix.com/websitesecurity/application-scanning-wp.htm
(12):http://www.x-ways.net/winhex/
(13): http://modifyheaders.mozdev.org/
(14): http://sqlmap.sourceforge.net/
(15): http://sqlninja.sourceforge.net/
Posted at 12:51PM Oct 01, 2008 by sathyan in Technology | Comments[0]
Wednesday Oct 01, 2008