How to work around the latest Man-In-The-Middle attacks

The ImperialViolet blog has an informative analysis of the just-patched encryption issue that can potentially expose unpatched iOS devices to a man-in-the-middle eavesdropping situation in some circumstances.  Seems Mac users running OS X 10.9 Mavericks should anticipate an update in the next days too…

Do this now: Update your iOS device straightaway, and your Mac when an update comes.  It couldn't be easier: in iOS, go to Settings, click General, and then Software Update.  You'll need to be on WiFi.  The whole process takes 5-7 minutes and temporarily requires a shade over 1GB of free space on your device for scratch storage.

The vulnerability was in an open-source component of iOS (and OS X, and potentially other platforms).  My point is not to make snide assertions about open source— I agree that many eyes make for a more secure product, and the solidity of Linux attests to that.  But it's no panacea, as mistakes can still be made and persist, as this demonstrates ...as does the 14-month-old WebView Android vulnerability that made the news in the past few days.  In this newest case the flaw is very easy to see even if, like me, you’re no expert in C-like languages or encryption.  But somehow it got overlooked, including by the compilers that one would have hoped would have caught such a visible issue.

From what I’ve read, seems the code involved is a fork of the OpenSSL encryption module.  I’ve not yet seen an analysis of whether it may have propagated beyond iOS/OS X.  You can bet that many eyes are looking into that right now.

As I understand it: in this vulnerability, a man-in-the-middle attacker possessing an encryption certificate signed by a trusted Certificate Authority could potentially intercept an encryption handshake between a user and a secure service or website, and under some circumstances the mechanisms that would detect such an attack would be short-circuited, allowing the MITM to eavesdrop or maybe impersonate the remote party.

A Workaround

Patch or no patch, one way around vulnerabilities of this sort is to tunnel past the attacker using a virtual private network that authenticates by some unrelated mechanism.  Typically, once a VPN client is set up on your computer, tablet or phone, you can connect to it most any time, and it establishes an encrypted tunnel and routes some or all your traffic into that tunnel so nearby eavesdroppers can’t make sense of it.

Using a VPN routinely is not a bad idea for those, like me, who frequently rely on public hotspots in hotels, planes and other venues… including in untrustworthy countries.  A bonus is that a VPN also evades firewall blocks for things like Voice-over-Internet and (in some countries) social media.  Of course, one must have their eyes open about the local rules for utilizing such services… It’s one thing if your hotel blocks VoIP to maximize its in-room-phone revenues, but VoIP is flat illegal in many Middle East countries (for example).  Fortunately, if you’re on a VPN, no one between you and your VPN service can detect what you’re doing, at least not easily.

Also, when you’re connected via a VPN, it appears to the services you connect-to that you are connecting from the geographic location of your VPN’s endpoint.  That’s great for accessing your subscriptions to things like Netflix and Hulu when you’re traveling beyond copyright enforcement borders.

Commercial VPN services are plentiful, cheap and easy to use.  It’s also easy to set up your own: Here at Jordan Manor we have three: two (PPTP and ssh-forwarding) running on Linux on a little Raspberry Pi per the instructions at http://unvexed.blogspot.com/2012/08/how-to-set-up-real-encrypted-vpn.html and http://unvexed.blogspot.com/2012/08/how-to-use-raspberry-pi-as-secure-web.html and then a third kind (L2TP) running on an elderly Mac enjoying a second life running OS X Server.

Although some firewall situations block VPNs as well, having a choice of VPNs maximizes the chance one will get through.  And running your own VPN means blocking strategies based on the IP addresses of known commercial VPN services won’t work.  Corollary: if you successfully run your own VPN in a situation where commercial VPNs are routinely blocked, don’t blab about it, and resist the temptation to run “check my IP address” utilities on the web when using your VPN, as these can serve as honeypots that database the IP addresses of likely VPN services, which can result in their being blacklisted.

(Meanwhile, blocking strategies based on the port numbers commonly used by VPN services can sometimes be evaded by routing your VPN through non-standard ports ordinarily utilized for other services less likely to be blocked, though that’s often not possible since port assignments are often baked in the pudding of most operating systems and clients.  Of the three VPN implementations I run here, only the ssh-forwarding approach is amenable to that dodge.)

The takeaway

Just be careful out there, use duplicative layers of security when you can, pay attention to updates and patches for your OS and applications and especially for things that execute code on your machine, like Java and Flash.

Something to watch

