分类目录归档:渗透测试

glibc CVE-2015-7547 漏洞

开源安全研究团队披露了Glibc getaddrinfo溢出漏洞,该漏洞影响范围较大,涉及当前主要的Linux发行版。据Google 博客中所述,该漏洞应该是可以绕过内存防护技术,从而形成代码执行漏洞。
以下版本均受影响

漏洞危害
Glibc组件包含了大量标准库,这些标准库会被众多的程序调用。其中 libresolv库用来实现主机名与IP地址之间转换的功能。作为glibc包含的组件之一,nss_dns模块通过libresolv库进行DNS查询,从而实现Name Service Switch(NSS)服务。
Libresolv库中的代码在执行A/AAAA 双重DNS查询时会触发基于堆栈的缓冲区溢出漏洞。远程攻击者可以通过创建特殊的DNS响应,造成libresolv崩溃或有可能以运行库用户的身份和权限执行代码;调用函数send_dg(UDP查询)和send_vc(TCP查询)时会触发缓冲区溢出。
漏洞分析
通过对安全漏洞进行分析,glibc通过alloca函数在堆栈中保有2048字节。响应DNS查询请求的函数为_nss_dns_gethostbyname4_r,然后继续调用send_dg和send_vc两个函数。如果响应大于2048字节,就会从堆栈分配一个新的缓冲区并更新所有的信息,包括缓冲区指针、新的缓冲区大小和响应包大小。在某些情况下,这一过程会造成堆栈缓冲之间的不匹配,并会再次分配新的堆栈。最终导致堆栈缓冲将全部被用于存储DNS响应,所以该行为会导致堆栈缓冲的溢出。
验证方法

DNS 解析为 127.0.0.1

1 重启服务

2 执行操作

另一个终端执行./CVE-2015-7547-client ,若含有漏洞,会造成Segmentation Fault。

采取措施:
el7 更新地址

el6 更新地址

参考:

升级后:使用

查看是否使用新的glibc。

glibc 幽灵漏洞 分析 (CVE-2015-0235)

1 据Qualys公司审核发现GUN C库(glibc)中存在一个__nss_hostname_digits_dots的缓冲区溢出漏洞,信息来源

==1== summary

__nss_hostname_digits_dots()导致的缓冲区溢出漏洞,这个bug可以通过gethostbynames*()函数来触发。在本地和远程均可以触发bug。
分析过程如下:
– 通过gethostbyname()or gethostbyname2(),缓冲区溢出将发生在堆(heap)上,通过gethostbyname_r()or gethostbyname2_4()触发调用者提供(caller-supplied)的缓冲区
溢出(调用者提供的缓冲区可以位于heap,stack,.data,.bss.etc,但实际操作中还未发现这样的情况)
– 漏洞产生时多个sizeof(char *)bytes被重写(注意 char*指针的大小,4bytes on32-bit系统上,8 bytes on 64-bit系统上)
。字节会被重写只有在(’0′…’9′),(‘.’),(‘\0′)
–尽管有这些限制,但我们可以随意的执行代码。作为概念的证明,我们开发了针对Exima邮件服务器的full-fledged远程执行脚本,发现可以旁路绕过所有现有的保护(ASLR,PIE,NX),
在32-bit or 64-bit机器上。
– 第一个容易被攻击的版本为GNU C库的glibc-2.2版本。
– 针对这些bug的研究,发现该漏洞在2013/5/21就已经在glib-2.17-glibc2.18版本之间被修复,但不幸的是,当时并没有被认为是一个安全威胁存在。受影响版本可能为:

==2== Analysis:

存在漏洞的__nss_hostname_digits_dots()是有glibc的不可重入的nss/getXXbyYY.c以及可重入的nss/getXXbyYY_r.c调用。而这个调用由ifdef HANDLE_DIGITS_DOTS来定义的。该定义分
布在以下几个文件中

以上的文件是实现gethostbyname*() family。因此也只有他们会调用reach __nss_hostname_digits_dots(),并触发缓冲区溢出。该函数作用是如果主机名的参数是IPv4 or IPv6的地址,
则不需要有DNS来解析
glibc-2.17的code

