It appears that there is currently an influx of rogue route objects created within the NTTCOM and RaDB IRR databases, in connection to Quadranet (AS8100) and China Mobile International (CMI). Examples of affected networks are: 193.30.32.0/23 45.129.92.0/23 45.129.94.0/24 Networks, which have seemingly no affiliation with Quadranet, nor China Mobile International (CMI), which merely appears to be an upstream of Quadranet and hence creates the route objects in an automated manner. Another person has already reached out to Quadranet to find out the root cause of the creation of these objects. Their support gave an ETA of 24-72 hours. The route objects are all identical: route: 193.30.32.0/23 descr: CMI (Customer Route) origin: AS8100 mnt-by: MAINT-AS58453 changed: qas_support@cmi.chinamobile.com 20200117 source: RADB There appears to be a correlation with the affected networks, a fair share of them is part of AS-SBAG, which in turn is part of AS-VMHAUS, which in turn is part of AS- QUADRANET and could yield the importing of these prefixes. AS-VMHAUS appears to be a customer of Quadranet, listed within AS-QUADRANET-CUSTOMER-ASSET. These networks do however have no direct connection to Quadranet, and are not affiliated with Quadranet, nor are currently connected to Quadranet, which, entirely ignoring that the `origin` points to Quadranet, makes the route object illicit. Basically this has given AS8100, whether that be legitimately Quadranet, or somebody impersonating/spinning up a rogue AS8100, theoretical control over a massive amount of prefixes, as these can be advertised without restrictions and very likely reach a fairly high percentage of global visibility. -- Florian Brandstetter President & Founder SquareFlow Network LTD.
Hi! This came up on our radar somewhere in the last 24 hours too. It indeed does look very curious. Thank you for your analysis and report. NTT is taking steps to figure out what is behind this. Our current working theories are that perhaps the IRR maintainer account was compromised, or some kind of automation script gone rogue, or perhaps there is adverserial intent and this is stage setting. I'm not sure we will be able to report our findings back to this group, but we are actively investigating. Kind regards, Job On Sat, Jan 25, 2020 at 12:06:51AM +0100, Florian Brandstetter wrote:
It appears that there is currently an influx of rogue route objects created within the NTTCOM and RaDB IRR databases, in connection to Quadranet (AS8100) and China Mobile International (CMI).
Examples of affected networks are:
193.30.32.0/23 45.129.92.0/23 45.129.94.0/24
Networks, which have seemingly no affiliation with Quadranet, nor China Mobile International (CMI), which merely appears to be an upstream of Quadranet and hence creates the route objects in an automated manner.
Another person has already reached out to Quadranet to find out the root cause of the creation of these objects. Their support gave an ETA of 24-72 hours.
The route objects are all identical:
route: 193.30.32.0/23 descr: CMI (Customer Route) origin: AS8100 mnt-by: MAINT-AS58453 changed: qas_support@cmi.chinamobile.com 20200117 source: RADB
There appears to be a correlation with the affected networks, a fair share of them is part of AS-SBAG, which in turn is part of AS-VMHAUS, which in turn is part of AS- QUADRANET and could yield the importing of these prefixes. AS-VMHAUS appears to be a customer of Quadranet, listed within AS-QUADRANET-CUSTOMER-ASSET.
These networks do however have no direct connection to Quadranet, and are not affiliated with Quadranet, nor are currently connected to Quadranet, which, entirely ignoring that the `origin` points to Quadranet, makes the route object illicit.
Basically this has given AS8100, whether that be legitimately Quadranet, or somebody impersonating/spinning up a rogue AS8100, theoretical control over a massive amount of prefixes, as these can be advertised without restrictions and very likely reach a fairly high percentage of global visibility.
-- Florian Brandstetter President & Founder SquareFlow Network LTD.
Hi Florian, NANOG, While the symptom of (automatically) proxy registered route objects is problematic, perhaps we could also take this opportunity to discuss the underlying issue: we as an industry appear to place our trust in various IRR sources operated by entities that either can't or don't validate whether the actual owner of the involved resource approves the creation of the IRR database object. We should start to push our customers to maintain their route origin information in databases operated by the RIR or NIR which assigned the resource, or even through RPKI ROAs that were optionally converted into IRR route objects for the ease of consumption. It's also time for the RIRs to take their responsibility in this matter by facilitating services like IRR, RPKI, PTR, etc for legacy IP space under conditions which are palatable to corporate lawyers, if they haven't already done so. Finally, there doesn't have to be a global "flip the switch" day where we decide to stop trusting 3rd party databases, but even if we start holding ourselves to a higher standard one customer at a time that's still going to have the potential to make a big difference a couple of years down the road. Best regards, Martijn Schmidt PS, a small disclaimer: none of the above are new ideas, nor did I come up with them myself - but it still makes sense to work towards implementing them.. ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Florian Brandstetter <florianb@globalone.io> Sent: 25 January 2020 00:06 To: nanog@nanog.org <nanog@nanog.org> Subject: Rogue objects in routing databases It appears that there is currently an influx of rogue route objects created within the NTTCOM and RaDB IRR databases, in connection to Quadranet (AS8100) and China Mobile International (CMI). Examples of affected networks are: 193.30.32.0/23 45.129.92.0/23 45.129.94.0/24 Networks, which have seemingly no affiliation with Quadranet, nor China Mobile International (CMI), which merely appears to be an upstream of Quadranet and hence creates the route objects in an automated manner. Another person has already reached out to Quadranet to find out the root cause of the creation of these objects. Their support gave an ETA of 24-72 hours. The route objects are all identical: route: 193.30.32.0/23 descr: CMI (Customer Route) origin: AS8100 mnt-by: MAINT-AS58453 changed: qas_support@cmi.chinamobile.com 20200117 source: RADB There appears to be a correlation with the affected networks, a fair share of them is part of AS-SBAG, which in turn is part of AS-VMHAUS, which in turn is part of AS- QUADRANET and could yield the importing of these prefixes. AS-VMHAUS appears to be a customer of Quadranet, listed within AS-QUADRANET-CUSTOMER-ASSET. These networks do however have no direct connection to Quadranet, and are not affiliated with Quadranet, nor are currently connected to Quadranet, which, entirely ignoring that the `origin` points to Quadranet, makes the route object illicit. Basically this has given AS8100, whether that be legitimately Quadranet, or somebody impersonating/spinning up a rogue AS8100, theoretical control over a massive amount of prefixes, as these can be advertised without restrictions and very likely reach a fairly high percentage of global visibility. -- Florian Brandstetter President & Founder SquareFlow Network LTD.
Hi Martijn, albeit a negligible amount of edge cases it can indeed be stated that there is too much trust put into alternative IRR sources operated by third partys not affiliated to RIRs. Generally, usage of such databases however is not mis-used in a larger scope, and the complexity involved with creating route objects (AltDB for example validates new MAINTAINERS, RaDB charges) diminishes the vector in a (barely influental) manner. An option to combat this would perhaps be to run validation at regular intervals, and brings invalid objects to the attention of operators. I did similar for this incident just a moment ago with a batch of self- written scripts. After further analysis, there are over 5390 IPv4 prefixes pointing with their origin towards AS8100: https://pastebin.com/Zh1YZfEq Out of 5390 prefixes, 2287 are currently not even visible within the global routing table: https://pastebin.com/cSepb7yS Another 2714 prefixes are INVALID, that in particular means that AS8100 is neither *within* the announcing AS-PATH, nor originating the prefix: https://pastebin.com/JhaxVeN0 Last but not least, there is 389 VALID prefixes (in this case, perhaps only technically valid, as I did probe for AS8100 within the AS-PATH sequence, and not if AS8100 actually originates the prefix): https://pastebin.com/UVt6nwGz That's a conceivable 5001 IPv4 prefixes for a potential bad actor right there. It can also clearly be stated that, while initially mentioned, the significance of ascendence caused by AS-SBAG is negligible, as it appears, the entirity of Quadranet and affiliates is affected. Regards, Florian Brandstetter On Sat, 2020-01-25 at 01:02 +0000, Martijn Schmidt wrote:
Hi Florian, NANOG,
While the symptom of (automatically) proxy registered route objects is problematic, perhaps we could also take this opportunity to discuss the underlying issue: we as an industry appear to place our trust in various IRR sources operated by entities that either can't or don't validate whether the actual owner of the involved resource approves the creation of the IRR database object.
We should start to push our customers to maintain their route origin information in databases operated by the RIR or NIR which assigned the resource, or even through RPKI ROAs that were optionally converted into IRR route objects for the ease of consumption. It's also time for the RIRs to take their responsibility in this matter by facilitating services like IRR, RPKI, PTR, etc for legacy IP space under conditions which are palatable to corporate lawyers, if they haven't already done so.
Finally, there doesn't have to be a global "flip the switch" day where we decide to stop trusting 3rd party databases, but even if we start holding ourselves to a higher standard one customer at a time that's still going to have the potential to make a big difference a couple of years down the road.
Best regards, Martijn Schmidt
PS, a small disclaimer: none of the above are new ideas, nor did I come up with them myself - but it still makes sense to work towards implementing them.. From: NANOG <nanog-bounces@nanog.org> on behalf of Florian Brandstetter <florianb@globalone.io> Sent: 25 January 2020 00:06 To: nanog@nanog.org <nanog@nanog.org> Subject: Rogue objects in routing databases
It appears that there is currently an influx of rogue route objects created within the NTTCOM and RaDB IRR databases, in connection to Quadranet (AS8100) and China Mobile International (CMI).
Examples of affected networks are:
193.30.32.0/23 45.129.92.0/23 45.129.94.0/24
Networks, which have seemingly no affiliation with Quadranet, nor China Mobile International (CMI), which merely appears to be an upstream of Quadranet and hence creates the route objects in an automated manner.
Another person has already reached out to Quadranet to find out the root cause of the creation of these objects. Their support gave an ETA of 24-72 hours.
The route objects are all identical:
route: 193.30.32.0/23 descr: CMI (Customer Route) origin: AS8100 mnt-by: MAINT-AS58453 changed: qas_support@cmi.chinamobile.com 20200117 source: RADB
There appears to be a correlation with the affected networks, a fair share of them is part of AS- SBAG, which in turn is part of AS-VMHAUS, which in turn is part of AS- QUADRANET and could yield the importing of these prefixes. AS-VMHAUS appears to be a customer of Quadranet, listed within AS-QUADRANET-CUSTOMER-ASSET.
These networks do however have no direct connection to Quadranet, and are not affiliated with Quadranet, nor are currently connected to Quadranet, which, entirely ignoring that the `origin` points to Quadranet, makes the route object illicit.
Basically this has given AS8100, whether that be legitimately Quadranet, or somebody impersonating/spinning up a rogue AS8100, theoretical control over a massive amount of prefixes, as these can be advertised without restrictions and very likely reach a fairly high percentage of global visibility.
-- Florian Brandstetter President & Founder SquareFlow Network LTD.
On Sat, Jan 25, 2020 at 12:06:51AM +0100, Florian Brandstetter <florianb@globalone.io> wrote a message of 53 lines which said:
Examples of affected networks are:
193.30.32.0/23 45.129.92.0/23 45.129.94.0/24
Note that 193.30.32.0/23 has also a ROA (announces by 42198). So, announces by AS8100 would be RPKI-invalid. 45.129.92.0/23 also has a ROA. Strangely, the prefix stopped being announced on sunday 26. 45.129.94.0/24 has a ROA and is normally announced. So, if AS8100 were to use its abnormal route objects , announces would still be refused by ROA-validating routers.
Hi Stephane, NANOG – Do the math for all pertained prefixes in the pastes, those 3 prefixes were just examples I had at hand, and the event is still of quite some significance. Albeit ROA-validating routers being an argument that extenuates probabilities and the ensuing effect, deployment of such still lacks, hence my mention of reaching levels of (random guess) 90% global visibility still, taken the attacker understands ROA. It is certainly unlikely that networks that are known for rather puerile filtering, or lack of adequate filtering to filter the networks, so ultimately they will inevitably still transpire in the global tables. An impression emerges that commitment in resolving this incident lacks, apart from the guys over at NTT which, from what I gathered, suspended their IRR account temporarily to prevent further damage. — Cheers, Florian Brandstetter On 27. Jan 2020, 7:03 PM +0100, Stephane Bortzmeyer <bortzmeyer@nic.fr>, wrote:
On Sat, Jan 25, 2020 at 12:06:51AM +0100, Florian Brandstetter <florianb@globalone.io> wrote a message of 53 lines which said:
Examples of affected networks are:
193.30.32.0/23 45.129.92.0/23 45.129.94.0/24
Note that 193.30.32.0/23 has also a ROA (announces by 42198). So, announces by AS8100 would be RPKI-invalid.
45.129.92.0/23 also has a ROA. Strangely, the prefix stopped being announced on sunday 26.
45.129.94.0/24 has a ROA and is normally announced.
So, if AS8100 were to use its abnormal route objects , announces would still be refused by ROA-validating routers.
participants (4)
-
Florian Brandstetter -
Job Snijders -
Martijn Schmidt -
Stephane Bortzmeyer