Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CodenomiCON 2011 - Stateful Fuzzing of Network ...

CodenomiCON 2011 - Stateful Fuzzing of Network Protocols Implementations

Laurent Butti

October 07, 2011
Tweet

More Decks by Laurent Butti

Other Decks in Technology

Transcript

  1. 2 % whoami  Senior Security Expert > Formerly at

    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
  2. 3 Agenda  Orange’s context  Fuzzing: why we decided

    to investigate this area of research  Examples of developed fuzzers and obtained results  Experience return on fuzzing Stateful Fuzzing of Network Protocol Implementations
  3. 4 Orange’s Context  Fixed-Mobile Convergence technologies are relying on

    > 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
  4. 5 Orange Labs’ context  Orange Labs in charge of

    > 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
  5. 6 “Classic” Security Audits  “Classic” security audits objectives aim

    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
  6. 7 Fuzzing: Why?  To assess security of these equipments

    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
  7. 8 Fuzzing: What?  Fuzzer candidates: > Wi-Fi > Internet

    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
  8. 9 Fuzzing: How?  Stateful fuzzing is required for cryptographic-based

    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
  9. 10 CVE-2006-6332  Stack-based buffer overflow in madwifi Open Source

    wireless driver #ifdef IWEVGENIE memset(&iwe, 0, sizeof(iwe)); memcpy(buf, se->se_wpa_ie, se->se_wpa_ie[1] + 2); iwe.cmd = IWEVGENIE; iwe.u.data.length = se->se_wpa_ie[1] + 2; #else static const char wpa_leader[ ] = "wpa_ie="; memset(&iwe, 0, sizeof(iwe)); iwe.cmd = IWEVCUSTOM; iwe.u.data.length = encode_ie(buf, sizeof(buf), se->se_wpa_ie, se->se_wpa_ie[1] + 2, wpa_leader, sizeof(wpa_leader) - 1); #endif > Model-based fuzzer is well adapted thanks to a WPA capabilities model data generation for fuzzing tests > http://www.metasploit.com/modules/exploit/linux/madwifi/madwifi_giwscan_cb Stateful Fuzzing of Network Protocol Implementations
  10. 11 CVE-2007-5651, CVE-2008-2441  EAP – CVE-2008-2441 (Cisco Secure ACS)

    > 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
  11. 12 CVE-2009-1957, CVE-2009-1958  IKEv2 implementation bugs > Nice examples

    of state machine implementation issues > Strongswan 4.3.0 was vulnerable, fixed in 4.3.1 Stateful Fuzzing of Network Protocol Implementations
  12. 13 Experience Return: General Facts  Fuzzing is always related

    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
  13. 14 Experience Return: Designing and Implementing Fuzzers  Model-based fuzzers

    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
  14. 15 Experience Return: Within a Software Development Life-Cycle  Fuzzing

    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
  15. 16 Experience Return: Some Limitations  Black-box fuzzing relies on

    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
  16. 17 Conclusions  Even security mechanisms may introduce security vulnerabilities

     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
  17. 19 References  Ari Takanen, Jared DeMott and Charlie Miller,

    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
  18. 20 (Some) CVEs  CVE-2006-6332 > 1st (publicly-known) remotely exploitable

    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