CocoiaCast Episode One: Secure E-Mail.

The Cocoia Blog has seen a lot of hyped terms on it — but not this one yet. Say hello to the first episode of Cocoia-Cast; about Cocoa, security on the Mac, and design with Macs in general. I hope you enjoy it.

The first episodes are about securing your communications; first securing Mail in this episode, in the second I will look at securing IM, and the third and final part will be about securing your surfing.

Link to Youtube (low res)

Download .torrent (Please do, eases the load on the server!)

Network the Cocoia way.

Networking is a fundamental part of using any computer. Today, virtually every computer is connected to the internet, and no matter how secure your operating system and setup is, inherently unsafe protocols, eavesdropping, and non-secured transactions are hard to combat without knowledge of networks. In this how-to, I show how I manage issues with security when it comes to networking - specifically, directed towards the Mac OS X platform, although some tips may be universal for systems across the board.

If you’re on the move, and you own a laptop computer, you’re always at risk. Open wireless networks have become gold-mines for people willing to apply such networking attacks. But you may find that you connect to your neighbor’s open Wi-Fi, or go to LAN parties with ‘open’ ethernet, or your own company network, where you go to work, or you are in control, and exposed to, possibly, people with malicious intent, or the intent to hurt your privacy.

To get past a lot of limitations and monitoring, people have been tunneling over protocols since the very beginning. These ‘covert channels’ are a premiere way to secure your own traffic; some people suggest using ‘anonymous’ proxies publicly available, which I consider to be a very bad idea. I’d like to know who I trust at all times. Be paranoid when it comes to networking, it’s often quite a healthy attitude. a very easy way to get the idea of these channels is to look at this diagram I made;

In this case, SSH, the Secure Shell protocol, is used to tunnel FTP (file transfer) and SMTP (e-mail transfer). You can be completely creative with tunneling services (although forwarding DNS is a won’t go — TCP services only) at your own leisure. It involves only a few painless keystrokes in the Terminal (in this case, open the Terminal application, which resides in the Applications’ folder subfolder ‘Utilities’, and type; sudo ssh -l username@server.com -L 25:server.com:25 ; in this case, port 25 (SMTP) will be tunneled over SSH, so you can point your Mail client to localhost at port 25). More complex solutions are VPN’s; they involve using protocols like PPP to make a full serial connection out of SSH.

For further, much further tunneling of services, one host, or a network of hosts is needed. You can tunnel your traffic over ICMP (the protocol commonly used for the infamous ‘ping’ command) via another server, to bypass pesky firewalls and closed access points (think T-Mobile). You can even take all limitations for granted and go over DNS, like Dan Kaminsky has shown in some astonishing presentations. However, because such solutions aren’t easily applicable on the Mac, I’ll leave them for the experienced reader to figure out themselves. You have the links you need. An easy, out of the box solution to networks that scrutinize content that gets sent by is encryption, and to ensure sites and advertising (a very big problem in this age) from tracking you, software for all platforms Tor / Vidalia and Privoxy are available. I recommend anyone to at least install them, and if you use Firefox as well, be sure to pick up the matching extension.

Simple other mental notes can always help you be secured. Try putting “https://” in front of your favorite URL’s, especially sensitive ones. Gmail loves to drop you out of your secure connection after login. Remember yourself to check these things, especially on an unsecured wireless network. You are just throwing all your email into the ether for anyone to sniff out. Be aware of what network you get onto, and if your network security settings are right (automatically joining networks and bluetooth on by default is bad! bad!).

If you want more control over your own network, my earlier how-to; “Owning your network, open-source style” might be just what you are looking for.

Apple Mail and its security.

Apple’s Mail client, aptly named Mail, is pushing closer towards more HTML email content in every major release of OS X. HTML email is a bit of a cinch, as a lot of people use cleartext clients (I set my Gmail to it) but most importantly, it’s a security issue. This wouldn’t be the Cocoia blog if we investigated what risks could go with Apple Mail’s HTML email facility.

