Posts List

2019 年针对 API 安全的 4 点建议

原文:4 Tips for Better API Security in 2019 译者:neal1991 welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 无论是在科技媒体亦或是分析报告中,2018年 “API”以及“安全”变得越来越常见,-或者更糟糕,“API” 以及“违规”一起出现在头条中。 APIs(应用程序编程接口)不仅是应用程序,系统和数据之间的连接组织,而且是允许开发人员利用和重用这些数字资产以实现新目的的机制。API 几乎影响到每个数字用例,它们在安全新闻中的作用不仅仅是 API 中的一个内在缺陷,因为它们中的一些已被破解,因此存在明显的缺陷。 但是头条新闻强调了一个重要信息:如果 API 安全性不是企业 2019 年优先事项的首要事项,那么优先级列表就不完整。 实际上,API 安全的要求正在成为一种共识: 在 2017 年 12 月的报告“如何构建有效的API安全策略中,”Gartner 分析师 Mark O’Neill, Dionisio Zumerl e和 Jeremy D’Hoinne 预测,“2022年,API 滥用将是最常见的攻击向量,导致企业网络应用程序的数据泄露。” OWASP Top 10是一个备受推崇的 Web 安全威胁列表,其中多次提及 API。其明确的警告包括针对没有保护即传输敏感数据的 API 的警告,针对可疑行为而未监控流量的 API 以及使用易受攻击组件的 API。

隐写术-深入研究 PDF 混淆漏洞

原文:“steganography” - obfuscating PDF exploits in depth 译者:neal1991 welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 上礼拜发现的关于使用 this.getPageNumWords() & this.getPageNthWord() 方法来进行混淆的 PDF 漏洞不久,我们发现另外一个,一个在 PDF 漏洞中更加强大的混淆利用技术。这种技术使用所谓的“隐写术”方法来隐藏嵌入在 PDF 文件中的图像中的恶意 Javascript 代码,它非常强大,因为它可以绕过几乎所有的 AV 引擎。 我们的 EdgeLogic 引擎将样本检测为 “exploit CVE-2013-3346”,与前一个相同。 https://edgespot.io/analysis/ebc5617447c58c88d52be6218384158ccf96ec7d7755179a31d209a95cd81a69/ 样本首先在 2017-10-10 提交给 VirusTotal,文件名为 “oral-b oxyjet spec.pdf”。 上周只有 1 个 AV 引擎检测到这种攻击(但是,截至写作时,检测增加到 5/57)。 * https://www.virustotal.com/#/file/ebc5617447c58c88d52be6218384158ccf96ec7d7755179a31d209a95cd81a69/detection 打开后,伪装成 IRS 文件的 PDF 看起来很正常。

什么是DDOS

什么是 DDOS DDOS(Distributed Denial of Service),即分布式拒绝服务,是一种针对于网络服务的攻击行为。对于 DDOS 我们可以这样通俗地理解,假如有一家商店在售卖商品,突然涌过来一大帮人说要买东西,这里面有的人是真正地顾客,有的人只是过来捣乱的,但是售货员如果没办法及时处置,就会导致一种拒绝服务攻击了。而分布式拒绝服务攻击,则是因为黑客控制了很多台肉鸡来发动攻击。这种攻击近些年来越来越流行,对于攻击者来说,成本小,但是相对收益大,对于受害者来说,造成的伤害却是巨大的。因为对于服务提供者来说,一旦服务不可用,就会造成不可挽回的损失,可能会导致用户量的流失。根据腾讯云发布的《2018年泛互联网行业DDoS攻击态势报告》,2018年 DDOS 攻击已经进入 TB 时代,2018 年的攻击峰值为 1.23Tbps(同比增长121%),而业界的攻击峰值更是达到惊人的 1.94Tbps。 有人说对于 DDOS 攻击,有钱的话,就死命扩容,没钱的话,就忍一忍。虽然是玩笑话,但是有一定的道理。最近也是自己了解 DDOS 攻击这一块知识,下面简单介绍一下自己看到的一些。 DDOS 攻击类型 常见的 DDOS 攻击主要包括以下几类:网络层攻击、传输层攻击、会话层攻击以及应用层攻击。 传输层 DDOS 攻击 传输层 DDoS 攻击一般是针对于 TCP 以及 UDP 协议地攻击,主要是指 Syn Flood,Ack Flood,UDP Flood,ICMP Flood、RstFlood 等攻击。 以最常见的 DDOS 攻击 Sync Flood 为例,它利用了 TCP 协议的三次握手机制,当服务端接收到一个 Syn 请求时,服务端必须使用一个监听队列将该连接保存一定时间。因此,通过向服务端不停发送 Syn 请求,但不响应 Syn+Ack 报文,从而消耗服务端的资源。当等待队列被占满时,服务端将无法响应正常用户的请求,达到拒绝服务攻击的目的。 DNS DDoS 攻击 DNS 服务对于企业来说是比较重要的,因此针对 DNS 服务的 DDOS 攻击也是比较常见的。DNS DDoS 攻击主要是指 DNS Request Flood、DNS Response Flood、虚假源+真实源 DNS Query Flood、权威服务器和 Local 服务器攻击。

GShark-监测你的 Github 敏感信息泄露

