When it comes to antivirus, how much coverage do you need? Everyone has different concerns when it comes to antivirus coverage. Some people want to circle the wagons and let very little into their networks, while others need some basic protection but prefer speed, speed and more speed. In this article I’ll discuss the new antivirus features in the FortiOS 4.0 MR2 for the FortiGate family and how your device can be configured for your preferred level of coverage versus performance.

Malware Lifecycles

All malware have a life cycle. Some are like shooting stars, blasting across the Internet infecting everything in their path and going out with a bang with the next signature update, leaving much news buzz in their wake. Others creep along, slowly infiltrating systems with their variants, keeping their name alive for months to years. Still others have gone the way of the dinosaurs and only live in memory, no longer spreading or able to spread on modern operating systems, aka the zoo viruses. In general it is the actively spreading viruses that a user need be overly concerned about and use products providing coverage for these active malware.

Today viruses are still tracked using the Wild List, a vendor independent managed list of the most active viruses. This is used as a minimal benchmark for vendors, to ensure that customers are protected from the most actively reported threats. The viruses that slow down and eventually drop off of this list eventually find themselves on the list of zoo viruses and are rarely, if ever, seen in the wild again.

Under the Hood

Although there are many different vendors of antivirus products most vendors use very similar techniques and need to deal with the same issues when trying to detect a virus. Most viruses are contained in a file of some sort, either self executable or as part of a format where it can be executed by another host program (e.g. such as a macro virus embedded in a document). Roughly 80-85 percent of the effort when examining a file is decomposing the file into a usable form for signature scanning. Decomposing the file is the process of extracting or converting the data of that file to a form where the signature scanning routines can match any known viruses in its corresponding database. For example, an incoming file may be an archive file, such as a zip archive, containing an executable file. If the file is sent in an email it is often in an ASCII format called base64. The file needs to be converted back to binary for deeper examination. This in-depth decomposition of the file is very often required for the most sophisticated viruses and therefore the full file needs to be buffered.

Flow or stream based antivirus is one of the latest techniques being used by network based products for scanning. They have a high throughput and use state based engines to keep track of what they have scanned, but they do have some limitations that probably can’t be solved due to the format of certain types of files. For example, some archive formats can not be streamed due to complexities in parts of their algorithms so streaming scanners have difficulty with these files. Heavily encrypted files, packed executables and file infectors may be difficult to detect using these stream based methods since not all the data will be available to assist in decryption of the files. Viruses embedded in documents require more in-depth extraction routines which are probably not commonly used in stream based scanning. Some files, such as polymorphic or packed files, require emulation in order to extract the clear viral code from its encrypted cocoon. Without this level of decomposition the number of different detection signatures that would be required is staggering to imagine. It’s not all bad news however. Flow or stream based methods are quite effective and fast against certain types of malware such as static worms (executables that don’t change their binary composition when they spread), certain Trojans, spyware, adware and other more static malware. Stream methods are useful for large files too, having little file size limits, but if you consider most malware files are relatively small (so they can spread quickly) the only advantage would be on large archives of files (which are most likely manually created and infrequently spread).

What Do You Need?

In this part of the article I’ll discuss the different coverage needs and how you can configure the latest FortiGate products to provide the appropriate level of protection and coverage. First I’ll discuss some of the different users and their basic needs.

• The Need For Speed: Some users are not overly concerned about full coverage for every virus that ever existed. They just want the Internet as fast as they can get it. For these users basic protection against most malware that is actively spreading is normally sufficient. Many of these users will also use host based antivirus if they want more protection at the host but still keep high speed networking (e.g. ISPs need to provide certain levels of performance so they may augment protection with host based security bundles for their customers). I’ll call these “High Performance” Users.
• On the Fence: Users in this category desire a bit more coverage but decent performance too. The malware coverage will go further back in history to malware that has lived over about the last year or so, but not go as far back as the ancient viruses of the 70s and 80s. I’ll call these “Cautious” Users.
• Nothing is Getting In: These users don’t want any viruses, no matter how old, in their networks. These users may be willing to sacrifice a bit of performance for full detection of every malware that has ever existed. I’ll call these users “Guarded” Users.

First Things First, What’s in the Box?

