The Security Skeptic

Domain Name Seizures Prominent in Dismantling the ZeuS botnet

On 19 March 2012 Microsoft, FS-ISAC , and NACHA filed a Complaint with the US District Court, Eastern District of New York, against thirty nine John Doe defendants who allegedly participated in a criminal enterprise, the Zeus botnet.

Microsoft alleges that ZeuS botnets have purportedly infected an estimated 13 million PCs and have been used to steal over $100M during the past five years. The official Microsoft blog post provides a summary of Operation b71, which involved seizures by US Marshalls of command and control servers in Scranton, PA and Lombard, IL., sinkholing of traffic for subsequent analysis, and the seizure of Harmful Domains and IP addresses used to manage and operate the criminal botnet infrastructure.

Photo by ElDave

Gary Warner and Brian Krebs have again posted excellent analyses of the ZeuS botnet takedown.  Rather than duplicate their efforts,  I’ll instead highlight what I thought to be aspects of the ZeuS Complaint that went beyond actions from earlier takedowns (see Coreflood). I’ll then focus on the seizure of Harmful Domains and comment on the value of providing complete and accurate DNS, Whois, and registry information in legal orders. 

The Complaint and the xTRO 

Microsoft, FC-ISAC, and NACHA identify the 39 John Doe Defendants by their fictitious names: the user IDs of email addresses of the defendants found in Whois records for the thousands of domains enumerated in the Complaint. The claims for relief include the usual suspects Microsoft has included in prior complaints against Rustock, Coreflood or Kelihos: computer fraud or abuse, spam, electronic communications privacy violations, trademark or Lanham Act violations, trespass, unjust enrichment...

New among the claims for relief is the allegation that the 39 defendants acted in concert and conspiracy and thus violated the RICO (Racketeer Influenced and Corrupt Organizations) Act.

John Does 1-3 are alleged to have organized the racketeering enterprise and John Does 4-39 to have contributed various skills to the enterprise: botnet, exploit, and web software development, mule recruiting, botnet and hosting administration, domain and IP registrations.  Botnet customers and "cash out" operators who sold credit card and credentials obtained via infected PCs were also listed.

The Complaint thus alleges that certain defendants conspired as a group to construct the botnet, others used (“leased”) to commit criminal acts, and still others turned stolen properties into cash.

The Temporary Restraining Order is ex parte because the fraudulently composed Whois records are the only identification available to the plaintiffs.The Court accepted the plaintiffs' claims that harms cited in the Complaint will continue unless the defendants are restrained, and ordered simultaneous actions at hosting companies (Continuum Data Center LLC and Burstnet Technologies, Inc.) 'to disable and seize servers and associated stored data' at hosting centers and to monitor and collect traffic for analysis.

Photo by xfordy

John Doe Defendants

The Court also ordered domain registries with US presence to assist in discovering the true identities of John Does 1-39, redirect traffic to servers at a Microsoft secured IP address and to disable Defendants' IP addresses.

It's noteworthy that the order sought to minimize collateral damage to parties that are not named as defendants but are affected by the seizure of equipment and disconnects.

Seizing Harmful Domains

Domain names and name servers play a prominent roles in the ZeuS criminal enterprises. "eCrime" name servers operated by criminals are used to resolve host names for command and control servers and for servers that host ZeuS files.  In Guidance for Preparing Domain Name Orders, Seizures & Takedowns, I explain that providing complete and unambiguous information to domain name registration providers can prevent confusion or delay, and may help prevent or minimize collateral damage. The ZeuS xTRO is a good case study for why I believe this guidance paper is important. 

In my thought paper, I point out that seizures typically instruct registries or registrars to modify the TLD zone file, the domain name registration record (and what is displayed by Whois), and the registry database (of domain names). In the ZeuS botnet xTRO, the Plaintiffs instruct the TLD registry operators to take the following action:

"2. For currently registered domains, the domain name registrant information and point of contact shall not be changed and associated WHOIS information shall not be changed;

"3. Domain names shall not be deleted or otherwise made available for registration by any party, but rather should remain active and redirected to IP address 199.2.137.141;

"4. Domain names shall not be transfered to any other person or registrar, pending further notice from the court.

"5. The Registries shall assume authority for name resolution of domain names to IP address 199.2.137.141 using the name servers of the Registries;

"6. Name resolution services shall not be suspended"

Instruction (2) is clear with respect to preserving registrant and point of contact information, but a consequence of saying only that "associated WHOIS information shall not be changed" is that some of the Whois returned is exactly what was in the registration data "pre-seizure",some of the Whois returned has the registrant/contact information the same as "pre-seizure" but the name server information is changed to NS1.MICROSOFTINTERNETSAFETY.NET, and Whois for some (try FILMV.NET) returns conflicting NS data from the the "thin" .NET registry and the sponsoring registrar. These inconsistencies might have been prevented if specific instructions for how name server information associated with the domain name had been provided.

(3) and (4) instruct registries or registrars to set domain status codes. These are adequately clear, but to eliminate any ambiguity, the order might have specified the exact EPP Status Codes for both registrar (client) and registry (server).

(3) further instructs the registries to keep the domain names "active and redirected to IP address 199.2.137.141." Neither instructions (3) nor (5) make clear whether the Plaintiffs are asking for changes to TLD name server configuration, name service for each domain name listed in the Complaint, or hosting, so they could be interpreted to mean that the registries are supposed to modify the name server configuration information ("glue") in the TLD zone file. They could also mean that Registries should provide name resolution for the Harmful Domains (which would be well out of scope).

A DNS lookup using the dig command shows that 199.2.137.141 is asssociated with a name server, NS1.MICROSOFTINTERNETSAFETY.NET.  In this case it was easy to deduce that the Plaintiffs' intention was that Microsoft was to act as the authority for the nameservers and would provide authoritative name resolution for the domains from a name server operating at IP address 199.2.137.141. In other (future) cases, orders could more accurately say "we want TLD name servers to be configured so that the authoritative name server for all the Harmful Domains listed in the Complaint is NS1.MICROSOFTINTERNETSAFETY.NET/199.2.137.141". The Plaintiffs are then in a position to decide whether to host zone data for the Harmful Domains or to return NXDOMAIN for hosts in the Harmful Domains".

(6) instructs that "name resolution services shall not be suspended". A random sample of the names in the xTRO shows that some return non-existent domain (NXDOMAIN) and some timeout without a response. So by some definition, either (6) was not executed properly by some parties subject to the order but the instruction did not make clear whether "name resolution services" applied to the TLD, which is responsible for identfying the name server(s) associated with the Harmful Domains listed in the Complaint, or resolution of host names associated with the Harmful Domains.

Closing remarks

Inaccuracies and ambiguities are not uncommon in legal orders, in part because the courts or plaintiffs are unfamiliar with the DNS or domain registrations, are imprecise when using domain name-related technology, operations, and terminology, or pressed for time. Checklists like those provided in Guidance for Preparing Domain Name Orders, Seizures & Takedowns may be beneficial in minimizing omissions and inaccuracies. 

David Dittrich has written a brilliant post on the Zeus botnet civil action entitled Thoughts on the Microsoft "Operation b71". One of the points he makes dovetails nicely with what I've discussed here:

"The act of writing up a complaint, backing it up with declarations in support of the plaintiff's motions, and having a federal judge review and grant plaintiff's motions is a very clear, very thorough, and very public justification for taking bold action. This process explains of who is being harmed, how they are being harmed, what can be done to stop the harm, and why the court should grant the plaintiff's motions. If this were a federally funded research study on developing a treatment for a disease, it is this level of detail that must be provided in order to get approval from ethics review boards. If we require such justification of doctors doing risky medical research that can harm us, why should we not have to similarly justify risky actions we take to resolve infected computers? This is the kind of standard that is warranted in order to show defensible justification for taking risky and aggressive action, before such action is initiated."

