1 / 22

Update on the Vulnerability Assessment Effort

Update on the Vulnerability Assessment Effort. Elisa Heymann Computer Architecture and Operating Systems Department Universitat Aut ònoma de Barcelona Elisa.Heymann@uab.es. 1. EMI: Software to Assess. gLite Argus 1.2 gLexec 0.8 VOMS Core

akando
Download Presentation

Update on the Vulnerability Assessment Effort

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. Update on the Vulnerability Assessment Effort Elisa Heymann Computer Architecture andOperating Systems Department UniversitatAutònoma de Barcelona Elisa.Heymann@uab.es 1

  2. 2 EMI: Software to Assess • gLite • Argus 1.2 • gLexec 0.8 • VOMS Core • CREAM: Computing Resource Execution And Management • WMS: Workload Management System

  3. 3 EMI: Software to Assess • Unicore • TSI: The Target System Interface • Gateway

  4. 4 Current Status • VOMS Admin 2.0.18: done! • Java, JSP y javascript • 38 KLOC • 2.5 months of work

  5. 5 Current Status • VOMS Admin 2.0.18: done • 2 Criticalvulnerabilities • Cross Site Request Forgery attacks => an attacker will be able to execute arbitrary VOMS Admin actions. • Persistent Cross Site Scripting vulnerabilities => non-privileged users can store javascript code in the database, which will be executed by other users. • 2 Non-criticalvulnerabilities • 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 => non-privileged users can submit javascript code to VOMS Admin, and this code is reflected back to the user browser.

  6. 6 Current Status • gLexec 0.8: done! • C • 13 KLOC • 5 months of work

  7. 7 Current Status • gLexec 0.8: done! • 3 Criticalvulnerabilities • Lack of cleanup of jobs => allows a prior user of the uid to attack the current user's jobs and files. • Reuseof local uids=> attackanotherjobrunninglater. • 1 Non-criticalvulnerabilities • A job can prevent the job completed log record from being written to the glexeclog.

  8. 8 Current Status • Argus 1.2: done! • Java, C, scripting languages • 42 KLOC • 5months of work • No vulnerabilitiesfound. • Reportonwhatwasassessed and whyArgusworked fine.

  9. 9 Were are we now • VOMS Core 2.0.2:Just started • VincenzoCiaschini & ValerioVenturi • C:     30753 • C++:     10138 • exp:         7955 • java:         7754 • Started: May 2011 • Expected duration: 6 months

  10. 10 VulnerabilityAssessment@EMI Apply FPVA to relevant EMI Middleware • Assessthe SW • Generatevulnerabilityreports A vulnerabilityisconsideredonlywhenwe produce anexploitforit.

  11. First Principles Vulnerability AssessmentUnderstanding 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

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

  13. First Principles Vulnerability AssessmentUnderstanding 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

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

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

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

  17. First Principles Vulnerability AssessmentSearch 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

  18. First Principles Vulnerability AssessmentTaking Actions Step 5: Dissemination of Results • Report vulnerabilities • Interaction with developers • Disclosure of vulnerabilities

  19. 20 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. 21 Occur about equally Categories of Vulnerabilities • Design Flaws • Problems inherent in the design • 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: • Announce the vulnerability, without details at the time you release the patch. • 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.

More Related