In the next version of the FortiGate OS 4.2 there will be support (on some platforms) for larger antivirus databases and a new stream based antivirus scanning engine. The breakdown of the basic coverage types are a follows:

• Normal
  • This setting contains signatures for the most currently active threats. These threats are actively spreading on the Internet in some form or another, e.g.) via email, self spreading worms, etc.
• Extended
  • This setting extends the Normal setting to include signatures for recent but no longer active malware. Such as viruses that may have been actively spreading within the past year but have significantly or completely died off.
• Extreme
  • The extreme setting provides the largest coverage and includes coverage of nearly all malware detected by Fortinet including zoo viruses from ages past.
• Flow
  • The flow antivirus operates independently from the above settings and is used as an alternative to the proxy based antivirus settings (normal, extended and extreme). It is a stream based scanning method in which the network session is inspected in chunks. Although fast, there are limitations with stream based scanning technology such that not all files can be fully decomposed in order to properly scan for a virus. Flow based scanning is however very fast and effective against static threats such as worms, Trojans, spyware and related malware. The flow based antivirus will cover a subsection of what the extreme setting detects.

These settings can be enabled on a per VDOM basis and used for all antivirus protection profiles within that VDOM. As a side note, users can override a specific protection profile setting using the CLI if desired.

High Performance Users

For High performance users there is the option of using the Flow AV option, a stream based scanning engine, or the proxy based normal setting. This can be set per VDOM via the CLI or GUI. Navigate to the UTM menu and select the Antivirus->Virus Database menu item. On this page you will be able to configure your database settings that will be used by default by the antivirus protection profiles.

The normal antivirus database, containing detection for the most active threats, is available on all FortiGate models. Flow AV will only be available on certain newer models such as the FGT-80C, and other mid/high end models.

Cautious Users

For cautious users it is recommended to use the Extended setting. This provides coverage for both older threats, up to about one year, as well as any malware that is actively spreading. Older threats were previously active malware that have essentially died off and are no longer being reported to our servers. Although some of these threats continue to spread in small areas, they are no longer widespread.

The extended database is available on many of the newer mid to high end FortiGate Products.

Guarded Users

For guarded users the extreme setting is the way to go. This gives the largest coverage to prevent both the newest threats from entering the network as well as preventing users from downloading some old archives of legacy malware. Users also have the option of enabling the full grayware detection to scan for programs that may not necessarily be threatening but cause annoyance, such as adware.

The extreme database will be available on many of the newer mid to high end FortiGate Products.

Conclusion

When looking for a product to protect your network, be wary of what various products are offering. You may be looking for speed, but know the benefits and limitations of the different types of technologies so you can choose what is best for your network. Although the data sheet may look impressive in regards to performance numbers, ask what kind of coverage you are really getting. At least ensure that you can get coverage for the Wild List and other active threats with whatever product you choose. I hope this article helps you decide the type of coverage you require in your network and what products suit your needs. May your networks remain infection free.

A few days ago we encountered a new variant of the Symbian worm, Yxes, that we named SymbOS/Yxes.H!worm. This worm contacts malicious remote servers, which host Java Server Pages, and propagates by sending ‘attractive’ SMS messages. For instance, this new variant sends an SMS with an URL promising private information concerning a Chinese actress. Globally, the logic (and much of the code) is the same as in previous variants. Yet, there are a few updates, one of the main ones being the use of new remote malicious Java Server Pages.

I guess every analyst has noticed this variant of the malware contacts the following URLs:

http://XXXX/Jump.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...

http://XXXX/Kernel.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...

http://XXXX/KernelPara.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...

The PhoneType argument contains the model of the infected phone (e.g nokia3250, nokian95…), while the PhoneImei and PhoneImsi arguments respectively contain the phone’s IMEI and IMSI. The Source argument is new to this variant, and its use has not been reversed yet. It could possibly contain the name of the malicious website used to infect the phone.

The first of those JSP pages, Jump.jsp, redirects the user to a Chinese mobile social networking site (3g.kaixin001.com then wap.kaixin001.com). Actually, we had already noticed this behaviour in at least 2 former JSP pages used by previous versions.

The second JSP page, Kernel.jsp, actually replies the following string (host name removed):

http://XXXX/download/root/plugucsrv.sisx

