Celer Network cBridge Cross-Chain Bridge Incident Analysis: BGP Hijacking Attack | Think like an attacker, defend like a guardian

Incident Background

On August 18, Celer Network officially stated that between 3:45 and 6:00 Beijing Time on August 18, some users of cBridge were redirected to malicious smart contracts, and the cBridge frontend was suspected of suffering a DNS Hijacking attack. Unlike previous cross-chain bridge hacking incidents such as Nomad, Wormhole, Ronin, and Harmony, this attack was not caused by bugs in the smart contracts or cross-chain protocol, nor by the compromise of related servers, so the cross-chain assets locked in cBridge remained safe throughout. In this attack, the hacker directly targeted the underlying infrastructure of the Internet architecture outside the Celer system. By deceiving the Internet’s underlying routing protocol (BGP), cross-chain users were directed to a “phishing” frontend user interface for a period of time. Because the Celer Network team has a 24-hour monitoring mechanism, customer service identified the issue immediately, and the team’s subsequent response was timely and well-handled, keeping user losses very small. At the same time, at the invitation of the Celer Network team, the SlowMist security team also participated in the emergency response at the earliest opportunity and assisted with in-depth analysis.

Celer Network official statement

Analysis Process

Initially, the Celer Network team suspected DNS Hijacking. After communicating and discussing with the Celer Network team, we obtained the problematic domain: cbridge-prod2.celer.network. According to user feedback, the browser did not show any certificate errors during the attack, so we first investigated the possibility of DNS Hijacking. (Special thanks to Twitter user @greysign1 for helping us quickly rule out the possibility of DNS Hijacking.)

Let’s first look at the relevant certificate information: https://crt.sh/?q=celer.network

Certificate information

Clearly, the certificate had changed abruptly. The original Let’s Encrypt-issued certificate was replaced by a forged certificate issued by GoGetSSL.

GoGetSSL can issue free 90-day certificates:

GoGetSSL free certificate

Certificate 1 analysis: https://crt.sh/?id=7356185959

SHA-256	A01A34FE398E56D80BDDA40EFB555D14654856B5FAA6C92BFEBEF2861D712732

A CRL Check error appeared on the certificate, at the following time:

Certificate 1 CRL error

Certificate 2 analysis: https://crt.sh/?id=7356184952

SHA-256	579FABEE3A9F7EFECD43C99795744C4B93DC49A4FB93E174B201F8A333990C1A

This certificate also showed a CRL Check error, at the following time:

Certificate 2 CRL error

Analyzing the IP and certificate associated with certificate 1, we found that the IP bound to the certificate was 44.235.216.69:

Certificate 1 bound IP

https://search.censys.io/hosts/44.235.216.69

Censys host information

When investigating the IP for certificate 2, we could not find the corresponding IP address. This may be because the attack lasted only a short time, and Internet search engines failed to capture the relevant information.

Therefore, the SlowMist security team shifted the focus of the investigation to querying the IP resolution records for the cbridge-prod2.celer.network domain:

cbridge-prod2.celer.network had been resolving to 44.235.216.69 for a long time:

DNS resolution records

Question: cbridge-prod2.celer.network had been resolving to 44.235.216.69 for a long time, which suggests that this IP should belong to the official Celer Network servers. After confirming with the Celer Network team, 44.235.216.69 is indeed their IP. But why would a forged certificate be bound to this 44.235.216.69 IP?

So we began checking the AS of 44.235.216.69 and found that the AS corresponding to this IP was abnormal.

AS check

AS16509 indicated that AS16509 announces bogons:

AS16509 bogons

Consulting relevant materials on bogons, this situation often occurs in scenarios where attackers forge IPs to launch attacks:

https://networkdirection.net/articles/routingandswitching/bgp-bogonsandmartians/
https://forum.networklessons.com/t/what-are-bogons/6333

bogons reference materials

Because the AS of 44.235.216.69 showed anomalies, we initially suspected that the problem might be related to BGP. The SlowMist security team continued communicating with the Celer Network team and obtained the attack IP: 54.84.236.100. Analyzing 54.84.236.100, we found that AS14618, where this IP resides, was also abnormal (AS14618 also announces bogons).

AS14618 anomaly

Coincidentally, the upstream of AS14618 is AS16509 (AS16509 is also the AS where 44.235.216.69 is located). At this point, the SlowMist security team became alert — this situation is very likely a BGP Hijacking attack.

AS upstream relationship

Continuing the investigation of the attack IP 54.84.236.100, we found that this IP had already been flagged as a malicious IP.

Malicious IP flag

