The first rule allows any on-campus user to make 20 simultaneous connections. The second rule prevents external clients from making more than 5 at a time. They can make as many connections as they want in series, but if a web crawler attempts to open 6 connections without closing any, the 6th will time out. Slick!

I have to send my MacBook Pro to Apple for service again, so it's time to review my list of Sensitive Data: Things to Delete and other preparation for giving up physical control of a Mac. Unfortunately last month my MacBook Pro completely died, and I didn't have a chance to do any of this. The Genius asked for my password, and I just laughed at her. She explained they'd probably replace the hard drive with a new install if they couldn't get in, and I said I'd deal with that, but suggested they just use the installer to reset the password to something they liked. As it turned out, they apparently decided not to bother -- I got the MBP back with some security settings changed, so perhaps Apple techs have a different tool that grants them access.

Before Shipment

Make a backup. I use SuperDuper for these, in addition to automatic CrashPlan & Time Capsule backups.

Create an apple user, and make it an administrator. Give it a simple password (don't forget to write it on a note for the tech -- you don't want to wait a couple extra days while they ask for the password!).

Flash sucks even worse than I thought. The Never Ask Again checkbox is not honored in Flash 9.0 r124 (under 10.5.5/Safari 3.1.2), which breaks Flash videos (pretty much Flash's only real reason for being, aside from advertising spyware). I reported this to Adobe, but don't expect much.

Note that I end up with dozens of stacked dialogs, and they pop back up about one per second, so hulu clearly won't work until Adobe fixes this bug, or I give up and turn on Flash cookies (which I have no intention of doing).

******BUG******

Concise problem statement: Flash does not honor setting to not store cookies or local data.

Results: Many many annoying Flash dialogs asking for permission to store data (1 on NYTimes; many on the videos, which interrupt playback).

Expected results: When I check Never Ask Again, I should get NO dialogs asking to store Flash cookies, and no Flash cookies should be stored.

In addition, I unchecked "Store common Flash components to reduce download times." But when I relaunched Safari, it was unchecked. I relaunched a second time, and this setting stayed checked. Never Ask Again was still correctly checked, but I still kept getting obnoxious cookie prompts from hulu.

Update:Leonard Rosenthol informed me that Flash 10 is out. It's a bit hard to find, but does appear to solve the problem. I upgraded, relaunched Safari, reset the option, relaunched Safari, and no longer get those stupid prompts. Hooray! It's odd that Adobe hides it so effectively (it's not even on Adobe's main update page), and the built-in Flash updater doesn't offer it; unfortunately Apple hasn't delivered it to Mac OS X users yet.

Update 2 -- 2008/12/25: Disabling local data (cookies and local caching) prevents Flash videos at Flickr and other sites from playing (I just get a black rectangle of the right size -- no change or controls). YouTube/Google video is not affected, though. I'm not re-enabling Flash cookies, though.

Update 2004/11/08 (Obama Day): It's worse thane I thought. Not only are these features and controls hidden and almost impossible to find, but the controls don't actually work.

Flash Cookies: The Silent Privacy Killer disturbed me. Then I visited the Flash Player Manager page, saw all the sites that were tracking me via Flash cookies, and felt really freaked. I disabled Flash cookies, and encourage you to do so as well. I'm not yet sure how well it worked, as I just checked and saw an unwelcome Yahoo cookie, apparently added after I attempted to disable them.

While people are aware of HTTP cookies, I had never heard of Flash cookies before. HTTP cookies are legitimately required by various sites, but I don't believe Flash cookies serve any user purpose, and they don't seem to be required for any reason I care about, so I don't expect problems from clearing and disabling them.

DreamHost wrote back, and the news isn't good. Someone sent them a list which is apparently circulating, of username/password pairs for "FTP" accounts; one was mine. I had hoped that if a password leaked it was my old password, which I replaced back in June (on my birthday) when DreamHost told me they got hacked. No joy, though -- the password they received was active on Extra Pepperoni (and chrispepper.com) until they sent me mail yesterday; I don't use it elsewhere and changed it last night, but that means someone had access to EP very recently. It looks like nobody ever used the account, but methinks it's time to install MySQL and WordPress on www.reppep.com, and probably Mailman too.

I got a message from DreamHost tonight which both confused and disturbed me.

Telling me there's evidence that I have been intruded upon is scary -- but what was the evidence?? Without more information, this is upsetting but not helpful.

I only access this account from fully patched Macs under my direct control. None of them were running Windows spyware, and I know there hasn't been a hardware keylogger in operation on my equipment recently (I don't believe every, but I've been doing lots of work on my equipment lately, so I know not recently). It's certainly possible I got hacked by some brand-new Mac OS X exploit, but (especially given my understanding of DreamHost's security model, which entails emailing plaintext passwords at the drop of a hat) I consider it considerably more likely this is a false alarm or miscommunication.

Especially given that, despite "we have reset your password", the affected account's password was NOT changed. I logged in normally and changed it myself. This makes me very glad that I created a brand-new password only for DreamHost last time they got hacked. On the other hand, I could have been sniffed logging in over the Internet (most of their access is unprotected); I only set up SSL for administration of Extra Pepperoni a month ago...

We'll see how they respond to my request for clarification.

In the meantime, I am worried and aggravated.

It's also somewhat suspicious that the timezone is UTC, considering that DreamHost is in Los Angeles. If it wasn't the right panel.dreamhost.com hostname, I'd think this was an attempt to get me to submit my DH account information to a spammer, but that information isn't worth much.

To: "Chris Pepper" <---->
From: DreamHost Support <support@---->
Subject: [reppep ----] Account Concerns...
Date: Fri, 7 Mar 2008 02:20:34 +0000 (UTC)
Dear DreamHost customer,
We have found evidence indicating that your 'reppep' web server account
may have been subject to intrusion by a malicious 3rd party. As a
precautionary measure, we have reset your password and ask that you
change it, here:
https://panel.dreamhost.com/index.cgi?tab=users&subtab=users&
current_step=Index&next_step=Edit&usid=1532237
At this time we have found no evidence to suggest that there has been a
breach of our internal security. We believe that the passwords in
question were likely obtained through the use of
spyware/keyloggers/malware, possibly installed on your personal
computer.
In order to secure your account, we ask that you immediately follow the
recommendations provided in the DreamHost AbuseCenter - particularly
those involving the removal of malware. You may visit the AbuseCenter,
here:
http://abuse.dreamhost.com/cracking/#exploits
If you have any questions or concerns, please let us know.
- DreamHost Abuse/Security Team

I've been thinking about using SSL to protect logins to this blog for a while, but thought it would be too complicated. This weekend, I took the time, and thanks to Haris' Admin-SSL plug-in, it was very easy. First I used cert.command to create a certificate for www.extrapepperoni.com, then I configured my DreamHost account to provide SSL (https://secure.reppep.com/ep/) in addition to the existing http scheme; this took a while to go through. Then I installed Admin-SSL, and after a few loading errors, all authentication and authenticated access is now SSL only, while reading anonymously is non-SSL.

Note that I'm using a certificate signed by my private certificate authority, ca.reppep.com, so you'll get a warning from your browser that it's not trusted; this is normal. You can continue past the warning and get full 128-bit SSL encryption; you just don't have the assurance of a public CA that I am who I say I am.

After getting burned too many times, I dropped my .Mac subscription. I never trusted my Apple keychains to iDisk anyway, but this means I have different subsets of passwords on different machines, and no good way to keep them in sync. I thought of a solution for manual sync last week: One keychain per Mac. Say I have 3 systems: work, home, and other. Each system has 3 Apple keychains: work.keychain, home.keychain, and other.keychain, with each host using its own as the default. Then I can rsyncwork.keychain to home.keychain & other.keychain, etc. This is awkward with rsync because it's inherently unidirectional, but keychains are small so it's quite feasible to script.

In Tiger, I know the keychain is actually stored in memory once it's unlocked, so it's good to lock (unload) all keychains with "security lock-keychain -a" before updating the files -- this goes in the same script. I also set mine to lock after 2 hours of inactivity, or (on those systems where I run SSHKeychain) when sleeping or activating the (locking) screen saver.

Over at Securosis, Rich and I posted a piece on using ipfw to increase your security. Leopard's new 'firewall' isn't a network firewall at all. It restricts applications' ability to listen on ports, rather than working at the level of the network stack, which means it cannot do things like allow ssh from home but not from the rest of the Internet. If you want classic packet filtering, it makes sense to use ipfw as well. We cooked up a starter ruleset for people to customize, with instructions on installing it using WaterRoof.

The new "firewall" in Leopard is called socketfilterfw, but as far as I can tell it doesn't actually do any packet filtering, which is how ipfw and classic packet filtering firewalls work. Instead, it restricts the ability of programs to "bind" a port so they can receive all traffic for that port. This discrimination is not novel -- UNIX systems (including Mac OS X) will not allow any program to bind ports 0-1023 unless they're running as root (UID 0). Normal users get an error when they attempt to take over low ports like this.

In recent years, many operating systems have made adjustments to this restriction, in an attempt to make permissions more granular. Apple, however, has added an entirely different (and much more sophisticated) test to the process of binding a port: does socketfilterfw trust it? socketfilterfw can even cryptographically 'seal' a binary (program), to make sure that if it is changed in the future, it automatically loses its authorization to listen on the network. Unfortunately, Apple seems to have gotten a bit carried away, and signed some tools that are as likely to be used by crackers who have just broken into a system as legitimate Mac users (netcat, I'm looking at you)

If socketfilterfw allows the request, the port is bound and the program receives traffic that reaches the port; if socketfilterfw denies the request, the port is not bound to the requesting program, and it doesn't get any traffic. Ironically, this is very much more like a Windows firewall (e.g., ZoneAlarm), of restricting and allowing individual applications, rather than working at a network level that has little or nothing to do with individual programs.

Anyway, here's the help message for socketfilterfw. Note the reference to firewallapp, which does not exist on my system. Presumably it is an unreleased CLI tool to manage the firewall, like the ipfw command manges the kernel firewall, or iptables on Linux. Note that the FreeBSD-derived ipfw is still available in Mac OS X Leopard (user), but not activated or used by the system -- it just passes all traffic through unless manually configured. On the other hand, Mac OS X Leopard Server's Server Admin (used in Advanced mode, but unavailable in favor of Server Preferences in Standard mode) still uses ipfw. Over at Securosis, I'm working on an example ipfw ruleset to get people dissatisfied with socketfilterfw started, but before we post any rules, we need to decide upon a suitable (easy) way for people to use them without delving into writing custom rc boot scripts.

Note that sudo /usr/libexec/ApplicationFirewall/socketfilterfw -d dumps out a list of allowed programs; there's some other junk in the output that looks like the signatures checked against the binaries, and a bunch of references to "ALF", which could stand for "Application Level Firewall".

Setting up new Leopard (user) and Leopard Server systems, I was shocked to discover that, in System Preferences:Accounts:Guest, "Allow guests to connect to shared folders" is enabled by default. This is lousy security. Fortunately file sharing is off by default, but I turned file sharing on a day or two before I noticed guest access was enabled. I don't want guest access enabled, and it shouldn't be on without a conscious decision.

For web sites, I generally use a browser to review the certificate, but for other protocols openssl is invaluable. Apple's /System/Library/CoreServices/Certificate\ Assistant.app/ (available from Keychain Access' Keychain menu) is also good for verifying SSL status of arbitrary SSL servers.

For traffic analysis, ssldump can (with the server's private key) decrypt tcpdump captures or live traffic.

I was walking down the street this morning, burning a piece of paper with some old passwords on it, and holding the box of matches I had used to light it. A woman saw me, and said "Hi. Gimme a match?" I got out a match and prepared to light it for her. Before I could strike flame, the woman leaned over to my burning password paper and lit a cigarette from it, then said "Thank you."

There I was, standing on the street, thinking "Smoking's bad, mm-kay," and wondering why she asked for a match when she wanted a light (yes, I know, I cannot turn off being an editor), and thinking this was probably actually not the first time someone's lit a cigarette from a burning password, but it's still unusual.

Undercover is spyware. It records your IP, takes screenshots, and (if an iSight is available) takes photos (presumably the green activity LED on built-in iSights flashes in use -- I don't think they can defeat it in software); sending all this across the Internet to Orbicule. It reminds me a lot of location tracking tools for cellphones, initially developed to track commercial fleets, but also useful to keep tabs on children, spy on spouses, and track government targets.

All that said, it's undoubtedly cool technology and a useful service, but I'm too uncomfortable to use it -- Orbicule's How it works page says "Undercover can not be disabled by the thief.", which raises my suspicions further.

Orbicule promises that Undercover doesn't emit any information unless the Mac is logged as stolen. This assumes you trust Orbicule's assurance, you and Orbicule trust Orbicule's programmers, and that your Mac doesn't get accidentally added to their list of stolen computers.

I hope no plain criminals get the source (or just the inspiration) and use it to spy on Mac users more effectively...

I got a very interesting (and unexpected) email today. Apparently Apple is in the process of certifying Mac OS X to Federal Information Processing Standard 140, which is used to validate encryption and security technologies -- it's commonly associated with SSL/TLS hardware and software; I know OpenSSL was being validated against FIPS too, but haven't kept track of that progress. I had no idea Apple was working on this, but if and when it's completed, it should be a useful credential for Apple in security-sensitive environments. Note that I make no claims as to the meaning of FIPS certification, but it will be used as a simple checkbox for trustworthiness, so can't hurt Apple to have this particular tick-mark.

Everyone has been eager to know the status of FIPS 140-2 Conformance Validation for Apple's Mac OS X and we are happy to finally announce that as of Friday September 7, 2007 the Apple Cryptographic Service Provider (CSP) Module is officially now in "Pre-Validation".

Listed on NIST (CMVP) Pre-Validation List

You will now find the Apple "Cryptographic Service Provider (CSP)" on line 5 of page 2 on the Pre-Validation List (PDF) posted on the NIST CMVP website. To view that list now or reference it in the future, use the following link to download the PDF document:

A Cryptography Architecture is built into Mac OS X and is the foundation for services critical to the protection and privacy of data. The key Apple Cryptographic Services which will be covered by this validation are:

Many have asked when Mac OS X's cryptographic algorithms and cryptography conformance validation against FIPS 140-2 Level 1 will be complete. Apple is unable to provide you with a more specific timeframe than the first half of 2008 due to the extensiveness of the process. Apple will make every effort to post status updates on the Federal website [ http://www.apple.com/itpro/federal/] as well as occasional updates posted to the Fed-Talk Mailing list [ http://lists.apple.com/mailman/listinfo/fed-talk ].

Meeting OMB Recommendations (M-06-16)

To assist Federal Agency IT Staff in understanding how Apple's Mac OS X Operating System can help them meet OMB guidelines, the Apple Enterprise Team had developed and presented the "Meeting OMB Encryption Guidelines with Mac OS X Today" briefing to a large Federal IT Staff on August 17, 2006. Many additional Federal Staff had indicated that they were unable to attend the all day briefing and technical discussion due to scheduling conflicts, but said they were extremely interested in getting access to the presentation.

FileVault provides full 128-bit AES encryption of the User's Home Directory where the user has full, direct access to read and write their data. The underlying Encrypted Disk Image architecture also provides services to create, manage and store the encrypted containers on any accessible storage media. This storage includes external volumes such as thumb drives, CDs/DVDs, USB/FireWire HDs and even network accessible volumes.

Background on Apple's Cryptographic Architecture

The Cryptography and PKI Services within Mac OS X and Mac OS X Server are provided through the CDSA - Common Data Security Architecture . The CDSA architecture is the core part of Apple's Security framework which is available from The Open Group and available as open source for review, use and modification.

Eric Warnke has discovered that, if asked nicely, SSHKeychain will print out the passphrase used to encrypt a loaded private key. This is bad, as the whole point of an ssh agent/keychain is to provide secure access to encrypted keys, meaning you cannot get the passphrases or plaintext keys out.

The exercise is more involved for the fully paranoid, or generally when preparing to enter a truly hostile network. I assume that someone at Black Hat/Defcon has an unannounced exploit that I'd be vulnerable to. This implies you shouldn't have any sensitive data or access to sensitive machines. Since you wouldn't need a laptop without data or access, you probably need to mitigate the consequences of getting hacked.

Make up a couple disposable passwords just to use at the conference, one for this machine and one for outside accounts. Destroy them later.

Bring an empty USB thumb drive.

Create a new email account, so you can send yourself notes/presentations for later.

Forward your important email accounts to the new one (keep copies on the normal accounts), so you don't have to check them.

Note that if you have a hosting plan like DreamHost's, you can create brand-new ssh and email accounts free. I believe DH offers SSL webmail, if you can ignore the certificate warnings.

In your local firewall, block outbound access except to the ports you intend to use; this is easy in Linux, but a bit more complicated on Macs, where you need to write your own startup script (or .command script in Login Items). This is obviously overridable, but an effective way to make sure you don't accidentally connect without encryption, either from habit or because a website redirects you to unencrypted HTTP to save encryption cycles (common). For services where you know what host you'll be connecting to, embed that. Here's a sample of what you might add to add Apple's ipfw. Note that it's easy to shoot your own foot off with outbound firewall restrictions.

ipfw add 01010 allow tcp from any to 4.2.2.1 dst-port 53 out
ipfw add 01020 allow udp from any to 4.2.2.1 dst-port 53 out
ipfw add 01030 allow tcp from any to 4.2.2.2 dst-port 53 out
ipfw add 01040 allow udp from any to 4.2.2.2 dst-port 53 out
ipfw add 01110 allow tcp from any to any dst-port 22 out
ipfw add 01120 allow tcp from any to any dst-port 443 out
ipfw add 01030 allow tcp from any to smtp.dreamhost.com dst-port 587 out
ipfw add 01040 allow tcp from any to mail.dreamhost.com dst-port 993 out
ipfw add 01900 deny tcp from any to any out

When you're back home, connect from your home machines to the untrusted laptop, rather than the other way around, retrieve any data on it, and then boot from CD/DVD/PXE and reinstall, or restore from your image if you can do that without using the untrusted OS on the laptop's hard drive.

I wrote a long article for about SSL/TLS, attempting to explain it to a lay audience. I wrote another piece for admins on how to use CA.pl, which TidBITS didn't pick up, and a third piece about a couple shell scripts I wrote to help run a Certificate Authority, called cert.command & sign.command. I hope you find them interesting and useful.

We were trying to figure out what was wrong with communications between our load balancers and Oracle Application Server this week, and the F5 rep whipped out ssldump. With the SSL key, ssldump can decrypt captured traffic from tcpdump just like wireshark (ethereal) does for unencrypted traffic; apparently it can also do live display of SSL traffic like wireshark, but I haven't tried.

I had to change the school's panel password (which will only be changed again in 24 days when I hand over the reins to my successor, who will change it again), plus my personal panel password, 3 shell passwords, 12 list passwords, this blog's password, and possibly the Analog passswords, and what will I forget?

Crud. Crud. Crud.

DreamHost's next failure is not telling us what the spam links look like. I can't read the source of every page on the site, but if they would tell us what to look for, I could grep for the suspect sites quite easily. I actually found them elsewhere (see the Andy Hagan link below) -- no thanks to DH, whose screw-up I'm now attempting to fix.

Adding injury to injury, I just got the cheery/goofy montly DreamHost email, with no mention of the hack, even though they must have been dealing with the break-in when the message was sent.

To make things worse, the status page where they promise to post updates on this incident doesn't even mention it! This is 2 1/2 hours after they sent me email, and they still haven't come clean in public. On the other hand, oscandy.com had a posting about it a couple days earlier http://www.oscandy.com/hacking/454-dreamhost-hosting-platform-hacked.

To: "Chris Pepper"
From: DreamHost Security Team
Subject: [reppep 11988754] URGENT: FTP Account Security Concerns...
Date: Tue, 5 Jun 2007 18:52:42 -0700 (PDT)
Hello -
This email is regarding a potential security concern related to your
'reppep' FTP account.
We have detected what appears to be the exploit of a number of
accounts belonging to DreamHost customers, and it appears that your
account was one of those affected.
We're still working to determine how this occurred, but it appears
that a 3rd party found a way to obtain the password information
associated with approximately 3,500 separate FTP accounts and has
used that information to append data to the index files of customer
sites using automated scripts (primarily for search engine
optimization purposes).
Our records indicate that only roughly 20% of the accounts accessed -
less than 0.15% of the total accounts that we host - actually had
any changes made to them. Most accounts were untouched.
We ask that you do the following as soon as possible:
1. Immediately change your FTP password, as well as that of any other
accounts that may share the same password. We recommend the use of
passwords containing 8 or more random letters and numbers. You may
change your FTP password from the web panel ("Users" section, "Manage
Users" sub-section).
2. Review your hosted accounts/sites and ensure that nothing has been
uploaded or changed that you did not do yourself. Many of the
unauthorized logins did not result in changes at all (the intruder
logged in, obtained a directory listing and quickly logged back out)
but to be sure you should carefully review the full contents of your
account.
Again, only about 20% of the exploited accounts showed any
modifications, and of those the only known changes have been to site
index documents (ie. 'index.php', 'index.html', etc - though we
recommend looking for other changes as well).
It appears that the same intruder also attempted to gain direct
access to our internal customer information database, but this was
thwarted by protections we have in place to prevent such access.
Similarly, we have seen no indication that the intruder accessed
other customer account services such as email or MySQL databases.
In the last 24 hours we have made numerous significant behind-the-
scenes changes to improve internal security, including the discovery
and patching to prevent a handful of possible exploits.
We will, of course, continue to investigate the source of this
particular security breach and keep customers apprised of what we
find. Once we learn more, we will be sure to post updates as they
become available to our status weblog:
http://www.dreamhoststatus.com/
Thank you for your patience. If you have any questions or concerns,
please let us know.
- DreamHost Security Team