86-87行所计算的缓冲区大小size_needed,需要存储3个不同的实体:host_addr,h_addr_pts,name(hostname)
88-117行确定缓冲区足够大
88-97行对应函数的重入case
98-117为非重入case

121-125准备缓冲区指针来存放4个不同实体:host_addr,h_addr_ptrs,h_alias_ptr,hostname。 (*h_alias_ptr)的字符指针的大小被size_need所漏掉。

157行的strcpy函数,是让我们写过缓冲区的末尾,最多(依赖strlen(name)和字符对其)4 bytes on32-bit,or 8 bytes on 64-bit。
有个相似的strcpy的函数,但没有缓冲区溢出

为了达到157行的缓冲区溢出,主机名参数必须符合以下条件:
- line 127行的 第一个字符是数字
- line 135行的 最后一个字符不能是’.’
- line 197行的 要只能包含数字和’.’
- 必须可以分配最够大的缓冲区,如非重入的gethostbyname* ()初始化分配malloc(1024)的大小
- line 143行,IPv4的地址被inet_aton函数正确解析,or line 147 ipv6 被inet_pton()
inet_pton中的”:”是被禁止的,也不能带有数字和点的地址解析成ipv6地址,所以inet_aton是唯一的选择,且主机名必须是下列形式之一:”a.b.c.d”,”a.b.c”,”a.b”or “a”。a,b,c,d是
无符号证书,最大是0xffffffful。并可以有strtoul转成十进制的。

==3== Mitigating factors

