Articles in web security zone
MySQL.com Victim of SQL Injection Attack
April 20, 2011 – 8:54 pm | No Comment
Introduction
On 27th March 2011 a message was posted on the popular Full Disclosure mailing list exposing a recent hack against the website mysql.com. This vulnerability was apparently also reported by a group called TinKode, who …
It is possible to manually crawl your website using a web browser. From these manually crawled links, then it is possible to build a website structure which the final scan will target. This is useful when in some rare cases, certain web applications cannot be automatically crawled due to some strange coding ambiguities. The following procedure offers a reliable workaround.
1. Configure the web browser
Configure your web browser of choice to proxy all the traffic through the Acunetix WVS HTTP Sniffer tool, as shown in the above screen shot. Presuming that the web browser is running on the same machine where Acunetix Web Vulnerability Scanner is installed, set the proxy server IP to 127.0.0.1 and the proxy server port to 8080.
2. Start the HTTP Sniffer and start browsing the website using the configured web browser.
3. Once ready, stop the HTTP sniffer. Save captured data by selecting ‘Save Logs’ from the Actions drop down menu.
4. Import Logs to Crawler
In the Site Crawler node, click the ‘Build Structure from HTTP Sniffer log’ button (highlighted in the above screen shot) to import the captured data into the Site Crawler.
5. Save the crawler import results by selecting ‘Save Results’ from the Actions drop down menu.
6. Launch the Scan
Click on the New Scan button to launch the scan wizard. In the first step of the Scan Wizard select the option ‘Scan using saved crawling results’ as highlighted in the above screen shot. Proceed with completing the scan wizard to launch the automated scan against the manually browsed website.
Note: Only the links you’ve manually crawled will be automatically scanned. Other pages in the website, even those linked from manually crawled pages will not be crawled or scanned.
Vulnerability checks in Acunetix Web Vulnerability Scanner version 7 consists of two files;
1. Writing the Vulnerability check script
To write a new vulnerability check script, you can use any text editor of your choice, or else WVS Scripting tool which is available for free.
The tool and detailed Acunetix WVS scripting reference can be downloaded from the following URL; http://www.acunetix.com/download/tools/Acunetix_SDK.zip. We recommend you use our tool since it is specifically designed to assist you in writing Acunetix WVS Vulnerability Checks. It also includes a number of functions to help you test your scripts.
2. Writing the vulnerability XML file (VulnXML format)
To create a new XML file using VulnXML format, use Acunetix WVS Vulnerability Editor which is available from the Acunetix Web Vulnerability Scanner Program Group.
Follow the below procedure to create a new VulnXML file for a custom vulnerability check;
In the ‘References’ tab you can specify links to additional information about the vulnerability (e.g., cause and related fix). You can add additional references by right clicking and selecting ‘Add reference’.
Note: The built-in vulnerability checks cannot be modified. Onlly their VulnXML files (vulnerability details) can be modified.
Modifying a custom vulnerability check
To modify a custom vulnerability check, open the script in the WVS Scripting tool and proceed with the desired changed. The WVS Scripting tool and detailed scripting reference are available from; http://www.acunetix.com/download/tools/Acunetix_SDK.zip.
Modifying the vulnerability VulnXML file
To modify an existing vulnerability check, open Acunetix Vulnerability Editor and select the script to edit from the VulnXML node. Click on the section which you would like to edit and proceed with the text changes. Once ready click on the ‘Save’ icon (first icon) in the top left corner or the Vulnerability Editor.
Submitted by Bogdan Calin on September 3, 2010 – 8:09 pm
While beta testing the latest version of Acunetix WVS v7, we found a large number of security vulnerabilities in various web applications. In the following days we will publish some of these vulnerabilities. Note that we will not publish vulnerabilities found in applications that are not commonly used or in beta stage.
One of the tested web applications is Pligg;
Pligg is an open source CMS (Content Management System) that you can download and use for free. Pligg CMS provides social publishing software that encourages visitors to register on your website so that they can submit content and connect with other users.
The following web vulnerabilities were found in Pligg CMS Version 1.0.4;
Technical details about each web vulnerability are below;
1. SQL injection in “/pliggcms_1_0_4/login.php“, parameter “email“.
Source file: /var/www/pliggcms_1_0_4/libs/db.php line: 222
Additional details:
SQL query:
1 |
SELECT * FROM `pligg_users` where `user_email` = '1ACUSTART'"*/rn ACUEND' AND user_level!='Spammer' |
“mysql_query” was called.
Stack trace:
1 |
1. ezSQL_mysql::query([string] "SELECT * FROM `pligg_users` where `user_email` = '1ACUSTART'"*/rn ACUEND' AND user_level!='Spammer'") |
2 |
2. ezSQLcore::get_row([string] "SELECT * FROM `pligg_users` where `user_email` = '1ACUSTART'"*/rn ACUEND' AND user_level!='Spammer'") |
Sample HTTP Request:
01 |
POST /pliggcms_1_0_4/login.php HTTP/1.1 |
02 |
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c |
03 |
Acunetix-Aspect: enabled |
04 |
Content-Length: 68 |
05 |
Content-Type: application/x-www-form-urlencoded |
06 |
Cookie: PHPSESSID=4c7d8e111f3ec5e90e664e26f365cc04; mnm_user=tmp; mnm_key=dG1wOjIyZkpqa1BveUhCVFE6NWY1YTg5NTJkYzUzODI4NGYwOTA0Y2Q0NTUzNzk5NDE%3D; template=wistie |
07 |
Host: webapps7:80 |
08 |
Connection: Keep-alive |
09 |
Accept-Encoding: gzip,deflate |
10 |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) |
11 |
|
12 |
email=sql'injection&processlogin=3&return=%2fpliggcms_1_0_4%2f |
2. Cross-site Scripting vulnerability in “/pliggcms_1_0_4/user.php”, parameter “category”.
Attack details
URL encoded GET input categorywas set to ” onmouseover=prompt(938687) bad=”
The input is reflected inside a tag element between double quotes.
The input is reflected inside a tag element between single quotes.
Sample HTTP Request:
01 |
POST /pliggcms_1_0_4/user.php?category=%22%20onmouseover%3dprompt%28938687%29%20bad%3d%22&id=&keyword=Search..&login=&module=&page=&search=&view=search HTTP/1.1 |
02 |
Content-Length: 9 |
03 |
Content-Type: application/x-www-form-urlencoded |
04 |
Cookie: PHPSESSID=4c7d8e111f3ec5e90e664e26f365cc04; mnm_user=tmp; mnm_key=dG1wOjIyZkpqa1BveUhCVFE6NWY1YTg5NTJkYzUzODI4NGYwOTA0Y2Q0NTUzNzk5NDE%3D; template=wistie |
05 |
Host: webapps7:80 |
06 |
Connection: Keep-alive |
07 |
Accept-Encoding: gzip,deflate |
08 |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) |
09 |
|
10 |
username= |
These vulnerabilities were reported to the Pligg team on 22/7/2010 via the contact form from their website and they were fixed in latest version of Pligg. If you are using Pligg, download the latest version from their website.
New scanning engine with improved vulnerability detection AND verification makes finding and fixing security issues in web applications easier.
September 1, 2010 – Acunetix, a market leader in web application security scanning technology, today announced version 7 of its popular Web Vulnerability Scanner. With the new human like vulnerability verifying techniques, revolutionary scanning engine and support for a wider variety of web applications, Acunetix re-establishes its technology lead in web application security. Acunetix WVS Version 7 also features improved performance, less false positives and detection of a wide range of new web vulnerability types.
“With Acunetix WVS v7 we focused on finding more vulnerabilities, reducing false positives, and on improving scanner performance,” said Robert Abela, Acunetix Technical Manager. “As a result, Acunetix 7 is now 300% faster, can reduce false positives up to 50% and detects new vulnerabilities such as stored directory traversal. This helps businesses reduce the time and resources needed to secure their web applications significantly.”
Unique vulnerability verifying technique reduces false positives
Acunetix v7 includes new advanced vulnerability verifying techniques which result in much less false positives, and thus saves time of security administrators trying to reproduce such situations. Such accuracy is achieved by sending a number of test inputs to the web application, and depending on the response, Acunetix v7 will automatically determine which web vulnerability checks to launch against the web application.
New faster scanning engine reduces time to scan a website by up to 300%
Acunetix Web Vulnerability Scanner Version 7 includes a new fast multi-threaded scanner that can scan on more threads at a time and more efficiently. Scans that could take hours to complete now can be done in minutes, depending on website structure and web applications.
When a web security threat is discovered, Acunetix WVS Version 7 presents the developers with a more precise and understandable technical and vulnerability remediation information, to help them fix the issue in a much shorter time. To improve understanding, different variants of the vulnerability are gathered in one detailed vulnerability report. Acunetix v7 can also re-check a fix for a particular vulnerability, without having to rescan the entire website.
Thanks to the new revolutionary scanning engine and website crawler, Version 7 is able to find much more vulnerabilities than ever before. The new site crawler’s in-depth analysis of the website presentation layer discovers more website parameters and inputs. Acunetix 7 is therefore capable of finding many more vulnerabilities in a larger variety of different web applications.
Scan a wider range of web applications
Acunetix v7 is also able to crawl and scan a wider variety of web technologies. Support for Web 2.0 applications has been improved, and also session handling. All of the advanced penetration testing tools have been rewritten to support Web 2.0 requests, such as JSON, XML and more.
HTTP authentication
Acunetix WVS v7 now supports more than a single pair of HTTP credentials for the same host. Thanks to the new HTTP authentication settings node, one can pre-define credentials per host, directory and even file.
Acunetix v7 now has improved support for creating custom vulnerability checks. Vulnerability checks are written in JavaScript, the most popular scripting language with web developers, and can thus be easily adjusted or extended. A scripting tool and SDK are also available to assist developers in writing custom web vulnerability and security checks.
Subscription based licenses now also include the maintenance agreement and are thus significantly cheaper. In addition free support and free version upgrades are included.
Other Features
■New graphical scan status interface shows more information about a web scan in progress
■Avoid the lengthy process of manually analyzing the code by specifying the label or tag instead of actual parameter name
■Verify that AcuSensor Technology is correctly installed with a simple click of a button
■During a scan, less bandwidth is consumed and less stress is put on the server thanks to improved network traffic handling
■A number of new network security checks have been added and other ones improved.
Acunetix WVS Trial Edition
Download Acunetix Web Vulnerability Scanner v7 trial edition from here
It has been one long year of development, testing and late nights at the office, though it was all worth it, and the results speak for themselves! Most of the core components have been rewritten, such as the crawler, scanner, vulnerability checks and the HTTP stack. Acunetix Web Vulnerability Scanner Version 7 is around 75% faster and more intelligent scanner than its predecessors. Most of the web vulnerability checks have been migrated from VulnXML format to Scripts. This allows us to have more advanced and flexible security checks, while reducing false positives. It is also easier for you to develop your own web vulnerability checks. Version 7 also includes much more meticulous web security tests, some of which were not possible before.
If you are interested in testing the new BETA of Version 7, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us at beta@acunetix.com.
The FREE version of Acunetix WVS Version 7 BETA can be downloaded from here
The new features of Version 7 are:
Major improvements in Version 7:
The Acunetix WVS Version 7 user manual is available in PDF Format and also in HTML Format.
With the introduction of scripting, a Getting Started guide / SDK is available to help you understand how the new vulnerability checks are implemented in Acunetix Web Vulnerability Scanner and to help you write your own scripts / security checks. We also developed a new tool, ‘WVS Scripting’, to help you writing your own scripts and testing them. You can download the documentation and tool from the following location; http://www.acunetix.com/download/tools/Acunetix_SDK.zip.
At a later stage, a more detailed SDK and ‘WVS Scripting’ tool documentation will also be released.
Alliance Technology Partners is a leading resellers of the Acunetix Web Vulnerability Scanner
Be sure to check our Acunetix Blog to keep updated with the latest news and release date of the BETA!
Acunetix WVS V7 is 75% faster, and ships with a more intelligent and faster scanning engine. Below is a summary of the top new features that will be available;
* New revolutionary scanning engine detects a wider range of web vulnerabilities
* Less false positives and false negatives; human like vulnerability verifying techniques!
* Improved web 2.0 applications support; better handling and parsing of JSON and XML
* Improved handling and detection techniques of links and input parameters
* Consolidation of vulnerabilities to facilitate coordination of vulnerability remediation
Alliance Technology Partners is a leading Acunetix partner. Visit our Acunetix Web Vulnerability Resource Page for the latest information on the Acunetix Web Vulnerability Scanner and for the best prices on Acunetix software.
What is a Directory Traversal attack?
Properly controlling access to web content is crucial for running a secure web server. Directory Traversal is an HTTP exploit which allows attackers to access restricted directories and execute commands outside of the web server’s root directory.
Web servers provide two main levels of security mechanisms:
An Access Control List is used in the authorization process. It is a list which the web server’s administrator uses to indicate which users or groups are able to access, modify or execute particular files on the server, as well as other access rights.
The root directory is a specific directory on the server file system in which the users are confined. Users are not able to access anything above this root.
For example: the default root directory of IIS on Windows is C:\Inetpub\wwwroot and with this setup, a user does not have access to C:\Windows but has access to C:\Inetpub\wwwroot\news and any other directories and files under the root directory (provided that the user is authenticated via the ACLs).
The root directory prevents users from accessing sensitive files on the server such as cmd.exe on Windows platforms and the passwd file on Linux/UNIX platforms.
This vulnerability can exist either in the web server software itself or in the web application code.
In order to perform a directory traversal attack, all an attacker needs is a web browser and some knowledge on where to blindly find any default files and directories on the system.
What an attacker can do if your site is vulnerable
With a system vulnerable to Directory Traversal, an attacker can make use of this vulnerability to step out of the root directory and access other parts of the file system. This might give the attacker the ability to view restricted files, or even more dangerous, allowing the attacker to execute powerful commands on the web server which can lead to a full compromise of the system.
Depending on how the website access is set up, the attacker will execute commands by impersonating himself as the user which is associated with “the website”. Therefore it all depends on what the website user has been given access to in the system.
Example of a directory traversal attack via web application code
In order to perform a directory traversal attack, all an attacker needs is a web browser and some knowledge on where to blindly find any default files and directories on the system.
Example of a directory traversal attack via web application code
In web applications with dynamic pages, input is usually received from browsers through GET or POST request methods. Here is an example of a GET HTTP request URL:
http://test.webarticles.com/show.asp?view=oldarchive.html
With this URL, the browser requests the dynamic page show.asp from the server and with it also sends the parameter “view” with the value of “oldarchive.html”. When this request is executed on the web server, show.asp retrieves the file oldarchive.htm from the server’s file system, renders it and then sends it back to the browser which displays it to the user. The attacker would assume that show.asp can retrieve files from the file system and sends this custom URL:
http://test.webarticles.com/show.asp?view=
../../../../../Windows/system.ini
This will cause the dynamic page to retrieve the file system.ini from the file system and display it to the user. The expression ../ instructs the system to go one directory up which is commonly used as an operating system directive. The attacker has to guess how many directories he has to go up to find the Windows folder on the system, but this is easily done by trial and error.
Example of a directory traversal attack via web server
Apart from vulnerabilities in the code, even the web server itself can be open to directory traversal attacks. The problem can either be incorporated into the web server software or inside some sample script files left available on the server.
The vulnerability has been fixed in the latest versions of web werver software, but there are web servers online which are still using older versions of IIS and Apache which might be open to directory traversal attacks. Even tough you might be using a web werver software version that has fixed this vulnerability, you might still have some sensitive default script directories exposed which are well known to hackers.
For example, a URL request which makes use of the scripts directory of IIS to traverse directories and execute a command can be:
http://server.com/scripts/..%5c../Windows/System32/
cmd.exe?/c+dir+c:\
The request would return to the user a list of all files in the C:\ directory by executing the cmd.exe command shell file and run the command “dir c:\” in the shell. The %5c expression that is in the URL request is a web server escape code which is used to represent normal characters. In this case %5c represents the character “\”.
Newer versions of modern web server software check for these escape codes and do not let them through. Some older versions however, do not filter out these codes in the root directory enforcer and will let the attackers execute such commands.
How to check for Directory Traversal vulnerabilities
The best way to check whether your web site & applications are vulnerable to Directory Traversal attacks is by using a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Directory Traversal vulnerabilities. It will report the vulnerability and how to easily fix it.. Besides Directory Traversal vulnerabilities a web application scanner will also check for SQL injection, Cross site scripting & other web vulnerabilities.
The Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting, Google hacking and many more vulnerabilities. For more information & a trial download click here.
Preventing directory traversal attacks
First of all, ensure you have installed the latest version of your web server software, and sure that all patches have been applied.
Secondly, effectively filter any user input. Ideally remove everything but the known good data and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server.
Check if your website is vulnerable to attack with Acunetix Web Vulnerability Scanner
Acunetix Web Vulnerability Scanner ensures website security by automatically checking for SQL injection, Cross site scripting, Directory Traversal and other vulnerabilities. It checks password strength on authentication pages and automatically audits shopping carts, forms, dynamic content and other web applications. As the scan is being completed, the software produces detailed reports that pinpoint where vulnerabilities exist. Take a product tour or download the evaluation version today!
Scanning for XSS vulnerabilities with Acunetix WVS Free Edition!
To check whether your website has cross site scripting vulnerabilities, download the Free Edition from http://www.acunetix.com/cross-site-scripting/scanner.htm. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site).
Facebook rates as the second most popular website on the internet with 400 million active users. When such a website has common web application security flaws, they are going to be abused for one’s gain. When we came across an obvious cross-site scripting vulnerability, we decided to show that an attacker could do that.
The below video shows how an attacker may exploit a cross-site scripting vulnerability on Facebook.com regardless of the HTTPOnly cookie protection used. Of course, this goes way beyond showing an “alert()” popup in Javascript, since the attacker is also able to hijack the victim’s Facebook account. We also published an article to explain in more technical detail the works behind abusing this Cross-Site scripting vulnerability on Facebook.
Alliance Technology Partners is an Acunetix partner specializing in IT Security including Web Application Security
Acunetix Web Vulnerability Scanner home page
Submitted to the Acunetix Blog by Kevin Beaver on August 4, 2010 – 8:25 pm
Making Web application security work is more than simply telling developers they need to write better code. We can scream “Write better code!” and “Integrate security into the application lifecycle!” at developers until end of time but that’s not going to fix the fundamental problems we have with unsecure software. Developers, by and large, know they need to write better code and integrate security into the application lifecycle. It’s like the average person knowing he or she needs to eat less and exercise more. However, just because people understand simple concepts and know certain things to be true doesn’t mean they’re going to do them.
I believe the reason why getting developers on board with security is not so cut and dried is something called the expediency principle. This principle says that people are going to take the fastest and easiest routes to get what they want without regard for the long-term consequences of their actions. Putting the expediency principle into software development terms: developers are going to develop software (the thing they want or have to do) in the quickest and simplest ways possible often ignoring the outcome of their choices (software security flaws that can be exploited for ill-gotten gains).
So what’s to give? If developers are going to take the path of least resistance, why even bother? The reality is, developers behaving in this fashion don’t have buy-in. It’s not that they don’t care. Rather it’s that developers are often not being held accountable. But how can we get them on board with security? I’m not saying it’s going to be easy but it is possible. Here are several things you can do right now to get started:
1. Find an advocate on the development team who’s interested in learning more about security and ultimately making things better for the business.
2. Get someone in management involved (i.e. the CTO, CIO, or CFO) who can not only set expectations and hold people responsible but also lead by example.
3. Invite developers to IT, compliance, security, and internal audit meetings so they can see how their actions affect these areas of the business.
4. Show developers what can happen when security flaws are exploited. Quite often developers haven’t even had a chance to slow down and think about the outcomes of XSS, SQL injection, session manipulation and so on. Some real-world examples can go a long way.
5. Share with them – even show them the ins and outs of – a good Web vulnerability scanner such as Acunetix Web Vulnerability Scanner that’s available to them throughout the development process.
6. Have them help you formulate a set security standards and policies that apply to software development across the board in your business.
Finally, it’s important to understand the reasoning behind why people do what they do. Psychologists have determined that people do things for two reasons: the desire for gain and the fear of loss. In other words, people want to get something positive (money, recognition, promotion, etc.) or they’re afraid they’re going to get into trouble (miss key system requirements, cause the business to fail to meet contractual or compliance requirements, get fired, etc.) as a result of their actions. This translates nicely into developers writing security code.
If we as information security professionals are going to get the right people on board in the right ways to improve software security it’s going to take some work. It’s all a matter of choice.
Alliance Technology Partners is an Acunetix partner specializing in IT Security including Web Application Security