↓Skip to main content
  1. Posts/

My First CVE, and the Dangers of Over-Logging

·4 mins
Ixonae
Security Research Reverse Engineering Vulnerabilities
Ixonae
Author
Ixonae
Table of Contents

As I recently filed my first CVE (CVE-2023-22481 - Sensitive Information Disclosure in FreshRSS Log Files), I wanted to take the opportunity to write a few words about what I found, what problems over-logging may have caused in this case, and what some of the best logging practices are.

What I found
#

I recently started using FreshRSS (great software, totally recommend) and decided to install a mobile application so that I could read everything from my phone. After installing the application, I tried to log in with my username and password, but the access was denied. I happened to have an SSH console open on my server, so I followed the logs and discovered the following:

    [_POST] => Array
        (
            [Email] => MyUserName
            [Passwd] => MyPassword
        )

    [_COOKIE] => Array
        (
        )

    [INPUT] => Email=MyUserName&Passwd=MyPassword

“Hold on,” I thought. “That looks a lot like my password in there 😱.” I then downloaded the source code and had a look at what was happening when using the API. The following snippet is what I found:

if user exists:
  if user configuration is missing:
     log the error and dump the request's headers, get, post, and cookie values
  if password is correct:
    accept login
  else if password is incorrect:
    log the error and dump the request's headers, get, post, and cookie values
else if user does not exist:
  log the error and dump the request's headers, get, post, and cookie values

Basically, if authentication failed, all the data in the HTTP login request was logged to the software’s log file and to syslog.

Note that why the pseudo-code says password, what was expected was an API key (the user password can only be used with the UI).

What could be the impact?
#

If the software was running in production with multiple users, the following could have happened:

  • A user enters the wrong username and API key
  • A user accidentally enters a username and password that they use for another service
  • A user enters their username and account password (as opposed to the expected API key)
  • A user enters a valid username and API key, but for some reason, their configuration file can’t be read when they try to log in

If a malicious user then exploits a bug that allows them to read the log file (note that syslog is accessible to all users by default), they could do the following:

  • Use the password to log in to the software as the user (the user’s private data is compromised; gives more attack surface)
  • Use the login and password to do some credential stuffing and possibly gain access to other accounts owned by the user

Good logging practices (in brief)
#

Logging is something that you want to have in your systems. Not only it can help you troubleshoot any issue experienced by the systems/users, but it can also assist in investigating security incidents.

However, too much logging can be an issue as well. Too detailed logs can introduce various risks such as security (as we saw in the previous example) or legal ones.

As a rule of thumb, you should never log any data such as passwords, API keys, PII (for example health data, credit card numbers, official ID numbers,) data of a higher security classification than the logging system is allowed to store, … What you can (or should) log also depend on the regulations and standards you are subject to (for example GDPR, PCI DSS, HIPAA.)

While you should avoid logging too much event data (e.g. the full content of HTTP requests), you still need to log all events that are relevant to your system. For example (but not limited to)

  • Data validation failure
  • User authentication (failure and success)
  • Authorization failures
  • System change of state (application starting, stopping, …)
  • Sensitive data access and data change
  • Use of privileged access (adding new users, changing passwords, …)
  • Application and system failures and errors
  • Data export

When logging such things, you want to answer the questions “Who? When? Where? What?”. You might also want to include additional information depending on what you are logging (for example, a Java exception if a program fails.)

An example of logs for our previous situation could be [IP] [Date] Authentification failed for username [username] : wrong password

In short, you want to think: “If an incident occurs, are my logs sufficient to allow me to find the cause and understand what happened just by looking at them?”

Conclusion
#

Logging is a vast subject, and a blog post wouldn’t be enough to say everything there is to say, but if you want to learn more about logging, OWASP has a very nice and detailed cheat sheet. The Practical Monitoring book I mentioned here is also a great resource.

Some things that are worth mentioning as well when speaking of logging are the $$$ cost of logging too much data and the risk of logging unsanitized data (log4j.)

Credit
#