| 2005: The year that was |
[Jan. 1st, 2006|08:58 pm] |
2005 saw 84 documented defacements of Australian websites. 63 of these were Government websites - and the vast majority of these were State / Territory and Local Government Websites. In May, a Queensland-based website that called for a boycott of Bali was compromised within an hour of going online.
This far, we have been fortunate that most attacks have been little more than vandalism - redirections to Turkish websites, images of Middle Eastern flags, and just plain "I was here and you couldn't stop me" messages. Most electronic attacks were sourced externally and DoS attacks continued to be the gretest cause of financial loss.
In most cases, the affected website was unusable for several hours, with normalcy restored only after 24 to 48 hours, leaving us to wonder whether Intrusion Detection Systems and Incident Response Plans exist. We've been amused with statements like "It was an attack on our infrastructure; not on our organisation" and "The website only contained public information anyway".
The 2005 survey by AusCERT showed that despite of the wide-spread use of IT Security Standards (65% as compared to 35% in 2003), only 7% of respondents believed that computer security issues were being managed reasonably well! the "pain areas" for 2005 were inadequate staff training in computer security management and poor security culture within the organisation.
Interestingly, the AusCERT survey indicated that only 18% of incident allegations reported to law enforcement agencies resulted in a charge. With such poor odds of redressal, the best strategy is incident avoidance through vigilence and protection. The World Wide Web is a war zone. Being out there without your armour is suicide. |
|
|
| Using HTTP GET Calls in your website. |
[Jun. 25th, 2005|10:39 pm] |
Recently I logged into a school website to check my niece's results. I had to login using her user-id and password first. Presumably, this would allow me to see her results for each unit she has completed so far. There were a couple of very basic security flaws with the website. First, the login form was submitted in plain-text HTML without SSL - meaning that anybody with a rudimentary packet sniffer could intercept and read the login credentials. Second, on login, the system seemed to validate the password and then append the Student ID to all subsequent GET requests. That was how the system knew which student's details to display. By tweaking the Student ID parameter in my Browser navigation bar, I could see the results of other students. Obviously, this was a breach of the basic security and privacy requirements of a public website.
Another shining example of poor GET request validation was on a local agency's website search page. The user was presented with a search form that allowed the user to enter the search terms, and then limit the search extents by selecting one of the values from a drop-down list that included values like
"this website only",
"all australian websites", or
"the web".
Entering "child support" and selecting "all australian websites" returned a results page with the heading "Your search for child support within all australian websites found the following results...".
I found that the GET request constructed was something like this "http....&searchString=child support&within=all australian websites"
I was able to get some amusing responses by tweaking the URL request. For example, "http....&searchString=intelligence&within=the parliament" got a response saying "Your search for intelligence within the parliament found no results" It took a good deal of self-restraint not to send this URL to my friends and acquaintences.
The moral of the episode is to use HTTP GET requests with extreme care. Use POST requests wherever possible. If you really need to use GET, ensure that each parameter is carefully validated. If possible, parameterise parameters. For example, in the example above, if the site used "...&within=1" to mean "this website only", "...&within=2" to mean "all australian websites" and so on, it would not have been possible for a user pass in arbitrary string data. Does your website handle missing HTTP GET parameters elegantly?
Inadequate GET request validation could lead to compromise of confidential data, unauthorised access to private information, or inappropriate content being displayed on your website.
|
|
|
| Running a Secure Website |
[Jun. 13th, 2005|01:07 pm] |
Ok, so you have a Web service that has been Penetration Tested. You run it in a "secure" environment, which no unauthorised user has access to. You even use a Network Monitoring system to make sure you don't have uninvited visitors in your network. And you get this warm fuzzy feeling that your system is safe. Why wouldn't it be?
For starters, new exploits and security vulnerabilities are being constantly found and fixed. Software that may have been deemed secure at the time your Penetration Testing was done, may no more be so. You need to quickly apply the security patches or upgrade to newer versions, leaving your systems vulnerable for the shortest possible time.
While your network is being monitored for illegal activity, you should know that some exploits do not need network access, but can be launched from the Internet. I have explained Cross-Site Scripting and SQL Injection attacks, which fall under this category, in an earlier posting. So unless you shutdown HTTP traffic, and thereby possibly your website, you may be vulnerable to these kind of attacks.
Over time, new services may be deployed on your Web Service hosting server or others servers on the same network, that may open up new vulnerabilities which did not exist at the time Penetration Testing was done. Most Penetration Testing includes a scan of all possible ports on the server to ensure that unnecessary ports are not accessible. However, this is useless in case one or more ports are opened up later for any reason whatsoever. A random security breach that may have been detected and terminated quickly, may have been enough to install a backdoor entry point or run processes that could compromise the security of the system.
For these reasons, a one-time Penetration Test is sadly inadequate to guarantee the security of your website.
There is only one known way to secure your Website completely, and that is to take it offline. That not being an option, consider the following measures:
- A repeat penetration test at least every 3 months.
- Weekly monitoring of log files.
- Constant network monitoring and intrusion detection.
- All software upgrades or patches installed after the initial Penetration Testing should be vetted by a Security Officer.
- Daily monitoring of processes running on the server to detect any unauthorised processes.
- Daily scan of server to detect unauthorised open ports.
The key to running a secure website is vigilance. Regular monitoring and inspection of your system and its logs is crucial to minimising the impact of a security breach.
|
|
|
| Keeping an Eye on your Website |
[Jun. 12th, 2005|05:49 pm] |
Every website is a potential target for malicious activity. With the Internet rapidly becoming more accessible to people in even the remotest areas of the world, the risk of a security breach is high. With each passing day, the number of wannabe “hackers” is increasing, eager to match their wits against the defences your website has to offer.
Unfortunately, till very recently, the people that wrote software believed that application security was the concern of the application hosting guys, or the network guys, or some benevolent force that would keep the bad people away. Instead of secure software, we’ve ended up with layers of security built around vulnerable software. We’ve come to rely on mechanisms like Firewalls, Application Logging, Network Monitoring, etc to keep our software and data protected.
Some of most dangerous security exploits in Web Applications like Cross-site Scripting and SQL Injection are best handled in the application itself. Re-developing the application to address security issues could be an expensive and time-consuming task, if it is at all possible. The good news is that it is fairly simple to identify attempts to exploit these vulnerabilities by the trails left in the logs. This article focuses on the Web Server logs, which would normally log every HTTP GET and POST request.
Cross Site Scripting (XSS)
XSS is possible when your server echoes some data entered by the user. For example, lets say your website has a search functionality. If user does a search for “abc”, your sever probably responds with a HTML page that says “Your search for abc found these results…”. Now the user enters the search string as "<script>alert(‘hello’)</script>", and gets back a HTML page that contains “Your search for <script>alert(‘hello’)</script> found these results…” The user’s browser may interpret this to mean that it should pop up an alert box that says “hello”. Using this technique, a malicious user can embed an offensive image from another site, a form that sends sensitive data to an unauthorised site, or even steal a cookie from the users session that contains private information. Once the user has crafted a URL that exploits the XSS vulnerability on your website, the URL may be posted on a newsgroup or website, or sent by email to an unsuspecting victim.
This is an extremely dangerous vulnerability because it “uses” your website as a tool to launch the attack on the victim. Moreover, by embedding an onload() or onmouseover() event, sensitive data can be silently sent to an unauthorised location without the user clicking on the page – by the time the user realises the page looks suspicious, it is too late.
Fortunately, this kind of exploit is relatively easily to notice in the Web Server log files. Since this attack needs your server to echo the inappropriate content, the inappropriate content embedded in a URL must be sent to your sever first. Any HTTP requests containing the following strings could be indications of an XSS attack:
<script> or </script> (indicates JavaScript embedded into a URL)
<form> or </form> (indicates an embedded form, or attempt to terminate a legitimate form served up by your server)
onclick, onmouseover, onload (indicates an attempt to modify the bahaviour of your form elements)
href= (indicates an unauthorised link embedded in the URL)
src= (indicates an attempt to load an unauthorised image or other file)
Finally, any occurrences of external URLs in your log files like http://external-site or www.external-site or just an unrecognised IP Address must be investigated, as they could indicate an XSS attack.
SQL Injection
SQL injection is an exploit that is possible when user-supplied data is used to construct queries without prior validation.
For example, consider a typical login page, where the user is expected to enter a username and password. The application then creates the following query to validate the login:
SQL = 'select (*) from users where userid = ' + user + ' and password = ' + password + ';'
If the user enters username as "* ; -- " and password as xyz, the query becomes
SQL=select (*) from users where userid = * ; -- and password = xyz ;
If your database recognises the ";" character as the end of a query and the "--" as a comment, the user may be able to compromise your login check.
Another popular hack is to enter the username and password as " ' OR '' = ' ".
In this case, the query formed is
SQL=select (*) from users where userid='' OR ''='' and password ='' OR '' = ''
Since ''='' is always true, the query will return all rows in the users table, and your login validation will be compromised.
Using this technique, an unauthorised user can access confidential data, and perhaps even obtain the entire contents of a table in the database.
Generally, forms that deal with this kind of transactions user the HTTP POST method or use ssh. Therefore, the best place to look for this kind of activity is the application logs, instead of the Web Server logs. The tell-tale signs of this SQL Injection attempts are:
quotes – either ' or " (indicates manipulation of the query parameters)
; (indicates an attempt to prematurely terminate a query, potentially stripping off a ‘where’ clause in the query)
-- or # (indicates an attempt to comment out the remaining portion of a query, potentially stripping off a ‘where’ clause in the query)
*, %, _ (These are SQL wildcard characters and should never be allowed as user input to a query)
Attempts to get Directory Listing
The default behaviour of a Web Server is to allow a listing of the contents of directories in the Web Root unless this is specifically turned off. In itself, allowing a user to see the contents of your directories seems harmless, but this could give a malicious user enough information to plan an attack on your system. I have touched upon this point in an earlier posting.
If your Web server logs contain multiple GET requests terminating with "/", it indicates that a user tried to obtain the directory listing. This is typically done by browsing your site, stripping off the filename from the end of the URL and resubmitting the HTTP request. Multiple such requests coming from the same client is reason enough to investigate.
Remember, a malicious user does not need to login to your servers to launch a XSS or SQL injection attack. Therefore, network monitoring and login control is no deterrent against attacks like this. Your best defence is regular monitoring of your log files for signs of suspicious activity.
|
|
|
| Is your website too verbose? |
[Jun. 8th, 2005|08:53 pm] |
“I often regret that I have spoken; never that I have been silent.” - Publilius Syrus
The first step in a planned attack on your website is the gathering of information about the site, in order to formulate a plan of attack. Obviously, one of the most effective ways to protect your website is to reveal as little information about your website as possible.
Here are some tips to minimise the amount of information your website reveals about itself.
1. Deny directory listings.
Unless you are running a ftp site, your users do not need to view the contents of a directory on your website. Exposing the directory structure and list of files to Internet users is unnecessary and can give a hacker valuable information about your website.
What you need to do: With the appropriate entry in your Web Server configuration file, you should be able to disable directory listings. Consult your Web Server documentation for the syntax.
2. Avoid revealing file names and directory structure in HTML comments.
Too often, HTML comments hanging around from the development days reveal enough information for a malicious user to piece together the directory structure and list of files in the directories.
What you need to do: Remove all comments that reveal unnecessary information like file names, directory structure or other sensitive information. You may be able to suppress comments by an application-level configuration setting, if the application you are running supports it.
3. Minimise the information sent out in HTTP headers.
A simple tool to view what information your server HTTP headers reveal is the good old text-based browser Lynx. Run “lynx –head http://your-server” to see what your HTTP headers contains. Do they reveal the server build number or the SSL version? Once a hacker has this information, it is fairly trivial to identify the vulnerabilities in the product. For example, Apache 2.0.52 is vulnerable to DOS attacks via a HTTP GET request with a MIME header containing multiple lines with a large number of space characters. If your HTTP header announces that you are running “Apache/2.0.52”, you are practically telling a malicious user how to launch a DOS attack on your website.
What you need to do: Minimise the verbosity of HTTP headers by an appropriate setting in your Server configuration file. Consult your Web Server documentation for the syntax.
In Apache, set the ServerTokens parameter in httpd.conf to “Prod”.
4. Customise your error responses.
In case of an error, redirect the user to a pre-defined error page. Not only is this an elegant way to handle errors, it may avoid the display of an error message that reveals sensitive information. For example, if a jsp page being invoked encounters an Exception, it outputs a stack trace that may reveal file names and locations. Setting up an error response to serve up an error page instead, will prevent this information from being visible to the user.
What you need to do: Customise error responses by making an appropriate entry in your Web Server configuration file. Consult your Web Server documentation for the syntax.
5. Minimise published site information.
If your website has a “Site Information” or “About This Site” page, keep the technical details on this page to the minimum. Does the user really need to know the version of Web Server you are using, or the platform your website runs on? Are you revealing information that may help a hacker plan an attack on your website?
What you need to do: Avoid mentioning product names and versions, operating system information, etc on your website. Instead, provide an email address where users can contact the administrator for details, which may be revealed on a need-to-know basis.
Remember, knowledge is power, and more so in the hands of a malicious user. Every superfluous piece of information your website reveals about itself makes it more vulnerable to attack.
DISCLAIMER: This article does not suggest that minimising the verbosity of a website is an alternative to the usual security measures employed (firewalls, intrusion detection, logfile analysis, etc.) |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
dextross's journal