Given the proliferation of internet connected devices, IPv6 has been proposed to replace IPv4. Aside from providing a larger address space which can be assigned to internet enabled devices, it has been suggested that the IPv6 protocol offers increased security due to the fact that with the large number of addresses available, standard IP scanning attacks will no longer become feasible. However, given the interest in attacking organizations rather than individual devices, most initial points of entry onto an organization's network and their attendant devices are visible and reachable through web crawling techniques, and, therefore, attacks on the visible application layer may offer ways to compromise the overall network. In this evaluation, we provide a straightforward implementation of a web crawler in conjunction with a benign black box penetration testing system and analyze the ease at which SQL injection attacks can be carried out.
IPv6 was developed by Engineering Task Force [
More specifically, most attacks are against organization rather than individual devices. Most of these organizations are connected to the internet in such a way where they can be searched via publically available search engines or a hyperlink structure can be traversed to reach them. After the initial web server or database has been identified and breached, other devices belonging to the organization can then be identified and compromised in turn, with the increased address space of IPv6 not making a difference. Thus, the increased address space provided by IPv6 does not offer any practical barriers to finding targets to attack.
To demonstrate this vulnerability, we will utilize the keyword search of publically available search engines such as Google, Bing, and Yahoo in conjunction with a web crawler with a black box penetration testing kit [
Briefly, the overall component of this system is a web crawler [
An effective web crawler needs to implement four key elements, a selection policy, a revisitation policy, a politeness policy, and parallelization scheme [
The typical web crawler works via breadth first search [
Web crawling flow chart.
Dynamic analysis identifies security problems by directly interacting with a functioning website. In other words, dynamic analysis relies on simulating user interactions with web pages, including interactions designed with potentially malicious intent. Because dynamic analysis uses a real website to find vulnerabilities in real time, found vulnerabilities are much more likely to be real than with static analysis, which has problems with detecting false positives [
SQL injection [
A complete dictionary file is important to our research. The web crawler we designed will detect the pages with weak password [
There are three techniques to transform IPv4 to IPv6 addresses which are dual stack, tunneling, and translation [
Application attack.
Among many application level attacks methods, SQL injection is the most well known. Furthermore, because it attacks databases which may store information related to accounts and authentication, they are an attractive target to hit. In our evaluation we combine the discovery module which utilizes web crawling with black box penetration methods [
In order to inspect if information stored on the web presents a security risk, this research combines a web crawler, like those used in search engines, with the concept of application vulnerability inspection, specifically black box and penetration testing. The end product is the website security mining system, a tool to evaluate a website’s security. This system can be separated into two main modules which are the Static Mining module and the Dynamic Scanning module. The Static Mining module inspects a specific website’s robots.txt, E-mails, potential SQL injection URLs, files, and broken links. The Dynamic Scanning module uses the system’s vulnerability-inspecting function by typing keywords into a search engine’s query box to inspect many websites.
Both the Static Mining and Dynamic Scanning modules leverage the system’s vulnerability inspecting function, which has two parts: known website vulnerability inspection and SQL injection inspection. The former compiles a database of open source website vulnerabilities into an XML file which is used to inspect the website to see whether it has the same vulnerability. Algorithm
<config> <name>Name of Vulnerability</name> <date>Releasing Date of Vulnerability</date> <author>Author</author> <version>Version Number</version> <type>Type of Vulnerability</type> <description>Description of Vulnerability</description> <file>File of Causing Vulnerability </file> <bugfile>The URL that used for Vulnerability Testing</bugfile> <successkeyword>Successful keyword shown on the page after error appears</successkeyword> </config>
The website security mining system can find vulnerabilities in a variety of database engines, specifically MS-SQL, MySQL, Access, Oracle, Postgresql, and Sqlite. The steps to identify SQL injection vulnerabilities are as follows. First, an injectable point must be identified by inspecting the website for places where user input may be used in SQL queries. If such an injectable point is found, then further tests are conducted to identify the specific type of database engine. To do this, we take advantage of how different databases use different function names for certain tasks. For example, MS-SQL and MySQL use len( ) to calculate length; however, Oracle uses length( ) to do it. In other words, when you use len(“s”) = 1 to test and receive a normal response, that means the target website uses MS-SQL or MySQL. On the other hand, if this does not work, then the database might be Oracle or other types of database. There are several other functions that can help us determine what the database is. After getting the database’s type, we find table and column names and finally get the database’s data.
The website security mining system can run on any operating systems that are supported by Java. We describe the two basic modules in more detail below.
The Static Mining module runs depth mining on a specific website. There is an option to determine whether you want to follow the website’s robot.txt rules. Robot.txt [
The Static Mining module starts with a specific web site and then collects all the related pages from it using a breath-first search algorithm. The system assumes that web pages have close relations to the original web page if the link distance is within a certain range [
Figure
Static Mining module.
Database content found by injectable URLs.
Additionally, we determined that the operating system (OS) of the host was “Microsoft Windows XP Professional,” as shown in Figure
Host operating system.
The most popular search engines today are Google, Yahoo, Baidu, Microsoft Bing, NHN, eBay, Ask.com, Yandex, and Alibaba. With the help of search engines, we can find billions of web pages and their URLs. Our system inspects these websites to determine whether they have vulnerabilities by analyzing the results retrieved from search engines. Our system supports the kinds of query syntaxes used in modern search engines. After you input the keywords, the system can find all related web pages and inspect whether they are at risk for vulnerabilities or not.
Figures
Work on Google search engine.
Work on Yahoo search engine.
Work on Bing search engine.
This research used the same command, inurl:.asp?
Dynamic scanning results.
Despite SQL queries injection, this system provides functions of backend systems detection [
We designed two experiments to test the security situation of IPv6’s website on the internet. Experiment 1 uses WSMS’s Dynamic Scanning module to compare the numbers of injectable URL in each IPv4 and IPv6 website. Experiment 2 uses WSMS’s Static Mining module to crawl the websites that have been authorized by IPv6 forum [
We constructed WSMS in the pure IPv4 environment; it will show “getaddr info failed URL Error” message and stop if it crawled IPv6’s website. In the case where we wish to explore IPv6 addresses, the converse will be true; that is, getaddr info URL failed will be returned for IPv4 address. We uses Dynamic Scanning module to search these four type web pages (asp/aspx/php/jsp) in three different search engines (Google/Yahoo!/Bing) with “world peace” as the keyword. The statements which we type in Google, Yahoo!, and Bing are shown as Google => inurl:asp? world peace Yahoo! => world peace asp? Bing => world peace asp?
We assumed that
Pure IPv4 website detection statistics.
( |
Yahoo! | Bing | |
---|---|---|---|
ASP | (831, 292, 22) | (558, 123, 7) | (575, 157, 15) |
ASPX | (875, 286, 8) | (559, 68, 5) | (623, 153, 1) |
PHP | (917, 311, 15) | (741, 177, 7) | (655, 220, 10) |
JSP | (866, 290, 12) | (501, 171, 13) | (571, 152, 12) |
Pure IPv6 website detection statistics.
( |
Yahoo! | Bing | |
---|---|---|---|
ASP | (482, 222, 4) | (504, 25, 1) | (517, 22, 0) |
ASPX | (368, 97, 2) | (502, 31, 1) | (506, 18, 2) |
PHP | (520, 175, 3) | (607, 45, 2) | (639, 29, 2) |
JSP | (128, 36, 0) | (516, 16, 0) | (546, 6, 1) |
Ratio of injectable URL.
ASP | ASPX | PHP | JSP | |
---|---|---|---|---|
IPv4 | 7.69% | 2.76% | 4.52% | 6.04% |
IPv6 | 1.86% | 3.42% | 2.81% | 1.72% |
| ||||
Average | 4.78% | 3.09% | 3.67% | 3.88% |
Ratio of injectable URL.
As shown in Table
ANOVA.
SS | DF | MS |
|
| |
---|---|---|---|---|---|
Ratio of injectable URL | |||||
Between | 0.001 | 3 | 0.000 | 0.232 | 0.873 |
Inner | 0.023 | 20 | 0.001 | ||
Sum | 0.024 | 23 |
Group statistics.
Web page | Number | Mean | |
---|---|---|---|
Ratio of injectable URL | IPv4 | 12 | 0.05545133 |
IPv6 | 12 | 0.02937988 |
Independent samples test.
Levene's test for equality of variances |
|
||||
---|---|---|---|---|---|
|
|
|
DF |
|
|
The ratio of injectable URL | 0.368 | 0.550 | 2.147 | 22 | 0.043 |
The experiment result shows that the number of inspectable URLs in Google is the highest above all because it supports the function of parameter “inurl.” In IPv4’s situation, ASPX has the least injection problem while ASP gets the worst outcome. In IPv6’s situation, JSP has the least injection problem while ASPX performs poorly. In general, ASPX has much fewer problems and ASP has most problems. From Tables
Page * type cross-tabulation.
Type | Sum | ||||
---|---|---|---|---|---|
ASP | ASPX | PHP | JSP | ||
IPv4 page | |||||
Amount | 44 | 14 | 32 | 37 | 127 |
Ratio | 34.6% | 11.0% | 25.2% | 29.1% | 100.0% |
IPv6 page | |||||
Amount | 5 | 5 | 7 | 1 | 18 |
Ratio | 27.8% | 27.8% | 38.9% | 5.6% | 100.0% |
Sum | |||||
Amount | 49 | 19 | 39 | 38 | 145 |
Ratio | 33.8% | 13.1% | 26.9% | 26.2% | 100.0% |
Chi-square test.
Value | DF | Asymp. Sig. (2-tailed) | |
---|---|---|---|
Pearson Chi-square |
|
3 | 0.016 |
We constructed WSMS on the pure IPv6 environment, using Static Mining module to crawl twenty websites which were randomly selected from twenty regions from the IPv6 forum, and then we gathered the amount of E-mail address and injectable URL again (shown in Table
Experiment 2 result output.
Region/country | Tags | URL | MAIL disclosure amount | Inject URL amount |
---|---|---|---|---|
Mexico | Enterprise site |
|
91 | 0 |
Brazil | IT site |
|
169 | 0 |
Denmark | Other |
|
13 | 0 |
Russia | Other |
|
46 | 0 |
Belgium | Government site |
|
565 | 3 |
Argentina | Education site |
|
0 | 0 |
Spain | Education site |
|
557 | 0 |
Britain | Education site |
|
1697 | 0 |
Canada | Personal site |
|
0 | 0 |
America | Not-for-profit cooperative site |
|
12 | 0 |
Germany | Other |
|
71 | 0 |
New Zealand | Other |
|
97 | 0 |
Italy | Government site |
|
33 | 0 |
India | Government site |
|
77 | 0 |
Japan | Personal site |
|
82 | 0 |
Taiwan | Education site |
|
3 | 0 |
Thailand | Education site |
|
0 | 0 |
China | Education site |
|
430 | 59 |
Switzerland | Other |
|
1691 | 13 |
Poland | Education site |
|
3 | 0 |
From the above two experiments, we can see that the migration to IPv6 still leaves a great deal of vulnerabilities present in the application level infrastructure with a great deal of vulnerabilities still existing. These vulnerabilities while known can represent the initial springboard for more targeted attacks.
One of the messages from this evaluation is that with respect to the majority of the attacks that are commonly used, IPv6 does not offer any increased level of security versus IPv4. This is not surprising given the fact that the application layer attacks bypass the majority of the security infrastructure built into IPv6. Therefore, the results of this evaluation are hardly surprising. However, one interesting consequence of IPv6 is that given the large address space, it becomes more difficult to identify where malicious attacks are coming from due to the fact that an attacker no longer has to be tied to a small number of IP addresses but instead has a much larger pool with which to hide. Without the need to be readily discoverable by the general public, this level of anonymity becomes a much stronger weapon for the attacker than it is for the defender. That being said, with a better understanding vulnerability, we see that newer systems are much more robust than legacy systems. This perhaps is the most important result of this paper.
The website figures sampled from the experiment can prove that, even though the injection problem of IPv6 website is less than the IPv4 one, IPv6’s security protection on the transport layer does nothing to mitigate shortcomings on the application layer. Therefore, the programming habit [
The authors thank the National Science Council, Taiwan, for partially supporting this research under contract no. NSC 102-2221-E-194-036. The authors also feel grateful to anonymous reviewers for their very helpful and constructive criticism. Their suggestions have enabled the authors to improve the quality of this work.