On Monday, July 24, 2017 at 5:31:33 AM UTC-7, Jakob Bohm wrote: > On 22/07/2017 02:38, birge...@princeton.edu 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. >
We have been considering research in this direction. PEERING controls several ASNs and may let us use them more liberally with some convincing. We also have the ASN from Princeton that could be used with cooperation from Princeton OIT (the Office of Information Technology) where we have several contracts. The problem is not the source of the ASNs but the network anomaly the announcement would cause. If we were to hijack the prefix of a cooperating organization, the PEERING ASes might have their announcements filtered because they are seemingly launching BGP attacks. This could be fixed with some communication with ISPs, but regardless there is a cost to launching such realistic attacks. Matthew Hardeman would probably know more detail about how this would be received by the community, but this is the general impression I have got from engaging with the people who run the PEERING framework. So far we have not been working on such an attack very much because we are focusing our research more on countermeasures. We believe that the attack surface is large and there are countless BGP tricks an adversary could use to get the desired properties in an attack. We are focusing our research on simple and countermeasures CAs can implement to reduce this attack space. We also aim to use industry contacts to accurately asses the false positive rates of our countermeasures and develop example implementations. If it appears that actually launching such a realistic attack would be valuable to the community, we certainty could look into it further. > > 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
