Almost an year ago we were boiling the idea of starting a professional security audit over the freshly released OpenSIPS 3.2 . What were the reasons for doing this and how the audit actually took shape, as targets, methodology and deliverables, is described in this original manifest.
Of course, nothing would have been possible without the implication of Enable Security, which is known for having dedicated RTC security expertise.
This Audit is a collective public effort, with public benefits for everyone. So arrangements on two “fronts” were made. First in relation with Enable Security to draft the scope of work and secondly, in relation to the community, to run the fund raising in order to cover the related expenses.
And the Open Source way of life thrived here. The entire community, people and businesses, contributed with funds here. Also Enable Security, with a good understanding of Open Source philosophy, did the best to align to the specifics of such a project.
With the deal done, the work effort was on Enable Security side. The security audit was based on the concept of White box Penetration Testing, using various methodologies:
- Blackbox fuzz testing
- Coverage-guided fuzz testing setup using libfuzzer
- Coverage-guided fuzz testing setup using AFL
- Greybox fuzzing setup using AFLNet
As parts of OpenSIPS, the main targets core script functions, the SIP parsing and builder and sensitive modules such as auth, sipmsgops, sl, tm , topology_hiding, dialog and mi – typically modules that do interact via SIP with the outer world, so probably the mostly prone to external attacks.
Of course, following the testing progress, different finding (read here bugs or crashes 🙂 ) were reported. This reporting was done almost in realtime, with a very detailed explanation of the issue and, most important, with instructions on how to reproduce it. This helped us a lot do the fixing.
The fixes were committed (and backported) to the public tree with no delays. Nevertheless, for security reasons, we avoided to provide a detailed description of the actual issue (and its fix) or information on how to reproduce – our first priority is to ensure that everyone has access to the fixes and a reasonable amount of time to upgrade, without being exposed to any malicious attacks “inspired” by the findings of this audit.
So, in order to avoid disclosing dangerous information, but still have well documented fixes for the future, we decided to use the Security Advisories provided by GITHUB. The audit related commits are quite simple and cryptic, simply pointing to a security advisory – and for now, these security advisories are private.
The plan is to go public with the security advisories – and to disclose all the information on the findings and fixes – after about one year, again, to give everyone a good chance to update and protect.
The outcome of this audit was a huge amount of code that was validated as being secured. But also a set of 15 issues (crashes) that were fixed, making the next OpenSIPS releases even safer.
Thanks to the Enable Security team, we can share here a comprehensive report on the tests, methodologies and found issues. A more detailed report (with backtraces, descriptions and how to reproduce each issue) will be later available as well.
All the reported issues were addressed and the fixes are available on all currently maintained OpenSIPS versions (3.1 and 3.2).
In addition, Enable Security provided a more descriptive document covering not only the findings, but also the methodology of how the audit was conducted, how various tests were performed and how the needed environment was setup.
The audit itself is now completed, but not our work. Part of the legacy of this audit is the knowledge on how to prepare and run such tests ourselves. So we can target more code in the future. Enable Security is here to guide and teach us during this whole process. A BIG THANK YOU here!
Besides the code pentesting, we plan to build and run blackbox fuzzing on systems setup (certain OpenSIPS configurations) as a whole. To a certain point OpenSIPS is as secure as you configure it to be ;).