ecaudit does not obfuscate passwords in audit logs with multi-line or failed queries under certain circumstances

[smiklosovic]

We have identified a bug in ecaudit where passwords are not obfuscated for the following situations:

• Multi line queries
• Failed queries

This results in plain text passwords being logged on the node and shipped to the audit logging elastic search cluster.

To Reproduce

• Create a cluster
• run the following query

CREATE ROLE testrole
WITH login = true
AND password = 'supersecretpassword';

password supersecretpassword will appear in the logs in plain text

The Cause

This mostly stems from the use of incorrect regex used in ecaudit (see

ecaudit/ecaudit/src/main/java/com/ericsson/bss/cassandra/ecaudit/obfuscator/PasswordObfuscator.java

Lines 40 to 43 in 2079a07

	private final static Pattern QUERY_CREATE_ALTER_USER_PATTERN =
	Pattern.compile(".*password\\s+'(?<password>[^\\s]+)'.*", Pattern.CASE_INSENSITIVE);
	private final static Pattern QUERY_CREATE_ALTER_ROLE_PATTERN =
	Pattern.compile(".*password\\s*=\\s*'(?<password>[^\\s]+)'.*", Pattern.CASE_INSENSITIVE);

). The above regex does not match newline characters correctly. I have not looked into the failed request handling.

[emolsson]

Thank you for the report, I'll try to get a PR up for it soon!

[eperott]

Thanks for reporting this @smiklosovic. Closing this ticket now.

A new release is coming up. Just want to get some other things merged first.

[smiklosovic]

Hi, @emolsson and @eperott

we wanted to implement the same approach in Cassandra 4 but more we were testing it, more problems we found :) Do not take me wrong, your approach does work but I am afraid it is not bullet-proof.

Everything is in this ticket https://issues.apache.org/jira/browse/CASSANDRA-16669

For example, you can have a batch statement with multiple statements which are setting passwords. Even such a batch statement is invalid, what we found is that it will be logged but the second password will not be obfuscated.

We were trying to figure out some "super regexp" but we were afraid that this might fail too and we do not catch all cases so what we did is that we took the approach of Postgres and they are obfuscating everything after password keyword. Simple (and brutal) as that.

The ideal solution in Cassandra, would be to parse a statement via antlr and somehow retrieve these passwords from there or reverse-build cql into Java objects / statements and get passwords somehow from there programmatically and obfuscate just that one but that solution appeared to be even more time consuming and complex so close to 4.0 release so we just made it simple stupid.

I am not sure our findings relate to you 100% but I would like to reiterate the fact that there are some cornercases in ecaudit which will probably leak passwords too. Please double check.

[eperott]

Thanks for the feedback @smiklosovic. I've created #180 to follow up on this.