Stoneware WebNetwork6 Vulnerability Assessment Conducted by: * Leland Public Schools (Stoneware Customer) * Jacob Holcomb (Network Engineer for LPS) Conducted for: * Leland Public Schools (Purchaser of WebNetwork product. Test was to assure cloud security) * Stoneware INC. (Discovered Zero Day vulnerabilities reported to support in 11/2011 & 12/2011) Date(s) Conducted: * 11/2011 – Started initial Web application penetration testing * 12/29/2011 – Started testing of Stoneware’s beta SP8 patch to resolve zero day vulnerabilities - Executive Summary The following reports details the findings from the security assessment performed by Jacob Holcomb of Leland Public Schools for the clients listed in the “Conducted for” heading. -Web Vulnerability Assessment- Deficiencies Noted The following findings were discovered, noted, and reported during the web application assessment. * WebNetwork6: o Six stored Cross Site Scripting (XSS) Zero Day vulnerabilities discovered in the WebNetwork6 product. o One Cross Site Request Forgery (CSRF) Zero Day vulnerabilities discovered in the WebNetwork6 product. Overall Summary The web application penetration test uncovered several deficiencies in the security structure of the WebNetwork6 private/hybrid cloud solution. - Findings and Recommendations The following Zero Day findings were discovered and disclosed through manual testing and were not disclosed by an automated web application security scanner (Such as Nessus, Acunetix, etc). Recommendations to correct the issues are based off of web development best practices according to OWASP (Open Web Application Security Project) and do not reflect the changes implemented by Stoneware INC. to address the security concerns in the WebNetwork6 product outlined in this document. Please see the section titled “Vendors solution to the problem” for a full comprehensive list of the actions taken to resolve the reported issues. -WebNetwork6 Vulnerability Findings- * XSS threats found. Input supplied by the user is not properly validated and sanitized by the Web Server application code prior to submitting the data for processing in multiple parts of the WebNetwork6 application. o This flaw in business programming logic allows malicious users to use the Cross Site Scripting attack vector to submit and store executable code on the server hosting WebNetwork that will be executed in a users browser. o XSS flaws occur when an application includes user-supplied input in a webpage that is sent to the browser without first properly validating or escaping (Sanitizing) that content. o Cross Site Scripting allows an attacker to execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, etc. * CSRF threat found. Requests sent to the Web Server application do not contain any sort of unique identifier that is tied to the users session. o This flaw in business programming logic allows malicious users to use the Cross Site Request Forgery attack vector to submit a falsified HTTP request to the server and initiate a state change of user data/information on the server. o Cross Site Request Forgery (CSRF) takes advantage of a web applications logic and allows attackers to predict all the details of a particular action. Browsers send session ID’s (cookies) for the requested website automatically when requesting that site, so an attacker can create a malicious web page, HTML post, or e-mail which then generates a forged request indistinguishable from the legitimate request and gets submitted to the server for processing. o Malicious hackers can cause victims (Administrator or lesser privileged users) to change any data the victim is allowed to change or perform any action the victim is authorized to use. The user must be logged in for this attack to work. o The CSRF can be exploited via the XSS attack vector as well using HTML GET request versus HTML POST request. -Common Vulnerabilities and Exposure (CVE)- The Common Vulnerabilities and Exposures (CVE) project has assigned the following CVE’s to the issues outlined in this web application penetration test report. * CVE-2012-0285 – XSS * CVE-2012-0286 - CSRF -WebNetwork6 Vulnerability Solutions- * XSS o All untrusted data (user data) should be properly escaped (Sanitized) based on the HTML context that the data is going to be placed into. o Validate ALL input. If input is encoded, decode it, and then validate the length, type, characters, and format of the data being passed as input. * CSRF o To prevent CSRF the web server application should include an unpredictable synchronizer token that is unique for each HTTP request made or per user session. o The preferred option is to include the unique token in a hidden field. This will never reveal the value in the URL and is put into the body of the HTTP request being sent to the server for processing o The synchronizer token can also be placed in the URL itself as a URL parameter. Doing so is not recommended as it divulges this information to an attacker. CSRF Exploitation: In the following example we use CSRF to forge a HTTP POST request that will update or configure a users alternate e-mail, password reset questions, and password reset question answers. The user must be logged in for CSRF to work. Exploited URL: https://NameOfServer/apps/selfService/resetPasswordOptions.jsp HTML code for forged POST request: