Web Security

1. Web Security Amit Kulkarni February 17, 2004

2. SSL / TLS • Developed by Netscape, supported by Microsoft and other developers • TLS is latest version of SSL • Works on top of TCP/IP, below higher-level protocols (e.g. HTTP, ICMP, etc.) • Based on Symmetric / Asymmetric Encryption

3. How SSL Works • Using Public Key Cryptography A  B random-message B  A {random-message}bob’s-private-key [Alice uses Bob’s public key to decrypt the message and authenticate Bob]

4. How SSL Works (contd.) • Handing out public keys A  B hello B  A Hi, I am Bob, bob’s-certificate A  B prove it B  A Alice, this is Bob {digest[Alice, This is Bob]}bob’s-private-key Certificate is a way to bind public key to a name. It also has Issuer’s name, expiration date, etc.

5. How SSL Works (contd.) • How Digital Certificate guards against “Man-in-the-middle” attack A  M hello M  A Hi, I am Bob, bob’s-certificate A  M prove it M  A ??? But, asymmetric key cryptography works slower than symmetric key cryptography. There is a workaround…

6. How SSL Works (contd.) • Exchanging a secret A  B hello B  A Hi, I am Bob, bob’s-certificate A  B prove it B  A Alice, this is Bob {digest[Alice, This is Bob]}bob’s-private-key A  B ok bob, here is a secret {secret}bob’s public-key B  A {some message}secret-key

7. How SSL Works (contd.) • One more loophole A  M hello M  B hello B  M Hi, I am Bob, bob’s-certificate M  A Hi, I am Bob, bob’s-certificate A  M prove it M  B prove it B  M Alice, this is Bob {digest[Alice, This is Bob]}bob’s-private-key M  A Alice, this is Bob {digest[Alice, This is Bob]}bob’s-private-key A  M ok bob, here is a secret {secret}bob’s public-key M  B ok bob, here is a secret {secret}bob’s public-key B  M {some message}secret-key B  M Garble[{some message}secret-key] Note that Alice will try to interpret this garbled message

8. How SSL Works (contd.) • Use of Message Authentication Code [MAC] MAC := Digest[some message, secret key] A  B hello B  A Hi, I am Bob, bob’s-certificate A  B prove it B  A Alice, this is Bob {digest[Alice, This is Bob]}bob’s-private-key A  B ok bob, here is a secret {secret}bob’s public-key B  A {some message, MAC}secret-key Now Alice can detect the tampering and will stop the conversation!!

9. SSL / TLS • Size of key decides strength of encryption. (40-bit, 56-bit encryptions are considered weak. They can be cracked in about a week) • Private Certificate Authorities: Used when certain kind of trust relation exists between the client and the server • Public Certificate Authorities: Used when no other relation exists between the client and the server

10. HTTPS • Secure Hypertext Transfer Protocol • Client requests a secure transaction by accessing an HTTPS URL and informs server about the encryption algorithm and key sizes it supports • Server sends back its digital certificate issued by CA • Client verifies the certificate, generates a session key, encrypts t with server’s public key and sends it back to server • Server decrypts the session key and uses it for symmetric encryption during further communication in the session

11. Instant Messaging • Security Issues • IM systems can transport sensitive and confidential data over public networks in unencrypted form. • IM systems do not prevent transportation of files containing viruses • Misconfigured file sharing can vide access to system files, passwords, etc. • To monitor and prevent IM traffic network can be configured to deny access to certain domains (e.g. block yahoo.com for Yahoo messenger)

12. Vulnerabilities of Web Tools • JavaScript • Code embedded in HTML document. Downloaded to and executed on client side. • Security loopholes exist in browsers, which could be exploited by JavaScript code in following ways: • Monitoring Web Browsing • Read System files, passwords • Read browser’s preferences (like email id, mail server, etc.) • Most browsers provide patches to fix JavaScript related vulnerabilities.

13. Vulnerabilities of Web Tools (contd.) • ActiveX • This is a Microsoft technology that provides tools for linking desktop applications to WWW content. • e.g. MS Office applications • An attacker could embed harmful macros into MS Office documents, which get executed without client’s knowledge. • These macros could gain access to sensitive information, edit registry settings, use client system to target other systems, etc. • Patches are available to address vulnerabilities exposed by ActiveX.

14. Vulnerabilities of Web Tools (contd.) • Cookies: Text files created by web server, stored on Web surfer’s disk drive • They contain information about user’s personal preferences, authentication information, browsing statistics, etc. • Any Web Server can access all the cookies apart from his own, and thus can gain access to sensitive information. • Browser has option not to accept cookies.

15. Vulnerabilities of Web Tools (contd.) • Buffer Overflow: Can be triggered by sending large amounts of data that receives capacity of receiving application within a given field • 2 prerequisite objectives to corrupt receiving buffer and alter program’s control flow to trigger desired action: • Place the necessary code into program’s address space • Direct the application to read and execute embedded code by manipulating registers and memory • In this attacker can gain access to system prompt, examine System variables, read file system, etc. • These are not easy to coordinate • Caused by poor application programming that does not check the size of input field.

16. Vulnerabilities of Web Tools (contd.) • Signed Applets • Unsigned applets operate within a set of restrictions called “Sandbox Model” (e.g. accessing system properties, files on the hard disk, connecting to other web servers, etc.) • Digitally signed applets do not have these restrictions. (Configurable by the user) • Providing digital signature with applet code involvs generating private/ public key pair and obtaining a certificate.

17. Vulnerabilities of Web Tools (contd.) • CGI • Client passes data to the server and requests execution of a script (perl, shell script, etc) 1. Send HTML Form to client Client Web Server 2. Fill out form on Client 3. Submit request 4. Execute program on Server

18. Vulnerabilities of Web Tools (contd.) • CGI • Malicious user can modify the parameters to be passed to the executable script. • In this way, user can gain access to sensitive files on the server. • To protect against these, use Intrusion Detection system, create user groups with different permissions to access files, validate security of the CGI scripts before deploying them.

19. Vulnerabilities of Web Tools (contd.) • SMTP Relay • SMTP is standard Internet protocol for global e-mail communication. • Simple by design because of high utilization • SMTP relay occurs when a SMTP server has to forward mail to client using some other SMTP server. (e.g. mail from abc@hotmail.com to pqr@yahoo.com ) • Malicious user can exploit this concept and hide the real origin of the message

20. Vulnerabilities of Web Tools (contd.) • Transaction between 2 SMTP Servers HELO mail.example.com 250 mail.anotherexample.com Hello mail.example.com MAIL FROM: person1@xample.com 250 person1@xample.com Sender ok RCPT TO: person2@anotherexample.com 250 person2@anotherexample.com Recipient ok DATA 354 Enter mail, end with “.” on a line by itself From: To: . 250 0AA08757 Message accepted for delivery A Malicious user can forge variables to hide its identity

21. Vulnerabilities of Web Tools (contd.) • An email message is “stamped” by every SMTP server along its way to destination. This could be used to track the real origin of the message. The following is a typical “Received” header From forged-address@example.com Received: from example.com ([172.16.35.44]) by mail.anotherexample.com (8.8.5) for <receiver@anotherexample.com> DNS lookup can verify if 172.16.35.44 is same as example.com

22. References • How SSL Works • SMTP Command Syntax • Fundamentals of Network Security, Canavan John • http://www.howstuffworks.com