Monthly Archives: November 2013

Intro To SSDs – LOPSA East 2013 – Matt Simmons

Written by William Roush on November 18, 2013 at 7:27 pm

A bit of a lengthy video from Matt Simmons at LOPSA (League of Professional System Administrators) EAST 2013. Pretty much covers all you could ever want to know about the history of magnetic storage and the move to flash storage.

Been considering to make some of the LOPSA meetings up in Knoxville, have even talked with some LOPSA guys about the possibility of starting a Chattanooga division…

WizTree – A Fast Replacement For WinDirStat

Written by William Roush on November 18, 2013 at 5:36 pm

WinDirStat is a handy open-source application for scanning your hard drive and finding out what folders and files are taking up the most room. On large drives this can be time consuming and disk intensive (both things that you want to avoid on virtual environments).

An alternative that has it beat for performance is WizTree. WizTree circumvents that annoying OS and digs right into your hard drive’s master file table, providing a massive performance increase over asking Windows to get statistics on all of your files.

Performance Breakdown

WinDirStat WizTree
Total Run Time (seconds) 324 14
MB/s 992 22,966
Items/s 2,707 62,669

We’re looking at >23x increase in performance!

Usability

Colorful and powerful visualization of WinDirStat’s results

Wiztree results

WinDirStat provides much more visually useful information, with file-type breakdown by color, selecting a file type will highlight all files of that type in the treemap. I am able to immediately notice that VMware images are currently taking up >10% of my use hard drive space, with WizTree it requires a little more digging.

Security

The only other concern I’ve seen brought up was security, of course WinDirStat is open source and available here on BitBucket, so those that are extra paranoid or worried about what “freebies” come with free software, they can download and compile it themselves. WizTree is closed source donationware, and from my first look into it, it seems clean of any kind of malware with little incentive for the creator to distribute anything iffy with it.

Cryptolocker – The Dreaded Trojan Horse Malware That’ll Put Your Company At Risk

Written by William Roush on November 13, 2013 at 8:47 pm

CryptoLocker

CryptoLocker is the latest nightmare malware that people in the network security community have been dreading for awhile. It follows very basic encryption principals that make it impossible to crack and get your files back, the software is simple and has been constantly evolving making it impossible for antivirus programs to keep up.

So far companies have been put out of business due to their IT staff not being prepared for an attack like this. Do not be the next company to get added to the list of casualties.

How CrypoLocker Works

CryptoLocker so far has only been seen coming in over e-mail, usually attached in a ZIP file. System administrators have reported CryptoLocker spreading through spoofed e-mail accounts to mailing lists, meaning that whoever is helping spread this malware seems to be hand-picking easy targets that’ll likely open attachments, not just blasting e-mails indiscriminately. Additionally there have been reports of infections through Java, and infections through the Zeus botnet.

Once you’re infected, CryptoLocker calls back home for a RSA 2048-bit public encryption key, this key can only be used for encryption, it will not work for decryption of your files. It will then encrypt all files it finds both on your machine, and on any attached network drives (this includes cloud storage like Google Drive and Dropbox) that end in the following extensions (this list may be incomplete):

*.odt, *.ods, *.odp, *.odm, *.odc, *.odb, *.doc, *.docx, *.docm, *.wps, *.xls, *.xlsx, *.xlsm, *.xlsb, *.xlk, *.ppt, *.pptx, *.pptm, *.mdb, *.accdb, *.pst, *.dwg, *.dxf, *.dxg, *.wpd, *.rtf, *.wb2, *.mdf, *.dbf, *.psd, *.pdd, *.eps, *.ai, *.indd, *.cdr, .jpg, .jpe, img_*.jpg, *.dng, *.3fr, *.arw, *.srf, *.sr2, *.bay, *.crw, *.cr2, *.dcr, *.kdc, *.erf, *.mef, *.mrw, *.nef, *.nrw, *.orf, *.raf, *.raw, *.rwl, *.rw2, *.r3d, *.ptx, *.pef, *.srw, *.x3f, *.der, *.cer, *.crt, *.pem, *.pfx, *.p12, *.p7b, *.p7c, *.pdf, *.tif

Then it’ll wait for you to pay for the decryption key for 72 hours, after the 72 hours your encryption key is deleted and your ability to recover the encrypted files are gone forever. Some more recent versions allow you to upload an encrypted file which they’ll crack for more money (> $3,000) after the 72 hours expires.

How Do I get My Files Back?

