← Back to Audits

HTLC Peer to Peer Swap - Between Bitcoin & Core - CoreDAO

Prepared by:

Halborn Logo

HALBORN

Last Updated 08/21/2024

Date of Engagement by: April 24th, 2024 - May 1st, 2024

Summary

100% of all REPORTED Findings have been addressed

All findings

2

Critical

0

High

0

Medium

1

Low

1

Informational

0

Table of Contents

1. Introduction

CoreDAO engaged Halborn to conduct a security assessment on their HTLC implementation, beginning on 2024-04-24 and ending on 2024-05-01. The security assessment was scoped to the assets provided to the Halborn team.

2. Assessment Summary

The team at Halborn was provided one week for the engagement and assigned a full-time security engineer to verify the security of all the applications. The security engineer is a penetration testing expert with advanced knowledge in web, recon, discovery & infrastructure penetration testing and blockchain protocols.

- Improve the security of the implementation

- Identify potential security issues that could be affecting the implementation

In summary, Halborn identified one medium and one low security issues that were accepted by the CoreDAO team.

The CoreDao HTLC source code contained a medium security issue that could allow an attacker to retrieve the private key of the victim, due to certain scripts need the private key of the user on the parameter. Additionally, a lack of verification was reported on the chainID parameter of multiple scripts.

It is recommended to resolve all the security issues listed in the document to improve the security health of the application and its underlying infrastructure.


3. RISK METHODOLOGY

Vulnerabilities or issues observed by Halborn are ranked based on the risk assessment methodology by measuring the LIKELIHOOD of a security incident and the IMPACT should an incident occur. This framework works for communicating the characteristics and impacts of technology vulnerabilities. The quantitative model ensures repeatable and accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the Risk scores. For every vulnerability, a risk level will be calculated on a scale of 5 to 1 with 5 being the highest likelihood or impact.
RISK SCALE - LIKELIHOOD
  • 5 - Almost certain an incident will occur.
  • 4 - High probability of an incident occurring.
  • 3 - Potential of a security incident in the long term.
  • 2 - Low probability of an incident occurring.
  • 1 - Very unlikely issue will cause an incident.
RISK SCALE - IMPACT
  • 5 - May cause devastating and unrecoverable impact or loss.
  • 4 - May cause a significant level of impact or loss.
  • 3 - May cause a partial impact or loss to many.
  • 2 - May cause temporary impact or loss.
  • 1 - May cause minimal or un-noticeable impact.
The risk level is then calculated using a sum of these two values, creating a value of 10 to 1 with 10 being the highest level of security risk.
Critical
High
Medium
Low
Informational
  • 10 - CRITICAL
  • 9 - 8 - HIGH
  • 7 - 6 - MEDIUM
  • 5 - 4 - LOW
  • 3 - 1 - VERY LOW AND INFORMATIONAL

4. SCOPE

Files and Repository
(a) Repository: btc-htlc-scripting
(b) Assessed Commit ID: 264c003
(c) Items in scope:
  • /README.md
  • /bash
  • /bash/clear_bitcoin_data.sh
↓ Expand ↓
Out-of-Scope:
Out-of-Scope: New features/implementations after the remediation commit IDs.

5. Assessment Summary & Findings Overview

Critical

0

High

0

Medium

1

Low

1

Informational

0

Impact x Likelihood

HAL-01

HAL-02

Security analysisRisk levelRemediation Date
PRIVATE KEY LOGGED ON BASH HISTORYMediumRisk Accepted
CHAIN ID NOT VERIFIEDLowRisk Accepted

6. Findings & Tech Details

6.1 PRIVATE KEY LOGGED ON BASH HISTORY

// Medium

Description

Multiple scripts contain sensitive information on their calling parameters. Bash automatically records most commands executed in the terminal to a history file (typically .bash_history), intended for user convenience in recalling past commands. However, this data could be exposed to anyone who can access this history file. Such exposure significantly increases the risk of security breaches, as private keys are crucial for authentication and encryption processes. The logging of private keys in this manner can lead to unauthorized access and potential misuse of the associated accounts or services.

Proof of Concept
if __name__ == "__main__":
    parser = argparse.ArgumentParser(description='Refund a HTLC.')
    parser.add_argument('--txid', help='Transaction ID of the HTLC UTXO', required=True)
    parser.add_argument('--vout', type=int, help='VOUT index of the HTLC UTXO', required=True)
    parser.add_argument('--amount', type=float, help='Amount in BTC to refund from the HTLC', required=True)
    parser.add_argument('--fee', type=float, help='Transaction fee in BTC', required=True)
    parser.add_argument('--destination', help='Destination address for the refund', required=True)
### Private key taken as an argument
    parser.add_argument('--private_key_sender', help='Private key of the sender', required=True)
    parser.add_argument('--witness_script_hex', help='Hex-encoded witness script of the HTLC', required=True)
    parser.add_argument('--redeem_blocknum', type=int, help='Block number after which the HTLC can be refunded', required=True)
    parser.add_argument('--chain', help='Blockchain network to use (e.g., regtest, testnet)', required=True)
Score
Impact: 3
Likelihood: 3
Recommendation

To remediate the issue of private keys being logged in Bash history, consider implementing the following measures:

  1. Disable Bash History for Sensitive Sessions: Temporarily turn off Bash history logging when working with sensitive information. You can do this by setting the HISTSIZE environment variable to zero with the command HISTSIZE=0 at the beginning of your session. Alternatively, use set +o history to disable history logging for the current session.

  2. Clear Bash History: After working with private keys, ensure that the Bash history is cleared to remove any accidentally logged sensitive information. You can clear the entire history by using history -c and then history -w to write the changes.

  3. Secure Bash History File: Restrict access to the .bash_history file by setting strict file permissions. Use chmod 600 ~/.bash_history to make the file readable and writable only by the owner.

  4. Use Secure Input Methods: Employ tools designed for secure input, such as password prompts or configuration files with restricted permissions, to handle private keys and other sensitive data.


Remediation Plan

RISK ACCEPTED: The CoreDAO team accepted the risk of this finding.

6.2 CHAIN ID NOT VERIFIED

// Low

Description

Verifying the chain ID is crucial in ensuring that operations are conducted on the correct network, especially in environments where multiple blockchains are accessible and operational errors can have significant repercussions.

This can lead to several risks, such as executing transactions on an unintended blockchain, which might result in loss of funds, incorrect data processing, or interactions with malicious entities.

Proof of Concept
#!/bin/bash

# Check if the correct number of arguments was provided
if [ "$#" -ne 2 ]; then
    echo "Usage: $0 <wallet_name> <chain>"
    exit 1
fi

# Wallet name to check the balance of
WALLET_NAME=$1
# Chain argument (regtest or testnet)
CHAIN=$2
Score
Impact: 2
Likelihood: 2
Recommendation

Implement validation to prevent potential errors when specifying the correct chainID.


Remediation Plan

RISK ACCEPTED: The CoreDAO team accepted the risk of this finding.

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.

// Download the full report

* Use Google Chrome for best results

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

© Halborn 2024. All rights reserved.