Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fuzzing and You: Automating Whitebox Testing


Published on

Fuzzing is easy, but getting useful information from fuzzing isn’t. ‘Spray and pray’ might get some results, but a set of well-designed tests will get much better results faster. Unfortunately, the job doesn’t end there. Fuzzing doesn’t find vulnerabilities; fuzzing finds unexpected behavior. Interpreting that unexpected behavior relies on understanding the application you’re fuzzing and the tests you’ve designed. This presentation will discuss techniques for creating tests targeted towards uncovering specific behavior, including authorization bypasses, directory traversals, and buffer overflows.

Published in: Technology

Fuzzing and You: Automating Whitebox Testing

  1. 1. Fuzzing and You: Automating Whitebox TestingMike Anderson
  2. 2. Intro• Senior Security Consultant ‒ 4 years of pentesting ‒ Presentations at DefCON, BASC, OWASP ‒ Goon at ThotCON and DefCON
  3. 3. What is fuzzing?• Automated testing procedure ‒ Protocol Fuzzing vs Application Fuzzing ‒ Heavily customized per application ‒ Multiple approaches • Whitebox vs Blackbox • Totally random < Mutation • Educated guesses
  4. 4. Fuzzability• Fuzzing can: ‒ Enumerate many issues in a large, complicated application ‒ Find issues purely manual testing or automated scanners might not find ‒ Help demonstrate how issues found by static analysis can be leveraged ‒ Be very thorough ‒ Cause availability problems
  5. 5. Infuzzability• Fuzzing won’t: ‒ Find vulnerabilities • Requires analysis ‒ Light your server on fire ‒ Fix issues
  6. 6. Know your goals• Static analysis ‒ Great for finding code issues ‒ Bad at risk ‒ Bad at configuration ‒ Bad at business logic• Fuzzing ‒ Accounts for configs ‒ Can be tailored for business logic ‒ Requires time ‒ Does not locate remediation point
  7. 7. How does I fuzzed?• Fuzzing can be super easy ‒ Automated tools like taof• More hands on approaches will deliver better results ‒ Favorite tools: • BURP Suite (web applications) • Sulley (for pretty much whatever)
  8. 8. Handcrafting with love• Design tests ‒ What application are you testing? • This determines what tools you may need to use ‒ What are you looking for? • Buffer overflows, Authorization Bypass, General error handling?, SQL injection (sqlmap does this) • This determines payloads ‒ Iterative process
  9. 9. Analysis and Remediation• Issues aren’t always clear cut ‒ Location in code can be confused ‒ Work with developers ‒ Less errors != less issues• Use metrics to refine tests ‒ Use code mapping • Percentage coverage • Tools will vary by technology ‒ Bugs detected ‒ Length of fuzzing ‒ Crashes caused
  10. 10. Use Cases• Authorization bypass ‒ Directory traversal (../) ‒ Delimiters (depends on protocol) ‒ ID names or numbers• Buffer overflow ‒ Length of parameters• Injection ‒ Sql injection ‒ LDAP injection• Many tools will have libraries that can check for these
  11. 11. BURP Suite• Fuzzes HTTP• More manual than something like WebInspect• Lacks insight into server state ‒ Crashes and network disruptions will hurt data• Potential attackers will likely use a tool like this• Lacks some versatility
  12. 12. Fuzzing with Intruder
  13. 13. Include some tests• FuzzDB • • Replicates a lot of expensive software • Super easy to use
  14. 14. Interpreting results• All responses 200• Only 1 error• The rest include guid• This is not an exploit• This may not even be a vulnerability
  15. 15. Missing Pieces• BURP is really difficult to use to fuzz things like wbxml ‒ Could write a plugin• BURP is really bad at finding things like buffer overflows ‒ High manual cost• We’ll need another tool…
  16. 16. Sulley• Flexibility• Grammar-based• Requires knowledge of the protocol in use• Requires access to set up some tools on the server ‒ Procmon, netmon, VM monitoring• Availability problems? I feel bad for you son
  17. 17. Building a Sulley Grammar• s_initialize ‒ Starts a section of your request• s_static, s_delim ‒ Doesn’t get fuzzed• s_string, s_binary ‒ This is a parameter you want to fuzz!• This is where spending time with the application will be very useful
  18. 18. Start with a request• Identify protocol data ‒ These should be static ‒ Ensure only application code gets fuzzed ‒ s_delim, s_static ‒ Look at headers, delimiters
  19. 19. Identify fuzzable data• Remember that encoded payload?• Respect delimiters, to ensure fuzzed data is valid
  20. 20. Building a Sulley Grammarfrom sulley import *s_initialize(“activesync")S_block_start(“headers”)s_static("POST /Microsoft-Server-ActiveSync?Cmd=Sync&User=netspi%5Cmanderson&DeviceId=androidc1551312136&DeviceType=Android HTTP/1.1") #protocol information is saved inan s_static primitive…s_block_start(“payload")s_delim(“0x05”);s_delim(“0x1c”);s_delim(“0x0f”);s_delim(“0x10”) #seriesof delimiterss_string(“email”)#fuzzable strings_delim(“0x10”); s_delim(“0x0b”)s_string(“0”) #another fuzzable parameters_delim(“0x0b”);s_delim(“0x12”)s_string(“d9c345dcae9f1640934f6b269e63d11f-111e2c9”)…
  21. 21. Sulley Session File• Allows direction of sulley by blocks• Allows fuzzing of multiple protocols• Analyzes information from procmon and netmon tools to direct fuzzing and fix servicessess =sessions.session(session_filename=“activesync)
  22. 22. Building your graph• Graphs tell Sulley what sections go where• Can be used to construct multiple requests• Use the commands below to specify our session filesess.connect(s_get(“activesync”)) #tells sulleyto include the session file
  23. 23. Session targets• Identify target protocol, and procmon/netmon“ip.ip.ip.ip”, port)Activesync_target.netmon=pedrpc.client(“ip.ip.ip.ip”,port) #theseare chosen when you run the netmon binary on the targetActivesync_target.procmon=pedrpc.client(“ip.ip.ip.ip”,port)Activesync_target.procmon_options ={“proc_name”: “process_name”,“stop_commands”: [‘cmd_to_stop_service’],“start_commands”: [‘cmd_to_start_again’]}• Run the procmon and netmon binaries before you begin fuzzing ‒ install sulley on the target
  24. 24. FINALLY• Add target, and run fuzzerSess.add_target(activesync_target)Sess.fuzz()• Then, invoke your python file from command line ‒ Make sure you import the libraries you’ll need$./
  25. 25. Analysis• Sulley has built in tools to help with analysis ‒ Use to filter any normal responses ‒ Crashbin_explorer helps understand crashes• Make sure to turn off netmon and procmon after fuzzing is complete• Seriously, even if its non-prod
  26. 26. Conclusion• Choose the right tool for your goal ‒ Not always fuzzing• Choose the right parameters to fuzz• Design the tests• Run the tests, analyze results• Refine tests, or exploit
  27. 27. Questions or comments?Michael AndersonSenior Security ConsultantNetSPI
  28. 28. Thank YouNetSPI800 Washington Avenue NorthMinneapolis, MN 55401612-465-8880