Announcement

Collapse
No announcement yet.

Systemd To Secure Logs With "Forward Secure Sealing"

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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.

    Comment


    • #22
      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.

      Comment


      • #23
        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.

        Comment


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

          Comment


          • #25
            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

            Comment


            • #26
              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.

              Comment


              • #27
                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?

                Comment


                • #28
                  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.

                  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.

                  Comment


                  • #29
                    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.

                    Comment


                    • #30
                      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)

                      Comment

                      Working...
                      X