Argus-info Digest, Vol 77, Issue 14

Chas DiFatta chas at difatta.org
Thu Jan 19 11:37:18 EST 2012 

I second Jason's comment.  Client apps like rastrip and ranonymize can easily accommodate the functionality of the flow analysis workflow.

There "might" be a need for yet another experimental client called "rased" or "raregex" who's functionality is obvious.

Even without capturing any of the user/application data, what one can discover/imply can be a real eye opener as we all know, and therefore requires anyone using Argus data to take a serious look at the data management policy of their organization, which includes data orchestration methods.

	...cd

On Jan 19, 2012, at 11:14 AM, Jason Carr wrote:

> I'd vote for swapping the behavior or eliminating the feature all
> together.  I tend to want the user data in an untouched state.  If I need
> to display or share data, I will manually hide the credentials or
> sensitive data.
> 
> On 1/18/12 6:58 PM, "Carter Bullard" <carter at qosient.com> wrote:
> 
>> OK, the count is now  2 - 2.  The issue is valid, that we should not set
>> incorrect expectations.  We could print a warning to stderr, that ra.1
>> obfuscated content?
>> 
>> Carter
>> 
>> 
>> On Jan 18, 2012, at 6:21 AM, elof2 at sentor.se wrote:
>> 
>>> 
>>> First I thought like CS Lee, that it was backwards to obfuscate without
>>> asking for it on the commandline. That's why I reported it to the list
>>> in the first place.
>>> 
>>> Though, once Carter explained that the default was to obfuscate, to
>>> protect and prevent from accidental copy and paste of sensitive data
>>> into e.g. an email, I changed my mind.
>>> That is a cheap and simple protection from human mistakes that can get
>>> really embarrising/awkward if one paste the wrong data to e.g. a
>>> mailinglist.
>>> 
>>> So I vote for the Carter approach. Obfuscate in the clients by default
>>> and use -x to reveal the real data.
>>> 
>>> The real problem is that this was an undocumented feature. Once it's a
>>> known default (the new man pages), I only see benefits with the default
>>> obfuscation.
>>> 
>>> 
>>> Regarding that there are sensitive data in the binary argus file... It
>>> contain so much sensitive data that I always treat it as highly
>>> sensitive.
>>> I would think three or four times before sending an argus-logfile to
>>> e.g. a mailinglist, while a simple copy and paste of some ra output
>>> could possibly slip by.
>>> 
>>> /Elof
>>> 
>>> 
>>> On Tue, 17 Jan 2012, Carter Bullard wrote:
>>> 
>>>> 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> 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] On
>>>>> Behalf Of Carter Bullard
>>>>> Sent: Tuesday, January 17, 2012 5:15 PM
>>>>> To: CS Lee
>>>>> Cc: 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> 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> wrote:
>>>>> Send Argus-info mailing list submissions to
>>>>>      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
>>>>> 
>>>>> You can reach the person managing the list at
>>>>>      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)
>>>>> 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
>>>>> Subject: Re: [ARGUS] Forced obfuscation in user data?
>>>>> To: Argus Development <argus-info at lists.andrew.cmu.edu>
>>>>> Message-ID:
>>>>>      <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 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 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>
>>>>> Subject: Re: [ARGUS] Forced obfuscation in user data?
>>>>> To: "Martin Olsson" <martin.olsson at sentor.se>
>>>>> Cc: 'Argus Development' <argus-info at lists.andrew.cmu.edu>
>>>>> Message-ID: <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]
>>>>>>> Sent: Tuesday, January 17, 2012 3:22 PM
>>>>>>> To: 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 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 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/201
>>>>> 20117/8e918136/attachment-0001.bin
>>>>> 
>>>>> ------------------------------
>>>>> 
>>>>> _______________________________________________
>>>>> Argus-info mailing list
>>>>> 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://geek00l.blogspot.com
>>>>> http://defcraft.net
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4363 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120119/e45251c6/attachment.bin>

More information about the argus mailing list