文章來自我們的老朋友：lawliet

這個問題的由來是因為自己在復現redis未授權訪問漏洞時，通過向linux任務計劃文件裡寫反彈shell的命令時，發現shell並不能反彈回來，之前使用的server端為Centos，一切順利並沒有出現這種問題，結果這次server換成了ubuntu，就出現不能反彈的問題，結果因為這個問題卡了很久，最終在kakaxi和ttgo2兩位大佬的指導和幫助下才解決了該問題，將整個問題的解決過程在這裡記錄一下~

環境說明

ubuntu16.04桌面版：192.168.0.107，用來任務計劃反彈shell的靶機

kali2.0：192.168.0.106，用來接收ubuntu反彈過來的shell具體過程

案發現場

事情源自於我利用redis未授權訪問漏洞在向ubuntu的目錄下創建任務計劃文件去反彈shell時，發現shell並不能反彈到自己的kali上

任務計劃文件內容如下

需要特別注意的一點是這的root文件的權限必須為600，也就是，否則會出現的錯誤，會影響到後面的實驗但是kali卻遲遲接收不到反彈過來的shell

之前在centos上利用的時候並沒有出現這種情況，使用ubuntu的時候居然不行，下面我們就來一步步的排查看看到底是什麼原因導致的

懸疑

首先，咱們先來看一下系統日誌

通過系統日誌可以看到這一條，我們之所以反彈shell失敗，和這句話有著很大的關係，百度了一番後得到這句話的大概意思就是我們任務計劃裡的命令執行如果出現了錯誤，ubuntu會將這些錯誤信息去輸出到ubuntu系統的郵件服務器，但是由於ubuntu系統默認沒有安裝郵件服務器，所以才導致了上面的錯誤。

發現蛛絲馬跡

通過了上面的信息，可以推斷出我們任務計劃中的命令執行出現了某種錯誤，然後ubuntu處理這種錯誤方式是將錯誤信息發送到本地的郵件服務器，但是郵件服務器不存在，那麼我們要想辦法將錯誤信息重定向到文件裡面去看看究竟是命令的什麼地方產生了錯誤，修改任務計劃文件為

1代表標準輸出。2代表標準錯誤輸出，也就是命令執行出現的錯誤，這裡將執行的標準錯誤輸出重定向到輸出流，也就是這個文件中，而不是郵件服務器，然後再看日誌就沒有剛剛的錯誤了

下面可以看到tmp目錄下新生成了一個記錄錯誤信息的文件error.txt,內容如下

這條錯誤的意思說/bin/bash沒有被找到，通過錯誤信息還可以明白一件事情，那就是linux裡面的cron中command執行的shell環境是/bin/sh，那我們可以再來看一下ubuntu下的/bin/sh文件究極是一個怎麼樣的文件

尋根問底，真相大白

可以看到/bin/sh其實是一個軟連接文件(l),類似於windows中的快捷方式，只不過在ubuntu中/bin/sh這個軟連接指向了dash，而我們反彈shell使用的shell環境是dash，所以這一點是反彈出錯的根本原因那麼之前的centos為什麼就能成功，下面來看一下centos/bin/sh的指向