On 22/07/2017 02:38, [email protected] wrote:
On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote:
It seems that a group of Princeton researchers just presented a live
theoretical* misissuance by Let's Encrypt.
They did a sub-prefix hijack via a technique other than those I described here
and achieved issuance while passing-through traffic for other destination
within the IP space of the hijacked scope.
They've got a paper at:
https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf
I say that theoretical because they hijacked a /24 of their own /23 under a different ASN
but I am given to believe that the "adversarial" ASN is also under their
control or that they had permission to use it. In as far as this is the case, this
technically isn't a misissuance because hijacking ones own IP space is technically just a
different routing configuration diverting the traffic to the destination they properly
control to another point of interconnection they properly controlled.
Hi,
I am Henry Birge-Lee, one of the researchers at Princeton leading that effort.
I just performed that live demo a couple hours ago. You are correct about how
we performed that attack. One minor detail is that we were forced to use the
same ASN twice (for both the adversary and the victim). The adversary and the
victim were two different routers peering with completely different ASes, but
we were forced to reuse the AS because we were performing the announcements
with the PEERING testbed (https://peering.usc.edu/) and are not allowed to
announce from another ASN. Thus from a policy point of view this was not a
misissuance and our BGP announcements would likely not have triggered an alarm
from a BGP monitoring system. Even if we had the ability to hijack another ASes
prefix and trigger such alarms we would be hesitant to because of ethical
considerations. Our goal was to demonstrate the effectiveness and ease of
interception of the technique we used, not freak out network operators because
of potential hijacks.
I know some may argue that had we triggered alarms from the major BGP
monitoring frameworks, CAs might not have issued us the certificates the did.
We find that this is unlikely because 1) The DV certificate signing process is
automated but the type of BGP announcements we made would likely require manual
review before they could be definitively flagged as an attack 2) There is no
evidence CAs are doing this (we know Let's Encrypt does not use BGP data
because of their transparency and conversations with their executive director
Josh Aas as well as their engineering team).
Another testing option would have been to use another AS legitimately
operated by someone associated with your research team. Unless
Princeton has historically obtained 2 AS numbers (this is not uncommon),
Cooperating with a researcher at another research facility could obtain
the other AS number without any actual breach or hijack.
As for further work, implementation of countermeasures into the CA and Browser
forum Baseline Requirements is our eventual goal and we see engaging with this
ongoing discussion as a step in the right direction.
Over the next couple days I will look over these conversations in more detail
and look for ways that we can integrate these ideas into the research we are
doing.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