And, from this location, we get a new minor variant of Yxes.D. This is a consistent behavior in Yxes: the worm indeed often works in pairs (e.g variants A, B, D or E download variants C, D or F). In this case, variant H silently downloads and installs a remotely hosted new version of variant D.

Its certificate says:

Serial Number:
 2a:2f:00:01:00:23:37:98:0c:73:b2:c7:69:17
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, O=Symbian Limited, CN=Symbian CA I
Validity
 Not Before: Jan 23 17:55:42 2010 GMT
 Not After : Jan 24 17:55:42 2020 GMT
Subject: C=CN, ST=Fujian, L=XiaMen, O=Xiamen Jindoucheng Tech Co. Ltd.,
OU=plugucsrv  2.1.0, OU=Symbian Signed ContentID,
CN=Xiamen Jindoucheng Tech Co. Ltd.

A notification has been sent to Symbian, who tells us the certificate should soon be revoked. Meanwhile, be cautious if you encounter a file named plugucsrv.sisx that installs as a ‘Setting Wizard’.

That variant D then actually does most of the malicious work: collect data on the phone, report it back to the malicious web servers and send SMS messages. The URLs it contacts are:

http://XXXX/bs.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=...

http://XXXX/index.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=...

http://XXXX/number.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...

The PhoneNumber, Succeed, Fail and Time arguments are obviously used to report contacts listed on the phone. The Succeed and Fail arguments are followed by an integer, probably the number of times that phone number has successfully been called or not.

Quite interestingly, if we try to get http://XXXX/bs.jsp, using a credible user agent (the malicious websites are known to check user agents – in particular, if it detects Internet Explorer, it responds “404 Not Found”):

SUCCESS reponse: 200 OK

http://hew1ett-packard.com/bs.jsp?

Notice the letter L of Hewlett has been replaced the number 1 (one).

So, the first malicious web server redirects the requests to another malicious web server, whose name is obviously intentionally crafted to fool the end-user. The URL does not respond any longer. Note that the Yxes worm is already known to use such mispellings:

• www.megac1jck.com
• www.mozi11a.com
• www.makt00b.com
• www.mediafir8.com
• www.megaup10ad.com

The third JSP, KernelPara.jsp, is still a mystery we have to work on. It returns a file named encrypt_Kernel_Para.txt. If its name is meaningful, it is likely to be an encrypted version of a file named Kernel_Para.txt (the worm already uses files with similar names: Local_Para.txt and Remote_Para.txt). In our case, its content is fixed and 32-byte long. It is not an XOR encrypted URL.

Finally, to evaluate the worm’s authors progress, it is interesting to follow the dates and versions of samples. The dates are taken from the first validity date in the X.509 certificate used to sign the sample, and the version numbers are included either in the main executable of the sample or in the certificate.

Apart from a sporadic ‘accident’ end of June 2009 where a version 1.0 goes in the wild (probably an error in versioning), we see the worm authors are continuously working on Yxes since the end of 2008. So my first prediction for 2010 was nearly bound to be true…

– The Crypto Girl

Flash exploits targeting the old integer overflow vulnerability (CVE-2007-071) in Flash Player are still relatively active and multiplying on the base of the early versions exploit code, with more or less slight differences. One such variation was rendered tremendously more stealth and reliable, thanks to the use of a Flash run-time packer spawning a multiplexer component. It is caught as SWF/Dloader!exploit by Fortinet, yet, detection of this peculiar variant across the spectrum of antivirus products is still extremely scarce. Let’s lift the lid on that variant by examining a sample here, named F1.swf.

As usual, all the dirty tricks here are done through ActionScript. ActionScript is compiled and stored in the flash file as bytecode. For analysis, it is therefore convenient to decompile the bytecode using casual tools, such as swfscan. Unfortunately, the latter having failed to decompile F1.swf for me, I had to summon swfdump, which can disassemble the bytecode into “something” easier to read. The analysis below is based on that dis-assembly.

1).F1.swf

Following below is the staticconstructor of class BinaryData, which contains an encoded payload:

sealed protectedNS([protected]BinaryData) class <q>[public]::BinaryData extends <q>[public]::Object{

staticconstructor * =()(0 params, 0 optional)

[stack:10349 locals:1 scope:3-4 flags:]

{

00000) + 0:0 getlocal_0
00001) + 1:0 pushscope
00002) + 0:1 debug [register 00=xorkey]
00003) + 0:1 findproperty <q>[public]::xorkey
00004) + 1:1 pushstring “PrivateKey01232dfdFSdf”————-Property “xorkey”: decryption key
00005) + 2:1 setproperty <q>[public]::xorkey
00006) + 0:1 debug [register 01=data]
00007) + 0:1 findproperty <q>[public]::data
00008) + 1:1 pushbyte 19
00009) + 2:1 pushbyte 37
00010) + 3:1 pushbyte 58
[...]
10352) + 10345:1 pushshort 245
10353) + 10346:1 pushbyte 123
10354) + 10347:1 pushbyte 2
10355) + 10348:1 pushshort 170
10356) + 10349:1 newarray 10348 params
10357) + 2:1 setproperty <q>[public]::data—————Property “data”: encoded payload
10358) + 0:1 returnvoid
}

As can be seen above, the decoding key “PrivateKey01232dfdFSdf” is hard-coded in the flash file, as well as the encoded payload. The class member (or “property”) holding the key being called “xorkey”, it is with a moderate surprise that we find out the nature of the decryption algorithm, consisting in a simple XORing of the payload with the key. This happens in the constructor of class Main:

constructor * <q>[public]::Main=Main/Main()(0 params, 0 optional)
[stack:7 locals:3 scope:10-15 flags: need_activation]
slot 4: var <q>[packageinternal]::loader:<q>[public]flash.display::Loader
slot 3: var <q>[packageinternal]::i:<q>[public]::Number
slot 2: var <q>[packageinternal]::j:<q>[public]::Number
slot 1: var <q>[packageinternal]::bytes:<q>[public]flash.utils::ByteArray
{
[...]
00029) + 1:2 pushbyte 0
00030) + 2:2 convert_d
00031) + 2:2 setslot 3—————————counter i=0
00032) + 0:2 jump ->77
00033) + 0:2 label ——————————-decryption loop start
[...]
00039) + 2:2 getlex <q>[public]::BinaryData
00040) + 3:2 getproperty <q>[public]::data————encoded flash
[...]
00044) + 3:2 getlex <q>[public]::BinaryData
00045) + 4:2 getproperty <q>[public]::xorkey————-decoding key
[...]
00055) + 5:2 callproperty <q>[namespace]http://adobe.com/AS3/2006/builtin::charCodeAt, 1 params
00056) + 4:2 bitxor———————–decoding algorithm: XOR

00057) + 3:2 setproperty <l,multi>{[private]Main,[packageinternal]“”,…[Truncated]}———-store decoded byte in slot 1
[...]
00077) + 0:2 getscopeobject 1
00078) + 1:2 getslot 3
00079) + 1:2 getlex <q>[public]::BinaryData
00080) + 2:2 getproperty <q>[public]::data
00081) + 2:2 getproperty <q>[public]::length
00082) + 2:2 iflt ->33————————loop if counter i is lower than length
00083) + 0:2 debugline 23
00084) + 0:2 getscopeobject 1
00085) + 1:2 findpropstrict <q>[public]flash.display::Loader
00086) + 2:2 constructprop <q>[public]flash.display::Loader, 0 params
00087) + 2:2 coerce <q>[public]flash.display::Loader
00088) + 2:2 setslot 4——————–Initialize a flash.display::Loader instance to load the decoded flash F2.swf
[...]
00105) + 1:2 getslot 4
00106) + 1:2 getscopeobject 1
00107) + 2:2 getslot 1
00108) + 2:2 callpropvoid <q>[public]::loadBytes, 1 params——--load F2.swf
[...]
00130) + 0:2 returnvoid
}

The decoded payload is flash itself and loaded again. Let’s name it F2.swf for clarity and proceed with our analysis:

2).F2.swf

In the constructor of class “Zasder” appears a piece of multiplexing code, which aims at adapting the exploit string to the player type and version:

{
[...]
00009) + 0:1 pushstring “4657530825060000…[Truncated]”
00010) + 1:1 coerce <q>[public]::String
00011) + 1:1 setlocal_1 ———————-exploit version: 1.swf
[...]
00024) + 0:1 pushstring “4657530825060000…[Truncated]”
00025) + 1:1 coerce <q>[public]::String
00026) + 1:1 setlocal r6–——————–exploit version: 6.swf
[...]
00042) + 0:1 pushstring “4657530825060000…[Truncated]”
00043) + 1:1 coerce <q>[public]::String
00044) + 1:1 setlocal r12————————exploit version: 12.swf
00045) + 0:1 getlex <q>[public]flash.system::Capabilities
00046) + 1:1 getproperty <q>[public]::playerType——————–query player type
00047) + 1:1 coerce <q>[public]::String
00048) + 1:1 setlocal r14
00049) + 0:1 getlex <q>[public]flash.system::Capabilities
00050) + 1:1 getproperty <q>[public]::version————-query player version
00051) + 1:1 coerce <q>[public]::String
00052) + 1:1 setlocal r15
00053) + 0:1 getlocal r14
00054) + 1:1 pushstring “PlugIn”————–“Top” case “PlugIn”
00055) + 2:1 ifne ->92—————jump to next top case if not equal to player type (stored in local variable r14)
00056) + 0:1 getlocal r15
00057) + 1:1 pushstring “WIN 9,0,115,0″——–sub case “WIN 9,0,115,0″
00058) + 2:1 ifne ->62—————–jump to next sub case if not equal to player version (stored in local variable r15)
00059) + 0:1 getlocal r6
00060) + 1:1 coerce <q>[public]::String
00061) + 1:1 setlocal r13———————-set exploit string (stored in r13) to 6.swf
[...]
00081) + 1:1 pushstring “WIN 9,0,47,0″———sub case “WIN 9,0,47,0″
00082) + 2:1 ifne ->86
00083) + 0:1 getlocal_1
00084) + 1:1 coerce <q>[public]::String
00085) + 1:1 setlocal r13—————————-set exploit string to 1.swf
[...]
00092) + 0:1 getlocal r14
00093) + 1:1 pushstring “ActiveX”—————–“Top” case “ActiveX”
00094) + 2:1 ifne ->131
00095) + 0:1 getlocal r15
00096) + 1:1 pushstring “WIN 9,0,115,0″——–sub case “WIN 9,0,115,0″
00097) + 2:1 ifne ->101
00098) + 0:1 getlocal r11
00099) + 1:1 coerce <q>[public]::String
00100) + 1:1 setlocal r13———————–set exploit string to 11.swf
[...]
00198) + 0:1 findpropstrict <q>[public]::ldr
00199) + 1:1 findpropstrict <q>[public]flash.display::Loader
00200) + 2:1 constructprop <q>[public]flash.display::Loader, 0 params
00201) + 2:1 initproperty <q>[public]::ldr
[...]
00210) + 0:1 findpropstrict <q>[public]::ldr
00211) + 1:1 getproperty <q>[public]::ldr
00212) + 1:1 getlocal r16
00213) + 2:1 callpropvoid <q>[public]::loadBytes, 1 params——–load selected exploit version
00214) + 0:1 returnvoid
}

This is a simple two-level switch-case on the flash player type and version. In total, 12 combinations – corresponding to 12 exploit versions (1.swf to 12.swf) – are available. For example, 6.swf is used when the flash player is embedded in the browser and the player version is 9.0.115.

Looking closer at flash 6.swf reveals that it contains a large (therefore negative, as the value is signed: 0x840381de > 0x7fffffff) SceneCount value in DefineSceneAndFrameData. In other words, it is trying to exploit CVE-2007-0071.

All these 12 actual exploits are similar, the only differences being adjustments (for example the SceneCount value, bogus DoABC ByteStream) meant to ensure correct jumping to the shellcode depending on the player type/version. Details of these 12 exploits can be find at Application-Specific Attacks:Leveraging the ActionScript Virtual Machine.

As a conclusion, F1.swf works as a run-time packer/decryptor and F2.swf works as an exploit multiplexer. It is easy to make this kind of attacks more stealth and wide-ranged, based on that packer/multiplexer framework: Lots of binary customer packer techniques may be used, and more flash vulnerabilities (not only one) may be integrated in the multiplexer, in the fashion of “exploit-packs” webapps. The threat landscape is such that most AV companies master, to a certain extent, the art of x86 binary unpacking. Will they have to integrate Flash-bytecode unpacking in their products soon?

