记事狗微博系统，后台存在设计缺陷，可导致进入后台者获得shell 版本：V3.6.1 Build 20120718 1.系统工具->数据备份->自定义备份->选择一张数据量较小的表->更多选项->选择压缩备份文件->多分卷压缩成一个文件。 直接提交。 2.直接把备份文件 下载 下来，然后往备份文件添加一个zzz.php.sql，内容为<?php phpinfo();?> 3.然后找一张正常的图片 执行cat yy520.zip >> yy520.png ，前台提交yy520.png 4.获取图片的地址images/topic/6/17/14_o.jpg，回到后台 系统工具->数据恢复 点击解压缩，用burp suite 截包 修改为：datafile_server=./images/topic/6/17/14_o.jpg 最后访问 最后的最后，请让我解释一下，为什么上面会有那么多2b的步骤。 1. $datafile_server = get_param('datafile_server'); 。。。。。 $unzip->ReadFile($datafile_server); if($unzip->Count() == 0 || $unzip->GetError(0) != 0 || !preg_match("/\.sql$/i", $importfile = $unzip->GetName(0))) { $this->Messager('数据文件不存在: 可能服务器不允许上传文件或尺寸超过限制。',null); } 由于上面preg_match的限制，在压缩文件里面的文件名必须是以sql结尾，这个可以用apache解析绕过，所以我们的文件名必须是***.php.sql 2. $identify = explode(',', base64_decode(preg_replace("/^# Identify:\s*(\w+).*/s", "\\1", substr($unzip->GetData(0), 0, 256)))); $confirm = !empty($confirm) ? 1 : 0; if(!$confirm && $identify[1] !=SYS_VERSION) { 。。。。反正就不是解压的操作 } 在进行导入的时候它会查看压缩包的第一个文件的头部，然后决定是直接导入，还是先解压，所以我们需要一个正常的备份文件，也就是那个yy520-1.sql 才会执行下面 $sqlfilecount = 0; foreach($unzip->Entries as $entry) { if(preg_match("/\.sql$/i", $entry->Name)) { $len = Load::lib('io', 1)->WriteFile('./data/backup/'.$backupdir.'/'.$entry->Name, $entry->Data); $sqlfilecount++; } } 3. 然后我就屁颠屁颠的跑前台上传zip文件，后来我发现上传后的zip文件路径是记录在 数据库 中，路径是由一个 mysql _insert_id 来随机生成滴，本来想暴力破，直接提交乌云，敷衍了事，后来想想意义不大。然后发现$unzip->ReadFile($datafile_server);可以读取jpg的，然后就把那个zip文件直接改为jpg上传，提示错误（不是一个有效的图片），看了代码 HdhCmsTest2cto测试数据 if(function_exists('exif_imagetype') && !exif_imagetype($temp)) { $this->_setError(507); return false; } elseif (function_exists('getimagesize') && !getimagesize($temp)) { $this->_setError(507); return false; } 然后就必须用一个正常文件，所以必须用cat yy520.zip >> yy520.png 后台拿个shell有必要那么难为我吗～。～ 修复方案： 稍微微的过滤一下下$datafile_serve 作者 yy520
查看更多关于记事狗微博V3.6.1 Build 20120718后台拿shell - 网站安的详细内容...