First Thoughts on Cloud Computing and the "Information Bank"

(From a discussion on the NAISG list in the fall of 2009)

After thinking about this for some time, I wonder if the day will come when locating transaction processing systems in a cloud-based "information bank" makes sense for the same reason we put our cash in a bank and not under our mattress. Banks evolved in response to the management and security needs of accumulated wealth; there was a time when people stored and protected their own wealth. As crime innovated and proliferated in size and sophistication, the cost of protecting one's own wealth tended toward asymptote. Perhaps the same transition will take place as data becomes more valuable.

On a pragmatic level, as a security architect who has to (within budget) construct defenses against a threat landscape that seems to have infinite creativity and resources, there are some aspects of the "cloud" paradigm that are attractive to me;

- controlled environment; not a general purpose information system like the modern OS
- quantifiable application footprint / behavior (unlike the modern enterprise with its eleventy million applications)
- exclusion of frivolous applications and/or requirements
- no (or hopefully smaller) backwards compatibility albatross(es)
- better security / survivability capabilities - thanks to greater resources through shared costs
- survivability: one environment has a problem? fail over to another..and if virtualization allows you to have an (affordable) heterogeneous environment, even better

All of this might tend to allow the security practitioner to employ a larger arsenal of tools. Key applications could conceivably be developed and QA'd to inter-operate well with strong host-based intrusion prevention tools in enforcement mode with a full ruleset (try that today without a HIPS babysitter). Quantifiable behavior allows for all sorts of behavioral and statistical anomaly detection in addition to traditional specification-based IDS (again, try that today on any large scale). Want to require two-factor auth, encryption everywhere, or IPsec compartments? No problem, we don't have eleventy thousand legacy applications. Want great analysts to monitor and respond to threat detects? That's OK too, as the cost is shared by many budgets (and probably less than what we were spending to do it ourselves).

The potential implications seem quite profound. If someone succeeds in building an "information bank" - using current and future security technologies - with better assurance levels than the average corporate security program offers today (and I think this likely) than we may have to contemplate facing the prospect that we've had it backwards all this time. It would be a startling realization to find that have spent enormous resources fighting a hopelesssly asymmetric battle to protect our accumulated data wealth. It's a bit like a 19th century business, after spending its fortunes trying to run a more secure pony express and field office operation, realizing what they really need to do is use (or better yet, invent) a bank with alarm systems; bank vaults; armored cars and monitoring / fraud detection tools..

More Thoughts on the Asymmetry of Cybercrime

I think it would be useful to re-examine the way we deal with the so called "data breach”. General Patton said plans should be simple - and made by those who would implement them. In the world of data breaches I believe we could do better if plans were made by actual security practitioners rather than by committees of policymakers.

The existing system is probably nonsensical now that merchants are facing structured threats who outmatch them a thousand fold. When commercial airliners were targeted by terrorists, we did not order the airlines to become impenetrable to terrorism or else face horrific penalties. The airlines don't know anything about counterterrorism; few would argue that they should be expected to defend themselves. Instead, the state - which has exclusive jurisdiction on the use of force - took offensive and defensive action to respond the threat. Why then does it make sense to penalize merchants and retailers for being victimized by well-organized for-profit structured threats who may even have state sponsorship (or at least enjoy tolerance by friendly or indifferent governments)? I propose 1) a simple metric system that we can use to continuously evaluate success / failure of corporate security programs, providing 2) an end to the existing breach notification / lawsuit parade so we can use that time and money constructively elsewhere 3) more offensive action by state and law enforcement and 3) seizures of monies from these for-profit actors by law enforcement - so we can use this money to do good things (like expand Infraguard) and help the cause of the defense (and help make the problem pay for itself).

2009 Conferences, Structured Threats and Asymmetric Conflict

(Posted to the NAISG list in August 2009)

I attended DEFCON and it was quite interesting; I will write a trip report in a blog article as soon as I can get around to it. Today I find myself thinking about the Mandiant talk at SANS Boston last night.