One thing worth listening-for in the coming days is the potential impact of this bug on other platforms that might utilize the same open-source code …including the Tor network, as it is OpenSSL based.

Cryptopocalypse: Can your iPhone be hacked by the NSA?

Today the Intertubes are awash with hysteric headlines like "The NSA Has Crazy Good Backdoor Access to iPhones".  It's quite the pile-on: besides the press' inclination to tear down the tall dog, there's something stunning about the well-regarded security of latter-day iDevices being easily circumvented by shadowy spies in Ft. Meade.

What's missing--as is all too typical--is a close and sober look at what's being disclosed.

Here's what we know from the latest Snowden documents:

The DROPOUTJEEP iPhone exploit requires physical access to the phone, which suggests it’s based on the sort of hard-boot privilege escalation that has animated the cat-and-mouse game of jailbreaking since 2007.  With each generation of hardware and software, old boot-time-access doors are closed by Apple and new ones discovered by jailbreak hackers.  The result has been continuous improvement of device security.

But hardware and iOS advancements now necessitate that all recent jailbreaks require the device filesystem be unencrypted by removing any passcode (and, in the case of the iPhone 5S, the fingerprint authentication).  That offers good likelihood that your recent iPhone or iPad is safe from this exploit if you enable the passcode.

But here’s something interesting that I’m not seeing discussed amid all the hoo-hah.  The source document that’s being splashed all over the Internet is dated 2007:

Specifically, the document datestamp is “20070108”.  It’s unclear if the date format is year-day-month, as is typically seen in the US outside of at least some government and military usage, or the more globally accepted year-month-day.  I’d argue the latter, because the iPhone was released on June 29, 2007.

Either way, the document relates to the very first generation of iPhone, before the filesystem encryption capability was even introduced.  (That came a year later, with iOS 2.)

So, calm down, people.  Enable your passcode.  And know that there are much more probable threats to your rights and privacy than this one.

On using VPNs, Proxies and VoIP from behind a restrictive firewall

I framed my posts on setting up one's own secure, encrypted Internet access via a Raspberry Pi with the notion of accessing one's Netflix account from outside the U.S.  That's certainly an understandable desire, and either of the solutions I've documented so far (ssh proxy and pptp VPN) will work well for that purpose, assuming your hotel Internet connection provides sufficient basic throughput.

But there is another potential usage: travel through a region in the world known for suppressing or monitoring individual Internet activities.  For example, in one country I've visited whose national firewall is well-known, all blog engines I tried were blocked (blogger.com, wordpress.com), as were all user-generated video sites (YouTube, Vimeo) and all social-media sites (Facebook, Twitter).  Similarly many political and commentary sites were blocked, especially those with what Americans would regard as conservative or libertarian viewpoints.  Most news sites were allowed through but in localized form with filtered content.

In such cases, it may be helpful to have one's Raspberry Pi running 24/7 on your home broadband connection, serving up the several work-arounds I've documented:

1. An encrypted pptp VPN suitable for any client (Mac, Windows, iOS...);
2. A ssh proxy suitable for laptops, and
3. A php anonymous web proxy I haven't gotten around to blogging about yet.

(Just be very sure you're familiar with your host's rules and laws... see below.)

Here in the U.S., I've found each of these approaches to have pluses and minuses:

(1), the pptp VPN approach, has generally been preferable for my usage since all platforms are supported, all traffic can be encrypted, your IP address cloaked, and blockage of things like VoIP services is circumvented.  This approach requires no downloaded client or jailbreaking, but it utilizes the standard pptp IP port, which some localities block (and, annoyingly, it seems alternate ports cannot be specified in the built-in VPN client in Windows, OS X, iOS or even Linux).  Note, however, that pptp VPNs utilize the ms-chap v2 encryption algorithm, which some commenters here have pointed out is potentially hackable, though with considerable effort.  Using a long, highly randomized password can help on that point.

(2), the ssh proxy, is immune to the port-blockage problem because I've documented a way to use the port ordinarily used for https web pages, which presumably will probably never be blocked.  All your traffic is encrypted, your IP address is cloaked, and blockage of things like VoIP activity is circumvented.  No downloaded client software is needed.  But, it's suitable for laptops only.

(3) is a familiar anonymous web proxy, so it's just a web page and its port will never be blocked except in severe cases of national Internet shutdowns.  It requires no downloaded client software.  But only your web traffic is encrypted/cloaked.  Things like VoIP-port blockage can't be gotten-around using this approach.

