How to report a phishing incident ?

Yet another email I received from what appears to be a phishing site http://www.blog-biz.jp/onlinebanking.capitalone.com
The phishing site is intended to steal user name and password and other information from Capital One customers by sending emails from what appear a legitimate Capital One site and email (security@capitalone.com)

The site try to collect username and password through HTTP POST from the fake login: http://www.blog-biz.jp/onlinebanking.capitalone.com/login.php

Other credentials such as customer address and PII such as SSN, DOB, account No, CVV, Card Number, Expitation can be also collected through HTTP POST from the page http://www.blog-biz.jp/onlinebanking.capitalone.com/finish.php

The host of this phishing site appears to be http://www.blog-biz.jp/ that resolves to the IP address: 202.229.27.242 The web server is an Apache server: Apache/2.0.53 (Fedora)
X-Powered-By: PHP/4.3.11

Further discovery info about the phishing hosting site seem to
indicate a web-related production site in Japan, with address
501-3954 Gifu prefecture Seki city and TEL (0575) 28-4131.

The first thing I'll do is to call Capital One support and alert them about the phishing I will also report the phishing by sending an email to abuse@capitalone.com and to the Anti Phishing Working Group at http://www.apwg.com/

Tactically you want to make sure that your respond to every phishing attack like any other vulnerability that triggers an immediate incident response. As a next step, there is a lot that you can do strategically to limit phishing especially through security training and awareness.

If I were in charge of the anti-fraud of a financial institution like Capital One this is how I would respond to phishing threats:

1) Advise all your customers to block email that carry phishing attacks. Typically phishing attacks are directed toward users through email. A spam filter should be able to detect the email as a spam by checking the Received-SPF for fail or softfail and either have it rejected or issue a warning.

Received-SPF: softfail (mx01.csee.onr.siteprotect.com: transitioning domain of capitalone.com does not designate 209.2.174.117 as permitted sender) client-ip=209.2.174.117; envelope-from=security@capitalone.com; helo=exchange.lifestyle-homes.com;
Received: from exchange.lifestyle-homes.com (mail.lifestylebuilders.com [209.2.174.117])
by mx01.csee.onr.siteprotect.com (Postfix) with ESMTP id 87762BD0045
for ; Sun, 18 Feb 2007 05:59:09 -0600 (CST)
Received: from User ([66.137.204.115]) by exchange.lifestyle-homes.com with Microsoft SMTPSVC(6.0.3790.1830);
Sun, 18 Feb 2007 07:04:48 -0500
From: "Capital One Security"
Subject: Security: Online Banking Update
Date: Sun, 18 Feb 2007 06:04:09 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID:
X-OriginalArrivalTime: 18 Feb 2007 12:04:48.0346 (UTC) FILETIME=[FC96FBA0:01C75354]
To: undisclosed-recipients:;

2) Do some discovery of the site hosting the phishing attack. Query whois for the domain registration information and google the site to find more information about who is hosting and administrating the site

3) Once you have identified the hosting site, contact the administrator and have the content removed (the page will show Content Removed 777 when reached) . If the phishing comes from a site in USA you can appeal to anti-phishing laws like the Virginia’s anti-phishing law that makes phishing a criminal offense punishable as a felony (Virginia Code § 18.2-152.5:1.)

4) Inform and educate customers and internal employees about phishing threats and social engineering. Eventually create a white-hat phishing site that look like your company site and send an email to your internal users inducing them to provide username and passwords. For example you can send an email to your internal users asking them to register to receive a new upgraded PC. Collect the reponses both positive and negative to assess how proficient is the security awareness both within your organization and your customers. If security awareness is bad your users might need a focused security training.

5) Be proactive and learn from other phishing attacks, learn how you mail gateway can defend against them and increase security awareness by alerting users and customers with proper advisories.

According to the latest data from the Anti-Phishing Working Group (APWG), there are now more than 2,600 active phishing Web sites on the Internet and more than 13,000 unique phishing emails in circulation. The threat is real and alive.

A nice list archive of phishing sites is provided at http://www.apwg.com/phishing_archive/phishing_archive.html

