Más contenido relacionado La actualidad más candente (20) Similar a Defending Web Applications: first-principles- Jason Lam (20) Más de OWASP-Qatar Chapter (8) Defending Web Applications: first-principles- Jason Lam3. 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
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
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
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
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
Notas del editor 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/