HUB v1 - Blueprint Finance

Prepared by:

HALBORN

Last Updated Unknown date

Date of Engagement: September 2nd, 2024 - September 20th, 2024

Summary

100% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Incorrect balance updates in erc721logic and internals
7.2 Lack of access control in pong handlers
7.3 Missing access control in policy termination blueprint
7.4 Incorrect namespace used on boolean commit
7.5 Missing validation for loan owner
7.6 Lack of validation for accesscontrolmanager contract in concretestorage
7.7 Missing check for response handler address
7.8 Missing handling of delete and increment
7.9 Missing operations in config and registry pong handlers.
7.10 Missing name initialization in erc721logic constructor
7.11 Non-atomic packet id may result in collisions
7.12 Missing underflow handling
7.13 Single step ownership transfer process
7.14 Missing validation for consistent chainid and eid
7.15 Lack of configurability in multisigwallet
7.16 Missing use of internal erc721 functions
7.17 Unused config pong handler
7.18 Use of hardcoded values instead of enums
7.19 Inefficient role checking
7.20 Unnecessary immutable namespace variable
7.21 Hardcoded value instead of enum
7.22 Lack of distinction between delete and setting value to 0
7.23 Entropy reduction may lead to collisions
7.24 Potential hash collisions in namespace constants due to 4-byte limitation
7.25 Unused function in configmanager
7.26 Unused functions in registrymanager
7.27 Empty packet gap
7.28 Redundant onlyrole modifier
7.29 Inefficient placement of amountsupply check
7.30 Lack of events for state changes
7.31 Ownership assumptions

1. Introduction

Concrete engaged our security analysis team to conduct a comprehensive security audit of their smart contract ecosystem. The primary aim was to meticulously assess the security architecture of the smart contracts to pinpoint vulnerabilities, evaluate existing security protocols, and offer actionable insights to bolster security and operational efficacy of their smart contract framework. Our assessment was strictly confined to the smart contracts provided, ensuring a focused and exhaustive analysis of their security features.

2. Assessment Summary

Our engagement with Blueprint spanned a 3-week period, during which we dedicated one full-time security engineer equipped with extensive experience in blockchain security, advanced penetration testing capabilities, and profound knowledge of various blockchain protocols. The objectives of this assessment were to:

- Verify the correct functionality of smart contract operations.

- Identify potential security vulnerabilities within the smart contracts.

- Provide recommendations to enhance the security and efficiency of the smart contracts.

In summary, Halborn identified several security concerns that were mostly addressed by the Concrete team.

3. Test Approach and Methodology

Our testing strategy employed a blend of manual and automated techniques to ensure a thorough evaluation. While manual testing was pivotal for uncovering logical and implementation flaws, automated testing offered broad code coverage and rapid identification of common vulnerabilities. The testing process included:

- A detailed examination of the smart contracts' architecture and intended functionality.

- Comprehensive manual code reviews and walkthroughs.

- Functional and connectivity analysis utilizing tools like Solgraph.

- Customized script-based manual testing and testnet deployment using Foundry.

This executive summary encapsulates the pivotal findings and recommendations from our security assessment of Blueprint smart contract ecosystem. By addressing the identified issues and implementing the recommended fixes, Blueprint can significantly boost the security, reliability, and trustworthiness of its smart contract platform.

4. RISK METHODOLOGY

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

4.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	METRIC VALUE	NUMERICAL VALUE
Attack Origin (AO)	Arbitrary (AO:A) Specific (AO:S)	1 0.2
Attack Cost (AC)	Low (AC:L) Medium (AC:M) High (AC:H)	1 0.67 0.33
Attack Complexity (AX)	Low (AX:L) Medium (AX:M) High (AX:H)	1 0.67 0.33

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

4.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	METRIC VALUE	NUMERICAL VALUE
Confidentiality (C)	None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C)	0 0.25 0.5 0.75 1
Integrity (I)	None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C)	0 0.25 0.5 0.75 1
Availability (A)	None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C)	0 0.25 0.5 0.75 1
Deposit (D)	None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C)	0 0.25 0.5 0.75 1
Yield (Y)	None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C)	0 0.25 0.5 0.75 1

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N) Partial (R:P) Full (R:F)	1 0.5 0.25
Scope ( $s$ )	Changed (S:C) Unchanged (S:U)	1.25 1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Severity	Score Value Range
Critical	9 - 10
High	7 - 8.9
Medium	4.5 - 6.9
Low	2 - 4.4
Informational	0 - 1.9

5. SCOPE

REPOSITORY

