TAG | IPv6
This is a guest post from Antonios Atlasis.
Having just finished the second “Advanced Attack Techniques against IPv6 Networks” workshop (some of the course material can be found here), organised and hosted by ERNW and their partner HM Training Solutions, I would like to take this opportunity to release publicly one of my scripting tools, an IPv6 scanner. This tool is based on Scapy (so you have to install Scapy and its prerequisites before using it). It should not be considered as a replacement or a competitor of nmap against IPv6 or of the scanners incorporated into the great IPv6 toolkits already released by Marc Heuse and Fernando Gont, but, instead, as a tool released mainly for educational purposes. Specifically, this scanner, apart from supporting some of the most well known port scanning techniques, from ping scanning to SYN, RESET, ACK, XMAS, etc., etc., TCP or UDP scanning, it also combines, by using the suitable switches, some IDS/IPS evasion techniques. As I have found out up to now, at least two of them, if used “properly”, can be effective against a very popular IDS/IPS software used by many “Fortune 100” companies out there. This means that you can launch actually any type of the supported network-scanning techniques while flying under the radar of this specific IDS software (and perhaps some other too, who knows…). But first of all, as always please check the corresponding README file.
I recently had a discussion with some practitioners about requirements to IP Address Management (IPAM) solutions which are specific for IPv6 networks. We came up with the following:
Mandatory: Track all dynamic IPv6 assignments (SLAAC + PrivExtensions, DHCP etc.), by polling neighbor caches from network devices. Support SNMPv3 for this task.
Optional (read: nice-to-have): support other methods than SNMP to gather this info (e.g. SSH-ing into devices and execution of appropriate “show” commands).
Mandatory: Display connected switch port (incl. device name or CDP-type info) for all addresses.
Mandatory: Be able to sort addresses according to their categories, e.g. “show all SLAAC systems vs. all systems with DHCPv6 addresses”.
Optional: Be able to easily identify systems which have several types _simultaneously_ (e.g. “static + SLAAC address”, “SLAAC + DHCP managed address”).
Mandatory: Full support for RFC 5952 notation in all UIs (both entry and display of addresses).
Optional: be able to display addresses in other formats in reports or exported files (e.g. CSV files).
Hope that some of you might find this useful when reflecting on the topic; have a great day everybody
a) The slides of our contribution can be found here. Again, pls note that this is work in progress and we’re happy to receive any kind of feedback.
[given Fernando explicitly mentioned Troopers, we've allowed ourselves to put some reference to it into this version of the slide deck...]
b) the scripts Stefan currently puts together will be released here once they’ve undergone more testing .
c) Sander Steffann mentioned that Juniper SRX models do have IPv6 support for management protocols. According to this link this seems somewhat correct.
e) I was really impressed by the work performed by these guys and I think that ft6 (“Firewalltester for IPv6″) is a great contribution to the IPv6 security (testing) space.
And, of course, Marc’s latest additions to THC-IPV6 shouldn’t go unnoticed . And I learned he can not only code, but cook as well.
Eric Vyncke commented “To be repeated”. We fully second that .
Next to IETF 87 going on in Berlin in a few days there will be an informal meeting of the “IPv6 Hackers” on Tuesday. We really look forward to personally meet a number of people who we (so far) only know from the associated mailing list or similar machine-enhanced exchange. We hope to contribute as well. Based on the stuff of this workshop from the IPv6 Security Summit at Troopers13 we might give a short project presentation along the lines of “Some Notes on Testing the Real-World IPv6 Capabilities of Commercial Security Products”, providing an overview of some testing done on commercial gear, together with a discussion of testing approaches, tools and key aspects.
I currently discuss this potential input with the guy who gratefully organized the meeting. In any case I encourage everybody interested in IPv6 security to show up there (you don’t have to be registered to IETF 87) as there’s not much that can substitute meeting in person to discuss how to make the IPv6 world a safer place.
1 Comment | Posted by Enno Rey
After his great presentations on IPv6 Extensions Headers and security problems related to fragmentation we had invited Antonios Atlasis to Heidelberg to give this workshop at ERNW. It was a great experience with many fruitful discussions between the participants (mostly security practitioners from very large organizations planning to have their Internet edge IPv6 enabled within the next 6-12 months) and him/us. Antonios thankfully decided to make his slides and scripts available for those interested in further research on the topics (it should be noted that the scripts have not been tested thoroughly and he’s happy to receive feedback of any kind at antoniosDOTatlasisDOTgmailDOTcom). Today Marc (Heuse) gives his workshop on pentesting in the IPv6 age. Hopefully such events help to move things into the right direction in the IPv6 security space…
Recently Jozef Pivarník and Matěj Grégr published an excellent write-up on RA Guard & evasion techniques. Amongst others they tested the “undetermined-transport” ACL we described here and here. As it turns out the “workaround” for implementing undetermined-transport on platforms seemingly not supporting it, causes some bad collateral damage: the respective port does not forward any IPv6 packets any more (this was brought to my attention by Roberto Taccon). We had done some tests after applying it (by means of the “workaround”) but we had just looked at fragmented RA packets (which did not get through => test succeeded). So, frankly: the undetermined-transport trick does not make sense at all on the “unsupported platforms”…
Jim Small didn’t notice this either, in his great presentation at the North American IPv6 Summit (which, btw, to the best of our knowledge is the best overview of ACL approaches to counter common IPv6 attacks on the local link).
Furthermore it should be noted that Jozef and Matej describe some really interesting ways to evade current implementations, incl. an evasion variant merely based on extension headers (without fragmentation) that we hadn’t been aware of before. These will be included in these workshops.
Obviously much more research (and vendor scrutiny) is needed as for RA Guard…
have a great week everybody
Due to “popular demand” and given Marc couldn’t join us at the IPv6 Security Summit (as flights into FRA were canceled that day due to snow) we decided to invite him and Antonios Atlasis another time, to present their knowledge, skills & voodoo in two workshops held in Heidelberg, in late June. More details can be found here.
See you all potentially at the Heise IPv6 Kongress, take care
on the [ipv6-ops] mailing list currently there’s some discussion about RA guard support on switches from different vendors.
Stefan, one of our students (btw: working on a topic similar to this session), quickly put together a preliminary list, based on publicly available information (read: the WWW ). Some of you may find this useful; it can be found here. Furthermore on the list this link was mentioned which seems to provide some info as well (albeit potentially not very up-to-date).
If anyone of you has better/more information pls feel free to share by leaving a comment. The IPv6 security comment will thank you for that
2 Comments | Posted by Enno Rey
I just had an interesting discussion with Jim Small (who gives the “IPv6 Attacks and Countermeasures” talk at the North American IPv6 Summit next week) about the feasibility of the “undetermined-transport” keyword in PACLs on Cisco 3560 switches (here running IOS 15.0(2)SE). Actually there’s some kind-of funny behavior as for it on that platform (and there’s even some Cisco documentation stating it’s not supported). Let’s have a look, and start with a quick refresher.
Rogue router advertisements pose a significant security and network stability risk in IPv6 networks. That’s why there’s a security feature implemented on certain switches which is called “RA Guard” (see also here). Unfortunately (at least Cisco’s current implementation of) RA Guard can easily be circumvented, e.g. by using the following command from the THC IPV6 attack toolkit:
fake_router26 -E D eth0
0 Comments | Posted by Enno Rey
We had a great day today at the Troopers IPv6 Security Summit. Good conversations, quite some technical discussion and a prevailing overall will to improve actual IPv6 network security.
Here are the slides of Antonios Atlasis’ great talk on extension headers and these are some of his accompanying Python/Scapy scripts. My own presentation on high secure IPv6 networks can be found here. The slides of the real-world capabilities workshop will not be published yet as we first have to discuss some stuff with a vendor.
Looking forward to tomorrow, have a great evening everybody