Creating an Encrypted Bootable OSX Lion USB Recovery Disk

With Apple's latest operating system release 10.7 - Lion they have included a number of new features which make it a bit more convenient to both backup and secure your data in case of a failure.  In this short post I'll explain how to use a generic external drive to make a secure bootable disk for your mac.

First a disclaimer and some assumptions regarding your setup.  I have used these instructions to get a working disk on my setup - but this does not mean that the same steps will work for you, so use caution - and if anything goes wrong please feel free to add to these steps.

I am also assuming that you are using the latest operating system patches for OSX and I'm at version 10.7.2.

Step 1 - Connect and prepare your external USB drive.

Connect your USB disk and open disk utility.

Change the formatting scheme of the disk to include two partitions, a 1GB partition, and a partition using the remaining disk space.  I named one as RECOVERY and one as TIMEMACHINE.  Ensure that under "Options" the format is GUID Partition

Select the format for both of the partitions as Mac OS Extended (HFS) and click apply. Note - this will erase all of the data from the selected drive so make sure you have the right drive selected.

Step 2 - Download and Install the OSX recovery disk assistant from Apple - http://support.apple.com/kb/dl1433

The wizard will ask you which disk you'd like to use to install onto.  Select the RECOVERY Volume.  Be aware that this will erase all data on the selected disk (well except for the TIMEMACHINE partition that we created earlier :)).

There is now a hidden recovery partition with a type of "Apple_Boot" on the USB drive that you used.  To see it, in a terminal window type:

diskutil list

Step 3 - Open Time Machine preferences and click select disk.  Select the TIMEMACHINE volume.  Also check off the encryption checkbox to ensure that your files are protected.  You will be prompted for a passphrase to use for this.  Note - this is a different passphrase than is used for the user on the computer and for the wholedisk encryption you have on the hard drive.

Step 4 - Wait until the first backup is complete.  Once the files are transfered for the first time the backups will be encrypted as well.  This also will take some time.  During these operations you can eject the disk and have it resume once the disk is reconnected.  When you reconnect the encrypted disk, you will be prompted for you password.

Step 5 - Once the backup and encryption operations are complete, you should test your backup solution by rebooting the computer and holding down the Option key, then select the USB disk.  The recovery wizard will walk you through the processes of restoring your computer from the recovery Volume on the USB drive.

I will update this post, when I get a chance to test out the recovery process.

Step 6 - Always remember the rule of 3 when making copies of your important data.  1 live copy, 1 backup copy, and 1 copy stored somewhere other than your other two.  In this case you could get by with just periodically (weekly / monthly) backing up to the USB drive and then storing this drive in a different location.

Announcing new team member - Benoit Desforges

I'm very pleased to announce that we've added another significant resource to our team.  Our new advisor Benoît Desforges brings international experience and a fresh perspective on information risk management.

Prior to joining, Benoît worked for KPMG's advisory group, he holds several professional designations including CISSP, CISA, GCIH, and GAWN.  When he's not teaching advanced networking courses for a local university, Benoît enjoys travel and time with his family.

Benoît will be providing our clients with security advice and building out a number of new and improved professional service offerings.  He'll also be regular contributor to our blog.  Congratulations Benoît!

New Trust Solutions

With the all of the activity circling around SSL certs and CA trust, there is an inherent trust problem.  Internet users have been taught to trust the PKI scheme that we use for all secure browsing activity.  There are two very valid cases for the destruction of this trust:

1.  Law-enforcement / Government interception.  There are product vendors whose business model is to supply equipment to law enforcement and government clients which can "law-fully" intercept communications without the knowledge of the end-user.  Example is www.packetforensics.com.  Although I do not have a link (can anyone supply a corroborating link?), there are several product pages that are not publicly accessible which would likely confirm this fact.  In order for these products to work, the SSL certs that are used would have to be trusted by the browser software to avoid being detected as un-trusted.  I am theorizing that these certs would be generated by one of the trusted roots within the existing trust-model.

2.  Compromised CAs.  Both Comodo and Diginotar both purport to have been compromised resulting in the generation of certificates that can be used to emulate the trust with popular web properties.  To the end user there is no easy way to differentiate between valid and invalid certs.

The impact here is that a user may think that all information is secured between them and the server, but in reality this traffic may be routed through a very-untrusted 3rd party and intercepted.  We currently have no effective tool to provide information to users that any activity like this has occurred.  So for the mean time we should be very vigilant about who we are communicating with, and the certificates that are used to trust their identities.

I also encourage and hope that we see some innovative solutions created that will allow users to be aware of changes to traffic patterns - indicating potential MITM, and new methods of generating trust in web-services like convergence http://convergence.io/.

