1 / 9

Module 5 Reviewing Code for Exploits

Presented by Heorot.net. Module 5 Reviewing Code for Exploits. Objectives. Understand abilities and limitations of code reviews Identify potentially “bad” code Identify and use code review tools * We will not discuss how to exploit code, just identify weak code.

jalene
Download Presentation

Module 5 Reviewing Code for Exploits

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Presented by Heorot.net Module 5 Reviewing Code for Exploits

  2. Objectives • Understand abilities and limitations of code reviews • Identify potentially “bad” code • Identify and use code review tools *We will not discuss how to exploit code, just identify weak code

  3. Abilities and Limitations • There is a lot of code to review • Nobody can review all code by themselves • You can only affect the program where the user interfaces with the application • Definitely true with remote servers • Mostly true with local system • You need to understand code • You need to understand how people exploit code • Understand that most coders do not know how to program securely – you become the expert • Expect a lot of False Positives

  4. Identify Potentially “Bad” Code • Code Reviews: (PenTest review) != (software development review) • Set a time limit • Code reviews take a lot of time • Pair up with someone if possible • Establish very small scope • Know your threats • Obfuscation does not work • Often used to hide hard-coded data

  5. Identify Potentially “Bad” Code • What can go wrong: • SQL injection • Cross-site scripting • Input/data validation • Authentication • Authorization • Sensitive data • Code access security • Exception management • Data access • Cryptography • Unsafe and unmanaged code use • Configuration • Threading • Undocumented public interfaces

  6. Identify Potentially “Bad” Code • C/C++ problems: • No bound checks: • strcpy(), strcat(), gets(), sprintf(), scanf() family • format string problems; • [v][f]printf(), [v]snprintf(), syslog() • race conditions: • access(), chown(), chgrp(), chmod(), tmpfile(), tmpnam(), tempnam(), mktemp() • shell metacharacter dangers: • exec() family, system(), popen()

  7. Tools for Code Reviews • Code scanner • Manual scanning is just not practical • Automated scanning often provides documentation that is usable in a write-up • Fuzzers • Able to find potential exploits • Reduces time spent on code reviews • Does not require code to use

  8. Tools for Code Reviews • Code scanner • *Fortify Static Code Analysis (SCA) • COBOL, Classic ASP and ColdFusion, Java, .NET, C/C++, PLSQL, TSQL and XML • http://www.fortify.com/products/sca/ • Rough Auditing Tool for Security (RATS) • Scans C, C++, Perl, PHP and Python • http://www.fortify.com/security-resources/rats.jsp • Flawfinder • Includes a list of other code scanner applications • http://www.dwheeler.com/flawfinder/ • Doxygen • Documents code – does not scan for vulnerabilities • C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C# • http://www.stack.nl/~dimitri/doxygen/ *Commercial Product

  9. Conclusion • Understand abilities and limitations of code reviews • Identify potentially “bad” code • Identify and use code review tools

More Related