In summary, many retail and financial firms' security teams are losing the fight against structured threats that outgun them by orders of magnitude. The financial penalties incurred by breach victims are in the scores of millions, collectively, and it is questionable whether these penalties are producing anything of value apart from legal caseload. Does it make sense to penalize the victims of data breaches when they were overwhelmed by structured threats? Are these fines and lawsuits an efficient method for driving positive change (scores of millions spent on security programs - rather than lawsuits - might have made a difference).

During the course of my career I've learned how important metrics and measurable performance indicators are when trying to illustrate risk and develop a business case for funding security programs. This morning I found myself thinking along these lines: should we scrap the existing breach reporting system for merchant organizations? We could replace it with a simple metric that continuously measures effectiveness of security programs and does not measure solely on whether or not a firm has avoided a messy breach spectacle (which is a rather simplistic and inefficient motivational tool after all - it only drives budget dollars to security programs after a catastrophic loss).

We don't evaluate most products and services based on their ability to avoid disaster; we evaluate them continuously on quality and performance. For example, require publication of, say, rates of fraud - either fraudulent transactions per 1,000 or the fraud percentage of total transactions or business volume. This is a simple, continuous and unbiased measurement of how successful (or not) security programs are. We could reward high performers for low fraud numbers (though the marketplace would likely take care of this).

Of course, the consumer may need to be educated that fraud rates are generally non-zero; in the financial world, the cost of zero fraud (in the form of increased security, risk avoidance and lost business) is sometimes more than the cost of low amounts of fraud. It would take a paradigm shift, but if it could provide a simple, clear cut metric it might possibly be a more effective motivational tool to build (and fund) security programs and actually prevent - or reduce - breaches as a consequence of containing and reducing fraud numbers. Fraud reduction is a perfectly reasonable goal; one could argue driving toward the goal of "either one is impenetrable, or else a failure" is a false (and possibly irrational) goal.

Conficker Author(s) Thinking Three Moves Ahead?

Trinity: "Where are you going?"
The Keymaker: "Another way. Always another way."
-The Matrix Reloaded

I can't help but feel that Conficker's author(s) are thinking some distance ahead of us. It was probably inevitable that the worm's pseudo-random domain name algorithm would produce a handful of existing, already registered domain names - names largely beyond the reach of the industry groups attempting to cut off the thing's control channel by registering and locking its domain names. Perhaps the worm's creator(s) expected us to lock the unregistered domains - knowing that they simply have to wait for the day the worm turns to a preexisting domain containing systems that they are able to take control of (or perhaps already have). In the month of March, for example, the worm's list includes a small number of pre-existing domains including these - as reported by Sophos at http://www.sophos.com/security/blog/2009/03/3457.htm

DOMAIN DATE
jogli dot com Big Web Great Music March 8
wnsux dot com Southwest Airlines March 13
qhflh dot com Women’s Net in Qinghai Province March 18
praat dot org Praat: doing phonetics by computer March 31

The good news is this is may present an easier method of detecting this bot's control channel. DNS servers may not log transactions by default - but most can enable logging - and I can't think of an off-the-shelf tool for alerting on DNS logs but this would not be difficult to script. Of course, these could easily be detected by an IDS rule as well (assuming IDS sensors are monitoring internal DNS traffic, particularly when DNS mitigation prevents the queries from traversing the perimeter). It would probably be a good idea to for sites to blackhole preexisting Conficker domains on the relevant days (or permanently); this might also make it easier to report on attempts to resolve the domain names, by reporting on names resolved to nowhere, depending on the DNS product used. AV vendors should be capable of providing lists of existing domains output by the worm's algorithm.

Conficker C / B++ Autoupdate Capabilities, Detection Tactics and Geometric Detection