Guillaume Lovet contributed to this post

There has been a lot of confusion lately concerning the SymbOS/Yxes worm. Among those, it has now dawned on me the so-called Transmitter.C reported in numerous articles on the net (for instance, here and here), is not sexySpace.sisx (detected as SymbOS/Yxes.E!worm): those are two different malware.

Why ? As a matter of fact, several issues startled me (ordered from weakest to strongest point):

1. Transmitter.C is reported to send a massive amount of SMS messages (they are talking about 500 SMS). If Transmitter.C is Yxes.E, it is surprising because I cannot see any loop in the code indicating numerous copies of SMS are sent out, but of course, that would depend on the amount of contacts and SMS stored in the infected phone. Strange though. In Yxes.E, I do see the piece of code that sends SMS messages (see picture below), but I haven’t spotted any function calling it yet. The malicious code might be bugged. And, as a matter of fact, on the Nokia N95 I tried it on, Yxes.E did not succeed to send any SMS at all.

Figure 1. Assembly routine sending an SMS – disassembled with IDA Pro. The routine connects to the SendAs server. Then it creates a message object, sets the recipient (“to”) and finally the message body.

2. The screenshot of the SMS message mentions the string “A very sexy girl, Try it now!” with a link to a website hosting sexySpace.sisx. But, quite strangely, this string is nowhere to be found in the executable inside sexySpace.sisx (AcsServer.exe) nor in other resources. No, it is definetely not in Yxes.E. Of course, it could be dynamically decrypted from data in the executable, but then, why are similar strings in cleartext in Yxes.D (“A very interesting sexy game!try it soon!”) ?

3. Last but not least, Transmitter.C is said to spread as a trojaned version of a legitimate application named ‘Advanced Device Locks’, but sexySpace.sisx does not install as ‘Advanced Device Locks’ at all: it installs under the name ‘Sexy Space’ and does not include any part of the Advanced Device Locks application. That does not sound like the right sample at all.

To my opinion, Transmitter.C is not sexySpace.sisx, and thus not SymbOS/Yxes.E!worm. In that case, the SMS screenshot should probably be credited to Transmitter.C (and not SymbOS/Yxes.E!worm), which is interesting, because it includes a link to a website hosting sexySpace.sisx. This means Transmitter.C can be seen as a kind of dropper that tries to spread SymbOS/Yxes.E!worm.

– The Crypto Girl.

PS. By the way, if you encounter a sample of Transmitter.C please be forward it to submitvirus (at) fortinet.com.

Well that would be the usual boring answer from the guy down at the pub who isn’t really entering in to the spirit of the conversation. How about this one… Be shot out of a cannon – that’s pretty dangerous. But with a little thought we can make it safer. For a start, how big is the cannon? Where is it aiming? Can I wear a crash helmet? Can I land in a very large safety net? Can I get someone else to do it for me?

Of course, reading email can be a pretty dangerous business to, with all those requests from your bank, or someone else’s bank, to make sure you validate your password just one more time. Or the links to special interest web sites eager to part you from you money. Or even some distant relative desperate to give you a share of those millions you thought were lost forever.

Of course we take precautions here, too, looking left and right, not doing anything stupid. But what if we are taken over by a feeling of wanting to know just what it would be like to be shot from a cannon?

The tempting invitation for the Cannon Shoot arriving in your inbox in the first place meant that your first antispam line of defence has been breached. Of course, you could still have some client software installed, but that has also failed you this time. So you click the Cannon Shoot registration, but the site has been blocked by your content filtering safety net, phew! Someone’s been busy rating dodgy websites on your behalf. Had you been able to access the site, download that little software application, then you too could soon be hosting your own Cannon Shoot. Of course a compromised PC would still need to be able to install this little piece of malware. Even if that happened,  here again someone has been working on your behalf making sure that even in this worst case, that software you’d installed wouldn’t be able to call home for the latest invitation instructions for the Cannon Shoot.

If we didn’t have antispam, content filtering, antivirus, and intrusion protection defences, pretty soon it wouldn’t be safe to cross the road, you’d be dodging all those crash helmet clad cannon balls flying up the street.