任何一个行业的人才缺口过大,都不是一个好的现象。现在来说,网络安全行业就是这么个情况。

大量报告显示,整个世界范围内都对网络安全相关人才的需求量非常之大。其中,以美国为例,(ISC)2预计到2020年,网络安全将出现180万的人才缺口。对整个行业来说,由于网络安全相关技术、人才的缺乏,一直以来也被认为是最大的网络安全风险之一。

填补这一空缺势在必行,但这无法仅靠某个部门或组织独立完成,需要多方面的协作。

147046_wx.jpg

安全压力日益增加

对于缺人的压力,各类安全团队的感受一定是最直观的。他们往往工作过度且人员不足,这很容易导致不良用网情况的出现,或者在清点网络资源的时候出现错误。

根据Ponemon发布的“2018年数据泄漏成本”报告显示,70%的数据都是由于云存储服务器、数据库、网络甚至是防火墙配置错误造成的泄漏、损失。现阶段,由于人员疏忽导致的数据泄漏事件发生的频率占据了网络攻击的一半,而因为此类失误导致的漏洞比往年增加了400%以上。

安全培训势在必行

虽然现在解决人才短缺问题的多数是选择提升技术能力以避免网络风险,但我们需要意识到,网络安全技能提升的难度远比增加安全人员就业的难度高。当今网络世界中最大的风险之一便是基础网络攻击,例如网络钓鱼、邮件诈骗或各类社会工程学技术等。很多人对于安全知识缺乏基础认知,企业需要改善他们对于安全的态度,并且也要针对不同受众进行相应的培训。

image.png

在网络安全供应商的角度,安全知识/技能培训通常是他们所擅长的:为客户和合作伙伴提供使用自身产品所需的知识和技能。随着网络安全解决方案日益复杂,安全培训也至关重要。想要成为真正让客户信赖的安全供应商,那么就需要提供比以往更丰富、全面的培训战略。例如:

为企业员工量身定制相应的安全意识培训;

实施网络管理安全解决方案;

扩大招聘范围,尤其关注女性、潜力股、对安全兴趣浓厚的人员;

设立专业服务团队以便解决客户需求;

学术机构应该对人工智能以及更高新的技术增大研究投入;

政府及NGO制定网络安全相关政策;

学龄青少年以及学校增加对网络安全专业的课程。

填补空缺

想要解决人才缺口,出台正式对政策计划是必要因素,全面的培训和教育也少不了政府机构以及学术界的支持。对于网络安全厂家来说,这算是给他们提供了一点思路。

世界各国以及各大企业都面临着重大的网络安全危机,不仅仅是人才缺口,如前文所说,网络安全技能的差距甚至比人才缺口还要大,这对于企业的持续运作都存在着巨大的威胁。

缩小技能差距不仅是包括对未来安全从业人员对教育,还需要对任意一个可能造成风险的人进行指导。如何在社会层面提升网络安全水平,将会是日后众多企业面临的最大问题。 

*参考来源:darkreading,Karunesh91编译,转载请注明来自FreeBuf.COM

在《Metasploit渗透测试魔鬼训练营》中讲过MS08-067的漏洞原理,不过内容十分晦涩难懂难以消化,我反复阅读钻研了几遍并通过实践分析,对该部分的内容用通俗易懂的语言重新组织一遍,画了该漏洞溢出的原理图,就当做分享和学习总结吧。

0×01 MS08-067漏洞原理

MS08-067漏洞是通过MSRPC over SMB通道调用Server服务程序中的NetPathCanonicalize函数时触发的,而NetPathCanonicalize函数在远程访问其他主机时,会调用NetpwPathCanonicalize函数,对远程访问的路径进行规范化,而在NetpwPathCanonicalize函数中存在的逻辑错误,造成栈缓冲区可被溢出,而获得远程代码执行(Remote Code Execution)。

所谓路径规范化,就是将路径字符串中的【/】转换为【\】,同时去除相对路径【.\】和【..\】。如:

