Embed Size (px)
Citation preview
Non-Invasive Elimination of Logical Access Control
Vulnerabilities in Web Applications
Denis Kolegov, Nikolay TkachenkoNational Research Tomsk State University
Information Security and Cryptography Department
Positive Hack Days V (May 26-27 2015), Moscow
Who We Are?
• Denis Kolegov– PhD, associate professor at Tomsk State University Information
Security and Cryptography Department– Sr. security test engineer at F5 Networks
• Nikolay Tkachenko– Post-graduate student of Information Security and
Cryptography Department at Tomsk State University– Security test engineer at F5 Networks
2
Access Control in Web
• Layers– Presentation layer
– Business layer
– Data access layer
• Attacks– Vertical and horizontal attacks
– Business logic attacks (Abuse workflow)
• Anti-patterns– Security by obscurity
– Hard-coded role checks
– Lack of centralized access control logic
– Order specific operators
– Dependence on client-side data (cookies, hidden fields)3
Typical Web-Based Architecture
4Source: http://rubix.com/cms/app_user_typical
Non-invasiveness of Access Control
5
• Non-invasive implementation should not change existent application logic and its code
• In other words, this is vulnerability mitigation without weakness elimination
• This approach is not new and there are many examples of non-invasive protection mechanisms in WAFs– CSRF– Data Manipulation– Cookies Tampering– Open redirect
• We will consider non-invasive approach to mitigate access control vulnerabilities in modern web applications
Causes and Consequences
6
Vulnerability Attack
Weakness Threat
Insecurity
RiskUnsafety
Vladimir Kochetkov. How to Develop Secure Web Application and State in Mind?
Applicability
7
• Every access to every entity must be checked for authority
• There is no possibility to eliminate access control vulnerabilities in source code
• Access control has not been developed or has flaws
• Implementation overlay access control without source code changes– RBAC on MLS
– ABAC on RBAC
– MLS on DAC
Agenda
• Access control policies and models
• Access control on DBMS layer
• Access control on Web-server layer
• Implementation and proof of concept
8
Access Control Terminology
9
Access Control - Authorization
• Authorization is the process where a system determines if a specific user has access to a particular resource in accordance with given security policy
• The intent of authorization is to ensure that a user only accesses system functionality to which he is entitled
• Complete mediation: Every subject’s access to every object must be checked for authority
10Jim Manico. Web Application Access Control Design
Access Control Policies
• Discretionary Access Control (DAC)– Owner-controlled administration of access rights to entities
• Mandatory Access Control (MAC)– Strict control of information flows– LBAC, TE (DTE), MLS
• Role-based Access Control (RBAC)– Subjects can access entities using assigned roles only– MAC and DAC can be enforced using RBAC
• Attributed-based Access Control (ABAC)
11
MAC
12
• Strict control of access rights and information flows
• Types– TE (DTE)– LBAC (MLS)– Themes-based– Role-based– Mandatory role-based (simulating MAC using RBAC)
• LBAC main requirement : Information must not flow from entity with higher security classification to entity with lower security classification (“top-down”)
MAC Policies
s2file2
s1
writem
write
file1
read
read
Low
High
TE
LBACMLS
13
LBAC policy
• All entities must be identified
• A lattice of security levels is given
• All entities are tagged with security classifications and all subjects are tagged with security clearances
• A subject can access to an entity if and only if– the subject’s security clearance allows to him to access to the
entity with given security classification– this access will not trigger information flow from entities with
higher security classification to entities with lower security classification
14
Weaknesses of Secure DBMS based on BLP-model
15
Weaknesses of BLP model
• Bell-LaPadula model is still the main model for systems with MAC
• Absence of logical connections between model’s requirements– Contradictions do not appear even if to add absurd requirement or
property to model
• Absence of state transition rules– System Z and vulnerability in low-watermark policy
• Absence security rules prevented timing covert channels– «clipboard» covert channel– «hard link» covert channel
• BLP model was created for Multics– Procfs flows
16
Trusted Rubix Rules
• «The simple and static nature of the Bell-LaPadula rules provides the potential for a higher assurance of correctness as compared to more complex and dynamic security policy models»
• «These labels are used along with fixed Bell-LaPadula rules to control operations»
• «In general, Bell-La Padula rules allows subjects to read objects at lower labels and update objects at their label»
17Source: http://rubix.com/cms/sites/default/files/documentation/RX_MLS_White_Paper_6_0.pdf
Fixed BLP-model
• David Bell, Leonard La Padula, “Secure Computer Systems: Mathematical Foundations,” MITRE Corporation, March 1, 1973
• If a subject S is allowed "append" access to an object O, a file or segment, then guaranteeing inviolability of rule W means the system must prevent S from appending information of a classification higher than that of O
• So the subject S can append information to the O if and only if their levels are equal, even if the S is not accessing any other objects
18Source: http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf
Trusted Rubix Rules
19Source: http://rubix.com/cms/sites/default/files/documentation/RX_MLS_White_Paper_6_0.pdf
Oracle OLS Read Access
20Source: https://docs.oracle.com/cd/B19306_01/network.102/b14267/accpriv.htm
Oracle OLS Write Access
21Source: https://docs.oracle.com/cd/B19306_01/network.102/b14267/accpriv.htm
Summary
• Almost all secure DBMSs based on fixed BLP-model
• They do not implement fair LBAC policy in terms domestic computer security (e.g., DP-models)
• There are no formal models for known secure DBMSs
• DBMSs do not provide API for developing custom access control policy
22Source: http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf
Access Control on DBMS Layer
23
Scope
24
• Account-based web applications
• DBMS types– SQL databases (MySQL)– NoSQL systems with REST API (OData, ElasticSearch, Solr)
• Enforcement policy model– Network device (load balancer, WAF, reverse proxy)– Framework module
• Goals– DBMS access control policy enforcement
– Data layer protection
Known Approaches
25
• Rubix Application User
• Oracle Virtual Private Database
• Raw Level Security
• SQL Integrated Access Control
• GreenSQL Database Access Control and Firewall
• Axiomatics Dynamic Authorization
Classification
26
• DBMS-based– Linter– Rubix– Oracle OLS
• Proxy-based– GreenSQL– Axiomatics Data Access Filter
• Kernel-based– PostgreSQL
• Application-based
DBMS Access Control Issues
27
• How to enforce custom access control policy?– Change source code– Change DBMS’s engines– Use SELinux– SQL-query rewriting– Kernel module– New DBMS
• Misunderstanding of MAC conception– Fixed Bell-LaPadula model– Theoretically based LBAC policies usually are not implemented
in known DBMS
DBMS Access Control Issues
28
• The main statement of any access policy: All entities must be identified
• Access control mechanisms are determined by identification capabilities (columns, rows, cells)
• Entities identification in account-based systems: At least it is necessary to identify web application subjects (users) that initiate queries to DBMS
• Row level security can be simulated even if DBMS does not support them
Approach
29
• Proxy-based– We don't change web application and DBMS source code
– All access control rules are implemented on proxy server
– Entities' security attributes (e.g., labels) are stored on proxy
• Access control policy
• Identification: adding user’s identifier to queries– NoSQL REST API system
– SQL database
• Access policy enforcement– Proxy server must provide an API for getting accesses
Entities Identification for REST API
• Network device (WAF) for REST API databases– URL Rewriting
• Databases with REST API– OData– ElasticSearch– Solr
http://services.odata.org/OData/OData.svc/Categories(1)/Products
http://services.odata.org/user/OData/OData.svc/Categories(1)/Products30
BIG-IP MAC iRule
31
Web Server
Load Balancer
Database
ElasticSearchhttp://10.1.1.10:9200
https://examle.com
https://10.1.1.9:443
Web Client
BIG-IP Identification iRule
when HTTP_REQUEST {
set apm_cookie "[HTTP::cookie value LastMRH_Session]"
if {$apm_cookie != "" && ! [ACCESS::session exists $apm_cookie]} {
set user "[ACCESS::session data get session.logon.last.username]"
if { [HTTP::uri] starts_with “elasticsearch" && $user != "" } {
set uri "/${user}[HTTP::uri]"
HTTP::uri $uri
}
}
}
32
NoSQL Systems Access Control
• Ingredients– Reverse proxy, DNAT
– URL rewriting, portal access
– Authentication modules
– iRules – Tcl-based scripting language that allows complete programmatic access to the HTTP flows
• Assign attributes for users– Storage: Local user DB, LDAP, Active Directory, etc.
– Attributes: groups, labels, roles, levels, etc.
• Assign attributes for resources– Data group lists, profiles
• Enforce access control policy using iRules33
Simple MAC Policy
• Checks that user is authenticated
• Retrieves user’s identifier and his classification from session database
• Parse URL and get index’s identifier and its classification
• If user’s classification is great or equal to index’s classification then permit request
• Note: This policy does not require control flow, by definition
34
BIG-IP MAC iRule
when HTTP_REQUEST {
if {[HTTP::uri] starts_with "/elasticsearch"} {
set apm_cookie [HTTP::cookie value LastMRH_Session]
if { $apm_cookie != "" && ! [ACCESS::session exists $apm_cookie] } {
set index [getfield [HTTP::uri] "/" 3]
set indexlabel [class lookup $index "labels"]
set group "[ACCESS::session data get session.localdb.groups]"
if {($group >= $indexlabel) and ($group != "" and $indexlabel != "")} {
HTTP::header replace Host "10.1.1.10:9200“
} else {
HTTP::redirect http://lb.site.com/vdesk/hangup.php3
}
}}}}35
Simulation of LBAC Policy
• An «access» concept in operation systems, classic DBMS and HTTP systems is not the same
• Despite this, it is possible to simulate fair LBAC policies in highly secure HTTP-based databases
• Policy– User can get read or write accesses to any entities in accordance
with their classifications– If user has gotten read access to entity with classification X he
will be able to get write access only to entities with the same classification in this session
36
Entities Identification for SQL
37
• Hybrid (integrated) module for SQL databases– intercepts SQL queries that are generated by each request– finds user’s identifier– adds user’s identifier to SQL query
SELECT name, salary FROM employee
/* user1 */SELECT name, salary FROM employee
Data Operations
• CRUD operations
• Embedded queries – «INSERT INTO … VALUES((SELECT…), …)»– «INSERT … SELECT»– «UPDATE … SET … = (SELECT …)»
• Routines– Triggers– Procedures / Functions
• Cursors
38
Simple Query Flow
• Subject Slow accesses secret data using SELECT query
SELECT * FROM secret
39
secret
Slow
SELECT
HIGH
LOW
writem
Embedded Query Flow
• Subject Shigh implements memory channel using INSERT … SELECT query
– INSERT into shared (data) SELECT secret.data from secret
• Subject Slow can read secret data from table
– SELECT shared.data from shared
40
shigh
shared
select
writem
insert
secret
slow
select insert
nonsecret
HIGH
LOW writem
Cursor Flow
CREATE PROCEDURE flow()BEGIN
DECLARE done INT DEFAULT FALSE; DECLARE a CHAR(32); DECLARE cur1 CURSOR FOR SELECT str FROM test.high; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
OPEN cur1;
read_loop: LOOP FETCH cur1 INTO buf;
IF done THEN LEAVE read_loop; END IF; INSERT INTO test.low VALUES (buf); END LOOP;
CLOSE cur1;
END;41
SQL Database Access Control
42
• On this step we have subject’s identifiers and entities’ identifiers and we can enforce given policy
• Simple queries
• Embedded queries
• Routines– It is more complicated case– SAST
Approach to Data Protection
43
• On this step we have subject’s identity and entities’ identities and we also can try implement data layer protection baseline using additional information
http://app.example.com/viewSalary?id=21312
/* user */SELECT * FROM salary WHERE id = 21312
SELECT * FROM salary WHERE id = 21312 AND name = user
Access Control on Web Server Layer
44
Web Server Access Control Issues
45
• Web application access control layers– Presentational– Business logic– Data access
• Workflow protection– It was shown that almost all frameworks and WAFs do not
provide basic workflow protection
• Authorization flaws– OWASP Top 10 2013: A4-Insecure Direct Object References
Known Approaches
• HMAC token protection is one of the known methods of attack surface reducing is
• Attacks– CSRF– XSS– SQLi– CRLFi
• WAFs– ModSecurity: HMAC Token Protection– F5 Networks ASM: Dynamic Content Value
• This idea can also be used in non-invasive baseline access control mechanisms
46
Authenticator Base String
• Authenticator base string (ABS) is a normalized string, calculated from object’s and subject’s attributes according to security policy
• The ABS includes the following elements of the HTTP request– Parameter names and values
– User’s identifiers (session cookie mandatory should be there)
– Resource’s identifier (URI)
– HTTP request method
– HTTP custom headers
• Encoding and delimiters– BASE64, HEX
– Special characters (# & ; =)
47
• ABS is constructed by concatenating the following HTTP request’s elements according to security policy
auth =
ordered list of parameter names + ";" +
ordered list of pairs (parameter name = value or #) + ";" +
user’s identifier + ";" +
resource’s identifier + ";" +
HTTP method
String Construction
48
Sessionless Protocol
• Parameters– k – server’s master key
– kr – server’s one-time random key
– IDr – resource's identifier
– IDs – user’s identifier
– LP – security policy expressed in a specific language
– time – timestamp– E – encryption function, h – hash function
• All servers share the same master key and there are no data in session
• Protocol actions– Client → Server: initial request from user (IDs) to resource (IDr)
– Client ← Server: response with mac = h(kr, auth, time) and Ek(LP , time, kr)
– Client → Server: final request with IDs’, IDr’, mac’, Ek(LP, time, kr)
49
Sessionful Protocol
• Parameters– k – server’s key
– IDr – resource's identifier
– IDs – user’s identifier
– LP – security policy expressed in a specific language
– time – timestamp– E – encryption function, h – hash function
• Session data– k, time and LP are stored in user’s session
• Protocol actions– Client → Server: initial request from user (IDs) to resource (IDr)
– Client ← Server: response, containing mac = h(k, auth, time)
– Client → Server: final request with IDs’, IDr’, mac’
50
Features
51
• HMAC token mechanism protects against– Access control entities manipulation attacks– CSRF– Replay attacks– Workflow attacks
• Implementation– Hybrid WAFs (ModSecurity)– Network WAFs (BIG-IP ASM)– Modular Frameworks (Django)
HMAC for Cookies
52
• «We are looking into options for adding hmac protection to Cookie data. The trick here is that the data leaving the web app in the Set-Cookie response header is not exactly the same as the data returned in request Cookie headers» (Trustwave SpiderLabs Blog)
• Our students (Oleg Broslavsky and Nikita Oleksov) researched if it’s possible to apply HMAC protection for cookies
Cookie Protection Protocol
• For every controlled cookie C = <key, value, path, domain, expires, secure> we create two special cookies
• WAF_[key] protecting only cookie [key]– Same path and domain– Maximum expires– Value = <controls C[value] and C[expires]>
• WAF_alpha protecting cookies’ scope– Most common path and domain– Maximum expires– Value = <path and domain for each controlled cookie>
53
WAF_[key] Cookie Construction
• Base64(hmac(k, C[value] | C[expires]) | C[expires])
• Properties– It is always sent with original cookie C– C[value] part protects C from modification– C[expires] part protects C from deletion and prolongation– HMAC part protects WAF_C from modification– HMAC secret key should be unique for every user, so it also
protects C and WAF_C from leakage
54
WAF_alpha Construction
• Base64(hmac(k, <values>)|
[C[key]|C[path]|C[domain]|C[secure] for all C])
• Properties– It is sent on every path and domain of web application– It contains key, path, domain and secure flag for every controlled
cookie– Allows to control whether every controlled cookie should or
shouldn’t be sent – HMAC part protects WAF_alpha from modification– HMAC secret key is unique for every user
55
Request processing algorithm
56
Forbid requestForbid request
Mark for deletion all Mark for deletion all controlled cookiescontrolled cookies
Request contains Request contains WAF_alphaWAF_alpha
then else
Process every controlled Process every controlled cookiecookie
HMAC is HMAC is correct correct
thenelse
Mark for deletion controlled Mark for deletion controlled cookies in request that are cookies in request that are missing in WAF_alpha and missing in WAF_alpha and
duplicated cookiesduplicated cookies
Forbid requestForbid request
elseSecure cookie was Secure cookie was sent over secure sent over secure
connectionconnection
Forbid requestForbid request
Domain is Domain is correctcorrect
Cookie processing algorithm
57
Forbid requestForbid requestelse
elsePath is Path is correctcorrect
then
Part I checks whether cookie should be sent to current location using data in WAF_ALPHA
then
then
Cookie processing algorithm
58
Forbid requestForbid request
Forbid requestForbid request
Request contains Request contains WAF_CWAF_C
then else
HMAC is HMAC is correct correct
thenelse
elseExpires and Expires and cookie value cookie value
is correctis correct
Forbid requestForbid request
Cookie is correctCookie is correct
then
Part II checks cookie integrity
Ways to forbid request
59
• When request is incorrect we should decide what to do with this request before passing it to the web application– Drop request
– Redirect to any safe page, e.g. homepage of web application
– Redirect to logout page
– Modify the request and pass it to the web application: delete all incorrect controlled cookies
• Our tool redirects forbidden request to the logout page in sessionful applications and to the safe page in sessionless ones
Advantages and Restrictions
60
• Advantages– Controls cookie integrity– Protects cookie from being deleted– Protects cookie from stealing– Controls whether every controlled cookie should or
shouldn’t be sent
• Restrictions– Requires additional traffic controlled cookies
Control Flow Integrity
61
Workflow
62
• Workflow is used to describe a system in which actions must be performed in a particular order
• In cryptographic workflow given order is achieved by making decryption a privileged action which can only be executed by users which possess an appropriate set of credentials
• There is a common cryptography workflow model based on identity-based cryptography
Counter-based Protocol
63
• Simple counter-based protocol for linear workflow
• Parameters– k - key
– url1, ..., urln – URLs
– mac1, ..., macn – attributes for access to URL and mac1=""
• Protocol actions– Client → Server: request to resource urli, maci
– Server checks that maci = F(k, i, urli), i=i+1
– Client ← Server: response with maci= F(k, i, urli)
Queue-based Protocol
64
• Simple queue-based protocol for linear workflow
• Parameters– k1, ..., kn - keys
– url1, ..., urln – URLs
– mac1, ..., macn – attributes for access to URL and mac1=""
• Protocol actions– Client → Server: request to resource urli, maci
– Server checks that maci = F(ki, urli), i=i+1
– Client ← Server: response with maci= F(ki, urli)
Implementation of MAC for DBMS MySQL and web framework Django
65
Architecture
66
MySQL Proxy
• The MySQL Proxy is an application that communicates over the network using the MySQL network protocol and provides communication between one or more MySQL servers and one or more MySQL clients
• Advantages– LUA interpreter
– Tokenizer
– Parser
67
MAC policy
• Labels– Positive number
• Domain and Types– LOAD XML– CALL procedure/function– LOAD DATA INFILE
• Hierarchy on DBMS entities
68
MySQL Proxy
69
Execution Flow
70
Identification
• Tagged SQL query example– /* USER_ID */ SELECT * from DB.TABLE;
• SQL execution– Cursor– Model / Manager
• Django DB backends–DatabaseWrapper–CursorWrapper
71
Identification
72
SQL Query Rewrite
73
• Problems– One account to work with DBMS– Some DBMSs do not support row level security
• In some cases these problems together with weaknesses in access control of the web application can lead to the unauthorized access vulnerabilities
• Injection points examples– SELECT .. WHERE <Statement>– SELECT .. LEFT / RIGHT / INNER JOIN .. ON <Statement> /
USING .. WHERE <Statement>
SQL Query Rewrite
• Column with identifiers in protected table
SELECT title from Order
SELECT title from Order WHERE username=`USER_ID`
74
SQL Query Rewrite
• Column with identifier can be found in other table and mapped to the column with primary keys of protected table
SELECT title from Order
SELECT title FROM Order WHERE id IN (SELECT o.id FROM Order_auth_user as o, auth_user as a WHERE o.Id_auth_user=a.id and a.username=`USER_ID`)
75
SQL Query Rewrite
76
Resources
77
• Jim Manico. Web Application Access Control Design
• Vladimir Kochetkov. How to Develop a Secure Web Application and State in Mind?
• Bastian Braun, Christian v. Pollak, and Joachim Posegga. A Survey on Control-Flow Integrity Means in Web Application Frameworks
