Mobile Email Security


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mobile Email Security

  1. 1. Team-9 Anirudh Gaur (B.Tech) Rahul Sihag (B.Tech)Bharatram Natarajan (M.Tech) Sanjay Bankapur (M.Tech)
  2. 2. Introduction SoftCorp is an emerging software development company and aims at leadership position in the upcoming mobile computing market by developing cutting edge products that address the entire range of handheld user needs. SoftCorp product development team had worked on office applications such as text processors, image editors, and even a small spreadsheet application. Team was quite clear that to develop a good email client for the PDAs/Mobile devices by which  Addressing the world that SoftCorp is arrived into the PDA software market, and  By development of this product would also help them to get more familiar with the handheld programming environment. After brainstorming, the team listed all the required features and they found the product called “EazeeMail” by their competitor KurApps. Team has decided to use this product as a benchmark for developing of Mobile Email Client (MEC). SoftCorp team found that EazeeMail didn‟t support multimedia based email such as support for audio clips, pictures etc. They decided that they will try to provide support for the multimedia emails.
  3. 3. Topics to cover Identify and specify various security requirements by using use/abuse case diagram. For the identified security requirements indentify potential vulnerabilities and threats for this system. Identify the security loop holes from the given fragmented codes. Identify at-least 4 design patterns that can be used to enhance the security for this product. By taking any 1 use cases related to email functionality, will perform thread modelling and generate threat tree for the same. Does SoftCorp requires redesigning of the product to ensure all security?
  4. 4. Security RequirementsAssets:•Data like Email content, User login credentials, User account information, Configuration file,Email client code.•Email Server.•Handheld devices.
  5. 5.  The need for prevention of virus, malicious software which if present in the handheld devices will result in the confidentiality, integrity, privacy violation. The need for securing the connection between the client and the email server in order to maintain data confidentiality, integrity, privacy. The need for preventing spam mails in order not to overload the server and handheld devices. The need for preventing phishing in email in order to protect the customer details and maintaining their trust, privacy. The need for protecting the mobile email client code for maintaining integrity constraint and confidentiality constraint, privacy. The need for protecting the configuration file from being accessed by anyone except the mobile email client for maintaining confidentiality, integrity.
  6. 6. Security Threats & Vulnerabilities Virus - Responsible for destructive payloads, destroying data and bringing down entire mail systems. E.g.: Internet Worms, Mass mailer viruses tend to stay longer even if antivirus products have included protection against them in their products leading to loss of money, resources ,effort to recover from such incidents, loss of productivity, corrupt or lost data, loss of user confidence. Phishing (Identify Theft) – It targets the customers of financial institutions and high- profile online retailers by luring them to spoofed websites and give their credentials. This leads to personal information revelation to other people thereby violating the confidentiality of the data. Spam – It bring down system availability and also can carry viruses, malicious code and fraudulent solicitations for private information. It overloads network and server resources. Adversary who are eavesdropping on the channel between the client and the email server, capturing the data and modifying the data according to his need and resending again.
  7. 7. Solutions to Threats Use of anti-virus software which will remove virus, malware program and un-trusted program, anti spam solution like blacklist the list of spam users rather than deleting the mails every time the mail comes, enabling the email spam filter and anti phishing solutions like Caller ID by Microsoft, Sender Policy Framework by Meng Wong, Domain Keys by Yahoo etc. Use of secure protocol like SSL(Secure Socket Layer). The wrapping of client code, configuration file with anti-virus software, anti-spam solution, anti-phishing solution which will act as the firewall for the client code.
  8. 8. Security Code Issue & CorrectionFragment 1void f(char *src1, char* src2) Threat of changing both src1 and src2 in this function{ char dest[DEST_SIZE]; // check to make sure first string fits if (strlen(src1) > sizeof(dest)) return; strcpy(dest, src1); // copy as much of the second string as will fit strncat(dest, src2, sizeof(dest)); strncpy() and strncat() functions are a source of buffer ... overflow vulnerabilities.}void f(const char *src1, const char* src2) { char dest[DEST_SIZE]; // check to make sure first string fits if (strlen(src1) > sizeof(dest)) return; strncpy_s and strcat_s functions are strcpy_s(dest, src1); secure for buffer vulnerabilities. // copy as much of the second string as will fit strncat_s(dest, src2, sizeof(dest)); ...}
  9. 9. Fragment 2:void *ConcatBytes(void *buf1, size_t len1, char *buf2, size_t len2){ void *buf = malloc(len1 + len2); if (buf == NULL) return; // allocation failed Threat of changing both buf1 and buf2in this function memcpy(buf, buf1, len1); memcpy(buf + len1, buf2, len2); ... Void pointers can store any data type & hence data type} mismatch will occur with memcpy.void *ConcatBytes(const void *buf1, size_t len1, const char *buf2, size_t len2){ void *buf = malloc(len1 + len2); if (buf == NULL) return; // allocation failed memcpy_s(buf, len1, buf1, len1); memcpy_s(buf + len1, len2 buf2, len2); ...}
  10. 10. Fragment 3:#define MAX_BUFF (64)BYTE bBuff[MAX_BUFF];DWORD cbBuff = 0; Functions return value is not verified… to check status of request// Determine how much data // to readRegQueryValueEx ( hKey, NULL, NULL, NULL,&cbBuff );...// Read ALL the data!!! Not verifying if cbBuff is greaterRegQueryValueEx ( hKey, NULL, NULL, bBuff, &cbBuff ); than MAX_BUFF…#define MAX_BUFF (64)BYTE bBuff[MAX_BUFF];DWORD cbBuff = 0;…// Determine how much data // to readIf(RegQueryValueEx ( hKey, NULL, NULL, NULL,&cbBuff ) > 0){ ... If(cbBuff>MAX_BUFF) bBuff=new BYTE[cbBuff]; // Read ALL the data!!! RegQueryValueEx ( hKey, NULL, NULL, bBuff, &cbBuff );}…
  11. 11. Fragment 4: … SqlConnection sql = new SqlConnection( @”data source = localhost;” + “userid = sa;password = password;” ); String sql = “select * from client where name = „” + name + “‟”; … Both UserId and Password values should Threat of SQL Injection not be hard coded in the code. Values should be read from the configuration file.…String id=getUserId();String pass=getPasswd();SqlConnection sql = new SqlConnection( @”data source = localhost;” + “userid = ” +id+ “;password=” + pass+ “;” );String sql = “select * from client where name = „” + name + “‟”;If(checkSyntax(sql) < 0) return;…
  12. 12. Secure Design PatternsThin client: process centrally, present locally Sensitive data stays centralised in hardened bunkers, with remote devices allowed views of it via thin-client terminal applications. network access is required, thin client doesnt support offline use. The advantage of thin client is that data never leaves the server - it is only rendered on the endpoint. For additional security, IT can restrict host copy-and-paste operations, limit data transfers, and require strong or two-factor authentication using SecureID or other tokens.
  13. 13. Thin device: replicated data, withdevice-kill for insurance Point-purpose devices like smartphones, for example, can keep only limited amounts of sensitive information on them. The information they keep is replicated, with master copies stored in data-centres. Because of their size, storage capacity, and comparatively modest processing power, application is limited to e- mail rather than general data processing. Using native management tools or third-party mobile device platforms like Sybase, smartphone security policies that can typically be imposed include backup and enforced encryption.
  14. 14. Protected process: local informationprocessing in a secure "bubble" It allows data to be processed locally. Sensitive information sits inside a compartmentalised processing environment that is separated from the users local operating system environment - whose security and backup properties are controlled by IT. The protected process pattern has many advantages: local execution, offline operation, central management, and a high degree of granular security control, including remote wipe.
  15. 15. Protected data: documents protectthemselves regardless of location Technologies like enterprise rights management enshrine access rules into documents directly. These rules, which rely on cryptography to enforce, apply no matter where the document rests - a key advantage. Of all the patterns in the Zero Trust data security strategy, protected data is the most fine-grained and effective because it focuses on the information, not its containers.
  16. 16. SuggestionSoftCorp should not go for complete redesign, since completecode is already done. Hence below strategy can be used forsecurity review of the product:- Threat Modelling Test Planning Test Execution Security Bug FixingApplicable Tests: Authentication Testing Input Validation Testing Session Management Testing Encryption Testing Application Testing
  17. 17. Benefits of Threat ModellingThese are some benefits of threat modelling:- Complex design level security bugs can be easily identified if we incorporate the threat modelling. More over multi-step security bugs (several small failures combining to form a disaster) are best found using threat modelling. it also will also help us to understand our application better, since we would spend time analysing the makeup of the application in a relatively structured manner. It yields useful documents which the testing team could use to test against.
  18. 18. Threat Modelling Process:1. Identify Security Objectives2. Create an Application Overview3. Application Decomposition4. Identify Threats5. Mitigation Measures
  19. 19. Use Case: Sending an e-mailSecurity Objectives:Confidentiality (No Eavesdropping) – Anythird person having access to my network shouldnot be able to read my mail.Privacy - Information may be used to tell in whichcity you are located or even to find out what youraddress is in some cases.No Spam and Unwanted EmailIntegrity (No Tampering) - No data should bemodified during the transmission of an email.Non-repudiation
  20. 20. Application OverviewUsers - Senders with authenticated accountat email providerTechnologies -Network : Wireless networkProtocol : SMTP (Simple Mail TransportProtocol)Description -1. Compose an email2. Press the send button
  21. 21. Application Decomposition
  22. 22. Threats(1) Disclosure of Information: Most of emails aretransmitted in the clear (not encrypted) text. By meansof some available tools, persons other than thedesignated recipients can sniff the packets and can readthe email contents. Email messages are stored on SMTPservers in plain, unencrypted text. Backups of the dataon these servers may be made at any time andadministrators can read any of the data on thesemachines.(2) Modification of messages: Email contents can bemodified during transport or storage.
  23. 23. (3) Repudiation: Because normal emailmessages can be forged, there is no way for youto prove that someone sent you a particularmessage. This means that even if someone DIDsend you a message, they can successfully denyit.(4) Identity Theft: If someone can obtain theusername and password that you use to accessyour email servers, they can read your emailand send false email messages as you.
  24. 24. Threat Tree Figure: Attack Tree for Information Disclosure
  25. 25. MitigationEncrypting an EMAIL messageEncrypt the message before sending. Useencryption algorithms like authenticated Diffi-Hellman key exchange or RSA Algorithm. Thissolves the problem of eavesdropping andDisclosure of Information
  26. 26. Encrypting the TRANSMISSION or RECEIPTof an email (SMTP/POP/IMAP over SSL/TLS)While connecting to mail server (whethersending or receiving), email credentials(username and password) are encrypted,protecting them from being intercepted bymalicious users as they traverse the internet fromemail client to mail server.
  27. 27. Security with Escrow EncryptionEscrow encryption uses a trusted “encryption middleman” toprovide the same security offered by asymmetric keyencryption, but with universal compatibility.The sender ands receiver connects to the middleman’s webmail portal on a secure SSL connection.There will be no information disclosure in communicationchannel and no identity theft as both sender and receiver areon secure SSL connection.There will be no repudiation as the middleman validates thesender.The middleman encrypts the message and stores it on hisserver. Therefore no one can modify the message because itnever leaves the middleman’s server and it will be secureeven in backups.