[Owasp-delhi] SSL Broken..

Gunwant Singh gunwant.s at gmail.com
Wed Jan 21 10:45:11 EST 2009


Hi Lava,

Come on! I know ARP poisoning, what I meant was how would you intercept and
manipulate the traffic in my specific case, especially when you have
time-stamps involved.

Thanks.
Gunwant

P.S: Is this mail delivery system error only coming to me or everyone else?

On Wed, Jan 21, 2009 at 11:39 AM, <lavakumar.kuppan at rbs.com> wrote:

>
> Hi Gunwant,
>
> You can check out ettercap, it has ARP poisoning capability and lets you
> manipulate the intercepted traffic on the fly with filters.
> Play around with it a little :)
>
> Thanks and Regards,
> Lavakumar K
> Penetration Tester - Global ISA
>
>
>
>  *"Gunwant Singh" <gunwant.s at gmail.com>*
>
> 01/19/2009 11:25 PM
>   To
> lavakumar.kuppan at rbs.com  cc
> owasp-delhi at lists.owasp.org
>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
> Hi Lava,
>
> Nice to see your reply. Please see my thoughts on your comments.
>
> >Now in the solution that you have suggested, the server has to fetch the
> user's password for each request which defeats the whole purpose of
> maintaning session IDs.
>
> Good point. My suggestion on this: Access the password only once and store
> it in a temporary variable securely for further transactions and then delete
> it as the session ends.
>
> >Ironically you had already suggested a solution and then asked the
> question, wonder if you were just checking if everyone understood your talk
> properly ;)
>
> If you would have read this mailing thread from the very scratch, you would
> have known that this question ain't related to salted MD5. I was not
> checking if people understood my talks properly. I could have done that
> there and then only.
>
> >For your salted-hashning technique or the new techique there is to be a
> lot of client side JS code which has to create the salted hash and send it
> to the server. The attacker would just intercept this message and replace
> your JS with another JS which does every thing like the original JS but in
> addition steals the user's clear text password and appends to the request
> which the attacker can now get by viewing your request.
>
> I would like to comment about the salted hashing part in a different e-mail
> (if I get some time) as this topic is not what I am talking about here.
> About the technique, in case if you can manipulate the generated hash
> somehow by intercepting, and make up your own hash, can you still be a part
> of the same session. I don't think so. Let me know if you can. Check out the
> way I told about its workings.
>
> Could you come up with some *PoC* to what you said? You said intercepting
> and manipulating the traffic on the fly travelling from the server to the
> client or the other way around? How would you do that sitting somewhere on
> the network? I am curious to know.
>
> I don't know why you guys keep involving SSL with this thing.
>
> Thanks for your feedback.
>
> -Gunwant
>
> On Mon, Jan 19, 2009 at 1:04 PM, <*lavakumar.kuppan at rbs.com*<lavakumar.kuppan at rbs.com>>
> wrote:
>
> Hi Gunwant,
>
> Thanks for bringing up this topic, can see that it has tickled quite a few
> brains in the list already ;), prompting some really intelligent ideas and
> arguments.
> I was on vacations and missed out on all the fun here, but its never too
> late so here is my humble opinion.
>
> There are two very important factors that have to be considered here:
>
> 1) Why is a session ID required.
> 2) What is the possibilty of some one with sniffing capability to intercept
> and manipulate the traffic.
>
>
> 1) Why is a session ID required
> I believe sessiond IDs are used to avoid connecting to the DB each time and
> validating the user's password, they are used to improve efficiency.
> Now in the solution that you have suggested, the server has to fetch the
> user's password for each request which defeats the whole purpose of
> maintaning session IDs.
> Since we are anyway reffering to the password for each request, I would
> like to think that we can authenticate for each request with the salted-hash
> technique you suggested in your december OWASP talk, provided once a salt is
> used the server discards it and issues a new one.
> Ironically you had already suggested a solution and then asked the
> question, wonder if you were just checking if everyone understood your talk
> properly ;)
>
> 2) What is the possibilty of some one with sniffing capability to intercept
> and manipulate the traffic.
> As someone who has done quite a bit of sniffing on customer networks during
> pentests, I think that someone who is capable of sniffing would in all
> probability also be capable of intercepting and manipulating the traffic
> between the client and server. There might be exceptions but they would be
> uncommon.
> Any techniquie which enforces some trust on the client-side logic now gets
> defeated.
> For your salted-hashning technique or the new techique there is to be a lot
> of client side JS code which has to create the salted hash and send it to
> the server. The attacker would just intercept this message and replace your
> JS with another JS which does every thing like the original JS but in
> addition steals the user's clear text password and appends to the request
> which the attacker can now get by viewing your request.
> Once this happens the entitre security system is defeated as its so closely
> attached to the user's password.
> So in my opinion once someone is able to intercept a clear-text traffic he
> could directly or indirectly bypass most restictions enforced.
>
> The thing that differentiates SSL from the suggested approach is the use of
> Server certificates which establishes authenticity, unless we can figure out
> a way to do that our confidentiality and integrity solutions might fail.
>
> Dont cosider thick client approach like java applets as reverse engineering
> is a possibility.
>
> PS: OK, I have not suggested any solution,  am a pentester what do you
> expect :P
>
> Thanks and Regards,
> Lavakumar K
> Penetration Tester - Global ISA
>
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
> Sent by: *owasp-delhi-bounces at lists.owasp.org*<owasp-delhi-bounces at lists.owasp.org>
>
> 01/16/2009 11:06 PM
>
>   To
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  cc
>   Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
> Hi,
>
> Ok, let me elucidate the workings of the technique I was talking about.
>
>
>
> But before that I just want to shed some light on a few things so no-one
> comes again questioning to me about these and start some endless argument.
>
> - The e-commerce site I was talking about, I never said that they are only
> using the technique I am going to discuss. They might be using other
> techniques for their protection. What I meant was I've not seen/heard anyone
> else using this technique. That doesn't mean that they are only using this
> technique for their protection. Every giant incorporates multi-tier security
> for their resources.  I am not sure what exactly they are using besides this
> technique as Nobody reveals that.  I questioned someone on a forum, he came
> up with this technique, I studied, checked this on their documentation page,
> discussed with some people, discussed with some more, argued with even more
> and now I am here. I am looking for some feedback from you all. Just let me
> know what ever you think is wrong with this. Anyhow the question is not that
> whether they are using it or not but the question is 'How good is the
> technique?'
>
> - Please don't misinterpret my statement. I am not saying 'Don't use SSL'.
> SSL is definitely a protection mechanism for "Now" if we use it
> appropriately (CA signed certificate with a well-tested, well-reviewed
> implementation). Use SSL till someone finds some exploit *practically* not
> theoretically. This whole discussion is based on a research question so I/we
> can get a *feasible* working solution for this (may-be-a-future) problem. If
> you are not interested in discussing please do not comment. And please do
> not envisage what I am not saying.
>
> So here is how it works.
>
> No SSL. All traffic in clear text.
> Initially we need to communicate an OOB password/code/nonce (whatever you
> call it) to the client - only *once* not each time.
>
>
> 1. The client initiates a connection request to the server. As a result,
> server will initiate a handshake process to synchronize the time-stamps
> between the client and itself. Then the server will analyze tolerance time
> of packets leaving the client workstation till it reaches the server. The
> tolerance time is configured so to manage slow hosts or slow traffic. In
> plain words, server synchronizes date and time (in seconds, milliseconds or
> even nanoseconds based on the criticality of the application) with the
> client.
>
> 2. At the client side: the message, instantaneous time-stamp and the
> password are concatenated and hashed via SHA-1/SHA-256, whatever one wishes.
> This ensuing hash is combined with the username to form an authentication
> header and sent to the server.
>
> 3. At the server side, the server sees the username and perceives which
> user is trying to authenticate. Based on the tolerance configured initially
> at the handshake time, it picks the time-stamp from its own clock and using
> the password and the message it generates the hash in the same way as it was
> done at the client side.
>
> 4. If the hash matches it generates a Session ID and maps it to the
> username of the user. This Session ID will be sent from the client to the
> server along with the computed hash (which is different for each request -
> see next Step)
>
> 5. Now if the client sends another request, it appends and then hashes the
> message, password and the time-stamp (which will be apparently because of
> the different instantaneous time-stamp i.e. date and time). This resulting
> string is sent to the server along with the Session ID assigned to the user
> earlier. The resulting string contains a different hash as the time has
> changed. This will be validated at the server the same way as in Step 3.
>
> Now how can an adversary exploit this scenario? What I think of are two
> ways:
>
> 1. Either he will capture one of the hashes and try to predict the next
> hash by brute forcing different time-stamps.
>
> - But this can not be possible. He doesn't have the password to generate
> the hash.
>
> 2. What if he captures a series of requests and responses and replays them
> back to the server at a later stage.
>
> - This can't be possible either. In order to interact with the server, one
> needs to handshake so to synchronize itself with the server's clock. The
> attacker would not be able to synchronize because he would not be able to
> synchronize the *past-timestamp* (in the captured traffic) with the server's
> current time.
>
> 3. Lastly for the newbies, what if he captures the Session ID.
>
> - But he would not be able to produce the matching Hash for the request, so
> no luck.
>
> A few things to contemplate:
>
> 1. This will be considerably be CPU intensive but can be acknowledged if
> compared to the processing cycles SSL takes.
>
> 2. Time synchronization can be complex. I have no idea how to do that.
>
> 3. Please provide your
> feedback/fury/antagonism/annoyance/appreciation/whatever. Hope I explained
> this in a very straightforward way.
>
> Thanks.
>
> Gunwant
>
>
>
>
>
> On Fri, Jan 16, 2009 at 4:26 AM, Plash Chowdhary <*plash.chowdhary at tcs.com
> * <plash.chowdhary at tcs.com>> wrote:
>
> Gunwant,
>
> I will be interested to know kind of soltutions are being used.
> SInce you are talking about **Time stamp**(in clear text will be
> perdictable, specially if a client side algo is being used) <some random
> number in hidden field with every request,<unique captcha with every request
> (this will be interesting)  can be a case but they will be not as roboust
>  as out of band..
> some how with Time stamps only thing that rings bell is CRYPTOGRAPHY *: D
> *(PKI??)
>
> I will be really surprized if that organization is not using SSL from a
> Vendor. (as you said its an e commerce site)
>
> and anyways i wont be using HTTPS on public content of my site and will
> switch to HTTPS session only when needed (IDEALLY)
>
>
> lemme know your thoughts
>
> Regards
> Plash
>
>
>
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/15/2009 12:30 PM
>
>   To
> "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
>  cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>
>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
> Plash,
>
> Thanks for the idea. Please don't take my talks as overstatements, I just
> wanted to have some innovative ideas from you guys.
>
> Many organizations implement session mechanisms without using SSL. As a
> matter of fact these are not the conditions that I have set. There are many
> scenarios where using SSL is unworkable and in order to provide protection,
> there are solutions.
>
> Also, it becomes more relevant when people are trying to prove the
> weaknesses of SSL. Not to forget, facts say that most organizations who use
> SSL, use self signed certificates rather than a CA sign it.
>
> For sessions on non-SSL, there are many undocumented solutions which can be
> put into practice but such solutions needs to be well-reviewed and
> well-tested before they are implemented. I have come to know about one of
> the methods implemented by one of the top e-commerce portal giants. This
> solution is a bit tough to understand and subsequently implement it. Before
> I discuss it on the mailing list, I need to make sure that I understand it
> well. The only thing I can share at the moment is, it uses time-stamps.
> Hopefully, I would be discussing this proposition in detail in the upcoming
> Delhi Chapter meeting this month.
>
> Sorry if my talks were exaggerated. I still seek more ideas on the same
> question if someone is willing to share.
>
> Many thanks.
>
> On Thu, Jan 15, 2009 at 11:29 PM, Plash Chowdhary <
> *plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>> wrote:
>
> Gunwant,,
>
> Yes impractical "Off band validation" for each request in the conditions
> you have set. Now either you come up with a solution or im implimenting SSL
> *: )*
>
>
> Regards
> Plash
>  *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/15/2009 10:27 AM
>
>   To
> "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
>  cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>
>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
>
>
> I would happily accept what you say if you say how it protects.
>
> Tell me **how** would a sniffer miss your validation code on an
> unencrypted channel. We should talk about mitigating not minimizing.
>
> Oh ! unless you are saying, a different off band validation code is sent
> for **each** request - then it is possible but it is impractical even in
> high risk applications.
>
> On Thu, Jan 15, 2009 at 9:41 PM, Plash Chowdhary <
> *plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>> wrote:
>
> It does Gunwant, Use long one time off band validation....and keep a short
> TTL it will minimize the risk of relpay,....
>  *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/15/2009 09:25 AM
>
>   To
> "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
>  cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>
>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
>
>
>
>
> That doesn't affirm protection against replay attack, dude!
> In the transit, anyone can see your validation code...
> Even if you hash/encrypt it, still it can used to replay the traffic...
> this is vulnerable.. :)
>
> On Thu, Jan 15, 2009 at 3:46 AM, Plash Chowdhary <
> *plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>> wrote:
>
> verify user offline.. send an sms(or similar) with a validation code(long
> randomly genrated  string) to the user everytime he logs in to validate and
> use it everytime a transaction (high risk) is done or role is  changed..
> best way still will be to use it over SSL and use digital signatures
>
>
> Regards
> Plash
>  *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>
> *>*
> Sent by: *owasp-delhi-bounces at lists.owasp.org*<owasp-delhi-bounces at lists.owasp.org>
>
> 01/14/2009 10:13 AM
>
>   To
> "Karthik Muthukrishnan" <*karthik.muthukrishnan at tcs.com*<karthik.muthukrishnan at tcs.com>
> >
>  cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>
>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> Thanks for your reply but that did not answer my question. You are telling
> me what I can use for protecting the credentials. I know what I can use, but
> just out of curiousity I want to know if I don't use SSL/VPN or any other
> network based protection, what else can be done on the application layer in
> order to protect the credentials
> . Please see the answers below.
>
>
> On Wed, Jan 14, 2009 at 3:50 PM, Karthik Muthukrishnan <*
> karthik.muthukrishnan at tcs.com* <karthik.muthukrishnan at tcs.com>> wrote:
>
> > salted MD5 hashing protects the authentication credentials rightly from
> eavesdropping on the network.
> Salting is used to protect MD5 hashes from rainbow table attacks.
> Apparently Yes, although ultimately it protects authentication credentials
> only. Facts say the highest risk is eavesdropping if the session is
> unencrypted.
>
> > SSL does the same thing.
> Yes, SSL is used to ensure confidentiality and trust in the network
> communiation. Confidentiality (or prevention of network eavesdropping) is
> ensured by encryption. Trust is accomplished by Server and/or client
> certificates.
> I know what SSL does, but my question is something else.
>
> > However, in some scenarios SSL might not be feasible. For example,
> causing heavy load on the server or may be some applications don't support
> it, etc.
> In such cases SSL Accelerators are used. They are devices which can be fit
> into the architecture without changing the application or affecting the load
> on the application server.
>
> Again my question is something else. I know if SSL doesn't work,
> accelerators help expedite the processing. What I want to know is, if I "Do
> Not" want to use SSL what measures can be taken.
>
>
> > We can protect the authentication credentials using salted MD5 hashing
> or by using SSL.
> To protect authentication credentials in HTTP, we have to rely on SSL.
> Hashes are a secure (aka not in clear text) way to store authentication
> credentials.
> So you are proclaiming that we *have to* rely  on SSL- no other
> alternative.
> Hashes are also used in many applications for many different purposes
> besides authenticity and integrity.
>
>
> > In order to protect the Session credentials (Session ID, tokens,
> cookies, etc) on a non-SSL channel what measures can be taken?
> To protect either auth or session credentials we have to ensure
> confidentiality of the communication channel. If we dont use HTTPS, then VPN
> might be another option. While authentication credentials can be protected
> by some challenge handshake mechanism (similar to CHAP), we would need to
> protect session creds by encrypting the channel.
> I was asking that if we can provide some protection on the application
> level rather than on the network level. Besides SSL/VPN there are many
> options available for protecting the authentication credentials. I want to
> know (just out of curiousity) that how can we secure the session credentials
> on an unencrypted/non-SSL channel. I know this will take too much processing
> cycles, time synchronization, quantization in milliseconds even nanoseconds,
> affirmation of the key exchange, dynamic hashing key generation to mitigate
> replay attacks, and even more.
>
> I just want to know  if anyone has an idea on how it can be done if h/she
> is willing to share that would be really appreciative. Please make sure
> you understand what I am looking for.
> No offence :)
>
>
>
> Karthik
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
> _______________________________________________
> Owasp-delhi mailing list*
> **Owasp-delhi at lists.owasp.org* <Owasp-delhi at lists.owasp.org>
> *https://lists.owasp.org/mailman/listinfo/owasp-delhi*<https://lists.owasp.org/mailman/listinfo/owasp-delhi>
>
> ForwardSourceID:NT00005236
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
> ForwardSourceID:NT000052F2
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
> ForwardSourceID:NT0000530E
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
> ForwardSourceID:NT0000533A
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
>
>
>
> --
> Gunwant Singh
> _______________________________________________
> Owasp-delhi mailing list*
> **Owasp-delhi at lists.owasp.org* <Owasp-delhi at lists.owasp.org>*
> **https://lists.owasp.org/mailman/listinfo/owasp-delhi*<https://lists.owasp.org/mailman/listinfo/owasp-delhi>
>
>
> This message (including any attachments) is confidential and may be
> privileged. If you have received it by mistake please notify the sender by
> return e-mail and delete this message from your system. Any unauthorised use
> or dissemination of this message in whole or in part is strictly prohibited.
> Please note that e-mails are susceptible to change. ABN AMRO Central
> Enterprise Services Pvt Ltd, part of RBS Group plc , having its registered
> office at Empire Complex, 414 Senapati Bapat Marg, Lower Parel (W), Mumbai -
> 400 013 , including its group companies, shall not be liable for the
> improper or incomplete transmission of the information contained in this
> communication nor for any delay in its receipt or damage to your system. ABN
> AMRO Central Enterprise Services Pvt Ltd (or its group companies) does not
> guarantee that the integrity of this communication has been maintained nor
> that this communication is free of viruses, interceptions or interference.
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit *http://www.messagelabs.com/email*<http://www.messagelabs.com/email>
> ______________________________________________________________________
>
>
>
> --
> Gunwant Singh
>
>
> This message (including any attachments) is confidential and may be
> privileged. If you have received it by mistake please notify the sender by
> return e-mail and delete this message from your system. Any unauthorised use
> or dissemination of this message in whole or in part is strictly prohibited.
> Please note that e-mails are susceptible to change. ABN AMRO Central
> Enterprise Services Pvt Ltd, part of RBS Group plc , having its registered
> office at Empire Complex, 414 Senapati Bapat Marg, Lower Parel (W), Mumbai -
> 400 013 , including its group companies, shall not be liable for the
> improper or incomplete transmission of the information contained in this
> communication nor for any delay in its receipt or damage to your system. ABN
> AMRO Central Enterprise Services Pvt Ltd (or its group companies) does not
> guarantee that the integrity of this communication has been maintained nor
> that this communication is free of viruses, interceptions or interference.
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
Gunwant Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090121/4d7d0c3e/attachment-0001.html 


More information about the Owasp-delhi mailing list