**/*/./**   =>  **\*\**
**\*\..\**  =>  **\**

在路径规范化的操作中,服务程序对路径字符串的地址空间检查存在逻辑漏洞。攻击者通过精心设计输入路径,可以在函数去除【..\】字符串时,把路径字符串中内容复制到路径串之前的地址空间中(低地址),达到覆盖函数返回地址,执行任意代码的目的。

路径处理流程

NetpwPathCanonicalize函数并没有直接进行输入路径和规范化,而是继续调用了下级函数CanonicalizePathName来进行路径整理,将待整理的路径字符串进行规范化,然后再保存到预先分配的输出路径缓冲区buffer中

路径处理流程:

1.检查待整理路径的第一个字符;

2.调用msvcrt.dll模块的wcslen函数计算路径长度;

3.调用msvcrt.dll模块的wcscat函数把待整理路径全部复制到新申请的内存中。

4.调用wcscpy函数,去掉待整理路径中第一个表示父目录的相对路径复制到strTemp,如:

\******\..\..\***   =>  \..\***

5.循环调用wcscpy,直到路径整理完毕。

在这里我们知道了,在规范化复制时要寻找表示父目录的【..\】字符串及其前面的一个【\】字符串,将这一段去掉并将新路径复制。

img

如图,第一次检查时去掉了第一个相对路径并复制到缓冲区

但是,当【..\】字符串在路径字符串的最前面时,那么其前面的一个【\】就在缓冲区外面了,就是在这里产生了向前(低地址)的溢出。

img

缓冲区溢出

需要明确的是,微软对路径规范化时的字符串复制可能出现的缓冲区溢出做了初步的防御。

在每次向缓冲区中复制字符串时,无论是用wcsccpy还是wcscat,在复制前总要比较源字符串的长度,保证长度小于某个值(207),否则不会继续复制,这一策略确保缓冲区不会向高地址溢出,即当前函数返回时不会发生问题。

但是注意,在规范化表示路径,寻找父目录的【..\】字符串前面的【\】字符时,程序做了判断和边界检查:如果当前比较字符的地址与源字符串地址相同,就表明整个字符串已经查找完毕,程序就会停止查找。

然而它唯独漏了一种情况,就是当父目录相对路径【..\】字符串在源字符串的开头时,在开始查找时比较的字符串(【\】到【..\】)位于缓冲区之外,这导致了复制的字符串向低地址的溢出,造成函数wcscpy的返回地址被覆盖。

img

0×02 漏洞还原分析

实验环境

靶机:Windows2003 SP0 EN

漏洞组件:netapi32.dll

工具:IDA Pro、OllyDbg

选择Windows XP SP3 EN系统主机作为分析环境,定位到包含该安全漏洞的系统模块netapi32.dll(路径C:\Windows\system32)和调用漏洞服务Server的进程svchost.exe,目标进程命令行为:

C:\Windows\System32\svchost.exe-k netsvcs

用IDA pro打开netapi32.dll,找到漏洞所在的NetpwPathCanonicalize函(每次运行堆栈中的地址会不同,但各函数的地址一样),如图在书中提到:

查看该函数流程图,可以看到,此函数并没有直接进行输入路径的规范化, 而是继续调用了下级函数CanonicalizePathName

然而在实际操作中并没有发现CanonicalizePathName这个函数,并且多种资料表明应当是调用CanonPathName函数进行规范化。

IDA分析NetpwPathCanonicalize函数代码(F5 + 整理 + 主要代码):

该函数声明如下:

DWORD NetpwPathCanonicalize(
    LPWSTR PathName, //需要标准化的路径
    LPWSTR Outbuf, //存储标准化后的路径的Buffer
    DWORD OutbufLen, //Buffer长度
    LPWSTR Prefix, //可选参数,当PathName是相对路径时有用
    LPDWORD PathType, //存储路径类型
    DWORD Flags // 保留,为0
 )

动态调试

通过wmic查看命令行参数为svchost.exe -k netsvcs的进程pid:

img

打开OllyDbg,点击file->attach,附着到svchost.exe进程上:

img

View->Executable modules双击netapi32,在cpu指令窗口右键选Search for查找exec(label) in current module,找到函数NetpwPathCanonicalize,地址为71C44A3E,在此处设下断点:

img

追踪漏洞触发过程

回到CPU指令窗口运行程序,然后攻击机Metasploit加载ms08_067_netapi模块并exploit:

img

NetpwPathCanonicalize中断

分析环境中的svchost程序会中断在NetpwPathCanonicalize函数的入口地址处。该函数的传入参数如下所示:

img

esp            [esp]        * 注释 *
00ECF924    02248D34    ;指向待整理路径
00ECF928    022321D8    ;指向输出路径buffer
00ECF92C    000003F1    ;输出buffer的长度
00ECF930    02248FB0    ;指向prefix,值为 \x5C\x00 ,即unicode ‘\’
00ECF934    02248FB4    ;指向路径类型,值为 0x1001
00ECF938    00000000    ;WORD Flags保留,值为0

CanonicalizePathName中断

结合IDA pro对NetpwPathCanonicalize的流程分析,在地址处将调用下一级函数CanonPathName,在此地址设下断点:

img

运行到此断点,然后跟踪函数CanonPathName,传入参数如下所示:

00F0F8FC    00157570    ;指向prefix,值为\x5C\00,即Unicode"\"
00F0F900    001572F4    ;指向待整理路径
00F0F904    02132E80    ;指向输出路径的buffer
00F0F908    000003F9    ;输出buffer的长度
00F0F90C    00000000    ;WORD Flag保留字,值为0

从上两个函数的参数传递可以看出,函数CanonPathName进行路径整理,然后再保存到预先分配的输出路径缓冲区buffer中。

待整理路径结构

在OD中查看待整理路径的结构,路径是Unicode字符串,以【\x5C\x00】(Unicode字符“\”)开始,【\x00\x00】结束,中间包含一些随机的大小写字母,较长一段不可显示的字符是经过编码的Shellcode,其中最关键的是两个连在一起的父目录相对路径【….\】。

1557343359609

整个待整理路径形如:

\******\..\..\***

整理路径前的预操作

在待整理路径所在内存地址000C0F50处4字节上设内存访问断点:

1557343390836

按F9运行,会中断3次,前两次分别是检查待整理路径的第一个字符和调用wcslen函数,第三次是在调用wcscat函数。分析第三次传入栈中两个参数:

1557343410176

第一个是strDestination,指向一段以【\x5c\x00】开头的内存空间;第二个是strSource,指向上述待整理路径前两字节【\x5c\x00】后的内容。

程序把待整理路径全部复制到strDestination,即0x001572F6处。在此4字节设断点,类型选择”Hardware, on access”DWord。

1557343435014

复制路径到缓冲区

F9继续运行,第4次中断在0x77BD4010 ,内存里显示这里将src的前两个字符复制到了dest的【\x5C\x00】后面,这是由于这两个字节设了断点的原因:

1557343573648

第5次中断在0x71C44B1C,位于wcscat函数内,内存显示已将src复制到dest,如图:

1557343589111

1557343606903

第一次路径规范化

按F9运行,中断多次后停在内存0x77bd4d36处,通过栈可知此处属于wcscpy函数。此处调用该函数进行第一次路径规范化。如图:

1557343631915

当前参数src值为0x00EC6E0,指向【..*】;参数 strDestination 值为0x00ECF4DC,指向temp中的第一个字符【\】。 显然,这次路径规范化即把待整理路径中第一个字符【\】和第一个【..\】相对路径之间的内容抛弃。

1557343644183

而此时wcscpy源地址src在edx寄存器中,指向【..*】;目的地址dest在ecx寄存器中,指向待整理路径第一个字符【\】,如图:

1557343668919

所以,这次字符串复制操作就是去掉第一个表示父目录的相对路径,即待整理路径temp中的第一个【\】和第一个【..\】之间的内容成为无用路径被抛弃。操作完成后,temp中的路径字符形如【..*】。

第一次规范化后,待整理路径形如:

\..\***

由于还有【..\】,还需要进行一次规范化,而这第二次规范化正是玄机所在。

第二次路径规范化

由于每次路径规范化都会调用wcscpy函数,接下来删除0x00ECF4DC的硬件断点,直接在wcscpy函数的入口地址0x77BD4D28处下断点。

1557343841212

F9运行后中断在wcscpy函数入口0x77BD4D28处,调用wcscpy函数传入的参数:

1557343857034

esp            [esp]        * 注释 *
00ECF4AC    00ECF494    目的地址,指向的内存区域值为\x5c\x00,即【\】
00ECF4B0    00ECF4E2    源地址,指向第二个相对路径【\..\】的最后一个斜杠

正常情况下,这次规范化处理会和第一次执行同样的操作,去除第二个相对路径【..\】,从而完成第二次的路径规范化。但这里出现了一个意外的情况,temp的首地址是0x00ECF4DC,而此次字符串复制操作的目的地址dest却在0x00ECF494,在temp之前,如图:

1557343903100

同时注意到,栈指针ESP值为0x00ECF4A8,该地址指向wcscpy函数的返回地址0x71C52FD4。ESP到复制目的dest地址0x00ECF494只有0×14字节,于是,函数wcscpy如果继续执行,将用源字符串src覆盖wcscpy函数的返回地址。

执行到retn命令,可以看到返回地址变成了0x0100129E,该地址的指令为:

00100129E        FFD6        call esi

执行 call esi(ES=0x00F0F4DE)指令,正好将EIP指向复制尽量的字符串中构造好的第8字节空指令,接着是【\xeb\x62】(jmp 0×62),此jmp指令跳过中间的随机字符串,指向经过编码的Shellcode,如图:

1557343946968

所以这里是由于内存0x00F0F494处的一个【\】(0x5C),使得出现在处理父母了相对路径【..\】时往前溢出了待处理路径,从而将字符串覆盖到函数wcscpy返回地址的位置,跳转到shellcode造成远程代码执行。

正如前面所提到的,当【..\】在源字符串开头的时候,在开始查找时,比较的字符位于缓冲区之外导致了向前的溢出。

参考

《Metasploit渗透测试魔鬼训练营》,诸葛建伟。

*本文作者:Dhakkan,转载请注明来自FreeBuf.COM

本周BUF大事件还是为大家带来了新鲜有趣的安全新闻,易到回应黑客攻击:完全恢复需要时间;Office 365出现网络钓鱼,用户需多加注意;2345网址导航回应“浏览器主页劫持”;FreeBuf《2019企业安全威胁统一应对指南》PDF完整版发布。想要了解详情,来看本周的BUF大事件吧!

观看视频

内容梗概

易到遭遇黑客攻击,完全恢复需要时间

5月26日中午,易到用车微博发布消息称,服务器连续遭到攻击,导致核心数据被加密、服务器宕机,攻击者要求支付巨额比特币。易到称,已经发动公司全部技术力量以及第三方网络安全防护专家,争取在最短时间里恢复服务。目前已经取得了一定成果,但由于黑客造成的破坏巨大,要完全恢复正常,还需要时间。

y1.png

Office 365出现网络钓鱼,用户需多加注意

近日,一种新形式的钓鱼活动出现在网络中,攻击者会将钓鱼内容伪装成Office 365警告邮件,声称用户已触发中级威胁警报,并告知用户在他的账户中发生了大量文件删除行为,诱使用户点击警告框。如果你点击了“查看详情”的链接,那么将会打开一个伪造的Microsoft的账户登录页面,当用户输入密码时,所输入的账号和密码会被发送到指定的网址。

o7.jpg

2345网址导航回应“浏览器主页劫持”

近日,2345浏览器因主页劫持问题而被网友频频点名。2345官方回应称,某些推广渠道为了赚取利益,违规推广,甚至劫持用户主页。2345坚决打击流氓推广渠道,禁止劫持、不能卸载、无提示安装软件等恶意推广行为,不允许这些推广渠道靠损伤2345的品牌来赚取推广费。如果发现这种行为,一经核实,立即查封该推广渠道,严重者还要追究其责任。

FreeBuf《2019企业安全威胁统一应对指南》PDF完整版发布

近一年,网络安全相关的政策法律陆续出台落实、技术投入应用、网络安全事件频发,带动网络安全行业进一步发展变化。传统威胁依旧存在,新的威胁与风险层出不穷,给企业安全带来更多挑战。FreeBuf 针对企业安全现状和安全产品情况进行了深入调查,并在安全专家和顾问的指导下,构建企业威胁应对流程模型,结合理论和应用进行分析,形成了《2019企业安全威胁统一应对指南》,完整版报告及产品推荐名录现已重磅发布,欢迎扫码下载。

15562708369317.jpg

* 本文作者:willhuang,FreeBuf视频组荣誉出品,转载须注明来自FreeBuf.COM