Account Abstraction Schnorr Signatures SDK - InFlux Technologies

1. Introduction

InFlux Technologies engaged Halborn to conduct a security assessment on their web application beginning on 01/02/2025 and ending on 01/15/2025. The security assessment was scoped to the source code files provided to the Halborn team.

2. Assessment Summary

The team at Halborn was provided one week and a half for the engagement and assigned a full-time security engineer to verify the security of the scoped source code application files. The security engineer is a blockchain and smart contract security expert with advanced penetration testing, smart contract hacking, and deep knowledge of multiple blockchain protocols.

The security assessment identified multiple critical areas requiring attention in the analyzed codebase, involving several issues and misconfigurations that the InFlux Technologies should address to enhance the application's security.

The lack of proper validation for external calls raised concerns about unchecked interactions with third-party contracts, potentially leading to unintended execution of malicious code.

Several medium-severity issues were also observed. The use of predictable salts during contract deployments could expose the system to collision attacks, jeopardizing address uniqueness. Additionally, the default hash function was not clearly specified, which could create inconsistencies or weaken the cryptographic integrity of the system. Sensitive information, including private keys, was potentially being stored within environment variables without sufficient protection, amplifying the risk of unauthorized access. The codebase also relied on third-party dependencies with known vulnerabilities, potentially exposing the entire project to inherited security flaws. Moreover, hardcoded transaction cost parameters may limit flexibility and could be exploited if not carefully controlled.

Furthermore, the absence of public key validation could allow unauthorized entities to submit invalid keys, increasing the likelihood of malicious transactions being accepted.

Lower-risk findings included the presence of insecure methods, which, although not actively used, could become a risk if reintroduced or overlooked in future development cycles.

Some other low severity issues involved cryptographic key handling and transaction integrity. Specifically, the potential reuse of nonces in the Schnorr signature scheme presented a substantial risk of private key leakage, compromising the overall integrity of the signing process.

Finally, an informational observation was also noted regarding the library usage, emphasizing the importance of clearly documenting and maintaining external code integrations.

Overall, while the project demonstrates solid foundations in many areas, these identified issues highlight the need for a more comprehensive approach to input validation, cryptographic hygiene, and dependency management to ensure long-term security and resilience.

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. Test Approach and Methodology

Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the penetration test... While manual testing is recommended to uncover flaws in logic, process and implementation; automated testing techniques assist enhance coverage of the solution and can quickly identify flaws in it.

The following phases and associated tools were used throughout the term of the assessment:

• Research about the scoped source code

• Technology stack-specific vulnerabilities and public source code assessment

• Vulnerable or outdated software

• Exposure of any critical information

• Application logic flaws

• Access Handling

• Authentication / Authorization flaws

• Lack of validation on inputs and input handling

• Brute force protections

• Sensitive information disclosure

• Source code review