First of all, a bit of background; Safari, Apple’s browser, uses the Webkit rendering engine. Webkit’s seen it’s share of exploits, as a any HTML rendering facility has. Apple Mail has an implementation of Webkit to render it’s HTML content. This is nicely illustrated when you go to a page in Safari. From there, you can easily make the page into an email (something I did for my mass-mailing of beta invites in HTML format).

So, what could ever go wrong? First and foremost, a major issue that isn’t yet solved in any email client: Spam.

Any spam email you read and embeds images or other web-based content with an external link, can be used to track your IP address and to see if you read your email. We all already know the links on the bottom of spam that ‘allows you to no longer recieve emails from this address’. It’s a great way to determine if someone reads the spam. The same goes for HTML email. For this reason, Gmail doesn’t load images automatically. EDIT; Mark Rowe (from the Webkit team) has commented that Mail doesn’t do this as well. Kudo’s, although I have found that all users around me have the setting in the ‘Viewing’ preferences, ‘Display images’, enabled.

XSS in Javascript can do some nasty stuff. I am a fanatic reader of the great ha.ckers security blog, and it often has great in-depth articles about the latest disclosed problems with Cross-Site-Scripting. Although there is very little on the blog about Webkit, some XSS is actually cross-platform. XSS could be brought to you with HTML or embedded content like images and Javascript. EDIT; Mark pointed out that Javascript doesn’t work in content. Avenues for HTML attacks aren’t transparent to me, and I hope Mark can give me more insight on this.

Quicktime exploits are common. Webkit is integrated with Quicktime, allowing for inline rendering of video’s and audio files. Quicktime is really a piece of software that gets patched with every minor update of OS X. Over this attack vector, one could easily try a mass-attack. Remember that the email address itself doesn’t even need to be valid; only the attached content that you will be executing. EDIT; (Mark pointed out that Quicktime doesn’t work embedded, but it does in attachments.)

Only these three major issues listed, it already shows the risks you are taking by using HTML email on your Mac, or any other OS. With Windows, it’s, of course, a lot more risky, but I really don’t deal with Windows. I suggest anyone to closely scrutinize his own needs to see if you really, really need HTML email, and if you do, only open HTML email from a trusted and verified source.

Review: Security in OS X Leopard Preview Build

I’ve got a few friends who really develop Apple software for a living (whose names I’d rather not discuss here) and run Apple’s developer builds of Leopard for software testing purposes. Every once in a while, I come by and test some of my apps, and the last few weeks, whenever I had some time to spare, I’ve been around the network to check on the security of the latest build - Client and Server edition. Stability and release date aside, Leopard’s already a very special OS. Apple’s taken a bit of a fright from the last ‘MOAB’ (The Month of Apple Bugs, for the uninformed) and has locked down several portions of the OS. The highlight of my tour was when someone said:

“Hey, Sebastiaan, don’t you, you know… -like- this stuff?” *Points at monitor*
Me: *peeks over and faints*

Here’s what I saw;

Image removed to comply to DMCA notice.

This is the Server Admin management pane for Leopard (people have pointed out this looks the same in Tiger, well, it now does what the GUI says it should do, touché), and although it sucks big-time that there is, once again, a built-in ‘don’t fuck up’ (some fields cannot be edited, including the ICMP rules), but look at that! It’s a veritable dashboard for network geeks! Count with that, that Leopard server could sit at home, between your modem, and your airport (slash access point that isn’t Apple), and serve anything (VPN, net-boot, files, calendar, weblogs, streaming, RADIUS to secure your wireless, Printing, software update deployment and even more), serve as a NAT and Firewall that is ultimately configurable. Gee, with all the news of late, I wonder more and more how possible it would be to run this on an Apple TV, or a Mac Mini. The latter must be possible, but the first would be fantastic. I have seen it running on a 0.7Ghz G4, and it was spanking fast.

