US Dept of Energy AS32982 Network Possibly BGP Hijacked by China Telecom | Hacker News Reader

US Dept of Energy AS32982 Network Possibly BGP Hijacked by China Telecom

bgpstream.com

118 pointsmmaunder21 comments

So? What is the significance of one single event? Looking at that site it is not that uncommon. Did this event catch your attention simply because it had the right keywords (US Dept of Energy and China)?

MIT hijacked someone's route? https://bgpstream.com/event/171889

An US ISP? https://bgpstream.com/event/171683

Another US ISP? https://bgpstream.com/event/170328

China Telecom could have been a victim too? https://bgpstream.com/event/155707

The list goes on...

(edited: formatting)

For the same reason robbing a bank is a more significant event than robbing a 7-Eleven.

"Who is responding to such an event during the government shutdown?" was my first thought. Assuming nefarious intent, now would be an ideal time to stage an attack.

DoE is currently not affected by the partial shutdown. It's business as usual at the national laboratories and with other employees/contractors. The way it's funded means that there would have to be a prolonged shutdown before DoE would have to start shutting down, but I think even then security and safety essential personnel are exempt.

https://www.directives.doe.gov/directives-documents/100-seri...

But is ESnet [1]? They are the org responsible for providing inter-org networking services between US DOE labs and other associated institutions.

[1] http://es.net/

ESnet is not affected by the shutdown. Also, ESnet does not transit all DoE traffic. ESnet is a purpose built science network and if you look in the AS-Set, this network is not transited by AS293 (ESnet).