Of course, there are also commercial services like Cloak (www.getcloak.com) and TorVPN (www.torvpn.com) and any number of anonymous web proxies available, both free and paid.  However, commercial services' IP addresses or URLs are sometimes blocked by institutions and countries.  Running your own service on your home broadband connection should avoid this issue if you keep your usage moderate and your mouth shut, and if you avoid the temptation of checking your cloaked IP address using services such as http://whatismyipaddress.com which can record such inquiries and thereby database them as likely coming from curious users of VPNs or proxies.

When it comes to countries with restrictive Internet policies and national firewalls, you will still probably find the pptp port accessible through your hotel connection.  Most host countries want to encourage commerce and more concerned about suppressing individual activities than preventing businessmen from securely contacting their corporate resources.  Consequently, the classical pptp VPN may be open, although known non-corporate VPN and proxy services may be blocked on a URL or IP address basis.

VoIP

Making calls when traveling in foreign countries can cost a fortune using conventional cell-phone roaming minutes.  You may find that even despite the crappy Internet connection in your hotel, the standard VoIP port may remain unblocked.  If so, and if it's legal where you are, you can try making a test call using your smartphone's VoIP app-- my favored iPhone/Android VoIP app, 3CXPhone, has worked beautifully for me in many such circumstances.  If so, the beleaguered router in your hotel has an effective Quality-of-Service (QoS) engine that prioritizes your VoIP traffic well enough to work for you.  Or, if the VoIP port is blocked (or if you'd prefer your conversations be encrypted, which normal VoIP is not, or if you'd like your use of VoIP to be hidden altogether), running your connection over your Raspberry Pi's pptp VPN might work, but the additional latency might or might not be a problem.  The new Silent Circle app might also be of interest if security and privacy of your conversations is desired; ditto running Liberte Linux or some other anonymized operating system.  Just keep in mind the legal points noted below.

A couple of important points

1) Technical

There are many potential bottlenecks in a cloaked or proxied connection.  Your hotel Internet connection is one, and nowadays it's almost a given that it will be pretty lousy.  But your home broadband connection is potentially another (especially the upstream bit-rate, which is usually much lower than downstream).  And the current Raspberry Pi implements its Ethernet port as a USB 2.0 device, so its throughput is limited to USB 2.0 speeds (theoretically 480 Mbit/sec but, in practice, less).  Keep in mind that every bit of VPN'd or proxied traffic must flow through your Raspberry Pi twice: first via your broadband downlink from the site our service you're visiting, and then via its uplink to you.  Plus, routing your Internet traffic through your Raspberry Pi from afar obviously adds latency.  All these limitations have an additive effect.

Also keep in mind that some localities will monitor traffic bit-patterns and flag unusual usage.  For example, if you're running a ssh proxy over the https port as I've documented, your host might notice that your usage doesn't match ordinary webpage-visiting behavior.

Your home ISP might similarly detect your usage (especially if it's heavy) and declare your online employment of the Raspberry Pi to be in violation of terms of service which prohibit running servers.

2) Legal

Accessing forbidden websites and services, utilizing a VPN or other forms of encryption, using a proxy, communicating via VoIP, etc., may be illegal in some countries, and many such activities can get you in trouble on college campuses too, not to mention the dim view employers take of employees accessing blocked services via whatever tricks. (It can even be cause for immediate termination.)

Please be mindful of your host's rules and laws-- this is your responsibility and obligation, and (not being a lawyer) I can offer no advice or counsel on the matter.  As far as countries go, while it's true that many are more concerned about keeping their citizens in line rather than crimping visitors' style, that's a risky assumption to make.  Be informed, and utilize tools such as these at your own risk and with your eyes wide open.

Check and protect your Mac or Linux computer from the "Flashback" Java trojan

Prior to OS X Lion, a Java interpreter came installed with OS X.  This allowed programs written in that language to be run; most often this enabled some web-related functionality.  Unfortunately Java seems to have recently stolen Adobe Flash's crown for vulnerability.  Successive security whoopses have driven Apple to remove both Flash and Java from its as-delivered builds of OS X (and of course neither was ever allowed on iOS).

That's great for folks buying new Macs and declining to install Flash and Java when requested by a website or software package.  But many (even most?) users do have these installed.  And a big Java vulnerability was discovered a couple of months ago.  Dubbed the Flashback trojan for its original packaging as a fake update to Adobe Flash (and how ironic is that?), it started life by infecting users' machines when they agreed to the seemingly-benign update.