Now, what runs on these Leopard machines, and is it secure?
Well, to be short: yes. Apple’s done a lot to make the Darwin 9 and up family save on a network administrator’s sleepless nights.

First of all, one of my points of critique in my last security articles was that the Firewall preferences were virtually hidden, and disabled by default. Now, following the ‘everything works out of the box - idiot proof - EXTREMELY friendly citizen in networks’, the software firewall is still defaulted to ‘Allow all connections’, but has more fine-grained controls if the user desires, including a, well, lock-down (disallow all traffic). It’s also housed in the Security preference panel.

Now, since the firewall is hardly the biggest issue in securityland, let’s look at some of the services’ version numbers;

versioning information removed to comply to DMCA notice

This looks like a new lineup of software. Especially the FreeRADIUS bundling makes me happy, as it’s becoming an easier technology than ACL’s on Access Points themselves, or even WPA2 / other ‘pass-phrase’ solutions. It’s fine-grained, gives the end-administrator more control over what is happening.

Other ‘little details’ involve the way the firewall handles things. Apple removed controls I discussed in the Advanced panel of the firewall of Tiger; “Stealth Mode” is gone, “UDP Filtering”, the rather generic button, is gone. You now have the ability to restrict services to the local network, or allow internet access. To my surprise, performing a port scan with nmap yielded all ports filtered but Bonjour. This means, as it stands now, out of the box, Leopard is actually OS-fingerprint proof.

It has been in the news lately that InputManagers no longer work in Leopard. If anyone was wondering if the loss of InputManagers would really cost Apple’s OS X it’s bleeding edge in user customization and hacking, Apple has done some Input hacking of their own - All Cocoa apps now enjoy inline grammar checking, which must be a service able to vacuum in the data you type. After seeing what service is responsible (this is a joke with Leopard’s new tools), it appears that simply hacking features into the Cocoa functionality will be a lot harder. Apple has hardcoded the spelling and grammar checker into the Cocoa framework itself, ensuring removing the InputManager support won’t break their own features. But is it really that impervious to adding a few hacks? We already know the current builds don’t allow Unsanity apps to do their work, and stuff like Mega-Zoom (a SIMBL plugin) doesn’t work anymore, so yes, it is. Is this really bad news? No. I consider it very good news that runtime code injection isn’t a possibility now. Of course, people will probably start an open, shared framework to put these kind of services in (like skinning, and changing some of the application’s fundamental workings) but Apple’s own binaries… I think we’ll be seeing a fight with that. Apple has proven to be very unforgiving to people reverse-engineering app files that belong to the Dock, or Finder. They discourage the OSX86 project, for understandable reasons. This could, quite certainly, hinder OS X86 hackers and break future exploits.

This already tells us one thing; Leopard will need less hardening out of the box. As I haven’t tested things like Bluetooth (not really available on the hardware I was assigned) I haven’t got a complete image on Leopard’s security, but it does feature some incredibly strong design decisions to harden the OS in advance. Apple isn’t stupid, they know OS X is the base to their user’s experience, and a secure base will ensure Apple stays in line as one of the most secure operating systems running on computers today.

Sneak Preview; Security in Leopard.

(…) Leopard, Apple’s new operating system slated for release later this spring, has already been dubbed the new ‘most advanced operating system in the world’. In Leopard, Apple builds further on the foundation of the open-source XNU kernel, and makes some very drastic changes in filesystem, interface, and configuration. One of these major changes is the control panel for security and the control panel for networking. The firewall, once conveniently located in the ‘Sharing’ panel in Tiger, now resides under the ‘Security’ panel. It’s options, however, have taken a beating.

From the panel in Leopard, one can choose to allow incoming connections, disallow them, or allow only specific services or applications. In the current developer release of Leopard, the firewall’s default ruleset is easy to summarize;

[pretty much anything]> ; Allow.

I have played around with the GUI for a bit, and it seems the Services panel is about as clever as Tiger’s firewall preference panel. It’s not specifically doing what you are instructing it to do. When you check a radio button that says it will disallow all incoming connections, many services, including a host of exploitable services like svrloc and CUPS still get incoming connections and are even able to establish a connection. (…)

