http://weblog.infoworld.com/enterprisemac/archives/2006/08/is_windows_inhe.html
• All Windows background processes/daemons are
spawned from a single hyper-privileged process and referred
to as services.
*nix init doet precies hetzelfde.
• By default, Windows launches all services with
SYSTEM-level privileges.
Alle *nix daemons worden in beginsel als root gestart.
• SYSTEM is a pseudo-user (LocalSystem) that trumps
Administrator (like UNIX's root) in privileges. SYSTEM
cannot be used to log in, but it also has no password, no
login script, no shell and no environment, therefore
• The activity of SYSTEM is next to impossible to control or
log.
Is anders prima te auditten. En met ACLs kun je SYSTEM
verhinderen. Probeer hetzelfde eens met root.
• Most of the code running on any Windows system at a given
time is related to services, most or all of which run with
SYSTEM privileges, therefore
Ten tijde van NT4 klopte dit. Tegenwoordig niet meer.
• Successful infection of running Windows software
carries a good chance of access to SYSTEM privileges.
Een daemin die op root draait heeft hetzelfde probleem.
• Windows buries most privileged software, service
executables and configuration files in a single,
unstructured massive directory (SYSTEM32) that is frequently
used by third parties.
Third parties horen daar niets in te schrijven. Da's geen
probleem van windows maar van die third party app. Op *nix
kunnen third party apps ook in /bin /sbin etc. schrijven.
Windows will notify you on an attempt to overwrite
one of its own system files stored here, but does not try to
protect privileged software.
System Restore.
• Microsoft does not sign or document the name and
purpose of the files it places in SYSTEM32.
The files zijn wel signed. Documentatie is te vinden op MSDN.
• Windows has no equivalent to OS X's bill of
materials, so it cannot validate permissions, dates and
checksums of system and third-party software.
?
• Windows requires that users log in with
administrative privileges to install software, which causes
many to use privileged accounts for day-to-day usage.
Run As...
• Windows requires extraordinary effort to extract
the path to, and the files and TCP/UDP ports opened by,
running services, and to certify that they are valid.
Netstat -abn is heel moeilijk inderdaad, not.
• Microsoft made it easy for commercial applications
to refuse a debugger's attempt to attach to a process or
thread. Attackers use this same mechanism to cloak
malware.
Heeft niets met windows te maken, zijn processor instructies.
A privileged user must never be denied access to a
debugger on any system. My right to track down malware on my
computers trumps vendors' interests in preventing piracy or
reverse-engineering. Maintaining that right is one of the
reasons that open source commercial OS kernels are so
vital.
DMCA heeft dat 'recht' omzeep geholpen.
• Access to the massive, arcane, nearly unstructured,
non-human-readable Windows Registry, which was to be
obsolete by now, remains the only resource a Windows
attacker needs to analyze and control a Windows system.
Da's opzich wel een punt maar zo moeilijk is het registry
ook weer niet.
• Another trick that attackers learned from Microsoft
is that Registry entries can be made read-only even to the
Administrator, so you can find an exploit and be blocked
from disarming it.
Ownership claimen reset de ACL.
• Malicious code or data can be concealed in NTFS
files' secondary streams. These are similar to HFS forks,
but so few would think to look at these.
HFS forks en NTFS ADS zijn hetzelfde. Er zijn zat scanners voor.
• One of the strongest tools that Microsoft has to
protect users from malware is Access Control Lists (ACLs),
but standard tools make ACLs difficult to employ, so most
opt for NTFS's inadequate standard access rights.
ACLs zijn lastig.. Zeker om goed te doen maar dat heeft meer
te maken met de granulariteit.
• OS X has no user account with privileges exceeding
root.
Niet nodig, root=god. Probeer root maar eens ergens uit te
houden.
• Maximum privilege is extended only to descendants
of process ID 1 (init or Darwin's launchd), a role that is
rarely used and closely scrutinized.
Nauwelijks gebruikt? Alles start vanaf init.
• Unlike services.exe, launchd executes daemons and
scheduled commands in a shell that's subject to login
scripts, environment variables, resource limits, auditing
and all security features of Darwin/OS X.
Shell login scripts en environment variablen zijn juist een
risico. LD_LIBRARY_PATH is een leuke bijv.
• Apple's daemons have man pages, and third parties
are duty-bound to provide the same. Admins also expect to be
able to run daemons, with verbose reporting, in a shell for
testing.
MSDN en de eventlog.
• OS X Man pages document daemons' file dependencies,
so administrators can easily rework file permissions to
match daemons' reduced privileges.
MSDN
• Launchd can tripwire directories so that if
they're altered unexpectedly, launchd triggers a
response.
Windows File Protection
• If an attacker takes over a local or remote
console, any effort to install software or alter significant
system settings cannot proceed without entering the
administrator's user name and password, even if the console
is already logged in as a privileged user. In other words,
even having privileges doesn't ensure that even an inside
hacker can arrange to keep them.
Root=god.
• OS X has a single console and a single system log,
both in plain text.
Single console?
• OS X's nearest equivalent to the Registry is
Netinfo, but this requires authentication for modification.
In later releases of OS X, it is fairly sparse.
Normale gebruikers kunnen ook niet veel in het Registry.
Zelfs administrator kan niet bij bepaalde delen.
• Applications have their own per-user and
system-wide properties files, private Registries if you
like, stored in human-readable files in standard
locations.
HKLM vs. HKLU
• Every installed file is traceable to a bill of
materials that can verify that the file is meant to exist,
and that it and all of its dependencies match their original
checksums. Mac users, back up and protect your Receipts
folder!
Wat houdt malware tegen om dat ook te doen?
• The directories used to hold OS X's privileged
system executables are sacred. Anything new that pops up
there is immediately suspect.
Zo ook system32. Third parties horen hier niet in te
schrijven en Windows File Protection voorkomt ellende.
• OS X does not require that a user be logged in as
an administrator to install software. The user or someone
aiding the install needs to know the name and password of a
local administrative user to complete the install.
Run As...
On a network, most software is installed using
Remote Desktop, an inexpensive Systems Management
Server-like console.
RDP/Terminal services.
• The UNIX/POSIX API, standard command-line tools and
open source tools leave malware unable to hide from a
competent OS X administrator.
Rootkits.
It takes a new UNIX programmer longer to choose an
editor than it does to write a console app that walks the
process tree listing privileged processes. Finding the
owners of open TCP/UDP ports or open files is similarly
trivial. The "system" is not opaque.
netstat -abn
• Basic OS X features can be put to use to make life
miserable for malware. For example, Windows' hackable
restore points are done better by OS X's ability to create
encrypted, read-only disk images.
EFS?
They're simpler than archives, and you can mount them
as volumes anywhere in your file hierarchy.
Mountvol.exe
• Likewise, OS X Server will image any Mac client or
server's local drives and maintain safe copies that can be
used not only for restoration, but which can be booted from
to guarantee that there's no trace of infection.
Windows File Protection, System Restore, Boot last known good.
• When erase-and-reinstall is the only way to be
sure, OS X Server automates it. It can safely capture the
affected Mac's active drives before having that Mac boot
from the fresh install image.
System Restore..
Maar waar het allemaal mee begon:
To set the stage, I'll describe the malware's methods. The only victim requirement is that a Windows system--client or server from 2000 and XP on up, 32 and 64-bit--be on an Internet-accessible IP address and listening for socket requests to the Windows Server service. The attacker connects to the Windows Server service, overflows a fixed-length buffer and tricks the service into executing code contained in a portion of the buffer.
Iemand heeft z'n patches niet geinstalleerd... En welke ui zet dit open op Internet?