1

SilverLine: Preventing Data Leaks from

Compromised Web Applications

Yogesh Mundada Anirudh Ramachandran

Nick 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 prevention devices

Shortcomings No protection against zero day attacks Once compromised, can’t stop data theft

Focus on protecting data, rather than the underlying system

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

DeclassifierProcess

Information FlowTracking Kernel

Webserver Process

SilverLine Architecture1. User sendsLogin request

2. AuthenticateUser

Trusted Realm

Untrusted Realm

Database Table

User-SessionsTable

Connection-Capabilities

Table User Authentication

Module

User-AuthTable

3. Authenticate4. Cookies

5. 5-tuple taints

6. Execute query

12. QueryResults

DatabaseProxy

Process

QueryParser

Process

QueryRegEx Table

Web ApplicationDatabase7

8

9

10

14. SendResponse

15. Check Session Permissions

16. ReturnResponse

Process

Database Node

Authentication Node

Firewall

Server

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

User-ID Name Transact-ID

1 John Smith 100

2 Jane Doe 200

Step #1: Configuration Example

User Table

Transact-ID Transact-no Item

200 37 DVD

200 38 PHONE

100 89 BRUSH

Transaction Table

User-ID Taint

1 ‘A’

2 ‘B’

User-Taint Table

SELECT Name FROM User WHERE User-ID = ‘2’

SELECT Name, Taint FROM User u, User-Taint ut WHERE User-ID = ‘2’ AND u.User-ID = ut.User-ID

SELECT Item FROM Transaction WHERE Transact-ID = ‘200’ and Transact-no=‘37’

Transact-Taint TableTransact-ID Taint

100 ‘A’

200 ‘B’

SELECT Item, Taint FROM Transaction t, Transact-Taint tt WHERE Transact-ID = ‘200’ and Transact-no=‘37’ and t.Transact-ID = tt.Transact-ID

Step #2a: Authenticate User

12

DeclassifierProcess

Information FlowTracking Kernel

Webserver Process

1. User sendsLogin request

2. AuthenticateUser

Trusted Realm

Untrusted Realm

Database Table

User-SessionsTable

Connection-Capabilities

Table User Authentication

Module

User-AuthTable

DatabaseProxy

Process

QueryParser

Process

QueryRegEx Table

Web ApplicationDatabase

Process

Database Node

Authentication Node

Firewall

Server

13

Step #2b: Decide Session Capability

User-Sessions

Table

Connection-Capabilities

Table User Authentication

Module

User-AuthTable

Trusted Realm

Process

Database Tables

2. Authenticate {username, password}

3. Verify &Authenticate

4. Store{Cookie1, User1}

5. Store{SIP:SP-DIP:DP-Prot, Taint1}

4. VerifyCookie

Authentication Node

Step #3: Retrieve Taints with Data

14

DeclassifierProcess

Information FlowTracking Kernel

Webserver Process

1. User sendsLogin request

2. AuthenticateUser

Trusted Realm

Untrusted Realm

Database Table

User-SessionsTable

Connection-Capabilities

Table User Authentication

Module

User-AuthTable

3. Authenticate4. Cookies

5. 5-tuple taints

6. Execute query Database

ProxyProcess

QueryParser

Process

QueryRegEx Table

Web ApplicationDatabase

Process

Database Node

Authentication Node

Firewall

Server

15

Step #3: DB Proxy Operation

DatabaseProxy

Process

QueryParser

Process

QueryRegEx Table

Web ApplicationDatabase

ConnectionTaintsTable

6. Execute query from Webserver

7. Match RegularExpression

8. Parse QueryAnd generateRegular expressions

9. StoreQuery, Taint Query

10. Execute Data + TaintRetrieval Query

11. Store {5-tuple, Taint}

12. Return resultsTo Webserver

Trusted Realm Process Database Tables

16

DatabaseServer

DatabaseProxy

UserID Username SSN

1 Alice 999-99-9999

2 Bob 888-88-8888

UserID Taint

1 0xABCDEF

2 0x123456

user table user_taints table

“SELECT name from user WHERE

UserID=1”

1 Alice 999-99-9999

Taint applied to network

connection0xABCDEF

Data Query

“SELECT name, taint from user u, user-taints ut WHERE

UserID=1 and u.UserID=ut.UserID”

1 Alice 999-99-9999

Modified Query by Proxy

Query Results

Step #3: Apply Taint to Connection

Step #4: Track Data

17

DeclassifierProcess

Information FlowTracking Kernel

Webserver Process

1. User sendsLogin request

2. AuthenticateUser

Trusted Realm

Untrusted Realm

Database Table

User-SessionsTable

Connection-Capabilities

Table User Authentication

Module

User-AuthTable

3. Authenticate4. Cookies

5. 5-tuple taints

6. Execute query

12. QueryResults

DatabaseProxy

Process

QueryParser

Process

QueryRegEx Table

Web ApplicationDatabase7

8

9

10

Process

Database Node

Authentication Node

Firewall

Server

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

Step #5: Declassification

19

DeclassifierProcess

Information FlowTracking Kernel

Webserver Process

1. User sendsLogin request

2. AuthenticateUser

Trusted Realm

Untrusted Realm

Database Table

User-SessionsTable

Connection-Capabilities

Table User Authentication

Module

User-AuthTable

3. Authenticate4. Cookies

5. 5-tuple taints

6. Execute query

12. QueryResults

DatabaseProxy

Process

QueryParser

Process

QueryRegEx Table

Web ApplicationDatabase7

8

9

10

14. SendResponse

15. Check Session Permissions

16. ReturnResponse

Process

Database Node

Authentication Node

Firewall

Server

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

25

Conclusion

• 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

SilverLine: Protect data, rather than the application