Expect much more soon on the preliminary security checkup of Leopard, any hacker’s new favorite OS.

Scanning my audience (split).

Followup of the article; Howto: A more secure OS X before Leopard. I split this article from the followup of the earlier link, because it’s really two things apart.

It’s been a ‘diggy’ day yesterday; There was a considerable amount of traffic.

Wow, what a friendly inauguration of my blog! As you can see, I’ve transferred a neat 6 gig in one day. I was silently hoping for this, because the follow-up required at least some people of who I could verify that they had read it. First off, more pretty figures and graphs.

Mac User total: 10122
Mac Users that have been on the page for more than 5 minutes: 5238 (51,75%)

Now, what am I getting at with all these stats? Well, raw access logs, like any webserver generates, contain information that the readers’ browsers sent to me. I am not into the whole American-ISP thing (I’m Dutch, myself), but it seemed to me a big share of the readers was American, and a whoppping 0,8% used Tor, which means 81 people (I think that is a lot, actually). Anyway, it wasn’t all that important, since last time I checked, portscanning was legal. What, Sebastiaan, you scanned these people? Yep. Let me first say a few words about this.

When I want to determine if people, say, followed my leads, and put their firewall on, put on UDP filtering, or even deleted the two rules that allowed in UDP traffic from the two magical ports; CUPS and Bonjour. Unfortunately, UDP is a very difficult protocol to do portscanning with, as it’s workings differ very much from TCP - a connection-based protocol. I need to use packets that ’speak the language’ of the protocol I am trying to find. I know my target services, namely NTP (Network Time), CUPS (Printing Daemon), and Bonjour. So, it would be difficult to enumerate what hosts have enabled their firewall (there isn’t really a way to tell what is dropping the packet, or I’d have to do a traceroute with every scan, which is possible, but a bit unwieldy). It is, however, easy to enumerate people who have not enabled UDP scanning, or have specifically removed the rules that allow UDP traffic into these ports (recieving an ICMP packet with port unreachable or administratively prohibited assumed in this test, by me, that it was blocked at the source). Thus, I can test the amount of people who have taken the advice and don’t need Bonjour and CUPS.

For this particular purpose of mass-scanning (don’t do this at home), I used a tailored and proven tool, scanrand. It’s a port scanner by Dan Kaminsky and it’s blazing fast. It uses SYN packets, like Nmap can deal out with the -sS option, and these TCP semi-connections go mostly unnoticed, especially by the OS X built-in firewall. Scanrand actually is able to output results in SQL, which is very handy, as you can just query your results. Hey, I can do that with my access logs too. I haven’t feeded the SQL data into scanrand, but did manage to distill a list of the Mac users that have been reading for more than 5 minutes, with the IP addresses. After making sure it’s bandwidth was limited, I set it free.
The results? People use firewalls! Most connections fail by virtue of the host in question being behind NAT (which means a router with a LAN behind it). However, a significant number still allows me to verify. Oohh, output.

That’s scanrand having fun, to see if people are online or not. Results; out of the 5238 users, a few hours later, 59,55% (3119) is online. After a cursory analysis of the scans’ packet dump, I can determine by MAC address what computer is a Mac without a router before it, or a router of some sorts. Time to go on to the second phase, detecting services. For this, I use unicornscan, the former udpscan, which has very nice UDP scanning, and database support. unicornscan -B631 (or 5353 for Bonjour) -r200 -mU $target:631 (or 5353) -E >> ~/scanresults.tmp does the job here, with a basic script that greps ps and does a count of the amount of unicornscan processes. -r defines rate, as unicornscan is blazing, and must be limited, -mU is UDP scanning, and -E shows unreachable ports as well. I cap at about ten concurrent scans. The address goes into $target, naturally. It’s great, because this stuff simply doesn’t show a line of output, it just runs, and after a few hours, I got my results. Results.

