[c-nsp] Change Pix passwds, without getting logged?

[Terje Bless]

Church, Chuck <cchurch at netcogov.com> wrote:

>If the console wasn't set to timeout, and someone connected directly
>into enable mode, they wouldn't have needed to reboot it.  Is it
>possible the config (and current password) wasn't saved, and the Pix
>just crashed?  It would have booted up with the old config/password.  

The access was most likely directly into enable mode on the console, and the
only identified change in the configuration are the changed passwords. A reload
or reboot should actually have changed little as it's a redundant pair of
Pix525s so the configuration gets replicated back and forth between the two;
once it's in the running-config you have to turn _both_ off simultaneously to
completely clear it.

But as mentioned, none of this is really out of the ordinary (if you're stupid
enough to leave your console network-accessible without security, you _will_ get
compromised eventually).


The thing we're worried about is the fact that the password change commands
weren't logged to the syslog server. A Null route to the syslog server, as Ryan
suggested, might explain it, but then that ought have been replicated to the
standby; and when the failover occurs the standby starts logging as usual.

There is a nine second gap in the logs after which there is a failover —
probably because the (active) primary crashed — and logging resumes as normal.
There was a "write mem" a few hours earlier and given the startup-config has the
correct (encrypted) passwords the change must have happened somewhere after that
point.

When we got to the box the only evident change in the (running) configuration
was the changed passwords.

Thus, in those nine seconds the intruder must have disabled logging (without
that change itself getting logged!), changed the passwords, and then re-enabled
logging (again without that change getting logged); or, they found some way to
change the passwords that would not turn up in the logs (without disabling
logging) and the nine second gap is simply due to the primary crashing (possibly
because the intruder deliberately crashed it).


An alternate explanation that's been floated is that this is a bug/crash in
PixOS that just happened to change the two passwords in memory (garbled config
sync combined with a failover, say). Given what I (think I) know of the way that
works I find that a real stretch — the encrypted passwords aren't special in any
way, they're just a config command like any other — and that a stray neutrino
should change _both_ passwords and nothing else must be a statistical
impossibility.

But either way there's a lot here that I don't get. Any plausible explanation
for the observed facts would do much to set my mind at ease here!


-- 
As a cat owner, I know this for a fact... Nothing says “I love you” like a
decapitated gopher on your front porch.