How secure is your code?


Published on

A brief look at PHP security

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How secure is your code?

  1. 1. How secure is your code? Mikee Franklin
  2. 2. Who am I? <ul><li>Developer @ coolpink
  3. 3. Working in the industry for 10 years
  4. 4. I never finish a personal proj...
  5. 5. I like to play with ALL languages. Use the right tool for the job. (except for javascript, javascript should be used for /everything/)
  6. 6. twitter: @mikeemoo web: </li></ul>
  7. 7. Why I find this interesting.. <ul><li>It's important to know for my work
  8. 8. I love finding things I shouldn't be able to find
  9. 9. I like to think I'm doing a 'good thing' if I find (and report) a security hole
  10. 10. I don't actually know much about it at all. I've barely scraped the surface of what's possible.
  11. 11. I don't “exploit” live websites. </li></ul>
  12. 12. The basics from an exploiters point of view <ul><li>We want to get the server to run our own code
  13. 13. If we can run our own code, we can get shell access
  14. 14. If we can get shell access, we can find things we shouldn't be able to find, and we can potentially get root access.
  15. 15. If not, we can still extract a lot information. Passwords, account details.. etc.. those passwords will often be the same for other sites </li></ul>
  16. 16. It'll help to see the source <ul><li>Having access to the source code makes it a lot easier to find the vulnerabilities.
  17. 17. Check for open /.svn/ folders
  18. 18. Have a poke around. Work out what plugins might be installed, check the source of them.
  19. 19. Check for known files that might give you the version number of the software. INSTALL, VERSION, LICENCE..etc. </li></ul>
  20. 20. File uploads <ul><li>File uploading is obviously the easiest way to get your code up there.
  21. 21. Abuse bad extension checking
  22. 22. Some servers will execute .php.jpg as a php file – depends on configuration and version(?)
  23. 23. You can embed code in image metadata and PHP will still recognise it as a valid image, no matter what the extension. </li></ul>
  24. 24. So now we can execute our own code, what next? <ul><li>Our PHP can execute a reverse socket shell which will attempt to connect back to our own machine and forward STDIN/STDOUT to a socket server running on our local machine.
  25. 25. We can run netcat locally and wait for the connection.
  26. 26. We now have shell access. But we're only running as the apache user... but we can now easily extract all of the data from the database, search the server for other files, and look to see what software is running that'll allow us to escalate permissions.
  27. 27. There's plenty of information out there with databases of exploits (for example, </li></ul>
  28. 28. Local file inclusion (LFI) <ul><li>Get code onto the machine
  29. 29. Use local file inclusion to execute the code good example: require $_GET[“file”].”.php”;
  30. 30. But what about the .php? Surely that'll only open php files?
  31. 31. Using a null character strips off the end, for example: index.php?file=../../../../../../../../../../etc/passwd%00
  32. 32. But.. we need to get our code onto the machine first... </li></ul>
  33. 33. Inject to Apache logs <ul><li>We can inject code into apaches logs by causing an error message that contains our code. This will throw an error:
  34. 34. index.php?file=<?php phpinfo(); ?>
  35. 35. Now we need to include the apache logs. </li><ul><li>We can run through a list of obvious log paths
  36. 36. We can cycle through /proc/self/fd/[x] as one might be a symlink to our logs </li></ul></ul>
  37. 37. Inject to FTP logs <ul><li>We can just attempt to connect to the FTP using our code as the username
  38. 38. The handshake messages from the server will give us a clue to the location of the logs Status: Resolving address of Status: Connecting to Status: Connection established, waiting for welcome message... Response: 220 (vsFTPd 2.2.2) Command: USER <?php phpinfo(); ?> -> logs likely to be at /var/log/vsftpd.log </li></ul>
  39. 39. Write to the database <ul><li>Another possibility is writing our code directly into a database. We can then attempt to include the database file to execute our code.
  40. 40. We can guess the location of the file
  41. 41. Knowing the database name will help us find the path to the database
  42. 42. ..but we cant use LFI to read the database config, because the PHP get will executed.. … but we can use the php filter wrapper to help read it. index.php?file=php://filter/convert.base64-encode/resource=config.php This will output the file base64 encoded, which we can then decode.
  43. 43. If SQL injection is available, we can use it to retrieve the database path </li></ul>
  44. 44. Writing code using SQL injection <ul><li>If the database permissions allow, we can write our code using SQL injection and “outfile”. Select '<?php phpinfo(); ?>' into outfile '/tmp/myfile'
  45. 45. Now we can call.. index.php?file=../../../../../../../../tmp/myfile%00 </li></ul>
  46. 46. SQL Injection <ul><li>SQL Injection is common. Make sure all parameters are parsed
  47. 47. Can extract data we shouldn't be able to get to
  48. 48. Can potentially log in as different users
  49. 49. Maybe read files off the server
  50. 50. Maybe even execute our own code </li></ul>
  51. 51. Conclusions <ul><li>Don't blindly trust open source. Even popular platforms can have vulnerabilities, and if they don't, their plugins/modules might.
  52. 52. Don't trust any user input. GET, POST, COOKIES.etc.
  53. 53. PDO prepare is your friend
  54. 54. Correctly check file extensions
  55. 55. Never give Apache or your MySQL user more permissions than they need
  56. 56. Keep an eye on news regarding new exploits </li></ul>