While you might find some resources to learn on how to protect from phishing here:
http://www.apwg.com/resources.html

The Anti-Phishing group at Indiana University: http://www.indiana.edu/~phishing/ maintains a site revoted to phishing research that is a very good resource to learn about phishing.

One way to win the security game is to be ahead of the threat by being smarter then the attacker and more educated on threats and countermeasures.

What is Threat Modeling?




A threat tree to map threats
to vulnerabilities and countermeasures
(Source OWASP threat modeling)



What is threat modeling?

Threat modeling is a process for modelling security threats and identify design flaws that can be exploited by these threats so that systems can be securely designed and countermeasures implemented to mitigate these threats.

How threat modeling can be performed by an organization?

Threat modeling adds value at different stages in the Software Development Life Cycle (SDLC) such as during Requirements, Design, Development, Test, Deployment and Operations. Carrying out threat modeling in each of these phases directs threat inputs into security activities and allows management of security risks during the overall life cycle. Hence, threat modeling is an iterative process that requires continues updates: new threats have to be assessed because of a design change in the system architecture as well the implementation of new component, the integration with new library etc.

The following security activities are supported by threat modeling during the SDLC:

Requirements: Key stakeholders use white-boarding and collect information through worksheets to identify end to end deployment scenarios. The drawing of abuse cases allows the identification of negative scenarios and a preliminary threat analysis during requirement definition. Data classification can also be performed during requirements to drive the identification of potential threats to the data assets.

Design:Threat modeling the system at design time allows system architects to validate and explore whether the design meets the level of acceptable risks. Flaws in the design can be exposed, and the information thus gathered used to improve the security quality of the design before the system is ever implemented. Furthermore, security testing efforts can be defined in terms of budgets and timelines.

Development:Threat modeling during implementation helps to drive threat analysis into secure code reviews. Flaws in implementation methodologies and lack of development standards can be identified by looking to specific threats. Threats and misuse cases can drive unit test cases during implementation. hence vulnerabilities in the system, can be avoided by bearing in mind the identified threats to the system.

Testing:Threats identified during threat modeling allow the identification of security tests to verify both new and existing security flaws. Penetration tests can be driven by attack vectors for the vulnerabilities identified during threat modeling.

Deployment: Threats identified in the external application environment impact different level of configuration and are mitigated by adopting security by default during deployment.

Operations:By threat modeling an application during system operations it is possible to identify and assess potential security risks and make informed decisions before change management events. Metrics and measurements can be gathered to plan the next releases. Lessons learnt can be used to develop best practices and standards.

What are the benefits of threat modeling?

Threat modeling helps design architects to take a broader view on the security design of the system, hence, enabling them to be aware of a broad range of attack scenarios and threats. Furthermore, they can identify common mistakes made in designs, apply patterns and reuse principles. This leads to a secure design and therefore an improvement in the overall security posture of the system. Developers typically have detailed knowledge about the system's implementation and deployment and therefore their input is very important for threat modeling. When engaged in the process they can also learn how to avoid common implementation bugs and anti-patterns. This process also helps them to be focused on security and ensures it plays a critical role in their decision process.

Quality assurance personnel, security auditors, technical security testers (collectively referred to as security testers) of a system are typically bound by time. Based on experience they also rarely take a systematic approach to testing, focusing on proving or disproving specific instances of vulnerabilities rather than for systematic issues. Threat modeling systematically helps to identify areas of concern in a focused manner, guiding testers to focus on particular parts of the system that are likely to be attacked. It also helps them prioritize time and budget allocation to security quality testing.

Using threat modeling helps project managers to get a better understanding of the security aspects of the system, thus enabling them to better estimate the time and people (money) needed for tests and reviews. This leads to a more predictable project plan that is more likely to be on budget and on time.

By systematically focusing on the important security issues in a system and prioritizing security threats, information risk managers can make risk management decisions based on facts, rather than on guesswork. When information risk managers build threat models early on in the system's development life cycle, they can reduce costs by making decisions such as the mitigation of risks by redesigning components if needed or by introducing countermeasures before much effort is spent on building the wrong solution. By applying systematic threat modeling to production based systems more issues can be found faster (and therefore cheaper) than with other forms of security testing.