The answer is one of two methods: pay the ransom, or recover from backups. So far if our current understanding of how CryptoLocker works is correct, it’ll be pretty much impossible to “crack” your files (people have been handing around a crack for MBL ransomware, this will NOT crack CryptoLocker, the encryption algorithms are completely different). CryptoLocker is a strong reminder that offline backups are extremely important. Online backups can be useless, being as CryptoLocker will gladly encrypt those if they’re attached to the system that has been infected. If you’re backing up to a removable hard drive, keep them unplugged when not actively backing up, additionally I’d recommend rotating at least two drives in and out, so if you get infected while you have the one drive plugged in while you’re actively backing up, you can always recover from the other.

Paying the ransom has appeared to work fine, however recovery of your encrypted files has been reported to be around 5GB/hr, so large file servers can take days to be recovered, in cases where a solid backup would bring a business back online in minutes. Additionally the original infected machine keeps a list of all encrypted files in the registry, you must not clean/remove this machine being as it must be used to decrypt the files on your hard drive. However even if you follow all the previous requirements and pay the ransom, some command and control servers have been taken offline, and their encryption keys have been lost.

Shouldn’t My Antivirus Prevent It?

As of definitions released on 2013-11-11, most antiviruses seem to be able to catch both the older variants and the newer variant compiled on 2013-10-21 13:23:51. This however is no guarantee that new variants of the malware will be produced that will not be stopped, it’s been running wild for over two months at this point, lots of people depended on their slow antivirus vendors to protect against malware such as this and paid the price.

Can’t We Stop It From Calling Home?

Technically yes: however your machine needs to be removed from the internet. The creator of CryptoLocker has so far thought of everything, and is jumping to new command and control servers at regular intervals. It appears that CryptoLocker derives a domain from the system clock, and will generate where the next server’s domain name will be (example: www.gevcgvgufvpiqozpnzpj.com), and the servers that these domains resolve to appear to be random, set up until they’re caught and taken down.

Prevention Methods

In order of the line of defense: the first would be your mail server (the main entry point of CryptoLocker). First you should never be accepting executable files, that includes scanning ZIP files for executables, some administrators have even gone as far as to automatically quarantining all ZIP files. Additionally removing Java will help if the above report of a Java infection from a jnlp file is to be believed. Additionally either look into a mail filtering solution or make sure your antivirus definitions are up to date on your mail server.

Of course the next layer is your end users, educating users to never open unknown attachments is always very important. This is always hit and miss depending on your company’s attitude towards IT (and how strict your company has been with enforcing use policies). This is of course the most effective long-term solution, but may be unrealistic.

Group Policy Objects to enforce to hopefully block CryptoLocker.

Group Policy Objects to enforce to hopefully block CryptoLocker.

Update

See an updated list of SRPs here.

The final layer that you’ll have control over is catching CryptoLocker before it can do it’s damage. So far the only effective method has been to disallow applications from running from the user’s AppData folder. While this is an acceptable short-term solution, I would not be surprised to see variants of CryptoLocker finding random locations to execute from and picking one, making it impossible to stop it via this method.

Of course with antivirus definitions catching up over the past couple days, we may see the malware creator take his winnings and go home, so keep those definitions up to date and buckle down and hope for no more variations that’ll slip past.

Also, for those that are really brave, there are 3rd party applications like CryptoPrevent, I haven’t heard anything good or bad about these tools, so investigate at your own risk.

Protecting Yourself In The Event Of An Infection

As you might have guessed, the above methods don’t seem that certain to prevent an infection, and it’s an unfortunate reality of this virus (at least for the time being), so the best we can do is have a strong recovery plan in place. Always stick with the basic 3-2-1 backup rule:

  • 3 copies
  • 2 different types of media
  • 1 offsite/offline

Make sure you have a solid server backup solution (VSS snapshots on Windows have shown to work well as one of these copies), confirm it’s running, run some restoration tests to make sure your backups are in good condition and you can restore promptly in the event of an emergency. If restoring your file server from your cloud backup provider is going to take two weeks now is a good time to consider another backup solution that’ll cut that recovery time in the event of CrypoLocker. Make sure that either all users are storing their files off of their machines (folder redirection, offline files, etc.) or make sure you have a solid client backup solution on-site (I recommend CrashPlan PROe).

vSphere 5 Memory Management

Written by William Roush on November 12, 2013 at 7:14 pm

A very informative video describing how the VMware hypervisor vSphere (AKA: ESXi) handles your virtual machine’s memory. The video below shows how to dig into your virtual machine’s memory usage statistics, read esxtop, and discusses how memory compression and Transparent Page Sharing (TPS) works!