(a) Repository: sc_hub-v1

(b) Assessed Commit ID: 5ff8b67

src/registry/RegistryManager.sol
src/blueprints/implementations/LenderBlueprint.sol
src/libraries/StorageHandlerLib.sol
src/blueprints/implementations/ProtectionBlueprint.sol
src/token/ERC721LogicContract.sol
src/storage/ConcreteStorage.sol
src/primitives/BasePongHandler.sol
src/blueprints/implementations/PolicyTerminationBlueprint.sol
src/primitives/ERC721_Internals.sol
src/multiSigWallet/MultiSigWallet.sol
src/blueprints/BaseBlueprint.sol
src/config/ConfigManager.sol
src/errors/Errors.sol
src/primitives/CreateUserBlueprint.sol
src/protocol/Protocol.sol
src/primitives/EnableConcreteLite.sol
src/constants/Tables.sol
src/primitives/PacketIdHandler.sol
src/storage/interfaces/IStorageOperations.sol
src/primitives/EVMAddressValidation.sol
src/primitives/GetConcreteLiteEncoding.sol
src/accessControl/AccessControlManager.sol
src/primitives/ValidateProtection.sol
src/registry/RegistryManagerEvents.sol
src/types/Enums.sol
src/primitives/RemoteChainHandler.sol
src/blueprints/BlueprintResolver.sol
src/storage/ConcreteStorageConnector.sol
src/blueprints/implementations/ProtectionBlueprintEvents.sol
src/protocol/PauseStatus.sol
src/registry/interfaces/IRegistryManager.sol
src/primitives/LoanToken_OwnerOf.sol
src/primitives/GetChainEndpoint.sol
src/pongHandler/PongHandlerImplementation.sol
src/constants/Namespaces.sol
src/primitives/GetLoanTokens.sol
src/primitives/GetEndpoint.sol
src/primitives/SetBorrowToken.sol
src/accessControl/OnlyRole.sol
src/constants/ProtocolConstants.sol
src/blueprints/implementations/PolicyTerminationBlueprintEvents.sol
src/primitives/ERC721_Constructor.sol
src/types/Structs.sol
src/multiSigWallet/MultiSigWalletEvents.sol
src/blueprints/implementations/LenderBlueprintEvents.sol
src/blueprints/interfaces/IRegistry.sol
src/storage/interfaces/IConcreteStorage.sol
src/config/ConfigManagerEvents.sol
src/storage/ConcreteStorageEvents.sol
src/protocol/interfaces/IProtocol.sol
src/blueprints/interfaces/IPongHandler.sol
src/primitives/ERC721_Events.sol
src/constants/Roles.sol
src/accessControl/AccessControlManagerEvents.sol
src/primitives/BasePongHandlerEvents.sol
src/config/interfaces/IConfigManager.sol

src/registry/RegistryManager.sol
src/blueprints/implementations/LenderBlueprint.sol
src/libraries/StorageHandlerLib.sol

↓ Expand ↓

Out-of-Scope: New features/implementations after the remediation commit IDs.

6. Assessment Summary & Findings Overview

Critical

High

Medium

Low

Informational

Security analysis	Risk level	Remediation Date
Incorrect Balance Updates in ERC721Logic and Internals	Critical	Solved - 09/26/2024
Lack of Access Control in Pong handlers	Critical	Solved - 09/19/2024
Missing Access Control in Policy termination blueprint	Critical	Solved - 09/19/2024
Incorrect Namespace Used On Boolean Commit	High	Solved - 09/19/2024
Missing Validation for Loan Owner	Medium	Risk Accepted
Lack of Validation for AccessControlManager Contract in ConcreteStorage	Medium	Solved - 09/19/2024
Missing Check for Response Handler Address	Medium	Solved - 09/19/2024
Missing Handling of DELETE and INCREMENT	Medium	Risk Accepted
Missing operations in config and registry pong handlers.	Medium	Solved - 09/19/2024
Missing Name Initialization in ERC721Logic Constructor	Low	Solved - 09/19/2024
Non-Atomic packet ID May Result in Collisions	Low	Not Applicable
Missing Underflow Handling	Low	Risk Accepted
Single step ownership transfer process	Low	Risk Accepted
Missing Validation for Consistent chainId and eid	Low	Risk Accepted
Lack of Configurability in MultiSigWallet	Informational	Acknowledged
Missing Use of Internal ERC721 Functions	Informational	Solved - 09/19/2024
Unused Config Pong Handler	Informational	Solved - 09/19/2024
Use of Hardcoded Values Instead of Enums	Informational	Solved - 09/26/2024
Inefficient Role Checking	Informational	Solved - 09/19/2024
Unnecessary immutable namespace variable	Informational	Solved - 09/26/2024
Hardcoded Value Instead of Enum	Informational	Solved - 09/19/2024
Lack of Distinction Between DELETE and Setting Value to 0	Informational	Acknowledged
Entropy Reduction May Lead to Collisions	Informational	Acknowledged
Potential Hash Collisions in Namespace Constants Due to 4-Byte Limitation	Informational	Acknowledged
Unused Function in ConfigManager	Informational	Solved - 09/19/2024
Unused Functions in RegistryManager	Informational	Solved - 09/19/2024
Empty Packet Gap	Informational	Not Applicable
Redundant onlyRole Modifier	Informational	Solved - 09/19/2024
Inefficient Placement of amountSupply check	Informational	Solved - 09/19/2024
Lack of Events for State Changes	Informational	Acknowledged
Ownership Assumptions	Informational	Acknowledged