The plan includes pay for external contractors and security-essential functions, so yes I would assume so (though I don't know firsthand about them specifically). To the best of my knowledge, DoE will continue to run entirely as normal until carryover funding from previous allocations runs out. Couple months at least. After that it basically goes into hibernation, but I expect that communications and network security would be considered as essential and hence would remain funded even then.

Thank you!

Are you asking how BGP Hijacking can be used maliciously?

  WAPA <-> Austria, Belgium, Phillipines, Russia, & NY

  MTR test for 192.208.19.0 Dec 28, 2018 3:38:02 AM  44 agents  

  Agent 245-ATVIRTUAL.NET Location  AT - Gross Network A1 Telekom Au … (AS8447)
  Target: 192.208.19.0
  #	Host	Loss%	Snt	Last	Avg	Best	Wrst	StDev
  1.	|-- 192.168.123.1 - RFC1918 
  0	10	0.45	0.49	0.43	0.63	0.06
  2.	|-- 80.123.111.226 - AS8447 - ge003.atvirtual.net. 
  0	10	1	1	0.92	1	0.12
  3.	|-- 195.3.65.22 - AS8447 
  0	10	4	3	3	4	0.08
  4.	|-- 195.3.65.21 - AS8447 
  0	10	3	3	3	4	0.10
  5.	|-- 195.3.64.6 - AS8447 - lg2-1171.as8447.a1.net. 
  0	10	14	14	14	15	0.09
  6.	|-- 80.81.194.33 - AS47872 - GM-FF-FRK-F-1.163.chinatelecomeurope.com. 
  0	10	16	16	15	19	1
  7.	|-- 202.97.58.49 - AS4134 
  0	10	240	239	237	240	1
  8.	|-- 202.97.90.54 - AS4134 
  0	10	221	221	221	221	0.12
  9.	|-- 202.97.57.146 - AS4134 
  0	10	222	225	222	229	3
  10.	|-- Target unreachable	100	0	0	0	0	0	0
  
  Agent 172-tb1.attiks.com Location  BE - Antwerp Network Telenet … (AS6848)
  Target: 192.208.19.0
  #	Host	Loss%	Snt	Last	Avg	Best	Wrst	StDev
  1.	|-- 192.168.1.1 - RFC1918 
  0	10	0.29	0.33	0.28	0.41	0.04
  2.	|-- 81.82.192.1 - AS6848 - d5152c001.static.telenet.be. 
  0	10	32	13	8	32	7
  3.	|-- 213.224.200.145 - AS6848 - dD5E0C891.access.telenet.be. 
  0	10	8	10	7	12	2
  4.	|-- 213.224.250.109 - AS6848 - dD5E0FA6D.access.telenet.be. 
  0	10	13	13	10	23	4
  5.	|-- 80.239.132.217 - AS1299 - brx-b2-link.telia.net. 
  0	10	12	13	10	19	3
  6.	|-- 62.115.118.118 - AS1299 - adm-bb4-link.telia.net. 
  0	10	18	15	14	18	1
  7.	|-- 62.115.134.27 - AS1299 - ldn-bb4-link.telia.net. 
  0	10	20	21	19	26	2
  8.	|-- 62.115.134.139 - AS1299 - ldn-b4-link.telia.net. 
  0	10	22	25	21	31	4
  9.	|-- 62.115.14.114 - AS1299 - chinatelecom-ic-335946-ldn-b4.c.telia.net. 
  0	10	26	25	22	31	3
  10.	|-- 202.97.71.73 
  0	10	212	211	208	213	1
  11.	|-- 202.97.90.58 - AS4134 
  0	10	230	230	229	232	1
  12.	|-- 202.97.57.158 - AS4134 
  0	10	232	233	228	245	5
  13.	|-- Target unreachable	100	0	0	0	0	0	0
  
  Agent 244-ManilaPH Location  PH - Pateros Network PLDT … (AS9299)
  Target: 192.208.19.0
  #	Host	Loss%	Snt	Last	Avg	Best	Wrst	StDev
  1.	|-- 192.168.1.1 - RFC1918 
  0	10	0.67	0.72	0.67	0.90	0.07
  2.	|-- 112.205.0.1 - AS9299 - 112.205.0.1.pldt.net. 
  0	10	2	9	2	17	6
  3.	|-- 122.2.175.182 - AS9299 - 122.2.175.182.static.pldt.net. 
  0	10	2	2	2	5	1
  4.	|-- 210.213.132.30 - AS9299 - 210.213.132.30.static.pldt.net. 
  0	10	3	4	2	12	3
  5.	|-- 122.2.175.50 - AS9299 - 122.2.175.50.static.pldt.net. 
  0	10	3	3	2	3	0.18
  6.	|-- 210.213.131.73 - AS9299 - 210.213.131.73.static.pldt.net. 
  0	10	2	6	2	40	12
  7.	|-- 157.238.179.225 - AS2914 - ae-12.r06.plalca01.us.bb.gin.ntt.net. 
  0	10	145	145	145	146	0.28
  8.	|-- 129.250.4.119 - AS2914 - ae-15.r02.snjsca04.us.bb.gin.ntt.net. 
  0	10	145	146	145	148	0.84
  9.	|-- 129.250.3.163 - AS2914 - ae-0.a01.snjsca04.us.bb.gin.ntt.net. 
  0	10	146	147	145	151	2
  10.	|-- 129.250.9.74 - AS2914 - ae-0.chinanet.snjsca04.us.bb.gin.ntt.net. 
  0	10	156	155	154	157	1
  11.	|-- 202.97.50.77 - AS4134 
  0	10	156	157	153	160	2
  12.	|-- 202.97.51.237 - AS4134 
  0	10	306	306	304	308	1
  13.	|-- 202.97.90.30 - AS4134 
  0	10	300	299	297	303	2
  14.	|-- 202.97.24.133 - AS4134 
  0	10	306	308	306	309	1
  15.	|-- Target unreachable	100	0	0	0	0	0	0
  
  Agent 143-TerAnYu Location  RU - Novosibirsk Network Novotelecom … (AS31200)
  Target: 192.208.19.0
  #	Host	Loss%	Snt	Last	Avg	Best	Wrst	StDev
  1.	|-- 10.5.55.1 - RFC1918 
  0	10	0.55	0.57	0.54	0.62	0.03
  2.	|-- 37.194.53.253 - AS31200 - l37-194-53-253.novotelecom.ru. 
  0	10	5	2	0.81	6	2
  3.	|-- 10.245.138.241 - RFC1918 
  0	10	1	1	1	2	0.18
  4.	|-- 10.245.138.242 - RFC1918 
  0	10	3	4	1	13	4
  5.	|-- 217.150.61.78 - AS20485 - nsk06.nsk32.transtelecom.net. 
  0	10	4	2	2	4	0.58
  6.	|-- 188.43.227.2 - AS20485 - vvk06rb.transtelecom.net. 
  0	10	155	155	155	156	0.57
  7.	|-- 188.43.227.1 - AS20485 - ChinaTelecomEurope-gw.transtelecom.net. 
  0	10	156	156	155	156	0.05
  8.	|-- 202.97.30.229 - AS4134 
  0	10	183	182	179	185	2
  9.	|-- 202.97.53.225 - AS4134 
  0	10	179	179	176	180	1
  10.	|-- 202.97.48.205 - AS4134 
  0	10	187	185	182	187	2
  11.	|-- Target unreachable	100	0	0	0	0	0	0
  
  Agent 146-Bitly-NY Location  US - New York Network Pilot Fiber … (AS46450)
  Target: 192.208.19.0
  #	Host	Loss%	Snt	Last	Avg	Best	Wrst	StDev
  1.	|-- 10.0.0.1 - RFC1918 
  0	10	0.92	0.87	0.82	0.92	0.04
  2.	|-- 69.12.26.89 - AS46450 
  0	10	16	20	7	38	9
  3.	|-- 104.129.140.204 - AS53340 - et-0-0-8.ar01.jfk00.nyc.pilotfiber.com. 
  0	10	3	3	2	3	0.19
  4.	|-- 104.129.140.65 - AS53340 - ae-16.cr01.jfk05.nyc.pilotfiber.com. 
  0	10	3	2	2	3	0.18
  5.	|-- 168.143.229.77 - AS2914 - ae-30.a02.nycmny01.us.bb.gin.ntt.net. 
  0	10	4	3	3	5	0.75
  6.	|-- 129.250.5.90 - AS2914 - ae-54.r08.nycmny01.us.bb.gin.ntt.net. 
  0	10	91	91	91	92	0.14
  7.	|-- 129.250.5.61 - AS2914 - ae-3.r24.nycmny01.us.bb.gin.ntt.net. 
  0	10	3	4	2	16	4
  8.	|-- 129.250.4.13 - AS2914 - ae-4.r22.sttlwa01.us.bb.gin.ntt.net. 
  60	10	67	68	67	68	0.39
  9.	|-- 129.250.6.30 - AS2914 - ae-0.r23.sttlwa01.us.bb.gin.ntt.net. 
  0	10	68	68	67	72	2
  10.	|-- 129.250.3.124 - AS2914 - ae-3.r23.snjsca04.us.bb.gin.ntt.net. 
  0	10	86	86	85	88	0.62
  11.	|-- 129.250.3.175 - AS2914 - ae-45.r01.snjsca04.us.bb.gin.ntt.net. 
  0	10	91	91	91	91	0.23
  12.	|-- 129.250.2.48 - AS2914 - ae-1.a01.snjsca04.us.bb.gin.ntt.net. 
  0	10	87	87	86	91	2
  13.	|-- 129.250.9.74 - AS2914 - ae-0.chinanet.snjsca04.us.bb.gin.ntt.net. 
  0	10	94	96	92	99	2
  14.	|-- 202.97.50.77 - AS4134 
  0	10	79	82	78	85	2
  15.	|-- 202.97.71.197 
  0	10	220	218	215	222	2
  16.	|-- 202.97.91.33 - AS4134 
  0	10	221	221	221	221	0.25
  17.	|-- 202.97.57.158 - AS4134 
  0	10	221	221	218	225	2
  18.	|-- 61.152.24.13 - AS4812 
  20	10	201	200	199	203	1
  19.	|-- Target unreachable	100	0	0	0	0	0	0

https://twitter.com/cpqNetworks/status/1078586917480992768

It's not neccessarily AS4812 / China Telecom announcing this themselves. Anyone could be announcing AS4812,192.208.19.0/24. For some degree of attribution, you need to go and figure out where the actual announcement is coming from.

The "beauty" of BGP :)

