4 ms·

In Linux, one way I protected my webserver in the past was to just do: cd /; sudo git init; git add /etc /{bin,sbin,lib} /usr/{bin,sbin,lib,local} ... ; su

In Linux, one way I protected my webserver in the past was to just do: cd /; sudo git init; git add /etc /{bin,sbin,lib} /usr/{bin,sbin,lib,local} ... ; sudo git commit git clone / into another remote server, and I can git diff from time to time to see if anyone/code mod my system. One very nice side effect of this system is that I got to know in details what files were modded and added when ever I did an "apt-get install ..." Questions for mac Guru: 1. Have anyone done this in Mac? 2. Any pro/con on why, why not do this? 3. Other than, /{bin,sbin,lib} /etc, /usr/{bin,sbin,lib}, What other dirs should I add? What's best way to handle /Applications/ (25GB ) ? 4. What other dirs can a worm,virus, hide in my Mac? Any good dtrace scripts to help monitor who/what is writing to those places?

patio11 12y ago
Keep in mind that, if the attacker gets code execution on your box, everything the box says is a lie if he wants it to be. You may catch some dumb attackers who leave readily available evidence of compromise, but there exists off-the-shelf ratware which is not amenable to discovery via simply diffing. As to where else a worm/virus can hide in your Mac: everywhere. Got a hard disk with writable firmware? It could be in the firmware. If you ask the firmware "Hey, apropos of nothing, do you contain a virus?" it will say "No, no, only totally authorized hard disk firmware here. Feel absolutely safe about reading executable instructions from me."
- atmosx 12y ago
  > Keep in mind that, if the attacker gets code execution on your box, everything the box says is a lie if he wants it to be. Sure, but in real life that's extremely unlikely. I never seen such a 'rootkit', meaning a rk complete at every level that disguises EVERYTHING (processes, connections, evades anti-rk software, etc.). It's been many years since the last time I was interested in security so things might have changed, but given the amount, time and effort that such a rootkit would take (to target specific OSes/versions) I'd say that it's highly unlikely unless it's gov-founded.
  - walterbell 12y ago
    How would you know, unless you booted from read-only media that contained signatures of known-good files?
    - atmosx 12y ago
      I can only judge by what I see, I can't judge real life applications by theorising about what's possible and I remember playing around with rootkits since adore-ng (by TT), which was fairly sophisticated back in the day.
      - walterbell 12y ago
        If you're going to judge, that implies you have at least looked for information on which to base a judgement. In this case, "looking" is not possible with a compromised OS, it requires booting from forensic media. Edit: to downvoter, you may want to read Phrack April 2014, http://www.phrack.org/papers/revisiting-mac-os-x-kernel-rootkits.html http://www.phrack.org/papers/revisiting-mac-os-x-kernel-root...
  - acdha 12y ago
    > I never seen such a 'rootkit', meaning a rk complete at every level that disguises EVERYTHING Isn't that the same as saying you'd only notice an incompetent attack? I've seen this twice (public web server running a student's exploitable PHP followed by a kernel 0-day) – once it was possible to see it due to a bug in the hiding logic (IIRC it compromised ps but not /proc) but the other was unnoticeable on the box itself. This was a decade ago and it was neither uncommon nor particularly sophisticated back then – the actual kernel exploit used to install it was novel but the rootkit code was widely available. I caught both of these attacks quickly because they were foolish enough to use IRC as a control channel and our IDS immediately caught the traffic – want to bet against someone realizing there are stealthier ways to report home?
- tonyplee 12y ago
  That's why I trust git more than anything else, especially compare to the typical "Anti-virus" software. git is written by Linus, open source, whole algorithm is based on file content change detection, base on hashes, etc. If my server software is corrupted initially by XXX gov agency at the Debian website, well, I can't do anything about it. If someone did management to add any additional software to the server after I add all file contents to git and clone it to a different server, I have strong confident I can detect any changes happen in the system with ease. Patio11, I have great respect for you works, blogs, etc. Assume you can hack/overwrite any piece of code in that server to anyway you want, what kind of changes can make so my git clone/backup system failed to detect your changes? Even if you can hack the git executable to tell me nothing has changes, I think when I do a remote git pull with the original git binaries, I can see the modifications. Right?
solarexplorer 12y ago
You may want to send your syslog to the remote server too. Like patio11 said, after the web server gets hacked, you cannot trust it anymore to do a legit git diff or store the legit log files. If you have a remote syslog, you can at least do forensics. (Except if your log server got hacked too...)
- pjmlp 12y ago
  The best way to prevent the log server from being hacked is to use multicast in the logs. Then you have a few log servers listening for those packets. Even if the server gets hacked, you will get other ones with the full, correct, log.
  - acdha 12y ago
    … and make sure that those servers run different kernels, syslog implementations, etc. so they don't all get hit by the same exploit. Probably a good idea to make sure that at least one of them is on a read-only network port, too.
dsl 12y ago
With a kernel based rootkit, git would never see the hidden files or would see a pristine version of the file. I've encountered this before on pentests. Not only was it easy to subvert, when I popped the version control server I got access to the data of a dozen or so other servers.
- tonyplee 12y ago
  You mean the zImage or vmLinux has been replace? Would adding them to the git help detect this?