Morpheus: "What can you see, Neo?"
Neo: "It's strange. The code is somehow different."
Morpheus: "Encrypted?"
Neo: "Maybe."
Trinity: "Is that good for us, or bad for us?"
Neo: "Well, it looks like every floor is wired with explosives."
Trinity: "Bad for us."
Morpheus: "Here we go."
-The Matrix Reloaded

The "conficker cabal" industry consortium is working to lock the domain names used by the worm for command and control. The best probability of success for the bot's creators to retake control may now be DNS poisoning; DNS poisoning attempts may be a potential early warning indicator if the worm's authors attempt to reassert control of the infected population. The latest version – Conficker B++ or C – has also implemented an “autoupdate” capability of sorts, perhaps as an alternative method to reassert control.

Recently a new variant of the worm - Conficker C or B++ - has emerged and is under analysis. The variant uses an additional network communication mechanism – SMB named pipes. Obviously many networks block SMB protocols at their perimeter so this would not be a reliable command and control channel – but it could be used as an “autoupdate” feature. Many organizations do not internally compartment or filter unicast SMB protocol – in such a network, one instance of Conficker could potentially update the entire version C population at wire speed. This technique will almost certainly be imitated in future generations of industrially produced malware. It would probably be a sensible precaution to re-examine worm containment and network compartmentalization capabilities, particularly for VPN users and laptop populations who may be at greater risk of experiencing DNS cache poisoning or malware infection vectors in general. A single infected laptop with an updated instance of a bot with this kind of “autoupdate” capabilities could potentially update an entire population of infected machines with a binary payload in an un-compartmented and/or unfiltered network.

Looking at what we know about the worm there are number of detection strategies. While the worm's propagation may be relatively simple to detect with a well-tuned threat detection tool, detection of HTTP based covert communication channels tends to be more difficult and error prone, particularly with static signatures. HTTP sessions are supernumerary in many networks - and these control channels can be quite subtle and hard to distinguish from normal web traffic (the best place to hide a tree is in a forest).

It's worth noting that scanning for the MS08-67 vuln is not a useful tactic as Conficker will often patch this vuln after it infects a host. Also worth noting that attempts to control the bot by providing it with a binary program to run will most likely fail; the authors thought of this and Conficker will reject any binary image not signed using the bot herder's keys.

Antivirus detects – by now the major vendors will all have reliable signatures. Antivirus tools are actively jammed and attacked by the worm, however, and may experience false negatives in cases where the worm is able to cripple them.

Authentication Logs – in many environments the worm will produce a spike in auth failure and account lockout events. Easily detectable using a SIEM or log aggregation tool.

IDS events – the worm uses exploits for MS08-67, which by now all IDS tools should be detecting. IDS tools may also generically detect shellcode used by the worm.

Proxy logs - The first two variants connect to one of these URIs. (n is an incremental number). An exact URI match would require computing the Conficker domain list and creating a very large ruleset; a generic match on the URI parameters may or may not be useful in terms of false positives depending on overlap with legitimate web applications in a given environment.

http://domainname/search?q=n\&aq=7 (Conficker A)
http://domainname/search?q=n (Conficker B)

Flow / session data – lots of potential here.
Behavioral detection of worm propagation – the worm and its newest variant use SMB sessions, easily detectable by an NBAD tool
Geolocation – variants of the worm will connect to www.getmyip.com, getmyip.co.uk, checkup.dyndns.org and maxmind.com – observable using flow data (obviously these have legitimate users as well, so potential false positives exist)
Connectivity tests – the worm may make HTTP connection requests at 60 second intervals when communication fails or is blocked; this is observable using flow data and obviously programmatic.
Protocol Anomalies - the worm may make HTTP connections on nonstandard ports.

Geometric detection (using the QRadar tool) – geometric detection works by detecting deviations from normal application shape or geometry. When monitoring network session data over time, one of the things you find is that normal usage of many applications has a predictable shape – and that significant departure from normal geometry often indicates suspicious use or misuse of a protocol.
DNS activity – every three hours, the worm will generate up to 500 DNS requests. This activity will be obviously programmatic and could likely be detected statistically by a behavioral sentry or with a simple threshold based rule.
HTTP control channels - HTTP traffic produced by the worm may also have abnormal geometry; it may be too small, to frequent or too predictable to be human activity. It may also be statistically detectable using a behavioral sentry.

