Test
it
Play
the hacker. Symantec can scan your machine and generate a report
http://security1.norton.com/SSC/
Caveats:
•
Multiple Users
•
Non-passive-mode
FTP connections
•
Allowing for non-obvious traffic (e.g.
Keyserver) |
Test
your firewall settings. Play the hacker. Symantec has a URL
you can visit which scans your machine and generates a report
about its level of security. Keep in mind that if you’re
NAT’ed, it won’t work, and if you’re behind
a firewall, your security administrator may hate you for doing
this.
Caveats:
• If you’re using Multiple Users, you’ll need to make sure
that your fw offers the proper amount of protection for all users. NPF uses one
Prefs file for all users but other fws may not.
• Beware of non-passive-mode FTP connections, often characterized by a
connection drop at 99 percent download completion. (It’s like they TRIED
to make it as frustrating as possible.) Set Passive Mode under Fetch’s “Firewall” Preferences
tab.
• If email takes forever, it may be an AUTH thing. Either allow the traffic
(TCP/113) or do an explicit reject so it doesn’t do the long timeout in
response to a silent drop.
• PTP programs (Gnutella and such) may malfunction in the presence of a
firewall.
• If you block UDP access on high ports, it may mess up DNS. Also don’t
block UDP/68 if you use DHCP to get an IP address (at Dartmouth, this is the
standard method). Ideally you need only allow that access from the IP of the
DHCP server, but if you’re not sure, open that port to anything. It’s
a pretty minor security hole.
•If you use NTP for Date and Time, open up UDP/123 from the specified NTP
server.
• If you use Keyserver over IP, it needs UDP/19283. You probably use it
over AppleTalk, though (default). |
|
MAC
OS X
Everything’s
changed.
OS X is based on a Unix subsystem, a version of FreeBSD
called Darwin. Here’s a pictorial representation of the
OS:)
(Don’t
worry about the GTK/Xdarwin part.) |
|
To
maintain backwards compatibility with the existing library
of Macintosh software, Mac OS X integrates the new Unix-based
environment with a MacOS-based emulation environment called “Classic” (also
sometimes called the True Blue Environment, which is how it
shows up in top). Old Mac apps run within Classic, and Classic
runs within X. As far as X is concerned, Classic is just another
application. It can be killed like any other Unix app, which
is nice for those times when some Classic app crashes the environment.
The term “Carbon” is used to describe applications
which are written such that they can run natively in either
OS X or Classic/OS 9. This is similar
to “fat binary” apps (which existed during the transition from the
680x0 processor to the PowerPC processor -- some software was re-written to include
code for both processor types, and since this tended to make them bigger, they
were called “fat.”) If you Get Info on a Carbon app, you can toggle
a checkbox to tell the app whether to launch in OS X or in Classic. “Cocoa” describes
apps written specifically for OS X, and which will not run in OS 9. Platinum
and Aqua are the names Apple uses to describe the user-visible appearance of
the operating system. Think of them as Winamp skins. Classic always wears the
Platinum appearance, which among other things, describes the shape and size of
common elements like scroll bars and title bars and menu fonts. Similarly, Aqua
is the skin worn by OS X, and it describes things like translucency of background
windows and drop shadows and such. |
|
MAC
OS X Continued
|
QuickDraw
and Quartz are the respective underlying graphics “engines” which
are what drive the appearance of the OS. I’m not sure
if it’s still the case today, but originally, most if
not all of the Mac’s QuickDraw calls were hardwired into
the ROMs, which is why all Mac apps tended to look very similar;
things like title bars and menus and the shape of the cursor
were standard objects. This was very deliberate on Apple’s
part -- it was a big part of what made the Mac easy to use
for newbies, because so much of what you learned about one
app could be applied to all the others.
The light-gray column in this picture shows the “command
line” riding
on top of the Terminal window, which in turn sits above the Shell. IMHO this
doesn’t really serve to illustrate much -- all you need to know is that
if you want to get at the Unix command-line interface, you first have to open
a Terminal window (Terminal is the name of the app that gives you CLI access).
By default, your shell is tcsh, though it’s easy to add bash if you prefer
it.
The far-right column has to do with a nifty add-on (NOT part of the OS, whereas
the rest of the picture is) called XDarwin, which is the Unix XWindows environment
for OS X. This may seem incredibly redundant, but it allows you to do some very
cool things that you wouldn’t otherwise be able to do. It’s outside
the scope of this class, but blitz me if you’d like a demo. |
|
Macs
and Unix
OS X inherits
from NeXTStep and Rhapsody
What you get:
•
Memory
protection
•
Preemptive multitasking
•
Built-in
compiler
•
etc. -- all the coolness of Unix
Combined
with:
•
Really terrific UI that Macs are famous for
•
BUT:
We gave up uniqueness. Vulnerabilities that affect
BSD Unix can now affect Macs, too. |
OS
X inherits much from NeXTStep and Rhapsody. See handout # 3, “Mac
OS X System Administration,” for more about the history
of NeXT and OS X.
OS X is the best of both worlds. It has all the functional advantages of Unix,
like memory protection, preemptive multitasking, the built-in compiler, Unix
compatibility resulting in access to a huge library of software (even the Debian
apt-get tools have been ported to OS X), Darwin is open-source so more software’s
coming faster, etc. AND...
…it has all the user-interface advantages that the Macintosh is famous
for. Most Mac users never need to interact with the Unix-ness directly; they
just revel in the delight of using a Mac that (almost) never crashes.
• The price we pay for this: We’re not unique anymore.
Vulnerabilities that affect BSD Unix, Apache, OpenSSH, etc. can now affect
Macs,
too. |
|
There
can be many
OS
X is a multi-user system.
Administrator is not quite root, but
almost
•
Sudo is invoked when needed in the GUI
•
It
can also be used explicitly at the CLI, just like in any other
Unix Administrator has enough privileges to do just about anything
you need. |
Unlike
old MacOS, OS X is a multi-user system. When you first set
up your new Mac, you are asked to provide a username and password
for the Administrator account. Administrator is not root, but
it’s almost that powerful -- Apple hides root from you,
for your own safety, and invokes something much like sudo when
you need to do root-esque things.
At first I didn’t understand this -- I thought, “this
is MY computer,
I should be able to do ANYTHING I WANT.” So I performed the convoluted
hack to enable root login (this was OS X 10.0, it wasn’t easy) and I habitually
ran things while logged in as root. One day, I went to change modes (chmod) a
file, but I didn’t notice that I’d accidentally selected the whole
hard disk (I was still getting used to OS X), and it seemed to be taking awhile
to finish…spinning beach ball of doom…uh-oh. I’d recursively
chmod’ed every file on the disk. OS X never booted again. I had to boot
into OS 9 to get my data, then wipe the drive and start over.
The moral of the story is, that wouldn’t have happened if I hadn’t
insisted on being root all the time. OS X would’ve chmod’ed maybe
one folder’s worth of stuff, but it would’ve stopped before it reached
the core system files and tossed a dialog saying “you don’t have
permission to do that” or something similar.
Administrator has enough privileges to do nearly anything you’ll need to
do -- you don’t need true root unless you start really messing around with
the Unix guts of OS X. Even then, it’s HIGHLY recommended that you use
sudo, rather than enable the root password and stay logged in as root for long
periods of time. You’re far less likely to do irreparable damage to your
system if you use sudo, since it gives you root privs only on a per-command basis.
Metaphorically, you’ve only chambered one round at a time, and if the gun
goes off, at least it’s not on full auto. ;)
Very rarely will sudo fail to meet your needs. But once in a while, something
in a shell script or some hardcore tinkering will require true root. The easiest
way to go at it in that case is sudo su - and use your Administrator password.
You will be root, with root’s path. |
|
Users
and Folders
You
can create users, and choose whether or not to give them Administrator
rights
Each user has a home folder (under /Users)
Each user also
has a “Desktop” folder, which corresponds to the
desktop he or she sees. |
You
can create however many users you want, and you can give them
Administrator rights (they can do Admin-level stuff using just
their own passwords for authentication, like sudo) or leave
them as normal, non-admin users. Each user has a home folder
(under /Users) which stores his/her documents, preferences,
fonts, personal webpage (if you have Web Sharing enabled),
etc. If you do NOT give users admin rights, then they can only
make new files in their home directories. They can still run
applications that reside outside their home folders, but apps
that need root (say, a sniffer) will not work for them. This
should be quite familiar to Unix users.
Each user also has a “Desktop” folder, which corresponds
to the desktop he or she sees. It shows up as a folder called
Desktop in your home directory,
but it’s simultaneously also the desktop underneath all your windows (which
can get weird, since you can open the Desktop _folder_ and be looking at the
icons that are also on your visible Desktop.) This is quite different from the
Desktop of old MacOS, which was sort of an über-folder. Each user can put
different things on his or her Desktop, and other users won’t see them
-- they’ll see their own Desktops.
Note: Users ought to make use of the screen saver lock feature -- it requires
you to enter your password to unlock the screen saver. System Preferences -> Screen
Effects. And never turn on the auto-login feature unless you’re sure your
Mac is physically isolated from other people; also, it’s better to leave
off the “pick user from list” option and type your username. Again,
don’t make it easier for the bad guys. |
|
Users
and Apps
Users
can install their own applications
If they have Admin rights,
they can install apps available to all users
In general, applications
run with the privileges of the user who launches them. |
Users
can install their own applications, available only to them,
or (if they have Admin rights) they can install apps available
to the whole system.
For the most part, applications run with the privileges of the user who launches
them. In other words, if I open BBEdit and try to edit the /etc/hosts file, BBEdit
will ask me to authenticate as Admin with my password before I can save changes.
(This assumes that my account has Admin rights, or in more Unixy terms, I am
in the sudoers list.) Users who are not flagged as Administrators would not be
able to edit that file at all. |
|
BSD
File Security
Same
as any Unix -- owner, group, everyone, modes, etc.
Can be changed
at the CLI using the usual -- chmod, chown, etc. -- as well as
with the GUI Get Info. |
As
with any Unix, files in OS X have access restrictions based
on owner and group, and files have modes (r/w/x). This isn’t
just the case for network file sharing (as is true with pre-X
Mac OS) -- it’s also true for every file on the system.
Old news for Unix folks, but a new realm for Mac users.
|
|
Classic
When
you open an old Mac app, OS X first launches the Classic (“TrueBlue”)
environment, then opens the app within that The integration is
fairly seamless -- some menus change, but you always see the
OS X Finder/Desktop and the Dock If some Classic Mac app crashes,
it’ll probably take the Classic environment down with it,
but OS X keeps running :) |
To
maintain compatibility with old MacOS software, Apple developed
a MacOS emulation environment, called Classic. When you open
an old Mac app, say, Classic Netscape, OS X first launches
the Classic (“TrueBlue”) environment, then opens
Netscape within that. The integration is fairly seamless --
some menus change when you flip between OS X and Classic apps,
but you always see the OS X Finder/Desktop and the Dock.
Classic runs as a separate process under OS X -- Classic is,
in effect, just another application under OS X. The cool thing
about this is that when some Classic
Mac app crashes (that would NEVER happen! hah), it’ll probably take the
Classic environment down with it, but OS X keeps running happily. The miracle
of memory protection.
(In the beta release of OS X Server, Classic and X were integrated differently,
and it was possible for Classic to crash and take the input devices with it.
OS X would still be running, but you couldn’t reach it to kill Classic
-- your cursor was frozen, keyboard locked. But, you COULD shell in from another
machine and run ps, find the Classic process, and kill -9 it and get X back.
Nice.) |
|
Classiconfusion
• The
integration is fairly seamless. Not completely.
Examples:
•
Both
Classic and OS X use a single IP address
•
File sharing
weirdness
•
Both environments can share a printer
•
OS
X owns the CD-ROM and Zip drive
•
Only one Finder (X)
•
OS
9 Desktop is still separate from OS X’s |
The
integration is _fairly_ seamless. It still takes a lot of getting
used to, especially if you’ve been a Mac user for awhile.
Examples:
Both Classic and OS X use a single IP address. It doesn’t affect client-type
behavior (e.g., you can use a web browser in each environment simultaneously),
but it can get weird with running servers.
You can’t do file sharing under Classic under X anymore (but you could
do it with AppleTalk only, no AFPoverTCP, in OS X 10.1, WHILE you were sharing
files directly from X too. Schizophrenic.) You can’t connect to AppleTalk-only
servers from Classic, but you can from X. You CAN do Program Linking from within
Classic, God only knows what happens if try to do Apple Events in X at the same
time. (It seems to let you turn on both simultaneously…)
Both environments can share one printer (need drivers for each environment, except
for the occasions when Classic just seems to “learn” about the printer
from X), but OS X owns the CD-ROM and Zip drive.
There is only one Finder (in X).
The Desktop of Mac OS 9 is a separate entity from that of OS X, and under OS
X, it’s invisible in the Finder (but you can see it from the Terminal if
you list the contents of the / directory). When you install OS X, it automatically
creates an alias to the Mac OS 9 Desktop, and puts that on your OS X Desktop
(stay with me here) and if you delete it, like I did, then you’re sorta
locked out of your OS 9 Desktop. But don’t worry, it’s still there
if you boot into 9. (More on that in the next slide) |
|
More
on Classic/X
More:
Under the standard partitioning scheme, you can boot directly
into MacOS 9
•
This has scary implications for file permissions
Carbon apps will run in anything, which is good to know
OS X “packages” (app
bundles) will appear as folders in 9, don’t mess with the
contents! |
Oh,
and as if that’s not enough, you can tell the Mac to
boot directly into MacOS 9 (using the same System Folder as
Classic), and then OS X effectively disappears and you have
an old-school Mac again. This also has the side effect of making
most of the Unix file permissions moot -- in other words, if
you boot into 9, you can probably delete the /bin directory
REGARDLESS of your OS X Administrator status, because regular
MacOS doesn’t speak that language. There isn’t
a complete disregard for it, though. Some key files and directories
from OS X will be “grayed out” in the Finder if
you boot into MacOS 9. But…from a Save or Open dialog
in some applications, you can still see and modify everything.
Mac OS 9 is gradually being phased out, but in the meantime,
all you can really do is shrug and be careful.
Remember the Carbon thing? Those apps will run in OS X, or
in Classic, or in OS 9 directly. So? Well, if you make a bad
mistake like I did, and hose your
OS X system, you can (hopefully) still boot into OS 9. You can grab your original
CD and boot off it long enough to change the Startup Disk setting and reboot
9. Then, if you held onto some Carbon (or Classic) apps, you can go in and run
them from 9 and perhaps use them to recover your data. It’s nice to have
a copy of Fetch that will work in either environment -- I used it to move my
data onto a network file server when I did the Bad Chmod that time. In short:
If you’ve got the disk space, it’s a good idea to hang onto Classic/Carbon
apps even after you install a superior Cocoa equivalent, so you double your chances
of being able to recover from a bad event. If you’re in 9 and you want
to know whether some app will run or not, you can just try it, and you’ll
get a message if it’s Cocoa. In general, if the application icon appears
properly in 9, it’s probably Carbonized.
One other note: OS X Cocoa apps sometimes make use of “packages,” which
are essentially application bundles -- they will appear as a single icon that
you double-click to launch, just like any other app, but if you control-click
them, you can see and alter the contents. Sort of like using ResEdit in the old
days to hack the resource fork, only now you don’t need a separate tool.
But if you boot into OS 9, packages will appear as folders since OS 9 doesn’t
know what packages are -- don’t start adding or removing things from them,
because when you boot back into OS X, they might not work right anymore! |
|
OS
X Security “out of the box”
Is
pretty good.
If I turn off my firewall and run TCP and UDP portscans
against my Mac, here are the results (notes sections):
I can
explain what I see. Nothing mysterious. This is important.
I
haven’t done any low-level hacking to turn off default
services, so a base OS X install should have fewer open ports
than what I have. |
Results
of nmap -sT -p 1-65535 my-mac (that’s a plain vanilla
TCP scan of all ports):
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on my-mac (some.ip.address):
(The 65530 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
80/tcp open http
427/tcp open svrloc
548/tcp open afpovertcp
902/tcp open unknown
913/tcp open unknown
2151/tcp open unknown
We know what the first two are. I’m running SSH (“Allow remote login” is
turned on in Sharing) and I’ve got Web Sharing turned on. 427 (svrloc)
is the Server Location daemon/protocol, which helps my Mac and other Macs find
each other’s services on the network. Port 548 shows File Sharing enabled
(over TCP, default on OS X, though I can enable AppleTalk as well). Nmap didn’t
know what port 913 is for, so I Googled for “port 913” and discovered
that it’s the Sidecar port (part of Kerberos, which we use to access protected
portions of the Dartmouth website, among other things). Ports 902 and 2151 are
for my BlitzMail ssh tunnel. If I hadn’t already known that, it’d
be kinda hard to figure out, since BlitzMail is a Dartmouth thing and Googling
for those ports will get you a lot of nonsense. But I could’ve tried telnetting
to those ports… |
|
What
is THAT port?
bash
mbates@my-mac ~ $ telnet localhost 902
Trying 127.0.0.1...
Connected
to localhost.
Escape character is '^]'.
220 DND server here.
Aha! Unfortunately, the same trick for 2151 is a lot less informative. |
bash
mbates@my-mac ~ $ telnet localhost 2151
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello?
011 Unknown command: hell
helo
011 Unknown command: helo
help
011 Unknown command: help
user
013 Missing argument.
info
011 Unknown command: info
get
011 Unknown command: get
(I gave up and exited)
Heh. But, a logical next step might’ve been to search the Dartmouth Computing
Services webpages for info on what ports BlitzMail uses.
|
|
More
on ports and services
• lsof
-i shows ports and their corresponding services
•
You can
get this with netstat, but lsof is a little easier to read and
interpret
Excerpt:
automount 260 root 4u inet 0x01bb8970 0t0 UDP *:860
httpd 268 root 16u inet 0x01d33cdc 0t0 TCP *:80 (LISTEN)
httpd
270 www 16u inet 0x01d33cdc 0t0 TCP *:80 (LISTEN)
sshd 283 root
3u inet 0x01d33a2c 0t0 TCP *:ssh (LISTEN)
slpd 293 root 0u inet
0x01bb8560 0t0 UDP *:427
slpd 293 root 1u inet 0x01d3377c 0t0
TCP *:427 (LISTEN)
|
Results
of nmap -sU -p 1-65535 my-mac (same as before, but UDP ports
this time):
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on my-mac (some.ip.address):
(The 65526 ports scanned but not shown below are in state: closed)
Port State Service
68/udp open dhcpclient
123/udp open ntp
427/udp open svrloc
514/udp open syslog
860/udp open unknown
49152/udp open unknown
49155/udp open unknown
49158/udp open unknown
49160/udp open unknown
68 is for my Mac to get an IP address from the DHCP server on my network. 123
is ntp, Network Time Protocol -- my Mac syncs its clock with Dartmouth’s
NTP server. 427 is the UDP port for svrloc, explained on the previous slide (svrloc
uses both TCP and UDP). 514 is syslog appearing to listen on the network, but
it doesn’t actually accept data from other hosts. 860 is automounter listening
for other hosts’ nfs requests, which is moot since I don’t have any
nfs shares defined. 49152 is being used by Keyserver, and I can’t telnet
to it (connection refused), so how would I know? I cheated and used lsof. (Could’ve
done that before too, but I wanted to show you another way to figure out what
ports are used for which applications.) The last three ports are being used by
lookupd, the all-purpose lookup daemon (for DNS among other things) and again,
I used lsof to figure that out. |
|
Logs
Via
syslog. Look in /var/log system.log is a good place to start
•
Firewall
logs (seems buggy, at least with BrickHouse -- sometimes stops???)
•
Use
of sudo
•
Subsystem status messages
also, /var/log/httpd/access_log
and error_log
others for other services (ftp, mail, etc.) |
OS X logs via the
Unix syslog facility. There may be some nice GUI log
reader available, but your best log analysis tools are grep and/or a good text
editor with a Find function. E.g.:
grep sudo /var/log/system.log # Look for all instances of sudo
tail -f /var/log/system.log | grep something # Watch the log as it’s written
(-f # = “follow”) and pipe the output # to grep to look for “something”
grep -v <your-ip> /var/log/httpd/access.log # Inverse grep (look for #
everything BUT your-ip)
And so on.
|
|
Unix
and Mac can collide…
VHFS+
is the native/default file system for OS X
OS X also supports
UFS (Unix File System)
One big difference:
•
HFS+ preserves
case of file names, but is case- insensitive (filename = FileName
= FILENAME)
•
UFS is not! Those could be three separate
files
•
Implications? |
Sometimes
the Mac-ness and the Unix-ness of OS X really butt heads.
HFS+, the Mac’s native file system since approximately
MacOS v. 8, is a
case
preserving but case-insensitive file system. This means that, under HFS+, a
file called “goober” cannot exist in the same folder as a file called “GooBer”
or “GOOBER” etc. Those are all considered to be the same name. But,
under
UFS, which is also supported by OS X, case DOES make a difference; UFS
would consider all of those to be separate file names. Well, so what? |
|
Apache
vulnerability!
“CERT/CC
Vulnerability Note VU#439395 Apache web server performs case
sensitive filtering on Mac OS X HFS+ case insensitive filesystem...
...Impact: Can bypass Apache file access protection, allowing
remote unprivileged users to read privileged files.” Yikes! |
THIS
is what:
---------------------------------------------------------------------------------------------------------------
CERT/CC Vulnerability Note VU#439395
Apache web server performs case sensitive filtering on Mac OS X HFS+ case insensitive
filesystem
I. Description: The Apache web server's file access protection scheme (i.e.,
file request
"filtering") assumes that the filesystem being protected is case sensitve...
Under the Apache scheme, you specify whether to deny or allow access to a filesystem
object
(which can be a directory, filename, or URL). The specifications are called "directives",
which
include <Directory>, <Files> and <Location> directives. See
for further information
on directives.
When you use a directive to deny access to a file or directory using the Apache
web server
under Mac OS X HFS+, the directive will NOT deny access to any other upper and
lower case
variation on the filename or directory...
-----------------------------------------------------------------------------------------------------------------
OOPS! Some tweaking in the Apache config file could fix this, and Apple
released a patch right away, so it’s not an issue now. But this serves
to
illustrate how programs which are accustomed to Unix/UFS behavior can
potentially be tripped up by seemingly-subtle differences like that.
For more details on this vulnerability and its solutions, go to:
|
|
Ease
of Use
OS
X is much more server-oriented than old MacOS
All sharing-related
services are handled from a single Preference pane
•
One
click turns on file sharing
•
One click turns on FTP access
to shared files
•
One click turns on Web Sharing
•
One
click turns on SSH access
Even more important: One click turns
these OFF! |
OS
X, even the non-”Server” version, is much more server-oriented
than old MacOS. Most of its server functionality can be turned
on or off and configured through the Sharing preference pane.
The defaults for most services are well-thought-out and are sufficient
for most users’ needs.
In the Sharing preference pane, all of the following services can be turned on
or off, and tweaked:
• File sharing
• FTP access to shared files (yikes…)
• Web Sharing, which uses the tried-and-true Apache web server -- root
web dir is Admin-access only, and each user has homepage folder (http://.../~username)
• Remote shell access - using OpenSSH, not telnet!
• Remote Apple Events (formerly known as Program Linking)
Likewise, one click turns these OFF, which is important when a vulnerability
in Apache or OpenSSH is discovered. As of OS X 10.2, the Sharing pane also includes
a GUI to administer the firewall. From what I’ve seen, it seems pretty
minimal...I’d still recommend BrickHouse, which we’ll talk about
soon.
A note: These service startup settings are written to a file, /etc/hostconfig.
You can edit this file directly to turn services on/off at startup. Good to know
if you want to shut down a service when you’re not sitting in front of
the Mac (i.e., do this over SSH). |
|
<<Back | Index | Next >>
|