Shadow Brokers在数周前就曾宣布将公布更多0-day Exploit,并就此发表了一篇声明。几周之前闹得沸沸扬扬的WannaCry恶意软件利用的正是Shadow Brokers从NSA窃取的“永恒之蓝”。如今六月将至,Shadow Brokers也兑现了自己的“承诺”,团队在最新的公告中表示,每个月将以订阅的方式出售数据,费用为100Zcash(根据5月31日汇率情况约为23,000美元,折合人民币约1,759,000)每月。

什么是ZEC(Zcash)?

Zcash是一较比特币匿名性更强的加密货币,也就是说交易双方的信息和交易金额都将被隐藏。不过Shadow Brokers的成员似乎对于利用Zcash和洋葱网络仍然感到不够放心。

他们在声明中写到:“Zcash与美国政府(美国国防高级研究计划局DARPA, 美国国防部DOD, John Hopkins)和以色列有关。美国政府“赞助”这种加密版的比特币的理由不得而知。从防御性角度而言,Tor洋葱网络的设计初衷也是防追踪。但是我们同样无法完全相信Tor。”

basic-txn-types_v2.png

现在就加入“月享俱乐部”

简单来说,感兴趣的用户可以首先将100Zcash发送至指定地址,并在“加密备忘栏”(encrypted memo field)中“预留邮箱地址”(delivery email address)。Shadow Brokers在收到付款后会向用户预留的邮箱发送确认邮件。

根据声明,该团体将从2017年6月开始在不同平台上发布新的0-day漏洞和利用工具。团队成员此次公布了更多的“漏洞订阅”细节。想要成为Shadow Brokers “Wine of Month Club”(月享俱乐部)的会员?请参照以下指示

欢迎来到TheShadowBrokers每月订阅服务——2017年6月

问:我应该如何进行订阅,获得theshadowbrokers下阶段的数据(2017年6月)?

#1-在2017年6月1日至2017年6月30期间将100ZEC(Zcash)转入以下地址:

zcaWeZ9j4DdBfZXQgHpBkyauHBtYKF7LnZvaYc4p86G7jGnVUq14KSxsnGmUp7Kh1Pgivcew1qZ64iEe

G6vobt8wV2siJiq

#2-转账需在“加密备忘栏”中附上“收件email地址”

#3-完成#1和#2后,你提供的“收件email地址”将收到一封确认邮件

#4-2017年7月1日至2017年7月17日期间,所有认证用户(完成#1,#2,#3)的“收件email

地址”都将收到一封”群发邮件”

#5-这封“群发邮件”将包含2017年六月数据的链接和密码

kaspersky-says-shadow-brokers-leaked-malware-is-authentic-507366-2.jpg

会员能拿到何种“福利”?

Shadow Brokers每月的数据包括:

web浏览器、路由器、手机的利用及工具

操作系统的利用(包括windows 10)

从SWIFT供应商和各央行盗取的网络数据

关于俄罗斯、中国、伊朗或朝鲜核武器及导弹计划的网络数据

攻击者的开价可以说已经很低了,情报机构和黑社会仅需23,000美元就可以获得宝贵的数据。但Shadow Brokers目前尚未决定2017年六月这批数据的具体内容。

Shadow Brokers表示,他们明白20,000美元并不是谁都付得起的价格,因此他们指出这项服务的对象主要是安全公司,各国政府,OEM厂商,黑客和“不差钱”的人。团队成员声称,Zcash交易同样存在一些风险,他们也无法保证其安全性和可靠性。

Shadow Brokers 此前试图通过拍卖,众筹或直接售卖的方式出售“方程式组织”的漏洞利用,但没有一种方式最终奏效。但这次,他们成功的希望就大得多,因为每月100Zcash的价格相较之前上千比特币的售价要“平易近人”得多。安全公司Hacker House的联合创始人Matthew Hickey就提议在KickStarter发起了众筹(似乎链接已失效),在获得这些漏洞信息后,对其进行分析然后告知受影响的厂商。

安全专家认为,The Shadow Brokes会在未来发布经过认证的,有效的漏洞,因为他们先前就发布过窃取的数据。因此该组织的此项声明应该得到严肃对待,至少目前是这样。我们知道WannaCry和其他恶意软件利用的就是Shadow Brokers上月泄露的NSA后门,全球都因此一片混乱。如果Shadow Brokers兑现声明,那么全世界都要做好准备,抵御一场WannaCry式的大规模攻击。

* 参考来源:securityaffairs, thehackernewsSecurityWeek,本文作者sun,转载请注明来自FreeBuf.COM

编者按:Chrome浏览器长期以安全著称,但它也有软肋,就是插件和扩展。Chrome插件和扩展有着极高的权限,但安全主要靠开发者自己把关,Google较少参与。在过去,曾经爆出多次插件/扩展被黑导致Chrome用户信息被劫持的事件。

最近,国人开发的知名插件“Infinity New Tab”因为开发者账号被盗,导致插件被劫持加入了弹窗广告,reddit、知乎上均有用户反馈。插件开发者发现后紧急处理解决了问题。他们分析了黑客添加的代码,比较庆幸这次只有弹窗广告,没有窃取信息或推送病毒。以下为“Infinity New Tab”开发者gh guang放出的事件处理经过,其中有许多可供参考的关键点信息,嘶吼加粗显示。

首先跟infinitynewtab的用户说声对不起,由于我们太愚蠢,导致账户被盗,给大家的使用带来不便了。黑客主要在代码中加入了弹窗广告,除此之外没有任何的影响,没有盗号,没有病毒。

好了,下面我们来说说这次事件的经过:

5月29号已经更新到6.0的版本,可以放心使用,如果版本低于6.0,赶紧更新到6.0的版本

下面就来说说这次事件的经过。

5月26号(星期五晚上)

gmail 邮箱突然收到一封邮件,大概看了一下,说是infinitynewtab被chrome 商店删除了,一看到这个邮件心里面就着急了啊。看到邮件中有个链接,说是查看被删的原因,就是违法了Google隐私政策的原因。当时太着急了,太着急了,太着急了,导致于做出了如此愚蠢的行为,一路点过去,输入账号跟密码。结果。。。账户就被盗了。但是,当天晚上并没有发现不对,而是心里在想,为啥被Google 商店移除了。违法了那条政策。去看Google商店也没被删除,心里当时想着,难道有延迟吗,就想着第二天好好研究下Google隐私政策。遂睡。邮件截图:

v2-263de8d7b333c613f0c801abe4f9930c_b.png

5月27号早上9点(星期六)

大早上,一起来,登陆开发者账号,进入后台页面,一看版本号怎么变成3.12.22了,本来3点几是作为目前正在开发的新版的版本号,突然感觉不对劲,再回到邮件仔细怎么是chromewebstore.pro这个域名 ,再把这次3.12.22的版本下载下来看,里面怎么多了一个alert10.js的文件,卧槽,这下可惨了。确定账户被盗无疑了。于是赶紧把密码改了。然后在进去后台,发现黑客又在发布3.12.5的版本,赶紧点了取消发布。这已取消发布,就显示正在等待Google审核。如图:

v2-0f05371d2e98b53b85f6a6e5d9c55c10_b.png

取消发布后,发现肯定是黑客发现了[email protected] 这个邮件和开发者账户绑定到一起,于是把后台的邮件改成[email protected]了,防止别人再来给我们发钓鱼邮件,当然经过这次事件后,以后开发这账户要单独用一个,保证安全

回过头来,再看看这个alert10.js文件。(这是alert10.js的源码

v2-32ec960689301205f67d419fefa320b2_b.png

v2-203f30defc0e913061beee2f3faa5e9b_b.png

分析一下这个alert10.js,生成了一个年月的md5值,而且每隔一个小时就会弹窗一次,弹窗的内容就是如图:

v2-790f5444f8c0f55a7ff938cf14983d8d_b.png

点击确定就会跳到md5生成的这个链接,再去查这个链接

v2-424b95ce4b34d3669396c38c53484e97_b.png

发现这个域名是从namecheap购买的。于是乎赶紧联系namecheap的客服,说明情况后,namecheap把这个域名给封了

5月27号11点

赶紧联系Google的人,找邮件,发邮件。

v2-b90c2c5beada51903004ef6907ab5e60_b.png

v2-f150d2e1383772a64b7e1b80d4d99493_b.png

邮件发出去了,却没有任何音讯。今天tmd 周六,Google不上班。

于是乎,给用户发通知,和找Google的联系方式。

临时做了一个简陋的告知信息页面关于黑客入侵),让用户卸载3.12.22的版本,从官网下载2.xx的离线版本。(可能有很多用户没收到通知,再给大家道歉)

另一方面,找Google的工作人员,最后在知乎上找到了Google的工作人员,愿意帮我们发内部邮件。自己写了一封英文邮件,他帮忙转发。

v2-5220d0fb617762a50bb0c91f614731be_b.png

在此感谢知乎这个平台。感谢帮助的人。然后进入等待中。。。。。

5月29号下午(星期一)

不断刷新后台看Google的审核状态。Google审核通过了,是把之前黑客发布的3.12.25的版本通过了,赶紧把准备的正常版本6.0,发布上去,用6.0的版本替换3.12.25的版本,这里再说明下,很多用户可能又从2.xx的版本或者3.12.22的版本升级到了3.12.25的版本,导致很多用户产生了误解,说升级后还有弹窗,因为3.12.25的版本也是黑客发布的。如果你还是3.12.22或者3.12.25的版本,请及时更新到6.0的版本。

到此事件告一段落,再次给大家说声抱歉了,由于我们的大意,给大家的使用带来不便了。

另外,大家以后上网也要保护好自己账户的安全,现在钓鱼邮件太多,陌生人发的邮件链接,千万不要随便点,陌生人发的邮件链接,千万不要随便点,陌生人发的邮件链接,千万不要随便点。

最后再次感谢大家对infinitynewtab的支持。

最后插件一定要从官网或者从Chrome商店下载。切勿从其它渠道下载。

免责声明:本站提供安全工具、程序(方法)可能带有攻击性,仅供安全研究与教学之用,风险自负!该破解版仅用于个人尝鲜测试使用用,请支持正版!

awvs.jpg

Acunetix Web Vulnerability Scanner(简称AWVS)是一款知名的网络漏洞扫描工具,它通过网络爬虫测试你的网站安全,检测流行安全漏洞。

由于官方下载正版不敢提供直接升级了,所以只有等小伙伴分享出来,再把正版安装包放网盘吧,由于官方的试用版是不带有注册功能的,建议先卸载老版本,再通过论坛下载最新的企业版安装包安装,,安装完成后关闭程序打开破解补丁,点Patch后可正常注册了,注册后支持正常升级。

如果界面字体挡住按钮,请将系统字体DPI调成正常,重新打开软件即可

Acunetix Web Vulnerability Scanner 11.x Service Provider License KeyGen By Hmily[LCG].exe
MD5: 52BC7C27598D86197DC5EC4663DFF214

aww.jpg

下载地址

链接:http://pan.baidu.com/s/1c1JoyBm 密码:hyue (请自行检测程序安全性)

破解来自

Acunetix Web Vulnerability Scanner 11.x KeyGen By Hmily[LCG] 

http://www.52pojie.cn/thread-609275-1-1.html

E-Mail:Hmily[at]52PoJie.Cn

吾爱破解论坛:http://www.52pojie.cn

*本文投稿作者:linger118927,以上下载内容请勿用于非法及商业用途,测试后请尽快删除,转载请注明来自FreeBuf.COM

要说今年最具看点的信息安全大会,非SyScan360莫属。北京时间5月31日凌晨,为期两天的SyScan360在美国西雅图开幕,来自谷歌、微软、Intel、McAfee、360、盘古等众多国内外公司的网络安全专家和顶级黑客齐聚一堂,分享安全圈备受关注的前沿话题。

SyScan360黑客大会为何招来FBI?细数它犯的这几宗“最”

这是国内厂商首次在海外举办技术峰会,阵势毫不含糊。微软、谷歌、Intel、McAfee、CheckPoint、360、盘古、常春藤名校等各门派的顶尖高手论道安全武林;两天的议程囊括了系统、移动、网络、硬件、IoT、机器学习等全领域13大热点话题,堪称史上最具性价比的“干货”盛会。 

顶尖黑客齐聚一堂,甚至引来FBI现场全程监控。FBI表示:此次活动虽然没有违法迹象,不过这么多黑客聚集在一起,我们是肯定要监控的。想知道大会中究竟有哪些猛料,让FBI都坐不住了?接下来,我们就为没能赶到现场的你解锁SyScan360搞的大事情。 

1.png

图:外媒报道SyScan360引发FBI现场监控

最吊诡:“不可利用”漏洞竟能实现全球首破谷歌Pixel

被称为“谷歌亲儿子”的智能手机Pixel可谓集万千宠爱于一身,对安全性极为重视的谷歌在Pixel的安全保护上重兵布阵。但铜墙铁壁的保护竟然被Chrome V8引擎中一个微不足道的逻辑错误漏洞攻破了! 360手机卫士Alpha Team的龚广就是这场奇迹的幕后作者,在议题“Butterfly Effect and Program Mistake-Exploit an ‘Unexploitable’ Chrome Bug”中,他还原了这场蝴蝶振翅引发的安全风暴,利用近乎不可能的漏洞(CVE-2016-9581)和多种奇特的利用技巧,最终用时不到60秒,就在PwnFest世界黑客大赛上实现了全球首破Pixel。

最热点:除了战胜棋王,人工智能挖洞技术也很强悍!

最近,“世界第一围棋AI”AlphaGo与中国围棋职业九段棋手柯洁的人机大战落幕,人工智能完胜人类棋王,并又强硬地刷了一波热搜。如今,人工智能在各个领域逐渐深入,在挖漏洞方面也表现不俗。来自美国乔治亚大学的李康教授在“Enhancing Symbolic Fuzzing withLearning”中就现场传授了借助机器学习增强Fuzzing性能的前沿课题,并首次披露了实验人工智能技术进行漏洞挖掘的实例。 

最惊悚:你盯着字幕时,字幕背后也有人盯着你

夜半时分,当你正盯着字幕看电影时,一双心怀叵测的眼睛正透过字幕紧紧盯着你。听到著名安全公司Check Point研究人员OmriHerscovici和Omer Gull带来的议题“Pwned in Translation – from Subtitles to RCE”时,即便是参会经验丰富的老江湖,也会一瞬间以为自己错走入恐怖片片场。

字幕为何成为黑客实施监控的新工具?实际上,现代字幕文件格式已经非常复杂,它允许支持大量的特效和功能,而各个播放器在实现字幕渲染时又没有统一的标准,代码的安全性完全由播放器开发者保证,这就给了黑客以可趁之机。通过字幕渲染漏洞,只需要一个字幕文件,就能完全控制播放器用户或者播放平台系统,进而为所欲为。

最科幻:1000美元监控全城,就算断网也无处可逃!

《速度与激情8》中,有个由多个联网摄像头组成的“天眼”监控系统,它能整合全球所有的数据采集、监控设备,通过手机音频、监控摄像头再加上大数据和人脸识别技术,瞬间把要找的人定位出来。

 听起来极为酷炫的黑客“千里眼”创意在SyScan360上演了现实版,而令人大跌眼镜的是,这套设备竟然只需要1000美元。没错!你可能认为监听网络数据需要投入国家级的技术力量,但Securing Hardware的研究员Joe FitzPatrick却实现了低成本监控数字痕迹信息,即便从不使用数字设备的偏执狂们也难逃天眼追踪。

最危急:全球服务器安全告急,谷歌全栈大神剖析内幕

谷歌安全工程团队负责人、网络安全领域最全能的顶级黑客Fermin J.Serna分享的是Linux系统最底层的基础库Glibc的漏洞(CVE-2015-7547)的细节。由于Google服务器配置错误发现的这一漏洞,如今已通过远程未经身份验证的方式影响了全球一半基于Linux的网络。

