Security issue with "--remote-debugging-port" when using Selenium C# + ChromeDriver in our product

[Amir Tal]

Hey all,

I would like to consult on a serious issue found in our product using selenium C#+ chrome driver.

Our product main goal is to provide a chrome secured and isolated sessions via for each pre-configured website by the end user, and then invoking automation commands as the end user pre-configured as well.

As all chrome sessions runs at the same application server,

Once chrome.exe opened, each end user can just browse to "localhost:{debugging port}"

of others user's chrome sessions (debugging ports of other sessions can be found by brute-forcing for instance),

and by this way, each end user can gain access to sensitive information of other users. This is currently causing a serious security issue within our product :(

We would like to set that the default behavior of Selenium c# + Chrome driver won't set up the flag of remote-debugging-port AT ALL!

So our crucial need is to block the "inspectable pages" console of the debugging port, or to disable\remove the debugging port flag via selenium code or in some way via Chrome configuration itself. But none of those options exists (we've also created bug for Chrome driver over this but currently there isn't any progress there either).

Also, We not sure whether the selenium c#\ChromeDriver "MUST" use the debugging port or not for its internal use, but we really hope that there is a way to resolve this major issue.

Will be really great having  your urgent assistance finding a mitigation\solution for that manner.

Thanks in advance

[Jesse Brown]

I am wondering if you can try some variation of the following that will work.

Netsh http add urlacl url http://localhost: port/ user=username

--
You received this message because you are subscribed to the Google Groups "ChromeDriver Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromedriver-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/96e6c2b1-cf3c-4360-a514-a71400aa0dd3n%40googlegroups.com.

[Amir Tal]

We've tried many variations like trying to block localhost ports via Windows firewall, but windows firewall doesn't trace loopback.

Also tried port-forwarding, trying to redirect localhost:port requests into unavailable page via this kind of commands " netsh interface portproxy " - but didn't work as well as the original url still accessible and it won't block the origin port.

Notice generally the blocking any localhost:port requests is quite crucial steps, as there may be some users that browsing many kings of internal hosted sites via localhost urls.

Regarding this specific variation of "Netsh http add urlacl url http://localhost: port/ user=username" - we didn't try that, can you explain how it can solve our issue? 

[Amir Tal]

Also, notice that we don't know the debugging port , its randomly chosen for each new chrome session invoked via chrome driver.

[Jesse Brown]

Setting an urlacl that implies that at least a url can be restricted to the specified user for that address. Which process is the parent of that port?

To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/e0ed70d8-de6e-4833-bf77-9d681a318e62n%40googlegroups.com.

[Jesse Brown]

Hypothetically, you could build a wrapper to launch a renamed chromedriver.exe read the redirect the console and error streams and scrape out the debugging port that was opened, set the uracl on that port, wait for the chrome driver process to terminate then remove the urlacl...

[Amir Tal]

Will try the urlacl to see whether it can block and restrict access to localhost:port, i'm wondering - if that will be a success, as each chrome session opened with other debugging port - how we'll manage to block all of the opened chrome debugging ports?

Regarding the renamed chromedriver.exe - not sure that we know how to do it, but in case the chrome driver is the one that enforced the debugging-port flag, or even so - needs it for its internal use- I not sure that this direction would work . WDYT?

[Amir Tal]

Hey jpbro,

I've tried the following varation:

"Netsh http add urlacl url=http://localhost:12300/ user=admin"

Then, via other user tried to open chrome and still managed to browse "http://localhost:12300" and gain access to DevTools.

Tried also couple of the add urlacl variations like adding "listen=no delegate=no" but still same result.

Am I missing something? looks like that it's not blocking from other users to access the "URL" chosen at the urlacl argument :(

[Jesse Brown]

Did you try it on the external IP? We use selenium with chrome simply from a dedicated desktop in a vm. 

Another thing; I noted with all the recent "failed to start chrome" issues, the solution was for me simply running the selenium scripts from a subfolder in the program files folder not a folder in my user profile.

To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/2642a9a9-a907-43e1-9324-f4df0ab0a160n%40googlegroups.com.

[Amir Tal]

Didn't try external IP as our issue related mainly to the localhost url. Generally, In our product, the end user get a monitored RDP session where the selenium runs over the remote machine, so each end user can simply (via their monitored RDP session) to just run "localhost:port" url and gaining access to the  debugging port console page of other chrome's sessions by other users. That's the big major issue here.

Regarding the second suggestion with the subfolder - not sure how the subfolder in the programs files is related to the urlacl suggestion, can you pls explain?

Anyhow, each time the end user via our product receives a session, we must use the user-dir flag folder in order to delete all of its browsing data and cookies at the end of this session, so it cannot run via a constant folder at the programs files or something similar, but only under the a running user's temp folder location which is added to the "--user-data-dir" flag.

[Jesse Brown]

Use wire shark to fingerprint the traffic from chromedriver's remote debugging port on local host. Google how to get the hash to do that.

Add a hash based rule to applocker. Use your discovered hash. Defender will reset the connection.

To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/181caa18-ce89-4e9c-884f-a10a9ddfc5bbn%40googlegroups.com.

[Amir Tal]

Hey jpbro,

(1)can you please share more details on your direction and how generally this can be done?

Not sure we knot how to do this suggestion here.

(2)How that hash can actually be unique? will it be unique for each traffic from each session to the debugging port?

(3)If the applocker will block the traffic for the debugging port, won't it also block the chrome driver access to the chrome itself regardless the debugging port and for that will prevent the chrome driver to work properly with the chrome.exe ?

[Jesse Brown]

Are you running the servers or writing the code? If coder, then ask your IT how to do it. If they don't know how, the I would suggest hiring a competent IT person. I am not going to give you a blog post.

To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/66304719-602d-44ae-8f51-b8754e39a0edn%40googlegroups.com.

[Amir Tal]

We're the coders who responsible for the selenium app that uses chrome driver. not sure, but why can't you assist us with some blog\article so we can take it from there?

Also, can you please reply regarding the questions on (2) and (3) in my last comment ?

[Vladimir Nechaev]

hi Amir,

Few pieces of information just in case:
1. Debugging port is used by ChromeDriver for communication with Chrome. They communicate via the same protocol as Chrome and DevTools.
2. The issue you are describing here is known: https://bugs.chromium.org/p/chromedriver/issues/detail?id=3480
3. There is a possibility to start Chrome listening on specific port and making ChromeDriver to attach it:
      $ chrome --remote-debugging-port=your-port ...other-args...
     And in you selenium script you create ChromeOptions:
        options = ChromeOptions()
        options.debugger_address='localhost:port'
    that you pass in the constructor to your ChromeDriver instance

Best regards,
Vladimir

To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/3055edad-d39c-482f-8deb-8a612100dbf0n%40googlegroups.com.

[Amir Tal]

Hey Vladimir, 

How are you?

Thanks for replying !

Regarding (3) - not sure how it can solve our issue, can you elaborate more? if we attach chrome driver to specific port, that security issue will still remain but only on a specific port and not a random one,

so security issue via the same specific port will remain.

Also,

we cannot use a specific port as each chrome session invoked by chrome driver+ selenium must be a new chrome isolated session, without attaching into the same instance. It should have separated user-dir as we need to

clear at the end of each chrome session - all the user's browsing data and cookies.

So, not sure understood about how "options.debugger_address='localhost:port"  can solve our issue. Appreciate your elaboration on this. Tnx  in advance.

[Amir Tal]

BTW  - Can see here https://bugs.chromium.org/p/chromedriver/issues/detail?id=3480 

that this bug is already marked as insecure feature. since Aug 2020. More than a year passed by, do you know what this issue still not fixed since then? 

On Sunday, October 31, 2021 at 11:41:28 PM UTC+2 nec...@chromium.org wrote: