Docstoc

Download - IEEE Entity Web Hosting - Home

Document Sample
Download - IEEE Entity Web Hosting - Home Powered By Docstoc
					Application Security
Satish Babu
Chair, Computer Society IEEE Kerala Section President, InApp Information Technologies, Technopark
1/102

Rule #0 of Application Security:

The most powerful weapon that an attacker has, is the unsuspecting user...

2/102

Overview
● ● ● ● ● ● ● ● ●

Introduction Network vs. Application security Concepts in cryptography Application-level vulnerabilities Web vulnerabilities Top 10 web vulnerabilities Google hacking Spam, Spim and Scams Conclusion

3/102

Disclaimer
●

●

●

●

This presentation is meant to familiarize participants with several security holes that exist in commonly-used software so as to sensitize them to the need for security In the process, it uses tools and techniques that, if applied in real-life, may attract prosecution Any real-world examples used here are only used for illustrative purposes and does not imply that the particular site has less security than others In particular, neither the speaker nor the organizers endorse any act such as forced entry into computers or the illicit retrieval and misuse of user credentials

4/102

Pre-requisites and desirables
●

Pre-requisites
– –

–
●

A sound knowledge of the workings of networks, TCP/IP and application-level protocols Exposure to a programming language Good knowledge of HTML Substantial exposure to the web

Desirable
–

5/102

Application and Network Security
Introduction

6/102

“Security is not a device, but a process. It is not the destination, but the journey itself...”
— Anonymous quote
7/102

Security
●

●

●

Security was not a concern for developers and systems programmers till the early 90s However, after the coming of the Internet and the spread of distributed applications, security has become a major concern Security concerns came into the limelight with threats as viruses, trojans, worms, and ―crackers‖, especially as valuable data went on the Network

8/102

Vulnerabilities Reported
6000 5000 4000 3000 2000 1000 0 1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

Vulnerabilities
Note: Values for 2005 projected from first two quarters

Source: http://www.cert.org (CMU)

9/102

Application security
●

These days, security is a concern at two levels:
– –

Network security Application security

●

●

The former is concerned about low-level security during processes such as transport, routing, and other TCP/IP protocol stack operations Application security refers to security concerns at a higher level—the level of applications

10/102

Network security
●

In the late '90s, the TCP/IP protocol stack was under threat, with various DoS/DDoS/ penetration attacks such as:
–

–
– – – – –

SYN flood UDP bombs Finger bombs Ping of death Broadcast storms Smurf/Fraggle attacks Nestea, Jolt, Teardrop, Bonk...

11/102

Application security
●

●

●

●

However, the last decade has seen significant improvements in Network security The ―crackers‖ or ―black-hat hackers‖ have therefore turned their attention to application security Application security was not a concern for developers until about 2-3 years back This presentation will focus on application security

12/102

Type of applications
●

●

●

For security purposes, applications can be classified as client-server or web-based The former includes all programmes running on a host with no or local back-ends These applications are usually written in a language such as C/C++/Java/VB etc, and have different security implications as compared to web apps

13/102

Some common non-web exploits

14/102

Buffer overflow
●

●

●

Buffer overflow is a commonly-seen problem with programmes written in C, C++ or assembler Java, C# or VB are not usually affected by this problem Many of the system utilities (eg., named, sendmail, ftpd) are written in C, and are hence vulnerable

15/102

Buffer overflow
●

●

●

Buffer overflow happens when data that is too large is copied into a buffer When this happens, the extra bytes overwrite some part of the memory What this does depends on the OS and the program, but in general, something bad happens

16/102

Trashing the stack
●

●

●

What the cracker does goes beyond merely crashing the programme The cracker overwrites memory in such a way that the return address of a function (on the stack) is overwritten by the address of a function that s/he has written Typically this short function spawns a shell. Such a shell will have full privileges of the original programme

17/102

printf exploits
●

●

●

The printf function prints formatted strings. It is usually difficult to crash printf, but there is one exception The %n format specifier of printf writes to a pointer (all other FSs read a variable and prints it). This FS writes the number of strings output so far The function does not check the validity of the destination address
18/102

Printf exploit
// vulnerable
●

void main(int ac,
char *av[]) { printf(av[1]); } // Immune void main(int ac, char *av[]) { printf(“%s”,av[1]); }

