Current issues of security of digital financial assets and cross-border payments based on blockchain technologies
The topic of cross-border payments and digital financial assets (DFA) has actively settled in the media sphere in recent years. Unfortunately, the discussion mainly comes down to assessing financial benefits and legal issues. While there are also security issues, which, in my opinion, are largely underestimated today (although awareness of the problem is gradually happening: about this start speaking publicly). There is little public information about security in this area. Meanwhile, the digital financial assets market is growing: almost 8-fold growth is expected in the Russian Federation in 3 years (up to 500 billion rubles). And the world – over $8 trillion by 2029. Therefore, security issues are becoming increasingly relevant. I had the opportunity to talk to some developers, explore the architectural solutions of some corporate blockchains. Also, I often encountered established misconceptions about risk factors that I would like to dispel. Based on all this, as well as my diverse experience (pentest, development, code review, including in the blockchain field), I would like to share my opinion on the current state of security of financial solutions based on blockchain technologies. And the reasons behind this. In the examples, the Hyperledger Fabric blockchain will be used to describe the problems. But, in many cases, the example can be common to other corporate blockchains.
Content:
The Place of Blockchain in Digital Financial Assets and Cross-Border Payments
First, let's note that blockchain is used in digital financial assets and cross-border payments. According to the Central Bank of the Russian Federation website, for 2022-2024, the register of information system operators 11 companies included. Most of them use blockchain for this. At the same time, the process is actively developing use of digital financial instruments as international settlements.
Blockchain is also actively used in digital currencies of central banks of various countries. SWIFT also announced the creation of infrastructure for operations with digital assets and digital currencies of central banks of different countries.
Additionally, I recommend reading the article on the benefits of blockchain in the corporate environment. It explains why blockchain has become a convenient tool for corporate use.
Developers' reluctance to acknowledge security issues
Now let's move on to security issues. A fresh story from my personal experience. I discovered a vulnerability in the Hyperledger Fabric blockchain (CVE-2024-45244). After my appeal through HackerOne the developers released correction. But they did not recognize it as a vulnerability: they did not assign a CVE identifier. In the end, I achieved the assignment of a CVE on my own. After I reported the assignment of a CVE to the developers, they tried to challenge it. They failed to challenge it. This is how I understood the developers' position: everything works as intended. In addition, there have been no incidents for a long time, so there is no problem as such. That's when I realized that with this approach, proving anything is useless, you need to get busy with assigning a CVE.
The bottom line of this story: the fix is currently unavailable for stable versions: the fix is only present in the main branch. I did not find any information about the vulnerability from the developers to users (on the project page in github in the list of vulnerabilities (not listed). I also didn't find any recommendations from the developer: what should users do who use the version without fixes? Personally, I got the impression that some developers believe that only they have the right to determine what is a vulnerability and what is not. Ignoring the established practice of interaction between security researchers and MITRE.
Now let's imagine: how many potential vulnerability reports could have been rejected by various developers? And did all the authors of such reports not lose their heads, but managed to assign CVE to their vulnerabilities?
The challenges of adopting open blockchain threat models without the necessary adaptation
I often come across the opinion that corporate blockchains have the same security problems as open blockchains. And, in order not to reinvent the wheel – let's just be guided by them. At the same time, even among blockchain security specialists, the opinion has become established: all attention is on smart contracts, there may be various errors, and the blockchain itself is safe – since it has been working for so long and is still alive (unlike smart contracts, which often become a target for attacks). If any small errors appear, they are quickly corrected. In addition, there are a lot of nodes (i.e. elements) in open blockchains. Each owner is interested in maintaining a working node. And even if many nodes fail, this will be acceptable and will not affect the operation of the entire blockchain. Unless a vulnerability is found at the protocol level of the entire blockchain, which will stop the entire network (but here we again return to the belief in the security of the blockchain). Well, and all the logic with finances in smart contracts, why would anyone attack the infrastructure?
In the previous section I have already shown: how things stand with the absence of vulnerabilities in the blockchain. In the part about Hyperledger Fabric, opponents sometimes refer to the report according to pentest from 2021 (which is not the first publicly available report pentest), which says that “the blockchain has reached a mature level of security and functionality.” To this I will note: since 2021 registered 7 CVEs (most of which are high-risk). Moreover, some of them (from 2021) existed at the time of the pentest, but for some reason were not detected.
As for blockchain nodes: unlike open blockchains (where there may be thousands of nodes), the number of participants in corporate ones is very limited. Which greatly simplifies the task of an attacker to disable the blockchain network by organizing an attack on the identified elements. For example, look at the diagram of a small Hyperledger Fabric blockchain network.
Presented here:
C1 – channel;
P1,P2 – peer nodes;
O4 – ordering service;
L1,L2 – copies of the registry (i.e. database);
S5 – smart contract;
A1, A2, A3 – applications;
R1,R2,R4 – organizations;
CA (1,2,4) – certification centers.
And the security of all these components should be taken care of. I found various elements of the Hyperledger Fabric blockchain available via the Internet: peers, ordering services. And even databases (it’s hard for me to think of why a DB should be available to the entire Internet). Including outdated versions. Which allowed attacks to be carried out and business processes to be stopped. Since we are talking about a finite number of nodes interacting with each other, it is worth thinking about an access list (ACL). Even if we imagine a situation in which it is difficult to keep the ACL up to date, you can use a dynamic ACL (I like this option did).
In addition, not all vulnerabilities that are discovered will be publicly known. Especially considering that the area of digital financial assets and cross-border payments is very important for the state. About this spoke and Director of the Department of Operational Risks, Information Security and Business Continuity of the Moscow Exchange Sergey Demidov. Especially considering the history when CIA hacking tools (including exploits for previously unknown vulnerabilities) have already become public knowledge.
Penetration Testers Ignoring Blockchain Elements
Quite often, large companies order penetration testing. At the same time, they believe that since the blockchain elements are inside the network being tested, then if there are vulnerabilities in the blockchain, this will be reflected in the report. And if the report does not mention blockchain, then there is no problem either. The main mistake that customers make is the lack of verification of the contractor's competence for specialized knowledge of blockchain and its network part. As a result, the report does not include information about vulnerabilities in the blockchain, not because they do not exist, but because the contractors do not have the necessary qualifications. And it is a big problem to find a suitable company at all. I interviewed several large companies specializing in penetration testing, talked to department heads. In all the companies, I was told that they had not encountered blockchain. Which is quite strange, considering that I found blockchain elements on the Internet in large companies on my own. Once, during an interview, it turned out that the head of the department and I saw the same infrastructure of one customer. The manager admitted to me that he had seen the service I was talking about, but it was not included in the report because: “we didn't understand at all: what it was.” And it was a vulnerable service, an attack on which could potentially lead to a stop in the business process. In another penetration testing company, the manager told me that they test everything in the customer's network equally well and they do not need narrow specialists. At the same time, he could not remember a single report that included blockchain. This is like a therapist saying that he is ready to give an expert opinion instead of a neurologist: he will give it. But how useful is such an opinion really?
Lack of blockchain in cyber polygons
Cyber polygons are special mock-ups that imitate an enterprise network. At such polygons: some specialists learn to carry out attacks on vulnerable equipment, while others learn to detect and prevent attacks. Some cyber polygons are sold as a service to customers: so that their security specialists gain the skills necessary for use on a real industrial enterprise network. The main problem: these cyber polygons are often made by the same companies that provide penetration testing services. And, as has been shown earlier, there are usually no blockchain specialists. In fact, it is difficult to find the blockchain elements themselves in a cyber polygon. I talked to the head of cyber polygon development at a large Russian company. And he honestly admitted that he had never encountered either blockchain or customer interest in it.
Network traffic monitoring and analysis tools are not designed to attack blockchain elements
There are different types of solutions for protecting against attacks on a company's network infrastructure: NTA, NGFW, WAF. But, all of them are not designed for targeted attacks on blockchain nodes. For example, for the Hyperlayer Fabric blockchain, information about 6 different attacks at the network level is available in public sources. At the same time, I did not find information in the public field about which solution for protection against attacks on network infrastructure is capable of preventing them. Yes, at least some of the solutions can technically be supplemented with information about such attacks in such a way as to start blocking them. But, someone must do the work of updating the attack data. And this “someone” must be competent in this.
Blockchain elements are often outside the list of bug bounty programs
Bug bounty programs have already become a part of the life of large companies. And, this is a really good way to increase the security of a company through independent researchers. The problem is that often elements of the blockchain are not included in the list of bug bounty programs. That is, a researcher who has found an opportunity to stop a business process has no economic incentive to report this problem to the manufacturer.
The problem with security specialists
This includes a “staff shortage” combined with low demand for specialists (a kind of oxymoron), incorrect expectations from the candidate and a small number of platforms for exchanging experiences of such specialists. Universities in the country are already teaching blockchain as a field. It is difficult to fully evaluate all the programs at all universities. But the most I have seen in programs in terms of security is cryptography (+ an introductory part, that they have already thought about security in the blockchain architecture). If you look for courses on blockchain security, you will mostly find courses on smart contract security. Conferences that talk about blockchain security are hard to find. In 2023, I was organizing a section on blockchain security at the PHDays conference. There were few people who applied for a report on their own. It took me a lot of effort to scrape together reports. It got to the point that I even suggested report topics to potential speakers. There were also opposite situations: when my report was not accepted to a specialized conference on security because “the topic was too narrow.”
At an interview, I was once asked questions as if I was interviewing not for a “security specialist”, but for a network administrator (“how many transactions are in a block by default, where is this configured”, etc.). At the same time, I did not receive an answer as to what relation such questions have to security. But I realized that the interviewer believes that a “security specialist” is someone who knows more about blockchain than he does. That's why he asks what he knows. Such an approach, when choosing from several candidates, can lead to priority for a former developer/administrator without practical security experience. In my experience, good “security specialists” are an exception to the rule in such cases. It's like a writer and a literary critic: theoretically, they can replace each other. But it is unlikely that you will be able to do both jobs equally well. At one of my previous jobs, I just had a team lead without practical experience in security in any area (before being hired for this position). He ignored a potential problem I found. As a result, I brought it to CVE assignments (no longer working there). Finding a specialist who has practical experience in finding vulnerabilities in parts of the blockchain other than smart contracts is quite difficult. To illustrate, I conducted a survey in a closed group Stronghold (to participate you must complete the smart contract security course – MixBytes Farm), which I am a member of. A total of 33 people voted. The results of the poll are below.
Yes, this survey is not very large in terms of the number of people. But the group is small. And companies interested in the comprehensive security of blockchain networks (and not just at the smart contract level) have something to think about. Of those who voted, 1 person (that's me) found a vulnerability in the blockchain that was assigned a CVE number. Almost a third do not know what CVE is.
Even if we focus only on specialists in the study of smart contracts of corporate blockchains, there are quite a few such specialists. Moreover: there is little demand for them on the labor market in the Russian Federation. There are attempts to replace such a specialist with a specialist in the code security of the required smart contract language. For example, if a smart contract is written in Golang, find a specialist in code analysis in Golang. But this leads to the fact that security issues specific to a particular blockchain solution will not be identified by such a specialist. Moreover, I have had experience in analyzing smart contracts for different blockchains. And I can say that even different blockchains have their own characteristics. Therefore, taking a specialist in the analysis of a smart contract of one blockchain and letting him study a smart contract of another blockchain (while not giving him the opportunity to study the features of a new blockchain) is not the best idea.
The influence of geopolitics
My experience shows that this question is the most difficult for integrators of blockchain solutions. There may be situations when, for a cross-border payment, traffic must be transmitted from a blockchain node in one country to a node in another. And here it is worth considering the influence of geopolitics: technically, such traffic can be singled out (against the background of other traffic) and blocked. Mostly, misconceptions are related to:
lack of understanding: how to select a part of the traffic and block only it;
the belief that if one path is blocked, another will work;
endless hope for VPN, which should solve all the problems.
Blocking only part of the traffic is a great real-life example from YouTube in the Russian Federation: almost all subscribers of wired providers have problems with it. And everything else works. Finding what exactly to block is also easy: I find blockchain elements on the Internet using specialized search engines like Shodan.
In terms of workarounds, everything is true, but there is a nuance: is there a traffic route from the Russian Federation to, say, Cuba bypassing unfriendly countries? There is none, unless we are talking about satellites (and here the issues of connection speed/availability arise). And this is if we assume that no one will jam the satellite signal (in this case, near Cuba). About VPN. The main problem here is that corporate blockchains do not support it “out of the box” (I have not encountered the opposite). That is, there are no guarantees that the implemented (another question: by whom?) VPN will not affect the performance and preservation of the initially declared technical characteristics of the blockchain.
Interaction with countries with a common border seems safer. But, even here, some risks must be taken into account, such as damage to underwater infrastructure. In some countries already thinking about it on the continuity of financial transactions in cases of cable damage.
Conclusion
I'll be brief. In my opinion, the security situation in corporate blockchains is in many ways similar to the security situation in industrial devices: at first there was no interest, and then it hit Stuxnet – and “security guards” were suddenly needed.
