Auditing Anonymous Networking Software
At HashCloak, we've been leveraging the work done in Katzenpost to build Meson, a mix network for cryptocurrency appplications. We've recently released our first testnet, Steel Magnet, after many years of R&D and debugging. As such, the Meson codebase is relatively small and contains code that we are now intimately familiar with. We figured this would be the best time to start thinking about the security of our anonymous network and prepare for our first internal audit.
In the midst of our research into this, we quickly learned that anonymous networking software doesn't get auditing to the same degree (if at all) as smart contracts or other blockchain enabled software. As such, we have decided to document our efforts in auditing Meson through this multi post blog series. We will be detailing our approach and any resources we develop with the goal of 1) educating others on how anonymous networking should be audited and 2) providing reassurance and transparency to supporters of Meson that at HashCloak, we take the security and privacy of our privacy software very seriously. In this first post, we will be going through our current plans and approach for how we aim to tackle auditing Meson.
The Beginning
As a first step, we started looking into how other well-known anonymity networking software handles audits and external code reviews. We started looking at software that was adjacent to Meson such as Tor, I2P, various VPNs and other mixnet competitors (Nym, Oxen, HOPR, etc). We quickly noticed that mainly only the VPN services had engaged external third parties to audit their software (often times clients, web browser extensions, etc) but the other kinds of privacy adjacent software rarely did this. In the case of Tor, the most famous anonymity networking software of all time, there is a vibrant academic community that seeks to find bugs in both its design and implementation and as such, Tor gets regularly looked at from a diverse set of stakeholders. Even though this doesn't necessarily count as a audit in the traditional sense, this approach has provided very valuable research and it may be possible to find similar bugs in Meson. To a smaller extent, the same can be said of I2P.
However, for the other projects, there have been no publicly published audits regarding the actual client and server software underpinning their networks. When there are audit reports available, it was mainly regarding the smart contract functionality needed for payments and other node management functionality (scalability, credentials, etc). We quickly realized that we will need to develop our own checklists of what to look out for and read more deeply into bugs that have affected previous networks in order to better adapt them to Meson and see how they might translate.
Since everyone on the Meson team at HashCloak has experience auditing software, we already had the skills needed to predict what areas would need more scrutiny and how to conduct research for security-related topics. This would be the first time we would need to develop our own set of resources without relying on the shoulders of giants. So, we set out to gather as much info as we can on anything adjacent to the security of anonymous networking software. We gathered audit reports of VPN clients, CVEs affecting various networks, academic papers, etc. We are still in the process of combing through all of these resources that we gathered. Over the course of this blog post series, we will be detailing our findings and hopefully these findings helps other projects better secure their networks as well.
Our current progress
So far in our process, we have compiled a list of basic things that we should check for no matter what. This minimal list will most likely be a mainstay for every single audit we do for Meson and any anonymous networking code that comes our way as part of our consulting business. You can find our current checklist here.
We will do a quick walkthrough of the checklist. Note that this list is ever evolving and we will be updating it as we learn more about auditing anonymous networking software.
Check and Update Dependencies
Dependencies are often a way in which vulnerabilities creep into a codebase. For every single dependency that we have, we will analyze to see if it needs to be updated or even if we can implement it ourselves and integrate it into the codebase. If we simply need to update it, we will ensure that any code that breaks as a result is confined to a staging branch. If we realize that it may be better for us to fork it or reimplement the functionality, we will take into account the extra time we need for our roadmap.
Set up a fuzzing harness
Fuzzing is a testing technique in which one's code is given arbitrary inputs in order to cause unexpected behavior in the code. The goal is to find areas of the code that hasn't been sufficiently hardened. This will most likely be an ongoing tasks as the codebase gets larger. Once we have a larger scale testnet, we will be using the testnet data to form our corpus to build our fuzzer with.
Check logs for info leaks
Logs are a common source of information leakage in security sensitive applications. These are usually the result of developers adding log messages in order to ease the debugging process but forget to omit them for production releases.
Ensure that installation doesn't escalate privileges
This item mainly relates to when users download a program with Meson embedded such as a cryptocurrency wallet. During the installation process, any executables that contain Meson should be only modifiable by privileged users on that machine. Otherwise, a normal user might have the ability to overwrite executables and escalate privileges.
Check for time of check and time of use bugs
Time of check and time of use bugs are a category of race condition bugs that hard to protect against in large scale distributed systems. The race condition occurs when there is a time gap between when a condition is checked and then that condition is leveraged to execute some code.
Check input and output sanitization
The inputs and outputs of certain operations need to be processed before they are used throughout the codebase. Otherwise, it might be result in intentionally malformed inputs or ouputs being able to trigger undefined behavior within a program. Further, sensitive data can be contained within inputs/outputs and these should be removed accordingly.
Check that Prometheus and Grafana ports are not easily accessible to an attacker
We make heavy use of Prometheus and Grafana for instrumentation and providing Meson node operators with as much information as possible about the state of their nodes. Prometheus and Grafana expose ports in order for the node operator to query data and display it as they see fit. We see this as a potential avenue for information leaks and unauthorized access. As such, we need to ensure that we are not introducing any problems into the Meson codebase by relying on these tools.
Check for the usual cryptography bugs
As Meson is a fork of Katzenpost and Katzenpost relies on many cryptographic protocols for various aspects of its designs, cryptographic implementation bugs can easily creep in. This category of bugs is very familiar to us as we find these bugs through our consulting engagements.
Check container configurations
For easily deploying Meson nodes, we provide docker containers for prospective node operators to use. As with using Prometheus and Grafana, we have similar concerns with potential information leaks and unauthorized access to containers.
Check for signature validation
Signature validation is a common area in which bugs creep into such codebases, that we felt that it warranted its own bulletpoint as opposed to being put together with cryptographic implementation bugs or time of check and time of use bugs. Signatures are used throughout Meson to provide authentication, integrity and confidentiality. As such, signatures need to be validated in order to minimize the risk that any of these properties are broken.
Once we have more items and have added more details, we will most likely create a separate community Github repository with this information so that other teams can check their code against this checklist.
Conclusion
That's the end of our first post in this series as we aim to build a good security foundation for Meson. Stay tuned for the next post! If you have any feedback about anything relating to auditing anonymous networking software, please let us know on Github by commenting on our issue , our Element Community or Tweet at us @MesonMixnet!