Aggregator
以攻击者角度学习某风控设备指纹产品
自己的一些漏洞分析文章汇总【含0day】
前几年做的一些漏洞分析复现或预警的文章,后来做管理岗,仅对感兴趣的漏洞做分析,写文写的少了。今天整理了下,存个档。
注:由于国家政策限制,有一些只对外发了预警,详细的版本均发送给了监管机构。有一些访问404的是因为不方便公开细节。对于0day申请了cve编号,详情都发在sec-list。
CodeQL学习——CodeQL CLI入门 - bamb00
vDPA kernel framework introduction
[胖猴小玩闹]智能门锁与网关第四篇: 海康萤石智能门锁的网关分析(4)
敵人不是勒贖軟體,而是組織型駭客
駭客攻擊事件一直存在於真實世界,只是鮮少被完整公開揭露。今年國內一些重大關鍵基礎設施 (Critical Information Infrastructure Protection,CIIP) 以及國內的跨國企業紛紛發生嚴重的資安事件,我們想簡單的跟大家談談這些事件背後企業真正需要思考及重視的核心問題。
企業面對的是組織型駭客而不只是勒贖軟體不知道是因為勒贖軟體比較吸睛還是什麼緣故,媒體比較喜歡用勒贖軟體作為標題呈現近年企業面臨的重大威脅。實際上,勒贖軟體只是攻擊過程的工具、加密只是勒贖的手段之一,甚至包含竊取機敏資料。因為這些事件我們沒有參與調查或相關的活動,我們僅就已公開揭露的資料來一窺面對這樣的威脅,企業的具體做法有哪些?
根據法務部調查局在 iThome 2020 資安大會的分享
在這起攻擊事件中,駭客首先從 Web 伺服器、員工電腦等途徑,入侵公司系統長期潛伏及探測,而後竊取帳號權限,進入 AD 伺服器,利用凌晨時段竄改群組派送原則(GPO),同時預埋 lc.tmp 惡意程式到內部伺服器中,等到員工上班打開電腦後,電腦立即套用遭竄改的 GPO,依據指令就會自動將勒索軟體載到記憶體中來執行。
企業在被勒贖軟體加密後,往往第一時間容易直覺想到防毒軟體或端點防護設備為何沒有生效?現實是,如果企業面對的是針對式的攻擊(Advanced Persistent Threat,APT),攻擊者勢必會研究可以繞過企業的防護或監控的方式。所以企業要思考的應該是一個防禦戰線或更為全面的防護策略,而非仰賴單一的資安設備或服務。
從上述的敘述,我們可以發現幾個問題:
- Web 伺服器具有可利用的漏洞,而這個漏洞可能導致主機被取得權限進行後續的橫向移動。造成這個問題的原因可能包含:
- 系統從未進行高強度的滲透測試及定期執行弱點掃描
- 屬於老舊無法修補的系統(使用老舊的框架、程式語言)或是廠商已經不再維護
- 一次性的活動網站或測試網站,活動或測試結束後未依照程序下線,成為企業防禦破口
- 不在企業盤點的防護範圍內(如前端未設置 WAF)
- 從員工電腦或是 Web 伺服器可以逐步跳到 AD 伺服器,可能存在的問題則包含:
- 網路間的區隔不嚴謹,例如未依照資料或系統的重要性進行區隔
- 同網段伺服器間的通訊方式管控不當,沒有開啟或管制重要伺服器的通訊埠或限制來源 IP 位址
- 系統存在可利用取得權限的弱點
- 利用凌晨時段竄改群組派送原則:最後是回應機制未即時(包含人員接獲告警後處理不當),企業對於具有集中管理權限的重要系統,例如 AD Server、資產管理軟體等這類型的主機,除了對特權帳號高強度的管理外(如 OTP),也應該針對「異常帳號登入」、「異常帳號新增到群組」、「正常帳號異常登入時間」、「新增排程或 GPO」等行為發出告警;而各種告警也應該依照資產的重要性訂定不同的 SLA 回應與處理。
我們在近三年的紅隊演練,以企業對其營運最關鍵的資訊資產作為演練標的,並模擬組織型駭客的攻擊模式,透過外部情搜、取得外部系統權限、橫向移動、持續取得更多內部伺服器權限及提權、破解密碼,最終達到企業指定的關鍵資產執行演練情境。而企業透過高強度且精準的演練過程,除了明確掌握可被入侵的路徑外,更得以檢視上述問題的不足並持續改善。
我們認為,只要你的企業夠重要(對駭客而言重要,而不是自己覺得重要),組織型的攻擊就不會停歇!企業唯有不斷的找出自己不足之處,持續提升自己的防禦強度才是能真正降低風險的正確作法。
至於「第三方供應鏈安全」及「如何更完整的制定資安策略」,我們將找時間另外跟大家說明。
The New Kid On The Cyber Block: Data Manipulation
初识CodeQL原理与漏洞挖掘过程
【VK技术分享】数据安全怎么做——数据分类分级
冰蝎3.0-分析系列 1-beta2-php
冰蝎3.0-分析系列 1-beta3-php
河马查杀1.8.2 发布|支持检测冰蝎、哥斯拉后门
漏洞分析丨WordPress评论插件wpDiscuz任意文件上传
How Criminals Attack the Games Industry
通用组件安全治理三步走实践
How I Designed an Open Source HTTPS Checker
通达OA11.6 preauth RCE 0day分析
0x00关于本文这漏洞我7.4挖出来交给先知,6号审核通过但是迟迟不发奖金,再留言就又是审核中,一直审核到现在(怀疑是因为厂商7.5的新版本就不收影响了,阿里觉得亏了?)护网听说这玩意爆出来了,群里面看知道创宇都有漏洞详情了,感觉吧这个烂在我手上显得没价值,倒不如在EXP流传的到处都是之前,放出来找找乐子exp放在了https://github.com/TomAPU/poc_and_exp/blob/master/rce.py需要者自取(注意,该EXP不是无损EXP,会删除auth.inc.php让OA无法正常工作)
这个漏洞结合了任意文件删除漏洞以及文件上传漏洞,需要两个漏洞配合才可以实现preauth rce复现需要的11.6安装我传到Google上面了:https://drive.google.com/file/d/1L3wG58EQpCufwqoTRP3lFq7IY6PYYqZ-/view?usp=sharing需要者自取
0x01貌似鸡肋的任意文件删除漏洞首先漏洞是在/module/appbuilder/assets/print.php里面一眼看过去,就是把get里面的guid传过去然后删除掉但是任意文件删除漏洞除了搞破坏有什么卵用呢,反正一眼看过去是没什么卵用的
0x02化腐朽为神奇的身份绕过尽管删文件看似只能做破坏,但在某些时候也能绕过一些认证!这是怎么做到的呢?我们来看看通达OA里常用来做身份校验的代码这里呢,简单来讲就是把auth.inc.php给包含进来,如果没有对应session的话,auth.inc.php就会作为“拦路虎”,让用户去登陆,但是删掉会怎么样?这里就要看php里面include和require的区别了这两个东西看起来很相似,都是包含嘛,但是稍稍学过洋文的都知道,include的意思指的是包含,而require却有要求的意思,在这里就可以看出点区别了。如果要包含的文件找不着,include就索性跳过去了,而require是要求,感觉更加强烈一些,找不着文件就撒泼打滚fatal error停止不前了。而恰巧通达OA里面用的都是include,于是如果发现auth.inc.php失踪了,就会直接跳过去!因此我们只需要利用前面的漏洞,删掉auth.inc.php,即可跳过通达OA里面大部分身份验证!
0x03最后一击!变量覆盖&任意文件上传除了身份绕过,我们还要找到一个漏洞点,来getshell
这里我们看到general/data_center/utils/upload.php这前面包含的header.inc.php会将$_REQUEST中的所有东西注册成变量(或者是别的被include进来的文件,因为一个月之前挖掘的,现在记不真切了)这样的话我们就有玩变量覆盖的可能性了!这里呢我们直接跳到漏洞点,就是最下面那个else(为什么直接跳呢?因为其实老版本的代码我删了,这点是我拿漏洞报告里面的代码片段粘的,新版本把这个改的面目全非,而我又忘了代码怎么弄的了,所以直接讲这个漏洞点,想研究的自己搞来分析)
这里则个$s_n是这样的,如果开头不是"{"那么$s_n前面加上一个$repkid,那么就可以通过变量覆盖,传入参数覆盖$repkid,加入../跳到别的目录去(为什么要跳到别的目录呢?因为通达OA的nginx配置中,上传文件所在的attachment目录里面的PHP不准访问,因此必须要跳出去)
那么综合上述就可以给出EXP了(在前面给了)
0x04修复方案删掉这个/module/appbuilder/assets/print.php或者升级到最新版(11.7)(不要自定义WAF规则拦截,通达OA对$_REQUEST里面的东西的全局过滤,导致黑客可以添加<>之类会被过滤掉的内容来绕过去)0x05吐槽昨天说深信服的代码质量不佳,是因为里面有许多奇奇怪怪的用法而这个通达OA的代码质量,只能用惨不忍睹来形容我就说四点1.首先代码里面有的时候会有些调试用的代码片段,莫名其妙打出某个变量,突兀地出现在屏幕上面2.接着呢,这里面有许多没用的PHP文件,散乱地堆在那儿3.还有,代码里面有些地方用了框架,有些地方没有用框架。然后代码各种风格都不统一,强行赛在一块的4.里面有很多不安全的写法,比如说直接echo一个$_GET参数出来,结果又是全局替换过滤了GET参数的,似乎是防护了问题,但是众所周知防护XSS从根本上来说还是要靠编码,这种全局过滤的歪路子,只要哪里没限制好就会出问题
物联网安全之MQTT协议安全
MQTT 全称为 Message Queuing Telemetry Transport(消息队列遥测传输)是是ISO 标准(ISO/IEC PRF 20922)下基于发布/订阅范式的消息协议,由 IBM 发布。由于其轻量、简单、开放和易于实现的特点非常适合需要低功耗和网络带宽有限的IoT场景。比如遥感数据、汽车、智能家居、智慧城市、医疗医护等。
MQTT协议MQTT协议为大量计算能力有限,低带宽、不可靠网络等环境而设计,其应用非常广泛。目前支持的服务端程序也较丰富,其PHP,JAVA,Python,C,C#等系统语言也都可以向MQTT发送相关消息。 目前最新的版本为5.0版本,可以在https://github.com/mqtt/mqtt.github.io/wiki/servers 这个连接中看到支持MQTT的服务端软件。 其中hivemq中提到针对汽车厂商的合作与应用,在研究过程中会发现有汽车行业应用了MQTT协议。
以下列举我们关心的几项:
- 使用发布/订阅的消息模式,支持一对多的消息发布;
- 消息是通过TCP/IP协议传输;
- 简单的数据包格式;
- 默认端口为TCP的1883,websocket端口8083,默认消息不加密。8883端口默认是通过TLS加密的MQTT协议。