Teach you how to use Log backup to get Webshell

The Blog was penetrated by someone, I wonder if you have lost anything. It turned out that there was a blog directory that could be listed. That time I dropped a small thing, and today someone told me that NBSI 3 used that thing method... Haha, it was a little dizzy, it was the one below, and the success rate was still very high, you can try it. Well, it doesn’t matter if the method is leaked, keep the article. It should not be difficult for dbowner to obtain a shell through injection. What is more troublesome is that even if you use incremental backups, there are still many uncertain factors. If someone has any errors in writing information before, the backup may still get some unusable 500 errors. How can it improve the success rate and reusability? If we only look at the method of adjusting incremental backup, although some effects can be achieved, the method is relatively complex and the effect is not obvious. With considerations about reusability, such as the success rate of multiple backups, the backup database method is not very applicable. What we will talk about here is another backup method, exporting the log file to the web directory to obtain the shell. The rice must be eaten one by one, and technical problems must be solved one by one. To get the webshell, you must first know the physical path before you can talk about other things. There are many ways to expose physical paths, and injection can also be obtained. Nbsi2 has done this, so I won’t say much more. It is worth noting that if the database and the web are separated, you will definitely not get a webshell. The backup stuff can overwrite any file. Some ideas about the start menu are still valid, just pay attention to the extension. It's a long way to go. Anyway, if the database and the web are on the same page, you will have a chance. Otherwise, you should think of other ways. Then you want to get the current permissions and database name. If it is sysadmin, of course there is no need to do very complicated things. Dbowner is enough, but public is not possible. The currently opened library name can be obtained by using db_name(), which is also very simple. The default situation is that the database failure restore type generally selected is simple, and log files cannot be backed up at this time. However, we are all dbowners, so what else can't be done? Just modify the properties. Since you cannot modify it in the enterprise manager, you can only use a piece of SQL statement, which is very simple, so you can: alter database XXXX set RECOVERY FULL  where XXXX is the name of the database you get, and you can back up the log after execution. This modification is destructive because you don't know what the previous failure recovery mode was. Careful administrators may start to suspicion when they see something strange. If you can get the status of the database before, it is best to change the properties of the database back after the backup. The rest is how to let the database record your data in the most primitive way. This corresponds to the problem of setting the table name image in backup database. If you just create a table like this, the records in the log are still recorded in a loose format, that is, < % %>, without any effect. Through actual testing, I found that it can still be recorded in a similar way as backup database, as follows: create table cmd (a image) insert into cmd (a) values ('') backup log XXXX to disk = 'c:\xxx\' In this way you have already got a webshell. Is it over here? No, haha, let's continue. There are two branch directions here. The first is to prevent single quotes from appearing during injection. It is too simple and I am too lazy to write; the second is to reduce the length of this webshell and improve the success rate. The following method is to discuss the second branch issue, which is also applicable to the reduction of backup database. The first is to initialize this log. backup log XXXX to disk = 'c:\caonima' with init This is a bit similar to the first step of incremental backup, but the difference is that after you do this, the available shells you back up are fixed. This is more important because with this step, no matter what the administrator does in the database disrupts your back database, or how many bastards you have (you will definitely think so) and get something you don't like. Even after you do it, others will succeed in following your method later. This will be of great help to occasional recurrences, such as reinstalling the other party's machine but the database and code have not changed. Then adjust the order of each statement in the backup. Through the first point, the general steps have been determined, that is: alter database XXXX set RECOVERY FULL backup log XXXX to disk = 'c:\Sammy' with init create table cmd (a image) insert into cmd (a) values ('') backup log XXXX to disk = 'c:\xxx\' This is not good, I feel like there is one more useless thing. create table cmd (a image) It’s really a bit annoying, but this sentence is necessary, so I had to adjust the position and get it to another place. The order of changing seems to be smaller. It is also OK for the incremental situation in backup database. Backup database can even be backed up immediately after update. However, since the data storage format is involved, the situation is very complicated and will not be discussed here. The adjusted one is: alter database XXXX set RECOVERY FULL create table cmd (a image) backup log XXXX to disk = 'c:\Sammy' with init insert into cmd (a) values ('') backup log XXXX to disk = 'c:\xxx\' If it is successful, the backed-up shell (the one above) has 78.5k, and the file length is fixed at 80,384 bytes. It’s also acceptable for very picky friends. Of course, it’s also OK to use this to generate a clean * - this is originally the S-end of the top Cs *, which is very general.

Latest Comments