Emlog automatic backup plug-in leakage full-Site Database Backup Vulnerability

Emlog automatic backup plug-in leakage full-Site Database Backup Vulnerability

This is the third time I found a critical vulnerability in my blog. The first time is a third-party storage, the solution is deleted. The second is "EMLOG album", that is, this article: https://www.leavesongs.com/penetration/emlog-important-plugin-getshell.html. This is the third time. I wrote a script to directly download the full-site backup file of my blog, including the administrator password.

The vulnerability is caused by this plug-in: http://www.emlog.net/plugin/14. Its id is 14, which is also an early plug-in for emlog. The author is Keller, the main version of emlog.

Let's talk about the cause of the vulnerability.

This plug-in is used for automatic backup. It places an ajax control on the front end and requests a plug-in every time the user accesses the file. The plug-in checks the time of the last backup file. If the time interval exceeds a certain value, it backs up the file again. This method achieves "automatic backup.

Check the code. kl_auto_backup_and_mail_do.php is the file requested by ajax and has no permission restrictions.

01 $ is_reproduct = false; 02 echo KL_AUTO_BACKUP_AND_MAIL_THE_TIME. "\ n"; 03 if (KL_AUTO_BACKUP_AND_MAIL_LAST_BACKUP_FILE! = ''& File_exists (duration) 04 {05 $ delay_time = time ()-filemtime (duration); 06 if ($ delay_time> intval (KL_AUTO_BACKUP_AND_MAIL_THE_TIME )) $ is_reproduct = true; 07 echo $ delay_time; 08} else {09 $ is_reproduct = true; 10}

$ Is_reproduct indicates whether to back up data. KL_AUTO_BACKUP_AND_MAIL_THE_TIME indicates the critical time, And KL_AUTO_BACKUP_AND_MAIL_LAST_BACKUP_FILE indicates the name of the last backup file.

If KL_AUTO_BACKUP_AND_MAIL_LAST_BACKUP_FILE exists, enter the if statement. Determine whether the difference between the current time and the last backup time is greater than the critical time. If the difference is greater than the critical time, set $ is_reproduct to true. $ Delay_time is output.

$ Delay_time is a very important value, which represents the difference between the "current time" and the "Creation Time" of the last backup file. We know the "current time". With the $ delay_time output here, we can calculate the creation time of the last backup file.

This time is very important and will be used later.

Check the code later:

If $ is_reproduct is true, enter the if statement and delete the last backup file (strictly speaking, the last backup file, which does not affect the subsequent vulnerability exploitation process ). Then it calculates the time as a file name and writes all the database data into the file.

In the final analysis, the file name is exactly the same as the timestamp. In turn, as long as you know the file creation time, you can roll out the file name.

Through the previous analysis, we can get the creation time of the last backup file, so we can actually release the file name.

In this case, the vulnerability "the backup file name can be accurately calculated" causes full-Site Database Backup leakage.

However, there are several vulnerabilities that are unstable:

1. when a backup file is created, the current computing time is not necessarily the same as the mtime of the last file created in linux, because the execution of SQL statements in the middle has delayed some time, therefore, the file name time may not be accurately predicted, but the gap may not be too large, just a second or two.

2. Some time is consumed during http transmission. As a result, the obtained now time is not necessarily the same as the time () obtained on the server, and there is a certain error.

 

3. Our time zone is not necessarily the same as the time zone of the website server. We do not know how to set the time zone on the website server, so we need to try it one by one.

These three unstable locations cause our POC to run for dozens or hundreds of times to find the final backup file. However, the running cost is very low and the stress on attackers is not great, acceptable.

Keller did not know why he didn't run out of the file, but I flipped through the emlog forum and found three victims:

The tool ran almost 50 times and ran the final backup file:

This hole is still a zero-day vulnerability. Although the impact is limited, it is very powerful. You can get the whole site database, which deserves attention.

Solution:

1. Temporarily Delete the plug-in

2. Server/WAF intercepts all requests suffixed with. SQL.

3. Change $ defname to a random string, for example:

1/* 2 * getRandStr is a built-in random string generation function of emlog. This problem can be avoided by using random strings. 3 */4 $ defname = 'emlog _'. gmdate ('ymd', time () + $ timezone * 3600 ). '_'. substr (md5 (getRandStr (), 0, 18 );