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.

Lead Security Engineer Position

Position: Lead Security Engineer; Location: Natick, MA; this is a permanent position.

Provide subject matter expertise in information security disciplines supporting the design of our client's security technology architecture and implementation of security solutions. This position will establish, document, manage and disseminate information security architectural methodologies, policies, standards and baseline across all IT departments. Participate on the Enterprise Architectural Board (EAB) to drive overall technology direction for security in defining the strategic view of Corporate IT and Business needs by reviewing proposed programs and projects referred by the EAB and PMO. Identify security risks, threat and vulnerabilities of networks, systems, applications and new technology initiatives and provide direction to security engineers and project teams on building appropriate information security controls into systems in development aligning them to enterprise security goals. This position is responsible for identifying solutions, product/vendor evaluation, selection and procurement, development, migration , deployment and oversight including perimeter defense, Firewall Management, Endpoint security, Intrusion detection, Encryption, Wireless, VPN, Access Control, data protection and integrity across platforms and applications. Provide direction to security engineers on improving and maintaining the appropriate information security controls. Serve as the point of contact for technical guidance, procedural questions and advanced level troubleshooting issues. Perform other duties and/or responsibilities as assigned.
A minimum of 6-8 years experience within an Information Systems organization, with a concentration on Network Communications, System applications, Security Review and Assessments, Vulnerability Management, Penetration Testing or Encryption Methodologies, is required. A Bachelor's degree in Computer Science or related field is preferred and equivalent work experience will be considered. A CISSP or CISA certification is a plus. Must have knowledge and experience with: (1) Firewall Management and Configuration Expertise; (2) Security Event Monitoring; (3) Vulnerability Management; (4) User Provisioning; (5) Single Sign-On; (6) Federation, Extranet Access Management, and Directory solutions. Direct experience with information security at the enterprise level and knowledge of Identity and Access Management (IAM) solutions are essential. Knowledge of regulatory requirements and compliance issues specific to security and data protection required. Must demonstrate proven skills in gathering and documenting business and functional requirements, system testing and configurations to contribute to the selection, deployment and maintenance of security solutions. Must have good Microsoft Office skills, including Excel, Word, PowerPoint, Visio and Access. Experience with technology vendors, direct customer or user contact and positive communications skills is required. Knowledge of scripting techniques (Perl, Shell, etc.) or programming languages (J2EE, C, SQL, HTML) desired. Knowledge of network infrastructures, including firewalls, VPN's, Intrusion Detection Systems, penetration testing and vulnerability assessment strategies, file and session encryption and cryptography methods, web application and device security is required.

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/