Multivariate Correlation (using a SIEM tool) – often best results come from corroborating multiple detects. Try using a function rule in a SIEM tool like QRadar to create a high priority alert when multiple detects are obtained within a time window.

Raison d'être of the "downadup" or "conficker" worm

"There is no escaping reason; no denying purpose. Because as we both know, without purpose, we would not exist."
- Agent Smith, The Matrix Reloaded

The downadup worm has been the subject of much discussion. Someone spent real resources developing this thing; Symantec calls it "the most prolific worm that we have seen for some time". At the SANS ISC an incident handler wrote, "we can definitely say that the Conficker authors were not amateurs – this looks like professionally written code". The fact that the purpose of the worm is unknown is a little bit spooky; unlike most crimeware, it reportedly does nothing post-infection except connect to a control channel and await instructions. So, we have a sophisticated worm with extensive antiforensics capabilities placing some 10% of the world's computers under the control of unknown actors for unknown purposes.

Why would someone fund the development and deployment a worm with no apparent purpose? If it were simply more crimeware, it seems likely that its authors would desire a rapid return on investment by immediately engaging in financial fraud and/or data theft activities. Why would a worm like this do nothing post-infection? There are several possibilities;

- the worm's developers no longer have a paying customer, because the client who commissioned the worm ceased operations (in this event, with a botnet in the realm of 10 million, one would think they could find new clients)

- the worm's developers are unable to access the command and control channel after losing the encryption keys to accident, data loss or system failure

- the worm's control channel has been seized by a government or law enforcement organization

- the worm was developed by a not-for-profit group who have no desire for monetization

- some other undetermined explanation

