• Vulnerability: Session Fixation, Reflected XSS, Code Execution
• Affected Software: PivotX
• Affected Version: 2.3.10 (probably also prior versions)
• Patched Version: 2.3.11
• Risk: Medium-High
• Vendor Contacted: 2015-05-27
• Vendor Fix: 2015-06-21
• Public Disclosure: 2015-06-27

• Vulnerability: Persistent XSS
• Affected Software: LimeSurvey
• Affected Version: Version 2.05+ Build 150520 (probably also prior versions)
• Patched Version: Version 2.06+ Build 150618
• Risk: Low-Medium
• Vendor Contacted: 2015-05-27
• Vendor Fix: 2015-06-18
• Public Disclosure: 2015-06-27

• Vulnerability: Reflected XSS
• Affected Software: TinyWebGallery
• Affected Version: 2.3.2 (probably also prior versions)
• Patched Version: 2.3.3
• Risk: Low-Medium
• Vendor Contacted: 2015-05-26
• Vendor Fix: 2015-06-15
• Public Disclosure: 2015-06-27

There is an XSS vulnerability in version 2.3.2 of TinyWebGallery. It is relatively hard to trigger as it requires a double click by an admin (which can be achieved via clickjacking and social engineering), but once triggered, leads to code execution because of the provided file edit functionality.

The vulnerability is unlikely to be exploited in the wild because it requires quite a bit of social engineering; I’m publishing it because it is a nice example of how different small vulnerabilities can come together and lead to arbitrary PHP code execution.

• Vulnerability: Multiple XSS and CSRF
• Affected Software: Beehive Forum
• Affected Version: 1.4.5 (probably also prior versions)
• Patched Version: 1.4.6
• Risk: Medium
• Vendor Contacted: 2015-05-18
• Vendor Fix: 2015-05-30
• Public Disclosure: 2015-06-05

There are multiple XSS and CSRF vulnerabilities in Beehive Forum 1.4.5. Beehive Forum is open source forum software based on PHP.

• Vulnerability: SQL Injection & Reflected XSS
• Affected Software: Visual Form Builder (WordPress Plugin)
• Affected Version: 2.8.2 (probably also prior versions)
• Patched Version: 2.8.3
• Risk: High
• Vendor Contacted: 2015-05-06
• Vendor Fix: 2015-05-09
• Public Disclosure: 2015-05-15

The current version (v2.8.2) of the WordPress plugin Visual Form Builder is vulnerable to reflected XSS as well as SQL injection attacks.

The damage each attack on it’s own can achieve is limited. The SQL injection can lead to data leaks, and possibly priviledge escalation or code execution, but an admin login is required. And as WordPress secures it’s relevant cookies, it’s not possible to gain a login via XSS, it is only possibly to eg display the login page and hope that the admin enters their password or inject a JavaScript keylogger; both mean that an admin doesn’t just have to visit a website, but also has to additionally enter their password somewhere. With XSS, it is also possibly to bypass CSRF, so an attacker could eg change PHP scripts if DISALLOW_FILE_EDIT is false, which hopefully is not the case.

Combined, these attacks get interesting: Via XSS it is possible to let the admin execute the SQL injection, and then send the results to the attacker. The admin only has to click on a link once, and does not have to perform any further actions.

• Vulnerability: Arbitrary File Override & Reflected XSS
• Affected Software: My Calendar (WordPress Plugin)
• Affected Version: 2.3.29 (probably also prior versions)
• Patched Version: 2.3.30
• Risk: Medium
• Vendor Contacted: 2015-05-10
• Vendor Fix: 2015-05-11
• Public Disclosure: 2015-05-15

There is an arbitrary file override vulnerability as well as a reflected XSS vulnerability in the current version (2.3.29) of the My Calendar plugin.

• Vulnerability: Reflected XSS
• Affected Software: Anti-Malware and Brute-Force Security by ELI (WordPress Plugin)
• Affected Version: 4.15.17 (probably also prior versions)
• Patched Version: 4.15.20
• Risk: Medium
• Vendor Contacted: 2015-05-06
• Vendor Fix: 2015-05-09
• Public Disclosure: 2015-05-15

There are multiple reflected XSS vulnerabilities in the current version (4.15.17) of the Anti-Malware and Brute-Force Security by ELI WordPress plugin.

Reflected XSS can lead to execution of arbitrary JavaScript in the victims browser, which can lead to key logging, phishing, stealing of cookies, changing of data, and so on. The fact that these are present in an admin area does not weaken the attack, as the most interesting victim will be an admin.

In this post I will show why anti-CSRF tokens are useless as soon as there is an XSS vulnerability in the target site. This post contains all the example scripts necessary to reproduce bypassing CSRF protection via XSS vulnerabilities. The code is meant for educational purposes only.

• Basic Terms: CSRF and XSS
• PHP CSRF Example Script
• Basic CSRF via POST attack
• Introducing a XSS vulnerability
• Bypass CSRF Protection via XSS
• Bypass CSRF Protection without XSS
• Conclusion on CSRF and the Dangers of XSS
• Mitigation

Basic Terms: CSRF and XSS

CSRF means Cross-Site Request Forgery. The idea is to get a user that is logged in at a website to perform actions on that site they do not actually want to perform. This can be achieved by getting the victim to visit a website (possibly – but not necessarily – owned by the attacker) that contains specially crafted HTML code created by the attacker. CSRF is possible with POST as well as GET requests (although as per REST, GET requests shouldn’t actually change data on the server).

Anti-CSRF token is the recommended way to prevent CSRF. A one time token is stored in the session as well as the form when creating it, and when the form is submitted, the submitted token is compared to the session token. If they match, there is no CSRF attack.

XSS means cross-site scripting, and it allows an attacker to execute arbitrary JavaScript in the victims browser in the context of the vulnerable website.

• Vulnerability: Bypass mod_security to perform SQL injection (login bypass)
• Affected Software: OWASP ModSecurity Core Rule Set
• Affected Version: 2.2.9 (probably also prior versions)
• Patched Version: 3.0.0
• Risk: Low
• Vendor Contacted: 2014-12-07 via mail, 2015-02-18 via github
• Vendor Fix: 2014-12-09 (in dev tree, independent of report)
• Public Disclosure: 2015-02-18 on github

Mod_Security & Core Rule Set

mod_security is an Intrusion Detection System / Web Application Firewall for Apache, IIS, and nginx developed by SpiderLabs. As a filter list it uses the OWASP ModSecurity Core Rule Set.

Injection Payload

Using the Core ModSecurity Rule Set ver.2.2.9 with default configuration, SecRuleEngine On, and all base_rules enabled, it is possible to inject the following payload, which can be used to bypass filters in SQL queries:

foo' or true #
foo' or false #

<p> With a growing code base, it is good to have tools which can automatically find weaknesses in it, be it duplicate code, bad patterns, possible bugs, bad formatting, or bad design. Here are some of the tools that can analyze Java Code. CheckStyle, FindBugs, PMD – Java Static Code Analysis Google CodePro AnalytiX Eclipse Build-In Java Static Code Analysis NetBeans Java Hints – Java Static Code Analysis iSpace – Dependency Graph QJ-Pro: Java Static Code Analysis Lint4j – Java Static Code Analysis SonarQube Further