Revoking Chinese CNNIC Root Certificate in Mac OS X
Earlier this month, Google and Firefox both dropped the Root Certificate of Chinese Certificate Authority CNNIC, after it was discovered that it had delegated its authority to an Egyptian intermediary to allow it to fraudulently sign SSL/TLS certificates for the google.com domain (presumably for the purposes of performing man-in-the-middle attacks and snooping on Egyptian internet traffic).
Apple, despite releasing Mac OS X 10.10.3 and iOS 8.3, has yet to remove this rogue CA. I hope that Apple joins in and revokes the CNNIC in an upcoming update, but in the meantime you can remove it from OS X yourself!
Simply run the following command in the Terminal and *poof*, another unnecessary and untrusted CA bites the dust:
sudo security delete-certificate -c "CNNIC ROOT" /System/Library/Keychains/SystemRootCertificates.keychain
It’s worth pointing out that a deleted Root CA cert may re-appear in a subsequent system update (I will check when 10.10.4 comes out). The alternative to this, which can only be achieved using Keychain Access (I believe), is to tell OS X to never trust a given Root CA certificate – a setting that shouldn’t be undone by future updates. To do this:
- Open Keychain Access
- Click on ‘System Roots’ on the left
- Right-click on the Root CA you don’t trust (ie. CNNIC ROOT) and select Get Info
- Expand the ‘Trust’ section
- Select ‘Never Trust’ from the “When using this certificate” dropdown
- Close the panel (OS X will probably ask for your password to authenticate the change)
- You should then see a red X icon next to the untrusted cert.
I personally think that our operating systems and browsers already trust far too many Root CAs, many of which are unnecessary, others are potentially malicious. OS X by default trusts around 204 Root CAs. I’m planning on cutting this down to a short list of CAs that are both (a) trusted and (b) necessary for normal day-to-day use of the Internet. I’ll report back on that when I get time.
Unfortunately, there is no mechanism in iOS to remove certificates from the Root CA store. The list of current trusted Root CAs in iOS can be found here.
Reverse SSH over Tor on the Pwnie Express
The Pwnie Express (PwnPlug) is a great little tool for hackers, pentesters and social engineers alike. While I don’t advocate the use of a Pwnie for illicit purposes, I was intrigued about using it as an untraceable tap into a network. Out of the box the Pwnie allows you to configure reverse SSH connections, exfiltrated over a number of different protocols including HTTP, SSL, ICMP and DNS.
While these are great for getting out of controlled networks, they all require the Pwnie to be configured with the IP address of your SSH server, which could potentially be traced back to you. It also requires your SSH server to be able to directly receive connections at the IP/hostname configured on the Pwnie. While one could run an SSH server on a proxy box somewhere, I felt that was too primitive, so I installed Tor on my Pwnie and configured a Tor Hidden Service on my SSH server.
Note: For the purposes of this tutorial, the SSH server will be running on BackTrack 5. I’m assuming you’ve already performed the initial Pwnie Express setup steps on the server! Check out my PwnieScripts to help speed up and automate the Pwnie setup.
These instructions do not yet work on Pwn Plug software >= 1.1 as they’ve changed the layout of things! Will update this post when I get the time.
Safari, Mac OS X and Fraudulent SSL Certificates (Comodo)
Following the recent hacking of Comodo, a certificate authority that distributes SSL certificates, web users to the following domains are at a higher risk of phishing and sniffing attacks:
- login.live.com
- mail.google.com
- www.google.com
- login.yahoo.com
- login.skype.com
- addons.mozilla.org
Attackers were able to obtain SSL certificates for these domains, essentially allowing them to pose as those websites. The certificates have since been revoked by Comodo, however this relies on browsers checking for them by checking Comodo’s Certificate Revocation List (CRL) and having the Online Certificate Status Protocol (OCSP) enabled. Firefox and Chrome were updated last week to block the fraudulent certs, but Safari doesn’t do CRL and OCSP checking by default.
Hit the jump for how to enable these checks in OSX and Safari. Read more
GPGTools Release Unified Installer for MacGPG/GPGMail
The guys at GPGTools have taken control of the MacGPG2, GPGMail, GPG Keychain Access and GPG Services projects, and have released a single unified installer that installs all of these apps. They are maintaining these tools, which are all 64-bit and Snow Leopard compatible. The package also include Enigmail, a GPG-compatible plugin for Thunderbird (Mozilla’s free email client).
GPG is an open source alternative to PGP’s suite of public key encryption software (PGP Desktop), which allows you to encrypt/decrypt files and emails and create/validate digital signatures.
For more information, check out my tutorial on using GPGMail to send encrypted emails on Mac OS X.
OpenBSD IPSec Possibly Probably Not Backdoored by FBI
In a post to the OpenBSD mailing list, developer Theo de Raadt reveals an email from an ex-contributor (Gregory Perry) alleging that money was accepted from the FBI around 2000-2001, in return for implementing a backdoor into the IPSec stack. Such a backdoor would give the FBI the ability to eavesdrop on any IPSec connection made using OpenBSD, or any other projects that have since made use of its IPSec code.
Clearly this would be a big deal if true, and although we know that open source projects are regularly backdoored by rogue developers or ‘hackers’ (such as the recent ProFTPd backdoor), it is not often that we hear of governments inserting some themselves. Should we be surprised? After all it is known that the NSA was involved with the development of DES by altering the algorithm’s S-Boxes and suggesting a shorter key length. There are also rumors of a covert backdoor in several versions of the Windows OS. That said, many people are smelling a troll in this case.
Following this information (can we call it a leak rumor?), OpenBSD’s IPSec code will undoubtedly come under quite a bit of scrutiny, and I’m sure we will hear a lot more about it should anything untoward be uncovered.
Read the full mailing list post here, archived below for posterity.
[Update] Scott Lowe denies being affiliated with the FBI, and Jason Wright denies having inserted a backdoor. This is sounding more and more like a trolling. To what end, I couldn’t speculate. It’s also worth noting that this kind of activity would probably not fall under a normal NDA, but under a government-level Top Secret classification which lasts at least 25 years…
An interesting observation about OpenBSD IPSec and Stuxnet. Read more
Creating a Secure Mac/PC Portable USB Drive
Ever since the release of the IronKey I’ve been drooling over the device (good thing it’s waterproof I guess). Due to not wanting to pay so much for a USB key, I decided to make my own. I grabbed myself a 32GB USB key, and got to work on making it as close to the IronKey as possible.
Using GPGMail to Encrypt Email
This post forms part of the series on Securing Leopard, and covers GPGMail, Mail.app plugin that allows you to digitally sign, encrypt and decrypt emails using PGP/GPG.
When Snow Leopard came around, it completely broke support for GPGMail, and there were no other solutions that enabled similar functionality. This caused a significant issue for Snow Leopard users needing GPG functionality. The original developer of GPGMail unfortunately did not have the time to update the plugin and restore support for Snow Leopard.
Since then the GPGMail project has been handed over to a new team of developers who have been working on restoring the full functionality of the plugin under 10.6. This tutorial shows you how to easily install GPGMail and start sending and receiving encrypted emails!
[Updated 21/01/2011] The team at GPGTools have now created a unified installer which consolidates MacGPG2, GPG Keychain Access, GPGMail and GPG Service. Their all-in-one installer simplifies the install process, and installs everything you need for encrypting/signing files and emails.
If you’ve used the GPGTools package, please post your experiences in the comments!
Ravan: Distributed Hash Cracking in JavaScript
The guys over at Attack & Defence Labs have released Ravan, a distributed hash cracker the runs in JavaScript. Users can submit hashes to be cracked, and their browser will then begin brute forcing them based on a user-defined charset. Other users can contribute some CPU power to assist in the cracking process of individual hashes, it’s all handled by the server. This would work particularly well if you have multiple computers, or lots of friends willing to help out in the cracking process. Note that as this is brute force and not dictionary-based, it really comes down to how many hashes per second are being tried.
Current supported hash algorithms are MD5, SHA-1, SHA-256 and SHA-512.
Compromising Disk Encryption Through Cold-boot Key Recovery
Note: This is a 2008 post I managed to recover from my archive of Securethoughts.net
A team of researchers at Princeton University have devised a way to compromise disk encryption mechanisms, and even other disk image encryption mechanisms, by recovering latent data such as encryption keys, that remain in RAM after a computer has been rebooted/turned off. They’ve tested their attacks against encryption mechanisms such as Microsoft’s BitLocker, TrueCrypt, Linux’s dm-crypt and Apple’s FileVault.
This technique is ingeniously simple, and they’ve written a tool from which they can boot a computer, and do a memory-dump of the latent memory data, which they then run through another utility which searches the memory dump for encryption keys, which can then be used to decrypt the encrypted drive/images.
With regards to Mac OS X 10.4 and 10.5, the group discovered that the system stores multiple copies of users’ login passwords in active memory, making them vulnerable to such imaging attacks. Those passwords are often used to protect the keychain, which stores many of users’ other passwords, including the FileVault password, and potentially other encrypted disk images. This is potentially something Apple should address, and they don’t really want to be storing passwords and keys in memory, if they don’t have to. Keeping as little sensitive data in active memory as possible would greatly reduce the chances of it being compromised in imaging attacks such as these.
Check out their great video below, and read more about it after the jump! Read more
Loading ...
