Forced obfuscation in user data?

[Carter Bullard]

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/ac68e1dd/attachment.bin>