White Board Software Security Question #2

What is wrong with this code?


char * foo(int len, char* value)
{
char * buf;
buf = (char*)malloc(len + 5);
if(!buf)
return (NULL);
try {
if(len <= 5) memcpy(buf,value,len); } catch (Exception* ex) { Console::WriteLine(S"Generic Exception Handler: {0}", ex); } return buf; } For finding the answer, think which values passed to "len" might create a problem. For example, look at this code that call the function "foo" #include "stdafx.h" #using
using namespace System;
char* foo(int l, char* value);

int main()
{
char value[]={'H','A','C','K','\0'};
char* buf;
//this will work
buf = foo(5,value);
//this will overflow the buffer
buf = foo(-4,value);
return 0;
}

Basically the problem of this code is that is prone to integer overflow. When len is negative (e.g -4) the amount of memory allocated for buf is one byte (-4+5). The call to memcpy will take the size_t (unsigned int) (4) value and will try to copy a value in "buf" that will be larger than the one that can be allocated by "buf".

In general, integer overflows occur when a program fails to check that an arithmetic operation can result in a quantity either greater than a data type's maximum value or less than its minimum value. This can happen when comparing values that have been casted (for example from int to long that is from 16 bit to 32 bits and compared to max boundaries that can be bypassed since the sign is maintained during casting such as exceeding the actual representation for int that is 32K). In the example herein, the cause of integer overflow is due to the memory allocation function, where user input stumbles with an implicit conversion between signed and unsigned values (like done in memcpy() for example). An attacker can cause the program to under-allocate memory (set len to -4) so that the program may be vulnerable to a buffer overflow.

White Board Security Question #1

Are Store Procedures (SP) SQL injectable?

Answer:

SP protects from SQL injection when SQL statements are executed independently from the input parameters. The same applies to prepared statements. When I say "independently" I am addressing the fact that the input is not embedded in the SQL statement but passed as parameter to a precompiled SP. SQL injection is possible in store procedures when the EXEC statement is embedded in the SP to execute a SQL statement that is passed as input parameter. Such input parameter can be a concatenated string that could be altered with user input. The same applies to prepared statements used badly such as when still concatenate inputs before being executed.

For example, let say you have a SP such as

CREATE PROCEDURE dbo.doQuery(@query nchar(128))
AS
Exec(@query)
RETURN

this SP can execute whenever malicious input is passed to the SP as a parameter.

As a best practice you should avoid to execute SQL statements internally to a store procedure and instead call the execute externally and passing the input query parameters through a parametrized query.

For example, this is a way to call a store procedure with parametrized input parameters:

string str ="sp_doQuery";
cmd= new SqlCommand(str, sqlConn);
cmd.CommandType= CommandType.StoreProcedure;
cmd.Parameters.Add("param 1" p1);
cmd.Connection.Open();
SqlDataReader read= cmd.ExecuteReader();

In this case the parameters cannot alter the syntax of the query statement embedded in the store procedure.

Assuming that you indeed for some reason you still want to execute the sql statement passed as parameters to the SP you might want al least to check the input internally with a regex such as:

CREATE PROCEDURE dbo.query.doQuery(@is nchar(4))
AS
DECLARE @query nchar(64)
IF RTRIM(@id) LIKE ‘[0-9][0-9][0-9][0-9]’
BEGIN
SELECT @query =’select ccnm from cust where id =’’’ +@id +’’’’
EXEC @query
END
RETURN

SP can offer an additional protection from SQL injection because you can set up user permissions to run the SP and prevent execution from untrused code. As a best practice you want the application to run minimum privilege (for example not use sa account to run queries).

From the security stand point this add ianother layer of security even if adds some admin overhead (e.g. set permissions to each SP in declarative way).

I would say that if you stick with use of SP with prepared statements and parametrized queries (no concatenation of input parameters) and if you do input validation of input parameters inside and outside the SP you are in good shape on mitigating SQL injection with SP.