Finding Vulnerabilities in Source Code

Transcription

1 Finding Vulnerabilities in Source Code Jason Miller CSCE 813 Fall 2012

2 Outline Approaches to code review Signatures of common vulnerabilities Language-independent considerations Tools for code browsing

3 Black-box vs White-box testing Black -box testing Involves attacking an application's functionality at its external interfaces HTTP protocols (GET, POST,...) Form inputs (overflow, type checking, injection,...) Controller logic (routes, redirects,...) Attacks carried out with no prior knowledge of the application code or logic Web Application Attack and Audit Framework (W3AF)

4 Black-box vs White-box testing Black -box testing (continued) W3AF:

5 Black-box vs White-box testing White -box testing Involves attacking the internals of an application as opposed to its functionality Data flow testing Branch/Path/Branch testing Statement coverage* Attacks carried out with complete access to source code and logic. *

6 Black-box vs White-box testing White -box testing (continued) Can be used to find problems extremely difficult to detect or infer by black-box testing (ex. Back doors) Should be used in tandem with, not in place of, black-box testing Programmer intuition not as thorough as external techniques like fuzzing Industry black-box testing applications adept at testing combinations over complete sets of application targets

7 Approach Methodologies Testing is usually time-constrained Need to quickly and methodically identify low-hanging fruit so that bulk of time can be spent on more subtle issues Authors' recommendation: 1.Tracing user-controllable data from entry points and reviewing handling code 2.Search for signatures of common vulnerabilities 3.Line-by-line review of inherently risky code

8 Signatures of Common Vulnerabilities Cross-site scripting (XSS) Bad: Returned HTML constructed from user-controllable input (java) String link = <a href= + HttpUtility.UrlDecode(Request.QueryString[ inputstring ]) + > Click me </a> ; Better: Returned HTML that is explicitly constructed (java) Private String[] goodsites = { } String input = HttpUtility.UrlDecode(request.QueryString[ inputstring ]); String link = ; index = Array.asList(goodSites).indexOf(input); if ( index == -1 ) link = <b> INVALID ADDRESS PROVIDED </b> ; else link = <a href= + goodsites[index] + > Click me </a> ; SIGNATURE: Look for code that constructs application output using literal user input. Often missed by fuzz testing and vulnerability scanning. employ input validation when possible. Mod_security?

9 Signatures of Common Vulnerabilities Sql injection Bad: Query constructed from user-controllable input (ruby) query = SELECT * from People where name = + params[:name] results = People.execute(query) Better: Query constructed using object-relational class (ruby) results = People.find( :all, :conditions=>['name =?', params[:name]] ) SIGNATURE: Look for hard-coded substrings that contain SQL keywords. (The book argues case sensitivity when searching). Also prepend and append a space character during searching as potential permutations.

10 Signatures of Common Vulnerabilities Path Traversal Bad: Not properly validating filesystem paths from user input (ruby) = /opt/http/downloads/ send_file( directory + params[:filename] ) Better: Performing minimal validation = /opt/http/downloads/ file = params[:filename] If file.include?.. or file.include? \/ redirect_to( :controller=>'error', :action=>'badfile' ) else send_file( directory + file ) end SIGNATURE: Look for potential avenues for users to traverse system directories or overcome other filesystem protections. File upload/download actions are prime suspects. Input validation. Chroot cage?

11 Signatures of Common Vulnerabilities OS command injection Potential vector for attack (PERL): $MAIL_CMD = '/usr/local/sbin/sendmail'; sub mail { ($recipient, $message) open(mail, $MAIL_CMD $recipient) or die( Could not call $MAIL_CMD ); print MAIL $message; close(mail) or warn( Could not close $MAIL_CMD ); } SIGNATURE: Search for constructs that allow OS commands to be executed (system(), ``,...). Search for directory delimeter characters ( /, \ ). Input validation.

12 Signatures of Common Vulnerabilities Backdoor passwords Potential vector for attack (BASH): #!/bin/env bash export validated validate() { user = ${1} password = ${2} If [[ ${user} == wreckless_zombie && ${password} == letmein ]]; do validated=0 else validated=$( system_validate ${@} ) fi } SIGNATURE: Look for test cases that look for specific users and/or passwords.

13 Signatures of Common Vulnerabilities Buffer overflow Bad: Not properly validating input size (C++): #define BUFFER_SIZE 50 char* readinputstring( InputReader *IR ) { char buffer[buffer_size]; strcpy( buffer, IR->readStream() ); return(buffer); } Better: Utilizing proper function arguments (C++): strcpy( buffer, IR->readStream(), BUFFER_SIZE ); SIGNATURE: For susceptible languages and APIs, look for specific array-handling functions. C/C++: strcpy(), strcat(), memcpy(), sprintf().

14 Signatures of Common Vulnerabilities Integer vulnerabilities Bad: Not paying attention to function return types and comparison values (C): bool toolong( int length, const char *string ) { return( (length<=strlen(string))? false : true ) } Better: Paying attention (C): bool toolong( unsigned int length, const char *string ) SIGNATURE: For susceptible languages and APIs, look for specific integer comparisons.

15 Signatures of Common Vulnerabilities Format string vulnerabilities Potential vector for attack (C): void logauthenticationattempt(char* username) { char tmp[64]; snprintf(tmp, 64, login attempt for: %s\n, username); tmp[63] = 0; fprintf(g_logfile, tmp); /* who knows what is written to the log file */ } SIGNATURE: For susceptible languages and APIs, look at string format patterns. C/C++: printf(), fprintf(), sprintf().

16 Signatures of Common Vulnerabilities Source code comments Potential vector for attack (C++): Char buf[200]; // I hope this is big enough! strcpy(buf, userinput); // FIX: Find alternative to strcpy() SIGNATURE: Review programmer comments.

17 Language Independent Considerations User-supplied data The critical interface between the application and the user Thoroughly learn the API responsible for handling user-supplied data Retrieving parameters Working with HTTP headers Working with cookies Working with sessions

18 Language Independent Considerations Environment configuration Sets the environment for the entire application May have unknown defaults being set Responsible for overall application parameters Security constraints Global variables Session options Error handling Initialization parameters

19 Language Independent Considerations Session interaction Sessions represent a serious door into the application if poorly implemented Understand the session API side-effects limitations Make no assumptions about normal user behavior

20 Language Independent Considerations Dynamic code Functions designed to interpret, not parse, arguments eval(), [ASP, PERL] create_function() [PHP] Use sparingly if at all

21 Language Independent Considerations OS interaction Know application process execution permissions Understand how the app is compartmentalized (if at all) Security labels (SELinux) Containers (Solaris 10, STOP) chroot() cage

22 Language Independent Considerations Miscellaneous APIs to limit and/or scrutinize Filesystem access Database access Socket access

23 Tools for code browsing Source Insight:

24 All Done! Questions?