正因威力巨大,Fermin凭该漏洞获得了2016年“黑客奥斯卡”——Pwnie奖的金奖。当然,这不是Fermin第一次获得Pwnie的垂青,从Windows操作系统内核,到浏览器、Flash插件、服务器系统、库等多个领域发现大量安全漏洞,Fermin多次获得“黑客奥斯卡”的青睐。

最反差:三好学生Office化身APT狂魔

 如果说软件也有性格,那么Office一定能上榜“最老实软件排行榜”头几名。低调不张扬,务实不取宠应该是Office留给上班族和学生党的最初印象。此外,微软在Office安全上也进行了大量投入,包括著名的白盒审计工具等,消灭了大量可利用的漏洞,真实可用的Office内存漏洞如今十分罕见。

不过,看起来无害的Office一旦出现漏洞,那可是威力惊人。来自McAfee的资深研究员、网络安全行业杰出的华人代表Haifei Li和BingSun通过神奇的思维魔法,挖到了Office的逻辑漏洞,通过一个特殊的字符串,就可以远程控制Office,据说这一漏洞还可能被应用于APT攻击!

最高招:“神隐级”黑客上演Win10虚拟化逃逸屠龙绝技

 说到黑客,不免给人一种“大隐隐于市”的神秘感,虽然黑客群像面目模糊,但混安全圈的谁要是不认识将要介绍的这位大神,恐怕就要露怯了。Alex Ionescu可能是全球Windows安全领域最厉害的专家。他不满20岁就领导了完全复制Windows系统的ReactOS开源项目,如今他是安全公司CrowdStrike的战略副总裁,还是BlackHat等安全盛会的保留讲师。

这位“神隐级”大师在SyScan360上带来的压轴议题堪称难度“超纲”。他不仅向全球首次公开了微软最新的虚拟化技术内部细节,还实现了全球首个Win10虚拟机到宿主机的逃逸攻击。被认为黑客圈屠龙之术的虚拟机逃逸就被Alex在弹指间轻松完成,这一套行云流水的攻击让现场观众大饱眼福。

经常被遗忘(或被误解)的一个事实是,大多数对象及其属性可以被验证的用户(通常是域用户)查看(或读取)。管理员可能会认为,由于通过管理工具(如“Active Directory用户和计算机”(dsa.msc)或“Active Directory管理中心”(dsac.msc))可以轻松访问此数据,因此其他人就无法查看用户数据(超出了Outlook的GAL中暴露的内容)。这通常导致密码数据被放置在用户对象属性或SYSVOL中

Active Directory中可以收集大量数据,可用于更新文档或对下一个攻击阶段的环境进行侦察。防守者通过常规用户帐户了解AD中可访问的不同类型的数据是很重要的一件事情。

攻击频繁地开始于网络钓鱼邮件使得攻击者可以在目标网络中的计算机上运行代码。一旦攻击者将其代码运行在企业内部,第一步就是进行信息侦察,以发现有用的资源来提升权限,持续控制,当然还有“掠夺”信息(通常是组织的“重要部门”)。

这篇文章将会阐述攻击者如何在只有域用户权限的情况下来对Active Directory环境进行信息侦察。许多人对于无需提升权限就能从AD中收集信息时感到非常惊讶。

注意:本文中的大多数示例都使用Active Directory PowerShell模块cmdlet。一个很好的选择是使用HarmJ0y的 PowerView(现在是PowerSploit的一部分)。

在2015年的几次安全会议(BSides,Shakacon,Black Hat,DEF CON和DerbyCon)中谈到了一些相关的技术。我还介绍了“ 最常见的Active Directory安全问题和可以解决的问题”中的一些问题。

获取Active Directory信息

我已经在PowerShell中使用.NET来收集AD数据,所以我不会在这里复制所有的.NET命令。

域林信息:

