[wp-trac] [WordPress Trac] #44935: Automated test's suggesting /wp-login.php?action=lostpassword can be used for compromizing site

[WordPress Trac]

#44935: Automated test's suggesting /wp-login.php?action=lostpassword can be used
for compromizing site
--------------------------+-----------------------------
 Reporter:  wzislam       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Security      |    Version:  4.9.8
 Severity:  major         |   Keywords:  needs-testing
  Focuses:                |
--------------------------+-----------------------------
 I'm not a security expert. But recently ran an automated test to one of
 our client site, and came with this issue. Tried posting in HackerOne, but
 couldn't came up with the UI. Hence posting here for proper notice.

 If there's nothing to take care about, at least I need a reasonable answer
 so that I can conclude the issue with my clients and to all the haters of
 WordPress.

 ----------------

 Test Tool: ZAP
 (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)

 Risk level: High

 Test server: Localhost (Windows 7 machine, PHP 7.1.7 and PHP 5.6)

 Alert details: Path Traversal

 Description:

 The Path Traversal attack technique allows an attacker access to files,
 directories, and commands that potentially reside outside the web document
 root directory. An attacker may manipulate a URL in such a way that the
 web site will execute or reveal the contents of arbitrary files anywhere
 on the web server. Any device that exposes an HTTP-based interface is
 potentially vulnerable to Path Traversal.

 Most web sites restrict user access to a specific portion of the file-
 system, typically called the "web document root" or "CGI root" directory.
 These directories contain the files intended for user access and the
 executable necessary to drive web application functionality. To access
 files or execute commands anywhere on the file-system, Path Traversal
 attacks will utilize the ability of special-characters sequences.

 The most basic Path Traversal attack uses the "../" special-character
 sequence to alter the resource location requested in the URL. Although
 most popular web servers will prevent this technique from escaping the web
 document root, alternate encodings of the "../" sequence may help bypass
 the security filters. These method variations include valid and invalid
 Unicode-encoding ("..%u2216" or "..%c0%af") of the forward slash
 character, backslash characters ("..\") on Windows-based servers, URL
 encoded characters "%2e%2e%2f"), and double URL encoding ("..%255c") of
 the backslash character.

 Even if the web server properly restricts Path Traversal attempts in the
 URL path, a web application itself may still be vulnerable due to improper
 handling of user-supplied input. This is a common problem of web
 applications that use template mechanisms or load static text from files.
 In variations of the attack, the original URL parameter value is
 substituted with the file name of one of the web application's dynamic
 scripts. Consequently, the results can reveal source code because the file
 is interpreted as text instead of an executable script. These techniques
 often employ additional special characters such as the dot (".") to reveal
 the listing of the current working directory, or "%00" NULL characters in
 order to bypass rudimentary file extension checks.

 URL: http://localhost/wordpress/wp-login.php?action=lostpassword

 Method: POST

 Parameter: user_login

 Attack: wp-login.php

 Instances: 1

 Solution:

 Assume all input is malicious. Use an "accept known good" input validation
 strategy, i.e., use a whitelist of acceptable inputs that strictly conform
 to specifications. Reject any input that does not strictly conform to
 specifications, or transform it into something that does. Do not rely
 exclusively on looking for malicious or malformed inputs (i.e., do not
 rely on a blacklist). However, blacklists can be useful for detecting
 potential attacks or determining which inputs are so malformed that they
 should be rejected outright.

 When performing input validation, consider all potentially relevant
 properties, including length, type of input, the full range of acceptable
 values, missing or extra inputs, syntax, consistency across related
 fields, and conformance to business rules. As an example of business rule
 logic, "boat" may be syntactically valid because it only contains
 alphanumeric characters, but it is not valid if you are expecting colors
 such as "red" or "blue."

 For filenames, use stringent whitelists that limit the character set to be
 used. If feasible, only allow a single "." character in the filename to
 avoid weaknesses, and exclude directory separators such as "/". Use a
 whitelist of allowable file extensions.

 Warning: if you attempt to cleanse your data, then do so that the end
 result is not in the form that can be dangerous. A sanitizing mechanism
 can remove characters such as '.' and ';' which may be required for some
 exploits. An attacker can try to fool the sanitizing mechanism into
 "cleaning" data into a dangerous form. Suppose the attacker injects a '.'
 inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism
 removes the character resulting in the valid filename, "sensitiveFile". If
 the input data are now assumed to be safe, then the file may be
 compromised.

 Inputs should be decoded and canonicalized to the application's current
 internal representation before being validated. Make sure that your
 application does not decode the same input twice. Such errors could be
 used to bypass whitelist schemes by introducing dangerous inputs after
 they have been checked.

 Use a built-in path canonicalization function (such as realpath() in C)
 that produces the canonical version of the pathname, which effectively
 removes ".." sequences and symbolic links.

 Run your code using the lowest privileges that are required to accomplish
 the necessary tasks. If possible, create isolated accounts with limited
 privileges that are only used for a single task. That way, a successful
 attack will not immediately give the attacker access to the rest of the
 software or its environment. For example, database applications rarely
 need to run as the database administrator, especially in day-to-day
 operations.

 When the set of acceptable objects, such as filenames or URLs, is limited
 or known, create a mapping from a set of fixed input values (such as
 numeric IDs) to the actual filenames or URLs, and reject all other inputs.

 Run your code in a "jail" or similar sandbox environment that enforces
 strict boundaries between the process and the operating system. This may
 effectively restrict which files can be accessed in a particular directory
 or which commands can be executed by your software.

 OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In
 general, managed code may provide some protection. For example,
 java.io.FilePermission in the Java SecurityManager allows you to specify
 restrictions on file operations.

 This may not be a feasible solution, and it only limits the impact to the
 operating system; the rest of your application may still be subject to
 compromise.

 Reference:

 1. http://projects.webappsec.org/Path-Traversal

 2. http://cwe.mitre.org/data/definitions/22.html

 CWE Id: 22

 WASC Id: 33

 Source ID: 1

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44935>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform