This document discusses three cases of web application security breaches and the countermeasures that could have prevented them. Case 1 describes an SQL injection attack that allowed access to credit card data. Parameterized queries and limiting database access could have prevented it. Case 2 involves compromising a Twitter account by guessing password reset questions, demonstrating the risk of sending passwords via email. Isolating admin interfaces could help. Case 3 details how stolen credentials were used across multiple sites due to weak passwords, ultimately compromising personal accounts. Unique, strong passwords and multi-factor authentication are recommended.

1. Defending Web Applications:
Going back to the First
Principles
Presented by Jason Lam
Sept 2012
Web App Security - © 2012 SANS

2. CASE 1
Web App Security - © 2012 SANS

3. Leaky Website
Credit
Card
DMZ Inside
Web App Security - © 2012 SANS

4. 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

5. Step 1 – SQL Injection
Credit
Card
Web App Security - © 2012 SANS

6. 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

7. Step 2 – Gain OS Access
Credit
Card
Web App Security - © 2012 SANS

8. 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

9. Step 3 – Attack Other Hosts
Credit
Card
Web App Security - © 2012 SANS

10. 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

11. Counter Measure
Input Filtering
• Common mitigation – Filter ' ; "
• More aggressive – Filter SELECT,
FROM.....
Web App Security - © 2012 SANS

12. (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
Web App Security - © 2012 SANS

13. 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

14. Counter Measure
Limiting Database Access
• Databases don't generally surf the
Internet
• Why allow open access to the
Internet?
Web App Security - © 2012 SANS

15. 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

16. 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

17. (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

18. CASE 2
Web App Security - © 2012 SANS

19. 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

20. Twitter 2
Web App Security - © 2012 SANS

21. Twitter 3
Web App Security - © 2012 SANS

22. Web App Security - © 2012 SANS

23. 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

24. 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

25. CASE 3
Web App Security - © 2012 SANS

26. 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
Web App Security - © 2012 SANS

27. 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
Web App Security - © 2012 SANS

28. 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

29. 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

30. 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)
Web App Security - © 2012 SANS

31. Step 4 – Local System
Privilege Elevation
• Local privilege escalation exploit
• Purged data
Web App Security - © 2012 SANS

32. 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
Web App Security - © 2012 SANS

33. 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
Web App Security - © 2012 SANS

34. Step 6 (cont'd) – Getting
Personal
• Social engineering
• Firewall circumvented
• SSH password reset
(changeme123)
Web App Security - © 2012 SANS

35. 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

36. 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

37. 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

38. 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

39. Counter Measures: Password
Storage
• Iterative hash (hashing multiple
times)
• Salted hash
Web App Security - © 2012 SANS

40. 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

41. Questions & Answers
Web App Security - © 2012 SANS