This code prints out the first command line argument, but is vulnerable

$ a.out “hello” hello $a.out “%n%n” segmentation fault

19/102

Vulnerable APIs
●

The following have been identified as dangerous to use
– – – – –

–
–

strcpy,wcscpy,lstrcpy and mbscpy strcat, wcscat, lstrcat memcpy sprintf, printf, scanf, sscanf strlen gets The insertion operator ―>>‖ of C++

20/102

Cryptography for security
Some basic concepts

21/102

Cryptography
●

●

●

Cryptography has become a main element of data security today Cryptography is defined as the science of obscuring and de-obscuring data for the purpose of rendering it inaccessible during storage and transmission Cryptography depends on algorithms that are computationally expensive to break

22/102

Security issues

●

● ●

Confidentiality (message should not be read by others) Authentication (confirming identity) Integrity (message not altered in transit)
23/102

Storing passwords
●

●

●

On most situations, security starts with storing passwords, as most authentication techniques are password or passphrase-based Storing passwords in plaintext is highly risky, as all passwords will be exposed if an attacker gains control to the system In most modern operating systems, the password is not stored at all

24/102

Hashes
●

●

●

●

Hashes are one-way functions. Any string can be hashed to a fixed-length hash, but it is impossible to get the original string back from the hash Well-known hashing algorithms are MD5, SHA1, both available in Javascript Most OSes store only the hash of the password. It is computationally impossible to get the password from the hash. Authentication is done through hashing the password entered by the user and comparing

25/102

Salted hash
●

●

●

Hashing is not secure against brute force or replay attacks. For additional safety, a random number (based on session, time etc) called the ―salt‖ is used Rehashing the salt is called ―salting‖ a hash: – Hash the first string – Append the salt to the hash – Hash it again Salted hashes are much more secure, as each password may be hashed with a different salt, thus increasing the computational complexity

26/102

Encryption
●

●

●

Encryption refers to transforming data (―plain text‖) through a series of arithmetical operations into a unreadable form (―cipher text‖) Encryption uses a ―key‖ (usually a string) for added security The cryptographic strength of the encryption depends on the algorithm and the key length

27/102

Symmetric key crypto
●

● ●

Both encryption and decryption are done using the same key in this case Reasonably good security and performance But several problems – transporting the key – Secure storage of too many keys (one per peer) – Prone to brute force attacks (a DES message was broken in 4 months by brute force). Can be made even more secure by sequential encryption (3DES)

28/102

29/102

Public key crypto
●

●

●

●

Public (or asymmetric) key crypto operates with two keys—one public key and the other private key Text that is encrypted with one key can only be decrypted with the other key A person distributes his public key to all his friends (and enemies) who would like to communicate with him either directly, or through a certifying authority He keeps his private key secure, and only known to himself

30/102

31/102

32/102

PK crypto
●

●

●

There is no need of a secure key exchange as in the case of symmetric key crypto PK crypto is computationally heavier than symmetric key crypto, leading to performance problems In many cases, a combination of the two is used, where the PK is used for secure transmission of the symmetric key

33/102

Digital signatures
●

●

●

If a message should be readable but not modifiable, a digital signature is used to authenticate the sender Bob writes a message and computes its hash. The hash is encrypted with Bob's private key and the resulting ―signature‖ is appended to the message Alice confirms that it is Bob who sent the mail, by decrypting the signature with Bob's public key, recomputing the message hash and comparing the two
34/102

Digital Signatures

Bob signing his message

Alice verifying Bob
35/102

Digital certificate
●

●

●

While interacting with unknown parties over the web, this scheme is not sufficient. The identity of Bob (that it is really Bob and not someone else using his name) needs confirmation This requires an additional document, a digital certificate Certificates are usually issued by globally trusted agencies

36/102

Digital certificate
●

Consists of:
– – – –

Issuer Validity Subject Site address Encrypted PK

Issuer's name (eg., Verisign, Thawte) Validity duration Subject's name and site address Subject's public key encrypted with CA's private key

37/102

Digital certificates
●

●

●

When Alice gets Bob's message, she asks for his digital certificate and public key She downloads the CA's public key, decrypts the certificate to obtain Bob's public key, and compares it with the key that she obtained from Bob This is the basic schema used for SSL

38/102

SSL/TLS
●

●

●

●

●

