1 / 24

SilverLine: Preventing Data Leaks from Compromised Web Applications

SilverLine: Preventing Data Leaks from Compromised Web Applications. Yogesh Mundada Anirudh Ramachandran Nick Feamster Georgia Tech. Appeared in Annual Computer Security Applications Conference (ACSAC) 2013. Data Breach Incidents. Sony Data Breach (SQL Injection, 2011)

aelwen
Download Presentation

SilverLine: Preventing Data Leaks from Compromised Web Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SilverLine: Preventing Data Leaks fromCompromised Web Applications YogeshMundadaAnirudhRamachandranNick FeamsterGeorgia Tech Appeared in Annual Computer Security Applications Conference (ACSAC) 2013

  2. Data Breach Incidents • Sony Data Breach (SQL Injection, 2011) • Citibank (Web application vulnerability, 2012) • Twitter (2013) • Adobe (2013) 90% of the data leakages occur at server. 95% of those leaks are from external attacks.

  3. Common Server-Side Vulnerabilities • Injection Attacks • Broken Authentication and Session Management • Insecure Direct Object References • Security Misconfiguration • Vulnerable Components and Libraries (Open Web Application Security Project)

  4. Current Protection Mechanisms • Penetration testing • Automated code review • Application firewalls • Data loss preventiondevices • Shortcomings • No protection against zero day attacks • Once compromised, can’t stop data theft • Focus on protecting data,rather than the underlyingsystem

  5. Design Goals • Security: Decouple data protection from the application • Deployment: Minimize changes to existing applications • Performance: Minimize overhead

  6. SilverLine Design Non-Goals • Kernel-level vulnerabilities • Covert channels • Malicious software on the database • Inside threats • Data modification attacks

  7. SilverLine Overview Step #1: Tag Sensitive Data Step #2: Associate User with Session Step #3: Retrieve Data with Taints Step #4: Track Data Step #5: Declassify Response

  8. SilverLine Components • Authentication Module • Database Proxy • Information Flow Monitor • Declassifier

  9. SilverLine Architecture 1. User sends Login request 6. Execute query Trusted Realm Webserver Process Database Proxy Process 10 Untrusted Realm 16. Return Response 14. Send Response Process Database Table 12. Query Results Web Application Database 8 7 Server Query Parser Process Declassifier Process Query RegEx Table Information Flow Tracking Kernel 9 Firewall Database Node 2. Authenticate User 15. Check Session Permissions Connection-Capabilities Table 4. Cookies User Authentication Module 3. Authenticate User-Auth Table User-Sessions Table 5. 5-tuple taints Authentication Node

  10. Step #1: Initial Configuration • Indentify and mark sensitive tables • Find unique user key • Find foreign keys • Find table groups • Find tables to monitor for insert query • Create taint-storage tables in each group

  11. Step #1: Configuration Example User Table User-Taint Table Transaction Table Transact-Taint Table SELECT Name FROM User WHERE User-ID = ‘2’ SELECT Item FROM Transaction WHERE Transact-ID = ‘200’ and Transact-no=‘37’ SELECT Item, Taint FROM Transaction t, Transact-Taint tt WHERE Transact-ID = ‘200’ and Transact-no=‘37’ and t.Transact-ID = tt.Transact-ID SELECT Name, Taint FROM User u, User-Taint ut WHERE User-ID = ‘2’ AND u.User-ID = ut.User-ID

  12. Step #2a: Authenticate User 1. User sends Login request Trusted Realm Webserver Process Database Proxy Process Untrusted Realm Process Database Table Web Application Database Server Query Parser Process Declassifier Process Query RegEx Table Information Flow Tracking Kernel Firewall Database Node 2. Authenticate User Connection-Capabilities Table User Authentication Module User-Auth Table User-Sessions Table Authentication Node

  13. Step #2b: Decide Session Capability Trusted Realm 2. Authenticate {username, password} Process 5. Store {SIP:SP-DIP:DP-Prot, Taint1} Connection-Capabilities Table Database Tables User Authentication Module User-Auth Table 3. Verify & Authenticate User-Sessions Table 4. Store {Cookie1, User1} 4. Verify Cookie Authentication Node

  14. Step #3: Retrieve Taints with Data 1. User sends Login request 6. Execute query Trusted Realm Webserver Process Database Proxy Process Untrusted Realm Process Database Table Web Application Database Server Query Parser Process Declassifier Process Query RegEx Table Information Flow Tracking Kernel Firewall Database Node 2. Authenticate User Connection-Capabilities Table 4. Cookies User Authentication Module 3. Authenticate User-Auth Table User-Sessions Table 5. 5-tuple taints Authentication Node

  15. Step #3: DB Proxy Operation Trusted Realm 6. Execute query from Webserver Database Proxy Process 10. Execute Data + Taint Retrieval Query Process 12. Return results To Webserver Web Application Database 8. Parse Query And generate Regular expressions 11. Store {5-tuple, Taint} 7. Match Regular Expression Query Parser Process ConnectionTaints Table Query RegEx Table 9. Store Query, Taint Query Database Tables

  16. Step #3: Apply Taint to Connection Database Server user table user_taintstable Modified Query by Proxy Data Query “SELECT name, taint from user u, user-taints utWHEREUserID=1 and u.UserID=ut.UserID” Database Proxy “SELECT name from user WHEREUserID=1” Taint applied to network connection Query Results

  17. Step #4: Track Data 1. User sends Login request 6. Execute query Trusted Realm Webserver Process Database Proxy Process 10 Untrusted Realm Process Database Table 12. Query Results Web Application Database 8 7 Server Query Parser Process Declassifier Process Query RegEx Table Information Flow Tracking Kernel 9 Firewall Database Node 2. Authenticate User Connection-Capabilities Table 4. Cookies User Authentication Module 3. Authenticate User-Auth Table User-Sessions Table 5. 5-tuple taints Authentication Node

  18. Step #4: Information Flow Tracking • Per-process taint records • Monitors system calls • IPC {send, shmat, kill}, • File/Device operations {read, unlink}, • Process management {fork, execve}, • Memory {mmap}, • Kernel configuration{sysctl} • Taint transfer with information exchange • Network database “connection-taints” to transfer taints across machines

  19. Step #5: Declassification 1. User sends Login request 6. Execute query Trusted Realm Webserver Process Database Proxy Process 10 Untrusted Realm 16. Return Response 14. Send Response Database Table Process 12. Query Results Web Application Database 8 7 Server Query Parser Process Declassifier Process Query RegEx Table Information Flow Tracking Kernel 9 Firewall Database Node 2. Authenticate User 15. Check Session Permissions Connection-Capabilities Table 4. Cookies User Authentication Module 3. Authenticate User-Auth Table User-Sessions Table 5. 5-tuple taints Authentication Node

  20. Implementation • 60 lines in OSCommerce • Information Flow Control • 8,000 lines of ‘C’ Linux kernel code • Redis key-value store • User-Session • Connection-Capabilities • Connection-Taints • Taint-Policy • Database proxy • 350 lines of Lua code

  21. Implementation • Configuration • Identify primary keys • Table groups • Foreign key relationship • Insert query monitoring for each group • In OSCommerce application: Out of 50 tables, 15 were sensitive • Tables were grouped in sets of 9, 5 and 1 • In all we needed 3 taint-storage tables

  22. Evaluation • File fetch (small: 7%, large: 1%) • Scalability: • Login slowdown (21%) • User session slowdown (30%)

  23. Related Work • Data Isolation • CLAMP, Nemesis • CryptDB • Information Flow Control • HiStar, Dstar, Asbestos, Flume • Language-level Taint Tracking • RESIN, Guardrails, PHPAspis, DBTaint • Full-system Taint Tracking • TaintDroid, Neon, Panorama

  24. Conclusion • SilverLine: Protect data, rather than the application • Prevent exfiltration of sensitive data, even if the application is compromised • Information flow: associate data with taints, only allow authorized user sessions to access • Very little modification to existing applications • Overhead is about 20–30% over unmodified applications

More Related