Now for the numbers;

Eligible Readers: 3119
Readers with NAT: 2304
Readers without NAT: 815
Readers with open ports: 479
Readers with closed ports: 336
Readers already offline or Blocked: 6

What is there to say, apart from the not so shocking statistic that very few people switch off their router or Mac, is that a very cool 41.23% has followed my advice thoroughly and deleted those rules. Way to go, baby (provided these UDP scans are in any way accurate)! I am glad there are a lot of people who found this how-to useful and checked over their OS X.

digg this!

Howto: An more secure OS X before Leopard (split).

This is a folow-up on my earlier how-to “A more secure OS X before Leopard“. I have split this article from the results of the scan following the last article. I recommend following the first how-to before this one, if you haven’t read it, and see what potentially insecure defaults you can change without interfering with your daily activities. Some things touched there that I will not discuss here are;

- Filevault
- Turning on your Firewall
- Bluetooth
- Making a new, unprivileged user

Further securing OS X is something for the truly paranoid, although some of the tips in here are handy for people who do feel like a checklist of things they could do to secure their Mac further. I am one of those very paranoid people, and I like to be in control of what happens on my computer. There are, once again, basic, intermediate, and advanced tips and little tricks in here, this time clearly divided in difficulty.

- Disable your Microphone input and / or iSight if you aren’t using them This hint, from the NSA Hardening guide, is a very good way to protect against any way for an intruder to physically eavesdrop on you, and any Quicktime component can access your iSight. There might be vulnerabilities looming on the horizon. The most desirable first is the iSight, as it has a real privacy concern if it were to be compromised. It’s as simple as a copy and paste into your Terminal. It won’t be painful, just open it for now.

/usr/bin/sudo /bin/chmod a-rwx /System/Library/QuickTime/QuickTimeUSBVDCDigitizer.component/Contents/MacOS/QuickTimeUSBVDCDigitizer

I will be explaining why I use full paths to commands later on. This simple line will make sure no user level process can access the module that interacts with the iSight. To restore;

/usr/bin/sudo /bin/chmod a+r /System/Library/QuickTime/QuickTimeUSBVDCDigitizer.component/Contents/MacOS/QuickTimeUSBVDCDigitizer
(I had this all mixed up. Thanks Greg)

Many thanks to techslaves. To disable your Microphone as well, you can set it’s input volume to zero in the Sound preference pane, under the “Input” tab.

- Enable Secure Keyboard Entry in the Terminal It’s that simple. It’s in the “File” menu in the menu bar.

- Disable IPv6 if you aren’t using it. Why? Potential vector for attack. To fix this, go to the Network configuration pane. Select the connection you want to use for internet access, and click here;

And now make sure it is set as below;

- Disable automatic Movie playback. What if there were to be an iSight vulnerability by delivery in a Quicktime file? We wouldn’t want it to just play without us asking. Go to the Quicktime preference pane, browser tab;

- Set your software updater to check more frequently. Of course, we like to be ready for fixes. This goes without any picture, because this is too trivial. Just go to the preference pane of Software Update.

- Ensure that access for assistive devices is disabled. In the preference pane for Universal Access. You can also make your cursor insanely big here, which is nice.

- Use a firewall accessory application like Glowworm FW Lite, or Little Snitch . Speaks for itself. Lets you decide if you want applications to connect to something.

- Set an Open Firmware Password. OF Passwords can be subverted in some ways (the password is nulled when RAM configuration is changed), but it is a hindrance. This works differently for PowerPC Macs and Intel Macs, because the latter use EFI and the other Open Firmware. For PowerPC, use the tool in Utilities to change your password. You can also boot with Command-Option-O-F pressed, to enter the OF prompt. From there, enter your newly set password, and type;
setenv security-mode full

To set full security mode, the most secure mode.
For Intel Macs. Apple has not yet provided security extensions to the EFI. You can use the Open Firmware Password Utility to set an EFI password, but that’s about it. Perhaps in the future, we will see rEFIt become TPM-aware (see advanced section).