A late, final word

A recent analysis of operation b71 by Michael Sandee calls attention to the easily overlooked issue that collateral damage is not limited to suspending or making legitimate domains or web sites unreachable. A criminal enterprise the size of ZeuS will no doubt be the target for numerous investigations. Absent sufficient information sharing, cooperation, coordination and trust among investigating parties, there is too much room for error or interference, and one party's success can hamper the erstwhile and equally important efforts of others. Looking ahead, providing clear instructions for domain registries or registrars can be an important part of the level of detail that Dittrich insists must be provided.  Coupling this with the kinds of reasonable efforts Sandee encourages to verify that domains listed in complaints are "harmful" when the legal orders are executed is equally important to minimize collateral damage.

A Behavioral Analysis Unit assessment of a APT unsub

The US Federal Bureau of Investigation's National Center for Analysis of Violent Crime (NCAVC) has four Behavioral Analysis Units:

• Unit 1 deals with counterterrorism, threat assessment;
• Unit 2 handles crimes against adults; 
• Unit 3 investigates crimes against children; and 
• Unit 4 manages the Violent Criminal Apprehension Program-ViCAP.

An APT Unsub Profile

If the FBI were to create an APT behavior analysis Unit (5) dedicated to assessing APT actors, and on the extraordinarily small chance that the writers of Criminal Minds were to run out of horrible, real world crimes to base scripts on, the story writers just might profile "the APT unsub" as follows:

The APT unsub is a sponsored actor. We believe his sponsor is a nation state. He has ample funding and technology at his disposal. While not necessarily the author of malicious software, we believe he has knowledge of and access to executable code that exploits common vulnerabilities. 

He combines or modifies malicious software to penetrate network defenses, compromise hosts, monitor activity or exfiltrate information. The APT unsub's activities can persist without detection for long periods of time. He targets military, commercial, government, or critical infrastructure facilities and networks. The APT unsub deliberately seeks out and collects information that can offer a military, commercial, or similarly highly valued advantage for his sponsor.

Photo by PopCultureGeek

He is patient and meticulous, willing to sift through and correlate information fromsurveillance conducted across many hosts over long periods of time.

 The APT unsub studies targets carefully before acting. He is skilled at disguising his intent. Through social engineering initiated via electronic mail, the unsub manipulates individuals within a targeted organization or agency by instilling such fear or uncertainty that the individual acts in haste and in so doing, introduces an infection that is designe to spread across the infected indvidual's network. Malicious code operating on the infected computers are remotely controlled and directed by the unsub to look for information of interest to the unsub's sponsors. This is not a single attack but an occupation.

Unit 5 would next explain what the investigating parties should look for as they pursue the unsub.

Photo by Christophe Verdier

Look for unusual traffic patterns on your networks. Client computers that usually generate "request traffic" outbound may begin to generate "response traffic", typically of much larger volume and most likely encrypted. Devices on your network may receive login requests from unauthorized systems. New application traffic and executing processes associated with remote control protocols may appear in event logs on your client computers. Your client computers may begin to resolve domain names using resolvers that are unfamiliar or unauthorized. Remember. You're looking for new or different activity: any network or host operating behavior that is "never before seen" should be carefully examined for possible malicious intent.

Lastly, Unit 5 might act in the interest of public safety by attempting to inform the public.

While we are taking measures to identify and apprehend the perpetrators, we advise the public to become familiar with the APT unsub and the threat he poses. Most importantly be vigilant in monitoring for signs of this threat. We are circulating a handout that summarizes what we've discussed here. The handout recommends measures you should implement to mitigate the threat this unsub poses.

The handout would look remarkably similar to Mitigation Guidelines for Advanced Persistent Threats.

