Blockchain software security report by China CERT, Ripple the worst
In December 2016, China CERT released a 17-page security audit report of blockchain software. As per the report, the audit was conducted in October 2016 and released later as “open” document. The report examined 25 open-source blockchain projects, categorizing the vulnerabilities found into 9 classes. A total of 746 high-level attack vectors are detected. Ripple is rated the most insecure one with over 223 highly risky bugs.
China CERT, the National Computer Network Emergency Response Technical Team/Coordination Center of China (known as CNCERT or CNCERT/CC) , was founded in September 2002. It is a non-governmental non-profit cybersecurity technical center and the key coordination team for China’s cybersecurity emergency response community. The CERT lab speaks highly of the global development around blockchain technology but also reiterates the importance of blockchain software security.
“Any vulnerability may result in huge property loss”.
The statistics in the report comes from scanner tools and manual review. The report only analyzes vulnerabilities from a coding perspective. Due to the restriction of the deployment environment and security equipment, some of the vulnerabilities may not be verified via penetration test.
Overview of 25 projects being audited
Based on the number of user group, followers and commit frequency, the CERT lab selected 25 blockchain with well-known reputation and extensive community both at home and abroad. These software were written with C, C + +, Java, Python, PHP and other programming languages.
Below is the overview of projects being reviewed:
Table 1: Overview of 25 blockchain projects
9 vulnerability categories
This test covers a variety of commonly seen security vulnerabilities, which are divided into 9 categories by the following criteria: formation cause of security vulnerabilities, the possibility of being exploited, the degree of harm and the difficulty to solve.
1. Input Validation and Representation
Input validation and representation problems are usually caused by special characters, encodings, and numerical representations. Such problems occur as a result of input trust. These problems include: buffer overflow, cross-site scripting, SQL injection, command injection and so on.
2. API Abuse
The API is a convention between the caller and the callee, and most API abuses are caused by the caller not understanding the purpose of the convention. Security problems can also arise when the API is not used properly.
3. Security Features
This category contains vulnerabilities in authentication, access control, confidentiality, password usage, and privilege management.
4. Memory Management
Memory management is a common type of vulnerability associated with memory operations, including memory leaks, post-release use, double-release and so on. This type of vulnerability usually leads to system performance degradation, program crashes and a common type of flaws in C / C + + language.
5. Time and State
Distributed computing is time and state dependent. The interaction between threads and processes and the order in which tasks are executed are often determined by shared state, such as semaphores, variables, file systems and so on. The vulnerabilities associated with distributed computing include race conditions, blocking misuse and so on.
6. Error and Exception Handling Errors
This type of vulnerability is related to error and exception handling, and the most common type of vulnerability is that there is no proper processing mechanism (or errors are not processed), resulting in unexpected termination of program. Another vulnerability is that the error generated provides potential attacker with too much information.
7. Code Quality
Poor code quality can lead to unpredictable behavior. For the attacker, the poor code enables them to threaten the system in unexpected ways. Common types of vulnerabilities include dead code, null pointer dereferences and resource leak.
8. Encapsulation and hidden defects
Reasonable encapsulation means that the distinction between verified and unverified data, distinction between data of different users, or distinguish data that is visible or invisible to users. Common vulnerabilities include hidden fields, information leakage, cross-site request forgery and so on.
9. Flaws in Code Runtime Environment
These types of vulnerability is external to the source code, such as runtime configuration issues, sensitive information management issues and so on, which are critical to the product security.
The first eight types of vulnerabilities are related to security flaws in the source code. They can be the target of malicious attacks. Once exploited, they can cause serious consequences such as information leak, authorization lift and command execution. The last type of vulnerability describes security concerns that are external to the actual code. They are likely to cause abnormal operation of the software, data loss and other serious problems.
Rating of vulnerability
The lab classified the source code security issues into three levels: High, Medium, and Low. Criteria for measuring the level include two dimensions, confidence and severity. Confidence refers to the probability if the problem is found to be accurate. For example, strcpy () call flagged as a buffer overflow vulnerability has low confidence. Severity refers to the seriousness of a problem if the test technique is authentic. For example a buffer overflow, which is often a more serious security issue than a null pointer dereference. The combination of these two factors can be accurately classified for security issues, as shown in Figure 1.
Ripple the most insecure project
746 high-level and 3,497 medium-level bugs were detected among the 25 projects with Ripple taking the lead by 223 highly risky loopholes. Figure 2 shows the statistics of high and medium level security vulnerabilities detected in the 25 projects. The red line indicates the number of vulnerabilities per thousand lines of code (total number of bugs / code lines * 1000)
Figure 2 Statistics of vulnerabilities detected in 25 projects
“It is noteworthy that among all the projected being audited this time, Ripple is likely to be the most widely used one with the most users. At the time of writing, the software company has received 100 million USD investments from Google and Accenture. Some large financial institutions have announced their joining the payment network, including Standard Chartered, Westpac, Shanghai Huarui Bank and so on. Given the fact that Ripple is directly dealing with financial assets, should these loopholes be exploited by hackers, the institutions may suffer unimaginable losses.”
Ethereumj comes as the second most risky project with 110 high-level vulnerabilities. Bitshares contains 4 high-risk bugs and 665 medium ones, the highest number among all projects.
Ethereum Wallet, Hlp-candidate and OmniJ are found bearing zero or only one high-level bugs and therefore considered the most secure projects among all units being audited.
High-level vulnerability Analysis
Most of the vulnerabilities fall into the category of “input validation and presentation”, which mainly results from the incomplete verification of user inputs. Malicious input may trigger arbitrary command execution, full access to files and other serious security issues.
“For example, some Java blockchain software, like Ripple, with the JNI framework use other language such C, C++ to manipulate memory and other operating system resources, bypassing the Java memory protection mechanism, making the program vulnerable to buffer overflow attacks.”
Another category with high frequency is “Code quality issue”, which results from the “the lack of security awareness of developers” and “unstandardized coding”. Such vulnerabilities may lead to memory overflow, resource depletion and other security concerns. Worst scenario may include abnormal operation of the system or even system crash. As the blockchain software is often integrated into the operating system of financial institutions, system crash will bring intolerable losses.
“Security features” also accounts for a certain percentage of vulnerabilities, such vulnerabilities mainly cover identity authentication, authorization management, password management and other issues. Attacker can exploit the loopholes to gain unauthorized access, steal private infos. Encryption function is the core of blockchain software in maintaining the integrity of the entire whole ledger. However, according to the test results, there are a number of “unsafe random numbers” issues, which will compromise the software’s defense against encryption attacks.
JNI and random number generator vulnerabilities
Of the 25 projects tested, the two most common types of vulnerabilities are insecure JNI (16.22%, 121) and insecure random numbers (21.72%, 162).
Figure 4 Allocation of Medium and High Vulnerabilities (by specific categories)
1.Insecure JNI ( under the category of “input validation and representation”)
When a Java application uses JNI to call code written in another programming language, improper calling can make Java applications vulnerable to security breaches in other languages. Although there is a Java-provided memory protection mechanism, this protection mechanism does not apply to source code written in other languages and accessed through the Java Native Interface (JNI). Precautionary measure proposed is to carefully check the operation of the native language contained in the Java code and implement a rigorous input validation.
2. Insecure random number (the security feature)
In a security demanding environment, the use of a predictable value of the function as a random data source will reduce the ability of the system against encryption attacks, resulting in serious vulnerabilities like easy-to-guess password, predictable encryption keys, session hijacking attacks and DNS spoofing.
Precautions: The cryptographic pseudo random number generator should be used and the information with the largest information entropy should be used as the seed. If information entropy is not available, the threat can be reduced by changing its seed when using a cryptographic pseudo random number generator.
Medium-level Vulnerability Analysis
The medium and low risk vulnerabilities may present less risks in the real operating environment. However, these bugs can reflect the code quality, the developer’s awareness of security to some extent. Figure 5 shows the distribution of security vulnerabilities. Although the medium-level problems will not lead to serious security vulnerabilities, there are still pose significant threat to the system. If exploited, they may lead to serious risks like system crash. A possible cause is that some of the tests are intermediate versions that have not yet been officially released, resulting in some residue of “process code”.
Figure 6 further demonstrates the allocation of various security vulnerabilities. It is noteworthy that 87 vulnerabilities with less than 10 occurrence, such as “inappropriate type conversion”, “residual debugging information” and other code quality, API-related vulnerabilities are classified as “Others” to facilitate the data presentation. The two most common vulnerabilities are unused local variables (13.94%, 1,181) and insecure string functions (13.20%, 1,118). At the end of the report, counter measures are also proposed for these two bugs.
The report is the first security audit conducted by Chinese national cybersecurity institutions. The sheer number of bugs may present a setback to potential adopters.
“The 746 high-level vulnerabilities reveal that there are serious safety risks that must not be ignored.
Feedback from developers are expected to clarify the situation.
Update: Ripple released an official response to the CERT report.