Argus-info Digest, Vol 77, Issue 14
Jason Carr
jcarr at andrew.cmu.edu
Thu Jan 19 11:14:07 EST 2012
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
>
More information about the argus
mailing list