Prepared by:
HALBORN
Last Updated 08/21/2024
Date of Engagement by: April 24th, 2024 - May 1st, 2024
100% of all REPORTED Findings have been addressed
All findings
2
Critical
0
High
0
Medium
1
Low
1
Informational
0
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.
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.
Critical
0
High
0
Medium
1
Low
1
Informational
0
Impact x Likelihood
HAL-01
HAL-02
Security analysis | Risk level | Remediation Date |
---|---|---|
PRIVATE KEY LOGGED ON BASH HISTORY | Medium | Risk Accepted |
CHAIN ID NOT VERIFIED | Low | Risk Accepted |
// Medium
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.
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)
To remediate the issue of private keys being logged in Bash history, consider implementing the following measures:
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.
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.
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.
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.
RISK ACCEPTED: The CoreDAO team accepted the risk of this finding.
// Low
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.
bash/get_balance.sh
#!/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
Implement validation to prevent potential errors when specifying the correct chainID.
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