The document discusses plans for a security audit of the OpenSIPS project. It began when Enable Security was proposed and hired to perform the audit in April/May 2021. The first milestone of testing the OpenSIPS parser, auth, tm, and dialog modules was funded, while the second milestone of additional testing remains to be funded. The goals of the audit are to find security issues, help integrate automated testing, and contribute findings to help improve OpenSIPS security long-term. A demo showed examples of black box and instrumented fuzzing approaches to be used.
3. Why a security audit?
AKA: why take an offensive security approach?
Offensive security = Simulating adversaries/attackers
4. Only by testing for security aws, can those
bugs be found and therefore addressed
5. OpenSIPS is de nitely an application that often serves a trusted
security function.
6. Who am I to talk about this?
Hi! Sandro Gauci here
Original author of SIPVicious OSS - security testing toolset for SIP
In Infosec / Cyber security since > 20 years
Last 13 years doing offensive security and leading Enable Security
We focus on VoIP and WebRTC security i.e. pentesting, security
audits, developing security tools, consultancy & training
15. 1. De ne the scope - helps limit tests in a huge project such as
OpenSIPS
based on our discussions with Bogdan
de ne the most security sensitive and interesting parts of
OpenSIPS
2. Come up with a test plan for that scope
not exact since creativity is involved and this is not exact
science
gives us an idea of the amount of effort and how much to
charge
3. Compile a proposal which includes Scope of Work, pricing and
schedule
16. De ning the work and the
price
After much discussion, we ended up with 2 milestones
Made a special price for the OpenSIPS community
First milestone cost 15k EUR - this has been reached
Second milestone cost an additional 5k EUR
20. Second milestone: tests
TLS related security tests (go beyond basic TLS testing of course)
Black box fuzzing of WebSocket handling
Analysis of TCP/UDP handling
Fuzzing of MI commands
Topology hiding fuzzing and manual tests to nd logic issues
Fuzzing of internal IDs exposed by TM and dialog modules
22. What can we show you?
we did not start the work yet on OpenSIPS
show some simple examples to illustrate 2 different approaches
to fuzzing
23. Black box fuzzing
sngrep is an excellent tool for debugging SIP
also, it had some over ows
found these by coincidence during an event called OpenSIPIt
the issue shown here has been xed late last year
25. About black box fuzzing
easy to do in its simplest form
OpenSIPS is mature software (i.e. we should not nd anything with
this simple approach)
this approach can still be very effective when enhanced with other
techniques
26. Techniques to enhance
black box fuzzing
compile OpenSIPS with sanitizers
sanitizer coverage reporting
different con gurations to hit the modules that are in scope
fuzz speci c areas e.g. headers
set speci c trigger points for non-crash or logic bug discovery
27. Instrumented fuzzing
this approach is different because the target application sort of
fuzzes itself
in memory so, very e cient
ideal for fuzzing functions in isolation (e.g. for parsers)
can also fuzz entire servers (e.g. AFLNET) using this technique
we do plan on doing that - it is more advanced
next we have a simple example with libfuzzer
30. The problem with
most security testing
they only look the state of the project at some point in time
projects (e.g. OpenSIPS) are all the time changing, with daily
contributions
how can our work be used in the future?
31. Contributing to the security
of OpenSIPS - long term
any ndings from our audit may be added as test cases for
regression testing
material so that fuzzing can be integrated as part of its automated
quality assurance processes
especially focus on getting the project integrated within the OSS-
Fuzz ecosystem (e.g. + )
nginx Apache httpd
32. Word of caution
our focus is the security audit - this is a positive side-effect output
what we will provide should serve as a great starting point
automated security testing efforts
naturally, future security tests will still be useful
both go hand in hand to make the codebase more robust
34. Schedule
start mid-September (i.e. next week)
be done around the end of October 2021
present our reports to the core developers
during the testing, we hope to have communication open with
devs so that any critical xes can be addressed quickly
36. Current status
rst milestone has been reached already so we can start
if anyone would like to still contribute, you certainly may!
we would love to cover the second milestone as well
38. Thanks!
Bogdan-Andrei Iancu & the OpenSIPS people for this opportunity
The sponsors for raising the funds to support our work
My colleague Alfred for his work and demos
39. Get in touch & References
Email:
Website:
The OpenSIPS security audit page:
Communication Breakdown blog @ rtcsec.com
sandro@enablesecurity.com
https://www.enablesecurity.com
https://www.opensips.org/Community/Security-Audit