naveeeeeeeeeen
commented
50 minutes ago I have resolved this bug. Now we are no longer using the hard-coded key, We are now hashing the password for authentication. Now the log entries are encrypted and decrypted using PBKDF2. Only those who know the password can now encrypt and decrypt log entries. No secret key is used. ( The one present is a dummy )
Security Bug: Hardcoded Encryption Key and Vulnerable Key Retrieval and Storage Mechanism
Description:
The current code contains a critical security flaw where the encryption key is hardcoded in the source code and is shared across all log files. Although a separate key retrieval mechanism has been implemented, it is not utilized effectively since the hardcoded key takes precedence and overwrites the retrieved key.
Even if the key retrieval mechanism is used, it fetches the key from a secret.key file, which is easily accessible, exposing the system to security risks. An attacker could access the file and decrypt the logs. Furthermore, since the _authtoken(stored as the first line of the log file) is the encrypted version of the correct token using the same secret key, an attacker can retrieve the token, allowing them to bypass authentication checks and potentially exploit the log append and read functionalities.
Steps to break the Security
Decryption of log file without knowing the token
As you can see in the above image, only these few lines of code can give the decrypted log entries even without the knowing the token since the key is hardcoded and can be retrieved easily from source code.
Lets assume if we use the load_key() function to retrieve the key and the hardcoded key is not used , then also the above code can be used just that we will use the following function to get the key since it is stored in the secret.key file which is easily accessible:
Finding token for any existing logfile
Bug Type: Security Bug Concerned Group: Group-2 Bug Reported by : Pranjal (21110160)