- Use a more reliable DNS service. It may even speed up your internet. OpenDNS is dubbed by some to be more reliable and secure than an arbitrary DNS server of your ISP. No real argument against that. To set OpenDNS’s DNS servers as yours, go to the Network preference pane, and select the interface you use for internet access.

Simply set this field, present under the TCP/IP tab in your interface of choice, to these addresses, or go to OpenDNS yourself to verify (hey, I could offer you IP’s of MY DNS server, so don’t thread lightly).

- Set a login-window warning banner. (Courtesy of the Corsaire Report) Simply type;
/usr/bin/sudo /usr/bin/open /Library/Preferences/com.apple.loginwindow.plist
in the terminal. This opens the preference file of your loginwindow application.

Make sure where the suggestion for the password is, like my bogus text here, completely empty. Mine says “Grensschutzgruppe en Bas Haring”. Password hints may be a risk to the security of your system. Now, back on topic. Simply click the New Sibling button, and add the sibling LoginwindowText. Add some intimidating text, like;
This is a private computer system and is for authorised use only.
Any or all use of this system and all files on this system may be intercepted and monitored.
Unauthorised or improper use of this system may result in disciplinary and/or legal action. By
continuing to use this system you indicate your awareness of and consent to these terms and conditions
of use.

- Lock your keychain. By default, the keychain that stores your passwords, is always unlocked. No one can read your passwords, but programs are able to access your passwords, if they created the password. Use the Keychain Access application to set another password than your login password for the keychain. It will then prompt you for your keychain password every time an item is needed, and it will be open for a configurable period, which defaults to 5 minutes.

- Use Encrypted Disk Images. To secure file, or nest encrypted files even deeper in filevault, you can use the Disk Utility to create secure disk images.

- Set a more critical umask. (command courtesy of Corsaire write-up) The default umask allows all users to read each other’s new files. This command disables this;
/usr/bin/sudo /usr/bin/defaults write /Library/Preferences/.GlobalPreferences NSUmask 23

- Enable Process Auditing. (command courtesy of Corsaire write-up) This will log commands executed by all users. One line;
/usr/bin/sudo /bin/mkdir /var/account && /usr/bin/sudo /usr/bin/touch /var/account/acct && /usr/bin/sudo /usr/sbin/accton /var/account/acct
It will now run from startup.

- Force SSH to use SSH2. You can edit the ssh configuration like this;
/usr/bin/sudo /usr/bin/nano /etc/sshd_config
Now replace the line that reads “#Protocol 2, 1″ with “Protocol 2″. Lose the comment mark, otherwise it won’t work.

- Use full paths to command names. This security measure, coined mostly by Rixstep (the author of the brilliant ACP), ensures Bash or defaults path poisoning is no longer an attack avenue. Although the bash developers didn’t consider it to be a real issue, Rixstep’s CLIX (an essential accessory to any power user, and it is free) has path resolving and builtin measures against path poisoning.

- Keep an eye on startup scripts in launchd. Lingon can be used to monitor what starts up automatically. It’s an excellent GUI utility.

- Keep an eye on running services. I use the simple iServeBox for this. A simple GUI to enable or disable services, handy if you know what you are doing.

- Compile and run Bastille-OSX on a regular basis.Bastille for OS X is a hardening assessment tool. It goes recommended for anyone that knows what he or she is doing. Perl-Tk on OS X might be a useful resource in this effort.
- Compile and implement SEDarwin. PPC-only for now, SEDarwin is an adaptation of the open Darwin kernel at the heart of OS X to support the Mandatory Access Control framework. It is, of course, based off SELinux.
- Use the Trusted Platform Module in your Mac. This is, only if it has one. The first generation of Macbook Pro’s have a TPM, for example. Do an ioreg;

/usr/sbin/ioreg | /usr/bin/grep -i tpm

The output should look like this, and not any differently;

| +-o TPM