SSL secures point-to-point traffic (though not necessarily end-to-end traffic) SSL can use self-certification, in which case users cannot cross-check the server's identity A Certifying Agency (CA) issues verifiable certificates CA's require one or more dedicated IPs, domain names, and other information for issuing certificates Certificates are issued for a valid period, and can be revoked
39/102

A simplified view of SSL
ALICE
“Hi, I'm Alice. Who are you?”

BOB

“I'm Bob. Here's my certificate” “Alice, this is Bob” + {digest[Alice, this is Bob]} ~ Bob's PrivKey

“Prove it!”

If found ok, sends: {A symmetric key}~Bob's PubKey

Decrypts using PrivKey, and starts transmission using symmetric key

Continues to use the same symmetric key
40/102

Web exploits

41/102

The web
● ●

●

●

●

The web was not designed with security in mind The typical web user is not very educated, nor security conscious In fact, even some System Administrators are not sufficiently security conscious! The wide distribution of access points (eg., cyber cafes) also makes building secure applications a challenge A large number of applications use the web (informational, educational, entertainment, transactional, governance...) as transport

42/102

Common web security myths
●

● ●

●

The user will always submit the ―appropriate‖ kind of data Javascript will take care of validation Our site runs on SSL with 128-bit encryption—so we are absolutely safe Server side validation is a waste, as we are already doing client-side validation

43/102

Browser proxy tools
●

●

●

Proxies are employed in many situations such as offices and cyber cafes to share an Internet connection among many machines There are several browser proxies that are capable of not only examining data that passes through them, but also modifying the data. These are a tool for hackers Examples are Achilles (Windows) and Paros (multiplatform)

44/102

Common web exploits
● ● ● ● ● ● ● ● ●

URL manipulation Password guessing Proxies and man-in-the-middle attack HTML comments ―Forgot password‖ implementations Keystroke loggers SQL injection Command injection XSS
45/102

HTTP Basics
● ●

●

●

HTTP is based on a series of request-response cycles Requests are originated by the client, while the server sends out the requested resource (provided it exists, and user is authorised) HTTP is a stateless protocol—the server closes the connection immediately after sending out the required resource Built-in security features of HTTP is very minimal and insufficient

46/102

GET and POST
●

●

●

Requests are made by the client using either GET or POST header methods (there are three more methods which are for specialized use) In both, the browser sends across a resource name, together with optional additional data (eg., form data) to the server GET is simpler and has size limitations. In theory, GET is to ask for information, while POST is to contribute information. Programmatically, they are almost identical in the new frameworks like PHP, ASP or JSP

47/102

HTML clues
●

●

Programmers may leave clues in the code about user names In some cases, the passwords can be guessed, especially if the hacker knows the victim reasonably well

48/102

Hidden field manipulation
●

●

Hidden fields can easily be seen and modified from within a proxy Therefore, storing important information (eg., userid, password, PIN) in hidden values is a very bad idea

49/102

Spoofed links in emails
●

●

●

It is easy to spoof email links in HTML-based emails (also used in phishing) An innocent-looking link may actually be going somewhere dangerous There have been cases where entire sites have been dynamically displayed through a back-to-back connection

50/102

JavaScript validation
●

●

Some programmers repose too much faith in client-side validation such as that using JavaScript However, such validation becomes totally useless in the face of proxies that modify parameters on the fly

51/102

Unprotected admin scripts
●

●

●

Many sites have admin interfaces for changing settings All admin interfaces are usually protected using password or SSL However, sometimes some of the other admin components are accessible even without a valid login, as the adminstrators think that since no link exists, people can't make out that such pages exist

52/102

Weak access control
●

●

If web directories are not given proper access privileges, an ordinary form can become vulnerable This can be used to get contents of sensitive files

53/102

“Forgot password” scripts
●

●

●

Many sites have a ―Forgot password‖ feature that often becomes a security flaw These scripts are not sufficiently tested as they are of low priority These days, ―Forgot password‖ scripts are implemented through security questions that make it harder to break

54/102

Weak cookies
●

●

●

●

Session handling is done usually through cookies However, many server-side programmes created cookies in a simplistic manner These cookies can be reverse-engineered to hijack sessions Ideally, session validation should be based on cookies + IP or some other parameter

55/102

XSS
●

Cross-site scripting is a complex process:
– – – – – –