jewel 12y ago
This is called intrusion detection, and there are a number of ready-made products that do it more efficiently. For an example, see tripwire. This will easily handle /Applications/. On first run it gets a hash of all the files, and then you schedule subsequent runs in cron to see what has changed. The problem with any approach like this is that if it were in common use that it'd be easy for the malware to change tripwire itself to stop it from detection. It also won't detect something that only infects running processes, infects firmware, or otherwise leaves the local filesystem alone. That's why you'd want to have defense in depth, such as having a separate box monitoring traffic, looking for anomalies. I'm not sure what the appropriate approach would be on a end-user machine. Any security measure that's implemented in software on the machine itself is a arms race against the malware authors. This has been going on for a long time in the Windows world, and I don't think there is anything fundamentally different about Linux and OS X that would protect them if they received the same amount of attention from malware authors.
- tonyplee 12y ago
  I have looking into tripwire before. It is old and complex. Git uses the hash of all files also and I am use to it.

patio11 12y ago

Keep in mind that, if the attacker gets code execution on your box, everything the box says is a lie if he wants it to be. You may catch some dumb attackers who leave readily available evidence of compromise, but there exists off-the-shelf ratware which is not amenable to discovery via simply diffing. As to where else a worm/virus can hide in your Mac: everywhere. Got a hard disk with writable firmware? It could be in the firmware. If you ask the firmware "Hey, apropos of nothing, do you contain a virus?" it will say "No, no, only totally authorized hard disk firmware here. Feel absolutely safe about reading executable instructions from me."

atmosx 12y ago
> Keep in mind that, if the attacker gets code execution on your box, everything the box says is a lie if he wants it to be. Sure, but in real life that's extremely unlikely. I never seen such a 'rootkit', meaning a rk complete at every level that disguises EVERYTHING (processes, connections, evades anti-rk software, etc.). It's been many years since the last time I was interested in security so things might have changed, but given the amount, time and effort that such a rootkit would take (to target specific OSes/versions) I'd say that it's highly unlikely unless it's gov-founded.
- walterbell 12y ago
  How would you know, unless you booted from read-only media that contained signatures of known-good files?
  - atmosx 12y ago
    I can only judge by what I see, I can't judge real life applications by theorising about what's possible and I remember playing around with rootkits since adore-ng (by TT), which was fairly sophisticated back in the day.
    - walterbell 12y ago
      If you're going to judge, that implies you have at least looked for information on which to base a judgement. In this case, "looking" is not possible with a compromised OS, it requires booting from forensic media. Edit: to downvoter, you may want to read Phrack April 2014, http://www.phrack.org/papers/revisiting-mac-os-x-kernel-rootkits.html http://www.phrack.org/papers/revisiting-mac-os-x-kernel-root...
- acdha 12y ago
  > I never seen such a 'rootkit', meaning a rk complete at every level that disguises EVERYTHING Isn't that the same as saying you'd only notice an incompetent attack? I've seen this twice (public web server running a student's exploitable PHP followed by a kernel 0-day) – once it was possible to see it due to a bug in the hiding logic (IIRC it compromised ps but not /proc) but the other was unnoticeable on the box itself. This was a decade ago and it was neither uncommon nor particularly sophisticated back then – the actual kernel exploit used to install it was novel but the rootkit code was widely available. I caught both of these attacks quickly because they were foolish enough to use IRC as a control channel and our IDS immediately caught the traffic – want to bet against someone realizing there are stealthier ways to report home?
tonyplee 12y ago
That's why I trust git more than anything else, especially compare to the typical "Anti-virus" software. git is written by Linus, open source, whole algorithm is based on file content change detection, base on hashes, etc. If my server software is corrupted initially by XXX gov agency at the Debian website, well, I can't do anything about it. If someone did management to add any additional software to the server after I add all file contents to git and clone it to a different server, I have strong confident I can detect any changes happen in the system with ease. Patio11, I have great respect for you works, blogs, etc. Assume you can hack/overwrite any piece of code in that server to anyway you want, what kind of changes can make so my git clone/backup system failed to detect your changes? Even if you can hack the git executable to tell me nothing has changes, I think when I do a remote git pull with the original git binaries, I can see the modifications. Right?

solarexplorer 12y ago

You may want to send your syslog to the remote server too. Like patio11 said, after the web server gets hacked, you cannot trust it anymore to do a legit git diff or store the legit log files. If you have a remote syslog, you can at least do forensics. (Except if your log server got hacked too...)

pjmlp 12y ago
The best way to prevent the log server from being hacked is to use multicast in the logs. Then you have a few log servers listening for those packets. Even if the server gets hacked, you will get other ones with the full, correct, log.
- acdha 12y ago
  … and make sure that those servers run different kernels, syslog implementations, etc. so they don't all get hit by the same exploit. Probably a good idea to make sure that at least one of them is on a read-only network port, too.

dsl 12y ago

With a kernel based rootkit, git would never see the hidden files or would see a pristine version of the file. I've encountered this before on pentests. Not only was it easy to subvert, when I popped the version control server I got access to the data of a dozen or so other servers.

tonyplee 12y ago
You mean the zImage or vmLinux has been replace? Would adding them to the git help detect this?

jewel 12y ago

This is called intrusion detection, and there are a number of ready-made products that do it more efficiently. For an example, see tripwire. This will easily handle /Applications/. On first run it gets a hash of all the files, and then you schedule subsequent runs in cron to see what has changed. The problem with any approach like this is that if it were in common use that it'd be easy for the malware to change tripwire itself to stop it from detection. It also won't detect something that only infects running processes, infects firmware, or otherwise leaves the local filesystem alone. That's why you'd want to have defense in depth, such as having a separate box monitoring traffic, looking for anomalies. I'm not sure what the appropriate approach would be on a end-user machine. Any security measure that's implemented in software on the machine itself is a arms race against the malware authors. This has been going on for a long time in the Windows world, and I don't think there is anything fundamentally different about Linux and OS X that would protect them if they received the same amount of attention from malware authors.

tonyplee 12y ago
I have looking into tripwire before. It is old and complex. Git uses the hash of all files also and I am use to it.