Archive for 四月, 2009

intval()使用不当导致安全漏洞的分析

author: xy7#80sec.com
from:http://www.80vul.com/pch/

一 描叙

intval函数有个特性:”直到遇上数字或正负符号才开始做转换,再遇到非数字或字符串结束时(\0)结束转换”,在某些应用程序里由于对intval函数这个特性认识不够,错误的使用导致绕过一些安全判断导致安全漏洞.

二 分析

PHP_FUNCTION(intval)
{
zval **num, **arg_base;

Microsoft Internet Infomation Server 6.0 ISAPI Filename Analytic Vulnerability
function Copyright()
{
var Author=”80sec”;
var Email=”kEvin#80sec.com”.replace(”#”,”@”)
var Site=”http://www.80sec.com”;
var Date=new Date(2009,4,24).toLocaleString();
var Reference=”http://www.80sec.com/Microsoft-Internet-Infomation-Server-6-ISAPI-filename-analytic-Vulnerabilitie.html”;
return Reference;
}
/*
漏洞描述:
IIS6 (Internet Infomation Server…

四月 24th, 2009

关于html本地权限问题

1 Comment, 安全防护, by Neeao, 535 views.

by:lcx
最近看了两篇文章,一篇是Google Chrome使用ajax读取本地文件漏洞,另一篇是本地执行ajax的权限问题,对此我有一点自己的想法,我认为这都不算是安全问题,好像这两篇文章没有对本地html的权限有足够的了解。
举两个例子,一个是html读出本地txt内容,一个是html操作本地数据库,关键是用户允许执行本地的js了。
如果还不清楚html权限有足够大的话,请执行C:\WINDOWS\pchealth\helpctr\System\sysinfo下面的相关 的html,如C:\WINDOWS\pchealth\helpctr\System\sysinfo\sysinfosum.htm,你就有足够的了 解。
如果有了用户执行本地active权限的操作,对IE来讲是不分浏览器的版本的,像html读出本地txt内容同样在IE8下就适用(win7+ie8以及xpsp2+ie7测试通过)。所以我认为空虚浪子心发的一会对这个浏览器测试一会对那个浏览器测试ajax读本地内容,以及xeye团队对这个议题研究的意义不大,本身是允许用户执行了本地js了。
如果没有提示来执行的话,才算是安全问题。举个例子,像ms06014网马在xp系统上补丁打了,你本地执行ms06014网马,如果一步一步允许所有执行都同意的话,它同样是可以执行的。
一家之言,希望以上两篇文章的作者不要骂我。

新闻来源:milw0rm.com
Linux的udev程序再爆本地提权漏洞,本地用户可以轻易获得root权限,请立即更新udev程序。(2.4内核系统不受影响)
修复方法(修复前请备份重要数据): debian用户请执行apt-get update ; apt-get upgrade -y
centos用户请执行yum update udev
RedHat用户请使用官方rpm包更新或者购买RedHat的satellite服务。
攻击效果展示:
libuuid@debian:~$ sh a 890
sh-3.1# id
uid=0(root) gid=0(root) groups=105(libuuid)
sh-3.1# cat /etc/debian_version
lenny/sid
sh-3.1# dpkg -l |…

在周四于迪拜举行的HITB安全大会上,安全研究人员演示了如何通过软件,来入侵微软的新系统Windows 7,他们利用的是该系统中无法修复的设计漏洞来进行的。研究员Vipin Kumar和Nitin Kumar利用自己开发的VBootkit 2.0,演示了黑客如何在Windows 7启动时获得系统的控制权。
据悉,这个攻击方式和其他的不太一样,它只能用于Windows 7。尽管此攻击过程不能通过远程控制来完成,需要黑客直接接触目标PC,但是Vipin指出:“目前该问题还未修复,而且它无法被修复,因为这是个设计上的问题。”
该程序只有3KB大小,允许攻击者在系统启动时更改系统内存中加载的文件。由于没有更改硬盘中的数据,所以VBootkit 2.0 很难被察觉,重启电脑之后可以消除此安全问题。
一旦成功使用该软件进行入侵,黑客可以远程控制目标机器,并改变用户的访问权限。正像它的版本号一样,VBootkit 2.0是这两位开发者开发的第二款程序,原先的版本在07年曾经用来演示如何入侵Windows Vista。目前微软尚未对此事发表评论。

cnBeta编译
来源:Electronista

一位计算机安全研究人员发布了一款升级工具,它可以简单的在微软Windows系统中的.Net Framework里,安置难以被察觉的恶意软件。该工具名为.Net-Sploit 1.0,可以用来修改.Net Framework,后者是安装在Windows机器上用来执行特定类型程序的软件。
据 该软件的作者,2BSecure的软件安全工程师Erez Metula称,.Net-Sploit允许黑客修改目标机器上的.Net Framework,并在安全软件没有触及,安全人员也不注意的位置,注入rootkit类的恶意软件。他在周五的黑帽安全大会上指出:“你将会对它攻击 过程的简易的程度感到吃惊。”
.Net-Sploit可以让黑客使用恶意代码取代.NET Framework中的合法代码。当一些依赖于.Net framework 的程序运行之后,恶意软件可以影响到这些程序的功能。比如某个程序携带身份认证机制,一旦被攻击之后,.Net framework 能自动拦截用户名和密码,并发送到远程服务器中。
此外,.Net-Sploit还能自动执行一些代码任务,来加速该框架的腐化速度,使得攻击的速度加快,比如,它可以感染到该框架相关的DLL,从而部署这些恶意的DLL。
Metula指出,在使用该工具之前,黑客必须首先要取得对目标机器的控制,之后利用被修改的.Net framework,攻击者可以秘密的控制这台机器很长一段时间而可能不会被察觉。
cnBeta编译
来源:Networkworld

四月 23rd, 2009

福州网龙公司招聘反黑专员

2 Comments, 业界咨询, by Neeao, 503 views.

福州网龙公司招聘反黑专员,要求如下:
1、男女不限,工作年限不限,本科以上学历、计算机应用、计算机网络等相关专业;
2、对脚本编程有较深了解,对各项WEB应用技术的安全问题熟悉;
3、熟悉至少两种安全攻防技术;熟悉系统漏洞、木马外挂技术、恶意脚本原理;
4、理解网络原理,入侵检测、漏洞扫描等原理,有一定的黑客入侵分析和防范经验;
5、有丰富安全项目实施经验者优先考虑;
7、具有较强的沟通及团队协作能力。
网龙公司简介:http://www.nd.com.cn/cn/about/intro.shtml
招聘人数:5人
工作地点:福州
待遇:3k以上,有能力者上不封顶
联系方式:
QQ:88952634
电话:13696855342
邮箱s0_6[at]hotmail.com

四月 21st, 2009

server limit dos利用随想

No Comments, 技术文档, by Neeao, 246 views.

By:空虚浪子心
看了墨西哥同学(其实看不懂,刺帮忙翻译的)和刺的文章,不过我们主要关心该技术的利用。
sirdarckcat说,HTTP头的长度,在APACHE等web服务器是有一定的要求的,如果超出一定长度,会产生服务器错误。HTTP头里面,有cookie,有location,有host。。。如果我们可以控制其中一个(例如cookie),给用户植入大长度的cookie,就会出现用户访问该域下所有的请求,都带上大长度cookie,导致用户不管访问域名下的哪个文件,都会产生服务器错误,造成客户端无法访问。
HTTP头有很多字段,为什么非要提COOKIE插入大字段呢?从理论上讲,只要HTTP的头,大于某个值,就可以DDOS,但是问题是,只有COOKIE会跟着用户一直走。种入COOKIE后,无论访问哪里,都会发出去,但是其他字段,例如location等,虽然插入了,却只有一次请求带着,下次没有了。
那么,我们就有两个问题需要讨论。
1, 把HTTP header搞大,让用户访问时挂掉。
2, 把COOKIE搞大,让用户访问时挂掉。
如前文所说,http header中的其他字段,即使加入了大字段,导致apache错误,也只能让一次请求失败(或两次,因为有referer)。所以利用价值,当然就不如COOKIE中植入了。所以,我们把关注点放在COOKIE上。
下面统计有几种情况可以给用户种入cookie:
1, XSS,当某个域下出现了XSS漏洞,我们当然可以添加大cookie,例子见刺的文章http://hi.baidu.com/aullik5/blog/item/6947261e7eaeaac0a7866913.html。本文就不讲这个了,我喜欢把它叫做JS植入法。
2, 服务器上某个应用,接受用户的提交变量,再把用户提交的数据,加入到COOKIE中。我喜欢叫他server植入法。
要使用js植入法,就只能找XSS漏洞、或者能够影响“JS处理COOKIE”的那段数据的内容。
Server植入法的利用方式有两种,第一种是服务器接收了用户的输入,之后更改COOKIE的值为用户提交上来的值。这种方式是直接攻击应用,溢出http头,很暴力的撑大。只要一次提交,后面再也访问不了了,被apache拦截。第二种比较阴险,是一次一次的撑大,典型的应用就是购物车。一旦我们可以直接控制购物车放入cookie中的值,我们就可以一次一次的把它搞大,每次都可以访问,直到最后一次,就不能访问了。
请注意一点,墨西哥同学提出的是40X错误,是apache爆出来的,实际上,我们的应用也可能爆出来这个东西。当然,应用爆出来的漏洞,就不是40x错误了。
举个sohu的POC:

http://passport.sohu.com/web/*****?*****=dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagssssssssssssssssssssssssssssssssssssssssssssssddddddddddddddddddddddddddddddddddddddddd

如果新浪看sohu不顺眼,只要在自己的网页中,iframe一下这个地址,访问过sina的用户,就登陆不了sohu了。如下图,用户访问任何地方,只要是passport域名下,全都是这个错误。

这个sohu的例子其实是应用爆出来的错误,而不是apache爆出来的。也就是说,在这里APACHE其实是允许这么大字段的cookie的(没有到apache指定的长度),但是apache后面的应用(JAVA程序)却受不了这么大的字段。
那apache的400和应用的500到底有啥区别呢?
我们可以从DDOS的效果谈这个问题,用户被植入大字段的COOKIE后,每次访问,都会返回40X,其实是针对用户的,而对服务器来讲,一个40x,代价可能很低。
但是500就不一样了,JAVA本来就是虚拟机上的乌龟,再加上每次用户访问都扔个500过来,性能会受很大的影响,最后如果真的把服务器也XX了,那就溴大了。YY下,不需要XSS,不需要种马,一样DDOS,一旦规模的种植后,这个漏洞就不好补了。。。
Server植入法利用的漏洞,也是有一定的利用技巧的,首先猜测哪个服务器的应用可能操作cookie,之后手工测试,当找到漏洞点的时候,就开始加入大字段,之后递减。使用这种方式,就不需要再去找XSS了,因为通常情况下,XSS的功能是比较强大的,能挂马,而这个XSS点用于DDOS用户访问,就感觉浪费了。

四月 13th, 2009

SAML

No Comments, 安全防护, by Neeao, 474 views.

by 云舒
摘要:SAML在国内介绍不多,这里简单描述一下。
WEB系统的登录一般基于cookie或者session(session底层还是需要cookie),在没有cookie的情况下比如WAP网站 则使用伪cookie方式或者伪session方式,这个我在以前的文章《从wap网站的认证授权到csrf的协议类比本质》中略微提到过。对于跨域的 SSO(single sign on)而言,虽然各系统具体实现各异,但是因为跨域不容易传输cookie所以和WAP类似,所以底层依然是伪cookie或者伪session或者类似 的变通方式。在这里我略微说一下SAML(Security Assertion Markup Language),SAML在国内似乎介绍不多,它是用来解决SSO问题的,本质上依旧是类似cookie和session,和传统的SSO相比并没有 很突出的优点。但是它毕竟是一个标准,得到了IBM,Google,Juniper等公司的支持,可以很通用,google apps就支持SAML认证。
SAML使用XML在不同的域之间传输认证和授权信息,这里的信息称为一个SAML断言。断言是可以加密的,以保证不被嗅探攻击。这里的不同域,根据在 SSO中的用途分为认证提供者和服务提供者。显然的,认证提供者提供认证服务并声称SAML断言,而服务提供者提供认证后的应用上的服务,信任SAML断 言。因为使用的XML的方式,所以可以很容易的和Web Service继承,如Sun Java System Access…