DTrace Topics Security
From Siwiki
Contents |
[edit] DTrace Topics: Security
This article is about using DTrace in the field of Security, and is part of the DTrace Topics collection. A general understanding of DTrace is assumed knowledge, which can be studied from the DTrace Topics: Intro section.
DTrace is a dynamic troubleshooting and analysis tool first introduced in the Solaris 10 and OpenSolaris operating systems.
Completion 
Difficulty 
Audience Security admins, sysadmins
[edit] Security and DTrace
Several uses of DTrace may spring to mind for the security professional, such as,
- event auditing
- access control lists
- authorization troubleshooting
- custom alerts
- malware investigation
Some of these are a good idea, some aren't. They will be explained in sections that follow.
For information on assigning privileges for users to run DTrace, see the DTrace Topics: Intro section on Consumers.
But first, perhaps the #1 FAQ about DTrace and security is whether the addition of DTrace to Solaris is a security risk.
[edit] DTrace Security Risk
Some people have suggested that DTrace is bad because it is a security risk. No, it isn't.
By default, only root can run DTrace. root can do all sorts of wicked mischeif anyway (such as reading /dev/mem), so the addition of DTrace hasn't worsened this situation. You could try to argue that DTrace makes certain types of wicked mischeif easier, but this assumes that you have root to start with.
DTrace could seem bad if SysAdmins gave out the dtrace_kernel privilege indiscriminately, which could lead to a root escelation. However the same could be said for other Solaris privileges. Don't give out dtrace_kernel, unless that user is allowed root level privileges anyway.
[edit] Wicked Mischeif
To illustrate of the sort of shenanigans that root with DTrace can perform, the following is shellsnoop, a script that snoops the output from other shells on the system,
Window 1
brendan@mars:~> ls -l passwords.txt -rw-r--r-- 1 brendan other 25 Mar 21 01:35 passwords.txt brendan@mars:~> chmod 600 passwords.txt brendan@mars:~> ls -l passwords.txt -rw------- 1 brendan other 25 Mar 21 01:35 passwords.txt brendan@mars:~> brendan@mars:~> cat passwords.txt mail.example.com fred123 brendan@mars:~> brendan@mars:~> echo wow, I hope no one is watching \! wow, I hope no one is watching !
Window 2
root@mars:/root/DTrace# ./shellsnoop -qp 126987 brendan@mars:~> ls -l passwords.txt -rw-r--r-- 1 brendan other 25 Mar 21 01:35 passwords.txt brendan@mars:~> chmod 600 passwords.txt brendan@mars:~> ls -l passwords.txt -rw------- 1 brendan other 25 Mar 21 01:35 passwords.txt brendan@mars:~> brendan@mars:~> cat passwords.txt mail.example.com fred123 brendan@mars:~> brendan@mars:~> echo wow, I hope no one is watching \! wow, I hope no one is watching !
Window 2 (root) was able to snoop the keystrokes and output from window 1 (brendan). This makes a better live demonstration, as the output in window 2 magically appears as though ghostly fingers are typing at the keyboard.
shellsnoop prints visible text; it would be much more worrysome if it printed invisible text, such as password keystrokes that were not echoed.
[edit] More Wicked Mischeif
The sshkeysnoop.d script captures keystrokes of users executing ssh from the server it is run on, including password keystrokes. do not run this script yourself!
DTrace keystroke sniffing
root@mars:/# ./sshkeysnoop.d UID PID PPID TYPE TEXT 100 9651 8600 cmd ssh -l fred mars 100 9651 8600 key f 100 9651 8600 key r 100 9651 8600 key e 100 9651 8600 key d 100 9651 8600 key 1 100 9651 8600 key 2 100 9651 8600 key 3 100 9651 8600 key 100 9651 8600 key l 100 9651 8600 key s 100 9651 8600 key 100 9651 8600 key u 100 9651 8600 key n 100 9651 8600 key a 100 9651 8600 key m 100 9651 8600 key e 100 9651 8600 key 100 9651 8600 key - 100 9651 8600 key a 100 9651 8600 key
The above output traced an ssh login to mars, with the user "fred" and the password "fred123", followed by the commands "ls" and "uname -a". Shocking? Evil?
Breeching privacy, such as sniffing other user's passwords, could certainly be described as evil (and depending on your country/state, it may be unlawful). Don't do this, even if you are the sysadmin.
This doesn't make DTrace evil. sshkeysnoop.d only works when run as root on the server that users are ssh'ing from. Users run the /usr/bin/ssh command, and DTrace plucks the keystrokes as /usr/bin/ssh reads them in. While DTrace has made it a little easier, DTrace hasn't introduced this security vulnerability - any number of previous tools can do this, assuming that you are root. For example,
truss keystroke sniffing
root@mars:/# ps -ef | grep ssh
root 101044 100375 0 02:32:33 ? 0:00 /usr/lib/ssh/sshd
brendan 101043 100789 0 02:32:33 pts/4 0:00 ssh -l fred mars
root 100375 1 0 01:50:50 ? 0:00 /usr/lib/ssh/sshd
root 101053 100812 0 02:32:38 pts/5 0:00 grep ssh
root@mars:/#
root@mars:/# truss -p 101043
read(4, 0x08046D6C, 1) (sleeping...)
read(4, " f", 1) = 1
read(4, " r", 1) = 1
read(4, " e", 1) = 1
read(4, " d", 1) = 1
read(4, " 1", 1) = 1
read(4, " 2", 1) = 1
read(4, " 3", 1) = 1
read(4, "\n", 1) = 1
write(4, "\n", 1) = 1
ioctl(4, TCSETSF, 0x08046CF8) = 0
Woah - truss can see the password too, and truss has been around for over a decade on Solaris and exists in other forms for other operating systems (strace on Linux)! In fact, with some effort, this same "vulnerability" could be performed with cat/grep/strings and either /proc or /dev/[k]mem.
This vulnerability is one of root abusing their power, not a vulnerability caused by DTrace or truss or cat.
Keystroke sniffing is interesting for another reason, event auditing,
[edit] Event Auditing
DTrace has some uses for Security event auditing, but you must first consider the existing tools in Solaris including:
- process accounting
- BSM auditing
