Date: Thu Mar 16 14:48:16 2006
From: simon at snosoft.com (Simon Smith)
Subject: HTTP AUTH BASIC monowall.

Alright,
    First off, I apologize for being such a dumb fuck yesterday, I was
having a bad day and a stupid day. So go ahead and flame me, tell me
what you like, I'm horribly sorry... I "beg for forgiveness" and "ask
for mercy". ;]

    I understand that SSL is the industry accepted standard for
protecting sensitive data in transit with respect to web applications
and other applications. In conjunction, I understand that firewall
administrators will most probably catch certificate warnings and
identify bunk certs. I understand that if the SSL pipe is compromised
there will be much larger issues than just simple authentication. I'm
not contesting anything that anyone is saying here at all, but I am
still not getting any ideas or theories on what I am looking for.

    Encoding a username and password combination using base64 is not
secure, but, I understand why it is encoded in base64. Having said that,
I am trying to discover/create an alternate method for authentication
that is secure even if the SSL pipe is compromised. I liked the idea of
creating a secondary tunnel within the initial SSL tunnel but I am not
certain that it would be the best way to do it.

    This concern came about initially because I was sniffing a LAN and I
noticed a lot of clear text http communications. Within those
communications was the basic authentication header. When I decoded the
auth string I successfully logged into the system receiving the packets.
Very quickly I found that I was connected to a centralized IT management
system that allowed me to control any other computer on the network. Not
only that, but it also allowed me to record emails, key strokes, install
software, remove software, etc.

    I took the liberty of hardening the system by implementing SSL
internally. That really didn't do much for the security of the system
though. I had one of my co-workers attempt a Man in the Middle attack,
and he did it successfully. Sure enough, once the SSL session was had
the encoded string could be decoded and access to the main console could
be gained.

    My concern isn't firewall management. My concern isn't with SSL
going over the Internet. My concern is more with SSL on a LAN and that
this IT tool and other similar tools can be compromised easily once a
LAN is penetrated. Providing an extra layer of security within the SSL
tunnel would help to prevent this tool and others like it from being
compromised so easily. My first thought was on how to harden the
authentication because the basic auth didn't cut it for me. Thats what I
am looking for ideas for.

 




Andrew Simmons wrote:
> Simon Smith wrote:
>
>>> Ok, so what's your alternative?
>
> [...]
>
>>> Some form of challenge response?  If you can already perform a man in
>>> the middle attack, than challenge response is just as vulnerable.
>>> Just connect to the server when the client hits you, and pass them the
>>> challenge you recieved.  Use the credential yourself, and pass them a
>>> failure.  When they try again, connect them to the server.
>
>> You're right again.  Does everyone here think that the majority of
>> companies hire security aware people?
>
>
> We're not talking about general staff, we're talking about your
> firewall admin. If your firewall admin doesn't care about security
> you've got much bigger problems. Which appears to be the case...
>
>
> \a
>


-- 


Regards, 
	Adriel T. Desautels
	Harvard Security Group
	http://www.harvardsecuritygroup.com

Powered by blists - more mailing lists