UP-01-001 HTTP Responses cached beyond Proxy Connection Lifetime

[cure53]

HTTP responses with appropriate headers are kept in the browser cache even after uProxy has been turned off. If the uProxy-serving device performs a MitM attack on HTTP traffic of the client, it can place malicious JavaScript or HTML files in the client’s cache.

While it is clear that the server’s ability to MitM HTTP connections is a design decision, the effect of such a MitM attack should not last beyond the end of the proxy connection – as this would violate reasonable assumptions of the client user. This can e.g. be exploited by serving a malicious copy of http://www.google-analytics.com/ga.js, which is used on many HTTP websites, including Sourceforge download websites, giving the attacker the ability to replace software downloads in the future.

Steps to reproduce:

_Attacker:_

• Grant a uProxy connection to victim
• MitM the HTTP traffic (mitmproxy was used for testing)
• Inject malicious Google Analytics JavaScript

_Victim:_

• Turn on uProxy
• Pick a connection to proxy though Attacker’s host
• Navigate to website benign.com
• Malicious Google Analytics will be loaded and cached
• End uProxy connection
• Cached JavaScript still loads on any website using it

As a mitigation, it is recommended to wipe the browser cache contents that were written while the proxy was active whenever the uProxy connection has been closed. In Chrome, that can be done using the chrome.browsingData API. This requires the additional “browsingData” permission though. Note that it’s recommendable to not only wipe the cache but also the appcache, cookies, local storage and so on to avoid persistent attack surface for any MitM attack.

It is further recommended to consider forcing all tabs to be closed when the proxy connection has been closed. If this is not being done, malicious JS could still be running in some hidden iframe after the connection has been closed, reading/writing cookies for the attacker.

[iislucas]

Interesting...! I think it's Chrome's design that proxying does affect a normal profile's session state. To suddenly not have your old state from the same IP is also giving away information (it says you are using uproxy as not many other extension do that). So, I suspect that if a client user doesn't want their session affected by proxying they are expected in the browser's user-model to be using an incognito window... ?

[cure53]

It's probably hard to find a programmatic solution that fits all needs. What about for instance adding a check-box for the user, prior to connection, to set where the behavior can be controlled? Or a dialog window after the connection has been terminated?

I agree on the info leak caused by the altered session state. Yet, concluding from it that uProxy was used and did that seems far fetched. Yes - if control is given to the user, both ways to handle it could be offered and the poisoning issue could be resolved.