Introduction & Background to the Security Audit (March 2024)
This report is part of a comprehensive documentation on the responsible disclosure of security findings on the Inleo platform. The vulnerabilities described here were identified around March 2024 and immediately reported to the development team.
Purpose of the Documentation
The goal of this audit is to provide transparency regarding past risks and to ensure the continuous improvement of the platform’s integrity. In the world of Web3 technologies, a proactive culture of accountability is essential to securing the community’s trust in the long term.
Risk Assessment and All-Clear
Although the identified vulnerabilities theoretically posed a risk to sensitive user data and cryptographic keys, an objective assessment of the situation is crucial:
- No Evidence of Exploitation: Based on current information and thorough investigation, there is no indication that these or other vulnerabilities reported during this period were actively exploited by third parties.
- Data security: There is no evidence that user information, private keys, or other sensitive data has been leaked to unauthorized third parties.
- Preventive measures: The prompt reporting and subsequent rapid implementation of security fixes by the Inleo team effectively closed the window of opportunity for potential attacks before any damage could occur.
Conclusion
These reports serve to document and provide evidence of a successful collaboration between independent security researchers and platform operators. They underscore the shared goal of making Inleo one of the most secure gateways in the Hive ecosystem.
Report Date: March 19, 2024
Status: Resolved
Vulnerability Type: Stored HTML Injection / Open Redirect via Meta Tag
Summary
A critical security vulnerability was identified within the InLeo platform's content rendering engine. The application failed to properly sanitize or filter specific HTML tags in user-generated content (blog posts and threads). This allowed an attacker to inject malicious tags that triggered an immediate, automated redirection of any user viewing the content to an external, potentially harmful website.
Technical Details
Vulnerability Mechanism
The flaw existed due to the rendering engine’s acceptance of the HTML tag within the Markdown/HTML editor. Because these tags were stored directly in the database and rendered in the victim's browser, they were executed with the authority of the platform.
Proof of Concept (PoC)
An attacker could exploit this by embedding the following payload into a post or thread:
<meta http-equiv="refresh" content="0; URL=https://malicious-site.com">
Execution Flow:
- Injection: The attacker publishes a thread or post containing the payload.
- Storage: The platform saves the raw HTML/Markdown to the blockchain/database as a post.
- Execution: When a legitimate user navigates to the post, their browser parses the injected tag.
- Redirection: The
http-equiv="refresh"attribute instructs the browser to immediately redirect the user to the specified URL after 0 seconds, without any user interaction or consent.
Proof
Screenshot shows potential malicious blog-post posted from Ecency to store the payload on the Blockchain and is listed in the Blog Overview.
Ecency Blog Post Content to execute the vulnerable redirect to splinterlands webpage
Animation of Exploit / Vulnerable automatic Redirection
Security Impact
The impact of this vulnerability was classified as high/critical due to the following risks:
- Automated Phishing: Users could be redirected to pixel-perfect clones of login pages to steal Hive keys or sensitive credentials.
- Malware Distribution: The redirect could lead to sites hosting "Drive-by-Download" exploits, compromising the user's device.
- Trust Erosion: Since the redirect happened instantly upon clicking an InLeo link, it severely undermined the perceived security and reliability of the platform.
- Session Manipulation: Beyond simple redirects, uncontrolled HTML injection could have been used to spoof UI elements or capture session data.
Resolution & Mitigation
The vulnerability was resolved by implementing strict server-side sanitization. It is a security best practice for web applications to utilize a "whitelist" approach for HTML rendering. Critical tags such as <meta>, <script>, <iframe>, and <form> must be stripped or escaped from user-generated content to prevent execution.
Acknowledgment
Thanks to the InLeo development team for their exceptionally fast response and the immediate implementation of a fix within the following day on March 20, 2024. Their commitment to rapid remediation ensured the continued safety of the Hive community and the platform’s user base.
Side Notes:
During investigative work in 2024 in collaboration with the Inleo Team, it was possible to execute the so-called marquee command in threads. <marquee> was also not sanitized on the server side, and consequently, it was possible—as other users soon realized and also inserted threads during a live show. It was also possible to change the entire chat to rainbow colors for all users. With the security vulnerabilities mentioned above, which were known at the time, any user could be redirected from the homepage, a thread, or a blog post—for example, to YouTube—where the Rick Roll video would play. This bug was fixed shortly after it was reported. Nevertheless, it’s worth noting that this bug went unnoticed for a very long time, exposing platform users to a high level of risk. I received a thank-you for my work...but no bug bounty for this work.