Banking Millions from Malware enabled by Badware

News broke this week that one of the criminals involved in a massive global banking fraud scheme that relied heavily on the Zeus trojan to steal millions from both U.S. and European banking accounts will be sentenced this Spring.

The news reminded me of the relationship between malicious software (i.e. “malware”) and insecure software (i.e., “badware”). Criminals intentionally create malware to do bad things (in other words, to launch attacks on victims). Viruses, trojans, root kits, malicious code, etc. are all examples of malware. Badware, on the other hand, is software that has underlying security weaknesses (or defects) that can be exploited by attackers. These underlying weaknesses manifest as the software is constructed and deployed and *are not intentionally* planted by software developers. Often, badware acts as a vehicle for malware to attach itself to victims and successfully carry out its operations.

Gary McGraw wrote about this problem in May 2012. Today, I focus on combating the badware problem - helping organizations build software that is resilient when attacked by malware and other malicious agents. Thus, I’m in the prevention or risk mitigation business.

I used to study malware during my undergraduate days with Professor Tobin at Fairmont State Unversity. I’ve always found malware footprints - how malware touches devices and leaves traces of execution - to be interesting. What’s more fascinating to me these days is how criminal organizations run global operations to successfully leverage malware and badware for monetization purposes.

The FBI has published a decent infographic that explains the high level moving parts and operational aspects of a Cyber Theft Ring [1]. The criminal who faces sentencing in the original news article was considered to be a “money mule”, a person who aids in the transfer of stolen funds.

A Fraud Scheme provided by FBI

[1]: FBI, 01:49, 3 October 2010 (UTC),

Establishing Effective Static Analysis Capabilities

Planning to establish or reboot a static analysis capability this year? Use this simple framework to plan a new implementation or reflect on an existing program to improve maturity.

Over the years, we’ve learned that there are four primary dimensions to any static analysis capability:

  • Solution Architecture
  • Policy
  • Application On-Boarding
  • Vulnerability Management
It doesn’t matter if you’re considering building an in-house solution [*1] or leveraging an outsourced SaaS static analysis provider [*2], these four dimensions apply and are crucial to your capability’s overall success. In fact, the first dimension - solution architecture - is about evaluating whether an in-house or outsourced solution is the right answer for your program. It also doesn’t matter if you’re a Fortune 10 company with 10K+ developers or a small start-up with a hand full of developers; these dimensions still apply irrespective of scale.

Continue Reading »

My Threat Modeling Talk @ OWASP AppSec USA

OWASP recently posted videos of all talks from the OWASP AppSec USA conference held in Minneapolis in September 2011.

You can find my talk on an approach for “simplifying threat modeling” here. Grab my slides here.

Check it out and let me know what you think. Would love to hear from you and your thoughts on where threat modeling is headed in our industry.

GC Labs: Securing URL Redirects

Can attackers control URL redirection functionality exposed by your application?

Unvalidated Redirects and Forwards is #10 on the 2010 OWASP Top Ten 10 List. Sites that are vulnerable often expose a servlet or server-side script that constructs the URL being transferred to using data that is received from the client (i.e., something that can be controlled by an attacker). A lot of sites simply accept a URL as input to the redirection script, and that’s what gets them into trouble.

Continue Reading »

GC Labs: Mitigating XML Entity Expansion Attacks with Xerces

Here are a few typical questions from my “assessment runbook” that I ask for an app that accepts and parses XML data that can be controlled by an attacker (think file uploads, web services, stored XML content made up of inputs from an external user, etc.):

(1) Is there a check to enforce a maximum number of bytes that is read from the data stream that consumes the data?
(2) Is there a check to ensure the markup is valid XML?
(3) Is there a check to ensure the content of the XML message is part of the application’s protocol and matches expected data types and formats?

I’ve intentionally left out two questions that are the focus of this post (entity expansion) and the next post (external entities). It turns out that you can implement checks to cover (1), (2), and (3) and still be vulnerable to a denial of service scenario caused by insecure entity expansion due to parser weaknesses. In fact, most parsers that I’ve come across seems to be vulnerable to entity expansion attacks by default. Xerces is no exception. It’s a widespread issue because developers must explicitly configure the XML parser being used to mitigate the vulnerability; a step that often isn’t included in company security standards.

Continue Reading »

Are your regular expressions anchored?

I recently found a SQL injection vulnerability in a J2EE app where a request parameter is used to construct a dynamic JDBC query via string concatenation. When I discussed the issue with the developer, he said something to the effect of “Wait, I’m validating this field against a white list like our standards say, what’s the deal?”. So we reviewed the validation check. Turns out a regex was being applied, but it was flawed: it wasn’t anchored from beginning to end. Let’s roll up our sleeves and figure out what happened.

Continue Reading »

BSIMM: A Descriptive Model of Software Security

Gary McGraw discusses prescriptive vs. descriptive models, and why/how BSIMM helps model the reality of software security initiatives in our industry.

Teaching Fortify SCA About Confidential Data

In Cigital’s latest newsletter, I explain a few tips for gaining assurance that Fortify SCA is “seeing” code (specifically private or confidential data) the way you think it should be.

Static analysis tools like Fortify SCA are powerful in how they can quickly and consistently apply rules to identify insecure coding patterns (i.e., patterns that reflect or lead to weaknesses in code). Sometimes, though, the default rulepacks shipped with a tool may leave gaps in how it covers your code, particularly if your application is built with in-house frameworks, new third party libraries, old third party libraries, or less well known libraries. Check with the tool vendor’s documentation to find out exactly what rules you’re getting.

Continue Reading »

Applying Basic Trust Concepts to Software Module Design

In the January/February 2009 issue of IEEE S&P, Schneider and Birman talk about “trust attacks” in a good article discussing IT Monoculture risk. They write:

Networked systems admit the possibility of trust attacks. In them, one computer satisfies a request from another because it trusts the source of the request, but in fact the source has already been compromised by an attacker [1].

As a consultant who reviews code a lot, this statement immediately got me thinking about trust at the code-level. Trust issues are fun to think about — not only because there are bookoos of trust-related issues in today’s apps (particularly mashups) but also because they are difficult to mitigate through good defensive design. As a software design enthusiast, I believe we can apply the concept of trust attacks as described above to low-level module design (think the Class keyword in Java or class keyword is C++) by changing one word in the second sentence:

[...] one module satisfies a request from another because it trusts the source of the request, but in fact the source has already been compromised by an attacker.

Continue Reading »

Building Security In Maturity Model (BSIMM)

A lot has been said about what companies *could do* to build secure software. Ever wonder what companies *really do*? Now you can find out — the Building Security In Maturity Model (BSIMM) recently went public. Cigital, along with Fortify, conducted the study by interviewing leaders of software security initiatives to gather facts about what activities they carry out to meet software security goals.

This is a big, big deal for our industry. It’s all about being proactive, thinking about software security from day 1, and developing a strategy for going from point A to point B to point C. We finally have good data from serious initiatives out there that shows what has worked over the years and what hasn’t. Companies included in the study that can be named: Adobe, The Depository Trust and Clearing Corporation (DTCC), EMC, Google, Microsoft, QUALCOMM, and Wells Fargo.

The framework that’s presented in the study is easy to read and understand. I invite you to ponder about how your organization sizes up against the nine companies included in this study. If you’re not doing the nine things everybody does, you may want to ask why.

Two other articles about BSIMM to check out:

What do you think?