1. 程式人生 > >關於雲大Urp系統的個人分析和一些不成熟的看法

關於雲大Urp系統的個人分析和一些不成熟的看法

0x00 背景

  本來這篇文章只對作者可見的,鑑於現在已經對系統進行了更新,12月中旬下旬期間將會正式啟用,所以這篇文章也放出來,當作交流和學習吧。關於雲大Urp系統,我想初入學校參加過選課的同學應該都是比較有印象的。作為一個教務管理系統,在各個方面應該說還是做的比較完善,畢竟其他不少學校是花錢買公司製作的教務系統來使用(我貌似又一不小心吐槽了一下學校又節約開支了 = =)。下面詳細記述了系統的一些漏洞和引數,比較偏技術,有一點技術基礎的話可以簡單看一看,我這裡主要是歸納一下。想直接看分析結果的可以直接跳到0x03章節哦。

0x01 例項
  我寫這篇文章主要是為了記述一下入侵過程,當然也是在大神強烈地要求下我才寫的,畢竟我沒有寫過類似這樣的滲透報告。 
  ynumis.ynu.edu.cn/ynumis是我們學校Urp的網址,剛開始想到的手段就是尋找哪裡存在注入點,所以我開始對各個登陸點進行掃描,無一例外的失敗。後來想到了選課系統中的踢課漏洞,所以考慮對這個點進行突破。
  選課系統和檢視全部課程的功能都是使用xml soap進行的信封裝post上去的。在這個過程中soap中的引數作為注入點進行測試,不過還是失敗(後來結果證實了幾乎所有的資料庫查詢或者刪除、更新操作,都是採用的儲存過程進行的引數化傳遞,把所有的引數都轉化為字串進行傳遞,所以字串裡面的內容當然沒法得到執行啦)。當然對於xml和soap還有其他的攻擊方式,我也拜讀了不少大牛的文章,然後直接拿去用還是不成功,其主要原因是本人對xml這樣的框架處於無知的層面,準確一點是對web伺服器、網路傳輸等處於一知半解的狀態,所以也沒法繼續實施相應的攻擊。
  在進一步的掃描結果中,在校級、院級管理等登陸介面存在XSS反射型漏洞,不過對於XSS漏洞的利用,特別是反射型漏洞本人也是知之甚少,又不會搭建伺服器付諸於實際,也只能作罷。
  之後無奈,只能迴歸到掃描目錄的狀態,當然掃描目錄的時候也是有所收穫,比如發現了目錄下的下載點,得知Urp系統主要是使用360防毒軟體和360安全軟體作為安全監控,很顯然用360作server的安全監控是很無力的……沒多大用。還有另外一個下載點也是有不少其他東西,不過對滲透沒有什麼幫助,也就略過了。
  絕大部分的目錄都是deny的狀態,在幾個使用者常用的asmx檔案倒是可以直接開啟,查詢到其他的post方法,不過也沒有我能知道的漏洞存在。最後我還是通過目錄的掃描獲取到一個測試用的上傳點,算是自己比較幸運吧。之前有大神提交了一個關於Urp的上傳漏洞報告,是遺留的kinder編輯器的漏洞,從目前的情況來看這個漏洞已經是被修復了。另外由於Urp開放了3389遠端桌面的埠,也就使得server上的可以進行介面化操作,由此可見Urp的漏洞還是很多的……
  Urp漏洞總結:登陸介面XSS反射型漏洞,download下檔案可下載,編輯器上傳漏洞,3389埠遠端桌面的漏洞,選課系統構造post從而達到偽裝身份目的的漏洞(這個是一直以來詬病最大的漏洞了)

0x02 修復

       1.所謂的踢課漏洞:主要是對使用者身份進行了多餘的驗證,在登陸時server已經把使用者的ID存進了session[]中,但是在選課系統位置對使用者ID進行再次確認和讀取,這是沒有必要的,可以修改asmx.cs中的程式碼,獲取session中的資訊,從而獲取學號ID,當然在soap的封裝裡面也要進行修改。
       2.編輯器上傳漏洞:該漏洞檔案應該屬於作測試用,可以直接刪除從而避免漏洞利用。
       3.download檔案下載漏洞:這個漏洞可以看到download目錄下的所有檔案,如果非需要建議把瀏覽許可權關閉。
       4.3389埠漏洞:這是一個可遠端操作桌面的漏洞,如果非需要,建議關閉埠。
       5.登陸介面XSS漏洞:修改登陸介面框架程式碼,反正我也不懂怎麼修改,也只能說管理員君請自行百度……