近几年由于 Github 信息泄露导致的信息安全事件屡见不鲜,且规模越来越大。就前段时间华住集团旗下酒店开房记录疑似泄露,涉及近5亿个人信息。后面调查发现疑似是华住的程序员在 Github 上上传的 CMS 项目中包含了华住敏感的服务器及数据库信息,被黑客利用导致信息泄露(这次背锅的还是程序猿)。 起源 对于大型 IT 公司或者其他行业,这种事件发生的概率实在是太常见了,只不过看影响的范围。现在大家看到的,也仅仅只是传播出来的而已。企业没办法保证所有人都能够遵守规定不要将敏感信息上传到 Github,尤其是对于那种特别依赖于外包的甲方企业,而甲方的开发人员也是一无所知,这种事件发生也就是司空见惯了。 废话说了一大通(可能是最近看安全大佬的文章看多了),终于要介绍一下我的这个项目,GShark。这个工具主要是基于 golang 实现,这也是第一次学习 golang 的项目,结合 go-macron Web 框架实现的一个系统。其实最初我是看到小米安全开源的 x-patrol 项目。网上这种扫描 Github 敏感信息的工具多如皮毛,我看过那种 star 数上千的项目,感觉实现方式也没有很好。因为说到底,大家都是通过 Github 提供的 API 结合相应的关键字来进行搜索的。但是,x-patrol 的这种实现方式我觉得是比较合理的,通过爬虫爬取信息,并对结果进行审核。所以,最初我是一个 x-patrol 的使用者。使用过程中,也遇到过一些问题,因为这个库似乎就是小米的某个固定的人维护的,文档写的不是特别清晰。中间我有提过 PR,但都被直接拒绝掉了。后来,我就想基于 x-patrol 来实现一套自己的系统,这也就是 GShark 的来由了。目前,这个项目与 x-patrol 已经有着很大的变化,比如移除了本地代码的检测,因为这个场景没有需求,其实我本身自己也实现了一个基于 lucene 的敏感信息检索工具。另外,将前端代码进行了梳理,并使用模板引擎来做模板的嵌套使用。基于 casbin实现基于角色的权限控制等等。 原理 讲完了起源,接着讲一讲这个系统的原理。基本上,这类工具都是首先会在 Github 申请相应的 token 来实现,接着通过相应的 API 来进行爬取。本项目主要是基于 Google 的 go-github。这个 API 使用起来还是比较方便的。通过这个 API 我们可实现在 Github 来进行搜索,其实这基本上等同于 Advanced Search。因为 API 提供的搜索能力肯定就是 Github 本身所具有的搜索能力。最基本的包括关键及,以及一些 owner 信息以及 star 数等等。

Qradar SIEM--查询利器 AQL

对于 SIEM 平台来说,好用的查询方式非常重要。之前有体验基于 ELK 搭建的平台,在 kibana 上面是可以通过一些 filter 来做一些过滤并且是支持 lucene 的语法,包括一些简单的逻辑查询以及 wildquery 等等。但是的确是在做一些汇聚之类时不是很方便,一般需要通过 json 来构建更高级的查询语句。后来好像也有转 SQL 之类的插件,但我也没有使用过,总的来说体验比较一般。 Qradar Qradar 是 IBM 一款比较成熟的商业 SIEM 平台(尽管他们的 BUG 一大堆,但架不住别的更差啊),基本上也是属于业界 TOP 5。商业产品的好处就是不用自己太折腾,搞搞就可以用,缺点就是贵。AQL(Ariel Query Language)是 Qradar 中的一种查询语言,与普通的 SQL 的语句类似,但是阉割了一些功能也增加了一些功能。以下是 AQL 的基本流程: 可以看出 AQL 是一种非常类似于 SQL 的语言,所以基本上你用过 SQL 学会 AQL 也就分分钟的事情,而且你也不会拿它去做特别复杂的嵌套查询(因为它也不支持。。。) Tips 虽然 AQL 终于让我们有枪可以搞一搞了,但是还是有一些地方值得吐槽的地方。第一就是很多 ID 不知道其具体的映射,就比如我们想查询一些事件的名称或者规则的名称,AQL 是不存在字段名是事件名称或者规则名称的。不过你可以通过函数来进行转换,比如使用 QIDNAME(qid) 来获取事件名称,RULENAME(123) 来获取规则名称。你没办法知道事件名称或者规则名称到底是对应什么 ID,目前我用的办法就是先去 IBM Develop API 里面先去查询。第二,AQL 查询的结果我发现有某个规则的查询结果和用 filter 查询的结果不一致,不知道这是不是特例。还有其他的,想到再说。 下面就是我在使用过程中一些小经验: 引号的使用 在 AQL 中,单引号和双引号的使用是有区别的。单引号一般可以表示字符串或者作为字段的别名,如果你的字段包含了空格,那么你必须使用单引号。双引号一般用来表示自定义属性的名称。还有一个值得注意的地方就是,当你在使用 WHERE, GROUP BY, ORDER BY 的时候,你必须要使用双引号来使用别名,而不是单引号,是不是有点绕。其实有个好的方法就是不要使用单引号了,直接使用帕斯卡命名或者使用下划线连接,比如 EventName 或者 Event_Name,其实你自己想怎么命名都可以啦。

黑产代码解密--利用canvas加载代码

前段时间获取到黑产的一些代码,不得不感叹黑产的代码实在在写的是好得很,思路巧妙,环环相扣。不得不说,技术不好,黑产都做不了了。虽然分析了好多天,但是也只是一知半解。这里抽出一小部分来讲一下。二话不说,先上代码: 最初的代码是经过混淆的,代码经过整理如下: var createImgElement = function(urla, b) { var imgElement = document.createElement('img'); var canvasEle = document.createElement('canvas'); imgElement['crossOrigin'] = true; imgElement['onload'] = function() { canvasEle.width = this.width; canvasEle.height = this.height; var canvasContext = canvasEle.getContext('2d') canvasContext.drawImage(this, 0, 0, this.width, this.height); for (var canvasContext = canvasContext.getImageData(0, 0, this.width, this.height), cancasDataLength = canvasContext.data.length, arr = [], i = 0; i < cancasDataLength; i += 4) { var code = canvasContext.data[i] var code1 = canvasContext.data[i + 1] var code2 = canvasContext.