In the field of IT security, there is a constant arms race between attackers and defenders. One side comes up with new ideas, concepts and technologies to breach defensive walls, while the other side recognizes and blocks these attacks – a constant back and forth of action and reaction. Offensive and defensive actions occur in stages. A defender may, for instance, try to recognize attacks, to block them and to prevent them from recurring.

We have repeatedly come across this starting point in penetration tests of web applications. Once the attack is recognized, the attacker’s IP address may be blocked, making it impossible connect again from this address. I have been thinking about this issue, wondering how we can respond to these barricades and successfully circumvent them. In this article I will discuss the RIPv6 Random IPv6 (RIPv6) tool, which circumvents restrictive IP address-based filter and blocking rules.

Starting point: IP address blocking

Taking a web application I’m unfamiliar with, I conduct a penetration test to find out how the application is built and where potential attack vectors may lie. A vector is a point of entry in an application, such as a login page for normal users or administrators. To find an administrator interface, I try pathnames like /admin, /adm/ or /administrator.

This testing of pathnames leaves an identifiable trace in the web server’s log file. Anyone who searches for possible directories or files in quick succession generates numerous error messages such as HTTP 404 Not found. A defender can now search the web server’s log file for these patterns and take appropriate action. This generally involves blocking the IP address of the identified attacker for a certain period, or even permanently. One of the best-known tools for this is Fail2ban, which scans log files and blocks IP addresses when it identifies suspicious patterns.

For a tester, this means that – in your role of “hacker” – you should ideally have a number of systems or IP addresses available to avoid being blocked from the outset when attempting to hack the web application. The use of a botnet is one possible solution to the problem; for reasons of practicality and legality, however, I am limiting myself to a single test system. That single system should therefore have a sufficient number of IP addresses available. The world of IPv4 has recently been recently been hit by the problem that in a time of an IPv4 address shortage large blocks of addresses are no longer readily available. That’s fine for those who already have a large IPv4 address range, but for the rest, the only option is a workaround with IPv6.

Goal: a new IP address every x seconds

In designing the IPv6 protocol, one of the goals was to deal with the IPv4 address shortage. Here the address range was increased from 32 to 128 bits to create far more subnets and addresses. Presently, every customer with an IPv6 Internet connection is assigned at least one /64 subnet. A /64 subnet contains 18,446,744,073,709,551,616 potential addresses. With one simple request, a good Internet service provider (ISP) will also make a /48 subnet available. If the ISP still does not offer IPv6 even in 2016, there are still IPv6 tunneling services to meet the demand for large blocks of IP addresses.

Here I have decided to undertake a statistical configuration of IPv6 addresses. The IPv6 addresses are generated at random and managed using tools that are part of the operating system. That way I can determine the point at which a new IP address is generated and when it is no longer in use. In addition, there is no a dependency on a network service (Router Advertisement or DHCPv6). When rotating IP addresses, it is important to monitor communications between the web server and client/scanner. When scanning a website, connections to the web server are established; the client sends a request which is answered by the web server. Switching the IP address in the meantime may mean that the answer from the web server can no longer be delivered.

The solution is to use multiple IP addresses simultaneously. This is supported by the IPv6 protocol and it is even by design so that a network adapter may have multiple (virtual) IPv6 addresses. My implementation is based on the rollover concept of the Pre-publish model of DNSSEC keys (ZSK). The first IPv6 address IP1 is generated and actively used. After time factor x, a second IPv6 address IP2 is generated and also actively used straight away for new connections. IP1 reverts to a kind of stand-by status so that it is no longer used for new requests but can still accept responses. When the third IPv6 address IP3 is generated, IP1 switches to rolled status and is deleted from the network adapter. IP2 is now in stand-by status and is also deleted when the next IPv6 address is generated. This cycle carries on endlessly, such that the test system receives new IP addresses and responses never get lost.

RIPv6

That’s the theory, anyway. The practical implementation of the RIPv6 (random IPv6) tool is based on a bash script. If necessary, an adaptation to Microsoft PowerShell for Windows test systems is possible. The software can be found in my GitHub Repository and is free to use.

A precondition for RIPv6 is an existing gateway that carries out the routing of the IPv6 network. The specific address range and this gateway are currently defined in the script itself in the Variables section. This section can also be used to define the time value for the rotation of IP addresses. In a later version these values can also be defined using parameters.

IP addresses in the network range are randomly generated by the GenerateAddress() function, which currently generates addresses for a /64 subnet. Support for /48 networks is planned. The original function itself comes from Vladislav V. Prodan, although I have modified and shortened it for my own purposes.

For the rollover concept I establish an endless while loop. The IP addresses generated are assigned to or removed from the network adapter using the ip command. During the first pass, the default route is also configured. This step is only carried out during the first pass.

The script can now be started and executed in the background. At the moment every operation (addition and deletion) is output with echo. This way it is clear which IP address is currently being used.

[user@host ~]# ./ripv6.sh
[+] add ip1 2001:470:26:12b:45dc:2314:b631:4c4a
[*] set default route
[+] add ip2 2001:470:26:12b:9a65:b818:6c96:4271
[+] add ip3 2001:470:26:12b:c15e:ec07:400a:56a2
[-] del ip1 2001:470:26:12b:45dc:2314:b631:4c4a
[+] add ip1 2001:470:26:12b:5326:a7c6:7122:d269
[-] del ip2 2001:470:26:12b:9a65:b818:6c96:4271
[+] add ip2 2001:470:26:12b:ef45:b13a:5665:7ae4
[-] del ip3 2001:470:26:12b:c15e:ec07:400a:56a2
[+] add ip3 2001:470:26:12b:9bd6:6e3d:f90f:8a36
[-] del ip1 2001:470:26:12b:5326:a7c6:7122:d269

No further modification to the test system is required. The web scanner and other applications can be used as normal. The only difference is that requests are now sent with alternating IP addresses. This means that IP-based blocking should not present an obstacle in the future – provided the website can be accessed through IPv6. The current version of GitHub is still in the proof-of-concept phase and will receive a number of improvements in future. Plans include use of parameters for the configuration and support of /48 subnets. Any feedback, changes or additions are appreciated.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• http://www.fail2ban.org/
• http://www.ipv6.com/
• https://gist.github.com/click0/939739
• https://github.com/scipag/RIPv6
• https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph