Blast-RADIUS attack
Hi Nanog Today we announced a vulnerability in the RADIUS protocol, based on its outdated use of the MD5 hash function. We wanted to share it with this list because we suspect many NANOG folks could be operating RADIUS in their networks (to control admin access to routers and switches and other networking gear). Our Blast-RADIUS attack allows a Man-in-the-Middle (MitM), with access to RADIUS traffic, to gain unauthorized administrative access to the devices using RADIUS clients for authentication. It does this without needing to brute force or steal credentials or shared secrets. The attack has been given a CVSS score of 9.0. This attack works on all authentication modes of RADIUS/UDP apart from those that use EAP. It exploits a protocol vulnerability that has been present in the RADIUS specifications since the 1990s. We exploited the vulnerability by developing an improved attack on the MD5 hash function. The long-term fix is to run RADIUS over TLS. There are also short term patches for RADIUS/UDP. Vendors have released new mitigations against this attack today. Here’s some more info about the attack and its mitigations. https://www.blastradius.fail/ https://blog.cloudflare.com/radius-udp-vulnerable-md5-attack/ https://www.inkbridgenetworks.com/blastradius Thanks Sharon Goldberg (for the Blast-RADIUS team) https://www.blastradius.fail/
Re: NIST NTP servers
Since we are on the subject, I would strongly recommend that you don't run NTP on Linux 2.2.13, since its especially vulnerable to our IPv4 fragmentation attack. "SunOS" also seems vulnerable, but I am not 100% sure what systems that say they are "SunOS" actually are. These OS will fragment packets to 64 bytes, and are vulnerable to frag attacks using "tiny" fragments. See Section VI of our paper: https://eprint.iacr.org/2015/1020.pdf You can also test your OS here (scroll to the bottom). http://www.cs.bu.edu/~goldbe/NTPattack.html On Fri, May 13, 2016 at 10:46 AM, Chuck Anderson wrote: > On Fri, May 13, 2016 at 10:12:49AM -0400, Lamar Owen wrote: > > On 05/11/2016 09:46 PM, Josh Reynolds wrote: > > >maybe try [setting up an NTP server] with an odroid? > > > > > ... > > > > I have several ODroid C2's, and the first thing to note about them > > is that there is no RTC at all. Also, the oscillator is just a > > garden-variety non-temperature-compensated quartz crystal, and not > > necessarily a very precise one, either (precise quartz oscillators > > can cost more than the whole ODroid board costs). The XU4 and other > > ODroid devices make nice single-board ARM computers, but have pretty > > ratty oscillator precision. > > > > You really have to have at least a temperature compensated quartz > > crystal oscillator (TCXO) to even begin to think about an NTP > > server, for anything but the most rudimentary of timing. Ovenized > > quartz oscillators (OCXO) and rubidium standards are the next step > > up, and most reasonably good GPS-disciplined clocks have at least an > > ovenized quartz oscillator module (the Agilent Z3816 and kin are of > > this type). > > Does anyone know of any COTS NTP servers that are based on non-ancient > Linux kernel versions? In 2012 we bought new GPS/CDMA NTP servers > with OCXO that are based on Linux 2.4, but they are fiddly as you can > imagine with such an ancient software stack. > > What would people recommend for NTP server hardware/software? > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: NIST NTP servers
With the caveat that if some of the servers are inside your own private network then learning who the servers are might be less useful. But this could be an issue for targets who use servers that are exclusively on the public internet. On Wed, May 11, 2016 at 3:15 PM, Sharon Goldberg wrote: > Well, if you really want to learn about the NTP servers a target is using > you can always just sent them a regular NTP timing query (mode 3) and just > read off the IP address in the reference ID field of the response (mode 4). > > > Reference ID reveals the target that the client is sync'd to. > > If you do this over and over as the client changes the servers it sync's > to, you learn all the servers. > > Or if you are really keen you can use our "kiss-of-death" attack to learn > all the servers a client is willing to take time from. See sections V.B-V.C > of our paper. > > https://eprint.iacr.org/2015/1020.pdf > > Sharon > > > > On Wed, May 11, 2016 at 3:07 PM, Florian Weimer wrote: > >> * Chris Adams: >> >> > First, out of the box, if you use the public pool servers (default >> > config), you'll typically get 4 random (more or less) servers from the >> > pool. There are a bunch, so Joe Random Hacker isn't going to have a >> > high chance of guessing the servers your system is using. >> >> A determined attacker will just run servers in the official pool. >> >> > > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: NIST NTP servers
Well, if you really want to learn about the NTP servers a target is using you can always just sent them a regular NTP timing query (mode 3) and just read off the IP address in the reference ID field of the response (mode 4). Reference ID reveals the target that the client is sync'd to. If you do this over and over as the client changes the servers it sync's to, you learn all the servers. Or if you are really keen you can use our "kiss-of-death" attack to learn all the servers a client is willing to take time from. See sections V.B-V.C of our paper. https://eprint.iacr.org/2015/1020.pdf Sharon On Wed, May 11, 2016 at 3:07 PM, Florian Weimer wrote: > * Chris Adams: > > > First, out of the box, if you use the public pool servers (default > > config), you'll typically get 4 random (more or less) servers from the > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > high chance of guessing the servers your system is using. > > A determined attacker will just run servers in the official pool. > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: BGPMON Alert Questions
On Sat, Apr 5, 2014 at 7:11 AM, Mark Tinka wrote: > > So do you know whether anyone has any idea about what the > top 10 global carriers are doing re: RPKI? > > Thinking? Justifying? Testing? Ignoring? > These looking glasses are helpful: http://www.labs.lacnic.net/rpkitools/looking_glass/ http://www-x.antd.nist.gov/rpki-monitor/ http://certification-stats.ripe.net/ http://rpki.surfnet.nl/index.html But naturally it's harder to see who has turned on origin validation. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: BGPMON Alert Questions
On Fri, Apr 4, 2014 at 11:17 AM, Sharon Goldberg wrote> > > > Actually, since this is NANOG, might as well ask: > > Do you all view filtering your downstream's downstreams as much more > difficult than filtering only downstreams, or only stub ASes? Do you have > a sense for how many networks filter only their direct downstreams but no > further, versus those that also filter downstreams downstreams? > I set up a quick anonymous survey (2 questions) to gather some info on this. If you have a minute, go here: https://docs.google.com/forms/d/1x6Bbe7OYvuWeOzO8xpxbIZzW3N14wI1SVVbQer4FSa4/viewform We will share our anonymized results on NANOG. Thanks, Sharon
Re: BGPMON Alert Questions
On Fri, Apr 4, 2014 at 1:15 AM, Mark Tinka wrote: > On Friday, April 04, 2014 05:06:22 AM Sharon Goldberg wrote: > > > We also looked at prefix filtering and found that it has > > better partial deployment characteristics. Our analysis > > assumed that ISPs only filter routes from their *stub* > > customers. (We defined a stub an AS that does not have > > its own customers.) > > Just curious; in your considerations, how would/did you > treat cases where ISP's filter their downstreams, to include > their downstream's downstreams? > Right, we didn't include that in our analysis because we didn't have a good sense for how many ISPs actually do filter their downstream downstreams. So we chose to give a conservative estimate of the impact of prefix filtering in partial deployment: we assumed that no one filters their downstreams downstreams. I'm honestly not sure exactly what including this assumption would do to our results, except to say that it would make them better (ie. that more attacks would be stopped). Might be a good experiment for one of my summer interns. Actually, since this is NANOG, might as well ask: Do you all view filtering your downstream's downstreams as much more difficult than filtering only downstreams, or only stub ASes? Do you have a sense for how many networks filter only their direct downstreams but no further, versus those that also filter downstreams downstreams? Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: BGPMON Alert Questions
On Thu, Apr 3, 2014 at 8:50 PM, Randy Bush wrote: > > > Good point, which makes me ask: So which 5 to 10 networks, > > implementing source validation, could result in the greatest > > "coverage" or "protection" for the largest part of the Internet > > to the best of my knowledge, no one has looked at this for origin > validation. sharon goldberg and co-conspirators have done a lot > of work in the area, see her pubs at https://www.cs.bu.edu/~goldbe/. > but the concentration seems to be on bgpsec which deploys quite > differently Right, we (and others) have not looked at the efficacy of a partial deployment of origin validation (using the RPKI) yet. But, we did look at partial deployments of BGPSEC. We found that a large number of networks (around 50% of ASes) need to deploy BGPSEC before its security benefits really kick in. The reasons for this include (1) routing policies during partial deployment might not prioritize the BGPSEC validity over its AS path or local pref, (2) you need every node on an AS path to deploy BGPSEC before it works. Full paper here: https://www.cs.bu.edu/~goldbe/papers/partialSec.pdf We also looked at prefix filtering and found that it has better partial deployment characteristics. Our analysis assumed that ISPs only filter routes from their *stub* customers. (We defined a stub an AS that does not have its own customers.) Then we looked at the fraction of attacks that would be eliminated, if the X largest ISPs correctly implemented prefix filtering. ("Large" was measured in terms of the number of customers ASes the ISP had.) See Figure 18 on pg 15 of this paper, and the text explaining it in the middle of the right column on pg 15: http://research.microsoft.com/pubs/120428/BGPAttack-full.pdf Finally, like Randy says, RPKI deploys quite different from BGPSEC. My intuition says that (1) once the RPKI is fully populated with ROAs for all originated prefixes, then (2) a partial deployment of origin validation at a few large ISPs should be fairly effective. But I would have to validate this with experiments before I can be sure, or say exactly how many ISPs, etc. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Soliciting your opinions on routing research: A routing policies survey
Hi NANOG, 27 ops have already responded to our routing policies survey; we're hoping to gather more responses before the week is over. We're collecting information about how you configure routing policies in your network to improve the models we use in our research on routing and security. We'll also share the aggregated results with the NANOG list. The survey is anonymous and should take under 5 minutes to complete. Feel free to answer all our questions, or just a few: http://www.cs.toronto.edu/~phillipa/measurement/opsurvey/survey.php We’d also be grateful if you could forward the survey to ops at other organizations who may not be reading NANOG. Thanks all of you that have responded so far! Phillipa Gill (U of Toronto), Michael Schapira (Princeton), Sharon Goldberg (Boston University)
Routing policies study [was: Preferring peers over customers]
Hi NANOG, Based on recent discussions (of our paper and other topics) on this list, it seems like research on interdomain routing could really benefit from a better understanding of current routing policies. But we researchers need your help here. So, we created a short survey: http://www.cs.toronto.edu/~phillipa/measurement/opsurvey/survey.php We'll keep the survey data anonymous, and use it to improve research on interdomain routing and security. We'll also post aggregated results to the NANOG list. We'd appreciate if you could take 5 minutes to complete our survey; feel free to answer all of our questions, or just a few. Thanks! Phillipa Gill, Sharon Goldberg & Michael Schapira
Re: Do Not Complicate Routing Security with Voodoo Economics
Nick Feamster wrote: > 2. I question what fraction of routing decisions come down to a blind > tiebreak---nearly all of them are likely to be driven by some other > consideration (reliability, cost, etc.). Our paper details a richer economic > model by which ASes actually select paths, for example, but it's still > unclear to me how coarse or fine-grained route selection really is in > practice, and to what extent more complicated contracts have evolved. I > wonder how common "blind tiebreaking" is in BGP, in real networks; the > approach in Sharon's paper definitely may overstate how common that is if > route selection considerations commonly involve things that are not visible > in the AS graph (e.g., traffic ratios, congestion, performance), but > academics could really benefit from some more insight into how rich these > decisions are in practice. We think a key point is getting lost here. Routing policies affect our result in the following crucial way -- they determine the size of ASes' "tiebreak sets" (section 6.6). A tiebreak set is a set of "equally good routes" that an source AS has to a destination AS; in our model, an AS should prefer to route along the _secure_ routes in its tiebreak set. Simply put, with a larger tiebreak set, there should be more competition over customer traffic, and thus more widespread S*BGP deployment. In our simulations we assumed that tiebreak sets were determined by Local-Pref (economic considerations) and AS-Path considerations. In practice, tiebreak sets could be larger (e.g., if ASes prefer shorter paths over customer paths) or smaller (e.g., if intradomain considerations, like hot potato routing, affect tiebreak sets) than those in our simulations. Like Nick said, this is a place where more data from the ops community would be helpful to help us figure out how big tiebreak sets really are. However, the key point we want to emphasize is that in the simulations we ran, the tiebreak sets are actually quite small: 1) The size of the average AS tiebreak set in our simulations is only 1.18; which mean that 80% of tiebreak sets have only one path, see also Figure 8. 2) Security does not play a role in the vast majority (96%) of routing decisions made in our simulations (Section 6.7). In other words, S*BGP deployment can be driven even by a fairly small amount of competition for customer traffic. > 3. I think the discussion on the list so far misses what I see as the central > question about the economic assumptions in that paper. The paper assumes > that all destinations are equally valuable, which we know is not the case. > This implicitly (and perhaps mistakenly?) shifts the balance of power to > tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google). > In practice, ISPs may be willing to spend significant amounts of money to > reach certain destinations or content (some destinations are more valuable > than others... e.g., Google). If the most "valuable" destinations deployed > S-BGP and made everyone who wanted to connect to them deploy it, that would > be more likely to succeed than the approach taken in the paper, I think. Our paper does not assume all destinations are equally valuable. 1) As mentioned in our response to Randy, we weight content providers more heavily (see Section 6.8.1; we ran experiments where the content providers collectively source 10%, 20%, 33% or 50% of Internet traffic). 2) From Section 6.8.1: "We test the robustness of our results... by modeling traffic locality [the idea that ASes are likely to send more traffic to ASes that are closer to them]..." Section 6.8.2 shows our results are insensitive to this assumption. Sincerely, Phillipa Gill, Michael Schapira, and Sharon Goldberg > On Sep 5, 2011, at 11:36 AM, Joe Maimon wrote: > >> >> >> Owen DeLong wrote: >>> >>> On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote: >>> >>>> >>>>> >>>>> One could argue that rejecting routes which you previously had no way to >>>>> know you should reject will inherently alter the routing system and that >>>>> this >>>>> is probably a good thing. >>>> >>>> Good point. Also, "tie breaking" in favor of signed-and-verified routes >>>> over not-signed-and-verified routes does not necessarily affect your >>>> traffic "positively or negatively" -- rather, if you are letting an >>>> arbitrary final tie break make the decision anyway, you are arguably >>>> *neutral* about the outcome... >>>> >>>> -- Jen >>> >>> This is true in terms of whether you care or not, but, if one just looks at >>
Re: Do Not Complicate Routing Security with Voodoo Economics
simulations to deal with this lack of ground truth. Please see Section 8 of our paper for detailed discussion about these issues. Here I'll address Randy's specific criticisms with direct quotes from our paper: Randy: "The paper also completely ignores the rise of the content providers as described so well in SIGCOMM 2010 by Labovitz et alia[2] It is not clear how to ‘fix’ the economic model, especially as[3] says you can not do so with rigor. Once one starts, e.g. the paper may lack Tier-N peering richness which is believed to be at the edges, we have bought into the game for which there is no clear end." Section 6.8.1: "Published AS-level topologies are known to have poor visibility into peering links at the edge of the AS-level topology [31]. This is particularly problematic for CPs, because they peer with many other ASes to cut down costs of delivering content [14] .. Thus, for sensitivity analysis, we created an augmented AS graph with ... additional peering edges from the five Content Providers." For more details on this graph, see Appendix D "AS graph Sensitivity analysis". Also, based on Labovitz's paper, we ran simulations where the content providers were assumed to source a vast majority (up to 50%) of total Internet traffic (as discussed in Section 3.1 and 6.8.1). Please see Section 6.8.2 to see how these assumptions affected our results. Randy: "The paper's simulations really should be shown not to rely on the popular but highly problematic Gao-Rexford model of inter-provider relationships, that providers prefer customers over peers (in fact, a number of global Tier-1 providers have preferred peers for decades), and that relationships are valley free, which also has significant exceptions. Yet these invalid assumptions may underpin the simulation results." Section 8.3: "In practice,... the local routing policies used by each AS, ... are arbitrary and not publicly known. Thus, we use a standard model of routing policies (Appendix A) based on business relationship and path length [16, 6]." Here we'll interject to say that while there are definitely examples that lie outside this model (e.g. ASes the prefer peer routes over provider routes), it currently remains the only general model we have, to date, of interdomain routing. As such, we note in Section 8.3: "Routing policies are likely to impact our results by determining (a) AS path lengths (longer AS paths mean it is harder to secure routes), and (b) tiebreak set size (Section 6.6). For example, we speculate that considering shortest path routing policy would lead to overly optimistic results; shortest-path routing certainly leads to shorter AS paths, and possibly also to larger tiebreak sets." Thus, while we cannot hope to accurately model every aspect of interdomain routing, nor predict how S*BGP deployment will proceed in practice, we believe that ISP competition over customer traffic is a significant economic lever for driving global S*BGP deployment. Sincerely, Sharon Goldberg and Michael Schapira -- Sharon Goldberg Assistant Professor, Computer Science, Boston University http://www.cs.bu.edu/~goldbe On Sun, Sep 4, 2011 at 6:02 AM, Randy Bush wrote: > [ http://archive.psg.com/110904.broadside.html ] > > Do Not Complicate Routing Security with Voodoo Economics > a broadside > > A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and > Goldberg[1] drew a lot of 'discussion' from the floor. But that > discussion missed significant problems with this work. I raise this > because of fear that uncritical acceptance of this work will be used as > the basis for others' work, or worse, misguided public policy. > o The ISP economic and incentive model is overly naive to the point of > being misleading, > o The security threat model is unrealistic and misguided, and > o The simulations are questionable. > > Basic ISP economics are quite different from those described by the > authors. Above the tail links to paying customers, the expenses of > inter-provider traffic are often higher than the income, thanks to the > telcos' race to the bottom. In this counter-intuitive world, transit > can often be cheaper than peering. I.e. history shows that in the rare > cases where providers have been inclined to such games, they usually > shed traffic not stole it, the opposite of what the paper presumes. The > paper also completely ignores the rise of the content providers as > described so well in SIGCOMM 2010 by Labovitz et alia[2] > > It is not clear how to ‘fix’ the economic model, especially as[3] says > you can not do so with rigor. Once one starts, e.g. the paper may lack > Tier-N peering richness which is believed to be at the edges, we have > bought into the game for which there is