webshell权限

拿到一个webshell，权限不等于拿到了整台服务器。权限很多人以为上传成功就万事大吉，权限实际上权限这关才是权限真正卡人的地方。

去年帮朋友看一个站，权限ThinkPHP的权限站，他通过文件上传漏洞传了个php马上去，权限访问返回200，权限但命令执行不了。权限一看就是权限disable_functions把system、exec这些全禁了。权限这种情况太常见了，权限尤其是权限虚拟主机环境，php.ini里能禁的权限都给你禁干净。他那个马只能读文件、权限写文件，想执行命令？没门。

webshell权限的本质是什么？是web服务进程在操作系统层面的权限。Linux下通常是www-data或者apache，Windows下一般是IIS_IUSRS或者Network Service。这个权限决定了你能干什么、不能干什么。

举个例子。你拿到一个webshell，whoami一看是www-data。想读/etc/shadow？Permission denied。想写/var/www/html以外的目录？大概率也不行。这就是权限边界。很多人拿到shell之后第一反应是提权，但提权之前得先搞清楚当前权限到底能摸到哪些东西。

有个细节容易被忽略：webshell的权限还跟PHP的运行模式有关。mod_php模式下，PHP进程就是Apache进程，权限跟Apache一致。php-fpm模式下，PHP有自己的worker进程池，权限由fpm的配置文件决定。这两种模式下，你webshell能做的事可能完全不同。我见过一个案例，同一个服务器，mod_php的站能读某个目录，php-fpm的站就读不了，因为fpm的pool配置里设了open_basedir。

open_basedir这玩意儿比disable_functions还恶心。disable_functions只是禁函数，open_basedir直接把文件系统访问范围给你圈死了。你webshell只能在你站点目录里活动，想跨目录？PHP层面直接报错。绕过open_basedir的方法不是没有，但大多数需要能执行命令或者有本地文件包含漏洞配合，单纯一个webshell很难突破。

再说Windows。IIS下拿到webshell，whoami一看可能是iis apppool\defaultapppool。这个权限更憋屈，连很多系统目录都读不了。但Windows有个好处，如果站点配置不当，比如给了写权限的目录恰好是网站根目录，你可以直接写个aspx马进去，权限可能就变了——如果新马的应用程序池配置不同的话。

实际渗透中，webshell权限够不够用，取决于你的目标。如果只是想读源码、找数据库配置，www-data权限通常够了。数据库配置文件一般就是644，www-data能读。想连数据库？3306端口如果只监听127.0.0.1，你webshell在本机就能连。想反弹shell？得看能不能执行命令，不能执行命令就得靠PHP的socket函数自己写一个。

我自己的习惯是，拿到webshell先跑几条命令摸清楚情况：whoami、id、uname -a、cat /etc/passwd、ls -la /home、cat /etc/php.ini里的disable_functions和open_basedir。这几条下来，基本就知道这个shell的斤两了。

别小看一个低权限webshell。有时候它比root还管用——比如目标站有内网数据库，你webshell能连，root反而因为防火墙规则连不上。权限这东西，够用就行，不是非得提权到root才算成功。

当然，如果目标是拿下整台服务器，那提权就是绕不过去的坎。但那是另一个话题了。先把手头的webshell权限吃透，比盲目找提权工具实在得多。