A practical resource for managing advanced persistent threats (APTs)

You don't have to search very hard to find some Chicken Little fluff piece heralding sky-falling doom in the form of an advanced persistent threat (APT). If your experience is like mine, however, fewer than one in ten of the resources you find do more than tell you what an APT is, warn you that you are already a victim or a victim in waiting, or promise you that you'll be better protected if you buy *this* product.

Photo by Lori

Kudos to the folks at Public Safety Canada for compiling a concise report entitled Mitigation Techniques for Advanced Persistent Threats. They helpfully deconstruct APT by offering a practical, consumable interpretation of each term. 

Advanced

The context for Advanced, for example, is further broken down into sub-contexts. The Report explains that malicious software is not always advanced in the sense that it is "sophisticated" but that it is often readily available exploit code that is simply better leveraged than earlier attacks. Advanced applies more to the growing body of evidence that indicates that state actors and sponsors "select their targets and refine the attack such that selected individuals in targeted organizations become the conduit to the organization's information assets".

Persistent

The context for Persistent is also broken into aspects. The reconaissance aspects is a panoply of P's: the attackers are patient, painstaking, precise, purposeful, and persevering. The execution aspect of a APTs is very "spy" oriented: clandestine and credibly socially engineered.

Threat

The threat is simple: exfiltration of information of a sensitive or secret nature that provides an APT sponsor with "a strategic, diplomatic, military, competitive, technological or economic advantage." 

Most online resources I've found stop here (feel free to recommend any in a comment). This Report goes on to explain the chronology of an APT attack, describing each stage - reconaissance, social engineering, establishing backdoor and C&C, achieving the objective, and maintaining presence. This chronology is a great segue to the remainder of the Report because it gives context for the strategies Public Safety Canada recommends that potential target organizations should take, how to monitor for and detect potential APT activity, and mitigation measures.

The information Public Safety Canada shares in these sections is not radically new; in fact, there isn't a single monitoring, detection, mitigation or remediation measure that hasn't been recommended before. The value of these sections, however, is twofold: first, Public Safety Canada's taken the initiative to gather this information from reputable sources (Aus DSD, McAfee, RSA, GAIC...), consider the growing body of work, and then condense the information into a single reference. More importantly, by creating a single reference, it allows us to realize that defending against APTs is as much a matter of doing better what we do today, with existing instrumentation, as it is introducing new techniques or technology.  

I'm always excited to share when I find a resource that is FUD free and full of useful information. This Report doesn't contain a silver bullet, but it will lend clarity to APT discussions and it may help you define a better strategy for defending against APTs than you have today.

USB Home Malware Test Kit

Leveraging on the success of the USB Home Pregnancy Test Kit, Malweradicator, a new player in the antivirus market, has adapted this "make it better by throwing hardware at the problem" strategy and has developed a USB Home Malware Test Kit. 

A company spokesperson claims the Malweradicator is OS-agnostic and is capable of detecting infections on systems running Windows, Linux, and Mac OS. Future releases will include iOS, Android, and other tablet OSs. The company has yet to formally announce availability for the product. Parties close to Malweradicator hint that a 1 April 2012 release date is likely. 

Another Microsoft botnet takedown (Kelihos)

Microsoft has added another notch in its botnet gun belt, taking action against subdomain registry operator, cz.cc. What distinguishes Operation b79 from Rustock is that Microsoft has named defendants - Dominique Alexander Piatti and the dotFREE Group SRO - along with nearly two dozen John Does in its ex parte temporary restraining order.  The complaint alleges that the Defendants ran command and control operations for a fast flux botnet named "Kelihos" via domain names assigned from cz.cc: specifically names such ascyvgtbxa.cz.cc were created for the purpose of hosting malware, running scareware or spamming campaigns.

Photo by Willie Lunchmeat

Microsoft claims that through these actions, the Defendants knowingly caused harm to Microsoft, its customers, and the public. 

