WordPress (WP) is a free and open source CMS for managing a website, blog, and other content on the Internet that was first released on May 27, 2003. Today, WordPress is used on over 75 million sites and is still based on PHP and MySQL and can either be installed on a web server or used though a WordPress hosting service like wordpress.com.One of the biggest attractions is the ease of creating new posts after WordPress has been installed without having to know a lot about HTML. Also, WordPress has a great community and thousands of themes, plugins, and is available in many languages.
This advisory reveals details of exploitation of the PHPMailer vulnerability (CVE-2016-10033) in WordPress Core which (contrary to what was believed and announced by WordPress security team) was affected by the vulnerability.
The Remote Code Execution attack could be used by unauthenticated remote attackers to gain instant access to the target server on which a vulnerable WordPress core version was installed in its default configuration which could lead to a full compromise of the target application server. No plugins or non-standard settings are required to exploit the vulnerability.
This advisory reveals new exploitation vectors for PHP mail() function discovered by the author that allow to exploit the vulnerability on a most popular MTA (Mail Transfer Agent) – Exim which can be found installed by default on many system such as Debian or Ubuntu, as opposed to rarely used Sendmail MTA that has been thought to be a requirement for mail() injection attacks to date.
Due to critical severity of this vulnerability, the disclosure of new exploitation vectors that increase the range of this type of attacks, and the ease of mass exploitation, the release of this advisory was delayed by an extended period of time to allow WordPress and other potentially affected software vendors enough time to update affected mail libraries. The release was also delayed to allow WordPress team more time for patching another WordPress vulnerability (CVE-2017-8295) which will be described in detail in a separate advisory shortly.
More info, visit here.
Now, you can use Metasploit to exploit this vulnerability.
Update your Metasploit Frameworkapt-get update && apt-get upgrade
By Govind Sarda (Vulnerability Research)
The Apache Struts framework is useful for building modern Java-based web applications, with two major versions, Apache Struts 1 and Apache Struts 2, released so far. Support for Apache Struts 1 ended in 2008 with the adoption of Apache Struts 2, which reached its first full release at the start of 2007. A Struts 1 plugin is available that allows developer to use existing Struts 1 Actions and ActionForms in Struts 2 web applications. A vulnerability has been found in this plugin that could allow remote code execution on the affected server, if used with Struts 2.3.x. (Versions 2.5.x are not affected.)
Previous incidents have shown that remote code execution (RCE) vulnerabilities in Apache Struts used Object Graph Navigation Language (OGNL) expressions. The use of OGNL makes it easy to execute arbitrary code remotely because Apache Struts uses it for most of its processes. A recently disclosed Struts vulnerability, CVE-2017-9791 (covered in S2-048) also uses OGNL expressions for Remote Code Execution.
For a remote code execution to be successful, the attacker needs to send a specially crafted request with a malicious value in the vulnerable parameter to the vulnerable server, which is using the Struts 2 – Struts 1 plugin and a Struts 1 action with the value part of a message being presented to the user. An example of this is when an untrusted input value is used as a part of the error message in the ActionMessage class.
The attacker can then send malicious code in the HTTP request or body as a parameter value that will be run on the targeted server hosting a vulnerable application. A proof of concept that demonstrates the attack scenario is publicly available.
When one looks at the solution provided by the vendor, it clearly mentions to always use resource keys instead of passing a raw message to the ActionMessage, as shown below:
messages.add(“msg”, new ActionMessage(“struts1.gangsterAdded”, gform.getName()));
A raw value should never be passed, as in the example below:
messages.add(“msg”, new ActionMessage(“Gangster ” + gform.getName() + ” was added”));
The Struts Showcase app is an example of a web application that does the above. This comes with the Struts 2.3.x series, and it also used the Struts 1 plugin—specifically, in the integration of struts2-showcase under the SaveGangsterAction class execute method (located in the SaveGangsterAction.java file).
This method pulls a user-controlled parameter value directly from gform.getName() into the message structure. The value picked by gform.getName() is not sanitized before it is passed on to different methods and since it is user controlled, OGNL expressions can be embedded in it. A call to getText(msg.getKey () …) is also made, which is able to execute the OGNL expression from subsequent calls to different methods in its implementation.
Apache Struts versions 2.3.x with Struts 1 plugin and Struts 1 action are reported to be Vulnerable. If you are using such configuration, to fix this issue, the vendor has suggested always using resource keys instead of passing a raw message to the ActionMessage or use Apache Struts 2.5.x series.
Trend Micro Solutions
Trend Micro™ Deep Security™ protects endpoints from threats that exploit vulnerabilities.
Deep Security™ provides protection from any threats that may target this vulnerability via the following DPI rule:
1008490 – Apache Struts2 Struts 1 Plugin Showcase Remote Code Execution Vulnerability (CVE-2017-9791)
TippingPoint has posted a Customer Shield Writer (CSW) file for this vulnerability that are available for customers to download on TMC. The applicable rules are as follows:
C000001: HTTP: Apache Struts 2 Struts1 Plugin Code Execution Vulnerability
C000002: HTTP: Struts 2 Struts 1 SaveGanster.action Showcase Site Access
C000003: HTTP: Apache Struts 2 Suspicious opensymphony Actions
C000004: HTTP: Apache Struts 2 Echo Command Usage
Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code, but it does complement the security code review process. The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning. This, combined with the documentation produced as part of the threat modeling process, can give the reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point. The concept of threat modeling is not new but there has been a clear mindset change in recent years. Modern threat modeling looks at a system from a potential attacker's perspective, as opposed to a defender's viewpoint. Microsoft have been strong advocates of the process over the past number of years. They have made threat modeling a core component of their SDLC, which they claim to be one of the reasons for the increased security of their products in recent years.
When source code analysis is performed outside the SDLC, such as on existing applications, the results of the threat modeling help in reducing the complexity of the source code analysis by promoting an in-depth first approach vs. breadth first approach. Instead of reviewing all source code with equal focus, you can prioritize the security code review of components whose threat modeling has ranked with high risk threats.
The threat modeling process can be decomposed into 3 high level steps:
Step 1: Decompose the Application. The first step in the threat modeling process is concerned with gaining an understanding of the application and how it interacts with external entities. This involves creating use-cases to understand how the application is used, identifying entry points to see where a potential attacker could interact with the application, identifying assets i.e. items/areas that the attacker would be interested in, and identifying trust levels which represent the access rights that the application will grant to external entities. This information is documented in the Threat Model document and it is also used to produce data flow diagrams (DFDs) for the application. The DFDs show the different paths through the system, highlighting the privilege boundaries.
Step 2: Determine and rank threats. Critical to the identification of threats is using a threat categorization methodology. A threat categorization such as STRIDE can be used, or the Application Security Frame (ASF) that defines threat categories such as Auditing & Logging, Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation, Exception Management. The goal of the threat categorization is to help identify threats both from the attacker (STRIDE) and the defensive perspective (ASF). DFDs produced in step 1 help to identify the potential threat targets from the attacker's perspective, such as data sources, processes, data flows, and interactions with users. These threats can be identified further as the roots for threat trees; there is one tree for each threat goal. From the defensive perspective, ASF categorization helps to identify the threats as weaknesses of security controls for such threats. Common threat-lists with examples can help in the identification of such threats. Use and abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. The determination of the security risk for each threat can be determined using a value-based risk model such as DREAD or a less subjective qualitative risk model based upon general risk factors (e.g. likelihood and impact).
Step 3: Determine countermeasures and mitigation. A lack of protection against a threat might indicate a vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure. Such countermeasures can be identified using threat-countermeasure mapping lists. Once a risk ranking is assigned to the threats, it is possible to sort threats from the highest to the lowest risk, and prioritize the mitigation effort, such as by responding to such threats by applying the identified countermeasures. The risk mitigation strategy might involve evaluating these threats from the business impact that they pose and reducing the risk. Other options might include taking the risk, assuming the business impact is acceptable because of compensating controls, informing the user of the threat, removing the risk posed by the threat completely, or the least preferable option, that is, to do nothing.
Each of the above steps are documented as they are carried out. The resulting document is the threat model for the application. This guide will use an example to help explain the concepts behind threat modeling. The same example will be used throughout each of the 3 steps as a learning aid. The example that will be used is a college library website. At the end of the guide we will have produced the threat model for the college library website. Each of the steps in the threat modeling process are described in detail below.