1. TESTING FOR VULNERABILITIES AND APPLICATION SECURITY REVIEW George-Alexandru Andrei CTO BIT SENTINEL

2. ABOUT ME  I am security a engineer and IT fanatic. Devoting his past 4 years to Security, not just IT Security but also physical and personal security he likes to tinker with just about every gadget that he can get his hands on. His technical skills pirouette around network security, penetration testing, security testing, wireless insecurity and of course setting up hackable machines for others to play with. He is also the main guy to go to at Defcamp if you want to “Hack The Machine”.

3. WHY FIND VULNERABILITIES?  Nobody believes their software is vulnerable  “If the software works, then it must be secure”  Finding flaws starts you on the path  If you’re not finding them, you’re allowing them Find Flaws Fix Find Flaws Improve Find Flaws Improve

4. SOFTWARE IS A BLACK BOX  Complex  Millions of lines of code  Layers of leaky abstractions  Massively interconnected  Compiled  Difficult to reverse engineer  Different on every platform  Legal Protections  No peeking  We’re not liable

5. SECURITY ANALYSIS TECHNIQUES  Find Vulnerabilities Using the Running Application  Combining All Four Techniques is Most Effective  Find Vulnerabilities Using the Source Code Automated Vulnerability Scanning Automated Static Code Analysis Manual Penetration Testing Manual Code Review

6. OWASP TESTING GUIDE  OWASP TESTING GUIDE V4.4 https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4. pdf https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4. pdf  Part of an appsec body of knowledge…

7. BLACK BOX VS GREY BOX The penetration tester does not have any information about the structure of the application, its components and internals Black Box The penetration tester has partial information about the application internals. E.g.: platform vendor, sessionID generation algorithm Gray Box

8. TESTING STEPS  Planning  Reconnaissance  Infrastructure  Input validation  Denial of Service (DoS)  Authentication & Authorization  Information Disclosure  Code Review  Reporting

9. PLANNING  Change Management  Don’t get fired  Communicate fully  Get approvals in writing  Clearly defined scope  Test or production  Which web servers will be targeted  Can vulnerabilities be exploited  Can modifications be made via exploits  Will Denial of Service be tested  Are brute force attacks allowed  White box vs. black box

10. PLANNING - TOOLS  Presenter's favorites  BurpSuite– Testing proxy, fuzzer, spider, more  Nessus – General vulnerability scanner  Nikto– Signature-based web scanning, Google reconnaissance  Nmap – Port scanner & fingerprinting  WireShark (Ethereal) – Packet capture  Other free tools  Wikto– Signature-based web scanning  Pantera – tool from OWASP, automated scanning  Paros – Testing proxy, spider  WebScarab– Testing proxy, more

11. RECONNAISSANCE & AUTOMATED SCANNING  Google (Wikto) – Can find some vulnerabilities, pages difficult to navigate to  Spider (WebScarab)  Specialized Web scanners (Wikto, commercial) – Known web- app vulnerabilities; simple cases of XSS, SQL injection, etc.  Try to identify what off-the-shelf software is being used, then research vulnerabilities (securityfocus.com)  Source code  Look on open file shares  Look for unsecured code repositories

12. INFRASTURCTURE  Port scan (nmap)  General vulnerability scan (Nessus)  Unsecured HTTP management ports  Web Server attacks  Application framework attacks: WebMethods, WebLogic, other J2EE, ColdFusion, etc  Miscellaneous vulnerable services; NetBIOS, RPC, etc.

13. INPUT VALIDATION  SQL Injection  Cross Site Scripting (XSS)  Buffer Overflows

14. SQL INJECTION  Caused by failure to properly validate user-provided input  Allows arbitrary commands to be executed in the database  Example for a login:  Username = alex  Password = very_secure

15. SQL INJECTION SELECT count(userID) FROM users WHERE username = ‘alex' AND password = 'very_secure'

16. SQL INJECTION  Username: alex' OR 1=1 -- SELECT count(userID) FROM users WHERE username = 'byrned' OR 1=1 -- ' AND password = 'very_secure'

17. SQL INJECTION  Test by inserting string delimiting characters such as a single quote  Look for error messages

18. CROSS SITE SCRIPTING (XSS)  Allows an attacker to imbed arbitrary HTML inside a web page  Can be persistent (e.g. a bulletin board) or dynamic (e.g. a URL)  JavaScript can  Redirect the browser to an attack site  Monitor and report browsing activity using frames  Launch attacks against browser vulnerabilities  Steal cookies  Perform actions while impersonating user (MySpace worm)

19. CROSS SITE SCRIPTING (XSS)  Look for any content in a web page that was based on user- provided input  Check the source: The content might be in the HTML, but not displayed  Input isn’t limited to visible form fields. Look at cookies, HTTP headers, URL query strings, hidden fields  Standard pages aren’t the only source of XSS; error pages (even 404s) are frequently vulnerable

20. BUFFER OVERFLOWS  Not common with modern web environments  With black box, send long strings for different parameters, >1024 bytes; might have to switch to POST

21. DENIAL OF SERVICE (DOS)  Locking Customer Accounts  Buffer Overflows  User Specified Object Allocation  User Input as a Loop Counter  Writing User Provided Data to Disk  Failure to Release Resources  Storing too Much Data in Session  http://www.owasp.org/index.php/Testing_for_application_laye r_Denial_of_Service_%28DoS%29_attacks

22. INFORMATION DISCLOSURE  Directory traversal & listing  HTML & JavaScript comments  Error messages can divulge:  Operating System environmental parameters  Web Server settings  Database drivers in use  SQL queries run on a page  Software versions

23. CODE REVIEW  SQL queries  Stored procedures  User-supplied input as part of output  Operating System / shell commands  Error handling routines  Source code storage & access  Authentication & authorization mechanisms  http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents

24. REPORTING  Severity  Category (OWASP Top 10)  Location (e.g. line 23 of /search/main.php)  Example exploit  Impact of exploit (e.g. theft of credit card data)  Recommended remediation  Third party documentation (vendor or OWASP)

25. REPORTING - CATEGORIZE SEVERITY  PCI severity levels: https://pcisecuritystandards.org/pdfs/pci_scanning_procedures_v1- 1.pdf 5Urgent Trojan Horses; file read and writes exploit; remotecommand execution 4Critical Potential Trojan Horses; file read exploit 3High Limited exploit of read; directory browsing; DoS 2Medium Sensitive configuration information can be obtained by hackers 1Low Information can be obtained by hackers on configuration  Common Vulnerability Scoring System (CVSS v2)  Remote vs. local expliot  Attack complexity  Authentication required  Availability of exploit  Type of fix available  C/A/I impact  Impact value rating  Organization specific potential for loss  Percentage of vulnerable systems  Level of vulnerability confirmation

26. EXAMPLE FINDING 11. Improper use of varchar data types Severity: Critical Category: Injection Flaws Exploitation prerequisites: Internet access; authentication may not be required for all pages Description Some pages handle numeric data types as “varchars” (character string). This makes SQL injection possible, despite the “cfqueryparam” tag; since there is no quote to break out of, escaping quote characters won’t help. This occurs in many pages. Example \dsg\createNewPage.cfm; line 54 select user_name from users (nolock) where user_number = Recommendation Every file should be reviewed for how each SQL query or stored procedure is called. Change all numeric SQL parameters to use CF_SQL_INTEGER. References http://www.adobe.com/devnet/coldfusion/articles/cfqueryparam.html http://www.owasp.org/index.php/Data_Validation

27. APP2OWN CONTEST

28. QUESTIONS?

29. THANK YOU