What other reasons can we imagine for releasing a worm that takes no action? As a thought experiment, imagine for a moment we were asked to develop a first strike weapon for information warfare. In the kinetic world we have the stealth bomber and the missile boat - first strike weapons designed to resist detection and deliver a massive payload with little or no warning (and if your delivery time is shorter than the defender's response time - or even their decision loop - little warning can be the practical equivalent of no warning).

The basic requirements for a first strike cyber-weapon then would similarly be stealth, availability and reliability. It would need to infiltrate large numbers of hosts and networks in advance and resist detection and removal to the maximum extent possible in order to be operational and capable of delivering an attack payload when the time comes. Another requirement would be to utilize a reliable command and control channel that is resistant to detection and interference. Like the missile boat, it would be deployed well in advance of any actual conflict so that it is ready when needed. Generalized large-scale distribution, rather than targeted distribution, would probably be more successful in infiltrating the target as any deployment targeted at a specific country or network would raise its alert status - ramping up its response and cleanup efforts and reducing the worm's effectiveness in penetrating its target(s) and/or growing a large bot population. Even if the program failed to infiltrate its target network(s) in large numbers, it could still be used to launch denial of service floods against strategic targets like internet service providers, communications networks, financial networks and government networks that are exposed to Internet based attack. A denial of service attack on major ISPs might accomplish much of this in one blow. Obviously a flood of this size would require a massive number of bots; the estimated 10 million hosts infected by downadup might be enough even if only a portion of them were able to hit their targets.

Perhaps the downadup worm essentially fits the description of a first strike cyber-weapon. There is no particular basis for believing it is a weapon; this is but one explanation that fits the available facts. Perhaps it is simply an R&D project for evaluating the effectiveness of various delivery systems, propagation methods and control channels that might be used by an actual weaponized bot in an actual cyberwar. It carries no obvious payload so far as we know but its payload could be easily delivered through its command and control channel. A simple destructive attack like destroying file systems or launching denial of service floods would be relatively simple to implement - probably in a matter of seconds - by sending a few commands down the C&C channel to the listening bots. Even relatively complex attack programs could probably be delivered over the control channel in a matter of minutes. It would probably make sense to hold back any attack payload until the decision had been made to use it as any detection of attack code by malware analysts would result in heightened cleanup operations that would reduce its numbers.

First Thoughts on Latest Data Breaches

“Fixed fortifications are a monument to the stupidity of man.” - General George S. Patton

I for one have never quite grasped the school of thought that a well-designed security program consists of bringing in a (possibly technically unsophisticated) audit team once year to run through a checklist of what are essentially basic requirements for an infosec architecture - with the expectation that will be sufficient until next year.

It’s not impossible to detect structured threats with a well-designed detection and response capability. Even with a semi-well designed program, it is often possible to detect these sorts of “data breach” incidents – if the organization is thoughtfully deploying and using good tools and technologies in their security program. Why is it, then, that so many victims only build security capabilities after they have had their first incident?

One aspect of the problem seems to be a large gap between perception and reality, in many organizations, as to just how structured and sophisticated for-profit threats are. Some of these victims would have done more in advance if they really understood the scope of the problem – and they might never had been victims. Maybe we need more information sharing - or even more of what Schneier calls "security theater" - in order for stakeholders to better appreciate how big the problem is.

Some organizations are unwilling or unable to confront risk until it materializes in a dramatic way. There is psychological science to support this; some people and organizations are risk-seeking in the face of a possible loss even thought they are risk-averse about potential gains (see Schneier's 2007 Blackhat keynote, it's pretty interesting). The result being, that in many cases, the temptation to save money by neglecting security and assuming some risk is irresistible to many until they have their first incident.

Fundamentally, the economics are against the breach victims; structured threats probably out-match corporate security programs by orders of magnitude in resources. Security programs are often seen as overhead cost centers and fight a continuous battle to justify their existence and obtain sufficient funding to build meaningful capabilities. The specter of data "breach" costs cannot always be relied upon to justify funding a security progam - particularly when a breach has never been known to occur; these costs are are assigned to the responsible parties, for the most part, by the banks and credit card companies now, and this does not seem to slow down the breach phenomenon (or maybe it has, and it could be worse). Perhaps an economic incentive - pushing the costs of the breach onto the responsible parties - is the only thing that will make a difference, as with many aspects of the marketplace. Maybe if there were a mechanism for capping the amount of fraud losses that can be passed on to consumers in rate / price increases..that might be just too difficult to design implement and might fundamentally break too many risk models. Levying fines and penalties is tricky also; while some cases may be clear cut examples of negligence, other cases will inevitable be found which feature structured threats that are sufficiently sophisticated to evade detection by state-of-the-art security tools; can we fairly assign responsibility to the victim organization in a case like that?

Detecting Data Breaches and Sensitive Information Leaks

Recently I've found myself in a number of discussions about detecting losses of "non public information" or NPI - high value data like medical data, credit cards and social security numbers. Many products can detect NPI in transmission on its way across a network to somewhere else; snort, for example, has good regexps for all kinds of NPI including socials and cards. It's interesting that this is one of the detection capabilities that is least likely to be in place and perform well despite the fact that this capability is one that many organizations would most like to have. What makes it so hard to detect and prevent these sorts of data breaches? Let's consider the detection problem.

NPI data (credit card, social security numbers and the like) can be reliably detected by IDS or "extrusion detection" devices using regular expressions; these capabilities also exist in snort. I've used regexps like these in the past for social security numbers and bleeding snort has ones that are even better;

SSNs delimited by dashes or spaces

\b\d{3}[- ]*\d{2}[- ]*\d{4}\b

SSNs delimited by any char not a letter, number or underscore

\b\d{3}[^A-Za-z0-9_]*\d{2}[^A-Za-z0-9_]*\d{4}\b

Match 1000 or more numbers, non-delimited (for the case where the bad guys remove the delimiters prior to transmission and you have tuned snort extremely well):

[0-9]{1000,}

And so on. The problem rapidly becomes that no matter how smart your regular expressions and / or content inspection technologies are, the possible evasion methods are supernumerary - that is, so numerous that they're practically infinite. Data can be encoded, obfuscated and encrypted in any number of ways which make regular expression based detection impossible. Add to that the fatc that not all application protocols are ASCII (text) based; there are a vast number of obscure binary application protocols out there that are not going to cooperate with regexp based detection. What can we do? I recently participated in a discussion of the subject on the focus-IDs list, reproduced below;

From: listbounce@securityfocus.com on behalf of Craig Chamberlain
Sent: Mon 10/15/2007 3:37 PM
To: focus-ids@securityfocus.com
Subject: RE: Using Snort to find creditcard data?

This has been an area of interest for me for some time. It's very true
the regexp based detection technologies can produce high rates of false
positives and are easily evaded. It's not uncommon for data leaks to
take place over vpns; a case study like this was presented at blackhat
this year. Even without encryption, the number of possible obfuscation
techniques is quite large (and we're assuming the data is ASCII; there
are probably enough obscure back end applications with binary protocols
to keep a good sized protocol dissector development team frustrated indefinitely).

I've seen some good success combining specification based techniques -
like these regexps - with behavioral detection - such as using netflow
or other flow data, for example, to detect unexpected large or long
duration data streams headed for places that don't makes sense (e.g.
foreign networks, foreign countries or external networks with which no
business relationship exists). It seems to often be the case that
systems containing high-value data have a predictable enough network
behavioral repertoire that this kind of behavioral detection performs
acceptably.

