2013-01-22 167 views
1

我在瀏覽的mysql-慢日誌檢查potentiall優化和我在他們注意到奇怪的架構(見下圖):Plesk 10.4.4安全漏洞?

SELECT password, type FROM accounts AS a JOIN sys_users AS s ON (a.id = s.account_id) WHERE s.login='**DICTIONARY_USER_NAME_HERE**' AND (SELECT count(*) FROM hosting AS h WHERE h.sys_user_id = s.id) = 0 AND (SELECT count(*) FROM web_users AS w WHERE w.sys_user_id = s.id) = 0 AND (SELECT count(*) FROM ftp_users AS f WHERE f.sys_user_id = s.id) = 0; 

什麼更可怕的是,這些查詢從管理@本地執行(這是指定的Plesk MySQL用戶)

我已經簽入和似乎的Plesk商店中的一些明文密碼和這些查詢是顯而易見的字典法猜出登錄因此MySQL將與明文密碼響應

所以總結起來

  • 查詢稱爲管理@本地
  • plesks密碼以純文本

我不知道什麼是攻擊的載體,但如果我們把幾件事情在考慮:

  • 攻擊者現在不admin的密碼,否則他可以執行 準確的查詢,而不是字典
  • 攻擊者顯然不是通過SSH /遠程MySQL會 執行
  • 它可能在Plesk的錯,因爲我看到它在兩個服務器這 不同的操作系統,不同的配置下運行,只有它的 人有任何內容上(網站/應用程序或任何可能成爲攻擊的可能 矢量)
  • 最有可能的似乎是攻擊者(或機器人在這種情況下 )通過一些在Plesk的不是固定的腳本執行查詢( 那些誰允許這樣的查詢時不需要您登錄)

現在我可能完全錯誤和錯誤理解的情況,這是一種完全正常的Plesk行動(我懷疑)還有什麼奇怪的是,我在Google上找不到任何有關此漏洞的任何內容

某些技術/軟背景:

  • VPS
  • 1xCentOS 5/1xDebian(均爲64)
  • 的Plesk面板訴10.4.4

我如果有人能夠證實他們確實遇到了這個問題/攻擊,並且可能採取了某種解決方案來防止攻擊者 - 他最終可能會猜到登錄名,但他還沒有得到。 。

升級到v 11現在是免談 - VPS供應商說,他不能這樣做呢,我不能移動項目到其他VPS或提前&問候至少不會這麼快

謝謝, 亞當

回答

0

大約一年前已有big buzz about Plesk security,但Plesk 10.4一直被報告爲安全。

對於以純文本格式存儲密碼的系統,通過SQL查詢檢索密碼是正常的。由於查詢看起來不像SQL注入,它很可能是Plesk本身的一項活動,但是活動確實可以由攻擊者發起。

攻擊者並不需要在Plesk中有任何特殊的非安全腳本來嘗試字典登錄。他們可以隨時登錄您的登錄頁面,並嘗試字典登錄/密碼的不同組合,直至匹配。我想可能存在從不同系統中獲得的登錄/密碼對池。由於人們經常會重複使用登錄名和密碼 - 如果嘗試使用多臺服務器,攻擊者就有機會獲得這個機會也許你的服務器是他們正在掃描的1000個其中的一個。

如果您真的被掃描了,您應該會在MySQL日誌中看到很多這些查詢,並且您應該看到多次嘗試訪問訪問日誌中的控制面板。爲了防止這種情況發生,您需要通過防火牆(或通過訪問限制)來阻止對您的Plesk的訪問,除了您的可信IP列表。