Claims for Relief

The claims for relief against the Defendants range from violations of the Computer Fraud & Abuse Act  Title 18 (1030), CAN SPAM Title 15 (7704) Act, and Electronic Communication Privacy Act Title 18 (2701) to common law trespass, unjust enrichment, and negligence. The complaint demands for a jury trial.

The article at Microsoft's TechNet Blog explains that "Naming defendants in this case marks a big step forward for Microsoft in making good on its commitment to aggressively protect its platform and customers against abuse from whomever and wherever it may originate. Naming these defendants also helps expose how cybercrime is enabled when domain providers and other cyber infrastructure providers fail to know their customers..."

Subdomain Registrations Play Prominent Role

In this same blog post, you'll read "...this case highlights an industry-wide problem pertaining to the use of subdomains. Under U.S. law, even pawn brokers are more effectively regulated to prevent the resale of stolen property than domain owners are to prevent the use of their digital properties for cybercrime. For example, pawn shop operators must require a name, address and proper identification from customers, while by contrast there are currently no requirements necessitating domain hosts to know anything about the people using their subdomains –making it easy for domain owners to look the other way."

Rod Rasmussen and I warned that subdomain registrations would become a problem in 2008 in an APWG white paper,Making Waves in the Phisher’ Safest Harbors: Exposing the Dark Side of Subdomain Registries. In that article, we explained that subdomain registries are appealing to phishers for several reasons:

"1. Many hosting accounts are free, easy to set up, and simple to remotely administer. In some cases, a subdomain registration only requires a first name and email address for registration.

"2. With a small investment of time, phishers can find hosting services where registration is virtually anonymous. Within minutes, a phisher can upload a scam site immediately upon completion of a registration.

"3. Subdomain registries do not collect complete and accurate contact information. This exacerbates the already challenging process of deleting or “taking down” a phishing subdomain.

"4. Many subdomain registration services have no obvious or formal dispute resolution mechanism.

and

"5. Hosting service providers who fear reputational or other harm to their businesses may be reluctant to suspend a customer account without further investigation, subpoena, or court order."

These characteristics make subdomain registrations appealing for scareware and other scams as well. Kudos to Microsoft for taking aggressive action, exposing these issues, and hopefully setting precedent for others to take like action. 

The Kelihos complaint targets subdomain registries, but some of the language Richard Domingues Boscovich (Senior Attorney, Microsoft Digital Crimes Unit) uses to describe the subdomain problem - "no requirements necessitating domain hosts to know anything", "easy for domain owners to look the other way"  - are similar to objections that law enforcement, security professionals, and IP&T attorneys make regarding WHOIS and domain name registration policies and requirements. Microsoft has consistently pushed the envelope in its offensives against botnets and malware. Who's going to get caught in Microsoft's crosshairs next? 

Coreflood: A techie tour of the Complaint

A US Federal Court judge granted the Justice Department (DOJ) a temporary restraining order (TRO) and with it, the rights to seize  domain names of the Coreflood botnet. The TRO also granted rights to seize the command and control (C&C) servers and replace these with sanctioned servers. The sanctioned servers, operated on behalf of the DOJ by the Internet Systems Consortium (ISC), emulated Coreflood's C&C communications with the Coreflood bots (infected computers) and sent instructions to the bots to go idle (stop).

Wired provides a summary of the post-restraining order activities of the DOJ, ISC, et. al. Gary Warner's CyberCrime & Doing Time provides a more technical breakdown. Gary's column discusses how the Coreflood temporary restraining order  expands on prior court rulings that granted the use of sinkholes to allow ISC's sinkhole to impersonate the C&C (irony here) and direct the bots to shut down.

This is certainly a compelling element of the TRO, but techies and in particular, anyone who is interested in anticrime activities may also want to take note of some of the language in the complaint itself.