This kind of behavioral detection, optionally corroborated with
available specification based detection such as regexp detects, can have
acceptably low false positive rates. Another advantage of flow data is
that it is hard to evade detection of the fact that you're moving a lot
of data; you can obfuscate and encrypt the traffic but you can't conceal
the fact that a quantity of traffic (and presumably data, if the payload
is not garbage) is being transmitted. Of course, if an obvious attack of
some sort precedes all of this - with a resulting detect or detects from
an IDS to corroborate - then confidence is again higher.

Regards,

Craig Chamberlain
Principal Security Consultant
craig@q1labs.com | www.q1labs.com

-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Ofer Shezaf
Sent: Tuesday, October 02, 2007 7:25 AM
To: jerikl75@gmail.com; focus-ids@securityfocus.com
Subject: RE: Using Snort to find creditcard data?


All the answers where good but also partial as the subject is far from
trivial.

There are few aspects to detecting credit card numbers on the network,
and I will try to address them:

1. Matching credit card numbers
2. Handling false positives
3. Evasion
4. Logging

Matching Credit Card Numbers
============================
Valid card numbers:

1. Are 13-16 digits long. This is easy to detect using regular
expressions but may result in a lot of false positives. A lot of IDs are
in this range.

2. Conform to the LUAN checksum function. Being a checksum function it
matches 1 out of 10 numbers in the range. Since many times applications
that use numbers of this length use an entire range, there will still be
false positives. LUAN cannot be verified using regular expressions and
would require code.

