Defending Web Applications: first-principles- Jason Lam
Upcoming SlideShare
Loading in...5
×
 

Defending Web Applications: first-principles- Jason Lam

on

  • 379 views

 

Statistics

Views

Total Views
379
Slideshare-icon Views on SlideShare
379
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • This screenshot demonstrates the administrative interface login. The URL is http://admin.twitter.com/admin, and there is BASIC authentication scheme (over HTTPS).This screenshot was taken from http://www.nowhereelse.fr/admin-twitter-hacker-19410/
  • This screenshot shows the menu of the twitter administrative interface. This screenshot was taken from http://www.nowhereelse.fr/admin-twitter-hacker-19410/

Defending Web Applications: first-principles- Jason Lam Defending Web Applications: first-principles- Jason Lam Presentation Transcript

  • Defending Web Applications: Going back to the First Principles Presented by Jason Lam Sept 2012 Web App Security - © 2012 SANS
  • CASE 1Web App Security - © 2012 SANS
  • Leaky Website Credit CardDMZ InsideWeb App Security - © 2012 SANS
  • Scenario• Lots of complains from customers about compromised cards• Anti-virus scan is negative• Database storing cards shows no sign of compromise• Upon close inspection, an odd process was found on one of the server• Entry point – Web server Web App Security - © 2012 SANS
  • Step 1 – SQL Injection Credit Card Web App Security - © 2012 SANS
  • Step 1 – SQL Injection• SELECT field FROM table WHERE name = userinput• User input is OR 1 = 1 ;--• User input spills into control structure• User input control the database execution Web App Security - © 2012 SANS
  • Step 2 – Gain OS Access Credit Card Web App Security - © 2012 SANS
  • Step 2 – Gain OS Access• Example - MS SQL Server provides xp_cmdshell()• Execute OS level command on database server• Need to be sa user Web App Security - © 2012 SANS
  • Step 3 – Attack Other Hosts Credit Card Web App Security - © 2012 SANS
  • Step 3 – Attack Other Hosts• Once attacker owns the database server, attacks other hosts• Download tools from Internet – Nmap, Nessus, Metaspolit....• Firewall probably allows outbound access Web App Security - © 2012 SANS
  • Counter Measure Input Filtering• Common mitigation – Filter ; "• More aggressive – Filter SELECT, FROM..... Web App Security - © 2012 SANS
  • (Input Filtering) But.......• What if I dont need to use for attack? – Think of numeric type• What if I need to allow all SQL keywords?• Input Filtering isnt a comprehensive solution Web App Security - © 2012 SANS
  • Counter Measure Parameterized Query• sql = "SELECT field FROM table WHERE name = @userinput"• Then, define @userinput• Database and Platform has a chance to distinguish between user input and control structure Web App Security - © 2012 SANS
  • Counter Measure Limiting Database Access• Databases dont generally surf the Internet• Why allow open access to the Internet? Web App Security - © 2012 SANS
  • Counter Measure Database permission• Reduce the account privilege level on the database• Using dba or sa account for web app is unsafe• Reduce permission level on a table and row basis Web App Security - © 2012 SANS
  • Counter Measure IPS• Intrusion prevention system can detect on tell-tale sign of SQL injection• Can detect irregular access outbound from Database• Need configuration Web App Security - © 2012 SANS
  • (IPS) But.......• What if obfuscation is used?• Eg. Encoding• Does IPS know all of the SQL injection cases?• Does IPS know all the evasion techniques? Web App Security - © 2012 SANS
  • CASE 2Web App Security - © 2012 SANS
  • Twitter• Twitter employee has a Yahoo mail account• Reset the password by answering secret questions• Twitter password in mailbox• Admin interface location easy to guess Web App Security - © 2012 SANS
  • Twitter 2Web App Security - © 2012 SANS
  • Twitter 3Web App Security - © 2012 SANS
  • Web App Security - © 2012 SANS
  • Counter Measure No Password via Email• Password should never be sent via Email• Email stays forever• If you hash, you should NOT have original password Web App Security - © 2012 SANS
  • Counter Measure Isolated Admin Interface• Do not allow "inline" administration• Use a second channel for admin (eg IPSec VPN)• Make admin interface available to internal network only Web App Security - © 2012 SANS
  • CASE 3Web App Security - © 2012 SANS
  • Good VS Evil• Federal government contract firm got website defaced• User registration data from an affiliating website published• CEOs Email posted online• Hacking group known to support Wikileak Web App Security - © 2012 SANS
  • 1st Step - SQL Injectionhttp://www.hbgaryfederal.com/pages.php?pageNav=2&page=27• Use a customized 3rd party CMS system• At mercy of 3rd party patching• SQL injection allows backend database read access Web App Security - © 2012 SANS
  • 2nd Step – Crack Password• CMS system store password in hash• Straight single MD5, no salt• Rainbow Table – pre-computed hash list• CEO & COO used simple passwords Web App Security - © 2012 SANS
  • 3rd Step – Systems Jump• Same username + password on related system• CEO & COO used credentials on multiple systems – Email – Twitter – LinkedIn Web App Security - © 2012 SANS
  • 3rd Step (contd) – SSH Jump• Support website on Linux box, SSH direct access from Internet• COO shared password between sites• SSH accepts password authentication• COO is a regular user (non root) Web App Security - © 2012 SANS
  • Step 4 – Local System Privilege Elevation• Local privilege escalation exploit• Purged data Web App Security - © 2012 SANS
  • Step 5 – Mail Retreival• Google App Mail• CEO account happened to be administrator• Able to access Email for whole organization (thru reset password)• CEO of sister companys Email was accessed• CEOs Email posted online Web App Security - © 2012 SANS
  • Step 6 – Getting Personal• Sister companys CEO also runs a security website with friends• Email revealed another person who has root access to the website• Two potential root passwords• Host is firewalled and does not allow direct root login Web App Security - © 2012 SANS
  • Step 6 (contd) – Getting Personal• Social engineering• Firewall circumvented• SSH password reset (changeme123) Web App Security - © 2012 SANS
  • Step 7 – Revenge At Personal Level• Credential database at the personal security site was stolen• MD5 single pass no salt hash• Site defaced• Credentials of users posted online Web App Security - © 2012 SANS
  • Counter Measure: Unique Complex Password• Do not share password between sites• Use 1Password, KeePass – Password Manager• User education• Rotate password often• Password complexity rule Web App Security - © 2012 SANS
  • Counter Measures: Strong authentication• Use key authentication for SSH• Password + key will be required to login• You may have the password, key is harder to steal Web App Security - © 2012 SANS
  • Counter Measures: Parameterized Query• sql = "SELECT field FROM table WHERE name = @userinput"• Then, define @userinput• Database and Platform has a chance to distinguish between user input and control structure Web App Security - © 2012 SANS
  • Counter Measures: Password Storage• Iterative hash (hashing multiple times)• Salted hash Web App Security - © 2012 SANS
  • Counter Measures: Privilege Account• Avoid using privileged account for day to day operations• Do CEO and COO generally need to be administrators or root?• Segregation of duties Web App Security - © 2012 SANS
  • Questions & Answers Web App Security - © 2012 SANS