A brief look at PHP security

1. How secure is your code? Mikee Franklin

3. Working in the industry for 10 years

4. I never finish a personal proj...

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. twitter: @mikeemoo web: www.mikeefranklin.co.uk

8. I love finding things I shouldn't be able to find

9. I like to think I'm doing a 'good thing' if I find (and report) a security hole

10. I don't actually know much about it at all. I've barely scraped the surface of what's possible.

11. I don't “exploit” live websites.

13. If we can run our own code, we can get shell access

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. If not, we can still extract a lot information. Passwords, account details.. etc.. those passwords will often be the same for other sites

17. Check for open /.svn/ folders

18. Have a poke around. Work out what plugins might be installed, check the source of them.

19. Check for known files that might give you the version number of the software. INSTALL, VERSION, LICENCE..etc.

21. Abuse bad extension checking

22. Some servers will execute .php.jpg as a php file – depends on configuration and version(?)

23. You can embed code in image metadata and PHP will still recognise it as a valid image, no matter what the extension.

25. We can run netcat locally and wait for the connection.

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. There's plenty of information out there with databases of exploits (for example, http://www.exploit-db.com)

29. Use local file inclusion to execute the code good example: require $_GET[“file”].”.php”;

30. But what about the .php? Surely that'll only open php files?

31. Using a null character strips off the end, for example: index.php?file=../../../../../../../../../../etc/passwd%00

32. But.. we need to get our code onto the machine first...

34. index.php?file=<?php phpinfo(); ?>

36. We can cycle through /proc/self/fd/[x] as one might be a symlink to our logs

38. The handshake messages from the server will give us a clue to the location of the logs Status: Resolving address of www.mikeefranklin.co.uk Status: Connecting to 65.49.60.84:21... 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

40. We can guess the location of the file

41. Knowing the database name will help us find the path to the database

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. If SQL injection is available, we can use it to retrieve the database path

45. Now we can call.. index.php?file=../../../../../../../../tmp/myfile%00

47. Can extract data we shouldn't be able to get to

48. Can potentially log in as different users

49. Maybe read files off the server

50. Maybe even execute our own code

52. Don't trust any user input. GET, POST, COOKIES.etc.

53. PDO prepare is your friend

54. Correctly check file extensions

55. Never give Apache or your MySQL user more permissions than they need

56. Keep an eye on news regarding new exploits