7. Findings & Tech Details

7.1 Incorrect Balance Updates in ERC721Logic and Internals

Critical

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/C:N/I:C/A:M/D:C/Y:C/R:N/S:C (10.0)

Recommendation

Remediation Comment

7.2 Lack of Access Control in Pong handlers

Critical

Description

Low

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Incorrect balance updates in erc721logic and internals
7.2 Lack of access control in pong handlers
7.3 Missing access control in policy termination blueprint
7.4 Incorrect namespace used on boolean commit
7.5 Missing validation for loan owner
7.6 Lack of validation for accesscontrolmanager contract in concretestorage
7.7 Missing check for response handler address
7.8 Missing handling of delete and increment
7.9 Missing operations in config and registry pong handlers.
7.10 Missing name initialization in erc721logic constructor
7.11 Non-atomic packet id may result in collisions
7.12 Missing underflow handling
7.13 Single step ownership transfer process
7.14 Missing validation for consistent chainid and eid
7.15 Lack of configurability in multisigwallet
7.16 Missing use of internal erc721 functions
7.17 Unused config pong handler
7.18 Use of hardcoded values instead of enums
7.19 Inefficient role checking
7.20 Unnecessary immutable namespace variable
7.21 Hardcoded value instead of enum
7.22 Lack of distinction between delete and setting value to 0
7.23 Entropy reduction may lead to collisions
7.24 Potential hash collisions in namespace constants due to 4-byte limitation
7.25 Unused function in configmanager
7.26 Unused functions in registrymanager
7.27 Empty packet gap
7.28 Redundant onlyrole modifier
7.29 Inefficient placement of amountsupply check
7.30 Lack of events for state changes
7.31 Ownership assumptions

// Download the full report

HUB v1

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed

HUB v1

Blueprint Finance

Table of Contents

1. Introduction

2. Assessment Summary

3. Test Approach and Methodology

4. RISK METHODOLOGY

4.1 EXPLOITABILITY

Attack Origin (AO):

Attack Cost (AC):

Attack Complexity (AX):

Metrics:

4.2 IMPACT

Confidentiality (C):

Integrity (I):

Availability (A):

Deposit (D):

Yield (Y):

Metrics:

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Scope (S):

Metrics:

5. SCOPE

6. Assessment Summary & Findings Overview

7. Findings & Tech Details

7.1 Incorrect Balance Updates in ERC721Logic and Internals

Description

Proof of Concept

BVSS

Recommendation

Remediation Comment

7.2 Lack of Access Control in Pong handlers

Description

Proof of Concept

BVSS

Recommendation

Remediation Comment

7.3 Missing Access Control in Policy termination blueprint

Description

BVSS

Recommendation

Remediation Comment

7.4 Incorrect Namespace Used On Boolean Commit

Description

BVSS

Recommendation

Remediation Comment

7.5 Missing Validation for Loan Owner

Description

BVSS

Recommendation

Remediation Comment

7.6 Lack of Validation for AccessControlManager Contract in ConcreteStorage

Description

BVSS

Recommendation

Remediation Comment

7.7 Missing Check for Response Handler Address

Description

BVSS

Recommendation

Remediation Comment

7.8 Missing Handling of DELETE and INCREMENT

Description

BVSS

Recommendation

Remediation Comment

7.9 Missing operations in config and registry pong handlers.

Description

BVSS

Recommendation

Remediation Comment

References

7.10 Missing Name Initialization in ERC721Logic Constructor

Description

Proof of Concept

BVSS

Recommendation

Remediation Comment