该影响现在显著减少了,
1 在2013/5/21发表的补丁显示:
[BZ #15014]
* nss/getXXbyYY_r.c (INTERNAL (REENTRANT_NAME))
[HANDLE_DIGITS_DOTS]: Set any_service when digits-dots parsing was
successful.
* nss/digits_dots.c (__nss_hostname_digits_dots): Remove
redundant variable declarations and reallocation of buffer when
parsing as IPv6 address. Always set NSS status when called from
reentrant functions. Use NETDB_INTERNAL instead of TRY_AGAIN when
buffer too small. Correct computation of needed size.当缓冲区太小时使用NETDB_INTERNAL而不是TRY_AGAIN
* nss/Makefile (tests): Add test-digits-dots.
* nss/test-digits-dots.c: New test.
2.gethostbyname*()函数被getaddrinfo() 代替,因为IPv6的到来
3.许多程序,特别是suid文件可以访问本地时,仅当使用inet_aton()调用失败时调用gethostbyname()
4 大多数其他程序,尤其是可远程(ssh)访问服务器时,会使用gethostbyname来逆向查找DNS。这个程序通常是安全的,因为传递到gethostbyname的主机名通常被DNS软件预先检测了。
每个lable最多只有63个8-bit octets,由点分隔,最多攻击有255个octets,,这使得其长度不能满足1kB要求
实际上,glibc的DNS解析器可以产生高达(最多)1025字符的主机名(如bit-string lable,特殊和非打印字符)但这些会一如”\\”,这样就造成不能满足”只有数字和点”的要求

==4== Case studies

 

测试:

==5== glibc使用时的案例

1 glibc-2.13/sysdeps/posix/getaddrinfo.c:
调用是安全的,安照”inet-aton”要求,是安全的。仅当第一次调用inet_aton()失败时,getaddrinfo()会调用gethostbyname2_r()

2 mount.nfs
调用是安全的,安照”inet-aton”要求,是安全的。仅当第一次调用inet_aton()失败时,getaddrinfo()会调用gethostbyname2_r()

3 mtr
调用是安全的,调用了getaddrinfo

4 iputils-clockdiff
是有弱点的

5 ping arping
ping 、arping 在inet_aton()失败时调用 gethostbyname() 和 gethostbyname2()。

== 6 == 系统中那些服务和应用涉及到glibc

可以使用以下命令查询

以上显示bash dnsmasq named sshd 可能涉及到gethostbyname影响

由bash:cve-2014-6271 学习execve 2

关于bash的测试方法如下:

我们使用ltrace 跟踪一下

看一下问题发生的的原因:

官方提供的第一次patch

但产生了一个新的问题:

由于函数体满足() { ,也没有发现”;”,bash在eval的时候遇到语法问题(x)=被忽略了,就执行>/my echo valunerable

第二次提供了

WEB安全_浏览器安全_同源策略

1 概述

本文是走入Linux操作系统系列的其中一篇,本文主要是针对近期关于web安全检测的一些学习和体会,web安全的关心范畴来自于web开发人员,测试人员,安全运维人员,以及互联网的另一头所谓的小黑们。WEB的应用逐渐成为互联网的核心,WEB的安全技术也在兴起,对web安全的问题爆发也越来越流行。
2011年末,一场有CSDN密码泄漏用户数据的事件掀起了一场血淋淋的个人密码泄漏大幕。跟随着网x,xx网,天x,猫x等大型网站的爆库现象,用户的用户名和密码便在互联网上随意下载,一时风声鹤唳,草木皆兵。

2 前言

2011年的那场爆库现象,警方也得出结论,模糊的记得其中2条(与本文不太相关,没有深究其准确性),一是安全意识不够,管理不规范。二是没有使用国家规定安全级别的操作系统。安全问题大都是出自对安全意识问题,如:你的密码在各大网站注册的时候,无论是用户名和密码都是一样的,甚至是你的邮箱。邮箱问题很是严重,因为很多网站是通过邮箱找回密码的,邮箱破解了,很多你的个人秘密和利益都被破解了,当然这其中有一部分属于社会工程学范畴。

一篇文章不能把web安全相关的东西讲的很全面,但我想还是将一些比较重要的东西说出来比较好,这样可以丰富大家的知识。写一篇文章要参考了很多书籍和资料,这里推荐大家的资料为:《The.Web.Application.Hacker’s.Handbook.Finding.and.Exploiting.Security.Flaws,.Stuttard,.Pinto,.2ed,.Wiley,.2011》,当然这本中文翻译本也有了,《黑客攻防技术宝典:Web实战篇(第2版)》 china-pub 地址为:http://product.china-pub.com/3662840 。《白帽子讲WEB安全》。

 3WEB安全发展历程

 

说起安全就会想起hacker这个词,hacker这个词的褒贬暂且不提,对于hacker来说,不想拿到root的hacker不算好hacker,在hacker的行业里,有人分为2种黑客,一种是玩exploit(精通计算机技术,挖掘漏洞编写exploit),另一种是玩脚本的(对攻击本身感兴趣,编程技术不是很高)。在国内存在者一些功利性比较强的黑客,与本主题无关这里闭而不谈。

黑客帝国想必大家都看过吧,其中有很多镜头,如下图:

其中这张图利用到了常见的nmap和ssh,以及一个sshnuke的exploit。最近韩国的幽灵电视剧也有很多镜头显示黑客们利用exploit的技能。但现在的电视剧上关于黑客的镜头大多是无厘头的,cd,ls什么的,便可以入侵了。有点玄乎。

Web安全问题的兴起在web1.0时代,关注服务器动态脚本的安全问题,如webshell(将可执行脚本上传到服务器)。

SQL注入以及XSS的威力也逐步被大家重视,在web2.0时代,XSS以及CSRF的危险则更强大。

上图是2007-2011年web应用安全事件的统计表。

要全面的认识一个安全问题,首先要明白安全问题组成的属性,有人提出了安全的三个要素:机密性,完整性以及可用性,后来有人补充了可审计性和不可抵赖性等要素。

设计安全方案,要做到以下几点:

     1 能够有效的解决问题

     2 用户体验好

     3 高性能

     4 低耦合

     5 易于扩展和升级

安全问题的发展历程也不是短短百十字能描写清楚,HTML5以及云计算的爆发,对web安全要求越来越高,下面从理论性上简单的了解一下web安全的问题。

 4 脚本安全

4.1 浏览器安全

浏览器是互联网的最大入口,每个浏览器都有自己的安全特性,而同源政策的一种安全约定是浏览器最为核心也最为基本的安全功能。web是建在同源策略的基础之上,浏览器则是同源策略的一种实现。

4.1.1同源策略

什么是同源策略?

同源策略是指浏览器会阻止从一个域上加载的脚本获取或者操作另一个域上的文档属性,也就是说,受到请求的URL的域必须与当前的WEB页面的域相同,否则浏览器会主动隔离来自不同源的内容。这一种同源策略,限制了不同源的”document”或脚本。

同源是指:同协议,同域名,同端口,host(域名或IP地址,如果是IP地址可以当作子域名)

他的精髓很简单,它认为任何站点装载的信赖内容是不安全的,当被浏览器半信半疑的脚本运行在沙箱时,它们应该之被运行访问来自同一站点的资源,而不是那些来在其它站点可能怀有恶意的资源。

需要注意的是,对于当前页面来说,页面内存放的javascript文件的域并不重要,重要的是加载js的页面所在的域是什么。如

a.com通过以下代码加载b.com上的b.js。但js是运行在a.com页面中。

a.com的index页面调用b.com的b.js。b.com的index也同样调用b.js.该测试按钮的作用显示当前的href页面。

<script type=”text/javascript” src=”http://www.b.com/b.js”></script>,其测试效果如下:

这个是a.com的测试效果,显示为www.a.com。

而这个则是b.com的测试效果,显示的为www.b.com。

测试的效果显示,其中b.js的脚本是在a.com的页面中运行。因此对于当前页面a.com来说,b.js的源则是a.com;而不是b.com;

测试代码如下:

b.js内容:

同样的对于<script>,<img>,<iframe>,<link>等标签都可以跨站加载资源,而不受同源策略的限制,实际上这些带”src”属性的标签每次加载时,是由浏览器发起一次GET请求。不同与XMLHttpRequest的是,通过src属性加载的资源,浏览器限制了javascript的权限,使其不能读写返回的内容。

点击测试按钮

而在站a.com则会出现,其中返回错误状态码为0。B1.txt没有取到

可以看的出,XMLHttpRequest 受到同源策略的约束,不能跨域访问资源。

测试代码如下:

b.js loadXMLDoc;

xmlHttptest.html code: b.com的代码。a.com域的代码类同。

但,随着互联网的发展,跨域请求的需求越来越多,W3C委员会制定了针对XMLHttpRequest跨域访问标准。他需要通过目标域返回的HTTP头来授权是否允许跨站访问,由于HTTP对与js来说一般是无法控制的,所以认为这个方案是可以实施的,但注意,可以跨域的方案的安全基数是信任”Javascript无法控制该HTTP头”。如果此信任被打破,则方案也将不在安全。

以下将在chrome上实现跨域访问的实验

点击测试按钮,结果如下:

这个测试需要在服务器端进行修改http header,使其支持Access-Control-Allow-Origin协议。

我们可以抓取http报头信息看到:

http://www.b.com/test.php?url=http://www.b.com/b1.txt

 

———————————————————

下面将贴出测试代码:

需要修改b.js的loadXMLDoc(url)函数体的地方

需要使用php修改header的代码

如果使用的其他语言实现,需要使用request.addheader方法实现,IE8需要使用XDomainRequest的方法。

跨域的风险是要注意的,ajax一般不允许跨域,也要根据不同的浏览器设定了。跨域容易引起第三方的恶意安全注入,网络攻击者(“中间人攻击”) 可能篡改服务器响应内容从而可能攻击你编写的扩展内容。

对于浏览器而言,除了DOM,Coookie,XMLHttpRequest受到同源策略的限制外,第三方插件也有各自的同源策略。如 flash,JAVA Applet等。

同源策略也会有很多漏洞,这里就不再深究下去了,有兴趣的可以查阅互联网

skipfish hash 算法

skipfish用到的hash函数
函数体为: