Yiche.com won the CDN Management System in multiple positions

Yiche.com won the CDN Management System in multiple positions

With so many vulnerabilities, I had the illusion that it was a honeypot. The importance of the CDN management system is needless to say.

However, the following content is found in a log file:
 

--2014-05-13 17:30:38--  http://59.151.127.48/SystemOpsPlatform/php/Interface/receiveApplyFeedback.phpConnecting to 59.151.127.48:80... connected.HTTP request sent, awaiting response...   HTTP/1.1 200 OK  Date: Tue, 13 May 2014 09:32:30 GMT  Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.3.10  X-Powered-By: PHP/5.3.10  Content-Length: 1  Keep-Alive: timeout=5, max=100  Connection: Keep-Alive  Content-Type: text/html; charset=utf-8Length: 1 [text/html]Saving to: `/dev/null'     0K                                                       100% 40.7K=0s2014-05-13 17:30:39 (40.7 KB/s) - `/dev/null' saved [1/1]

Let's see what the url is.
 

Wow, cdn background management. However, the account password does not exist, and rsync only obtains url Information. First, scan the port to see if there is any breakthrough. Unfortunately, only 80 is opened and can only be solved from the web end.

Continue to look at the url and find that the php Directory contains a directory that can be listed.
 

All these are PHP files that cannot read the content. It's hard to find a rar compressed package and open it.


 

There are two PHP files in it.
 

 

 

Okay. These two files are not in the website directory. However, the content in the source code still attracts my attention:
 

$sql_validation = "update VersionApplyValidation set Status=$validation_status,ErrorFlag=$error_flag,ErrorMessage='" . $error_msg . "'where GUID = '" . $guid . "' and IP = '" . $ip . "' and InstanceID = $instanceid and ConfigInfoID = $configinfoid";$sql_history = "update InstanceConfigHistory set Status=$history_statuswhere GUID = '" . $guid . "' and InstanceID = $instanceid and ConfigInfoID = $configinfoid";

After several post parameters are not processed, they are merged into the SQL statement. In this way, there is a high possibility of website injection. At the front-end, you only need to log on to the console. First, try to inject it in login.

The username structure is as follows:
 

admin' or '1' ='1'#

 

 

Come in... I have never met this universal password.

Sqlmap can also run
 

A problem found during background Testing
 

Have you found any problems? The cookie contains only the user name, no session .... Does this mean that we don't need a password. Just set the cookie?
 

 

2333333 again.



Now the cave master has a deep doubt about the verification mechanism of this system, and we will go to the login interface to see how it is verified.

Looking at the source code on the login page, we were stunned when we saw this section of js:
 

$ (Document). ready (function () {var username = $. cookie ('cdnops _ user'); if (username! = Null) {window. location. href = "/SystemOpsPlatform/home.html" ;}$ ("# UserName "). val ($. cookie ('cdnops _ remeber_user '); $ ("# ckb_RememberMe "). attr ("checked", $. cookie ('cdnops _ remeber_ckb_status '); $ ("# UserName "). focus () ;}); function LogIn () {if (CheckInput () {// call PHP for Logon verification var username = del_blank ($ ('# UserName '). val (); var pwd = $. md5 ($ ('# password '). val (); $. post ("/SystemOpsPlatform/php/login. php ", {username: username, pwd: pwd, anticache: Math. floor (Math. random () * 1000)}, function (data, state) {if (state = "success") {if (data = "true ") {// write Cookie var cookietime = new Date (); cookietime. setTime (cookietime. getTime () + (60*60*1000*4); // cookie is valid for 4 hours $. cookie ('cdnops _ user', username, {expires: cookietime, path: '/'}); if ($ ("# ckb_RememberMe "). attr ("checked") = true) {$. cookie ('cdnops _ remeber_user ', username, {expires: 7, path:'/'}); $. cookie ('cdnops _ remeber_ckb_status ', true, {expires: 7, path:'/'});} else {$. cookie ('cdnops _ remeber_user ', null, {path:'/'}); $. cookie ('cdnops _ remeber_ckb_status ', null, {path:'/'});} window. location. href = "/SystemOpsPlatform/home.html";} else {$ (". errorMsg "). text (data) ;}}, "text") ;}else {}};

The verification performed on the client means that the user name and password are sent to the server. If the server matches the verification, the return value is "true "; if "true" is received, the user name is written to the cookie and redirected to the background page. In this case, we only need to change response to true to log on to the system. To verify.



In the fiddler command line, enter the command bpafter 59.151.127.48 to set the response breakpoint and submit an incorrect user password. At this moment, an error message is returned.
 

Change to 'true'. Try again.
 

We met again.



Now I have another idea. Since the login verification is done by the client, is the user verification on the background page also on the client.


 

We found such a script on the background page and verified the previous statement that only detected the cookie username. In this way, it is also feasible to kill the js here and construct the script by ourselves, but we will not go into detail in this case.



Verify that this piece has been mined. Can you enter this system in other positions? Of course!

I wanted to get something through the injection, but this system sqlmap ran out Based on Time injection, and there was an error in getting data, and the database account permissions were limited. There is a user management in the background. When I view related files through the column directory, I open the php link for retrieving system account information in the background:
 

 

 

 

In the slot, all accounts and MD5. it's not a strong password. It can be found at google. Of course, this can be obtained without logon.

 

Solution:

Completely retrained from the system architecture