Coreflood: the Defendants The complaint lists only John Does, but explains later  (Paragraphs 7, 20) that the Defendants are only known as the registrants of a set of domain names and that the Defendants "registered the Coreflood Domains using stolen or fictitious identities, or using services that shield the name of the nominal registrant from public view. On information and belief, the Defendants are located outside the United States." The services this clause describe as "shielding" the Defendant's names are known as privacy protection services.

It's worth noting that the DOJ calls attention to the misuse of these services (Abuse 1, Abuse 2). Goverments and law enforcement agencies have recommended changes to ICANN's current policies regarding privacy protection services to mitigate these abuses (RAA1, RAA2, RAA3). 

Civil Action

Paragraph 1 of the complaint asserts that this is a civil action, not a criminal action (Action 1, Action 2). A branch of the US government is bringing a civil suit to federal court claiming that the defendants have violated federal statutes. In this case, the Defendants  are accused of distributing and using malware to commit "wire fraud, bank fraud, and unauthorized interception of electronic communications". This is a civil action intended to remedy harm from alleged criminal acts, not a criminal indictment for the alleged criminal acts.

"Law Tech" Description of Coreflood

Paragraphs 2 -7 and 15-23 of the complaint provide a low tech description of Coreflood including a brief overview of what a botnet is and how bots are controlled by C&Cs. The attorney who prepared the complaint effectively explains how IP addresses were used to initially identify the C&Cs, how these addresses were used to obtain the domain names, how  the infected computers used these domain names to contact the C&Cs and, how registration (Whois) information was used to identify the John Doe Defendants.

