On 26/7/2017 3:38 πμ, Matthew Hardeman via dev-security-policy wrote:
On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5,birg...@princeton.edu wrote:
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.
I have some thoughts on how to perform such experiments while mitigating the
likelihood of significant lasting consequence to the party helping ingress the
hijack to the routing table, but you correctly point out that the attack
surface is large and the one consistent feature of all discussion up to this
point on the topic of BGP hijacks for purpose of countering CA domain
validation is that none of those discuss have, up to this point, expressed
doubt as to the risks or the feasibility of carrying out these risks. To that
ends, I think the first case that would need to be made to further that
research is whether anything of significance is gained in making the attack
more tangible.
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.
This is the question to answer before performing such an attack. In effect,
who is the audience that needs to be impressed? What criteria must be met to
impress that audience? What benefits in furtherance of the work arise from
impressing that audience?
Thanks,
Matt Hardeman
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
That was a very interesting topic to read. Unfortunately, CAs can't do
much to protect against network hijacking because most of the
counter-measures lie in the ISPs' side. However, the CAs could request
some counter-measures from their ISPs.
Best practices for ISPs state that for each connected peer, the ISP need
to apply a prefix filter that will allow announcements for only
legitimate prefixes that the peer controls/owns. We can easily imagine
that this is not performed by all ISPs. Another solution that has been
around for some time, is RPKI
<https://www.ripe.net/manage-ips-and-asns/resource-management/certification>
along with BGP Origin Validation
<https://www.ripe.net/manage-ips-and-asns/resource-management/certification/bgp-origin-validation>.
Of course, we can't expect all ISPs to check for Route Origin
Authorizations (ROAs) but if the major ISPs checked for ROAs, it would
improve things a lot in terms of securing the Internet.
So, in order to minimize the risk for a CA or a site owner network from
being hijacked, if a CA/site owner has an address space that is Provider
Aggregatable (PA) (this means the ISP "owns" the IP space), they should
check that their upstream network provider has properly created the ROAs
for the CA/site operator's network prefix(es) in the RIR authorized
list, and that they have configured their routers to validate ROAs for
each prefix. If the CA/site operator has a Provider Independent (PI)
address space (this means the CA/site operator "owns" the IP space),
then the CA/site operator should create the ROAs.
In Matt's example, if eff.org had ROAs for their network prefixes (that
include their DNS servers) and if Let's Encrypt provider (or Let's
Encrypt router) was validating ROAs, this attack wouldn't work.
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
