Five portable antivirus and antimalware tools to carry with you at all times

Five Apps

1. ClamWin Portable

ClamWin Portable is very much like its big brother: It’s free, open source, and does a great job of disinfecting machines. ClamWin has a very high detection rate, has frequently updated definitions, and has an easy to use graphical interface. The only caveat to using ClamWin is that it does not offer a real-time scanner - which is not an issue for a portable version. This is my go-to portable virus scanning software.

2. Sophos Anti Rootkit Portable

Sophos Anti Rootkit Portable is one of those tools you hope you never have to use; but you know, at some point, you will. Sophos is remarkably adept at locating root kits - especially for a portable app. Sophos: scans, detects and removes rootkits, is 100% free, supports Windows XP, Vista and 7, and works alongside your existing antivirus. I have found Sophos reliable enough to use even while the PC being scanned is in use.

3. Emsisoft Free Emergency Toolkit

Emsisoft Free Emergency Toolkit is a powerful malware removal tool that can scan for, and remove, over six million dangers to your PC. Emsisoft Free Emergency Toolkit has both a GUI and a command line version, so you can scan your machine even if there are problems with the GUI. With this toolkit, you not only get the malware scanner, you also get HiJackFree and BlitzBlank as well. Emsisoft offers the free download, or you can purchase a pre-compiled USB stick.

4. Vipre Rescue

Vipre Rescue is that tool you use when your machine is severely infected. Vipre is run in safe mode and does not depend upon a GUI tool for use. You double-click the executable and a command window opens with the scanner running (and running at blazing speeds). If you already use the full version of Vipre, you can still run this tool should your machine become so infected, Vipre will not run.

5. Spybot Search and Destroy Portable

Spybot Search and Destroy Portable is the portable version of the massively popular full Spybot Search and Destroy. This antimalware tool does a great job of finding and removing malicious software - all from your flash drive. Spybot has a unique feature that will help you backup your registry before you begin the scan. Should Spybot fubar your PCs registry, you have a backup to restore to - safe and sound.

Bottom line

You know that point is coming when you’ll require the assistance of portable antivirus and/or antimalware. It’s a shame that this is such a big part of our jobs, but it is inevitable. Make sure you are always armed with the tools to combat this plague by keeping a few of these portable apps along with you.
elitebuyer.com 135 e. 9th st, long beach, ca 90813
562-366-4177
Long Beach Computer Support, Service, Sales.

Read More

Insecure SSL and How PCI gets it right

Insecure SSL and How PCI “Nearly” gets it Right

Nearly every assessment project we do we see insecure ciphers. Unfortunately, many people see SSL and cryptography as a ‘voodoo art’ that mere mortals can not tackle, or they just assume that the default install of the web server will set it up just fine.

It would seem logical if the data transmitted to and from your site is important enough to encrypt, then you might as well do it properly. Afterall, large web sites don’t use encryption just for the fun of it, the mathematics required to undertake these cryptographic functions on a large scale requires significantly more CPU power, often including accelerator cards or dedicated SSL Accelerator appliances. This, of course, dramatically increases expense and infrastructure complexity, when comparing an SSL page to its non-encrypted counterpart.

Background

As some background lets define what exactly is an “insecure SSL Cipher”. For the sake of simplicity, it is probably best broken into two categories:

1. Insecure Cryptography. This is where the keys, signatures, and hashes that secure the data are weak and can be broken within a reasonable amount of time. Back in the mid-90′s, ‘export-grade’ encryption that moved from 40bit to 56bit in strength was really thought to be ok for general consumer transactions. It was generally thought to be strong enough to keep honest people out, and dishonest people would have to go through quite a bit of number crunching to break the keys. But in 1999, the Electronic Frontier Foundation (EFF) and distributed.net rocked the world and cracked a 56bit key in just 22hrs. Recent advances in video card processors and interfaces now makes the Graphics Processing Unit (GPU) an extremely fast and accessible math processor that is rapidly reducing the time it takes to crack passwords and of course cryptography of all sorts. For example, some software claim statistics like 200 million attempts per second at cracking md5. It is now generally recognized that keys should be 128bit and above in key length. Of course this is a generalization since each cipher’s strength varies even at the same key-length, but it’s a good rule of thumb.

