Letters

Readers sound off.

Letters

Clarification from Damballa

This letter is in regard to Grzegorz Landecki's “Detecting Botnets” article from the January 2009 issue of Linux Journal, from Paul Royal, Principal Researcher at Damballa, Inc.—Ed.

As the individual who discovered the Kraken botnet, I wanted to clarify some inaccuracies that were stated regarding its discovery and handling. In addition to these clarifications, I would welcome any conversations about Damballa, its processes and Kraken findings if Mr Landecki is interested in further discussion.

From the Linux Journal article:

“To simplify, Damballa discovered (probably during a security audit) a new malware with hard-coded addresses (URLs) for zombie control servers (CCs—computers that manage tasks for zombie machines and all infected computers report to them).”

Damballa first discovered Kraken through network anomalies observed on a DynDNS provider's network with which it collaborates to shut down C&C servers. Damballa originally thought Kraken was HacDef (a well-known type of malware used by a botnet documented in 2006; see www.avira.com/en/threats/section/fulldetails/id_vir/2900/bds_hacdef.fv.1.a.html) and did not have a malware sample for Kraken until late March 2008. Damballa only discovered that the botnet was not HacDef after it located a malware sample matching the network anomaly. That others in industry thought the botnet was Bobax, an older botnet (and perhaps ancestor of Kraken), speaks to the general difficulty of new botnet identification.

From the article: “Damballa also found that some of those hard-coded addresses were not registered in a DNS service (the botnet probably was tested at that time, and the authors were preparing to launch it later).”

Kraken malware does not use hard-coded domain names at all; it autogenerates them. The algorithm used to generate domain names has been documented by both ThreatExpert (blog.threatexpert.com/2008/04/kraken-changes-tactics.html) and TippingPoint (dvlabs.tippingpoint.com/blog/2008/04/28/owning-kraken-zombies).

From the article: “Damballa registered those domains as its own and ended up controlling quite a large botnet for research.”

Damballa never “controlled” Kraken; because Kraken malware generates domains, the botmasters simply registered domains that would be subsequently autogenerated (Damballa could not register them all) and resumed its operation.

From the article: “It hasn't contacted any security company about the methods of infection it discovered.”

In early April 2008, Damballa released instructions for remediating Kraken compromises (www.damballa.com/downloads/brochures/Kraken_Remediation.pdf) and a technical whitepaper/industry response (www.damballa.com/downloads/press/Kraken_Response.pdf) that included Kraken C&C domains that companies/organizations could use to prevent compromised systems from talking to the Kraken control servers.

Damballa (who codeveloped and administrates the malfease malware repository—www.malfease.oarci.net) also shared malware samples (that could be downloaded by researchers/practitioners) with SANS ISC (isc.sans.org/diary.html?storyid=4256) and OffensiveComputing (www.offensivecomputing.net/?q=node/699).

From the article: “It hasn't published any details of the exploits used to any bugtrack, nor has it contacted any vendors to alert them of the issue.”

Kraken didn't use any exploit to propagate; there were no vendors to contact. Like Storm, Kraken propagated through social engineering (e-mail and instant message).


Paul Royal

Tech Tip Tuning

I like to read the Tech Tips, as I did with David S. Sinck's tip “Treating Compressed and Uncompressed Data Sources the Same” (LJ, December 2008, page 56). Here are some remarks and suggestions.

I strongly recommend using double quotes. The presented solution silently misses all files with one or more whitespaces in its name.

The only purpose of the line:

F=$(echo $1 | perl -pe 's/.gz$//')

is to remove the last file extension from the filename. This is done with Perl, an interpreter for a language much more powerful than Bash, a subshell and a pipe. There's too much effort to remove a few characters (in every loop cycle!). The first two lines of the function could be replaced by a parameter substitution, which costs nearly nothing. So, with quoting, we get the following:

function data_source ()
{
  local F=${1%.gz}           # remove file extension

  if [[ -f $F ]] ; then
    cat "${F}"
  elif [[ -f $F.gz ]] ; then
    gunzip --stdout "${F}.gz"
  fi
}    # -------  end of function data_source  -------

for file in * ; do
  data_source "$file" | ...
done



Fritz Mehner

Photo of the Month

Have a photo you'd like to share with LJ readers? Send your submission to publisher@linuxjournal.com. If we run yours in the magazine, we'll send you a free T-shirt.

Tux and Tuxina cake, submitted by David Backeberg, taken at his friend's wedding.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix