Hello there,
So recently I’ve been taking to @CVEnew on Twitter to monitor newly releasing CVEs, and something caught my eye was:
“CVE-2020-7241 The WP Database Backup plugin through 5.5 for WordPress stores downloads by default locally in the directory wp-content/uploads/db-backup/. This might allow attackers to read ZIP archives by guessing random ID numbers, guessing date string…”
Now, I do static analysis on WordPress plugins often as I find I can audit plugins really fast, as I’ve done extensive PHP development over my career. But the Github describing this vulnerability struck me as whaaaat?..
https://github.com/V1n1v131r4/Exploiting-WP-Database-Backup-WordPress-Plugin/blob/master/README.md
They make the following claim:
“This plugin stores downloads by default locally in the directory wp-content/uploads/db-backup/ with this syntax:
[Site_Title]_[Date with EPOC]_[7 characters random ID]_wpdb.zip”
So to me the first thing that I notice is the UNIX timestamp and the 7 random characters are in the filename, this is actually a huge key-space to brute force!
The key-space for a 7 random digit id with charset [a-f0-9] is 268,435,456. Plus you need to brute the exact second the database backup happens, then for every second in a day (86400) you brute you have to multiply that by 268,435,456! Thats assuming you know which day the backup happened.
We’re looking at the following statistics in order to recover a database backup:
Key-space: 268,435,456
Seconds in a day: 86,400
Total requests needed to brute: (268,435,456 x 86,400) = 23,192,823,398,400
So even if we had a multi-threaded brute forcer of 100 reqs/s that would take 231,928,233,984 seconds to brute force or 7,354 years.
So while the storage method isn’t the best I think its a bit of a stretch to say that this is a security vulnerability, if I came across this during a Bug Bounty program I don’t think there would be a way for me to prove any impact. Am I wrong? Let me on Twitter: https://twitter.com/zeroauth
EDIT: Had to adjust math, the random digit charset is actually [a-f0-9] since its a truncated MD5 of the WordPress AUTH_KEY salt.
Happy Bug Hunting 😁