Blindly Trusted Roots

With both Comodo and Diginotar both having their security breached, it highlights some of the important trust issues we have on the Internet.  The process of trusting these root CA's is extremely important as they serve as the foundation of protecting our information as it is transmitted across public and untrusted networks.

Both of the breaches resulted in fraudulent certifications being issued and used to impersonate high-traffic sites such as google, yahoo, skype and live dot com properties.  These certificates were used to trick browsers (and users) into thinking that they were connected to a valid site, when they were not.

More importantly though is the realization that the trust in the root CA system on the Internet has been eroded.  With two publicly disclosed breaches, how many undisclosed breaches have their been, and how many breaches of these CA's have not even been discovered?

While the use of fraudulent certificates on high-volume consumer sites is a big issue, the bigger issue here is the use of low-volume high-value certs to intercept financial transactions, email message systems, and other highly critical services.

My position is that we need to come up with a new paradigm for establishing trust in public/private services, and eliminate the use of old broken systems like the root CA pki's.  The only issue I see is the speed with which this can happen.

Application Security - Don't Wait for the Breach

The ongoing Sony saga, the Conservative Party, and now CodeMasters.  High-profile breaches of data are becoming everyday occurrences.   Reports like Verizon's DBIR indicate that more than 90% of these incidents would have been avoidable using basic security controls.  TripleCheck offers straight-forward assessment services to ensure that you're organization is prepared to meet these challenges.  Call or email us today to gain assurance over the security of your environment.

May Security Catch-up

Its been much too long since my last post - Sony's PSN network has been breached a few times, a record number of vulnerabilities have been published, and the US government has released a new set of cyber space strategies.

On the cool tools and technologies there have been lots of notable releases:

• Some research from Albert Cotesi New Zealand on the traffic flowing from IOS to 3rd parties, now sniffable thanks to MITMProxy, and instructions on getting it working with IOS
• As always SQLmap is making life easier for the vulnerability assessor and pen-tester.
• Microsoft has released an updated to the Enhanced Mitigation Experience Toolkit - I'll be looking into this over the next few weeks, and how it can be applied practically.
• New major version of Backtrack also released, for those of you that are still relying upon live-cd's as a source for tools.

RSA SecurID Information Breached

In a disclosure made by RSA today, they indicated that they have been breached by an "extremely sophisticated cyber attack" which has partially compromised the SecurID information which millions of clients use to provide strong authentication to services.

It is not yet clear what information was breached or what the impact will be to RSA customers, but for now I would suggest that people stay tuned to ensure that they take appropriate action based on what RSA and others release.

Update 1 - Found the recommendations made by RSA to customers regarding how to better protect their environments. I have added my comments on what these recommendations could mean to RSA.


• We recommend customers increase their focus on security for social media applications and the use of those applications and websites by anyone with access to their critical networks.

This could mean that part of the RSA breach was associated with a social media application attack vector - maybe employees reusing passwords across internal and cloud-based sites?

• We recommend customers enforce strong password and pin policies.

Could mean that the data that was compromised is related to the seed and token records kept by RSA, and with less reliance on this part of the SecurID solution, that customers must make the corresponding passwords and pins used in combination with the token more robust.

• We recommend customers follow the rule of least privilege when assigning roles and responsibilities to security administrators.

Could mean that the attack vector was related to additional privileges assigned to RSA security administration staff.

• We recommend customers re-educate employees on the importance of avoiding suspicious emails, and remind them not to provide user names or other credentials to anyone without verifying that person’s identity and authority. Employees should not comply with email or phone-based requests for credentials and should report any such attempts.

Could mean that social engineering was part of the attack vector, sounds very similar to the HBGary breach here.

• We recommend customers pay special attention to security around their active directories, making full use of their SIEM products and also implementing two-factor authentication to control access to active directories.

• We recommend customers watch closely for changes in user privilege levels and access rights using security monitoring technologies such as SIEM, and consider adding more levels of manual approval for those changes.

Could mean that users privileges were escalated as part of the attack, and that regular users were given privileges without any alerting of this fact.

• We recommend customers harden, closely monitor, and limit remote and physical access to infrastructure that is hosting critical security software.

Critical security software could mean the RSA intellectual information or customer information. Could also refer to the infrastructure.

• We recommend customers examine their help desk practices for information leakage that could help an attacker perform a social engineering attack.

Could mean that RSA staff were pre-texted, difficult to train out-sourced helpdesks.

• We recommend customers update their security products and the operating systems hosting them with the latest patches.

Could mean that the attack vector took advantage of previously known vulnerabilities with patches available but just not applied.


Hopefully we continue to hear more about the attack.