March 07, 2016

Techno Bits vol. 63: The Transmission Problem


Yesterday, news began to spread of a problem with the Transmission BitTorrent client. Specifically that their version 2.90 had been infected with malware - specifically, the ransomware KeRanger. If you have downloaded 2.90, stop what you're doing and upgrade to 2.92, or ask yourself if you should really trust them with your downloads any longer. What's KeRanger? I'll let Palo Alto Networks explain:
The KeRanger application was signed with a valid Mac app development certificate; therefore, it was able to bypass Apple’s Gatekeeper protection. If a user installs the infected apps, an embedded executable file is run on the system. KeRanger then waits for for three days before connecting with command and control (C2) servers over the Tor anonymizer network. The malware then begins encrypting certain types of document and data files on the system. After completing the encryption process, KeRanger demands that victims pay one bitcoin (about $400) to a specific address to retrieve their files. Additionally, KeRanger appears to still be under active development and it seems the malware is also attempting to encrypt Time Machine backup files to prevent victims from recovering their back-up data.

Yeah, That's pretty scary. Version 2.90 was out for a total of 32 hours (11:00am PST, March 4 to 7:00pm PST, March 5) before being pulled, so the exposure window was narrow. Macs who are using Gruntwork for updates wouldn't have pulled down the infected binary, which is a plus, and Macs currently watched by Watchman Monitoring will now alert on the presence of this version of the software. I am very fortunate to work with such hard-working people like Allen Hancock at Watchman and Brian Best at Mac-MSP during these kinds of events, because they're on the ball before anyone even asks. I still don't know when they sleep.



Toward Better Security: A Munki-in-a-Box Upgrade

Saturday afternoon, I made some alterations to a new branch of Munki-in-a-Box. The new version now sets up HTTP Basic Authorization on the Munki repository, making it impossible to download anything from the repository without first setting up additional HTTP headers on the client, or entering a password at the web page. The goal is to prevent unauthorized access to your Munki repository, usually from outside your network. 

The amount of work to secure the Munki repository this way is not terribly large, it just requires some extra details for your server. There is a better way to make sure that unauthorized clients are unable to access your repository, and that your clients can verify that your server is really your server, and that's machine certificates. You can read more about this method at the Munki Wiki. This is the real holy grail, but I suspect that it's not necessarily something I can code up as part of Munki-in-a-Box just yet. If you have ideas, I'm open to them. Pull requests are welcome.


iPad Paradise Lost

I've found myself over the last two week taking a step back from the iPad Pro, not out of inability to get something done, but out of inability to do something in a sane amount of time. We've been busy as hell the last two weeks, and there just hasn't been time to learn exactly how run the kind of setup I need. I feel like the iPad Pro is an awesome device if you have no pressure on your environment to work at the time, making it the perfect vacation and travel device. I find myself still coming back to the laptop when I have busy times. I'm not sure if that's an indictment of my workflow, or an indictment of the iPad Pro. We'll see. I travel this week, and I'm tempted not to bring my laptop.


Links to Read