Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 31

Thread: Systemd To Secure Logs With "Forward Secure Sealing"

  1. #21
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote Originally Posted by crazycheese View Post
    Lookup Uplink (game) log deleter levels
    Deleting or overwriting is something that will be noticed much easier, true, but it will still prevent or slowdown a backtrace.
    If your IDS and other monitoring is setup correctly doing something like that would be the same as if the attacker sent a email to your administator and said: 'Hey, this machine I am emailing you from. I was yours and I hacked it a bit ago.'

    Which is exactly what they don't want to happen. It would be easier to just leave the old logs alone and just prevent newer activity from being logged and hope that the admin is clueless enough that they won't notice any evidence of the successful intrusion detection in the logs. (this is usually a fairly safe bet)

    Now if the way they attacked you is valuable enough that they are willing to blow the whistle on themselves then deleting the logs could be a advantageous option.

  2. #22
    Join Date
    Jul 2008
    Posts
    1,731

    Default

    Quote Originally Posted by tettamanti View Post
    The sealing key changes with time (15m by default) and the old key is securely erased; the algorithm is designed so that given K(t) is easy to compute K(t+1) (i.e. the new key), but it's not possible to compute K(t-1) given K(t) (i.e. it's not possible to compute the "old" key given the current one). The starting point K(0) is derived from the verification key (which is not stored on the machine), and using the verification key it's possible to generate K(t) for any t.
    An attacker could tamper with the last portion of the log, the one cover with the key currently stored on the system, but cannot alter the past checkpoints (seals) since he is unable to compute the older keys (including K(0)).
    so if the key changes every few minutes, how do keep the other key a) seperate b) without of reach and c) still up to date?

    Sounds... not very secure.

    Either way, a guy has root access you are toast.

  3. #23
    Join Date
    Jul 2008
    Posts
    314

    Default

    Quote Originally Posted by tettamanti View Post
    The sealing key changes with time (15m by default) and the old key is securely erased; the algorithm is designed so that given K(t) is easy to compute K(t+1) (i.e. the new key), but it's not possible to compute K(t-1) given K(t) (i.e. it's not possible to compute the "old" key given the current one). The starting point K(0) is derived from the verification key (which is not stored on the machine), and using the verification key it's possible to generate K(t) for any t.
    An attacker could tamper with the last portion of the log, the one cover with the key currently stored on the system, but cannot alter the past checkpoints (seals) since he is unable to compute the older keys (including K(0)).
    So couldn't an attacker log on, grab K(t) from wherever it's currently stored, be evil for several hours, then go back and re-write the log verbatim until the start of K(t), then (with knowledge of how to compute all keys after K(t)) rewrite an altered log from then onwards?

    It might be a bit more secure if a key change was initiated upon each login, but an attacker could still hide all activity after that, and make their login look legitimate.

    It might also be a bit more secure if the log is fully encrypted and unreadable on the local host, which would force the attacker to guess what a legitimate log could look like.

  4. #24
    Join Date
    Aug 2007
    Posts
    6,683

    Default

    Well maybe just replace systemd with a patched version then. Or just disable logging.

  5. #25
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    985

    Default

    Quote Originally Posted by Kano View Post
    Well maybe just replace systemd with a patched version then. Or just disable logging.
    Or use a secure logging server that has a different password for the admin account

  6. #26
    Join Date
    Apr 2010
    Posts
    820

    Default

    Quote Originally Posted by Kano View Post
    Well maybe just replace systemd with a patched version then. Or just disable logging.
    And disable the mechanism checking that things like systemd and logging daemons haven't been messed with. And do it all quickly enough that *none* of the layers of detection have a chance to sound an alarm.

  7. #27
    Join Date
    Aug 2007
    Posts
    6,683

    Default

    Well some things could be easyly disabled. Like when you want to check for checksums to verify integrity you just delete em (or fix em). As soon as you are root it is just a matter of your skill how to hide best. If you ever tried to analyze a hacked system you should know how easy that task is. There are some tricks to "hide" processes which basically show the pid when done incorrectly, so there are some markers but really tricky. Did you ever watch a hacking contest?

  8. #28
    Join Date
    Jan 2009
    Location
    Italy
    Posts
    82

    Default

    Quote Originally Posted by energyman View Post
    so if the key changes every few minutes, how do keep the other key a) seperate b) without of reach and c) still up to date?
    The verification key ("other") is generated only once at system setup and is never altered.

    Quote Originally Posted by energyman View Post
    Either way, a guy has root access you are toast.
    The point is to ensure the integrity of the logs *up to* the intrusion, once the attacker has gained root privileges all the data must be considered untrusted.

  9. #29
    Join Date
    Jan 2009
    Location
    Italy
    Posts
    82

    Default

    Quote Originally Posted by grantek View Post
    So couldn't an attacker log on, grab K(t) from wherever it's currently stored, be evil for several hours, then go back and re-write the log verbatim until the start of K(t), then (with knowledge of how to compute all keys after K(t)) rewrite an altered log from then onwards?
    It's certainly possible, once the attacker is in all bets are off; the thread model of FSS however is different: the system tries to ensure integrity of log files up to the intrusion, after that the attacker can alter the logs as [s]he sees fit.
    The point is that the attacker cannot change logs prior to the current seal, and the old logs may contain information useful for an IDS or for an analysis of the break-in.

  10. #30
    Join Date
    Sep 2011
    Posts
    69

    Default

    Regular bs from the systemd author. Unfortunately, my high expectations got torn into high disappointment times and times again with this software.

    The seccomp filter was already pretty useless, the binary with a weirdo log format was pretty annoying to deal with, and this is just as bad.

    I can understand experimenting with features and trying new things, but this is different, as systemd pushes those features into the world, no questions asked. (thanks fedora, archlinux etc, for making this pile of junk a default)


    To argue with that very case:

    - whoever claimed he had a glimpse of computer security obviously has no clue. deleting logs on compromised systems is a very common case. its the most common case, in fact. the reason is that nobody is going to notice. you can replace by files filled with garbage with the same name, time, does not matter.
    you can also simply compromise the system before the key is deleted, anyway. most root compromises also happen well within 15min, as local root exploits are rather common, and few are the kernel with no vuln. Those are much cheaper to buy than client exploits too (obviously, since they're so common)

    - encrypting logs in such a way is generally more cumbersome AND less secure than using a remote log server, so, why bother?

    - decrypting logs require transmitting them to another machine, then pulling the decryption key, then decrypting, then reading. Fun! most people using this feature will end up typing the decryption keys ON THE SAME HOST via SSH anyway, which is, well, defeating the whole purpose. More fun! (and once again, people who realize this and do need more log security, will have a separate syslog server as its more secure, reliable, and useable, by several magnitudes)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •