Re: Help with tracking down intrusion record logs - VMS

This is a discussion on Re: Help with tracking down intrusion record logs - VMS ; From: John Santos > The problem, AFAIK , is that if a user gets out of sync with the prompts on a > login failure, and types his password in to Username:, it will show up in > the Username: ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Help with tracking down intrusion record logs

  1. Re: Help with tracking down intrusion record logs

    From: John Santos

    > The problem, AFAIK, is that if a user gets out of sync with the prompts on a
    > login failure, and types his password in to Username:, it will show up in
    > the Username: field (in plain text) in this file, which, if world-readable,
    > any enterprising nogoodnik could scrape up.


    Could happen. Hasn't.

    > I think ana/audit used to put the attempted passwords in the log, which
    > are sometimes very interesting, but I think it no longer does this.


    You mean like this?:

    Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119
    Auditable event: Remote interactive login failure
    Event time: 22-AUG-2007 16:57:45.90
    PID: 20221BB1
    Process name: _RTA4:
    Username: SMS
    Terminal name: RTA4:, _RTA4:, ALP::SMS
    Remote node fullname: LOCAL:.ALP
    Remote username: SMS
    Status: %LOGIN-F-INVPWD, invalid password


    > You can get valid usernames from successful logins. [...]


    _Successful_ log-ins don't appear in the report.

    > Does anyone know of any other reasons why analyze/audit's output needs to
    > be kept secure? Or is it just on general principle?


    I haven't seen one, which is why I wasn't particularly worried about
    the permissive protections on this report. I normally look at the
    report after I extract it, and if I ever see anything worth protecting,
    I'll probably take some step or other to protect it.

    ------------------------------------------------------------------------

    Steven M. Schweda sms@antinode-org
    382 South Warwick Street (+1) 651-699-9818
    Saint Paul MN 55105-2547

  2. Re: Help with tracking down intrusion record logs

    Steven M. Schweda wrote:
    > From: John Santos
    >
    >>The problem, AFAIK, is that if a user gets out of sync with the prompts on a
    >>login failure, and types his password in to Username:, it will show up in
    >>the Username: field (in plain text) in this file, which, if world-readable,
    >>any enterprising nogoodnik could scrape up.

    >
    >
    > Could happen. Hasn't.
    >
    >
    >>I think ana/audit used to put the attempted passwords in the log, which
    >>are sometimes very interesting, but I think it no longer does this.

    >
    >
    > You mean like this?:
    >
    > Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id: 1119
    > Auditable event: Remote interactive login failure
    > Event time: 22-AUG-2007 16:57:45.90
    > PID: 20221BB1
    > Process name: _RTA4:
    > Username: SMS
    > Terminal name: RTA4:, _RTA4:, ALP::SMS
    > Remote node fullname: LOCAL:.ALP
    > Remote username: SMS
    > Status: %LOGIN-F-INVPWD, invalid password
    >
    >


    Well, no, not like that, because the text the user typed doesn't
    appear here. What I'm claiming is that in an earlier version of
    VMS (which could very well still be in use out there), the response
    to "Password:" *did* appear in the report.

    >
    >>You can get valid usernames from successful logins. [...]

    >
    >
    > _Successful_ log-ins don't appear in the report.
    >


    Only because you've filtered them out or have set audit/disable=logins...

    (The reason I'm being picky about this is because someone is sure to
    Google this someday, possibly in the midst of a security incident, and
    it would be good to have them proceed cautiously and avoid the fire-pits.)

    >
    >>Does anyone know of any other reasons why analyze/audit's output needs to
    >>be kept secure? Or is it just on general principle?

    >
    >
    > I haven't seen one, which is why I wasn't particularly worried about
    > the permissive protections on this report. I normally look at the
    > report after I extract it, and if I ever see anything worth protecting,
    > I'll probably take some step or other to protect it.



    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  3. Re: Help with tracking down intrusion record logs

    In article , John Santos
    wrote:

    > Steven M. Schweda wrote:
    > > From: John Santos
    > >
    > >>The problem, AFAIK, is that if a user gets out of sync with the prompts on
    > >>a
    > >>login failure, and types his password in to Username:, it will show up in
    > >>the Username: field (in plain text) in this file, which, if world-readable,
    > >>any enterprising nogoodnik could scrape up.

    > >
    > >
    > > Could happen. Hasn't.
    > >
    > >
    > >>I think ana/audit used to put the attempted passwords in the log, which
    > >>are sometimes very interesting, but I think it no longer does this.

    > >
    > >
    > > You mean like this?:
    > >
    > > Security alarm (SECURITY) and security audit (SECURITY) on ALP, system id:
    > > 1119
    > > Auditable event: Remote interactive login failure
    > > Event time: 22-AUG-2007 16:57:45.90
    > > PID: 20221BB1
    > > Process name: _RTA4:
    > > Username: SMS
    > > Terminal name: RTA4:, _RTA4:, ALP::SMS
    > > Remote node fullname: LOCAL:.ALP
    > > Remote username: SMS
    > > Status: %LOGIN-F-INVPWD, invalid password
    > >
    > >

    >
    > Well, no, not like that, because the text the user typed doesn't
    > appear here. What I'm claiming is that in an earlier version of
    > VMS (which could very well still be in use out there), the response
    > to "Password:" *did* appear in the report.


    I'll confirm that claim. On at least one occasion I found it useful, as
    it showed where the problem was coming from (for example, a keyboard
    with the wrong language settings).

    > >
    > >>You can get valid usernames from successful logins. [...]

    > >
    > >
    > > _Successful_ log-ins don't appear in the report.
    > >

    >
    > Only because you've filtered them out or have set audit/disable=logins...
    >
    >
    > (The reason I'm being picky about this is because someone is sure to
    > Google this someday, possibly in the midst of a security incident, and
    > it would be good to have them proceed cautiously and avoid the fire-pits.)
    >


    Good thinking.

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

+ Reply to Thread