Attacker logs in into an on-line forum He makes an entry here that will be read by anyone who wants to read it Embedded in his routine text entry is a <script>... </script> section which contains malicious code. He logs out The site is visited by some unsuspecting victim who clicks the attacker's entry The victim's browser executes the malicious code, which sends sensitive information to the attacker

56/102

XSS: vulnerable targets
●

Targets are
– – –

–
–

Bulletin boards Blogs Chatrooms Guest books Anything else that reflects browser inputs without validation

●

Sanitize data (ie., remove HTML, ―<‖ and ―>‖ and several other characters in postings)

57/102

Command injection
●

●

Weakly coded applications are vulnerable to injection of commands into a form Since can Unix take multiple commands in a single line, all the user has to do is to enter his command after a semicolon (which is a command separator)

58/102

SQL injection
●

●

●

●

A serious flaw with dynamically-built SQL queries Can result in significant loss of confidentiality or even loss of entire database Always use PreparedStatement or CallableStatement in Java or ADO in .NET Validate and Sanitize data before using

59/102

URL manipulation
●

●

● ●

When GET is used for form submission, all the fields are exposed in the URL line in the browser This makes it easy to change things on the submitted query Can be avoided by using POST instead of GET If GET is required for some reason, then cryptographic protection of parameters is required

60/102

Fail-open authentication
●

●

●

Hackers armed with proxies can provide unexpected inputs to the application (so never trust client-side validation alone) Some applications are coded in such a way that when they fail, they leave the door wide open...! This can be a potent tool for the hacker

61/102

Browser refresh
●

●

Browsers cache entire submissions in their memory Even after logout (and session invalidation), these can be retrieved by the back key followed by a refresh if the browser is not closed

62/102

Phishing
●

●

●

A high-tech scam of spoofing trusted sites by misleading links (esp. in HTML mail or a link like www.ebay.com@members.tripod.com) Aimed to fool inexperienced (and some experienced) users Can result in loss of user credentials and financial loss

63/102

64/102

65/102

66/102

67/102

Name similarities
● ● ● ● ● ● ●

●

www.mcrosoft.com www.whithouse.org, www.whitehouse.com www.ebay.com@members.tripod.com www.nasa.com WWW.VERlSIGN.com www.paypa1.com https://www.paypal.com:ac=alksdjff@KI54fT.WoRlDiSp NeTwOrK. CoM/i.CgI? billing@yourdomain.com <a href= http://&#119;&#119;&#119;.&#104;&#97; &#99;&#107;&#101;&#114;.com>Hello</a>

68/102

Evading phishing
● ●

●

●

User awareness (―look carefully twice‖) Never click on an email link to go to a financial site Never respond to financial mail immediately—always cross check off-line Look at the status bar to see whether a link points to the real site

69/102

Keystroke loggers
● ●

● ●

●

Keystroke loggers can be hardware or software Software loggers are trojans that log all keystrokes into a file (or email it out to the perpetrator daily) Hardware loggers can be impossible to detect These can defeat most of the methods that we discussed so far More sophisticated techniques are required to beat these: graphical entry of login (with the mouse),

70/102

Passwords in memory
●

●

●

