Defending Web Applications: first-principles- Jason Lam

Web App Security - © 2012 SANS

Defending Web Applications: Going back

to the First Principles

Presented by Jason LamSept 2012


CASE 1


Leaky Website

InsideDMZ

Credit Card


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


Step 1 – SQL Injection

Credit Card


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


Step 2 – Gain OS Access

Credit Card


Step 2 – Gain OS Access

• Example - MS SQL Server provides xp_cmdshell()

• Execute OS level command on database server

• Need to be 'sa' user


Step 3 – Attack Other Hosts

Credit Card


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


Counter MeasureInput Filtering

• Common mitigation – Filter ' ; "• More aggressive – Filter

SELECT, FROM.....


(Input Filtering) But.......

• What if I don't need to use ' for attack? –Think of numeric type

• What if I need to allow all SQL keywords?

• Input Filtering isn't a comprehensive solution


Counter MeasureParameterized 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


Counter MeasureLimiting Database Access

• Databases don't generally surf the Internet

• Why allow open access to the Internet?


Counter MeasureDatabase 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


Counter MeasureIPS

• Intrusion prevention system can detect on tell-tale sign of SQL injection

• Can detect irregular access outbound from Database

• Need configuration


(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?


CASE 2


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


Twitter 2


Twitter 3



Counter MeasureNo Password via Email

• Password should never be sent via Email

• Email stays forever• If you hash, you should NOT

have original password


Counter MeasureIsolated Admin Interface

• Do not allow "inline" administration

• Use a second channel for admin (eg IPSec VPN)

• Make admin interface available to internal network only


CASE 3


Good VS Evil

• Federal government contract firm got website defaced

• User registration data from an affiliating website published

• CEO's Email posted online• Hacking group known to

support Wikileak


1st Step - SQL Injection

http://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


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


3rd Step – Systems Jump

• Same username + password on related system

• CEO & COO used credentials on multiple systems–Email–Twitter–LinkedIn


3rd Step (cont'd) – 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)


Step 4 – Local System Privilege Elevation

• Local privilege escalation exploit

• Purged data


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 company's Email was

accessed• CEO's Email posted online


Step 6 – Getting Personal

• Sister company's 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


Step 6 (cont'd) – Getting Personal

• Social engineering • Firewall circumvented • SSH password reset (changeme123)


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


Counter Measure: Unique Complex Password

• Do not share password between sites

• Use 1Password, KeePass – Password Manager

• User education• Rotate password often• Password complexity rule


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


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


Counter Measures: Password Storage

• Iterative hash (hashing multiple times)

• Salted hash


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


Questions & Answers

Date post:	18-Nov-2014
Category:	Technology
Upload:	owasp-qatar-chapter
View:	428 times
Download:	0 times

Defending Web Applications: first-principles- Jason Lam

Technology