3. Have certain prefixes which were assigned to issuers. A pretty good
table of assigned prefixes can be found in Wikipedia, but I'm not sure
it is comprehensive (http://en.wikipedia.org/wiki/Credit_card_number).
Prefixes further reduce false positives and can be implemented using a
(complex) regular expression. Using prefixes introduce a risk of false
negatives due to omission of less common prefixes. For example we have
not been aware until recently of Bankcard from Austria. This is
especially a problem internationally.

False positives
===============

The problem is that the above rules generate a lot of false positives.
Most false positives are related to normal application traffic using
long ASCII numbers. Such an application would usually use a range and
therefore hit some valid numbers.

Since the PCI requirement is for "Encrypt transmission of cardholder
data (only) across open, public networks", another source of false
positives are applications that transmit credit card numbers
intentionally and legally.

The solution for such false positives would be exceptions, which I'm not
sure Snort is the best solution for and would require an application
layer IDS. A network layer exception would be limited to addresses and
ports while a good exception would be by a specific property of the
transaction such as URL and parameter (for HTTP traffic). For web
traffic I would use for example something like ModSecurity. But I'm
biased.

Evasion
=======
It is important to note that any such mechanism will detect only
erroneous use of credit card numbers. Even the simplest transformation
function on the numbers will enable them to bypass detection, so most
malicious usage would not be detected.

There is also an issue with leakage through encrypted channels, since
PCI requires encryption, leakage would many times be encrypted. IDS
limitations regarding encrypted traffic have been discussed extensively
here (http://archives.neohapsis.com/archives/sf/ids/2007-q3/0084.html)
and elsewhere.

Logging:
========
Assuming that we did everything right and built a system for detecting
credit card numbers on the network, we cannot keep the number as we
would violate PCI in the detection system. Solutions are:

(a) Encrypt all collected information

(b) Mask the credit card number


~ Ofer Shezaf

Re: Using Snort to find creditcard data? Oct 19 2007 06:59AM
Siim Põder (siim p6drad-teel net) (1 replies

-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Siim Põder
Sent: Friday, October 19, 2007 2:59 AM
To: Craig Chamberlain
Cc: focus-ids (at) securityfocus (dot) com [email concealed]
Subject: Re: Using Snort to find creditcard data?

Yo!

Craig Chamberlain wrote:
> Good point; what I'm suggesting is that while it's relatively easy to
> hide or obfuscate the data itself, it is hard to conceal the fact that
> data - or packets - are being transmitted, possibly using a
> recognizable application protocol, to an unexpected destination, which
> can be a useful last-ditch detection mechanism when the other methods
> fail - or can be a useful corroboration when correlated with the other
> detect data.

There is bound to be some sort of legitimate production traffic. For example, if there are https connections coming in to a specific machine and specific port. You can detect if that machine starts sending out data on its own or starts accepting connections on another port.
However, if the same port starts serving credit card numbers
(obfuscated) or even hides the credit card numbers in tcp sequence numbers (or does something even more subtle as serving them by changing the case of "A" letters in http connections from certain addresses) the movement of data should be extremely hard to detect.

Siim

Re: Using Snort to find creditcard data? Oct 19 2007 06:59AM
Siim Põder (siim p6drad-teel net) (1 replies)RE: Using Snort to find creditcard data? Oct 19 2007 03:45PM
Craig Chamberlain (craig chamberlain Q1Labs com)
What I'm describing in this bit is actually a behavioral detection technique rather than the specification or regexp based method (though the combination of the two is often preferable, where available) as the detection failure scenarios data inspection are endless, as you point out. What I'm suggesting is that while methods and scenarios for obfuscating or concealing data beyond detection or inspection are supernumerary, there are a few elements that can usually be reliably detected using flow data, assuming the reporting devices themselves have not been compromised;

1. network transmission took place with between two IP sockets
2. some number of bytes and packets were transmitted, which can be measured
3. the destination address was or was not part of the organization which owns the source
4. the destination address is or is not within expectations (e.g. is it a foreign country or organization with which no business relationship exists)
5. (possibly, if you have some packet content samples with the flow data) the application protocol appears to be a known application or network protocol
6. this apparent application usage is or is not within expectations - and is or is not typical

With this information, behavioral detection can sometimes find data leaks in the form of anomalous network behavior such as the appearance of a new application protocol e.g. a vpn, ssl or ssh connection - especially on a non standard port - with a remote destination which is unexpected (while the encrypted data itself is beyond inspection, the application protocol itself may be recognizable); or a direct SQL connection from a client desktop, where they normally connect through a middleware application, or something else.

We use a technique we call anomaly detection in the QRadar tool to detect appearance of new behaviors for selected high-value systems and networks. useful either as a corroboration to methods like regexp based inspection or as a potential method of finding information leaks that evade these detection methods. Of course, there are scenarios where new behaviors result from normal changes; none of these methods are perfect, but they are all useful. Combining them through correlation can sometimes improve accuracy of detection even further. In my experience, the best method of finding misuse patterns like data leaks is through sophisticated event correlation - either manual or programmatic - though it needs to be done programmatically in order to scale.

Craig Chamberlain
Principal Security Consultant
craig (at) q1labs (dot) com [email concealed] | www.q1labs.com

Blackhat 2007 Favorites

Here is the short version; the web is the new playground; "web 2.0" has serious issues; threat models are becoming sophisticated enough they're actually hard to follow in some cases; we're losing the fight against malware; security products themselves are increasingly targeted and used to compromise networks they are supposed to protect.

These talks were my favorites, organized by broad subject:

Incidents

Belani and Jones gave a real-world incident talk containing three very interesting case studies including a case where of non-public information including credit card transaction data was compromised. This case was never solved and may have been a wireless penetration or possibly an inside job.

Web Based Threats

Bolzoni_and_Zambon demonstrated an anomaly based intrusion detection system for web applications; this is an idea I had found myself advocating earlier in the year.

Byre’s talk “Intranet Invasion With Anti-DNS Pinning” covers a threat model so complex it is actually hard to follow. Essentially a browser hijacking technique for compromising a browser and / or desktop with some potential perhaps as a Javascript / HTTP control channel for a botnet.

Chenette_and_Joseph presented a tool for detecting zero day exploits, particularly browser heap spray exploits. See also Sotirov’s talk “Heap Feng Shui in JavaScript”.

Grossman & Hansen continued last year’s foray into browser hijacking techniques.

Gutesman, Futoransky and Waissbein presented a novel method of securing web applications.

Brad Hill gave an in-depth presentation on message oriented security as implemented in XML and WS-Security and the state of the art in XML attacks.

Hoffman and Terrill discussed the state of the art in web based worms and possible future directions such worms might take in order to become more virulent.

Dan Kaminsky gave a must-read multi-subject tour of his very interesting research in his usual style; this year focusing on vulnerabilities in the web application space.

Sullivan and Hoffman discussed Ajax design flaws and threat models.

Malware

Butler_and_Kendall discussed the use of DLL injection by malware to avoid detection and demonstrated methods of kernel mode injection techniques in the win32 space as well as memory analysis forensic detection techniques.

Nick Harbour of Mandiant discussed anti-forensics techniques used by malware and presented a UNIX equivalent to the Nebbtt’s Shuttle method of launching a win32 executable from a memory buffer.

Mikko Hypponen presented the state of the art in cell phone malware.

Wysopal and Eng discussed the state of the art in insertion and detection of backdoors.

Mark Yason discussed the state of the art in malware anti-reversing techniques.

Other Topics

Jim Hoaglund from Symantec presented the results of an in-depth analysis of the Vista network attack surface. He also discussed security implications of Teredo, an IPv6-over-IPv4 tunneling protocol which gives a vista host a globally routable IPv6 address. No practical inspection mechanism exists for Teredo traffic; the security implications are significant as any malicious traffic using the Teredo protocol may well go undetected.

David Litchfield presented a case study in Oracle database forensic analysis.

Palmer, Newsham and Stamos discussed weaknesses and evasion techniques in commercial forensics tools.

Mike Perry presented some interesting threat models and defensive techniques for users of the tor network.

Roecher and Thumann discussed the Cisco NAC protocol.

Rutkowska and Tereshkin continued last year’s discussion of Vista kernel compromise and virtualization based malware including a bluepill implementation supporting nested virtualization.

Bruce Schneier gave a keynote talk called “The Psychology of Security” – a must read examination of how the human mind thinks about risk.

Thermos presented some new VoIP protocol attacks.

See http://craigchamberlain.com/library/blackhat-2007/