1. Team-9
Anirudh Gaur (B.Tech)
Rahul Sihag (B.Tech)
Bharatram Natarajan (M.Tech)
Sanjay Bankapur (M.Tech)

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. 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. Security Requirements
Assets:
•Data like Email content, User login credentials, User account information, Configuration file,
Email client code.
•Email Server.
•Handheld devices.

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. 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. 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. Security Code Issue & Correction
Fragment 1
void 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. 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. 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 read
RegQueryValueEx ( hKey, NULL, NULL, NULL,&cbBuff );
...
// Read ALL the data!!! Not verifying if cbBuff is greater
RegQueryValueEx ( hKey, NULL, NULL, bBuff, &cbBuff );
than MAX_BUFF
…
#define MAX_BUFF (64)
BYTE bBuff[MAX_BUFF];
DWORD cbBuff = 0;
…
// Determine how much data // to read
If(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. 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. Secure Design Patterns
Thin 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 doesn't 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. Thin device: replicated data, with
device-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. Protected process: local information
processing in a secure "bubble"
 It allows data to be processed locally.
 Sensitive information sits inside a compartmentalised
processing environment that is separated from the
user's 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. Protected data: documents protect
themselves 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. Suggestion
SoftCorp should not go for complete redesign, since complete
code is already done. Hence below strategy can be used for
security review of the product:-
 Threat Modelling
 Test Planning
 Test Execution
 Security Bug Fixing
Applicable Tests:
 Authentication Testing
 Input Validation Testing
 Session Management Testing
 Encryption Testing
 Application Testing

17. Benefits of Threat Modelling
These 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. Threat Modelling Process:
1. Identify Security Objectives
2. Create an Application Overview
3. Application Decomposition
4. Identify Threats
5. Mitigation Measures

19. Use Case: Sending an e-mail
Security Objectives:
Confidentiality (No Eavesdropping) – Any
third person having access to my network should
not be able to read my mail.
Privacy - Information may be used to tell in which
city you are located or even to find out what your
address is in some cases.
No Spam and Unwanted Email
Integrity (No Tampering) - No data should be
modified during the transmission of an email.
Non-repudiation

20. Application Overview
Users - Senders with authenticated account
at email provider
Technologies -
Network : Wireless network
Protocol : SMTP (Simple Mail Transport
Protocol)
Description -
1. Compose an email
2. Press the send button

21. Application Decomposition

22. Threats
(1) Disclosure of Information: Most of emails are
transmitted in the clear (not encrypted) text. By means
of some available tools, persons other than the
designated recipients can sniff the packets and can read
the email contents. Email messages are stored on SMTP
servers in plain, unencrypted text. Backups of the data
on these servers may be made at any time and
administrators can read any of the data on these
machines.
(2) Modification of messages: Email contents can be
modified during transport or storage.

23. (3) Repudiation: Because normal email
messages can be forged, there is no way for you
to prove that someone sent you a particular
message. This means that even if someone DID
send you a message, they can successfully deny
it.
(4) Identity Theft: If someone can obtain the
username and password that you use to access
your email servers, they can read your email
and send false email messages as you.

24. Threat Tree
Figure: Attack Tree for Information Disclosure

25. Mitigation
Encrypting an EMAIL message
Encrypt the message before sending. Use
encryption algorithms like authenticated Diffi-
Hellman key exchange or RSA Algorithm. This
solves the problem of eavesdropping and
Disclosure of Information

26. Encrypting the TRANSMISSION or RECEIPT
of an email (SMTP/POP/IMAP over SSL/TLS)
While connecting to mail server (whether
sending or receiving), email credentials
(username and password) are encrypted,
protecting them from being intercepted by
malicious users as they traverse the internet from
email client to mail server.

27. Security with Escrow Encryption
Escrow encryption uses a trusted “encryption middleman” to
provide the same security offered by asymmetric key
encryption, but with universal compatibility.
The sender ands receiver connects to the middleman’s web
mail portal on a secure SSL connection.
There will be no information disclosure in communication
channel and no identity theft as both sender and receiver are
on secure SSL connection.
There will be no repudiation as the middleman validates the
sender.
The middleman encrypts the message and stores it on his
server. Therefore no one can modify the message because it
never leaves the middleman’s server and it will be secure
even in backups.