Paragraph 22 is particularly important. It describes a behavior of the Coreflood trojan that runs on infected computers that supports the substitution of sanctioned servers in place of the Coreflood servers and justifies allowing the ISC-controlled servers to send "stop" commands to the bots  (read Gary Warner's column).

Jurisdiction

Paragraphs 8 and 10 establish jurisdiction. The complaint identfies the Defendants as foreign nationals" but cites Title 18, United States Code, Section 1345(a)(1), Injunctions Against Fraud and Title 28, United States Code, Sections 1331 & 1345, diversity of citizenship instances in civil actions to hold the defendants subject to the US Federal Court jurisdiction on the basis that the defendants used infected computers located in the United States to perpetrate fraud. In this case, the jurisdiction was determined to lie where the acts were committed, not where the perpetrators were at the time they were committed. (I'm told by a colleague that the legal nexus of the crime can be in either place and that it is sometimes contested but here the jurisdiction is US and the nexus is Connecticut since at least one victim does business there.)

Schemes to Defraud

Paragraphs 10 through 14 describe the schemes to defraud. The attorneys step through the elements of the fraud, identify the victims and the harms inflicted. Sadly, the Assistant US Attorney couldn't resist playing the "threat to national security" card when he explained what a botnet is. While the attorneys cited a small number of tangible loss cases, they also cite ongoing harm to the owners of the infected computers. It's heartening to see this argument used to support a civil action.

Paragraphs 24-32 list the counts of the complaint. The wire fraud count is based on the defendants having devised a scheme to defraud and consequently used the Internet to transmit "writings, signs, and signals for the purpose of executing such scheme.. in interstate and foreign commerce". A count of bank fraud follows: "Defendants did knowingly execute a scheme and artifice to defraud a financial institution." A third count, unauthorized interception of electronic communications, covers keylogging, traffic capture and other information gathering that C&C's could instruct bots to perform.

Temporary Restraining Order

The complaint requests a TRO for each count and then asks the court to issue the following against the "Defendants and all those receiving notice thereof, including the Domain Service Providers":

1. A temporary restraining order and preliminary injunction that prohibits the Defendants (a) from using Coreflood to engage in wire fraud, bank fraud, or unauthorized interception of electronic communications, and (b) from running Coreflood on any computers not owned by the Defendants, by authorizing the operation of a substitute command and control server to give effect to the Court's orders;
2. A permanent injunction that requires the Defendants to uninstall Coreflood on any computers not owned by the Defendants and authorizes the operation of a substitute command and control server to give effect to the Court's orders; and
3. Such other relief as the Court deems just and proper.

This is noteworthy because it asks the Court to grant a broad remit in order to remedy the acts, including remote control of infected computers.

What Does the Future Hold?

The seizure and substitutions have played out; however,  consider how the action may influence future takedowns. The action calls attention to inaccurate Whois and misuse of privacy protection services in a very public way. This may affect policy changes to Whois and domain registration services. It grants permission to issue commands to software running on millions of personal and business computers and instructs the Defendants to uninstall software associated with the fraud. This is beneficial in the case of Coreflood, but the grant raises questions as well. Under what circumstances should governments instruct software on privately owned or business computer systems? What if the instructions don't produce the desired result? What if the instructions cause harm? How has the government reconciled its apparent actions here with the commission of crimes described in Title 18, United States Code, Section 1030 (a) (2): “intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains— (C) information from any protected computer"?

For me, the most intruiging issue is "What will malware writers and scammers do to counter this measure?"

A convocation of Conficker reports

The Conficker worm is still around and still newsworthy. On 24 January, 2011, the Conficker Working Group published its Lessons Learned report (summary, pdf),  a DHS funded effort prepared by the Rendon Group.

Jose Nazario of Arbor Networks has an insightful "insider" blog post on the announcement and report. I won't steal Jose's thunder by summarizing his post, but I will encourage you to read and appreciate the three takeaways he describes.

I'm also flattered and humbled that Jose mentions my 11 May 2011 report in his blog:

"Another after action report came from ICANN, who was instrumental in the response. The report was published in May, 2010, and is largely a timeline of events. The two together are very worthwhile reading if you are involved in the operational security community."

The two reports, along with Jose's blog post, are indeed complementary and worth reading together.

How to keep ALL your software patched and secure

If you pay any attention to computer security, you know that you should run scheduled checks for Windows or Apple Updates to keep your operating system software up to date, be it Windows XP/Vista/7 or MacOS 10.x. This is a necessary step to protect your computer from attacks that exploit vulnerabilities in software.

Necessary, but not sufficient.

Attackers experiment with software of all types, from browsers and email clients to graphics, business and office software. They  find programming flaws and exploit what they find to gain control of your computer. Attackers don't discriminate between free-, share-, or commercial applications: if the application is popular enough, some bad actor is searching for an exploit.

Windows and Apple Updates only keep operating system software "patch current". You need to keep all your software patched to protect yourself as much as possible against known vulnerabilities and exploits.

At first glance, this sounds like an impossible or full-time task. It's not uncommon for a user to install and use several dozen applications over time (my office MacBook has over 100). Not all of these applications offer automatic updates. Searching and finding patches for all your software manually is more than the average user will ever consider. Surely there's an easy way to manage this? Yes.

I've had some success using Appfresh for my Mac, and Secunia Personal Software Inspector (PSI) for my Windows XP/Vista/7 PCs. Let's have a look.

Appfresh

Appfresh scans your Mac to enumerate all installed applications, widgets, and plugins and will check for Apple Updates. Appfresh informs you whether your installed software is up to date or whether an update is available for installed software that is not patch current. Appfresh also tells you when you last used the software: use this to decide whether it's best to simply remove the program.

A right-mouse click on an application provides options to check for and download updates.

Appfresh has native support for commonly used software and supplements this support with information from a reputation-based software tracking community, iusethis. Appfresh lets you register with iusethis so you can obtain comments, notices, and reviews of software you've installed. Appfresh can be scheduled to run automatically at startup or on a day and time that's convenient for you.

Appfresh is still under development but I've found the current version to be stable and useful. Try it.

Secunia PSI

Like Appfresh, Secunia PSI scans Windows-based PCs for vulnerable or out-of-date programs and plug-ins. Secunia PSI has a simple and advanced interface mode. The simple mode enumerates insecure software and provides a threat rating; a Category 5 threat, for example, is an indication that the insecure software is currently being exploited by attackers on the Internet to gain control of PCs. Simple mode  provides a convenient one-click "solution" that connects you to a vendor patch link.

Advanced mode provides more detail for power users. Separate tabs provide details about insecure programs, end-of-life programs, and security issues associated with browser settings and plug-ins. You still have a one-click "solution" that connects you to a vendor patch link.

Secunia supports an extensive database of security advisories for users who want to understand the nature of threats in some detail. This is available from simple or advanced mode. Secunia PSI can run as a service, accessible from the System Tray, to continuously monitor and report on the patch status of your installed software. I've use PSI for several years now and highly recommend that you try it.

Last Word

Unpatched software leaves you just as exposed to attack as unpatched Operating Systems. Appfresh and Secunia PSI won't automatically update your installed applications but they do warn you when your applications are vulnerable and they make the update process simple. Invest a small amount of your time to regularly scan your software and keep your installed software up to date.

Zeus Trojans - worst threat yet?

Laura Mather and her Silvertail Systems colleagues have recorded two very fine webinars on Man in the Brower (MitB) attacks  and the Zeus Trojan. A Man in the Browser attack is one in which a trojan program on a compromised computer is able to capture information a user types into browser forms and intercept then modify content a web server attempts to display to the user. Zeus is a particularly insidious trojan because it is allows attackers to customize MitB attacks against specific targets (largely financial institutions) and to defeat both two-factor authentication and machine ID authentication measures. Based on some statistics Laura presents during the Zeus Trojan webinar, you quickly appreciate why I call it insidious: as a result of customization, Zeus is not one but nearly 800 botnets spanning ~1.6 M bot hosts and attacking over 1100 brands, 85% of which are financial institutions.

Laura recently asked APWG colleagues to comment on the suggestion that “trojans like Zeus are the biggest threat to small business in the last decade”. I'd say that Zeus is the most recent but not nearly the last biggest threat to small business. My experience is that small business networking and security differ very little from residential broadband and differ *dramatically* from medium to large enterprise. Common attributes of small business networking and security I’ve encountered include:

• very little if any in-house networking or security expertise 
• employees are not sophisticated users 
• employees receive little or no training and have little or no security awareness beyond “I run antivirus so I’m safe from all that”.
• the security or professional services small businesses can afford are not as competent as medium/large enterprise IT staff or  the consulting services medium/large enterprises can engage 
• the security networking technology small businesses invest in is often residential quality, freeware, or a modest increment (i.e., from a $100 broadband firewall/router to a $300 UTM device) 
• default configurations are the rule rather than the exception; in fact, a fair number of small businesses use default configurations in complete ignorance or because they are afraid to alter configurations for fear of breaking something

My initial response to Laura was “You’re spot on when you say "something like Zeus can destroy a small business" but honestly, it doesn't take a Zeus in most cases.” Mulling the Zeus scenario a second time, particularly having watched the webinar, I think the threat is as worrisome as Laura suggests. Small businesses look like a sweet spot for financial abuse, having more capital than individual bank customers and less access to the types of detection and countermeasures larger organizations can acquire from companies like Silvertail Systems.

I also worry that the configuration agility Zeus introduces has broader applications than attacks financials. I’m thinking specifically of healthcare. If you really want a healthcare scare, run a security audit on your typical medical practice office network or NFP hospice. I have and they are not pretty. From experience, I’ll speculate that many of the attributes I mentioned earlier are commonplace among the typical physician, hospice, laboratory or diagnostic testing facilities you visit. I don't sleep well some nights thinking about the offices of physicians who manage my family’s care whose networks I haven't been invited to check. I’ll sleep even less now worrying that Zeus could be configured to target healthcare insurance providers.