Although Oracle, Java's owner, delivered a patch with reasonable speed, it took Apple seven weeks--and a disturbing outbreak of machines tainted from having visited infested websites, resulting in OS X's very first botnet--to issue an update.  The episode is a black eye for them.  It's an inauspicious performance by the internationally-regarded security guru they hired early 2011 as Global Director of Security.  And it's a sorry performance by the security-products industry as well, as the trojan flew under its radar the whole time, and then security firm Kaspersky Labs' removal tool turned out to have some unfortunate side-effects and was quickly withdrawn.  What a mess!

An official Apple remedy is available now, however, and given the severity of this outbreak it's essential that you update your Mac to eliminate the possibility of infection.  Do this even if you ran the terminal commands published by F-Secure, as there are reports of folks who'd been given the all-clear but later learned there was indeed an infection on their machines.

1. First, check to see if your machine even has Java installed.  Open Safari, select Preferences from its menu, click the Security button, and see if you have an "Enable Java" check-mark available.  If not, you don't, then you don't have Java installed, and you win a beer.  If so, seriously consider un-checking it, as Java is rarely required today in this day of HTML5.  Note that despite its similar name, JavaScript is something else and is unrelated to this vulnerability.
2. Next, close your browser and run Software Update.  Your Mac will churn for a moment or five, then ask for your administrator password, and the update (and any others) will install.  If the trojan is installed, it will be removed, and your Java installation will be updated with a less-vulnerable version.  (Still... uncheck that check-mark.  Seriously.)
3. If, in Step 1, you found you did not have Java installed, out of an abundance of caution Apple has still made a Trojan-checking/removal tool available.  Go to http://support.apple.com/kb/HT5246 and download and run the tool they've made available.  You only need to do this if you do not have Java installed.

Non-Mac victims a concern

Ominously, Ars Technica reports that while the Mac was the most prominent victim of this malware, a couple percent of the victims logged by Kaspersky Labs were Linux, FreeBSD and Windows machines.  This isn't surprising, since Java's original allure was for write-once/run-everywhere universality, and in fact there's nothing platform-specific about Oracle's patch description.  

The small number of Windows infections is very probably a testament to the automatic update mechanism Oracle and Microsoft instituted for Windows.  An attaboy to them, then.  

More worrisome is the approximately one percent of victims logged from the free/open-source OSes.  It's not at all clear what to do or where to turn for checking and disinfecting those machines.  Towards the bottom of the Oracle patch-page previously referenced is a sizable risk matrix; as poster "UnSpawn" on the LinuxQuestions.org site helpfully notes:

The Oracle page also contains a list of CVE identifiers. So if you have a CVELIST=$('links -dump $URI | awk '/\| CVE-20/ {print $2}'|xargs;') then depending on your distribution you could check if those require fixing and if they are yourself. Per-CVE details are at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-yyyy-nnnn (or www.cvedetails.com/cve/CVE-yyyy-nnnn/) for Red Hat / Centos / Scientific Linux see https://access.redhat.com/security/cve/CVE-yyyy-nnnn (or 'yum --cve CVE-yyyy-nnnn'), for SuSE see support.novell.com/security/cve/CVE-yyyy-nnnn.html, for Ubuntu see people.canonical.com/~ubuntu-security/cve/CVE-yyyy-nnnn, for Debian and .*BSD see http://cvechecker.sourceforge.net and for others, well, you either know how to find your distributions SO bulletins or CVE listings yourself already or your distro maintainer(s) simply may not care.

At a minimum, update Java if you have it installed and constrain its activities as much as possible by taking a close look at your browser preferences, up to and including disallowing automatic execution of any scripts at all.  I'd imagine that antivirus utilities like Clam will now be watching for Flashback on the open-source platforms, too.

It's all a lesson to mind keep your machine updated whatever its OS, watch where you browse, and think carefully before installing software--even an update--unless you're certain of its source.

Another thing to consider is disabling system-level Flash and Java from your machine but keeping a copy of Google's Chrome browser handy.  Then you can rely on the built-in Flash and Java plug-in for that browser on those occasions when you need them.  This is what I do now-- I rely on Safari for 90% of my web work out of preference for its support of OS X Lion's gestures and its invaluable Reader Mode (with its nifty one-click send-article button, which emails articles all nicely formatted with source links and subject lines all filled-in).  Come across a site that requires Flash or Java?  Just copy the URL over to Chrome.  Best of all worlds.


