[Owasp-delhi] SSL Broken..

Gunwant Singh gunwant.s at gmail.com
Fri Jan 23 10:52:55 EST 2009


Lava,

Initially the user's password is sent OOB, then in the transit it is hashed
via. one-way hashing algorithm. You can't get the password, you only get the
hash which is indeed useless to an attacker. I think you have not understood
what I was trying to say earlier.

Regards.

On Fri, Jan 23, 2009 at 5:17 PM, <lavakumar.kuppan at rbs.com> wrote:

>
> Gunwant you are missing the point, once I have the user's password I dont
> even have to bother with a MITM.
>
> Thanks and Regards,
> Lavakumar K
> Penetration Tester - Global ISA
> +919833320286(M)||+91-044-43976738 | 047-6738|lavakumar.kuppan at rbs.com
>
>
>  *Gunwant Singh <gunwant.s at gmail.com>*
>
> 01/22/2009 11:06 PM
>   To
> lavakumar.kuppan at rbs.com  cc
> owasp-delhi at lists.owasp.org  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
> Lava,
>
> What do you think about the delay caused while intercepting and modifying
> the traffic on the fly. As I pointed out earlier the time-stamp appended at
> each end is validated at the other which is also based on the tolerace
> calculated at the handshake time. This will compute the delay caused due to
> manipulation of the traffic by MITM.
>
> As I also said that based on the criticality factor the quantization can
> vary in milliseconds even nanoseconds. Nonetheless the validation is
> performed at both ends, so modifying traffic from either end to the other
> will be detected and invalidated.
>
> However, for me the question is how to code/implement the handshake process
> which can be a bit complex. Infact, much complex.
>
> -Gunwant.
>
>
>
> On Thu, Jan 22, 2009 at 2:49 PM, <*lavakumar.kuppan at rbs.com*<lavakumar.kuppan at rbs.com>>
> wrote:
>
> Hi Gunwant,
>
> In addition to ARP poisoning this tool also lets you manipulate HTTP
> content on the fly.
> However coming back to the timestamp technique, here is how it will happen:
>
> STEP 1:
> Client  -> GET /index.jsp -> Server
> Server - > 200 OK <html>Secret_Msg="secret"<script src=timestamp.js></html>
> -> Attacker (notes down the secret message) -> Client (lets say timestamp.js
> contains the client-side logic for timestamp creation and hashing)
>
> STEP 2:
> Client -> GET /timestamp.js  -> Server
> Server  -> [timestamp();hash()] -> Attacker - > [timestamp();hash();
> (document.cookie = "password
> ="+document.forms['login'].password.value+"time"=time())] -> Client
> (The attacker who is sniffing with ARP poisoning is now manipulating the js
> file's content on the fly, he adds a couple of more lines of code to the
> actual js file which adds the user's password to the cookie under the name
> 'password' and the current time on the client under the name 'time'.)
>
> STEP 3:
> Client(user enters the password, the hash is created by the js and sent to
> the server, this request also contains the clear-text password and the
> current time in the cookie) -> Attacker (notes down the password and time
> and removes these fields from the cookie and sends to the server) ->
> Server(server happily authenticates the user)
>
>
> At this point the attacker has all the three values needed for the hash
> creation - current time on the client side, secret message and the user's
> password. He also knows how the hash is created.
> Now he can recreate the hash as many time as he wants with new timestamps.
> If the server issues a new secret message then the attacker can get that as
> he is sniffing, same goes for any session ID that is issued.
> It should be trivial to stay within the time-lag tolerance as for any site
> to not piss off its users the tolerance should atleast be in seconds.
> If it was in milliseconds then even the actual sites users cant send valid
> requests.
>
> If the attacker doesnt have a sense of adventure then he can stop once he
> gets the user's password ;)
>
> Hope this makes things clear
> .
> It would have been intresting to discuss this with you in person during
> this month's meet but unfortunately am not in Gurgoan anymore.
> Good luck with your presentation, am sure that everyone..developers esp
> would find it just as useful as the earlier two :)
>
> Thanks and Regards,
> Lavakumar K
> Penetration Tester - Global ISA
>
>
>   *Gunwant Singh <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/21/2009 09:15 PM
>
>   To
> *lavakumar.kuppan at rbs.com* <lavakumar.kuppan at rbs.com>  cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
> 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*<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* <gunwant.s at gmail.com>*>*
>
> 01/19/2009 11:25 PM
>
>   To
> *lavakumar.kuppan at rbs.com* <lavakumar.kuppan at rbs.com>  cc
> *owasp-delhi at lists.owasp.org* <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*<http://www.messagelabs.com/email>
> ______________________________________________________________________
>
>
>
>
> --
> Gunwant Singh
>
>
> ______________________________________________________________________
> 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 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/20090123/0ebb62d5/attachment-0001.html 


More information about the Owasp-delhi mailing list