2. Insecure Protocols. The protocol is essentially how the cryptography is used to secure the data. The protocol uses cryptography (keys, certificates, and hashes) to create and maintain a secure connection between the user and the server. If the protocol can be subverted, it can allow an attacker to tamper with the encryption mechanisms to reduce or eliminate it altogether. SSL version 2 is a great example of an insecure protocol, with quite a list of problems that would keep a mathematician awake at night.

The fix for the above problems is of course to disable the insecure ciphers and protocols at the server level. When a secure connection is being established, the server and the client (eg. the user’s browser) negotiate the protocol and encryption that will be used. If the server does not allow the insecure mechanisms then the client can not possibly setup an ‘insecure’ connection. Everyone should disable SSLv2 and all ciphers under 128bit.

You might be wondering how many people rely on SSLv2 for their transactions. Just how many people need to use SSLv2? There doesn’t seem to be a definitive resource that lists all the browsers ever created and what versions of SSL they support. However, doing some research I stumbled upon a site from the “Massachusetts Registry of Motor Vehicles” that really is good on several levels. This site does not appear to allow SSLv2 or insecure ciphers. It also defines what browsers will work with the site and tells the users how to set their browser settings if they do have problems. This site says that it will support Internet Explorer (IE) version 4 and above. This version of IE was released in 1997. Therefore only IE versions released before 1997 would not work with their site; that would require a user not to have updated their browser in nearly 12 years!

So how does this relate to PCI?

Well up until November 2008 there was quite a bit of ‘grey’ area in the wording of SSL requirements in the PCI standards (section 4.1). As with all standards, they are often quite general and open for interpretation. You might be surprised to know that there are some companies out there that want to do as little as possible to meet the certification criteria rather then do the “right thing.” Disabling insecure ciphers and SSLv2 seems easy, and indeed it is, but some companies would rather argue ad-infinitum that they might block one legitimate user from using the site instead of making the site more secure for everyone else to use. It would be much better to guide and nudge that one user to better protect themselves – a user typically has no idea what goes on behind the scenes and wouldn’t even know they are unsafe.

To combat this argument, in November 2008 (PCI Assessor Update Nov’08p1), the PCI council came out and said quite specifically that SSLv2 would create a failure in PCI compliance if it was used to transmit confidential information. To my absolute amazement they did not go so far as to say SSLv2 must be disabled altogether. They leave an ‘out’ so that supposedly an insecure browser can initiate an SSLv2 session so the user can receive an ‘error’ and be told to upgrade their browser. This is quite ridiculous because now the PCI assessor needs to look at the application business logic to ensure this mechanism is indeed in place, and is in place properly. The biggest real problem is that applications change. One small slip up and it is quite possible that a developer inadvertently drops the browser check and SSLv2 is enabled again for the entire site. The best way to solve the problem is never have SSLv2 enabled and to redirect from a non-encrypted site to the ‘secure site’. Use the non-encrypted site to provide directions in case a user needs help with their browser, just as MA-RMV did above.

In essence the PCI council “nearly got it right”. I have been considering why the council would allow SSLv2 just to throw an error to a user and I just can’t think of a valid use case. So this one ruling not only theoretically allows implementation of insecure protocols – since it doesn’t explicitly disallow them – but they also make it much more difficult for an assessor to determine just how SSLv2 is being implemented and caught.

If every single website on the Internet turned off SSLv2 right now, the world would be a slightly better place, and this discussion would end – as every user would have no choice but to fix their browser. Sometimes users need a little motivation to change; 12 years really is a long time not to have updated a browser.

Read More