edit: It's also interesting to note that the bogus announcement is for /24, which is more specific than the original /23, so it takes precedence.

For reference, the path observed by BGPMon was:

  11039 The George Washington University
  46887 Lightower Fiber Networks I, LLC
  6939 Hurricane Electric LLC
  4134 China Telecom Backbone
  4134 China Telecom Backbone
  4134 China Telecom Backbone
  4812 China Telecom (Group)

Hurricane Electric has been known to not apply route filters to large peers, leading to hijacks like this. I suspect that was the case here, too. Although you are right, this path could have been spoofed by GWU or Lightower (or BGPMon!)

Article describing BGP hijacking. It is the first article from a DDG search, and I know nothing of the topic so YMMV.

https://www.internetsociety.org/blog/2018/05/what-is-bgp-hij...

Wikipedia article: https://en.wikipedia.org/wiki/BGP_hijacking

The article mentions there are mitigations to this type of attack available. Does anyone know of how an individual user could (practically) reduce their exposure to this type of attack?

The IP you normally would have communicated with is among the hijacked IPs, then you have exposure. The data you send to such IP is ending up in the hijacker's hands. As an end user, your only defense is to use end-to-end authenticated encryption between you and your intended other end-point. The authenticated part is very critical in this case.

A typical mitigation at the ASN level is to have allowlists of exactly which prefixes your downstsream ASN is expected and allowed to announce. I don't recall the name of this technique, and it's somewhat widely deployed, but definitely far from widely enough to secure Internet routing.

Individual end users don't have much of a chance to avoid BGP hijacking. You could continuously run traceroutes to your destination network, but then that gives you not much guarantee that individual TCP connections will take the same route as those ICMP packets.

By using encryption. That way if such attack occurs, the only negative effects is downtime, rather than data exposure.

Encryption does not help BGP hijacks at all. You need to filter the accepted upstream routes. But filtering ultimatively defeats the purpose of BGP - route learning is no longer fully dynamic and need some manual approvals.

Just noticed this one, too: https://bgpstream.com/event/170070

Does it mean an Iranian telecom hijacked some of AT&T's traffic?

Notionally yes, though as with a lot of these hijackings it's really a question of how far it propagated/who is correctly filtering routes. This happens with Iran Tele from time to time, typically when they are trying to block something specific internally and let the route leak out (e.g. their Telegram block back in July).

Reply on news.ycombinator.com