[Owasp-delhi] SSL Broken..

lavakumar.kuppan at rbs.com lavakumar.kuppan at rbs.com
Tue Jan 27 04:26:28 EST 2009


Gunwant, in my earlier mail I have explained how the password would be 
stolen even when you use hashing.
Guess we have argued on this long enough, since either party is hard to 
convice lets just bury this thread ;)

Thanks and Regards,
Lavakumar K





Gunwant Singh <gunwant.s at gmail.com> 
01/23/2009 09:22 PM

To
lavakumar.kuppan at rbs.com
cc
owasp-delhi at lists.owasp.org
Subject
Re: [Owasp-delhi] SSL Broken..






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> 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> 
01/21/2009 09:15 PM


To
lavakumar.kuppan at rbs.com 
cc
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> 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> 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
> 
Sent by: owasp-delhi-bounces at lists.owasp.org 
01/16/2009 11:06 PM 


To
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> 
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> 
01/15/2009 12:30 PM 


To
"Plash Chowdhary" <plash.chowdhary at tcs.com> 
cc
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> 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> 
01/15/2009 10:27 AM 


To
"Plash Chowdhary" <plash.chowdhary at tcs.com> 
cc
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> 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> 
01/15/2009 09:25 AM 


To
"Plash Chowdhary" <plash.chowdhary at tcs.com> 
cc
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> 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 

> 
Sent by: owasp-delhi-bounces at lists.owasp.org 
01/14/2009 10:13 AM 


To
"Karthik Muthukrishnan" <karthik.muthukrishnan at tcs.com> 
cc
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> 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 
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
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

______________________________________________________________________ 



-- 
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 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit 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



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 
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090127/8d8fca52/attachment-0001.html 


More information about the Owasp-delhi mailing list