PS C:> [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
Name: lab.adsecurity.org Sites: {Default-First-Site-Name} Domains: {lab.adsecurity.org, child.lab.adsecurity.org} GlobalCatalogs: {ADSDC01.lab.adsecurity.org, ADSDC02.lab.adsecurity.org, ADSDC03.lab.adsecurity.org, ADSDC11.child.lab.adsecurity.org} ApplicationPartitions: {DC=DomainDnsZones,DC=child,DC=lab,DC=adsecurity,DC=org, DC=DomainDnsZones,DC=lab,DC=adsecurity,DC=org, DC=ForestDnsZones,DC=lab,DC=adsecurity,DC=org} ForestMode: Windows2008R2Forest RootDomain: lab.adsecurity.org Schema: CN=Schema,CN=Configuration,DC=lab,DC=adsecurity,DC=org SchemaRoleOwner: ADSDC03.lab.adsecurity.org NamingRoleOwner: ADSDC03.lab.adsecurity.org

域信息:

PS C:> [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
Forest: lab.adsecurity.org DomainControllers: {ADSDC01.lab.adsecurity.org, ADSDC02.lab.adsecurity.org, ADSDC03.lab.adsecurity.org} Children: {child.lab.adsecurity.org} DomainMode: Windows2008R2Domain Parent: PdcRoleOwner: ADSDC03.lab.adsecurity.org RidRoleOwner: ADSDC03.lab.adsecurity.org InfrastructureRoleOwner: ADSDC03.lab.adsecurity.org Name: lab.adsecurity.org

域林信任:

$ForestRootDomain = ‘lab.adsecurity.org’
 ([System.DirectoryServices.ActiveDirectory.Forest]::GetForest((New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext(‘Forest’, $ForestRootDomain)))).GetAllTrustRelationships()

域信任:

PS C:> ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()
SourceName:    lab.adsecurity.org TargetName: child.lab.adsecurity.org TrustType:   ParentChild TrustDirection: Bidirectional

获取域林全局目录(通常每个域控制器就是一个GC):

PS C:> [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs
Forest                     : lab.adsecurity.org CurrentTime                : 1/27/2016 5:31:36 PM HighestCommittedUsn        : 305210 OSVersion                  : Windows Server 2008 R2 Datacenter Roles                      : {} Domain                     : lab.adsecurity.org IPAddress                  : 172.16.11.11 SiteName                   : Default-First-Site-Name SyncFromAllServersCallback : InboundConnections         : {36bfdadf-777d-4bad-9427-bc148cea256f, 48594a5d-c2a3-4cd1-a80d-bedf367cc2a9, 549871d2-e238-4423-a6b8-1bb OutboundConnections        : {9da361fd-0eed-414a-b4ee-0a9caa1b153e, 86690811-f995-4c3e-89fe-73c61fa4a3a0, 8797cbb4-fe09-49dc-8891-952 Name                       : ADSDC01.lab.adsecurity.org Partitions                 : {DC=lab,DC=adsecurity,DC=org, CN=Configuration,DC=lab,DC=adsecurity,DC=org, CN=Schema,CN=Configuration,DC=lab,DC=adsecurity,DC=org, DC=DomainDnsZones,DC=lab,DC=adsecurity,DC=org…
Forest                     : lab.adsecurity.org CurrentTime                : 1/27/2016 5:31:37 PM HighestCommittedUsn        : 274976 OSVersion                  : Windows Server 2012 R2 Datacenter Roles                      : {SchemaRole, NamingRole, PdcRole, RidRole…} Domain                     : lab.adsecurity.org IPAddress                  : fe80::1881:40d5:fc2e:e744%12 SiteName                   : Default-First-Site-Name SyncFromAllServersCallback : InboundConnections         : {86690811-f995-4c3e-89fe-73c61fa4a3a0, dd7b36a8-a52e-446d-95a8-318b69bd9765} OutboundConnections        : {f901f0b5-8754-44e9-92e8-f56b3d67197b, 549871d2-e238-4423-a6b8-1bb258e2a62f} Name                       : ADSDC03.lab.adsecurity.org Partitions                 : {DC=lab,DC=adsecurity,DC=org, CN=Configuration,DC=lab,DC=adsecurity,DC=org, CN=Schema,CN=Configuration,DC=lab,DC=adsecurity,DC=org, DC=DomainDnsZones,DC=lab,DC=adsecurity,DC=org…
Forest                     : lab.adsecurity.org CurrentTime                : 1/27/2016 5:31:38 PM HighestCommittedUsn        : 161898 OSVersion                  : Windows Server 2012 R2 Datacenter Roles                      : {PdcRole, RidRole, InfrastructureRole} Domain                     : child.lab.adsecurity.org IPAddress                  : 172.16.11.21 SiteName                   : Default-First-Site-Name SyncFromAllServersCallback : InboundConnections         : {612c2d75-1c35-4073-a8a9-d41169665000, 8797cbb4-fe09-49dc-8891-952f38822eda} OutboundConnections        : {71ea129f-8d56-4bd0-9b68-d80e89ae7385, 36bfdadf-777d-4bad-9427-bc148cea256f} Name                       : ADSDC11.child.lab.adsecurity.org Partitions                 : {CN=Configuration,DC=lab,DC=adsecurity,DC=org, CN=Schema,CN=Configuration,DC=lab,DC=adsecurity,DC=org, DC=ForestDnsZones,DC=lab,DC=adsecurity,DC=org, DC=child,DC=lab,DC=adsecurity,DC=org…}

缓解措施:没有合理的缓解措施。这些信息不能也不应该被模糊或隐藏。

发现企业服务,无需网络扫描

最简单的信息侦察方法是使用我称之为“ SPN扫描 ”的技术,它要求域控制器查找特定类型的所有服务主体名称(SPN)。这样可以让攻击者发现所有的SQL服务器,Exchange服务器等等。我维护了一个包含企业中最常见的SPNSPN目录列表

SPN扫描还可以发现Windows计算机中是否启用了RDP(TERMSERV)和WinRM(WSMAN)等信息。

注意:为了发现所有企业服务,需要同时指定计算机和用户(服务帐户)。

PS C:> get-adcomputer -filter {ServicePrincipalName -like “*TERMSRV*”} -Properties OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack, PasswordLastSet,LastLogonDate,ServicePrincipalName,TrustedForDelegation,TrustedtoAuthForDelegation
DistinguishedName          : CN=ADSDC02,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSDC02.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 6:46:18 AM Name                       : ADSDC02 ObjectClass                : computer ObjectGUID                 : 1efe44af-d8d9-420b-a66a-8d771d295085 OperatingSystem            : Windows Server 2008 R2 Datacenter OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 12/31/2015 6:34:15 AM SamAccountName             : ADSDC02$ ServicePrincipalName       : {DNS/ADSDC02.lab.adsecurity.org, HOST/ADSDC02/ADSECLAB, HOST/ADSDC02.lab.adsecurity.org/ADSECLAB, GC/ADSDC02.lab.adsecurity.org/lab.adsecurity.org…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1103 TrustedForDelegation       : True TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSDC01,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSDC01.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 6:47:21 AM Name                       : ADSDC01 ObjectClass                : computer ObjectGUID                 : 31b2038d-e63d-4cfe-b7b6-77206c325af9 OperatingSystem            : Windows Server 2008 R2 Datacenter OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 12/31/2015 6:34:14 AM SamAccountName             : ADSDC01$ ServicePrincipalName       : {ldap/ADSDC01.lab.adsecurity.org/ForestDnsZones.lab.adsecurity.org, ldap/ADSDC01.lab.adsecurity.org/DomainDnsZones.lab.adsecurity.org, TERMSRV/ADSDC01, TERMSRV/ADSDC01.lab.adsecurity.org…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1000 TrustedForDelegation       : True TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSDC03,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSDC03.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 6:35:16 AM Name                       : ADSDC03 ObjectClass                : computer ObjectGUID                 : 0a2d849c-cc59-4785-8ba2-997fd6ca4dc8 OperatingSystem            : Windows Server 2012 R2 Datacenter OperatingSystemServicePack : OperatingSystemVersion     : 6.3 (9600) PasswordLastSet            : 12/31/2015 6:34:16 AM SamAccountName             : ADSDC03$ ServicePrincipalName       : {DNS/ADSDC03.lab.adsecurity.org, HOST/ADSDC03.lab.adsecurity.org/ADSECLAB, RPC/c8e1e99e-2aaa-4888-a5d8-23a4355fac48._msdcs.lab.adsecurity.org, GC/ADSDC03.lab.adsecurity.org/lab.adsecurity.org…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1601 TrustedForDelegation       : True TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSWRKWIN7,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSWRKWIN7.lab.adsecurity.org Enabled                    : True LastLogonDate              : 8/29/2015 6:40:16 PM Name                       : ADSWRKWIN7 ObjectClass                : computer ObjectGUID                 : e8b3bed2-75b4-4512-a4f0-6d9c2d975c70 OperatingSystem            : Windows 7 Enterprise OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 8/29/2015 6:40:12 PM SamAccountName             : ADSWRKWIN7$ ServicePrincipalName       : {TERMSRV/ADSWRKWin7.lab.adsecurity.org, TERMSRV/ADSWRKWIN7, RestrictedKrbHost/ADSWRKWIN7, HOST/ADSWRKWIN7…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1104 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSAP01,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSAP01.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/24/2016 11:03:41 AM Name                       : ADSAP01 ObjectClass                : computer ObjectGUID                 : b79bb5e3-8f9e-4ee0-a30c-5f66b61da681 OperatingSystem            : Windows Server 2008 R2 Datacenter OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 1/4/2016 6:38:16 AM SamAccountName             : ADSAP01$ ServicePrincipalName       : {WSMAN/ADSAP01.lab.adsecurity.org, WSMAN/ADSAP01, TERMSRV/ADSAP01.lab.adsecurity.org, TERMSRV/ADSAP01…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1105 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSWKWIN7,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSWKWIN7.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 7:07:11 AM Name                       : ADSWKWIN7 ObjectClass                : computer ObjectGUID                 : 2f164d63-d721-4b0e-a553-3ca0e272aa96 OperatingSystem            : Windows 7 Enterprise OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 12/31/2015 8:03:05 AM SamAccountName             : ADSWKWIN7$ ServicePrincipalName       : {TERMSRV/ADSWKWin7.lab.adsecurity.org, TERMSRV/ADSWKWIN7, RestrictedKrbHost/ADSWKWIN7, HOST/ADSWKWIN7…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1602 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSAP02,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSAP02.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/24/2016 7:39:48 AM Name                       : ADSAP02 ObjectClass                : computer ObjectGUID                 : 1006978e-8627-4d01-98b6-3215c4ee4541 OperatingSystem            : Windows Server 2012 R2 Datacenter OperatingSystemServicePack : OperatingSystemVersion     : 6.3 (9600) PasswordLastSet            : 1/4/2016 6:39:25 AM SamAccountName             : ADSAP02$ ServicePrincipalName       : {WSMAN/ADSAP02.lab.adsecurity.org, WSMAN/ADSAP02, TERMSRV/ADSAP02.lab.adsecurity.org, TERMSRV/ADSAP02…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1603 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :

缓解措施:没有缓解措施。服务主体名称是Kerberos工作所必需的东西。

无需网络扫描发现企业服务第2部分

SPN扫描能够发现支持Kerberos的所有企业服务。与Active Directory集成的其他企业服务通常会在域“系统”容器(CN = System,DC = < domain >)中创建一个新的容器。在域系统容器中存储数据的一些企业应用程序包括:SCCM:“系统管理”

有一些应用程序,如Exchange,在域林配置分区“服务”容器(CN = Services,CN = Configuration,DC = < domain >)中创建容器。

缓解措施:没有合适的缓解措施。

发现服务帐户

找到服务帐户和使用帐户的服务器的最快方法是使用服务主体名称的用户帐户进行SPN扫描。

的GitHub存储库中的Find-PSServiceAccounts PowerShell脚本可以执行sme查询,而不需要AD PowerShell模块。

PS C:> get-aduser -filter {ServicePrincipalName -like “*”} -Properties PasswordLastSet,LastLogonDate,ServicePrincipalName,TrustedForDelegation,Truste dtoAuthForDelegation
DistinguishedName          : CN=svc-adsMSSQL11,OU=Test,DC=lab,DC=adsecurity,DC=org Enabled                    : False GivenName                  : LastLogonDate              : Name                       : svc-adsMSSQL11 ObjectClass                : user ObjectGUID                 : 275d3bf4-80d3-42ba-9d77-405c5cc63c07 PasswordLastSet            : 1/4/2016 7:13:03 AM SamAccountName             : svc-adsMSSQL11 ServicePrincipalName       : {MSSQL/adsMSSQL11.lab.adsecurity.org:7434} SID                        : S-1-5-21-1581655573-3923512380-696647894-3601 Surname                    : TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=svc-adsSQLSA,OU=Test,DC=lab,DC=adsecurity,DC=org Enabled                    : False GivenName                  : LastLogonDate              : Name                       : svc-adsSQLSA ObjectClass                : user ObjectGUID                 : 56faaab2-5b05-4bb2-aaea-0bdc1409eab3 PasswordLastSet            : 1/4/2016 7:13:13 AM SamAccountName             : svc-adsSQLSA ServicePrincipalName       : {MSSQL/adsMSSQL23.lab.adsecurity.org:7434, MSSQL/adsMSSQL22.lab.adsecurity.org:5534,                            MSSQL/adsMSSQL21.lab.adsecurity.org:9834, MSSQL/adsMSSQL10.lab.adsecurity.org:14434…} SID                        : S-1-5-21-1581655573-3923512380-696647894-3602 Surname                    : TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=svc-adsMSSQL10,OU=Test,DC=lab,DC=adsecurity,DC=org Enabled                    : False GivenName                  : LastLogonDate              : Name                       : svc-adsMSSQL10 ObjectClass                : user ObjectGUID                 : 6c2f15a2-ba4a-485a-a367-39395ad82c86 PasswordLastSet            : 1/4/2016 7:13:24 AM SamAccountName             : svc-adsMSSQL10 ServicePrincipalName       : {MSSQL/adsMSSQL10.lab.adsecurity.org:7434} SID                        : S-1-5-21-1581655573-3923512380-696647894-3603 Surname                    : TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :

缓解措施:没有合适的缓解措施。

无需网络扫描发现内网计算机

每个连接Active Directory的计算机在AD中都有一个关联的计算机帐户。当计算机加入时,有几个与此计算机对象关联的属性会被更新,其中几个是非常有用的。这些包括:

Created
Modified
Enabled
Description
LastLogonDate (Reboot)
PrimaryGroupID       (516 = DC)
PasswordLastSet       (Active/Inactive)OperatingSystem
OperatingSystemVersion
OperatingSystemServicePack
PasswordLastSet
LastLogonDate (PowerShell cmdlet      attribute)
ServicePrincipalName
TrustedForDelegation
TrustedToAuthForDelegation
PS C:> get-adcomputer -filter {PrimaryGroupID -eq “515”} -Properties OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack,Passwo t,LastLogonDate,ServicePrincipalName,TrustedForDelegation,TrustedtoAuthForDelegation
DistinguishedName          : CN=ADSWRKWIN7,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSWRKWIN7.lab.adsecurity.org Enabled                    : True LastLogonDate              : 8/29/2015 6:40:16 PM Name                       : ADSWRKWIN7 ObjectClass                : computer ObjectGUID                 : e8b3bed2-75b4-4512-a4f0-6d9c2d975c70 OperatingSystem            : Windows 7 Enterprise OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 8/29/2015 6:40:12 PM SamAccountName             : ADSWRKWIN7$ ServicePrincipalName       : {TERMSRV/ADSWRKWin7.lab.adsecurity.org, TERMSRV/ADSWRKWIN7, RestrictedKrbHost/ADSWRKWIN7, HOST/ADSWRKWIN7…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1104 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSAP01,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSAP01.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/24/2016 11:03:41 AM Name                       : ADSAP01 ObjectClass                : computer ObjectGUID                 : b79bb5e3-8f9e-4ee0-a30c-5f66b61da681 OperatingSystem            : Windows Server 2008 R2 Datacenter OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 1/4/2016 6:38:16 AM SamAccountName             : ADSAP01$ ServicePrincipalName       : {WSMAN/ADSAP01.lab.adsecurity.org, WSMAN/ADSAP01, TERMSRV/ADSAP01.lab.adsecurity.org, TERMSRV/ADSAP01…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1105 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSWKWIN7,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSWKWIN7.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 7:07:11 AM Name                       : ADSWKWIN7 ObjectClass                : computer ObjectGUID                 : 2f164d63-d721-4b0e-a553-3ca0e272aa96 OperatingSystem            : Windows 7 Enterprise OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 12/31/2015 8:03:05 AM SamAccountName             : ADSWKWIN7$ ServicePrincipalName       : {TERMSRV/ADSWKWin7.lab.adsecurity.org, TERMSRV/ADSWKWIN7, RestrictedKrbHost/ADSWKWIN7, HOST/ADSWKWIN7…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1602 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSAP02,CN=Computers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSAP02.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/24/2016 7:39:48 AM Name                       : ADSAP02 ObjectClass                : computer ObjectGUID                 : 1006978e-8627-4d01-98b6-3215c4ee4541 OperatingSystem            : Windows Server 2012 R2 Datacenter OperatingSystemServicePack : OperatingSystemVersion     : 6.3 (9600) PasswordLastSet            : 1/4/2016 6:39:25 AM SamAccountName             : ADSAP02$ ServicePrincipalName       : {WSMAN/ADSAP02.lab.adsecurity.org, WSMAN/ADSAP02, TERMSRV/ADSAP02.lab.adsecurity.org, TERMSRV/ADSAP02…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1603 TrustedForDelegation       : False TrustedToAuthForDelegation : False UserPrincipalName          :

通过将PrimaryGroupID的值更改为“516”,或通过更改为“-filter *”获取所有计算机,可以收集域控制器的相同数据。

PS C:> get-adcomputer -filter {PrimaryGroupID -eq “516”} -Properties OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack,PasswordLastSe t,LastLogonDate,ServicePrincipalName,TrustedForDelegation,TrustedtoAuthForDelegation
DistinguishedName          : CN=ADSDC02,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSDC02.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 6:46:18 AM Name                       : ADSDC02 ObjectClass                : computer ObjectGUID                 : 1efe44af-d8d9-420b-a66a-8d771d295085 OperatingSystem            : Windows Server 2008 R2 Datacenter OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 12/31/2015 6:34:15 AM SamAccountName             : ADSDC02$ ServicePrincipalName       : {DNS/ADSDC02.lab.adsecurity.org, HOST/ADSDC02/ADSECLAB, HOST/ADSDC02.lab.adsecurity.org/ADSECLAB, GC/ADSDC02.lab.adsecurity.org/lab.adsecurity.org…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1103 TrustedForDelegation       : True TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSDC01,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSDC01.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 6:47:21 AM Name                       : ADSDC01 ObjectClass                : computer ObjectGUID                 : 31b2038d-e63d-4cfe-b7b6-77206c325af9 OperatingSystem            : Windows Server 2008 R2 Datacenter OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601) PasswordLastSet            : 12/31/2015 6:34:14 AM SamAccountName             : ADSDC01$ ServicePrincipalName       : {ldap/ADSDC01.lab.adsecurity.org/ForestDnsZones.lab.adsecurity.org, ldap/ADSDC01.lab.adsecurity.org/DomainDnsZones.lab.adsecurity.org, TERMSRV/ADSDC01, TERMSRV/ADSDC01.lab.adsecurity.org…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1000 TrustedForDelegation       : True TrustedToAuthForDelegation : False UserPrincipalName          :
DistinguishedName          : CN=ADSDC03,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org DNSHostName                : ADSDC03.lab.adsecurity.org Enabled                    : True LastLogonDate              : 1/20/2016 6:35:16 AM Name                       : ADSDC03 ObjectClass                : computer ObjectGUID                 : 0a2d849c-cc59-4785-8ba2-997fd6ca4dc8 OperatingSystem            : Windows Server 2012 R2 Datacenter OperatingSystemServicePack : OperatingSystemVersion     : 6.3 (9600) PasswordLastSet            : 12/31/2015 6:34:16 AM SamAccountName             : ADSDC03$ ServicePrincipalName       : {DNS/ADSDC03.lab.adsecurity.org, HOST/ADSDC03.lab.adsecurity.org/ADSECLAB, RPC/c8e1e99e-2aaa-4888-a5d8-23a4355fac48._msdcs.lab.adsecurity.org, GC/ADSDC03.lab.adsecurity.org/lab.adsecurity.org…} SID                        : S-1-5-21-1581655573-3923512380-696647894-1601 TrustedForDelegation       : True TrustedToAuthForDelegation : False UserPrincipalName          :

这提供了有关Windows操作系统版本以及加入Active Directory的非Windows设备的有用信息。

查找非Windows设备的一些查询示例:

OperatingSystem -Like “*Samba*”
OperatingSystem -Like “*OnTap*”
OperatingSystem -Like “*Data Domain*”
OperatingSystem -Like “*EMC*”
OperatingSystem -Like “*Windows NT*”

缓解措施:没有缓解措施。

识别管理员帐户

有两种有效的方法可以在Active Directory中发现具有较高权限的帐户。第一个是标准组枚举方法,用于标识Active Directory管理员组的所有成员:域管理员,管理员,企业管理员等。通常,域“Adminsitrators”组的递归组成员资格将提供所有AD管理员的列表。

第二种方法,我在2015年DerbyCon中强调的涉及到将所有属性“AdminCount”设置为1的所有帐户。要注意的是,在此查询中可能会返回不再具有管理员权限的帐户,因为该值对应的帐户如果从管理组中删除后,不会自动重置。可以在这篇博文中查看有关SDProp和AdminCount属性的更多信息:“ Active Directory内网渗透权限持久控制#15:利用AdminSDHolder和SDProp(Re)获得域管理员权限 ”。

PS C:> get-aduser -filter {AdminCount -eq 1} -Properties Name,AdminCount,ServicePrincipalName,PasswordLastSet,LastLogonDate,MemberOf
AdminCount        : 1 DistinguishedName : CN=ADSAdministrator,CN=Users,DC=lab,DC=adsecurity,DC=org Enabled           : True GivenName         : LastLogonDate     : 1/27/2016 8:55:48 AM MemberOf          : {CN=Administrators,CN=Builtin,DC=lab,DC=adsecurity,DC=org, CN=Schema Admins,CN=Users,DC=lab,DC=adsecurity,DC=org, CN=Group Policy Creator Owners,CN=Users,DC=lab,DC=adsecurity,DC=org, CN=Enterprise Admins,CN=Users,DC=lab,DC=adsecurity,DC=org…} Name              : ADSAdministrator ObjectClass       : user ObjectGUID        : 72ac7731-0a76-4e5a-8e5d-b4ded9a304b5 PasswordLastSet   : 12/31/2015 8:45:27 AM SamAccountName    : ADSAdministrator SID               : S-1-5-21-1581655573-3923512380-696647894-500 Surname           : UserPrincipalName :
AdminCount           : 1 DistinguishedName    : CN=krbtgt,CN=Users,DC=lab,DC=adsecurity,DC=org Enabled              : False GivenName            : LastLogonDate        : MemberOf             : {CN=Denied RODC Password Replication Group,CN=Users,DC=lab,DC=adsecurity,DC=org} Name                 : krbtgt ObjectClass          : user ObjectGUID           : 3d5be8dd-df7f-4f84-b2cf-4556310a7292 PasswordLastSet      : 8/27/2015 7:10:22 PM SamAccountName       : krbtgt ServicePrincipalName : {kadmin/changepw} SID                  : S-1-5-21-1581655573-3923512380-696647894-502 Surname              : UserPrincipalName    :
AdminCount        : 1 DistinguishedName : CN=LukeSkywalker,OU=AD Management,DC=lab,DC=adsecurity,DC=org Enabled           : True GivenName         : LastLogonDate     : 8/29/2015 7:29:52 PM MemberOf          : {CN=Domain Admins,CN=Users,DC=lab,DC=adsecurity,DC=org} Name              : LukeSkywalker ObjectClass       : user ObjectGUID        : 32b5226b-aa6d-4b35-a031-ddbcbde07137 PasswordLastSet   : 8/29/2015 7:26:02 PM SamAccountName    : LukeSkywalker SID               : S-1-5-21-1581655573-3923512380-696647894-2629 Surname           : UserPrincipalName :

注意:这些方法不会返回带有自定义委托的管理员帐户 ——管理帐户根本不是标准AD组的成员。

缓解措施:没有缓解措施。期望攻击者更多地去了解哪些帐户拥有着重要资源的权限。

查找管理员组

大多数组织都有自定义的管理员组,并具有不同的命名方案,但是在大多数组织的命名中都包括单词“admin”。在所有的安全用户组的组名中使用“admin”进行筛选是快速获取AD中管理员组列表的方式。

PS C:> get-adgroup -filter {GroupCategory -eq ‘Security’ -AND Name -like “*admin*”}
DistinguishedName : CN=Domain Admins,CN=Users,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : Global Name : Domain Admins ObjectClass : group ObjectGUID : 5621cc71-d318-4e2c-b1b1-c181f630e10e SamAccountName : Domain Admins SID : S-1-5-21-1581655573-3923512380-696647894-512
DistinguishedName : CN=Workstation Admins,OU=AD Management,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : Global Name : Workstation Admins ObjectClass : group ObjectGUID : 88cd4d52-aedb-4f90-9ebd-02d4c0e322e4 SamAccountName : WorkstationAdmins SID : S-1-5-21-1581655573-3923512380-696647894-2627
DistinguishedName : CN=Server Admins,OU=AD Management,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : Global Name : Server Admins ObjectClass : group ObjectGUID : 3877c311-9321-41c0-a6b5-c0d88684b335 SamAccountName : ServerAdmins SID : S-1-5-21-1581655573-3923512380-696647894-2628
DistinguishedName : CN=DnsAdmins,CN=Users,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : DomainLocal Name : DnsAdmins ObjectClass : group ObjectGUID : 46caa0dd-6a22-42a3-a2d9-bd467934aab5 SamAccountName : DnsAdmins SID : S-1-5-21-1581655573-3923512380-696647894-1101
DistinguishedName : CN=Administrators,CN=Builtin,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : DomainLocal Name : Administrators ObjectClass : group ObjectGUID : d03a4afc-b14e-48c6-893c-bbc1ac872ca2 SamAccountName : Administrators SID : S-1-5-32-544
DistinguishedName : CN=Hyper-V Administrators,CN=Builtin,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : DomainLocal Name : Hyper-V Administrators ObjectClass : group ObjectGUID : 3137943e-f1c3-46d0-acf2-4711bf6f8417 SamAccountName : Hyper-V Administrators SID : S-1-5-32-578
DistinguishedName : CN=Enterprise Admins,CN=Users,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : Universal Name : Enterprise Admins ObjectClass : group ObjectGUID : 7674d6ad-777b-4db1-9fe3-e31fd664eb6e SamAccountName : Enterprise Admins SID : S-1-5-21-1581655573-3923512380-696647894-519
DistinguishedName : CN=Schema Admins,CN=Users,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : Universal Name : Schema Admins ObjectClass : group ObjectGUID : 420e8ee5-77f5-43b8-9f51-cde3feea0662 SamAccountName : Schema Admins SID : S-1-5-21-1581655573-3923512380-696647894-518

识别合作伙伴组织

外部电子邮件地址会被添加到企业组织的全局地址列表(GAL)中,以促进合作组织之间的协作。这些电子邮件地址在Active Directory中创建为联系人对象。

PS C:> get-adobject -filter {ObjectClass -eq “Contact”} -Prop *
CanonicalName                   : lab.adsecurity.org/Contaxts/Admiral Ackbar CN                              : Admiral Ackbar Created                         : 1/27/2016 10:00:06 AM createTimeStamp                 : 1/27/2016 10:00:06 AM Deleted                         : Description                     : DisplayName                     : DistinguishedName               : CN=Admiral Ackbar,OU=Contaxts,DC=lab,DC=adsecurity,DC=org dSCorePropagationData           : {12/31/1600 4:00:00 PM} givenName                       : Admiral instanceType                    : 4 isDeleted                       : LastKnownParent                 : mail                            : [email protected] Modified                        : 1/27/2016 10:00:24 AM modifyTimeStamp                 : 1/27/2016 10:00:24 AM Name                            : Admiral Ackbar nTSecurityDescriptor            : System.DirectoryServices.ActiveDirectorySecurity ObjectCategory                  : CN=Person,CN=Schema,CN=Configuration,DC=lab,DC=adsecurity,DC=org ObjectClass                     : contact ObjectGUID                      : 52c80a1d-a614-4889-92d4-1f588387d9f3 ProtectedFromAccidentalDeletion : False sDRightsEffective               : 15 sn                              : Ackbar uSNChanged                      : 275113 uSNCreated                      : 275112 whenChanged                     : 1/27/2016 10:00:24 AM whenCreated                     : 1/27/2016 10:00:06 AM
CanonicalName                   : lab.adsecurity.org/Contaxts/Leia Organa CN                              : Leia Organa Created                         : 1/27/2016 10:01:25 AM createTimeStamp                 : 1/27/2016 10:01:25 AM Deleted                         : Description                     : DisplayName                     : DistinguishedName               : CN=Leia Organa,OU=Contaxts,DC=lab,DC=adsecurity,DC=org dSCorePropagationData           : {12/31/1600 4:00:00 PM} givenName                       : Leia instanceType                    : 4 isDeleted                       : LastKnownParent                 : mail                            : [email protected] Modified                        : 1/27/2016 10:09:15 AM modifyTimeStamp                 : 1/27/2016 10:09:15 AM Name                            : Leia Organa nTSecurityDescriptor            : System.DirectoryServices.ActiveDirectorySecurity ObjectCategory                  : CN=Person,CN=Schema,CN=Configuration,DC=lab,DC=adsecurity,DC=org ObjectClass                     : contact ObjectGUID                      : ba8ec318-a0a2-41d5-923e-a3f646d1c7f9 ProtectedFromAccidentalDeletion : False sDRightsEffective               : 15 sn                              : Organa uSNChanged                      : 275157 uSNCreated                      : 275132 whenChanged                     : 1/27/2016 10:09:15 AM whenCreated                     : 1/27/2016 10:01:25 AM

缓解措施:唯一的缓解措施是不要在Active Directory中放置联系人对象,这可能是一个可选的办法。

识别域密码策略

使用“net accounts”或AD PowerShell模块“ Get-ADDefaultDomainPasswordPolicy ” 可以轻松的枚举域密码策略。

PS C:> Get-ADDefaultDomainPasswordPolicy
ComplexityEnabled           : True DistinguishedName           : DC=lab,DC=adsecurity,DC=org LockoutDuration             : 00:30:00 LockoutObservationWindow    : 00:30:00 LockoutThreshold            : 0 MaxPasswordAge              : 42.00:00:00 MinPasswordAge              : 1.00:00:00 MinPasswordLength           : 7 objectClass                 : {domainDNS} objectGuid                  : bbf0907c-3171-4448-b33a-76a48d859039 PasswordHistoryCount        : 24 ReversibleEncryptionEnabled : False

缓解措施:没有合理的缓解措施。

识别细粒度密码策略

如果域功能级别(DFL)设置的是“Windows Server 2008”或更高版本,则可以使用“细粒度密码策略(FGPP)”的新功能来提供可应用于用户或组的各种密码策略(不是OU)。虽然微软从Windows Server 2008(DFL)开始制定了细粒度密码策略,但Active Directory管理中心(ADAC)尚未更新,来支持Windows Server 2012之前的FGPP管理。从“查看”菜单启用Active Directory用户和计算机中的选项的“高级功能”,然后浏览到系统,密码设置容器(CN =密码设置容器,CN =系统,DC = DOMAIN,DC = COM)将会显示任何域的FGPP对象。请注意,如果未启用“高级功能”,则看不到系统容器。

FGPP覆盖域密码策略设置,可用于要求更严格的密码策略或为域用户子集启用较少限制的设置。

PS C:> Get-ADFineGrainedPasswordPolicy -Filter *
AppliesTo                   : {CN=Special FGPP Users,OU=Test,DC=lab,DC=adsecurity,DC=org} ComplexityEnabled           : True DistinguishedName           : CN=Special Password Policy Group,CN=Password Settings Container,CN=System,DC=lab,DC=adsecurity,DC=org LockoutDuration             : 12:00:00 LockoutObservationWindow    : 00:15:00 LockoutThreshold            : 10 MaxPasswordAge              : 00:00:00.0000365 MinPasswordAge              : 00:00:00 MinPasswordLength           : 7 Name                        : Special Password Policy Group ObjectClass                 : msDS-PasswordSettings ObjectGUID                  : c1301d8f-ba52-4bb3-b160-c449d9c7b8f8 PasswordHistoryCount        : 24 Precedence                  : 100 ReversibleEncryptionEnabled : True

缓解措施:没有合理的缓解措施。

识别托管服务帐户和组托管服务帐户

Microsoft将托管服务帐户( MSAs)添加为Windows Server 2008 R2 DFL的新功能,能够自动管理和更新MSA密码。关键的限制是MSA只能链接到运行Windows 7或Windows Server 2008 R2(或更新版本)的单台计算机。

Windows Server 2012 DFL向一个叫做组管理服务帐户(gMSA)的 MSA引入了需要的更新,使gMSA可以链接到运行Windows 8或Windows Server 2012(或更高版本)的任意数量的计算机。将DFL升级到Windows Server 2012或更高版本后,默认的AD服务帐户创建选项将创建一个新的gMSA(例如,使用AD PowerShell模块cmdlet New-ADServiceAccount)。在创建gMSA之前,需要创建KDS根密钥(Add-KDSRootKey -EffectiveImmediately)。

PS C:> Get-ADServiceAccount -Filter * -Properties *
AccountExpirationDate                      : 12/27/2017 11:14:38 AM accountExpires                             : 131588756787719890 AccountLockoutTime                         : AccountNotDelegated                        : False AllowReversiblePasswordEncryption          : False AuthenticationPolicy                       : {} AuthenticationPolicySilo                   : {} BadLogonCount                              : 0 badPasswordTime                            : 0 badPwdCount                                : 0 CannotChangePassword                       : False CanonicalName                              : lab.adsecurity.org/Managed Service Accounts/ADSMSA12 Certificates                               : {} CN                                         : ADSMSA12 codePage                                   : 0 CompoundIdentitySupported                  : {False} countryCode                                : 0 Created                                    : 1/27/2016 11:14:38 AM createTimeStamp                            : 1/27/2016 11:14:38 AM Deleted                                    : Description                                : gMSA for XYZ App DisplayName                                : ADSMSA12 DistinguishedName                          : CN=ADSMSA12,CN=Managed Service Accounts,DC=lab,DC=adsecurity,DC=org DNSHostName                                : ADSAP02.lab.adsecurity.org DoesNotRequirePreAuth                      : False dSCorePropagationData                      : {12/31/1600 4:00:00 PM} Enabled                                    : True HomedirRequired                            : False HomePage                                   : HostComputers                              : {} instanceType                               : 4 isCriticalSystemObject                     : False isDeleted                                  : KerberosEncryptionType                     : {RC4, AES128, AES256} LastBadPasswordAttempt                     : LastKnownParent                            : lastLogoff                                 : 0 lastLogon                                  : 0 LastLogonDate                              : localPolicyFlags                           : 0 LockedOut                                  : False logonCount                                 : 0 ManagedPasswordIntervalInDays              : {21} MemberOf                                   : {} MNSLogonAccount                            : False Modified                                   : 1/27/2016 11:14:39 AM modifyTimeStamp                            : 1/27/2016 11:14:39 AM msDS-ManagedPasswordId                     : {1, 0, 0, 0…} msDS-ManagedPasswordInterval               : 21 msDS-SupportedEncryptionTypes              : 28 msDS-User-Account-Control-Computed         : 0 Name                                       : ADSMSA12 nTSecurityDescriptor                       : System.DirectoryServices.ActiveDirectorySecurity ObjectCategory                             : CN=ms-DS-Group-Managed-Service-Account,CN=Schema,CN=Configuration,DC=lab,DC=adsecurity,DC=org ObjectClass                                : msDS-GroupManagedServiceAccount ObjectGUID                                 : fe4c287b-f9d2-45ce-abe3-4acd6d09c3ff objectSid                                  : S-1-5-21-1581655573-3923512380-696647894-3605 PasswordExpired                            : False PasswordLastSet                            : 1/27/2016 11:14:38 AM PasswordNeverExpires                       : False PasswordNotRequired                        : False PrimaryGroup                               : CN=Domain Computers,CN=Users,DC=lab,DC=adsecurity,DC=org primaryGroupID                             : 515 PrincipalsAllowedToDelegateToAccount       : {} PrincipalsAllowedToRetrieveManagedPassword : {} ProtectedFromAccidentalDeletion            : False pwdLastSet                                 : 130983956789440119 SamAccountName                             : ADSMSA12$ sAMAccountType                             : 805306369 sDRightsEffective                          : 15 ServicePrincipalNames                      : SID                                        : S-1-5-21-1581655573-3923512380-696647894-3605 SIDHistory                                 : {} TrustedForDelegation                       : False TrustedToAuthForDelegation                 : False UseDESKeyOnly                              : False userAccountControl                         : 4096 userCertificate                            : {} UserPrincipalName                          : uSNChanged                                 : 275383 uSNCreated                                 : 275380 whenChanged                                : 1/27/2016 11:14:39 AM whenCreated                                : 1/27/2016 11:14:38 AM

缓解措施:没有合理的缓解措施。

识别具有工作站或服务器的本地管理员权限的用户组

PowerView已经引入了这个功能。
组策略通过“限制组”的功能提供强制本地组成员身份的功能,例如OU中所有计算机上的管理员组。可以通过识别使用限制组的GPO和应用于其的OU来跟踪这一点。这可以提供具有管理员权限的AD组和相关的计算机列表。

使用PowerViewPowerSploit的一部分),我们可以快速识别出包括“限制组”的GPO。

PS C:> Get-NetGPOGroup
GPOName        : {E9CABE0F-3A3F-40B1-B4C1-1FA89AC1F212} GPOPath        : lab.adsecurity.orgSysVollab.adsecurity.orgPolicies{E9CABE0F-3A3F-40B1-B4C1-1FA89AC1F212} Members        : {Server Admins} MemberOf       : {Administrators} GPODisplayName : Add Server Admins to Local Administrator Group
Filters        : GPOName        : {45556105-EFE6-43D8-A92C-AACB1D3D4DE5} GPOPath        : lab.adsecurity.orgSysVollab.adsecurity.orgPolicies{45556105-EFE6-43D8-A92C-AACB1D3D4DE5} Members        : {Workstation Admins} MemberOf       : {Administrators} GPODisplayName : Add Workstation Admins to Local Administrators Group

一旦我们获得了这些信息,我们可以使用PowerView cmdlet 检查一下GPO链接的OU。

PS C:> get-netOU -guid “E9CABE0F-3A3F-40B1-B4C1-1FA89AC1F212” LDAP://OU=Servers,DC=lab,DC=adsecurity,DC=org
PS C:> get-netOU -guid “45556105-EFE6-43D8-A92C-AACB1D3D4DE5” LDAP://OU=Workstations,DC=lab,DC=adsecurity,DC=org

接下来,我们识别这些OU中的计算机

PS C:> get-adcomputer -filter * -SearchBase “OU=Servers,DC=lab,DC=adsecurity,DC=org”
DistinguishedName : CN=ADSAP01,OU=Servers,DC=lab,DC=adsecurity,DC=org DNSHostName : ADSAP01.lab.adsecurity.org Enabled : True Name : ADSAP01 ObjectClass : computer ObjectGUID : b79bb5e3-8f9e-4ee0-a30c-5f66b61da681 SamAccountName : ADSAP01$ SID : S-1-5-21-1581655573-3923512380-696647894-1105 UserPrincipalName :
DistinguishedName : CN=ADSAP02,OU=Servers,DC=lab,DC=adsecurity,DC=org DNSHostName : ADSAP02.lab.adsecurity.org Enabled : True Name : ADSAP02 ObjectClass : computer ObjectGUID : 1006978e-8627-4d01-98b6-3215c4ee4541 SamAccountName : ADSAP02$ SID : S-1-5-21-1581655573-3923512380-696647894-1603 UserPrincipalName :
PS C:> get-adcomputer -filter * -SearchBase “OU=Workstations,DC=lab,DC=adsecurity,DC=org”
DistinguishedName : CN=ADSWRKWIN7,OU=Workstations,DC=lab,DC=adsecurity,DC=org DNSHostName       : ADSWRKWIN7.lab.adsecurity.org Enabled           : True Name              : ADSWRKWIN7 ObjectClass       : computer ObjectGUID        : e8b3bed2-75b4-4512-a4f0-6d9c2d975c70 SamAccountName    : ADSWRKWIN7$ SID               : S-1-5-21-1581655573-3923512380-696647894-1104 UserPrincipalName :
DistinguishedName : CN=ADSWKWIN7,OU=Workstations,DC=lab,DC=adsecurity,DC=org DNSHostName       : ADSWKWIN7.lab.adsecurity.org Enabled           : True Name              : ADSWKWIN7 ObjectClass       : computer ObjectGUID        : 2f164d63-d721-4b0e-a553-3ca0e272aa96 SamAccountName    : ADSWKWIN7$ SID               : S-1-5-21-1581655573-3923512380-696647894-1602 UserPrincipalName :

使用几个PowerShell命令,我们就能够识别通过GPO配置的AD组,并且这些用户组在域中的计算机上具有完整的管理员权限。

缓解措施:唯一的缓解措施是删除能够读取管理本地组的GPO的域用户。只有域中的计算机才有读取和处理这些GPO的需要。请注意,一旦攻击者在域中的单个计算机上获得管理员权限,他们也可以使用计算机帐户来读取GPO。

识别Microsoft AppLocker设置

Microsoft AppLocker可用于将应用程序执行限制为特定的已批准的应用程序。AppLocker推荐了几个不同的阶段:

  • 阶段1:审核模式 – 审核用户执行的所有执行操作以及运行的路径。此日志记录模式提供有关企业中运行的程序的信息,并将该数据记录到事件日志中。

  • 阶段2:“黑名单模式” – 配置AppLocker阻止用户主目录,配置文件路径和用户对其进行写入访问的临时文件位置的任何文件的执行,如c:temp。

  • 阶段3:“文件夹白名单模式” -将AppLocker配置为构建阶段2,再通过添加新规则仅允许在特定文件夹(如c:Windows和c:Program Files)中执行文件,。

  • 阶段4:“应用程序白名单” – 列出企业环境中使用的所有应用程序,并通过位置和散列(最好是数字签名)将这些应用程序列入白名单。这确保只有经过批准的组织应用程序才能执行。

问题是AppLocker是通过组策略来配置的,它通常保持默认状态,所以所有域用户能够读取配置。

缓解措施:唯一的缓解措施是删除能够读取管理本地组的GPO的域用户。只有域中的计算机才需要读取和处理这些GPO的能力。请注意,一旦攻击者在域中的单个计算机上获得管理员权限,他们也可以使用计算机帐户来读取GPO。

识别Microsoft EMET设置

Microsoft增强缓解体验工具包(EMET)有助于防止应用程序漏洞被利用(包括一些0day)。这是一个免费的产品,有效地“包装”了流行的应用程序,以便在尝试使用漏洞时,尝试在“包装器”中阻断,并不会使其在操作系统执行。
企业通常使用组策略来配置EMET,并且通常保持了默认状态,所以所有的域用户能够读取配置。

缓解措施:唯一的缓解措施是删除能够读取管理本地组的GPO的域用户。只有域中的计算机才需要读取和处理这些GPO的能力。请注意,一旦攻击者在域中的单个计算机上获得管理员权限,他们也可以使用计算机帐户来读取GPO。

识别Microsoft LAPS委托

Microsoft本地管理员密码解决方案(LAPS)是管理企业中计算机的本地管理员帐户密码的好选择。LAPS向AD计算机对象添加两个新属性,一个用于存储本地管理员密码,另一个用于跟踪上次更改密码的时间。LAPS GPO用于配置LAPS客户端来确定密码更改时间,密码长度,管理的帐户等。计算机的本地管理员密码由计算机上的LAPS客户端创建,并且密码会设置为一个新的值也就是LAPS密码属性(ms-Mcs-AdmPwd),最后在本地更改。为了管理员可以使用密码,需要委托ms-Mcs-AdmPwd的读取权限。所以可以通过枚举属性上的安全ACL来识别该委派。

缓解措施:唯一的缓解措施是删除能够读取管理本地组的GPO的域用户。只有域中的计算机才需要读取和处理这些GPO的能力。请注意,一旦攻击者在域中的单个计算机上获得管理员权限,他们也可以使用计算机帐户来读取GPO。

在域中的SYSVOL共享中发现管理凭据

管理员通常会将脚本或组策略中的凭据放在SYSVOL中。
有关此问题的更多信息,包括缓解措施可以在这篇博文中阅读:“ 在SYSVOL中查找密码并利用组策略首选项 ”

结论

这些只是一些有趣的数据项,可以在域用户权限下轻松地搜集Active Directory信息。期望攻击者在企业中立足并对当前的策略进行相应的调整。

注意:我有一些脚本已经执行了许多类似的操作,我还没有没做好进行共享的准备。在未来的某个时刻,我可以分享这些给你。

twitter-vulnerability-allowed-hackers-to-access-locked-accounts-513609-2.jpg

在参与Twitter漏洞赏金项目的过程中,我通过一些安全测试发现了Twitter存在的重大漏洞:攻击者不需要获取他人账户权限,就能以任意账户发布推文。我于2017年2月26日发现了该漏洞,Twitter方面于2017年2月28日及时对其进行了修复(参考Hackerone),并最终向我奖励了$7560美元漏洞赏金。我们一起来看看该漏洞细节:

简介

Twitter Ads最早为向企业开放的广告服务平台,为了扩大自媒体广告业务,Twitter Ads于2013年5月1日向所有美国用户免费开放,用户可以通过https://ads.twitter.com/注册个人广告业务,实现推文(Tweet)推广、竞价排行、个性化定制等个人广告宣传。Twitter Ads服务中包含了一个多媒体库,注册用户可以向该库上传个人广告相关的视频、图片、GIF动图等多媒体文件,另外,用户在发布推文之前也能对这些文件进行审核。该多媒体库存在以下链接中:

https://ads.twitter.com/accounts/*id_of_your_account*/media

前期试探

如果你是Twitter Ads注册用户,用以上链接登入多媒体库后会发现其多媒体文件上传功能:

01.jpg

我们点击右上角的媒体文件下载按钮Download media-file(Загрузить медиа-файл),选择某一上传图片文件后,会显示相应的已经上传的图片:

02.jpg

点击该图片放大,请注意查看上图中显示的功能,将出现以下情景:

03.jpg

1、我们可以推送发布该多媒体文件

2、我们可以与任何用户分享该多媒体文件

通过BurpSuit抓包具体分析一下该推文布动作的相关功能:

04.jpg

可以发现网络请求包中包含以下参数:

account_id:账户ID,为已登录入库的账户ID;

owner_id:图片文件所有者ID;

user_id:推文分享用户的ID;

media_key:媒体文件发布ID,如下图的地址栏URL后部分数字:

05.jpg

接下来,让我们来定义一些相关的测试标识:

我的第一个测试账号:account №1

我的第二个测试账号:account №2

由于我不记得错误输出的确切语句,所以我们暂且把两个账号对应的错误输出定义为error №1、error №2。

漏洞发现

首先,我拦截监听了推文发布的网络请求信息,并尝试进行以下参数更改:

基于json的GET请求owner_id和user_id,在POST方式下,被设置从account №1发往对应的account №2处,此时,发生了错误error №1;

之后,我尝试在POST包中更改owner_id和user_id,又出现了错误error №2,我记得当时的错误提示是这样的:

作为替代*的,owner_id为*id的用户,并不是该多媒体文件的所有者,*这里应该是一个media_key*

我想,既然这样,那我们作出如下更改:

我使用account №2登录ads.twitter.com,进入媒体库,上传图片,以提前让Twitter解析出media_key的值。

举一反三

我们回到account №1登录状态:

拦截监听推文发布的网络请求信息,针对推文接收方account №2,我们对GET方式和POST请求中的owner_id和user_id作出相应更改,同时使用了之前知道的media_key值,之后,将会得到错误error №1,尽管如此,但在对owner_id和user_id的更改替换中,仅只出现了一种错误error №1;而仅在POST方式中对owner_id和user_id作出更改替换,会出现另一种错误error №2。那我们再试试其它的?

终于,在POST请求中对owner_id、user_id和media_key作出一系列更改替换之后,响应信息提示我们尝试的推文发布动作成功执行!对于account №2账户来说,可以发现尽管该账户本身没有执行任何推文发布动作,但其实以其身份和相应media_key的上传图片已被account №1当成推文发送出去了!

漏洞探索

好了,现在,我们可以以任意用户账户身份发布推文了,但同时也存在一些可能会消弱漏洞严重性的限制条件:我们用来发布推文的受害者用户必须具有一个已经上传的多媒体文件,而且,还需要知道这个多媒体文件的media_key,但由于media_key包含18位数字,一般来说,很难通过暴力猜解或其它方式知晓该数值,media_key值的获取存在一定限制性难度。

难道这就歇菜了吗?就这样向Twitter上报该漏洞?再想想看!我个人感觉该漏洞可能非常严重,想想看,还记得之前可以对任何用户分享该媒体文件的情况吗?我想到了一个非常有趣的点子:如果我们向受害者用户(即用他的账户发送推文)分享我们的多媒体文件,那么此时,该受害者用户也将被视为是这个多媒体文件的所有者, 错误error №2情况也将不会发生,而以该账户身份发送的推文也能成功发布!经过测试证明,该情景确实能成功实现!

综合以上场景可知,其实对该漏洞的成功利用并不需要media_key的值,当然,如果我们是多媒体文件的所有者,当然也就知道media_key值了。

最终,可以总结出以下漏洞利用的实现条件:

1、我们上传自己的多媒体文件;

2、向受害者用户(推文发布用户)分享该多媒体文件;

3、拦截监听向受害者用户发起的推文发布网络请求信息,并对owner_id和user_id值进行修改,;

4、之后,就可以接收到以受害者用户身份成功发布推文的响应信息。

5、利用该漏洞尽情玩耍吧!

好了,可以安心地向Twitter上报漏洞并等待漏洞赏金了!

*参考来源:Blog,freebuf小编clouds编译,转载请注明来自FreeBuf.COM

kodi_htpc_story.jpg

Checkpoint研究人员最近发现了一种新型攻击手段–字幕攻击,当受害者加载了攻击者制作的恶意字幕文件后将会触发播放器漏洞,从而实现对受害者系统“悄无声息”地完全控制。据测试发现,该攻击方法可以在多个知名视频播放器存在漏洞的版本软件上成功实现,目前,由于这些涉漏洞视频软件的全球下载量超过2亿次,并被用户在各种播放设备平台中使用,所以这种攻击方法将可能成为近年来影响广泛、传播深远的入侵手段之一。

先来看攻击实现的PoC视频:

         

攻击简介

当你想在电脑上观看影片时,很自然地打开视频播放器,加载字幕,当然遇到一些“生肉”影片时,我们还可能在网上千方百计寻找字幕,好吧来个葛优躺,….两小时过去了,殊不知,当你在完全放松欣赏大片的时候,黑客早已经悄悄入侵了你的电脑,把该干的事都干了。这种字幕攻击手段可能是最最容易被用户忽视和防范的黑客攻击技术,因为对于普通用户和播放器来说,都会把字幕文件认为是可信文件。

对于攻击者来说,他们可能会制作一些专门的恶意字幕库,然后通过各种手段向受害者推送这些恶意字幕文件,诱导受害者加载使用。而对用户来说,这种毫无防范意识的攻击将会是最危险的攻击。

当前,这种攻击在根源和意识方面,杀毒软件等各类安全厂商都还不具备检测识别能力,从某种程度上来说,这更增加了用户风险。

受影响用户

范围:据统计,因为目前每一种播放器的涉漏洞版本都存在数百万计的用户下载量,所以该攻击方法影响用户可能达数亿人之多。仅VLC在去年6月推出的最新版本下载量就达1亿7000万;Kodi (XBMC)每天使用人次达1000万,月用户达4000万;暂无统计信息的Popcorn Time使用量估计也是数百万。

影响:攻击者利用这种攻击,可以轻松控制电视、平板、手机….等使用视频播放器的各类系统设备。当然这种攻击将可能造成一些严重的潜在影响,如信息窃取、勒索攻击、DDoS等等。

受影响的视频播放器软件

截止目前,我们仅对当前流行的四种视频播放器VLC、Kodi、Popcorn Time、Stremio进行了漏洞识别和攻击方式成功测试,这种问题在其它视频播放器中同样存在。我们已把相关漏洞和问题向厂商方面进行了及时的沟通和上报,目前,有些漏洞和问题已被修复处理,有些则处于测试核查阶段。为了给厂商方面更多的时间来解决这些漏洞,我们在此暂且不公布一些具体的测试方法和技术信息

已经发布更新的视频软件

Popcorn Time:推出了一个修复版本软件,可以从此链接手动下载安装;

Kodi:可以通过其官方网站下载安装修复版本;

VLC:可以通过其官方网站下载安装修复版本;

Stremio:可以通过其官方网站下载安装修复版本。

入侵检测IPS签名定义

Popcorn Time Subtitles Remote Code Execution

Kodi Open Subtitles Addon Remote Code Execution

VLC ParseJSS Null Skip Subtitle Remote Code Execution

Stremio Subtitles Remote Code Execution

该攻击的传播实现方式

深入探究字幕服务链后将会发现其中一些有意思的结果,恶意字幕文件被攻击者制作出来后,可能会被上传到如OpenSubtitles.org等在线库中进行共享。之后,攻击者通过操作这些共享网站的库文件排名算法,可以把预先制作的恶意字幕文件列为视频播放器的优先选择,并被播放器自动加载使用。黑客无需借助中间人攻击(MITM)或其它交互手段,只需对恶意字幕文件的整个服务和推送链进行控制,就可实现对目标系统的隐蔽入侵控制。当然了,这种攻击可能还会对那些依赖排名进行字幕文件下载选择的用户造成威胁影响。该攻击的大致流程如下:

infographic_hack_in_translation_v6-1024x946.jpg

*参考来源:checkpoint,freebuf小编clouds编译,转载请注明来自FreeBuf.COM。

在对Twitter的安全测试期间,我发现了一个漏洞,它允许黑客在任何用户使用该服务的情况下在Twitter网络中发布条目,并且无需访问受害者的帐户。这个漏洞发现于2017年2月26日,并于2017年2月28日被修复。

详细报告参考:https://hackerone.com/reports/208978。

现在来看看这个漏洞的技术细节。

twitter网络中有一项服务为:https://ads.twitter.com/,它具有可以上传媒体文件(视频,图片,gif动画)的媒体库,也可以查看之前上传的文件,这是在发布Twitter的时刻使用的。 它的具体链接如下:

https://ads.twitter.com/accounts/*id_of_your_account*/media。

当我们打开该库,我们就会看到其上传媒体文件的功能:

1495511972909724.png

点击“下载媒体文件”按钮并选择适当的文件后,我们就会看到图片:

1495511987247699.png

点击上传的图片,然后我们就会看到:

1495512035748339.png

我们可以推送我们的媒体文件,也能够与任何用户共享媒体文件。

好!所以,现在让我们仔细看一下tweet的功能:

1495512058617604.png

我们在这里可以看到 

account_id – 帐号(直接在库中)

图片拥有者的owner_id -id

user_id – tweet将被发布给具有此id的用户

media_key – 要发布的媒体文件的ID(查看图3中的地址字符串)

我们来介绍一下我所使用的符号: 

帐号№1 – 我的第一个帐户

帐号№2 – 我的第二个帐号

因为我不记得输出错误的确切语句,所以我把他们暂且称之为:“错误№1”,“错误№2”。

揭示漏洞的步骤如下:

首先,我拦截了tweet发布和更改参数的请求:GET-request中的owner_id和user_id,由POST-method发送的json从帐号№1的id到相应的id号,但是没有收到预期的结果,而是得到了错误№1。 

之后,我决定在POST中更改owner_id和user_id,然后我就收到了错误№2,其具体内容是:«User with owner_id * id which was a substitute* is not an owner of this media-file *here should be a media_key*»

再然后我做了下面的这些事情: 

我拿了帐号№2,打开了服务ads.twitter.com,然后点开该库,并提前上传图片来了解media_key。 

一件事往往会导致另一件事的发生

我们回到帐号№1: 

然后,我们截取Twitter的请求,并更改GET和POST方法中的owner_id、user_id,以便在帐户№2上传图片时我们可以获取到帐户№2的相应数据和媒体密钥。这时我们又看到了错误№1。这是非常难过的…但是,尽管如此,当我们在GET和POST方法中替换owner_id和user_id时,只有一个错误(错误№1),而在POST方法中仅替换owner_id和user_id的情况还有其他错误(错误№2)。我们继续! 

在POST方法中更改请求owner_id,user_id和media_key,然后…我们就会看到响应,我想关于这一漏洞的验证成功了!转到帐号№2,我们可以看到已经发布了之前帐号№2上传图片的推文,但事实上帐号№2本身并没有公布。 

那么也就是说,我们现在理论上有可能发布在任何用户的账户中发布twitter,但实际上这一切还是有明确的限制的,这严重地减少了该漏洞的影响(一个漏洞的严重程度),限制包括:我们用来入侵进行发布的用户必须上传了一个媒体文件。此外,需要知道这个文件的media_key,而它几乎不可能以暴力的方式揭示它,因为它包含18位数字。事实上,在我的整个测试过程中,我并没有找到100%的方式来了解这个media_key,总是有一些情况会限制你来获取media_key。那么到这里就结束了?真的没有其他办法了吗?我是不是应该报告现在的这个情况呢?

绝对不 !我个人认为这个漏洞可能会带来极端的严重性!你还记得分享上传的媒体文件的可能性吗?我来到一个非常有趣的想法,如果我们与用户共享我们的媒体文件,用于从他的帐户发布,他将被视为这个媒体文件的所有者,那么错误№2就不会出现而转发的tweet将成功发布。而这一切真的实现了!

要想完整的利用该漏洞就需要我们获取media_key,然而我们没有,但是在我们是这个文件的所有者的情况下,我们就可能会看到它的media_key(截屏№3)啊!

现在,情景如下:

我们上传我们的媒体文件。

与用户共享此文件,该用户的帐号用于发布条目。

拦截查询的tweet发布,只需更改POST方法的以下数据:owner_id和user_id到受害者帐户的id twitter。

我们就会收到有关Twitter发布成功的消息。

是不是很有趣?现在我们可以安心地报告漏洞了!

*本文原创作者:PhyzX本文属FreeBuf原创奖励计划,未经许可禁止转载

0×00 Intro

本文以Ian Wienand博客 为蓝本,我在必要的地方予以增补、解释以及再实验,希望读者对PLT和GOT有一个初步的、相对完整的认识。

0×01 The Simplest Example

原文的标题是“PLT and GOT – the key to code sharing and dynamic libraries”,可见PLT和GOT对代码复用以及动态库的关键作用。

共享库(shared library)是现代操作系统的组成部分,但其内部机制却很少有人去了解。当然,有很多解释共享库机制的文章,希望本篇博客能为这方面的知识体系加一把火。

OK,我们从最起始部分讲起—-在二进制文件(比如object file)中会有一段叫relocations的部分,这部分的内容在链接时候(link time)再进行敲定确切的值,注意链接可以发生在运行前(称为静态链接,toolchain linker),也可发生在运行时(称为动态链接,dynamic linker)。具体relocations部分中的内容就是在讲:“确定X这个符号(symbol)的值,然后把这个值写到二进制文件的Y偏移处”。每一条relocation都有确定的类型(定义与ABI文档中),从而确切地说明每个类型的值到底该如何敲定。

如下为最简单的例子:

Image

我们可以看到”foo”这个符号的Sym.Value是0,说明在把a.c编译成a.o的时候,“foo”这个符号的值还不知道,所以编译就在Sym.Value处先写0,然后在Type这个位置写上R_X86_64_PC32,从而告诉之后要进行link的链接器:”在最终生成的可执行文件的.text部分的0×6这个偏移位置,patch上foo这个符号的地址值”。如果我们看一下a.o这个对象文件的.text部分0×6这个位置,我们会看到如图绿线部分:

Image

觉得刚刚看到这张图片,可能就会有些刚刚接触这些概念的同学就有些懵了。别急,我一点点地讲这张图。首先一个二进制可执行文件可被划分为多个部分:

Image

这张图片截取自《程序员的自我修养》这本书,真心希望像搞懂“程序是如何跑起来的?”这种问题的同学,去读一下这本书,你会觉得很值的,这是一个很本质的问题,而书中解释得那样的清晰,总之,强烈推荐!

.text部分会放着这个二进制文件的执行代码,所以当我们用objdump进行反汇编的时候,就会看到a.o这个二进制文件的.text部分的机器码,前两条指令用于布置好栈空间(这部分可参考William Stallings的Computer Security那本书的第十章)不是本文的重点,后两条指令用于清理栈空间,并返回调用函数,也不是本文重点。重点在第三条语句,它在.text的Offset 0×4处。我们可以看到,a.o仅仅是一个经过编译后的object file,所以其中的真实值并没有敲定,从而看到绿线处暂时填4个00。

好,下面我问一个问题:当CPU执行到0×4出这句指令时,%rip(即PC)的值为多少?两个选项,A. 0×4 ;B. 0xa。答案:B。参考CSAPP第四章,截图如下:

Image

其实,计算机在执行一条指令需要一个指令周期,不同的CPU架构的指令周期可以分为不同阶段,上图中我们可看到Intel x86架构CPU的指令周期分为:取指,译码,执行,访存,写回,PC update,这六个阶段。这里,我说一下我对PC的理解,图中绿线部分,vaIP对应%rip寄存器,%rip趋向于一种实际意义层面上的理解,而PC更趋向于一种意向意义层面上的理解。具体来说,在PC update阶段,CPU才去关注”我要去执行的下一条指令在哪里”(通过关注%rip中的值),而在CPU关注“下一条指令在哪里”之前(即PC update周期之前),在Fetch阶段,%rip寄存器按图中绿线的指示,其值便已经改变了,(改变方法是:当前指令的PC加上当前指令的长度,图中subl %edx, %ebx这条指令长度为2,所以vaIP被赋值为PC+2)。简单理解,%rip就是PC,在CPU这执行当前指令时,%rip便已经指向了下一条指令所在的地址处了,只是到了PC update环节,CPU才去看%rip的值(当然在Execute环节,CPU也可以使用%rip,但并不是为了程序的执行流而去关注%rip,此时就纯粹那%rip作为一个存值的寄存器来使用,而且此时的%rip已经指向下一条指令了)。

对于我上述理解的支撑材料是,王爽老师那本《汇编语言》的第二章的2.10节有关CPU如何执行一条指令的一系列图示。这里由于图示很长,我就不粘贴了,简单讲就是,CPU还没开始执行具体指令的时候,IP的值便已经指向下一条指令了。

好了,说了这么多,我想,我可以开始解释0×4处这条指令的意思了,就是将0×0 + %rip这个地址处所存的值,赋给%eax。而此时,%rip的值,根据我们上面问的问题的描述,应为0xa(下一条指令的地址),所以这条指令的含义进一步解释为,以%rip为基址,以0×0为偏移的内存地址处取内容,给到%eax。而此时偏移之所以为0×0,是因为还没有经过链接过程,所以真实的偏移地址还没有敲定,所以暂时写0×0。

明白了该指令的含义,但这句到底是在干啥啊?我们回头看一下a.c源码,foo是一个extern(外部)的int型数据,函数function的返回类型也是一个int型数据,其内容为将foo给return出来。我们知道a.o仅仅是经过编译的,编译器会说:“我不知道foo这个外来int会来自于那个.o文件,那是链接器的活!我就姑且把foo所在的内存地址偏移定为0×0”。而返回值一般都保存在%eax这个寄存器中,所以0×4处这个指令的含义就是function函数的返回值为0 。

经过link之后,该偏移会被patch成foo的真实地址偏移。

0×02 Position-Independent Code

接着上面,如果foo这变量的值出现在其他的对象文件(比如b.o)中,那么便可以通过静态链接,来将a.o和b.o链接到一个executable中,而在executable中,原来a.o中relocations部分foo相关的条目便可以去掉了,因为foo的真实地址,已经被linker,根据b.o中有关foo的信息,给patch好了。但是,“ there is a whole bunch of stuff for a fully linked executable or shared-library that just can’t be resolved until runtime. ”,对于一个executable或者共享库,有许多事,只有到了运行时(runtime)才能敲定。比如,我们即将讲到的位置无关代码(position-independent code ,PIC)。

首先,我们先看一下位置相关代码(清晰起见,用作者的32位机的例子即可):

$ readelf --headers /bin/ls
[...]
ELF Header:
[...]
  Entry point address:               0x8049bb0

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  LOAD           0x000000 0x08048000 0x08048000 0x16f88 0x16f88 R E 0x1000
  LOAD           0x016f88 0x0805ff88 0x0805ff88 0x01543 0x01543 RW  0x1000

可见ls这个可执行文件,它有一个fixed的加载位置,即代码部分(其flag是R和E)必须加载到0×08048000(注意这个是物理地址),而数据部分(其flag是R和W)必须加载到0x0805ff88。这种位置相关的代码,固然有其好处,不用再在runtime的时候去算一些地址信息什么的了,因为地址都是fixed。

不过,这种fixed地址对shared library(.so文件)并没有好处。so文件的一个核心观点就是拿过来,加载到任意一段物理内存上就用。而如果so文件必须被加载到一个特定的地址上才能运行的话,我们可能就得把计算机上所有so文件都给一个特定的加载地址,以保证在使用这些so文件时不会有重叠(overlap),这其实也是预链接(prelinking)要做的事。但对于一个32位机,你这么做的话,马上内存就分配完了。所以,还是得考虑一种位置无关代码的方案。实际上,当我们去检查一个so文件的时候,会看到它们并不会指定一个特定的加载基地址(可见R E flag标示的代码部分的物理地址为0,即不会指定加载基地址):

$ readelf --headers /lib/libc.so.6
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  LOAD           0x000000 0x00000000 0x00000000 0x236ac 0x236ac R E 0x1000
  LOAD           0x023edc 0x00024edc 0x00024edc 0x0015c 0x001a4 RW  0x1000

共享库的第二个目标就是代码重用(code sharing)。对于shared library,我们需要让它的code段保持不变,如果变了的话,那么100个进程调用这段代码,因为code段会变的原因,就要占用100段物理内存空间,这肯定不是我们想要的,所以要保持so文件中code段不能动,从而只需将这个code段加载到一个特定的物理地址处,每个调用该so文件的进程的虚存指向这个物理地址就可以了。还有就是,so文件中data段的相对位置也不能变,从而使写死的code段,能够通过相对位置来找到data段(上面的headers中,我们可以看到data段的offset是0x023edc)。这样,通过virtual memory的神奇机制(同一虚拟地址,可以映射到不同的物理地址),“every process sees its own data section but can share the unmodified code”。于是对于每一个进程,要找到其特有的data段时,使用简单的数学即可:我当前的地址(code段某处) + 已知的相对位置 = 我索引的data段 。

0×03 Global Offset Table

不过说着轻松,想确定“我当前的地址”可不是件容易的事,比如有如下代码:

$ cat test.c
static int foo = 100;

int function(void) {
    return foo;
}
$ gcc -fPIC -shared -o libtest.so test.c

-shared告诉编译器生成so文件,-fPIC告诉编译器生成位置无关的代码,综合在一起就是生成位置无关的so文件,这两个通常配套使用。

这里foo是static的,所以它会保存在so文件的data段中。对于64位机(amd64),因为可以直接访问%rip,所以当前指令地址很好获得:

000000000000056c <function>:
 56c:        55         push   %rbp
 56d:        48 89 e5               mov    %rsp,%rbp
 570:        8b 05 b2 02 20 00      mov    0x2002b2(%rip),%eax        # 200828 <foo>
 576:        5d                     pop    %rbp

第三条是重点(其余不属于本文讨论范文),我们在上一节接触过类似的,按照相对位置%rip+0x2002b2,取到该地址处的内容(即data),将其赋给%eax。对于64位机,就这么简单。

但对于32位机(i386)的话,就要麻烦一些了,因为32位架构下接触不到PC。所以,需要一点小技巧:

0000040c <function>:
 40c:    55         push   %ebp
 40d:    89 e5                  mov    %esp,%ebp
 40f:    e8 0e 00 00 00         call   422 <__i686.get_pc_thunk.cx>
 414:    81 c1 5c 11 00 00      add    $0x115c,%ecx
 41a:    8b 81 18 00 00 00      mov    0x18(%ecx),%eax
 420:    5d                     pop    %ebp
 421:    c3                     ret

00000422 <__i686.get_pc_thunk.cx>:
 422:    8b 0c 24       mov    (%esp),%ecx
 425:    c3                     ret

0x40f处一个call指令调用__i686.get_pc_thunk.cx函数:先将call指令的下一条指令的地址(这里是0×414)压到栈上,然后蹦到这个函数地址处(0×422)开始执行:将刚刚压栈的下一条指令的地址赋给%ecx,然后ret到0×414继续执行add指令:0x115c + 0×414 = 0×1570。然后再到0x41a把0×1570 + 0×18 = 0×1588地址处的内容,给到%eax寄存器中。这里我们可以去看一下0×1588中写着什么:

00001588 <global>:
    1588:       64 00 00                add    %al,%fs:(%eax)

值为0×0000000064=100,正是源码中static int 类型的变量foo的值100。

我们注意到,上面源码中foo是static的,即使属于该so文件本身的。那么,如果一个so文件,想去索引其他的so文件中的data怎么办?当然,我们可以patch这个so文件的代码部分,直接把那个data的位置为patch上,但这样就破坏了so文件的 code-sharability。而计算机中有一个原理就是:所有问题都可以通过加一个间接层来解决。这里,这个间接层就叫global offset table or GOT.

考虑下面情况:

$ cat test.c
extern int foo;

int function(void) {
    return foo;
}
$ gcc -shared -fPIC -o libtest.so test.c

这里foo是一个extern外部变量,大概来自什么其他的库文件吧。我们看一下在amd64架构上的情况吧:

$ objdump --disassemble libtest.so
[...]
00000000000005ac <function>:
 5ac:        55         push   %rbp
 5ad:        48 89 e5               mov    %rsp,%rbp
 5b0:        48 8b 05 71 02 20 00   mov    0x200271(%rip),%rax        # 200828 <_DYNAMIC+0x1a0>
 5b7:        8b 00                  mov    (%rax),%eax
 5b9:        5d                     pop    %rbp
 5ba:        c3                     retq

$ readelf --sections libtest.so
Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
[...]
  [20] .got              PROGBITS         0000000000200818  00000818
       0000000000000020  0000000000000008  WA       0     0     8

$ readelf --relocs libtest.so
Relocation section '.rela.dyn' at offset 0x418 contains 5 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
[...]
000000200828  000400000006 R_X86_64_GLOB_DAT 0000000000000000 foo + 0

我们可以看到返回值来自于%rip + 0×200271 = 0×200828。我们再看一下这个so文件的headers,可见0×200828属于.got范围内。然后,我们在看一下这个so文件的relocations,我们看到“R_X86_64_GLOB_DAT ”告诉链接器:“链接器啊,你去到其他对象文件中找一下foo的值,然后把它patch到0×200828这个位置”。

所以,当动态加载器加载该so文件时,会先去看它的relocations,然后找到foo的值,然后把它patch到该so文件的属于.got部分的0×200828地址处。当code段索引到foo这个值的时候,直接到.got的0×200828处去拿就好了,everything just works:code段也不需要修改,从而就没有破坏so文件的code sharability。

0×04 Procedure Linkage Table

上节我们可以处理so文件对外部变量的引用了,但如果是外部函数调用呢?此处,我们使用的“间接层”叫做procedure linkage table or PLT。code只会通过PLT stub(PLT桩代码,其实就是一小段代码),实现外部函数调用。如下例子:

$ cat test.c
int foo(void);

int function(void) {
    return foo();
}
$ gcc -shared -fPIC -o libtest.so test.c

$ objdump --disassemble libtest.so
[...]
00000000000005bc <function>:
 5bc:        55         push   %rbp
 5bd:        48 89 e5               mov    %rsp,%rbp
 5c0:        e8 0b ff ff ff         callq  4d0 <[email protected]>
 5c5:        5d                     pop    %rbp

$ objdump --disassemble-all libtest.so
00000000000004d0 <[email protected]>:
 4d0:   ff 25 82 03 20 00       jmpq   *0x200382(%rip)        # 200858 <_GLOBAL_OFFSET_TABLE_+0x18>
 4d6:   68 00 00 00 00          pushq  $0x0
 4db:   e9 e0 ff ff ff          jmpq   4c0 <_init+0x18>

$ readelf --relocs libtest.so
Relocation section '.rela.plt' at offset 0x478 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000200858  000400000007 R_X86_64_JUMP_SLO 0000000000000000 foo + 0

执行function这个函数时,我们看到有一句callq指令,从而执行流跳到0x4d0处执行,该处为jmpq *0×200382(%rip),即以0×200382 + 0x4d6 = 0×200858地址处取内容作为地址,进行跳转。那么我们看一下第一次这么执行时,0×200858处的内容是什么:

$ objdump --disassemble-all libtest.so

Disassembly of section .got.plt:

0000000000200840 <.got.plt>:
  200840:       98                      cwtl
  200841:       06                      (bad)
  200842:       20 00                   and    %al,(%rax)
        ...
  200858:       d6                      (bad)
  200859:       04 00                   add    $0x0,%al
  20085b:       00 00                   add    %al,(%rax)
  20085d:       00 00                   add    %al,(%rax)
  20085f:       00 e6                   add    %ah,%dh
  200861:       04 00                   add    $0x0,%al
  200863:       00 00                   add    %al,(%rax)
  200865:       00 00                   add    %al,(%rax)

jmpq是quadra word,即8个字节,所以取0x00000000000004d6(即从地址0×200858到0x20085f地址,取这8个字节,注意小端模式,所以倒着写)。这恰好是jmpq的下一条指令的地址(注意,这是第一次call foo这个外部函数时的情形)。0x4d6的指令是,push $0×0,这里这个push的0是foo这个函数符号在.rela.plt数据结构中的下标(也可称为索引或者index),用于定位这个foo这个符号(具体参见《程序员的自我修养》,估计以后我也会专门写一篇有关对象文件构成的文章)。执行完push后,就jmp到了0x4c0这个位置,我们看一下0x4c0处写了什么:

00000000000004c0 <[email protected]>:
 4c0:   ff 35 82 03 20 00       pushq  0x200382(%rip)        # 200848 <_GLOBAL_OFFSET_TABLE_+0x8>
 4c6:   ff 25 84 03 20 00       jmpq   *0x200384(%rip)        # 200850 <_GLOBAL_OFFSET_TABLE_+0x10>
 4cc:   0f 1f 40 00             nopl   0x0(%rax)

又push了一个值,这个值是什么呢?在后面注释中我们可以看到_GLOBAL_OFFSET_TABLE_+0×8这种字样,它又是什么呢?

我先查阅了CSAPP,看到了如下内容:

Image

然后,查阅了《程序员的自我修养》,看到如下内容:

Image

所以,我的理解是,我们可以把_GLOBAL_OFFSET_TABLE_理解成为一个类似数组一样的东西,每个元素保存着一个地址,32位机就是4字节地址,64位机就是8字节地址。

所以_GLOBAL_OFFSET_TABLE_+0×8就是_GLOBAL_OFFSET_TABLE_的第二个元素,参考上面两幅图片可知,这个代表了libtest.so(即模块的ID),_GLOBAL_OFFSET_TABLE_+0×10则为_GLOBAL_OFFSET_TABLE_的第三个元素,为动态解析函数的入口地址。

然后在0x4c6,跳到这个动态解析函数,开始对foo这个函数名进行解析,找到其地址,并patch到0×200858这个位置(这个位置在GOT中),从而第二次调用foo的时候,jmp的地址就不是0x00000000000004d6了,而是foo的实际地址了。

这种,第一次调用foo函数,通过PLT stub(PLT桩代码)进行动态链接(地址解析),找到foo函数真实地址并patch GOT表,第二次直接通过PLT桩代码跳到foo函数真实地址的方式,称为“延迟绑定技术”(lazy binding)

好了,以上便是PLT技术的一些细节实现。另外多说一句,我们可以在运行某使用so库的可执行文件时,使用LD_PRELOAD 来修改动态链接时,符号解析的顺序。也就是说,LD_PRELOAD会告诉动态链接器,想找什么符号的话,先从这里找,如果LD_PRELOAD中所提供so库里有foo这个符号,那么动态链接器会首先到这里找foo的地址,而不会去其他so库中去找。

*本文原创作者:PhyzX本文属FreeBuf原创奖励计划,未经许可禁止转载

0×00 Intro

本文以Ian Wienand博客 为蓝本,我在必要的地方予以增补、解释以及再实验,希望读者对PLT和GOT有一个初步的、相对完整的认识。

0×01 The Simplest Example

原文的标题是“PLT and GOT – the key to code sharing and dynamic libraries”,可见PLT和GOT对代码复用以及动态库的关键作用。

共享库(shared library)是现代操作系统的组成部分,但其内部机制却很少有人去了解。当然,有很多解释共享库机制的文章,希望本篇博客能为这方面的知识体系加一把火。

OK,我们从最起始部分讲起—-在二进制文件(比如object file)中会有一段叫relocations的部分,这部分的内容在链接时候(link time)再进行敲定确切的值,注意链接可以发生在运行前(称为静态链接,toolchain linker),也可发生在运行时(称为动态链接,dynamic linker)。具体relocations部分中的内容就是在讲:“确定X这个符号(symbol)的值,然后把这个值写到二进制文件的Y偏移处”。每一条relocation都有确定的类型(定义与ABI文档中),从而确切地说明每个类型的值到底该如何敲定。

如下为最简单的例子:

Image

我们可以看到”foo”这个符号的Sym.Value是0,说明在把a.c编译成a.o的时候,“foo”这个符号的值还不知道,所以编译就在Sym.Value处先写0,然后在Type这个位置写上R_X86_64_PC32,从而告诉之后要进行link的链接器:”在最终生成的可执行文件的.text部分的0×6这个偏移位置,patch上foo这个符号的地址值”。如果我们看一下a.o这个对象文件的.text部分0×6这个位置,我们会看到如图绿线部分:

Image

觉得刚刚看到这张图片,可能就会有些刚刚接触这些概念的同学就有些懵了。别急,我一点点地讲这张图。首先一个二进制可执行文件可被划分为多个部分:

Image

这张图片截取自《程序员的自我修养》这本书,真心希望像搞懂“程序是如何跑起来的?”这种问题的同学,去读一下这本书,你会觉得很值的,这是一个很本质的问题,而书中解释得那样的清晰,总之,强烈推荐!

.text部分会放着这个二进制文件的执行代码,所以当我们用objdump进行反汇编的时候,就会看到a.o这个二进制文件的.text部分的机器码,前两条指令用于布置好栈空间(这部分可参考William Stallings的Computer Security那本书的第十章)不是本文的重点,后两条指令用于清理栈空间,并返回调用函数,也不是本文重点。重点在第三条语句,它在.text的Offset 0×4处。我们可以看到,a.o仅仅是一个经过编译后的object file,所以其中的真实值并没有敲定,从而看到绿线处暂时填4个00。

好,下面我问一个问题:当CPU执行到0×4出这句指令时,%rip(即PC)的值为多少?两个选项,A. 0×4 ;B. 0xa。答案:B。参考CSAPP第四章,截图如下:

Image

其实,计算机在执行一条指令需要一个指令周期,不同的CPU架构的指令周期可以分为不同阶段,上图中我们可看到Intel x86架构CPU的指令周期分为:取指,译码,执行,访存,写回,PC update,这六个阶段。这里,我说一下我对PC的理解,图中绿线部分,vaIP对应%rip寄存器,%rip趋向于一种实际意义层面上的理解,而PC更趋向于一种意向意义层面上的理解。具体来说,在PC update阶段,CPU才去关注”我要去执行的下一条指令在哪里”(通过关注%rip中的值),而在CPU关注“下一条指令在哪里”之前(即PCupdate周期之前),在Fetch阶段,%rip寄存器按图中绿线的指示,其值便已经改变了,(改变方法是:当前指令的PC加上当前指令的长度,图中subl %edx, %ebx这条指令长度为2,所以vaIP被赋值为PC+2)。简单理解,%rip就是PC,在CPU这执行当前指令时,%rip便已经指向了下一条指令所在的地址处了,只是到了PC update环节,CPU才去看%rip的值(当然在Execute环节,CPU也可以使用%rip,但并不是为了程序的执行流而去关注%rip,此时就纯粹那%rip作为一个存值的寄存器来使用,而且此时的%rip已经指向下一条指令了)。

对于我上述理解的支撑材料是,王爽老师那本《汇编语言》的第二章的2.10节有关CPU如何执行一条指令的一系列图示。这里由于图示很长,我就不粘贴了,简单讲就是,CPU还没开始执行具体指令的时候,IP的值便已经指向下一条指令了。

好了,说了这么多,我想,我可以开始解释0×4处这条指令的意思了,就是将0×0 + %rip这个地址处所存的值,赋给%eax。而此时,%rip的值,根据我们上面问的问题的描述,应为0xa(下一条指令的地址),所以这条指令的含义进一步解释为,以%rip为基址,以0×0为偏移的内存地址处取内容,给到%eax。而此时偏移之所以为0×0,是因为还没有经过链接过程,所以真实的偏移地址还没有敲定,所以暂时写0×0。

明白了该指令的含义,但这句到底是在干啥啊?我们回头看一下a.c源码,foo是一个extern(外部)的int型数据,函数function的返回类型也是一个int型数据,其内容为将foo给return出来。我们知道a.o仅仅是经过编译的,编译器会说:“我不知道foo这个外来int会来自于那个.o文件,那是链接器的活!我就姑且把foo所在的内存地址偏移定为0×0”。而返回值一般都保存在%eax这个寄存器中,所以0×4处这个指令的含义就是function函数的返回值为0 。

经过link之后,该偏移会被patch成foo的真实地址偏移。

0×02 Position-Independent Code

接着上面,如果foo这变量的值出现在其他的对象文件(比如b.o)中,那么便可以通过静态链接,来将a.o和b.o链接到一个executable中,而在executable中,原来a.o中relocations部分foo相关的条目便可以去掉了,因为foo的真实地址,已经被linker,根据b.o中有关foo的信息,给patch好了。但是,“ there is a whole bunch of stuff for a fully linked executable or shared-librarythat just can’t be resolved until runtime. ”,对于一个executable或者共享库,有许多事,只有到了运行时(runtime)才能敲定。比如,我们即将讲到的位置无关代码(position-independent code ,PIC)。

首先,我们先看一下位置相关代码(清晰起见,用作者的32位机的例子即可):

$ readelf --headers /bin/ls
[...]
ELF Header:
[...]
  Entry point address:   0x8049bb0

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  LOAD   0x000000 0x08048000 0x08048000 0x16f88 0x16f88 R E 0x1000
  LOAD   0x016f88 0x0805ff88 0x0805ff88 0x01543 0x01543 RW  0x1000

可见ls这个可执行文件,它有一个fixed的加载位置,即代码部分(其flag是R和E)必须加载到0×08048000(注意这个是物理地址),而数据部分(其flag是R和W)必须加载到0x0805ff88。这种位置相关的代码,固然有其好处,不用再在runtime的时候去算一些地址信息什么的了,因为地址都是fixed。

不过,这种fixed地址对shared library(.so文件)并没有好处。so文件的一个核心观点就是拿过来,加载到任意一段物理内存上就用。而如果so文件必须被加载到一个特定的地址上才能运行的话,我们可能就得把计算机上所有so文件都给一个特定的加载地址,以保证在使用这些so文件时不会有重叠(overlap),这其实也是预链接(prelinking)要做的事。但对于一个32位机,你这么做的话,马上内存就分配完了。所以,还是得考虑一种位置无关代码的方案。实际上,当我们去检查一个so文件的时候,会看到它们并不会指定一个特定的加载基地址(可见RE flag标示的代码部分的物理地址为0,即不会指定加载基地址):

$ readelf --headers /lib/libc.so.6
Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  LOAD   0x000000 0x00000000 0x00000000 0x236ac 0x236ac R E 0x1000
  LOAD   0x023edc 0x00024edc 0x00024edc 0x0015c 0x001a4 RW  0x1000

共享库的第二个目标就是代码重用(code sharing)。对于shared library,我们需要让它的code段保持不变,如果变了的话,那么100个进程调用这段代码,因为code段会变的原因,就要占用100段物理内存空间,这肯定不是我们想要的,所以要保持so文件中code段不能动,从而只需将这个code段加载到一个特定的物理地址处,每个调用该so文件的进程的虚存指向这个物理地址就可以了。还有就是,so文件中data段的相对位置也不能变,从而使写死的code段,能够通过相对位置来找到data段(上面的headers中,我们可以看到data段的offset是0x023edc)。这样,通过virtual memory的神奇机制(同一虚拟地址,可以映射到不同的物理地址),“every process sees its own data section but can share the unmodified code”。于是对于每一个进程,要找到其特有的data段时,使用简单的数学即可:我当前的地址(code段某处) + 已知的相对位置 = 我索引的data段 。

0×03 Global Offset Table

不过说着轻松,想确定“我当前的地址”可不是件容易的事,比如有如下代码:

$ cat test.c
static int foo = 100;

int function(void) {
return foo;
}
$ gcc -fPIC -shared -o libtest.so test.c

-shared告诉编译器生成so文件,-fPIC告诉编译器生成位置无关的代码,综合在一起就是生成位置无关的so文件,这两个通常配套使用。

这里foo是static的,所以它会保存在so文件的data段中。对于64位机(amd64),因为可以直接访问%rip,所以当前指令地址很好获得:

000000000000056c <function>:
 56c:55 push   %rbp
 56d:48 89 e5   mov%rsp,%rbp
 570:8b 05 b2 02 20 00  mov0x2002b2(%rip),%eax# 200828 <foo>
 576:5d pop%rbp

第三条是重点(其余不属于本文讨论范文),我们在上一节接触过类似的,按照相对位置%rip+0x2002b2,取到该地址处的内容(即data),将其赋给%eax。对于64位机,就这么简单。

但对于32位机(i386)的话,就要麻烦一些了,因为32位架构下接触不到PC。所以,需要一点小技巧:

0000040c <function>:
 40c:55 push   %ebp
 40d:89 e5  mov%esp,%ebp
 40f:e8 0e 00 00 00 call   422 <__i686.get_pc_thunk.cx>
 414:81 c1 5c 11 00 00  add$0x115c,%ecx
 41a:8b 81 18 00 00 00  mov0x18(%ecx),%eax
 420:5d pop%ebp
 421:c3 ret

00000422 <__i686.get_pc_thunk.cx>:
 422:8b 0c 24   mov(%esp),%ecx
 425:c3 ret

0x40f处一个call指令调用__i686.get_pc_thunk.cx函数:先将call指令的下一条指令的地址(这里是0×414)压到栈上,然后蹦到这个函数地址处(0×422)开始执行:将刚刚压栈的下一条指令的地址赋给%ecx,然后ret到0×414继续执行add指令:0x115c + 0×414 = 0×1570。然后再到0x41a把0×1570 + 0×18 = 0×1588地址处的内容,给到%eax寄存器中。这里我们可以去看一下0×1588中写着什么:

00001588 <global>:
1588:   64 00 00add%al,%fs:(%eax)

值为0×0000000064=100,正是源码中static int 类型的变量foo的值100。

我们注意到,上面源码中foo是static的,即使属于该so文件本身的。那么,如果一个so文件,想去索引其他的so文件中的data怎么办?当然,我们可以patch这个so文件的代码部分,直接把那个data的位置为patch上,但这样就破坏了so文件的 code-sharability。而计算机中有一个原理就是:所有问题都可以通过加一个间接层来解决。这里,这个间接层就叫global offset table or GOT.

考虑下面情况:

$ cat test.c
extern int foo;

int function(void) {
return foo;
}
$ gcc -shared -fPIC -o libtest.so test.c

这里foo是一个extern外部变量,大概来自什么其他的库文件吧。我们看一下在amd64架构上的情况吧:

$ objdump --disassemble libtest.so
[...]
00000000000005ac <function>:
 5ac:55 push   %rbp
 5ad:48 89 e5   mov%rsp,%rbp
 5b0:48 8b 05 71 02 20 00   mov0x200271(%rip),%rax# 200828 <_DYNAMIC+0x1a0>
 5b7:8b 00  mov(%rax),%eax
 5b9:5d pop%rbp
 5ba:c3 retq

$ readelf --sections libtest.so
Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
[...]
  [20] .got  PROGBITS 0000000000200818  00000818
   0000000000000020  0000000000000008  WA   0 0 8

$ readelf --relocs libtest.so
Relocation section '.rela.dyn' at offset 0x418 contains 5 entries:
  Offset  Info   Type   Sym. ValueSym. Name + Addend
[...]
000000200828  000400000006 R_X86_64_GLOB_DAT 0000000000000000 foo + 0

我们可以看到返回值来自于%rip + 0×200271 = 0×200828。我们再看一下这个so文件的headers,可见0×200828属于.got范围内。然后,我们在看一下这个so文件的relocations,我们看到“R_X86_64_GLOB_DAT ”告诉链接器:“链接器啊,你去到其他对象文件中找一下foo的值,然后把它patch到0×200828这个位置”。

所以,当动态加载器加载该so文件时,会先去看它的relocations,然后找到foo的值,然后把它patch到该so文件的属于.got部分的0×200828地址处。当code段索引到foo这个值的时候,直接到.got的0×200828处去拿就好了,everything just works:code段也不需要修改,从而就没有破坏so文件的code sharability。

0×04 Procedure Linkage Table

上节我们可以处理so文件对外部变量的引用了,但如果是外部函数调用呢?此处,我们使用的“间接层”叫做procedure linkage table or PLT。code只会通过PLT stub(PLT桩代码,其实就是一小段代码),实现外部函数调用。如下例子:

$ cat test.c
int foo(void);

int function(void) {
return foo();
}
$ gcc -shared -fPIC -o libtest.so test.c

$ objdump --disassemble libtest.so
[...]
00000000000005bc <function>:
 5bc:55 push   %rbp
 5bd:48 89 e5   mov%rsp,%rbp
 5c0:e8 0b ff ff ff callq  4d0 <[email protected]>
 5c5:5d pop%rbp

$ objdump --disassemble-all libtest.so
00000000000004d0 <[email protected]>:
 4d0:   ff 25 82 03 20 00   jmpq   *0x200382(%rip)# 200858 <_GLOBAL_OFFSET_TABLE_+0x18>
 4d6:   68 00 00 00 00  pushq  $0x0
 4db:   e9 e0 ff ff ff  jmpq   4c0 <_init+0x18>

$ readelf --relocs libtest.so
Relocation section '.rela.plt' at offset 0x478 contains 2 entries:
  Offset  Info   Type   Sym. ValueSym. Name + Addend
000000200858  000400000007 R_X86_64_JUMP_SLO 0000000000000000 foo + 0

执行function这个函数时,我们看到有一句callq指令,从而执行流跳到0x4d0处执行,该处为jmpq *0×200382(%rip),即以0×200382 + 0x4d6 = 0×200858地址处取内容作为地址,进行跳转。那么我们看一下第一次这么执行时,0×200858处的内容是什么:

$ objdump --disassemble-all libtest.so

Disassembly of section .got.plt:

0000000000200840 <.got.plt>:
  200840:   98  cwtl
  200841:   06  (bad)
  200842:   20 00   and%al,(%rax)
...
  200858:   d6  (bad)
  200859:   04 00   add$0x0,%al
  20085b:   00 00   add%al,(%rax)
  20085d:   00 00   add%al,(%rax)
  20085f:   00 e6   add%ah,%dh
  200861:   04 00   add$0x0,%al
  200863:   00 00   add%al,(%rax)
  200865:   00 00   add%al,(%rax)

jmpq是quadra word,即8个字节,所以取0x00000000000004d6(即从地址0×200858到0x20085f地址,取这8个字节,注意小端模式,所以倒着写)。这恰好是jmpq的下一条指令的地址(注意,这是第一次call foo这个外部函数时的情形)。0x4d6的指令是,push $0×0,这里这个push的0是foo这个函数符号在.rela.plt数据结构中的下标(也可称为索引或者index),用于定位这个foo这个符号(具体参见《程序员的自我修养》,估计以后我也会专门写一篇有关对象文件构成的文章)。执行完push后,就jmp到了0x4c0这个位置,我们看一下0x4c0处写了什么:

00000000000004c0 <[email protected]>:
 4c0:   ff 35 82 03 20 00   pushq  0x200382(%rip)# 200848 <_GLOBAL_OFFSET_TABLE_+0x8>
 4c6:   ff 25 84 03 20 00   jmpq   *0x200384(%rip)# 200850 <_GLOBAL_OFFSET_TABLE_+0x10>
 4cc:   0f 1f 40 00 nopl   0x0(%rax)

又push了一个值,这个值是什么呢?在后面注释中我们可以看到_GLOBAL_OFFSET_TABLE_+0×8这种字样,它又是什么呢?

我先查阅了CSAPP,看到了如下内容:

Image

然后,查阅了《程序员的自我修养》,看到如下内容:

Image

所以,我的理解是,我们可以把_GLOBAL_OFFSET_TABLE_理解成为一个类似数组一样的东西,每个元素保存着一个地址,32位机就是4字节地址,64位机就是8字节地址。

所以_GLOBAL_OFFSET_TABLE_+0×8就是_GLOBAL_OFFSET_TABLE_的第二个元素,参考上面两幅图片可知,这个代表了libtest.so(即模块的ID),_GLOBAL_OFFSET_TABLE_+0×10则为_GLOBAL_OFFSET_TABLE_的第三个元素,为动态解析函数的入口地址。

然后在0x4c6,跳到这个动态解析函数,开始对foo这个函数名进行解析,找到其地址,并patch到0×200858这个位置(这个位置在GOT中),从而第二次调用foo的时候,jmp的地址就不是0x00000000000004d6了,而是foo的实际地址了。

这种,第一次调用foo函数,通过PLT stub(PLT桩代码)进行动态链接(地址解析),找到foo函数真实地址并patch GOT表,第二次直接通过PLT桩代码跳到foo函数真实地址的方式,称为“延迟绑定技术”(lazy binding)

好了,以上便是PLT技术的一些细节实现。另外多说一句,我们可以在运行某使用so库的可执行文件时,使用LD_PRELOAD 来修改动态链接时,符号解析的顺序。也就是说,LD_PRELOAD会告诉动态链接器,想找什么符号的话,先从这里找,如果LD_PRELOAD中所提供so库里有foo这个符号,那么动态链接器会首先到这里找foo的地址,而不会去其他so库中去找。

0×05 Summary

so库的代码段要保持只读,而且数据段也要为各个进程所私有。需要在编译时通过已知的各个符号的偏移量,建立GOT和PLT表,从而间接地达成第一句的目标。

*本文原创作者:PhyzX本文属FreeBuf原创奖励计划,未经许可禁止转载

0×05 Summary

so库的代码段要保持只读,而且数据段也要为各个进程所私有。需要在编译时通过已知的各个符号的偏移量,建立GOT和PLT表,从而间接地达成第一句的目标。

*本文原创作者:PhyzX本文属FreeBuf原创奖励计划,未经许可禁止转载

在物联网即将到来的时代,似乎一切都是连接在一起的。烤面包机,婴儿监控,甚至咖啡机都将连接上网。对于成年人来说,这些设备可以让你的生活更轻松,但是,我不得不提醒一下—方便你的同时也会让网络犯罪分子的入侵更轻松。

QQ截图20170527015959.png

想像一下,动画世界里一个孩子被玩具所包围着,玩耍着,突然间他就被和多其他孩子一起都被恶魔偷走了。每一个在地板上整齐排列的小玩具都有一个小主人,但是他们却都没有发现甚至可能没有注意到他们的玩具被恶魔控制了,而这将使得世界上所有的孩子都可能遭受危险。

不过你完全不需要害怕,因为有明确的标准判定你的电脑是否已经加入了互联网的僵尸行列。在今天的文章中,我们将解释什么是僵尸网络,僵尸网络是如何进行犯罪行为的,以及如何发现我们的设备控制在botmasters手中。

什么是僵尸网络?

为了解释这一点,首先让我们看一下bot是什么。

bot由一种特洛伊木马感染所造成的,这种恶意软件隐藏在你的操作系统中,等待着由被称为botmaster或bot herder的犯罪者的命令以及控制服务器的指令。bot可以代表其主人执行各种自动化任务,例如发送钓鱼诈骗电子邮件或运行键盘记录器来收集信用卡详细信息。所有受到这种非法活动的网络犯罪分子安全地位于互联网上的某个地方。

僵尸网络可以控制成千上万台的设备,这意味着只要这个雪球不停的滚动,网络犯罪分子的危害能力就会不断的扩大。他们不是从一台电脑发送100封垃圾邮件,而是用20万台电脑发送10封邮件。

当然,bot并不总是电脑。任何互联网设备都能被感染,闭路电视、摄像机都曾出乎意料地被劫持过。一个受感染的设备是bot,而这些bot的集合就形成了僵尸网络。

僵尸网络如何工作?

像任何恶意软件感染一样,bot感染有特定的阶段,进入系统,与botmaster进行通信并执行任务。对他们的最好解释如下:

 1495821145863834.png

感染

botmaster发送恶意软件来感染计算机。这些可以通过驱动下载,可疑电子邮件附件或社交媒体帖子中的链接进入您的计算机。bot恶意软件将利用您软件中的漏洞,通过您过时的插件或过时的操作系统寻找后门访问。然后,它就在您的系统中生根了。

联系

在您的系统中,恶意软件将使用互联网与命令和控制服务器(C2)进行联系。您的计算机将在此阶段保持闲置,bot休眠,除了定期检查botmaster的指示外。由于系统的影响如此之小,您却完全不了解这一切。

控制

僵尸网络作为一个整体可能会在等待执行任务时休息一段时间。一旦botmaster有一个僵尸网络的目标,他/她就会通过命令和控制服务器向bots发送指令。在这个阶段,僵尸网络引导程序唤醒并开始执行恶意活动,例如发送垃圾邮件或参与DDoS攻击。

滚雪球

同时,botmaster将专注于招募越来越多的电脑来扩展僵尸网络。由于这些电脑似乎没有做任何事情,僵尸网络可能会包含成千上万的僵尸电脑,而不会引起任何怀疑。

僵尸网络主要用途

僵尸网络作为非法活动的代理服务器,不会暴露犯罪者。非法活动超过数千个设备的传播隐藏了犯罪的根源,同时为网络犯罪分子提供了几乎无限的计算能力。这可以用来:

1.提交广告欺诈。可以利用数千台电脑重复点击广告,为利用广告点击赚钱的欺诈者提供充足的利润。
2.下载并分发非法材料,如儿童色情内容,或一般垃圾邮件人在线。公司将付出巨额的资金,尽可能广泛地传播广告。租用僵尸网络或雇用一个可以访问的业务是实现此目的的最简单的方法。
3.挖掘比特币可以通过将工作量分散在数千机器人上来使其变得更富有。
4.窃取您的私人数据,包括通过使用键盘记录器来窃取密码和信用卡信息。
5.提交僵尸网络DDoS攻击和重载,弄崩溃一个在线服务,如Twitter或Spotify。
6.发送垃圾邮件,以骗取新的受害者的信用卡信息和私人信息。
7.通过电子邮件附件将ransomware传播给新的受害者。
8.每个计算机都可以算作一个独一无二的投票,以僵尸网络进行投票欺诈可以极大地影响结果。
9.强力攻击企业服务器,找出一个密码,并访问一个主要的业务网络。

你可能会认为这与你无关,你的电脑绝不可能是这些里的几千之一。但是,你知道宙斯僵尸网络是由美国的360万机器人组成吗?目前世界上有四分之一的人口每月访问Facebook,这是Zbot(Zeus)和其他恶意软件的受欢迎的感染源。您的设备中至少有一个可能与其中一个机器恶意软件系统有可能接触。

请记住,这不仅影响您的计算机。所有互联网设备都是易受攻击 像之前那次攻击一样,一系列智能烤面包机,DVR和其他网络设备打破了互联网,夺走了亚马逊,纽约时报,Netflix以及我们生活中的许多其他服务。

这是一个特别可怕的想法,完整的初学者可以在不到15分钟内在自己的家中舒适地创建一个僵尸网络。想象一下,现如今的黑客们,无限资源可以做些什么呢?这里面甚至会包括您的冰箱或家用电脑。

这会影响每个人。如果你的电脑进行非法活动,不知道显然不能作为借口。甚至如果非法行为来自您的计算机,您是需要负责任的。

2.png

值得注意的僵尸网络攻击

攻击者的主要优点之一是使用僵尸网络来隐藏其身份。这样可以实现较大规模的攻击,对botmaster的影响最小。以下是一些值得注意的最近的例子:

Mirai僵尸网络

Mirai的名字来自日语,意思是“未来”。相信是来自一个名叫未来Nikki的动漫系列。Mirai,通过不断扫描互联网,获取物联网(IoT)设备的 IP地址。扫描时会识别易受攻击的小工具并登录到其中。一旦进入,它就会被恶意软件感染。

就像计算机上的机器人一样,Mirai的远程恶意软件在系统影响很小的设备上运行。Mirai的僵尸网络近来被用于一些最大规模的DDoS攻击,其中包括:

在2016年9月袭击的安全博客 Krebs on Security.。
对法国网络运营商OVH的攻击也是利用Mirai的僵尸网络。
2016年10月的攻击,DNS服务提供商Dyn成为其目标。这次僵尸网络攻击有具有非常大的影响,它使Twitter,Amazon,Netflix,AirBnB和Reddit离线了。并且利比里亚的整个互联网基础设施也成为了其攻击目标。
Mirai已经成为迄今为止记录的最大的攻击,并且其仍在继续向僵尸网络部队感染设备。

Hajime僵尸网络

Hajime僵尸网络在2015年10月由Rapidity Networks发现,Hajime试图尽可能多地寻找机器人。留下的注销声明声称,Hajime的唯一目标是在Mirai或任何其他botherder可以访问之前保护IoT设备。然而,一些安全专家质疑Hajime是否真的是一个白帽子的操作,声称虽然其关闭了Mirai的大门,但却打开了自己的。

Hajime已经控制了超过30万个受感染设备,主要是DVR,路由器和互联网连接的摄像机,但目前并不用于任何恶意活动。我个人比较关心的是,如果这个僵尸网络被劫持了,那么谁知道可以被用来做什么。

宙斯/ Zbot僵尸网络

宙斯与Mirai的传播方式相同,多年来一直这样做。并且它是窃取银行信息的首选木马,它通过浏览器中的键盘记录器攻击工作,接收所有的网络银行和信用卡详细信息。它也被用来欺骗每天的PC用户认为他们的计算机感染了一些其他类型的病毒通过技术支持诈骗弹出窗口。

在其活动的峰值时间段,宙斯危及了美国银行,NASA,ABC,思科和亚马逊。在Mirai之前,这是最大的僵尸网络,它并不是执行DDoS攻击,而是传播了CryptoLocker Ransomware。

你知道一旦感染了bot恶意软件,你可以永远感染吗?

如果对您的计算机的影响是如此难以察觉,您怎么知道这个恶意软件已经扎根于您的系统?别担心,还是有一些明显的迹象可以发现的。

僵尸网络感染症状

系统速度突然减慢

如果您的设备突然降低到僵尸速度,可能是您的系统太忙,才能执行攻击者发出的命令来完成您的常规任务。看看你的任务管理器,看看发生了什么。如果您看不到任何解释系统滞后的过程,您可能需要更深入一些—检查在后台运行的内容,以及是否在系统上托管不需要的数据。

不明原因的系统卷更改

同样,请检查您的硬盘空间。你没有理由突然失去数量吗?这可能是因为一个隐藏的主机正在使用这个空间并隐藏自身。检查硬盘驱动器有三个非常简单的步骤:

1.打开文件资源管理器 您可以使用键盘快捷键,Windows键+ E或点击任务栏中的文件夹图标。
2.从左侧窗口点击或单击此PC。
3.你可以在Windows(C :)驱动器下看到硬盘上的可用空间量。

4.png

突然的网页浏览器或电子邮件问题

你的网络浏览器是否经常无缘无故地崩溃?您是否收到首先没有发送的退回邮件?这些都是你的计算机被用于你不知道的目的的所有可能的迹象。

如何防止感染

防止僵尸网络恶意软件就像防止任何其他类型的恶意软件,并且因为在系统中很难删除,所以预防是你唯一真正要做的。

对于PC

定期软件更新至关重要。确保将你的操作系统和应用程序保持最新,作为常规电脑清洁的一部分。

点击一些邮件之前想一想。不要从你不认可的发件人(或发件人您认可但没有要求的附件)打开邮件附件。同样,请注意任何电子邮件,要求您点击链接。通过网络钓鱼欺诈以及恶意软件的典型方式来不断的学习教育提高自己的意识。

使用优质的反恶意软件套件保持拒绝0day威胁。

对于其他互联网设备

更改默认密码。我们收到的许多产品都设置了默认密码。这些包括WiFi路由器,如果您没有设置唯一的密码,可以非常快速地访问。

关闭您的设备的远程访问,以免他人未经授权访问。

在连接到互联网之前研究新产品。制造商可能已经有安全漏洞。在连接互联网之前对所有修补程序进行修复。