We also obtained intelligence about 54.84.236.100 through the intelligence community. One piece of intelligence mentioned that 54.84.236.100 was related to a BGP Hijacking incident in 2014, but because that incident was so long ago, it may not be time-relevant for now.

Intelligence reference

https://www.secureworks.com/research/bgp-hijacking-for-cryptocurrency-profit

SecureWorks reference

The SlowMist security team continued its in-depth analysis along the BGP Hijacking direction and began tracing BGP Trace records:

BGP Trace

Tracing the BGP Trace records of the attack IP 54.84.236.100, we found that this route can no longer be found now.

Attack IP BGP Trace

Continuing to trace the BGP Router Trace records of Celer’s IP 44.235.216.69, the route could be found normally.

Celer IP BGP Trace

Next, we queried the BGP node change records:

Beijing Time: 8/18/2022 2:48 AM - 8/18/2022 7:48 AM UTC+8

BGP node changes

We found that during the period from 2:48 AM to 7:48 AM Beijing Time on 8/18/2022, there were a large number of node addition and deletion change records.

We continued to trace the AS change records and found that AS14618 historically contained the route 44.235.216.0/24, but this path was later Withdrawn. This proves:

Previously, 44.235.216.0/24 in AS14618 was the optimal path
Now, 44.235.216.0/24 in AS14618 is no longer the optimal path, so it was Withdrawn

(When BGP Hijacking occurs, the attacker announces an optimal path to direct traffic to their own server.)

AS14618 routing history

https://smakd.potaroo.net/cgi-bin/per-as?as=14618

Withdrawn route

Through the above analysis, there are already clear traces of BGP Hijacking. To obtain more precise data, we used bgplay to view the changes of the relevant paths of 44.235.216.69 before and after the attack time:

https://stat.ripe.net/special/bgplay#bgplay_fetch.resource=44.235.216.69

bgplay analysis

We can see that during the period from 2022-08-17 19:19:23 +UTC to 2022-08-17 23:19:23 +UTC, the BGP routing path information showed significant volatile changes.

BGP routing changes

These changes manifested as: directing the traffic of 44.235.216.0/24 to AS14618, and after the attack time, the traffic path of 44.235.216.0/24 went through AS16509 again.

AS14618 Withdrawn

Technical Detail

The attacker was able to bind certificate 1 (the forged certificate) to Celer Network’s IP 44.235.216.69 because they had a malicious server with the same IP 44.235.216.69, and GoGetSSL supports HTTP-based validation — all the attacker had to do was place a GoGetSSL-provided txt file on the malicious server. Through BGP Hijacking, traffic could be redirected to the malicious server with the same IP to complete the binding of certificate 1, so the browser would not raise any certificate error.

When communicating over HTTPS, data cannot be encrypted/decrypted without the certificate’s private key. Therefore, to ensure the certificate was valid and to perform a man-in-the-middle attack, the attacker needed to rebind a certificate obtained from a trusted authority to the malicious server with the same IP 44.235.216.69. This way, the attacker could decrypt the client’s data and insert malicious code into the response packets.

Therefore, we concluded that this incident was most likely a BGP Hijacking issue, and AS14618 should be a node that the attacker could control (AS14618’s Router may have had security issues that allowed the attacker to exploit it). The attack lasted about 4 hours.

Reasons for judging that AS14618 should be controllable by the attacker:

The attacker first directed the traffic of 44.235.216.69 to AS14618, and after the attack ended, the route of 44.235.216.69 returned to AS16509
The attack IP 54.84.236.100 was also within AS14618
After the attack ended, AS14618 Withdrawn the route of 44.235.216.69

Analysis Conclusion

This attack incident was jointly and thoroughly analyzed by the SlowMist security team and the Celer Network team. The incident was a security event caused by a BGP Hijacking attack. This was a purposeful BGP Hijacking attack against Celer Network — the attacker’s choice of attack timing, certificate forgery, and AS control were all executed seamlessly.

Finally, it is worth reminding that many operators are already well aware of the risks of BGP Hijacking attacks and have made adequate preparations. However, many project teams are not so aware, especially regarding network path changes caused by AS changes — without adequate preparation and response measures, they may well be repeatedly attacked by the same attacker or other attackers in the future. Therefore, the SlowMist security team recommends that project teams, Internet service providers, and server hosting providers should recognize the risks of such incidents and cooperate in defense to prevent them from happening again. If you need assistance, please contact the SlowMist security team.

Appendix:

【1】BGP Hijacking primer reference link: https://www.cloudflare.com/zh-cn/learning/security/glossary/bgp-hijacking/

【2】cbridge-prod2.celer.network DNS change diagram:

DNS change diagram