Mike Ossmann: RF Retroreflectors, Emission Security and SDR
Synopsis: The leaked pages from the NSA ANT catalog provided a glimpse into the modern world of emission security. Extending beyond passive monitoring of unintentional emissions, today’s spooks employ active attacks with tools such as RF retroreflectors. I’ll report on my experiments to reproduce such techniques with open source hardware and software, primarily using SDR.
When planning for IPv6 addressing, many organizations – rightfully & wisely – decide to go with global unicast addresses (GUAs) only (hence not to use unique local addresses/ULAs as of RFC 4193 at all), in order to avoid address selection hell or just for simplicity & consistency reasons. This post discusses security implications and complementary security controls of such an approach.
In their IPv4 networks, most of these organizations currently use RFC 1918 space, combined with NAT for specific connections or use cases. Ideally NAT is only in place “where strictly needed”, in practice it’s often used as a kludge to conceal of all types of bad network design or debatable application architectures. I won’t enter the “is NAT a security control?” debate here, one statement might be allowed though: as of section 3 (“Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links.”) RFC 1918 space is usually not reachable from the Internet. So using such address space for internal networks is a nice example of the isolation principle as of the “Seven Sisters” approach we like to use. Now, bringing NAT into these networks enables connections (usually between trusted and untrusted networks) which simply would not be possible without it [NAT], so this actually breaks the isolation property. Question: how can one ever call something that increases the number of possible interactions between assets and potential attack originators a ‘security control’?!
In one of our customer environments each vendor offering an IT product/solution is asked to fill out a questionnaire collecting information on a number of technical parameters with regard to their product[s]. We were recently asked to come up with a proposal of 8 to 10 IPv6-related questions to be added to the questionnaire/process. Here’s what we suggested:
When displaying, storing or exporting IP addresses, can your solution correctly handle IPv6 addresses of all types (link-local, ULAs, GUAs)?
When receiving IP addresses as input or processing them (e.g. in a database), can your solution correctly handle IPv6 addresses of all types (link-local, ULAs, GUAs) and of variable length?
Does your solution implement RFC 5952 in the sense that input (of IPv6 addresses) can be in any format, but output (e.g. in log files) follows the RFC 5952 recommendation?
Can your solution handle both A and AAAA records from DNS?
Does your solution use link-local or GUAs/ULAs for intra-subnet communication? Which is the default and can both types of addresses be configured?
Does your product/offering comply with any of the profiles in the ripe-554 requirements specification?
[http://www.ripe.net/ripe/docs/ripe-554]
Do all security-related functions of your solution (e.g. traffic filtering/ACLs, blacklisting, logging) fully support IPv6, with performance being equal to that of IPv4?
Do all implementations of management interfaces & protocols (SNMP, syslog etc.) used within your solution fully support IPv6?
Does your solution have a built-in webserver? Can this be configured to listen on an IPv6 address and has it been tested to successfully work in an IPv6-only or dual-stack setting?
Has your solution been thoroughly tested in an IPv6 only or in a dual-stack setting? Please provide proper test documentation.
In dual-stack settings which approach (e.g. Happy Eyeballs as of RFC 6555) does your solution follow as for preferring IPv6 over IPv4 or vice versa? Can this be configured/adjusted if needed?
On Thursday the 20^(th) Enno, Jayson and I had the pleasure to present our latest research results regarding MLD at Deepsec 2014, both from vendors’ implementation perspective as well as regarding protocol design flaws (some preliminary results as well as our testing methodology were discussed here and here).
For refreshing out memory, in a nutshell, the purpose of MLD, a subprotocol of IPv6, is to inform routers about the presence of nodes which are interested in receiving specific multicast traffic (RFC 2710). The newer version of MLD, MLDv2 adds the ability for source address selection (RFC 3810).
We’re delighted to provide the first announcement of talks of next year’s Troopers edition. Looks like it’s going to be a great event again .
Here we go:
Jacob Torrey – The foundation is rotting and the basement is flooding: A deeper look at the implicit trust relationships in your organization FIRST TIME MATERIAL
Synopsis: In this session, a new hardware-level attack on PCIe is presented as an example for the implicit trust your organization places in 3rd parties. These implicit trust relationships that are typically overlooked will be closely examined under the lens of “InfoSec debt” and providing guidance to InfoSec decision makers on the ROI or risks of adding additional IT services/appliances to an organization’s network.
The “InfoSec debt” metric can then be tracked over time and provides an intuitive way to explain the cost/benefits of IT security to other organizational stakeholders.
Next week, at DeepSec, we’re going to give a talk about Multicast Listener Discovery (MLD), a component of IPv6 which is realized by means of ICMPv6 messages. There are two versions of MLD (mainly specified in RFC 2710 and RFC 3810 respectively) and while MLD is technically implemented by ICMPv6 exchanges, these specifications describe a whole set of rules and communication formats, hence we can safely talk about “the MLD protocol”.
Now, you might ask: how does one tackle the task of examining the security “of a protocol”?
To contribute to the current debate on IPv6 route deaggregation & “strict-filtering” performed by certain ISPs we just released a white paper on “Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region“. I will give a talk on the overall topic later today at the Routing Working Group. We sincerely hope that the IPv6 community becomes aware of the inherent issues, and that practical solutions can be found which consider & meet the needs of the different parties involved.
If any of you is interested in the intricacies of IPv6 Neighbor Discovery (ND) I briefly referred to in the course of my series on DHCPv6, I recommend reading section 5.2 “The Host, the Link, and the Subnet in IPv6” of Yar Tikhiy’s excellent ebook “IPv6 for IPv4 Experts”. It can be found here.
Probably due to the (“secondary”) role it has been historically assigned within the IPv6 universe, DHCPv6 is a protocol which is very different from its IPv4 counterpart. Some of the differences and similarities have been discussed recently (e.g. see Scott Hogg‘s article on “High Availability DHCPv6“). This post aims at covering a fundamental, yet widely unknown or misunderstood difference, that is the properties of DHCPv6 addresses and their behavior on the local-link.
.