Project Basecamp is a research effort by Digital Bond and a team of volunteer researchers to highlight and demonstrate the fragility and insecurity of most SCADA and DCS field devices, such as PLC’s and RTU’s.
There has been some lively discussion at MacInTouch about a problem with Lion systems and being able to change the password of a user without verification via dscl(1), and what that means, and I’ve attempted to explain it.
I submitted this as a Reader Report but am archiving here as well.
Gregory Tetrault writes:
Lion’s whole disk encryption feature has a password-related security flaw that should be fixed ASAP.
Not at all.
From the article:
So, in order to change the password of the currently logged in user, simply use:
Key phrase is “currently logged in user”. You must be an authenticated user of the target system in order to leverage this type of attack. WDE is already invalidated at that point.
I dated in high school, what does this mean?
For the non-nerds out there who are wondering what we’re talking about:
When you log in to a Lion system running FileVault 2 WDE (whole-disk encryption), it uses your password and then opens the encrypted volume. You have to authenticate by logging in to do that.
Upon entering your own private Groundhog Day where Lion dutifully resumes your previous session and your home directory is available and your Farmville animals or Malcontent Avians are waiting for you, you have unlocked the whole-disk encryption. That encrypted volume (courtesy of the new Core Storage logical volume manager technology in Lion) has been mounted.
This means you have already unlocked the disk and already have access to the filesystem. Once you are logged in to a Lion system using FileVault 2’s WDE, you have unlocked the disk.
So at that point, you can leverage this bug/flaw what-have-you and dump hashes for other users of your Mac to crack later, or change the password on your account without knowing what it is. This would allow someone else to then login with that password that they have changed it to, BUT it requires them to have access to an active session with you logged in.
This doesn’t mean strangers can access your Mac if they steal it. It means if you are successfully logged you can change your password without knowing what it is.
Log out or shut down. Your disk isn’t locked unless you’re not holding it open. Once you’re logged in, any process can access the filesystem limited only by ACLs and file permissions. It is encrypted on-disk but the volume you open upon login is the unencrypted creamy center.
The real danger
The real threat or attack vector this presents is this:
- Malicious software that you install (MacDefender) and provide your credentials to can then change your password and use that to escalate privileges via UNIX sorcery (i.e. sudo(8)) and do bad things without knowing your password because it can change it to something else, then use that to become the super-user with full permissions to do everything. This is a serious problem.
- Unpatched and vulnerable software such as your Flash Player you haven’t updated since the Bush administration can be manipulated into executing code without you knowing about it. This is also a problem because it can do the same thing mentioned above — force super-user by forcing a password and then doing whatever they want.
When you read a vulnerability notice or security bulletin and see the phrase “execute arbitrary code”, that means “feed whatever malicious software we want onto the system”, and that is precisely what can happen on your Mac if you install software that is malicious (like MacDefender) or when you have exploitable software on your Mac.
How can I stay safe?
“Gosh, Emory, I want to be sure my browser isn’t back-stabbing me every time I play the Facebooks!”
Well you’re in luck! You can use a tool like the Qualys Browser Check to ensure your plugins are all up-to-date.
If they’re not current, they’re likely vulnerable, and you’re leaving yourself open to miscreants and villains.
Staying current on software patches isn’t just for the enterprise. The majority of compromised systems on the Internet are small business, residential home users.
FWIW I strongly recommend (to everyone that listens) that if you aren’t going to stop using Adobe Flash entirely, remove every instance of it from your Mac (Internet Plug-ins folders in /Library and ~/Library) and install Google Chrome and use that for Flash sites. Google does a much better job than you do at keeping the Flash plugin current. Certainly better than Adobe does at any rate.
Hopefully I have managed to avoid the rage of my fellow neck-beards in the nerdery while still explaining to others the situation. It isn’t the end of the world, you do however need to follow best practices.
Log out when not in use. Require passwords. Disable auto-login. Install patches regularly. Practice good hygiene.
I’ve been hearing things about Prey Project, which is an open-source recovery tool for mobile computers (and handsets). I’ve been skeptical because in order for Prey to really work, it requires you to ignore best practices for securing your system. My conclusion is that if you want to use Prey, your computer needs to be about as secure as your average Bait Car.
Doesn’t sound very reassuring does it?
This is a copy of my recent Reader Report: Security on MacInTouch. I was responding to a line from the Prey Project FAQ that reads:
Will Prey still phone home if there’s no user logged in?
The answer is yes, since Prey runs in the background as the root (system) user.
My testing revealed this isn’t accurate. I have not yet tried to validate if Prey will attempt to hit an insecure wireless network, but I will explain my test case:
- MacBookAir4,2 running Mac OS X Lion 10.7.1
- Local accounts like most people use, password required.
- Whole-disk encryption “FileVault 2” active and enabled
- created a lost.html as per Prey’s instructions
- configured smtp credentials for a gmail account
- watched the prey agent check-in with the remote server to pull lost.html a few times
- Sleep the MacBook Air
- Wait five minutes (per my configured check-in) to confirm sleeping as expected
- Remove lost.html from the remote server per Prey’s instruction
- Wait another five minutes (still no GETs of lost.html)
- Wake up the MacBook to a lock screen asking for my password
- Wait five minutes (still no GETs)
- Fail a couple of logins and then clicking to Switch User (still no GETs)
- Login as my locked user
- once logged in, my Keychain unlocks, and my WiFi connection is authenticated, lost.html gets pulled and it works as expected
Prey may work for people who rely on insecure wireless networks and don’t protect their system with a password or any form of encryption of their data. I didn’t test that (and if nobody else volunteers I’ll do that too!).
I wouldn’t recommend relying on Prey if you are security-conscious and leverage whole-disk encryption via FileVault 2 or other mechanisms, or use authenticated wireless connections. Doing so would require you to ignore best practices. I certainly wouldn’t recommend a small business or enterprise use Prey.
I would rather a thief get a MacBook they have to re-image and that I’ll never see again than let them have access to my data. Mac OS X Lion’s “Samaritan” message lets you display a message on the login screen that is probably going to be more effective in getting your Mac back!
When iCloud is released the “Find my Mac” service may be a better option, it isn’t known how that service will work. It’s possible that the tight integration with iCloud will provide some level of accountability for devices you have associated with your ID and report them as stolen? Who knows!?
 If you follow Prey Project’s advice and have an account that requires no login to “lure” people into using your Mac, you are negating whole-disk encryption. Don’t follow their advice if you expect whole-disk encryption to encrypt your files, should your Mac be stolen.
 The nerve of these people using cron instead of launchd! — not following OS X conventions isn’t a great way to deploy this software in my opinion. I’m being somewhat tongue-in-cheek but c’mon.