Argus-info Digest, Vol 77, Issue 14

Mark Poepping poepping at cmu.edu
Tue Jan 17 22:44:03 EST 2012



When it comes to argus data, especially with user data, you better not be leaving it lie around anyway.  I’d claim that argus will never be able to entirely scrub the data, so while it’s cheap to put the options in (and I really don’t mind if it doesn’t hurt performance), my inclination would be to keep the default behavior as keeping the data intact and instead improving the setup materials (configure) to clarify these key options (for default argus.conf file) – and while you’re at it, warn the heck out of people to protect this stuff, since there’s bound to be sensitive data..

Just my opinion.

Mark.







From: argus-info-bounces+poepping=cmu.edu at lists.andrew.cmu.edu [mailto:argus-info-bounces+poepping=cmu.edu at lists.andrew.cmu.edu] On Behalf Of Carter Bullard
Sent: Tuesday, January 17, 2012 9:56 PM
To: Dave Edelman
Cc: argus-info at lists.andrew.cmu.edu; CS Lee
Subject: Re: [ARGUS] Argus-info Digest, Vol 77, Issue 14



Hey Dave,

Hmmmmm, I can buy this logic, and I'm not against a change.   So 2 - 1 for swapping the -x behavior.



Any counter arguments ?

Carter


On Jan 17, 2012, at 9:34 PM, Dave Edelman <dedelman at iname.com<mailto:dedelman at iname.com>> wrote:

   I have to agree with CS Lee. I think the major problem here is that the file contains authentication credentials in clear text. As long as the clients obfuscate this information is provides a false sense of security since it is not obvious that the clear text is stored in the data and is trivially retrievable.



   The logical next step is to craft a client that actually overwrites sensitive data in the argus output files and that can be used inline –w – or  to produce a new file with –w defanged.out





   (You did ask J )



   --Dave



   From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu<mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu> [mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu<mailto:iname.com at lists.andrew.cmu.edu>] On Behalf Of Carter Bullard
   Sent: Tuesday, January 17, 2012 5:15 PM
   To: CS Lee
   Cc: argus-info at lists.andrew.cmu.edu<mailto:argus-info at lists.andrew.cmu.edu>
   Subject: Re: [ARGUS] Argus-info Digest, Vol 77, Issue 14



   Hey CS Lee,

   Not sure that would provide any help to avoid unintentional disclosure.  Default behavior, I think, should provide some protection ?  Any other opinions ?  Seems we have a tie ?

   Best



   Carter





   , CS Lee <geek00l at gmail.com<mailto:geek00l at gmail.com>> wrote:



      hi Carter,



      My thought on this one - the password obfuscation.



      I would rather have default argus client print out the password without -x option, and with -x option it will obfuscate when printing the user data. That way new comers won't be confusing when they first use argus client. Since you already mentioned underlying data won't be changed anyway, so by default argus client should print generic data and with -x option the passwords will be obfuscated.



      Cheers!

      On Wed, Jan 18, 2012 at 1:00 AM, <argus-info-request at lists.andrew.cmu.edu<mailto:argus-info-request at lists.andrew.cmu.edu>> wrote:

      Send Argus-info mailing list submissions to
             argus-info at lists.andrew.cmu.edu<mailto:argus-info at lists.andrew.cmu.edu>

      To subscribe or unsubscribe via the World Wide Web, visit
             https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
      or, via email, send a message with subject or body 'help' to
             argus-info-request at lists.andrew.cmu.edu<mailto:argus-info-request at lists.andrew.cmu.edu>

      You can reach the person managing the list at
             argus-info-owner at lists.andrew.cmu.edu<mailto:argus-info-owner at lists.andrew.cmu.edu>

      When replying, please edit your Subject line so it is more specific
      than "Re: Contents of Argus-info digest..."


      Today's Topics:

        1. Re:  Forced obfuscation in user data? (elof2 at sentor.se<mailto:elof2 at sentor.se>)
        2. Re:  Forced obfuscation in user data? (Carter Bullard)


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

      Message: 1
      Date: Tue, 17 Jan 2012 15:31:27 +0100 (CET)
      From: elof2 at sentor.se<mailto:elof2 at sentor.se>
      Subject: Re: [ARGUS] Forced obfuscation in user data?
      To: Argus Development <argus-info at lists.andrew.cmu.edu<mailto:argus-info at lists.andrew.cmu.edu>>
      Message-ID:
             <alpine.BSF.2.00.1201171530410.75104 at deliverator.sentor.se<mailto:alpine.BSF.2.00.1201171530410.75104 at deliverator.sentor.se>>
      Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

      Sounds great!

      I'm just curious, what passwords (i.e. what protocols and services (or
      patterns?)) will the ra-clients hide?

      FTP passwords obviously.

      /Elof

      On Tue, 17 Jan 2012, Carter Bullard wrote:

      > Hey \Elof2,
      > OK, I fixed the bug so we're consistent in the effort, (replace an ' if ' with a ' while ')
      > and I documented the feature in the rarc.5 man page, and I've documented
      > the -x option in the ra.1 man page.
      >
      > Just a note.  This 'feature' is there simply as a safety, so that the casual
      > user doesn't inadvertently leak captured passwords.  Its not intended as
      > a real protection strategy.   On the contrary, being able to recover clear
      > text passwords is a good security strategy.  Since they are a bad idea,
      > being able to detect them on the wire is the only way to enforce the policy.
      >
      > Thanks !!!!!!!
      >
      > Carter
      >
      > On Jan 17, 2012, at 7:48 AM, Carter Bullard wrote:
      >
      >> Hmmm, thanks, I'll fix that on this next round of clients.
      >> Carter
      >>
      >> On Jan 17, 2012, at 4:29 AM, elof2 at sentor.se<mailto:elof2 at sentor.se> wrote:
      >>
      >>>
      >>> Ah, an undocumented feature.
      >>> -x solved it. Thanks.
      >>>
      >>> BTW, in my logs I found a bunch of plaintext passwords even when not using -x. Apparently you only obfuscate the first PASS in a session.
      >>> In sessions where the first login attempt(s) fail, ra will reveal the password of the second and later attempts.
      >>>
      >>> <- Welcome-banner
      >>> -> USER foo PASS bar1
      >>> <- Login incorrect
      >>> -> USER foo PASS bar!
      >>> <- Login successful
      >>>
      >>> suser data printed by ra (without -x) show:
      >>> s[42]=USER foo..PASS xxxx..USER foo..PASS bar!..
      >>>                    ^^^^                 ^^^^
      >>> while ra -x reveal both passwords:
      >>> s[42]=USER foo..PASS bar1..USER foo..PASS bar!..
      >>>
      >>> /Elof
      >>>
      >>>
      >>> On Mon, 16 Jan 2012, Carter Bullard wrote:
      >>>
      >>>> Hey /Elof,
      >>>> Yes, that was a request.  The obfuscation is done in the ascii printer in the clients.
      >>>> If you use the "-x" option, it will print them out.
      >>>>
      >>>> Carter
      >>>>
      >>>> On Jan 16, 2012, at 11:07 AM, elof2 at sentor.se<mailto:elof2 at sentor.se> wrote:
      >>>>
      >>>>>
      >>>>> I just looked at the suser data in my argus logfile.
      >>>>> It appears that argus is obfuscating the data even though I'm not asking for it.
      >>>>>
      >>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port 21
      >>>>> s[116]=USER myloginname..PASS xxxxxxxxx..CWD /foo/bar..TYPE I..PASV..STOR gazonk.pdf..QUIT..
      >>>>>
      >>>>> The FTP password I entered was "foobar", not "xxxxxxxxx".
      >>>>> Somewhere, all FTP passwords are being obfuscated into "xxxxxxxxx".
      >>>>>
      >>>>>
      >>>>> 1.
      >>>>> Is the obfuscation done in argus (i.e. the logfile never even contain the true password) or is it done in ra?
      >>>>>
      >>>>> 2.
      >>>>> Can this be turned off? I need the true data for evidence.
      >>>>>
      >>>>> 3.
      >>>>> If the obfuscation is performed in argus, won't this introduce a slight performance penalty? ...a few cpu cycles are wasted verifying if the current packet need to be obfuscated, and if so, obfuscate it.
      >>>>>
      >>>>>
      >>>>>
      >>>>> My argus.conf:
      >>>>> ARGUS_MONITOR_ID=1.2.3.4
      >>>>> ARGUS_INTERFACE=mon0
      >>>>> ARGUS_OUTPUT_FILE=/foo/log/out.log
      >>>>> ARGUS_DAEMON=yes
      >>>>> ARGUS_ACCESS_PORT=0
      >>>>> ARGUS_GENERATE_MAC_DATA=yes
      >>>>> ARGUS_CAPTURE_DATA_LEN=120
      >>>>> ARGUS_FILTER=""
      >>>>>
      >>>>> My ra command:
      >>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port 21
      >>>>>
      >>>>> /Elof
      >>>>
      >>>>
      >>
      >
      >


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

      Message: 2
      Date: Tue, 17 Jan 2012 09:36:58 -0500
      From: Carter Bullard <carter at qosient.com<mailto:carter at qosient.com>>
      Subject: Re: [ARGUS] Forced obfuscation in user data?
      To: "Martin Olsson" <martin.olsson at sentor.se<mailto:martin.olsson at sentor.se>>
      Cc: 'Argus Development' <argus-info at lists.andrew.cmu.edu<mailto:argus-info at lists.andrew.cmu.edu>>
      Message-ID: <2FC2A2F9-C20F-4999-B6DD-A31F47D19BC3 at qosient.com<mailto:2FC2A2F9-C20F-4999-B6DD-A31F47D19BC3 at qosient.com>>
      Content-Type: text/plain; charset="us-ascii"

      Oh, the algorithm is trivial, and if there are other situations, I will add.
      We just look for "PASS", and anything that is printable after that, unto
      a '\cr' or a '.', we'll put an 'x' in its place.   (yes not perfect, but fast and
      it works for the most part).

      This is only when we printout the buffer.  We never change the actual
      capture data in the argus record.   As a result, we don't exclude the
      text while you "grep" the buffers.  So you could match a record user buffer,
      because your pattern is in someone's password, and when you go to
      print it out, you may not see it in the output.  Not sure what to do with
      that, but its a side effect of what we're doing.

      Carter


      On Jan 17, 2012, at 9:29 AM, Martin Olsson wrote:

      > Sounds great!
      >
      > I'm just curious, what passwords (i.e. what protocols and services (or
      > patterns?)) will the ra-clients hide?
      >
      > FTP passwords obviously.
      >
      > /Elof
      >
      >> -----Original Message-----
      >> From: Carter Bullard [mailto:carter at qosient.com<mailto:carter at qosient.com>]
      >> Sent: Tuesday, January 17, 2012 3:22 PM
      >> To: elof2 at sentor.se<mailto:elof2 at sentor.se>
      >> Cc: Argus Development
      >> Subject: Re: [ARGUS] Forced obfuscation in user data?
      >>
      >> Hey \Elof2,
      >> OK, I fixed the bug so we're consistent in the effort, (replace an ' if '
      >> with a ' while ')
      >> and I documented the feature in the rarc.5 man page, and I've documented
      >> the -x option in the ra.1 man page.
      >>
      >> Just a note.  This 'feature' is there simply as a safety, so that the
      >> casual
      >> user doesn't inadvertently leak captured passwords.  Its not intended as
      >> a real protection strategy.   On the contrary, being able to recover clear
      >> text passwords is a good security strategy.  Since they are a bad idea,
      >> being able to detect them on the wire is the only way to enforce the
      >> policy.
      >>
      >> Thanks !!!!!!!
      >>
      >> Carter
      >>
      >> On Jan 17, 2012, at 7:48 AM, Carter Bullard wrote:
      >>
      >>> Hmmm, thanks, I'll fix that on this next round of clients.
      >>> Carter
      >>>
      >>> On Jan 17, 2012, at 4:29 AM, elof2 at sentor.se<mailto:elof2 at sentor.se> wrote:
      >>>
      >>>>
      >>>> Ah, an undocumented feature.
      >>>> -x solved it. Thanks.
      >>>>
      >>>> BTW, in my logs I found a bunch of plaintext passwords even when not
      >> using -x. Apparently you only obfuscate the first PASS in a session.
      >>>> In sessions where the first login attempt(s) fail, ra will reveal the
      >> password of the second and later attempts.
      >>>>
      >>>> <- Welcome-banner
      >>>> -> USER foo PASS bar1
      >>>> <- Login incorrect
      >>>> -> USER foo PASS bar!
      >>>> <- Login successful
      >>>>
      >>>> suser data printed by ra (without -x) show:
      >>>> s[42]=USER foo..PASS xxxx..USER foo..PASS bar!..
      >>>>                   ^^^^                 ^^^^
      >>>> while ra -x reveal both passwords:
      >>>> s[42]=USER foo..PASS bar1..USER foo..PASS bar!..
      >>>>
      >>>> /Elof
      >>>>
      >>>>
      >>>> On Mon, 16 Jan 2012, Carter Bullard wrote:
      >>>>
      >>>>> Hey /Elof,
      >>>>> Yes, that was a request.  The obfuscation is done in the ascii printer
      >> in the clients.
      >>>>> If you use the "-x" option, it will print them out.
      >>>>>
      >>>>> Carter
      >>>>>
      >>>>> On Jan 16, 2012, at 11:07 AM, elof2 at sentor.se<mailto:elof2 at sentor.se> wrote:
      >>>>>
      >>>>>>
      >>>>>> I just looked at the suser data in my argus logfile.
      >>>>>> It appears that argus is obfuscating the data even though I'm not
      >> asking for it.
      >>>>>>
      >>>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port 21
      >>>>>> s[116]=USER myloginname..PASS xxxxxxxxx..CWD /foo/bar..TYPE
      >> I..PASV..STOR gazonk.pdf..QUIT..
      >>>>>>
      >>>>>> The FTP password I entered was "foobar", not "xxxxxxxxx".
      >>>>>> Somewhere, all FTP passwords are being obfuscated into "xxxxxxxxx".
      >>>>>>
      >>>>>>
      >>>>>> 1.
      >>>>>> Is the obfuscation done in argus (i.e. the logfile never even contain
      >> the true password) or is it done in ra?
      >>>>>>
      >>>>>> 2.
      >>>>>> Can this be turned off? I need the true data for evidence.
      >>>>>>
      >>>>>> 3.
      >>>>>> If the obfuscation is performed in argus, won't this introduce a
      >> slight performance penalty? ...a few cpu cycles are wasted verifying if
      >> the current packet need to be obfuscated, and if so, obfuscate it.
      >>>>>>
      >>>>>>
      >>>>>>
      >>>>>> My argus.conf:
      >>>>>> ARGUS_MONITOR_ID=1.2.3.4
      >>>>>> ARGUS_INTERFACE=mon0
      >>>>>> ARGUS_OUTPUT_FILE=/foo/log/out.log
      >>>>>> ARGUS_DAEMON=yes
      >>>>>> ARGUS_ACCESS_PORT=0
      >>>>>> ARGUS_GENERATE_MAC_DATA=yes
      >>>>>> ARGUS_CAPTURE_DATA_LEN=120
      >>>>>> ARGUS_FILTER=""
      >>>>>>
      >>>>>> My ra command:
      >>>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port 21
      >>>>>>
      >>>>>> /Elof
      >>>>>
      >>>>>
      >>>
      >

      -------------- next part --------------
      A non-text attachment was scrubbed...
      Name: smime.p7s
      Type: application/pkcs7-signature
      Size: 4367 bytes
      Desc: not available
      Url : https://lists.andrew.cmu.edu/mailman/private/argus-info/attachments/20120117/8e918136/attachment-0001.bin

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

      _______________________________________________
      Argus-info mailing list
      Argus-info at lists.andrew.cmu.edu<mailto:Argus-info at lists.andrew.cmu.edu>
      https://lists.andrew.cmu.edu/mailman/listinfo/argus-info


      End of Argus-info Digest, Vol 77, Issue 14
      ******************************************







      --
      Best Regards,

      CS Lee<geek00L[at]gmail.com<http://gmail.com>>

      http://geek00l.blogspot.com
      http://defcraft.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120118/e682bad9/attachment.html>


More information about the argus mailing list