2. or How to Hack
Websites and Prevent
Your Site from Being
Hacked
3. What this is for
• Learn how common exploits are
done and how to identify code
that is vulnerable
• Learn how to fix code that is
susceptible to these attacks
• Learn how to attack your own
code and your own sites so you
can fix them
4. What this is not for
• Hacking or attacking sites
that you do not have
permission to attack
!
• If you don’t have permission,
don’t do it.
5. The Code
• The code I am showing you is
similar to real code I’ve seen in
real projects, but it was written
specifically for this presentation.
6. Gouda Times
• Provided on the VM is a hackable site - The
Gouda Times cheese shop and social
cheese site
7. What you need
• Virtualbox 4.3
• The VM
• A browser (preferably chrome but any
works)
• Something to send HTTP requests to the
server on the VM
8. Getting Started
• Copy the contents of the thumb drive -
• There are 4 files:
• Virtualbox for Mac and Windows
• The VM
• An image
9. Import the VM
• Start the VM in virtual box and log into the console (vagrant /
vagrant)
• ifconfig -a
• Find eth*
• Edit /etc/sysconfig/network-scripts/ifcfg-eth1
• Change DEVICE= to match eth* from above
• sudo service network restart
• mailcatcher —ip=0.0.0.0
10. One note about email
• On the VM is mailcatcher. It will catch any
emails that the system or you cause to be
sent. You can access it at http://
hacksite.dev:1080/
11. To play fair
• Don’t go on the VM after the initial set up.
However, all the code is there and if you
really want to look, feel free:
• /vagrant_web
• Try to figure out some exploits without
looking at the code first though
12. On your host
• Ping 192.168.33.199
• ssh vagrant@192.168.33.199 (password
vagrant)
• If this works, add a host entry (/etc/hosts
or /windws/system32/driver/etc/hosts for
hackingsite.dev to 192.168.33.199
14. Start hacking
• There are loads and loads of vulnerabilities
• If you break the VM, just re-import and start
again
• This is your VM on your computer. Anything
destructive you do is on you. Be sure you’re in
the VM before seeing if
rm -rf /* works
20. Errors can help attackers
• Showing SQL errors can help attackers fix SQL injection
attempts
!
• Other errors can help in other ways (some show
passwords)
!
• Turn off display_errors in production, but log errors
always
21. Blind SQL injection
• Make calls that take
varying amounts of time to
run. Use the time to
determine the answers to
questions about the
systems you are attacking.
22. Blind SQL injection
• http://news.org/news.php?id=5
• http://news.org/news.php?id=5 and 1=1
• http://news.org/news.php?id=5 and 1=2
27. Guessing column names
• news.php?id=11 and (select
substring(concat(1, password),1,1) from
users limit 0,1)=1
28. Guessing data
• news.php?id=4 and
ascii(substring((SELECT concat(username,
0x3a, password) from users limit 0,1),
1,1))>80
!
• Increment to guess values letter by letter
35. So what?
• What if we post code into
$_POST[‘image’]
!
● Steal session cookies
● Call Javascript APIs to cause actions
on the server (CSRF)
● Post forms as the user
43. Why this matters
• Sites identify and authenticate
users with session.
• I have identified myself as you. I
am now logged in as you and
can do anything you can do on
the site.
44. Ok, so I can steal my own
session
• Here’s how to use
it against someone.
45. The first part of the attack
• Create an email to a link on the
attacking site that posts the code to the
site under attack. Send the email to the
victim.
!
• They click the link, you steal their
session.
46. What else can I do?
• Cross Site Request Forgery (CSRF)
• Causing actions to happen on the user’s
behalf
• Purchasing things, changing passwords,
creating accounts, etc.
47. How to prevent?
• Escape output
• Whitelist URLs, domains, input
• Make the print page lookup and use image
paths from a trusted source (database
maybe?)
48. Prevent CSRF
• Use a CSRF token.
• Disallow requests
that don’t contain the
correct token.
51. PHP Web File Browser
• Supposed to allow viewing of files within
the web directories
• $files = shell_exec(‘ls -al ’ .
$_GET[‘dir’]);
52. What’s the danger?
• $_GET[‘dir’] = ‘.; rm -rf / *’;
• Or whatever.
• cat /etc/passwd; cat /etc/shadow
53. How to prevent?
• If you must use user input in a command,
use escapeshellarg()
• $dir = escapeshellarg($_GET[‘dir’]);
• $files = shell_exec(‘ls -al ‘ . $dir);
• Validate that the input is allowed
54. Other types of injection
● Code (eval)
● Regex
● Log
● LDAP
55. Other exploits
● Authentication / Session management
● Information disclosure
● Sensitive data exposure
● File upload flaws
● Unchecked redirects
● Leftover debug code
● Session fixation
● Internal threats
● Privacy Violation (password in logs,
etc)
56. Mitigation
• Validation on the client
• Reject invalid requests entirely, log
intrusion attempt
• Principle of least privilege
• Filter input, escape output
61. Put it together
• Hit pages quickly in this order:
• Login -> forgot password / privileged page
• Privileged page sees ‘user’ and allows
attacker in
62. How was this found?
• By accident, via web crawler getting
access to privileged pages
63. Now what?
• Find as many exploits as possible in
Gouda Times
• Be creative, you can use multiple exploits
in a single creative hack
• Stuck for ideas?
64. Ideas
• Trick the system to give up another user’s
password
• Log in to the system as another user
without knowing their password
• Change guestbook entries
• Remove guestbook entries
65. More ideas
• View nearly any file on the system
• Get your own code onto the system
• Find hidden functionality
• Exploit the site with an image
• Create more users than the system thinks you should
have
• Social engineering - get someone to tell you a password
67. If you have questions or
need help I’ll be around
• If you get a hack to work, let me know and
you can share what you did and how
• If you want to try to fix it, the source is on
the VM - show me your fix, I’ll try to break it