UPDATE: Another Java-based trojan has been detected.  Called Backdoor.OSX.SabPub.a or SX/Sabpab-A, it is stymied by the latest Java patches (and of course by removal or disabling of Java).  One may surmise that Java vulnerabilities are all the rage among malware writers right now.  Another reason to take this seriously, then.

Warning: Watch out if you run Windows on a partitioned disk (e.g., Boot Camp)

Windows has a horrible misbehavior when it updates itself in a partitioned environment.  

This hit my son hard when, home for the holidays, his Windows 7 installation in a small Boot Camp partition on his MacBook Pro decided to run Windows Update, which is a behavior that is enabled by default and un-obvious to turn off in Win7.  From what I'm reading, the behavior is hazardous to many types of systems, not just Windows-on-Mac situations.

From Microsoft's forums: 

"Windows Installer [creates] a temporary folder on the logical volume with the most free space, during the actual installation process, but that folder is deleted after use."

...The trouble is, it will do that even if that capacious volume is not a Windows-formatted partition!

Meaning, if you're running...

• A server, 
• A Storage Area Network or file-server, 
• A multi-boot configuration

...in which more than one logical volume are visible to Windows or where your physical volume is partitioned into two or more logical volumes...

...then Windows 7's commandeering of the largest partition for scratchpad purposes can damage the file system on that partition.

Astonishing.  Totally unacceptable behavior from an operating system.

(Most virtual machine configurations including cloud instances cannot see host partitions, but SANs and file servers are routinely accessible to them, and this behavior might put them them at risk.)

This results in tales of woe such as are increasingly documented on Apple's support forums with scary headlines like "Unrepairable disk errors on Mac partitions caused by Bootcamp Windows updates?"

In my son's case, his OS X installation summarily disappeared during the Windows Update process, and the machine could no longer be booted except into Windows.  His panicked trip to the local Apple Store just before closing time resulted in a gratifying all-hands-on-deck response from the Genius Bar and an impressive deployment of all their tools, but the tools reported that the drive was irreparably hosed.  His backup drives are back at his college, and (ahem) a month out of date.  

Fortunately he has a geek for a dad, and I was eventually able to get into his damaged partition using various tricks including the marvelous Target Disk Mode which allows a Mac to act like an external disk drive for another Mac.  Ultimately I was able to copy all his files over to a USB hard disk.  But the damaged partition was really and truly ruined; the disk needed reformatting if it was going to be used at all.

As I write, the machine has a freshly formatted disk and no further Boot Camp partition.  He'll run Windows in a virtual machine when needed from now on.  Fortunately, he's running OS X Lion, so the machine could be booted into Recovery Mode after its disk was wiped; it just performed an Internet Recovery and is now downloading and installing the operating system.  Soon it will be sporting a fresh installation of OS X; the download process takes a little over an hour on our WiFi.  No CDs needed!  Pretty wonderful.  We'll then copy his files back, and he'll be back in business.

Lessons:

• Be very cautious with Windows 7 in a partitioned, multi-boot situation, and very possibly where there are big file resources available on LAN.
• If you use Win7 as one of several OSes, then prefer virtual machines over multi-boot implementations (e.g., Boot Camp)
• BACK UP!!

UPDATE:

Poster "Intell" at the invaluable MacRumors forum notes,

Windows when started up on Boot Camp does not have write abilities to a Mac/HFS+ formatted volume, when using Apple's drivers. Thus, the installer will be forced to use the Windows/NTFS volume. Furthermore, the installer will only do this to internal NTFS formatted drives with priority given to the current startup disk.

So perhaps my son's tale of woe and those of the unfortunates populating forum threads like "Unrepairable disk errors on Mac partitions caused by Bootcamp Windows updates?" relate to improperly installed, corrupted or out-of-date drivers.

So add another couple bullets to the list of lessons:

• Follow Apple's Boot Camp installation instructions to-the-letter
• Ensure your Boot Camp drivers are installed and current

Users of other multi-boot environments should take heed as well.

Also consider turning off automatic updates so installation can be approved at a convenient time and when the computer has been backed up.  To do so: Click the Start button, select Control Panel, then select Windows Update.  In the left-hand bar, select Change Settings.  Then, in the Important Updates field, consider "Download updates but let me choose whether to install them."  Selecting this option will prevent spontaneous update installations, including those annoying installations that trigger on shut-down ...especially when the machine senses you're in a hurry, or so it sometimes seems.