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.
.