Passwords remain in the memory of the computer that runs it (even when it can't be displayed in the password field) If a running programme can be examined by a memory scanner, the password can be destroyed Even after the programme exits, the password can be discovered unless it is explicitly cleared programmatically (cat /dev/mem > /tmp/mem)

71/102

Proxies and SSL
●

●

●

●

Web proxies can defeat SSL by the classic man-in-themiddle strategy When the client asks for a https site, the proxy in turn contacts the site and gets its certificate It then gives a valid—but self-issued—certificate to the client. Most clients will now pop up a box saying the certificate is untrusted (and most uneducated users will continue browsing) From then on, there are two back-to-back secure connections: client-proxy and proxy-server

72/102

Pharming
●

●

●

Pharming exploits vulnerabilities on DNS servers and their caches The strategy is to hijack a website's DNS entry, thereby redirecting the site to a bogus page, even when the user types in the correct name Many sites such as ebay.de, hushmail.com and panix.com were hijacked like this

73/102

Evil Twin
●

●

●

●

An ―evil twin‖ is a spoofed wireless hotspot that pretends to be legitimate This has happened in restaurants, public places and even conferences In April 2005, fraudsters set up an Evil Twin in a conference in London, pretending to be the official WiFi providers When users connected, not only were their passwords stolen, but they were also infected with an array of about 45 viruses

74/102

OWASP Top ten most critical vulnerabilities

75/102

1. Unvalidated input
●

●

●

Attackers can tamper with any part of the input, including the URL, querystring, headers, cookies, form fields and hidden fields Resulting vulnerabilities include buffer overflow, format string, forced browsing (ie., deep link browsing), injection etc Server-side validation is absolutely essential

76/102

2. Broken access control
●

●

● ● ●

Insecure access control IDs (Eg., admin, manager, editor) Forced browsing past by-passable ―deep‖ links Path traversal (―..\..\target_dir\secret_file‖) Inappropriate file permissions Browser caching from insecure locations (libraries, cyber cafes)

77/102

3. Poor session management
● ● ● ● ● ● ●

Poor password strength No locking after fixed number of wrong logins Insecure password change mechanisms Plaintext password storage Insecure transmission of credentials Insecure transmission of session ID Passing of credentials in GET

78/102

4. XSS (Cross-site scripting)
● ●

●

●

Can be stored or reflected Malicious portions often encoded (including using Unicode) Any embedded content including ActiveX, VBScript, Flash or Shockwave can be malicious HTML user input must be sanitized in order to prevent this

79/102

5. Buffer overflows
●

● ●

Due to inappropriate use of certain C/C++ functions that attack the stack Can be detected by a security code review Earlier several Internet applications were vulnerable (eg., sendmail, named), but now these have been fixed

80/102

6. Injection flaws
● ●

●

●

Injection of commands or SQL into forms Command injection generally a problem of Perl, python and other interpreted languages SQL injection is a consequence of näive SQL code (dynamic code as opposed to prepared statements) Always validate and sanitize user data

81/102

7. Improper error handling
●

●

Error messages sometimes reveal too much information about the platform, server, and application This can provide clues to enterprising attackers

82/102

8. Insecure storage
●

Storage of sensitive information (credit card numbers, PIN numbers) on insecure storages
– – – – – –

Failure to encrypt critical data Insecure storage of keys, certificates, passwords Poor sources of random numbers Poor choice of algorithms Attempting to invent own encrypting system Failure to include support for encryption key changes and other maintenance

83/102

9. Denial of service
●

●

●

Difficult to distinguish between attacks and genuine requests Therefore, difficult to protect against such attack Fixing process/user quotas for CPU time and memory may help

84/102

10. Insecure configuration mgmt
●

Configuration/Deployment management may also have problems:
– – – –

–
–

Unpatched flaws in server-side software Misconfiguration allows directory listings and directory traversal attacks Unnecessary files (default, backup, samples..) Unnecessary services enabled Default ―out-of-the-box‖ accounts & passwords Admin/debug functions enabled

85/102

Why look for back-doors when you can waltz in through the front door?

Welcome to Google hacking!

86/102

Google hacking
●

●

●

As many first-time programmers and administrators took to the Internet, most using tools that are meant for novices, security lapses have become quite common Google, through its powerful API, can be used to quickly pinpoint such vulnerabilities Since Google indexes sites without even the administrator noticing, many sites have found their sensitive documents available in public

87/102

Google search operators
●

The site: operator can be used to list down all pages in a given site
–

eg., ―site:http://www.microsoft.com XP‖ will locate all pages at Microsoft that contains the word XP

●

The inurl: operator locates a word in the URL string
–

eg., inurl:index.of “parent directory” gives several sites that have inadvertently exposed whole directories

88/102

Google operators
●

●

●

The same command can be used to locate servers with a particular version number (quite handy for locating vulnerable releases) The query ―allintitle:Welcome to Internet Information Server‖ would fetch the list of all outof-the-box installations of IIS The filetype: operator can show selected file types (eg: ―inurl:+edu inurl:grades filetype:xls‖

89/102

Weak CGI spotting
●

There are several weak CGI vulnerabilities that can be spotted using Google
–

–

/cgi-bin/web2mail.cgi (mail out /etc/passwd) /random_banner/index.cgi?image_list= alternative_image.list&html_file=../../../../../etc/pas swd (display passwd as a banner)

90/102

File spotting
●

Some files may contain ―interesting‖ information
– – – –

Personal history and details Medical history Organizational records Financial information

●

Google has recently added number spanning searches (eg., 15-20), and hackers have already used it for searching for credit card numbers (―visa 4356000000000000-4356999999999999‖)

91/102

Spam, Spim, Scams and cyber terrorism

92/102

There's a popular saying that the only secure computer is one that's turned off. Clever, but false: The pretexter simply talks someone into going into the office and turning that computer on...
Kevin Mitnick, Cracker turned security consultant

93/102

“Social Engineering”
●

●

●

The weakest link in the security chain is often the unprepared user/staff member, who gives out seemingly-inoccuous pieces of information In most corporate attacks, the attacker uses the tools of social engineering, together with good planning, an intimate knowledge of the environment/technology and audacity Kevin Mitnick, the legendary phreaker-cracker has outlined the power of social engineering in his masterpiece, ―The Art of Deception‖

94/102

Spam
●

●

●

●

Spam has become a major consumer of bandwidth, disk space and users' time, with imputed costs running into millions of dollars All kinds of material ride the Net as spam: chain letters, advertisements, virus hoaxes, scams... Never reply to spam, as the spammer now knows that he has a valid email ID Despite legislation, spam filters and smart mail clients (eg., gmail), spam occupies about 30% of all email today, growing at about 20% each year

95/102

Spam and Spim
●

●

●

●

At this rate, 99% of all email will be spam by the year 2009 ! Some spammers user automated techniques (eg., a graphic image embedded in a spam through a CGI script) to separate real email ids from fake ones Spim is similar to spam, but the carriers are IMs (Instant Messengers) Spim is set to treble from 400 million in 2003 to 1.2 billion this year

96/102

Scams
●

There are several scams that are using the Internet and print media to circulate:
– – – – – – –

–

Nigeria (419) scam Auction fraud Patent medication (Cialis, herbal viagra) Pump-and-dump stock market scam Viruses Chain letters (―Microsoft will pay you $25‖) Identity theft Lottery

97/102

Scams
– – – – – – – – – –

―Work from home and make big money‖ Health and diet scams ―Spy on anyone‖ Get credit card numbers and site passwords Scholarship scams Telephone billing scam (bills are charged to telephone accounts—the lost pet scam) Get a college degree Get software cheap 9/11 donations Free computers (cameras, printers...)

98/102

Auction scams
● ● ● ● ●

● ● ●

●

Misrepresentation of item or value Failure to ship Failure to pay (bounced cheques, stolen cards) Shilling (artificially boosting bids by accomplices) Bid shielding (using phony bids to scare away real bidders and finally retracting the bid) Piracy (of music or other counterfeit material) Fencing (selling stolen goods) Buy and switch (buying and then returning a different, but damaged item) Shell auction (no merchandise exists)

99/102

Identity theft
●

●

●

When someone appropriates your personal information in order to commit fraud or theft Credentials (Name, email, address, social security number, credit card number) can be obtained through a variety of mechanisms (including a lost wallet) In the West, ID theft can be serious, as the fraudster can completely take over the ID (and deny the original owner of medical care, bank credit and even mail!)

100/102

Cyberterrorism
●

●

●

After 9/11, there is substantial attention on the use of the Internet by terrorist groups These groups use techniques such as steganography to multicast messages Apart from images and sounds, the latest discovery is that secret messages can be hidden in in the most common mail--Spam!

101/102

Conclusions

102/102

Conclusions
●

●

●

There are a large number of motivated and malicious people who attack sites, be it for profit or the thrill Until we use better tools, techniques and discipline, there is the risk of our sites being defaced, used as the base of attacking other sites, or worse, losing valuable information The age of ―innocent coding‖ is over, and it is time that every site on the Internet paid attention to application security

103/102

References
●

● ● ● ● ● ●

―Innocent Code: A Security Wake-up Call for Web Programmers‖ by Sverre H. Huseby CERT, http://www.cert.org/ OWASP, http://www.owasp.org Johnny Long, http://www.ihackstuff.com ―The Art of Deception‖ by Kevin Mitnick Wikipedia (http://www.wikipedia.org) pages on security ―The Ten Immutable Laws of Security‖ at http://www.microsoft.com

104/102

Thank you.

105/102


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:22
posted:11/6/2009
language:English
pages:105