排行榜

0x01 thinkadmin historical vulnerability review The background address of the other party's app has been found to be thinkadmin, so we need to review the historical loopholes of thinkadmin. CVE-2020-25540 https://github.com/zoujingli/ThinkAdmin/issues/244 Use POC as follows https://github.com/Schira4396/CVE-2020-25540 Column Directory POST /?s=admin/api.Update/noderules=['runtime/'] file read /?s=admin/api.Update/get/encode/34392q302x2r1b37382p382x2r1b1a1a1b1a1a1b363932382x312t1b The essence is probably to design a function that allows third parties to compare system web files on the server. As a result, any directory is read due to directory traversal. Although there are certain restrictions, the harm is still very, very great, so this function will be removed from the shelves after subsequent updates. There is also a deserialization vulnerability without CVE https://github.com/zoujingli/ThinkAdmin/issues/238 There are two interfaces, one of which is the rule parameter of the directory function listed above. POST /?s=admin/api.Update/noderules=payload The other place is POST /?s=wechat/api.Push/indexreceive=payload 0x02 First source code Because the official no longer provides downloads of the old version of the source code, I immediately went to another place to find an old version of the source code using thinkphp5.1.38. After detection, it has the following vulnerabilities. application/wechat/controller/api/Push.php Only one of the two deserializations was fixed. application/admin/controller/api/Update.php The routes for reading column directories and any files have changed slightly, and the column directories cannot be controlled by passing rules parameters, so they can only list the web root directory. But arbitrary file reading removes various restrictions, which means you can directly read config/database.php to get the database configuration. After obtaining the database configuration, if the database can be connected externally, it can be used more deeply. application/admin/controller/api/Plugs.php This is the file upload interface that thinkadmin comes with. Just like many cms designed, its whitelist storage_local_exts can be configured in the database or system background. Normally, we can use this to perform getshell operations, but it is obvious that if we directly add php to the whitelist, we will not be able to pass the fourth if, and there will also be intercepts in the system configuration in the background. application/admin/controller/Config.php If we operate the database directly, we can bypass the background configuration restrictions, but cannot bypass the upload() restrictions. Obviously, filtering php is not enough. If the other party is a windows server, we still have php:$DATA optional. If the other party is apache and has made the wrong configuration, we also have possible parsing suffixes such as php3/php4/php5/php7/pht/pht/phtml/phar. 0x03 Second source code However, the first source code has no use except being familiar with the thinkadmin architecture. Because the target is thinkphp6.0.3, and the vulnerability is different from the first one, there is no deserialization. However, there are still column directories and file readings, and they are exactly the same as historical vulnerabilities. app/admin/controller/api/Update.php But when listing directories, I encountered a problem. This is because I'm listing the web root directory. If the other party's project is huge, or a folder does not have permission, it will cause an error. At this time, you need to list the directory in a targeted manner, mainly ./app and ./runtime. Read ./app to get the controller path. In the original thinkadmin, there are not many breakthroughs, but many of these programs are opened in the second place. Compared with the controllers that do not have in the original thinkadmin, you may directly audit the vulnerabilities. Audit vulnerabilities need to be read with any file. Please review the previous one for details. In short, with CVE-2020-25540 we are equivalent to obtaining its source code. This program is easy to find a SQL injection. /app/admin/controller/api/Main.php However, after I invoked the password, I found that login required OTP verification, so I could not continue the audit. /app/admin/controller/Posting.php Very stupid command splicing, there are three places in the same location, but all require background permissions. In the end, it was found that exec() was disabled_functions, so it cannot be used. /app/admin/controller/api/Upload.php The last place was discovered by a friend’s reminder. At first glance, isn’t this a upload brought by thinkadmin? I have analyzed before that a specific environment is needed to utilize it, so I skipped it directly. As a result, there is an extra xkey parameter that can completely control $this-name. It is hard not to suspect that this is a backdoor. In the end, getshell is like this. But this upload interface also requires background permissions, what should I do? At this time, it is the turn of thinkphp, which is often used by ./runtime, to appear. Reading the file runtime/admin/log/single_error.log is easy to find that it records a series of session errors. And we can know that this program uses the original php session, and it is not placed in /tmp or /var/lib/php/sessions/, but runtime/session. That's simple. We directly use the column directory to list all sessions and then blast them. In this way, you can directly enter the background and bypass the OTP limit. Then use its xkey backdoor getshell. 0x04 Alternative mind What if there is no back door? This system is linux+nginx, and it cannot bypass the original upload limit of thinkadmin. But in the subsequent code audit, I found that it has a graph bed server. This getshell server (A) can access an interface of the graph bed server (B) with the file_paths parameter. The purpose is to allow server B to download the pictures on server A in turn and backup them. Why do I know this? Because Server B is even more riddled with holes, you will find out by directly accessing this interface. Not only does the source code leak because of debug, but the splicing of this command is too naked, and it can even be used as a shell. Therefore, we can completely take down Server B directly through arbitrary file reading and code audit without taking down Server A. What's the use of getting server B? Server A will use curl to request Server B. In this case, you can tamper with the code of Server B, change the interface to 302 and jump, and then modify the protocol to gopher, and you can hit the local port of Server A. If the FPM 9000 port and the 6379 port of Redis are present locally on Server A, SSRF getshell can be performed in this way. This case can often be exploited in the SSRF vulnerability of Discuz. Although there is no 9000 fpm this time, there is redis. The redis key and port are also stored in config/cache.php, and the web directory happens to have 777 permissions, which fully meets the conditions for gopher to hit local redis. Of course, I didn't try it in the end, but there was no problem in theory. Reprinted from the original link: https://mp.weixin.qq.com/s/BuHJuQh3lyaq1SmY2xKl3g