Update on the Vulnerability Assessment Effort Elisa Heymann

Update on the Vulnerability Assessment Effort Elisa Heymann Computer Architecture and Operating Systems Department Universitat Autònoma de Barcelona Elisa. Heymann@uab. es

EMI: Software to Assess › g. Lite – Argus 1. 2 – g. Lexec 0. 8 – VOMS Core – CREAM: Computing Resource Execution And Management – WMS: Workload Management System 2

EMI: Software to Assess › Unicore – TSI: The Target System Interface – Gateway 3

Current Status › VOMS Admin 2. 0. 18: done! › Java, JSP y javascript › 38 KLOC › 2. 5 months of work 4

Current Status › VOMS Admin 2. 0. 18: done › 2 Critical vulnerabilities › Cross Site Request Forgery attacks => an attacker will be able to execute arbitrary VOMS Admin actions. › Persistent Cross Site Scripting vulnerabilities => nonprivileged users can store javascript code in the database, which will be executed by other users. › 2 Non-critical vulnerabilities › Fields of the web interface that display information about the users certificates are vulnerable to Persistent Cross Site Scripting vulnerabilities. › Reflected Cross Site Scripting vulnerabilities => nonprivileged users can submit javascript code to VOMS Admin, and this code is 5 reflected back to the user browser.

Current Status › g. Lexec 0. 8: done! › C › 13 KLOC › 5 months of work 6

Current Status › g. Lexec 0. 8: done! › 3 Critical vulnerabilities › Lack of cleanup of jobs => allows a prior user of the uid to attack the current user's jobs and files. › Reuse of local uids => attack another job running later. › 1 Non-critical vulnerabilities › A job can prevent the job completed log record from being written to the glexec log. 7

Current Status › Argus 1. 2: done! › Java, C, scripting languages › 42 KLOC › 5 months of work › No vulnerabilities found. › Report on what was assessed and why Argus worked fine. 8

Were are we now › VOMS Core 2. 0. 2: Just started – Vincenzo Ciaschini & Valerio Venturi – C: 30753 – C++: 10138 – exp: 7955 – java: 7754 › Started: May 2011 › Expected duration: 6 months 9

Vulnerability Assessment@EMI Apply FPVA to relevant EMI Middleware – Assess the SW – Generate vulnerability reports A vulnerability is considered only when we produce an exploit for it. 10

First Principles Vulnerability Assessment Understanding the System Step 1: Architectural Analysis – Functionality and structure of the system, major components (modules, threads, processes), communication channels – Interactions among components and with users

Argus 1. 2 Architecture 1 b Admin data-flow auth. Z service Host User (UI) User data-flow 1 a A RB Host Administrator CLI B WMS /etc/init. d/pdp reloadpolicy LRMS F’ /etc/init. d/pepd clearcache Dt Et 9 PDP 8 7 6 PEP Server 4 PAP (Policy Administration Point) → Manage Policies. PDP (Policy Decision Point) → Evaluate Authorization Requests. PEP (Policy Enforcement Point) → Process Client Requests and Responses. 10 b PEP Client (Lib) g. LExec 5 WN job Ft Communications among PAP, PDP, and PEP Server via HTTPS Exit g. LExec 10 a E’ D’ CREAM 3 PAP C’ CE Host Run job HTTPS 2 WN Host PAP Admin Tool (Edit Policy) OS privileges user root batch user External Component Administrator & root

First Principles Vulnerability Assessment Understanding the System Step 2: Resource Identification – Key resources accessed by each component – Operations allowed on those resources Step 3: Trust & Privilege Analysis – How components are protected and who can access them – Privilege level at which each component runs – Trust delegation

Argus 1. 2 Resources auth. Z service Host (PAP Component) PAP bin conf lib repository logs etc/ grid_security TRUSTED_CA sbin host has key signed, pap-admin pap_ authorization. ini certificates logging pap_ configuration. ini XML Policies hostcert. pem Readable Owner World hostkey. pem papdeploy. sh papstandalone. sh OS privileges user root batch user External Component Administrator & root

Argus 1. 2 Resources auth. Z service Host (PDP Component) Repository policy PDP sbin lib conf TRUSTED_CA etc/ grid_security logs host has key signed, env. sh pdpctl. sh pdp. ini logging. xml certificates Readable Owner World hostcert. pem hostkey. pem OS privileges user root batch user External Component Administrator & root

Argus 1. 2 Resources auth. Z service Host (PEP Server Component) PEP Server sbin env. sh pepdctl. sh lib conf pepd. ini Cached Policies TRUSTED_CA etc/ grid_security logs logging. xml host has key signed, certificates grid-mapfile hostcert. pem Readable Owner World hostkey. pem groupmap file gridmapdir vomsdir OS privileges user root batch user External Component Administrator & root

First Principles Vulnerability Assessment Search for Vulnerabilities Step 4: Component Evaluation – Examine critical components in depth – Guide search using: Diagrams from steps 1 -3 Knowledge of vulnerabilities – Helped by Automated scanning tools

First Principles Vulnerability Assessment Taking Actions Step 5: Dissemination of Results – Report vulnerabilities – Interaction with developers – Disclosure of vulnerabilities

Vulnerability Report › One report per vulnerability › Provide enough information for developers to reproduce and suggest mitigations › Written so that a few sections can be removed and the abstracted report is still useful to users without revealing too much information to easily create an attack. 20

Categories of Vulnerabilities › Design Flaws Occur about – Problems inherent in the design equally – Hard to automate discovery › Implementation Bugs – Improper use of the programming language, or of a library API – Localized in the code › Operational vulnerabilities – Configuration or environment › Social Engineering – Valid users tricked into attacking 21

How do You Respond? › Identify a team member to handle vulnerability reports. › Develop a remediation strategy: – Study the vulnerability report. – Use your knowledge of the system to try to identify other places in the code where this might exist. – Study the suggested remdiation and formulate your response. – Get feedback from the assessment team on your fix – very important for the first few vulnerabilities. › Develop a security patch release mechanism. – This mechanism must be separate from your release feature/upgrade releases. – You may have to target patches for more than one version. 22

How do You Respond? Develop a notification strategy: › › › What will you tell and when? Users are nervous during the first reports, but then become your biggest fans. Often a staged process: 1. Announce the vulnerability, without details at the time you release the patch. 2. Release full details after the user community has had a chance to update, perhaps 6 -12 months later. › Open source makes this more complicated! The first release of the patch reveals the details of the vulnerability. 23