0x03 分析

       1.之前聽說Urp是8核的臺式電腦,這裡我要糾正一下:IBM-xxx(這個主機名我忘記了額)、16核cpu、windowsserver 2003 R2作業系統、IIS-6.0+asp.net、Microsoft SQL Server 2000、Microsoft Visual Studio 2005(這個沒用 = = 說著玩吧),另外在院級管理、校級管理那塊兒使用的是一個叫netcase的辦公網路系統。
       2.當我瞭解到為人詬病的選課系統的具體結構的時候,我也是比較驚訝的:選課系統也是使用儲存過程進行資料庫操作。在新增選課時,先是對已選人數+1,再把學號和課程程式碼加進選課名單中;而在退課時,先是把學號和課程程式碼從選課名單中刪除,後對已選人數-1。這樣,在選課高峰期,新增選課可能先對已選人數+1,而沒有把自己加進去;而在退課時先把自己退出去,而沒有對已選人數-1,這是高負荷下過多使用者呼叫同一個儲存過程導致程式碼沒有執行完,陷入死鎖或者伺服器崩潰。結果就是:已選人數往往比真正選到這門課的人要多,而這個時候也就無法進行該門課程的選課了,選課系統會因為虛假的已選人數提示你選課人數已滿,從而使得剛開學期間,有加課需求的同學比較多,同時因為近段時間伺服器的崩潰,使得這種現象越來越明顯。所以這算不算選課系統引發的一種教學事故了?當然也有特殊情況,也有實選人數多餘已選人數的情況出現,不過較於前者和已選人數反映的是真實資料的情況,這種情況就要少很多。
       3.上面就是我主要想告訴大家的選課系統背後的祕密,說得比較冗長,希望不要噴我語言表達有問題 = =
       4.其他的漏洞也無關大家緊要,這裡也就一筆帶過了。

0x04 建議
       1.很多人強烈要求學校更換一個更強大的電腦或者伺服器來解決目前爭議比較大的選課問題。不過我這裡還是闡述一下自己的觀點和看法:首先Urp的伺服器cpu是16核級別的,已經是比較不錯的校園伺服器載體了。其次一年就兩次選課,兩次使用高峰期,為了這兩次高峰期而去購買一臺中低端的伺服器是不經濟的,當然我們學校還特別省錢的說,想想我們等了多久的圖書館大家就明白了。所以更換伺服器,並不是很好的處理途徑,畢竟能用錢解決的問題都不是問題,but no way.
       2.近兩次選課高峰期中,選課系統的崩潰應該是大家始料未及的,這種現象在以前從來沒有發生過。不過由於近期選課軟體的廣泛普及以及更多新興的選課軟體的出現,再加上學校的擴招,使得參與選課的人數也是呈一定比例的上漲,當然擴招並不是主要問題,問題是選課軟體。試想一下,一個人在電腦上開幾個選課軟體刷課,再在用手機app開一個,可能還在機房佔個位置在開以及軟體,另外再自己用IE等瀏覽器手刷,這是多麼恐怖的一件事。這樣一個人就當十個人用了,這樣做的應該也只是小部分。平均下來相當於一萬名學生變成了四五萬人選課,是不是對伺服器太殘暴了一點……
       3.當然這也不是什麼個人的問題,選課這種事情還是要靠人品和一定的經驗,不少人還是倡導手刷人品比較高嘛,年輕人用用IE鍛鍊鍛鍊手指還是不錯的,o(∩_∩)o 哈哈,開個玩笑。總之是建議大家要開選課軟體開一個就行,選課系統崩潰,大家正常的生活也被打亂了不少不是麼?

希望大家謹記:選課靠人品,切勿多開掛