Security Isssue

[J-GainSec]

Hey, can you just email me at [email protected] and I'll give you the details.

Thanks

[inoda]

Can you just share the details here?

[J-GainSec]

Sure. The issues aren't big.

Issue 1: Weak Password Requirements

The OnTrack application allows extremely weak passwords such as "toor". Below is the exact output demonstrating that the application created a user with a weak password that is also the same as the username.

Loading production environment (Rails 6.1.6) irb(main):001:0> User.create!(username: "toor", password: "toor") D, [2022-06-29T22:55:35.436698 #4] DEBUG -- : TRANSACTION (3.3ms) BEGIN D, [2022-06-29T22:55:35.442076 #4] DEBUG -- : User Create (5.0ms) INSERT INTO "users" ("username", "password", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id" [["username", "$2a$12$DpOrLFhATVwY2.4W7rdXLu.pJyESqE2hb6NpbJLTj9tk4TImvMxWq"], ["password", "$2a$12$Z4zejwEb2wcvJpjw/V9M3.iKsJAyuYdJZoE439AwRYW1UxI1oM3O."], ["created_at", "2022-06-29 22:55:35.432511"], ["updated_at", "2022-06-29 22:55:35.432511"]] D, [2022-06-29T22:55:35.450126 #4] DEBUG -- : TRANSACTION (7.7ms) COMMIT => #<User id: 1, username: "$2a$12$DpOrLFhATVwY2.4W7rdXLu.pJyESqE2hb6NpbJLTj9t...", password: [FILTERED], created_at: "2022-06-29 22:55:35.432511000 +0000", updated_at: "2022-06-29 22:55:35.432511000 +0000", monthly_goal: 0> irb(main):002:0>

Reference: https://cwe.mitre.org/data/definitions/521.html

Issue 2: Use of Password Hash With Insufficient Computational Effort

The username/passwords of the OnTrack application is utilizing Bcrypt (default configuration). Below is in the input/output of running hashcat against the hashed username/passwords.

hashcat -m 3200 -a 0 hashlist wordlist --force

hashcat (v6.2.5-508-g0b27d1f9e) starting

You have enabled --force to bypass dangerous warnings and errors! This can hide serious problems and should only be done when debugging. Do not report hashcat issues encountered when using --force.

Minimum password length supported by kernel: 0 Maximum password length supported by kernel: 72

Hashes: 2 digests; 2 unique digests, 2 unique salts Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates Rules: 1

Optimizers applied:

• Zero-Byte

Watchdog: Temperature abort trigger set to 100c

Host memory required for this attack: 0 MB

Dictionary cache built:

• Filename..: wordlist
• Passwords.: 1
• Bytes.....: 5
• Keyspace..: 1
• Runtime...: 0 secs

The wordlist or mask that you are using is too small. This means that hashcat cannot use the full parallel power of your device(s). Unless you supply more work, your cracking speed will drop. For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

$2a$12$DpOrLFhATVwY2.4W7rdXLu.pJyESqE2hb6NpbJLTj9tk4TImvMxWq:toor $2a$12$Z4zejwEb2wcvJpjw/V9M3.iKsJAyuYdJZoE439AwRYW1UxI1oM3O.:toor

Session..........: hashcat Status...........: Cracked Hash.Mode........: 3200 (bcrypt $2*$, Blowfish (Unix)) Hash.Target......: hashlist Time.Started.....: Thu Jun 30 01:04:45 2022, (1 sec) Time.Estimated...: Thu Jun 30 01:04:46 2022, (0 secs) Kernel.Feature...: Pure Kernel Guess.Base.......: File (wordlist) Guess.Queue......: 1/1 (100.00%) Speed.#2.........: 4 H/s (0.98ms) @ Accel:8 Loops:16 Thr:1 Vec:1 Recovered.Total..: 2/2 (100.00%) Digests, 2/2 (100.00%) Salts Progress.........: 2/2 (100.00%) Rejected.........: 0/2 (0.00%) Restore.Point....: 0/1 (0.00%) Restore.Sub.#2...: Salt:1 Amplifier:0-1 Iteration:4080-4096 Candidate.Engine.: Device Generator Candidates.#2....: toor -> toor Hardware.Mon.SMC.: Fan0: 19%, Fan1: 19% Hardware.Mon.#2..: Temp: 52c

Started: Thu Jun 30 01:04:39 2022

Reference: https://cwe.mitre.org/data/definitions/916.html

Again nothing serious at all. Just wanted to bring to your attention and publish/post about the issues. Do I have permission to do that? Would you like me to wait a week or two so you can implement a fix if you see fit?

[inoda]

Isn't issue 2 just a result of issue 1? Or is there some bcrypt configuration I should be taking advantage of?

[J-GainSec]

Think you can increase the "cost" to mitigate the ease of cracking :

https://www.rubydoc.info/github/codahale/bcrypt-ruby/BCrypt/Password

Class Method Details

Hashes a secret, returning a BCrypt::Password instance. Takes an optional :cost option, which is a logarithmic variable which determines how computational expensive the hash is to calculate (a :cost of 4 is twice as much work as a :cost of 3). The higher the :cost the harder it becomes for attackers to try to guess passwords (even if a copy of your database is stolen), but the slower it is to check users' passwords.

Increasing the password complexity requirements is also ideal ofc.