我在瀏覽的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或提前&問候至少不會這麼快
謝謝, 亞當