No edit summary |
No edit summary |
||
| Line 21: | Line 21: | ||
As some of you might've heard, we discovered a security issue earlier today and asked users to update immediately. We apologize for the inconvenience this has caused. | As some of you might've heard, we discovered a security issue earlier today and asked users to update immediately. We apologize for the inconvenience this has caused. | ||
== What happened? == | === What happened? === | ||
Earlier today, we became aware that when a user logs into Resonite by typing their credentials and the login succeeds, the user's login token ends up written to the log file. If this log file is then shared with anyone by that user, it can be abused to get access to the user's account under certain conditions. | Earlier today, we became aware that when a user logs into Resonite by typing their credentials and the login succeeds, the user's login token ends up written to the log file. If this log file is then shared with anyone by that user, it can be abused to get access to the user's account under certain conditions. | ||
==Why did this happen?== | ===Why did this happen?=== | ||
The original goal was to log in just basic information about the login process - mostly the server response status. However at some point we have extended the diagnostic to print out the entire entities coming from the cloud (this includes a number of entities that do not contain sensitive data as this), which affected the login entity, exposing its internal data by accident. | The original goal was to log in just basic information about the login process - mostly the server response status. However at some point we have extended the diagnostic to print out the entire entities coming from the cloud (this includes a number of entities that do not contain sensitive data as this), which affected the login entity, exposing its internal data by accident. | ||
==Who did this affect?== | ===Who did this affect?=== | ||
The session token system is designed to limit their lifetime and usability, to minimize the impact of accidental leaks like this. The tokens are made to be short lived if possible and will be invalidated in following conditions: | The session token system is designed to limit their lifetime and usability, to minimize the impact of accidental leaks like this. The tokens are made to be short lived if possible and will be invalidated in following conditions: | ||
* When user explicitly logs in from the same machine | * When user explicitly logs in from the same machine | ||
| Line 38: | Line 38: | ||
* You have not started the client again since logging in | * You have not started the client again since logging in | ||
== Was there a cloud data breach?== | === Was there a cloud data breach?=== | ||
No. | No. | ||
| Line 45: | Line 45: | ||
Additionally we do not store the actual session tokens on our cloud - instead we store a salted hash of those tokens. As a result, even in the event of a data breach on the cloud where the session information would get leaked, an attacker would be unable to use this data to access your account. | Additionally we do not store the actual session tokens on our cloud - instead we store a salted hash of those tokens. As a result, even in the event of a data breach on the cloud where the session information would get leaked, an attacker would be unable to use this data to access your account. | ||
== What did we do to resolve this issue? == | === What did we do to resolve this issue? === | ||
We have published a new client which removes the logging from the login process and requested that any online users update immediately. | We have published a new client which removes the logging from the login process and requested that any online users update immediately. | ||
| Line 52: | Line 52: | ||
Users who have had “Remember Me” turned on and have restarted the client at least once were not affected, since the potentially leaked session token from login was already removed from the database by the subsequent launches of the client. | Users who have had “Remember Me” turned on and have restarted the client at least once were not affected, since the potentially leaked session token from login was already removed from the database by the subsequent launches of the client. | ||
== What are we doing to prevent this in the future? == | === What are we doing to prevent this in the future? === | ||
To ensure that similar mistakes do not happen again, we’re making a few modifications to the system to tighten its security: | To ensure that similar mistakes do not happen again, we’re making a few modifications to the system to tighten its security: | ||
* Mark sensitive cloud entities and prevent them from being logged for diagnostics | * Mark sensitive cloud entities and prevent them from being logged for diagnostics | ||
Revision as of 07:16, 28 January 2024
Beta 2024.1.27.608 is a Resonite version released on 2024/01/27.
It is compatible with the previous build, Beta 2024.1.26.617.
The following notes were sent by Frooxius:
- This build fixes a security issue. To ensure you're not affected, please update to this version immediately if you're currently running older version.
- Details will come soon!
- Compatible with current.
Security:
- Fixed a security issue reported by @Stiefel and @ProbablePrime - details will come soon
Security Write-Up
Froox followed up this update with a security write-up on the incident. It is copied here from Discord.
Hello everyone!
As some of you might've heard, we discovered a security issue earlier today and asked users to update immediately. We apologize for the inconvenience this has caused.
What happened?
Earlier today, we became aware that when a user logs into Resonite by typing their credentials and the login succeeds, the user's login token ends up written to the log file. If this log file is then shared with anyone by that user, it can be abused to get access to the user's account under certain conditions.
Why did this happen?
The original goal was to log in just basic information about the login process - mostly the server response status. However at some point we have extended the diagnostic to print out the entire entities coming from the cloud (this includes a number of entities that do not contain sensitive data as this), which affected the login entity, exposing its internal data by accident.
Who did this affect?
The session token system is designed to limit their lifetime and usability, to minimize the impact of accidental leaks like this. The tokens are made to be short lived if possible and will be invalidated in following conditions:
- When user explicitly logs in from the same machine
- When user checks “Remember Me” and starts their client again
- The token expires (1 day without “Remember Me” and 30 days with “Remember Me”)
Given this mechanism, you would’ve been potentially affected by this given you meet the following conditions:
- You have shared a log file from a client session where you logged in by typing your credentials (username/email and password)
- You have not logged in again on the same machine manually
- You have not started the client again since logging in
Was there a cloud data breach?
No.
The only way the tokens leaked is by users sharing a log from their own machine from when they logged in.
Additionally we do not store the actual session tokens on our cloud - instead we store a salted hash of those tokens. As a result, even in the event of a data breach on the cloud where the session information would get leaked, an attacker would be unable to use this data to access your account.
What did we do to resolve this issue?
We have published a new client which removes the logging from the login process and requested that any online users update immediately.
Roughly 10 minutes following this, we have cleared any existing sessions in the database that only had a single login (meaning they were the original login session, which would be vulnerable).
Users who have had “Remember Me” turned on and have restarted the client at least once were not affected, since the potentially leaked session token from login was already removed from the database by the subsequent launches of the client.
What are we doing to prevent this in the future?
To ensure that similar mistakes do not happen again, we’re making a few modifications to the system to tighten its security:
- Mark sensitive cloud entities and prevent them from being logged for diagnostics
- Entities containing the session token are now marked as such. The diagnostic systems respect this mark and will not print out their contents
- This prevents situations where we would accidentally end up printing out the entity to the log from revealing the sensitive information again
- Extending long running sessions will regenerate token at regular intervals
- For long running clients (e.g. headless), the original login token would be kept and its lifetime would be extended continuously for weeks or even months (depending on when restart occurs), but the token would remain same, allowing it to be potentially exploited if it’s leaked
- From now on, the token will be regenerated and the previous one invalidated at regular intervals - this is currently every day. As a result the potential window for exploitation of a given token is now much shorter for long running sessions
- Validating user’s secret machine ID
- Each instance of the client generates a unique secret machine ID which is used to identify that machine. This is used to differentiate multiple sessions from multiple machines / installs
- From now on, in addition to validating the token itself, the secret machine ID is used to ensure that the client trying to access the account is the same one as that originally logged in
- In case the session token ends up leaking, it will be insufficient to access the user's account without also knowing the secret machine ID. This would require both pieces of information to leak
- Note: This is different from the user’s “Machine ID” which is used to identity user’s machine to other users