Forced obfuscation in user data?
Carter Bullard
carter at qosient.com
Tue Jan 17 09:36:58 EST 2012
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://pairlist1.pair.net/pipermail/argus/attachments/20120117/8e918136/attachment.bin>
More information about the argus
mailing list