Orange Labs (R&D) > Now at Orange Portal (development and hosting of *.orange.fr) Interests > Mainly wireless (Wi-Fi, GSM/GPRS, 3G, UMA…) > Now involved in Web security domain Contact information > laurent dot butti at orange dot com > http://www.linkedin.com/in/laurentbutti Stateful Fuzzing of Network Protocol Implementations
to investigate this area of research Examples of developed fuzzers and obtained results Experience return on fuzzing Stateful Fuzzing of Network Protocol Implementations
> Wireless LAN (e.g. Wi-Fi) > Unlicensed Mobile Access (UMA) > Interworking-WLAN (I-WLAN) > IP Multimedia Subsystem (IMS) > FemtoCells (small cellular base station, e.g. 3G) Increased attack surface: > Deploying new network protocol stacks and equipments that are directly or indirectly reachable from un-trusted networks > Exposing some old and unaudited (regarding security) network protocol stacks and equipments (e.g. GSM) Stateful Fuzzing of Network Protocol Implementations
> R&D activities > Validation tests of mobile architectures (2G/3G/LTE/FemtoCells…) conjointly with Orange Mobile business unit Within the validation process there are mandatory security audits But, these architectures are not mastered by “classic” security auditors > Recently designed network protocols and architectures > Very limited number of publications regarding security issues > Very limited number of appropriate Open Source security tools Stateful Fuzzing of Network Protocol Implementations
at validating: > Architecture design > Network security policies enforcement > System security hardening > Physical device security > Processes (deployment, maintenance…) Issues in above topics can be discovered by experienced security auditors > Unfortunately, it is not enough to protect you from advanced intruders Stateful Fuzzing of Network Protocol Implementations
and their network protocol stacks Fuzzing is a great candidate to discover implementation issues > Fits well on both white-box and black-box contexts Fuzzing is usually good at catching low-hanging fruit vulnerabilities Stateful Fuzzing of Network Protocol Implementations
Key Exchange v2 (IKEv2) w/ IPsec > Extensible Authentication Protocol (EAP) and its methods (SIM/AKA) > UMA and Global System for Mobile Communications (GSM) Stateful Fuzzing of Network Protocol Implementations
network protocols > Key exchange, encryption, message authentication codes… Model-based fuzzing was our primary choice > Random and mutation based fuzzing are not efficient on encrypted flows > Relying on a valid skeleton helps to pass preliminary sanitization checks > Still have the ability to add “randomness” on some parts of the model Awesome Open Source release (2007): Sulley Fuzzing Framework > Model-based fuzzing framework for data generation > Capabilities to run automatically set of tests and to monitor them Stateful Fuzzing of Network Protocol Implementations
> Nice example of a flaw in a RADIUS software thus deep in the network EAP – CVE-2007-5651 (Cisco Authenticators) > Nice example of an embedded device bug (switches, access points…) thus attacking the infrastructure Stateful Fuzzing of Network Protocol Implementations
to implementations not specifications > e.g. implementation of parsers and state machines Fuzzing is successful when testing young unaudited implementations Fuzzers only find implementation errors for what they are designed for > Unless you’re “lucky” (side-effects) Fuzzing focuses only on user-controlled data > No false positive issues (depending on your “error detection” technique) Stateful Fuzzing of Network Protocol Implementations
are sometimes time consuming to develop > You have to understand and implement a (partial) network stack > They must evolve to test new protocol features Stateful model-based fuzzing is great! > Adapted to “hard-to-fuzz” network protocol implementations An efficient “test-bed” for fuzzing tests is as important as data generation > Efficiency of error detection techniques is critical on black-box fuzzing > Fuzzing client implementations requires client instrumentation > All tests must be replayable and recordable – Some bugs are triggered only thanks to a sequence of packets Stateful Fuzzing of Network Protocol Implementations
improves code quality > Complimentary to code coverage (unit testing) Launch a fuzzing campaign for every software release > Testing possible regressions and new features Do not forget that humans are running fuzzers > Interpreting results and analyzing issues > Reporting bug issues for corrective maintenance > Managing legal contracts to ensure a reasonable delay for corrective actions Stateful Fuzzing of Network Protocol Implementations
efficient error detection techniques > Otherwise it leads to false negatives Fuzzers can not test every single code’s path > Must be considered as another tool to improve code quality Model-based fuzzers must evolve continuously > Otherwise will not be efficient on new protocol features implementations Stateful Fuzzing of Network Protocol Implementations
Stateful model-based fuzzing is great! Network stack implementers must integrate fuzzing in their SDLC Their customers should integrate fuzzing tests when doing security audits Fuzzing must be considered as a mandatory step for code quality Stateful Fuzzing of Network Protocol Implementations
Fuzzing for Software Security Testing and Quality Assurance, ISBN 978-1-59693-214-2 Michael Sutton, Adam Greene, Pedram Amini (2007). Fuzzing: Brute Force Vulnerability Discovery. Addison-Wesley. ISBN 0321446119 Stateful Fuzzing of Network Protocol Implementations
802.11 stack buffer overflow bug in an Open Source wireless driver under Linux CVE-2007-5651, CVE-2008-2441 > One of the 1st (publicly-kown) EAP implementation security bugs CVE-2009-1957, CVE-2009-1958 > One of the 1st (publicly-known) IKEv2 implementation security bugs in an Open Source software (StrongSWAN) Stateful Fuzzing of Network Protocol Implementations