Truth Behind the Celer Network cBridge cross-chain bridge incident: BGP hijacking
Background
Celer Network officials stated on August 18 that between 3:45 and 6:00 Beijing time, certain cBridge users were directed to malicious smart contracts. Initially, the cBridge front-end interface was suspected of being compromised by DNS hijacking.
Completely different from the previous cross-chain bridge hacking incidents such as Nomad, Wormhole, Ronin, Harmony, etc., this attack was not caused by bugs in smart contracts and cross-chain protocols or the intrusion of related servers, and the cross-chain assets locked in cBridge have also been kept safe. In this attack, the hackers directly targeted the underlying infrastructure in the Internet architecture outside the Celer system, and allowed cross-chain users to access a “phishing” front-end user interface within a period of time by deceiving the Internet’s underlying routing protocol (BGP).The Celer network was able to limit damages due to their prompt response.This is because the Celer Network team has a 24-hour monitoring system. Their customer service team was able to identify the problem and alert the community in a timely manner. The Celer Network team empowered the SlowMist security team to respond to this emergency and conduct an in-depth investigation.
Analysis Process
The Celer Network team initially suspected a DNS hijacking, and after communicating with them, we were able to learn more about the domain name in question: cbridge-prod2.celer.network. We discovered that the browser did not report a certificate error during the attack. Therefore, our investigation started with addressing the possibility of DNS hijacking first. (Special thanks to @greysign1 for helping us to quickly check the possibility of DNS Hijacking)
We began by reviewing the relevant certificate information:
The certificate appears to have been altered unexpectedly, where the original certificate issued by Let’s Encrypt was replaced with a counterfeit certificate issued by GoGetSSL.
GoGetSSL can issue a free 90 day certificate:
- Analysis of Certificate 1: https://crt.sh/?id=7356185959
A CRL Check error appears on the certificate at the following time:
- Analysis of Certificate 2: https://crt.sh/?id=7356185959
This certificate also has a CRL Check error at the following times:
After examining the IP address, the certificate, as well as other information associated with Certificate 1, we discovered that the IP address bound by this certificate was 44.235.216.69.
The IP address of Certificate 2 failed to query the IP address corresponding to Certificate 2, which could be due to the short duration of the attack and the Internet search engine’s failure to collect relevant information.
As a result, we focused our analysis on the IP resolution data for the cbridge-prod2.celer.network domain:
IP address, 44.235.216.69, was associated with cbridge-prod2.celer.network for an extended period of time.
Here’s the question: The fact that this IP address, 44.235.216.69, was associated with cbridge-prod2.celer.network for an extended period of time, proves that it belonged to the official Celer Network server. This was also confirmed with the Celer Network team. So why was there a counterfeit certificate associated with this IP?
So we began to investigate the AS of 44.235.216.69 and discovered that the AS corresponding to this IP was unusual.
AS16509 announces bogons：
Looking through the bogons, we’re able to determine that this is generally the case where an attacker spoofs an IP address to perform an attack:
https://networkdirection.net/articles/routingandswitching/bgp-bogonsandmartians/
https://forum.networklessons.com/t/what-are-bogons/6333
Because the AS at 44.235.216.69 exhibited anomalies, we first suspected that the issue was with BGP, therefore we reached out to the Celer Network to obtain the IP address of the attacker: 54.84.236.100. We discovered that AS14618, where the IP address is located, also had an exception. (AS14618 also announces bogons)
Coincidentally, the upstream of AS14618 was AS16509 (AS16509 is also the AS where 44.235.216.69 is located). This alerted us to the possibility of a BGP Hijacking attack.
Our investigation revealed that IP: 54.84.236.100 was flagged as malicious.
We collected relevant information on IP: 54.84.236.100 from our community and found a mention of that IP address being related to another BGP Hijacking incident that occured back in 2014. However, because this incident occurred a long time ago, it may no longer be relevant.
We then continued our investigation by following the records left behind by this BGP Hijacking:
Tracking the BGP record for the attack IP: 54.84.236.100 revealed that the route is no longer available.
We continued tracking the BGP router traces for celer’s IP: 44.235.216.69 and were able to find the correct route.
We then checked the BGP node change log:
Beijing time: 8/18/2022 2:48 AM — 8/18/2022 7:48 AM UTC+8
On 8/18/2022, the time period between 2:48 AM — 7:48 AM BST was found to have a large number of node additions and deletions of change records.
We continued to monitor the AS change log and discovered that AS14618 formerly had the routing information 44.235.216.0/24, but the path was then altered to Withdrawn, proving that:
- 44.235.216.0/24 in AS14618 used to be the optimal path
- Now 44.235.216.0/24 in AS14618 is no longer the optimal path; it is Withdrawn.
(When BGP Hijacking occurs, the attacker will publish an optimal path to direct traffic to his own server)
In order to get more accurate data, we used the following bgplay to check the changes in the paths related to 44.235.216.69 around the time of the attack.
On 8/17/2022, we can see that during the time period between 19:19:23 +UTC and 23:19:23 +UTC, there was a significant fluctuation in the information of BGP routing pathways.
This change is reflected in directing traffic from 44.235.216.0/24 to AS14618, where traffic from 44.235.216.0/24 goes out through AS16509 after the attack.
As a result, we’re considering that this incident is likely a BGP Hijacking event, where AS14618 appears to be a node under the attacker’s control (The router of the AS14618 may have security issues and may be exploited by attackers), with the attack lasting approximately 4 hours.
The attacker was able to bind Certificate 1 (counterfeit certificate) to Celer Network’s IP: 44.235.216.69 because the attacker had a malicious server with the same IP. Since gogetssl supports http for authentication, they can just input text provided by gogetssl into the malicious server. Therefore, making it possible to bind Certificate 1 by directing traffic to the malicious server with the same IP through BGP Hijacking. As a result, the browser was alerted of the certificate error.
We determined that AS14618 was controlled by the attacker for the following reasons.
- The attacker first directed traffic of 44.235.216.69 to AS14618, and routed 44.235.216.69 back to AS16509 after the attack.
- Attack IP: 54.84.236.100 is also inside AS14618.
- After the attack, AS14618 was Withdrawn to 44.235.216.69.
To answer this question: The fact that this IP address, 44.235.216.69, was associated with cbridge-prod2.celer.network for an extended period of time, proves that it belonged to the official Celer Network server. This was also confirmed with the Celer Network team. So why was there a counterfeit certificate associated with this IP?
If you use HTTPS protocol to communicate, you cannot encrypt/decrypt the data (including the data of client/server communication) without getting the private key of the certificate. So to ensure the certificate is correct and be able to carry out the man-in-the-middle attack, the attacker needs to rebind the certificate applied in the authority to the malicious server with the same IP 44.235.216.69. This enables the attacker to decrypt the client’s data and insert the malicious code into data of the response packet.
Analysis Conclusion
We investigated this attack in collaboration with the Celer Network team. Despite the fact that this was a sophisticated BGP Hijacking attempt on the Celer Network, with the attacker preparing everything from the timing of attack, certificate forgery, AS control, and other operations.
Ultimately, we recognize that many projects are already aware of the risks associated with BGP Hijacking attacks and have taken appropriate precautions. However, many are still unaware, particularly when it comes to network path modifications induced by AS changes. Without adequate preparation and response measures, there is a considerable risk of further attacks by the same or other attackers. Therefore, we urge that organizations, ISPs, and server hosting providers recognize such risks and coordinate on defensive strategies to prevent similar incidents from occurring again. And, as always, if you ever need assistance, please contact the SlowMist Security Team.
Attachment
BGP Hijacking principle reference link:
https://www.cloudflare.com/en-us/learning/security/glossary/bgp-hijacking/
cbridge-prod2.celer.network DNS Chart:
New to trading? Try crypto trading bots or copy trading
