[squid-dev] [RFC] --> Redirect attack

Fri Feb 19 12:40:31 UTC 2016

Thanks for the detailed response!

 From what I understand until now it seems to me that the main reason 
that nobody created a "standard" for MITM proxies authentication is 
since the current HTTP implementations and UA are somehow aware of the 
option to the wildness of the networks and the Internet world.

While reviewing OAuth and SSO technologies I noticed that it is very 
"simple" to attack them using some kind of MITM and I was kind of amazed 
by what issues might arise if the UA in some way contacts some public 
Internet system.
It gets even more complicated with NAT and until now the solutions for 
SSO and OAuth are to somehow use an Internal Authentication and 
Authorization system in the UA\Session level.

Maybe I missed something but I am unsure. Authorization and 
Authentication can work in a way together or in separated ways(leaving 
squid and other acls aside).
What Authorization helpers I have missed?
The ones I know about that a transparent(MITM) proxy can use are:
- Radius(IP)
- Time_quota(IP)
- session(IP)

These are good for specific usages and will probably not be good enough 
for full authentication and authorization for VNC\RDP\NAT environments.

I do not argue with the risks that do exists and organizations do 
consider them over and over again. Some use VPN connections to somehow 
evade every HTTP\HTTPS MITM proxies in the wild but many do not require 
that and I really do not know how they make sure that the connections 
are secure else then TLS\SSL.

One of the really hard things I have seen lately in the security 
industry was Anti Viruses that are doing machine local HTTPS MITM. And 
the harder thing was that these programs implement some kind of "sensor" 
net which sends data to their main systems. The most weird thing I have 
seen is that most of them didn't even used HTTPS connections to these 
"sensor" networks main API system.

There is a whole other aspect about CDN security, many offer free domain 
level SSL.

The dilemma that stands is:
If these Security firms use plain HTTP for so many delicate things, why 
should I trust them or why do I use HTTPS?

As a result to this dilemma and the thread opening subject I was 
starting to think about writing a wiki article. In some relation to 
squid without providing any code, would it be right to describe in some 
technical details this kind of attack?
The pros:
- It will give another aspect when looking at the attack.
- It will make the awareness to the subjects a bit better.
- The time on the research about the subject was already invested.

The cons:
- Many wrote about the subject in the past.
- It's not a caching subject but rather a security one.

What do you and maybe others think about security related articles in 
the wiki?

Eliezer

On 18/02/2016 19:19, Amos Jeffries wrote:
> On 19/02/2016 5:28 a.m., Eliezer Croitoru wrote:
>> After playing with couple SSO ideas in general I noticed that something
>> similar can be done with squid while it will not be as secured as
>> kerberos and couple other nice implementation.
>>
>> Deatils:
>> A transparent proxy cannot authenticate users in the session level. The
>> current known available options are using some session db(by IP) or
>> Radius or LDAP(by ip) and couple others.
>> So for couple specific environments which uses either NAT or multiple
>> VNC\RDP sessions there is no option to authenticate a specific user but
>> a whole IP\machine.
>>
>> The real solution would be to somehow make it possible for a browser to
>> know about the option of a "transparent proxy" and to also trust it.
>> Also this specific network must be secured enough so no rough dhcp
>> services will pop up and couple other network level restrictions will be
>> applied to ensure that the browser can authenticate to the proxy in the
>> case he will be there.(There might be some other attacks which I didn't
>> mentioned)
>>
>
> "transparent proxy" is a badly overloaded phrase.
>   * Taken literally it means the same as "forward-proxy" in HTTP terminology.
>   * Taken as a colloquial way of saying "interception proxy", aka. MITM.
> It is by definition not possible to have trust since the identity of the
> proxy is unverifiable.
>
>
>> Another approach to the issue:
>> Currently browsers use cookies to authenticate banks, police, health and
>> many other systems. They are not highly secured but they are being used
>> in many places.
>
> Let me stop you right there.
>
> In order to set a Cookie that is in any way equivalent to the
> authentication/authorization sessions. The proxy has to first be able to
> determine whether any two random connections came from the same client UA.
>    If it is capable of doing that already then that is how the
> authorization session helper should be operating. No need for Cookie to
> be involved.
>
> The ability to set Cookies for generic UA->interceptor authorization is
> an *outcome* of having a session. Not the reverse.
>
> They could be used for the much more limited scope of tying two UA
> connections for the same domain into a session. But ...
>
> A secondary effect of using Cookie is that the Cookie data is then
> delivered by the UA to the origin it thinks that Cookie belongs to.
> Including down channels the proxy is not intercepting. This wastes a lot
> of bandwidth, reveals not just the proxy existence but its session
> credentials as well into the WAN.
>
>
> There is still the ultimate question of trust needing to verify the
> proxies identity. To ensure that the unseen proxy setting the Cookie is
> the one its going to be delivered to later.
>
>
>>
>> Maybe we can use them for something?
>> Since the first days of cookies security restrictions was applied on
>> them to disable phishing, impersonation etc.
>> Many vendors "secure" the cookies based on user-agent string,
>> timestamps, origin ip and many others. These in very specific cases can
>> make it somehow harder on the cookie finder to use them but it still
>> might not be enough for many systems.
>
> What you go on to describe is a Redirect attack. Its particularly a
> favorite when attacking websites using OAuth.
>
> Amos
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>