Database Security Using White-Hat Google Hacking

Session Outline:

What is Google Hacking?

• How to do it
• How to use/automate it without violating Google’s TOS

SQL Injection

• search for inurl: “page” or “id” (i.e., knowledge bases, blog software, bug tracking software) or forms on a page
• very manual process, but with metadata knowledge of DBs, very effective
• validate/scrub input, only allow needed characters (i.e., cast page or id as int in code before using in SQL query)
• use prepared statements when possible

Cross-Site Request Forgery

• unlike SQL injection, CSRF uses completely valid requests
• search for inurl: “delete”
• can make harder with POST instead of GET
• can avoid with referer checking (hackable) or validation tokens (for site and for permission—do not think “if they got to this page they can execute the code”—re-validate if necessary)

Cross-Site Scripting

• search for a FORM TEXTAREA or such, and try to inject code (a malicious hacker likely wouldn’t use this approach, but Google search is likely better at finding everything on your site(s) than a person)
• validate/scrub input (disallow < and > )
• use prepared statements when possible

3rd Party Code & Gateway (Including App/Web Server) Vulnerabilities

• search for “powered by”
• search for common paths (”/wp-admin”)
• search for inurl:port (i.e., 8987 = sawmill)
• open source makes these more known; double-edged sword

Social Engineering

• use Google to find out information, then use it against someone
• a login or cookie may not be enough

Minimize Impact

• you will be hacked
• the gateway needs DB passwords to be an effective gateway, but if the gateway is hacked the DB password is easily attainable, your database’s security has been breached
• defense in depth

Patch

• Google Search for <software> sql injection vulnerability advisory security announcement, i.e., “wordpress sql injection vulnerability advisory security announcement”
• Get on security mailing lists for all 3rd party software
• Check out previous vulnerabilities and make sure they don’t work; automate for regression testing

Forensics

• Audit your databases
• Assume nothing (i.e., if apache is hacked, don’t assume it’s because it’s an old version of apache, it may be 3rd party software that gives a webserver exploit)
• How to find where a known breach occurred
• How to find breaches you did not know about, i.e., http://pauldotcom.com/wiki/index.php/Episode81# Tech_Segment:_Google_Queries_To_Run_Against_Your_Own_Domain

Tools

• sqlmap, absinthe, bsqlbf 1.1, SQLBrute, sqlget, SQLiX, SQL Power Injector, Priamos: schema mappers/data grabbers using automated [some blind] SQL injection
• pixy: detection of SQL injection and XSS vulnerabilities in PHP source code
• Wapiti, w3af: Black-box testing for web applications
• SPIKE Proxy (http and https), Wfuzz, Sandcat, XSS Shell, Odysseus: for white-hat hacking
• FG-Injector Framework, BobCat, JBroFuzz: find SQL injection vulnerabilities
• SQL Injection Cheatsheet: http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/