Improper consideration of DZ upgrade/DX Conversion Program leads to exploitation of user legacy information by hackers

(Glossary: DZ = Discuz !; DX = Discuz! X; UC = UCenter; PW = phpwind)
 
As we all know, DZ <= 6.0, PW <= 8.7 of user passwords are simple md5, which is prone to brute force cracking after database theft. Therefore, kangsheng added salt when developing UC to prevent this problem.
However, improper processing of the original information in the DZ upgrade and DX conversion programs may cause Simple md5 information to be left in some tables. The result is that the historical information will be exploited by hackers once the website is broken or dragged.
I did not think it was a problem, but the following link shows that it is likely to have been circulating in the black industry:
Http://weibo.com/1933769763/eDKax2duHJa (see forwarding and comments)
 
@ Hxai11 submitted a Vulnerability (http://www.wooyun.org/bugs/wooyun-2010-04146) in this part of the details of the description of the error, to discuss it, or independently submitted a good.
We hope that the upgrade script can be properly handled before the programs that rewrite code DX 2.5 and PW 9 are released.
(1) DZ <= 6.0 of user information is stored in the cdb_members table, and its password field is simple md5;
After DZ> = 6.1, the password field is used only as the cookie login credential verification. Each time the user changes the password, A New Login credential verification with no password is generated;
The actual password information exists in the UCenter cdb_uc_members table and has been salt;
(2) However, when upgrading to DZ (such as DZ 7.0) that requires UC, the upgrade script for importing cdb_members to UCenter cdb_uc_members only focuses on adding salt to the password of cdb_uc_members, the password of cdb_members is not harmless;
The result is that after the upgrade, if the old user does not change the password, the legacy md5 will remain in cdb_members.
(3) what's more serious is that the DX conversion script moves the cdb_members password of DZ without any further harmless treatment. As a result, the problem of DZ extends to DX.
(4) This issue mainly affects old users who have not changed their passwords since the upgrade to UC. This group of users generally contributed a lot to the Forum in the early days, so they will be puzzled when problems arise ......
Vulnerability proof: The uid is 1 and the password is 123 (md5: 202cb962ac59075b964b07152d234b70. Upgrade steps:
Discuz! 6.0-> Discuz! 7.0-> Discuz! 7.2-> Discuz! X2
 
(1) install DZ 6.
 
Mysql> use test_dz6
Database changed
Mysql> SELECT 'Password' FROM 'cdb _ members 'WHERE 'uid' = '1 ';
+ ---------------------------------- +
| Password |
+ ---------------------------------- +
| 202cb962ac59075b964b07152d234b70 |
+ ---------------------------------- +
1 row in set (0.00 sec)
 
(2) upgrade DZ 6 to DZ 7
In this case, UC is automatically installed based on the upgrade script.
However, in the subsequent DZ cdb_members-> UC cdb_uc_members process, the password of DZ cdb_members is not harmless. Only the password before UC cdb_uc_members is salt and inserted:
 
120321 11:46:00 30 Connect root @ localhost on
......
30 Init DB test_dz6
31 Init DB test_dz6
30 Query select count (*) FROM cdb_members
30 Query SELECT * FROM cdb_members LIMIT 0, 5000
31 Query SELECT uid, salt, password FROM 'test _ dz6 '. cdb_uc_members WHERE username = 'admin'
31 Query INSERT LOW_PRIORITY INTO 'test _ dz6 '. cdb_uc_members SET uid = '1', username = 'admin', password = '0379ba3a48962bac0faefbf0f7274604', secques = '',
Email = 'name @ domain.com ', regip = 'den den', regdate = '000000', salt = '000000'
31 Query INSERT LOW_PRIORITY INTO 'test _ dz6 '. cdb_uc_memberfields SET uid = '1'
30 Quit
31 Quit
 
Result:
 
Mysql> SELECT 'Password' FROM 'cdb _ members 'WHERE 'uid' = '1 ';
+ ---------------------------------- +
| Password |
+ ---------------------------------- +
| 202cb962ac59075b964b07152d234b70 |
+ ---------------------------------- +
1 row in set (0.00 sec)
 
Mysql> SELECT 'Password', 'salt' FROM 'cdb _ uc_members 'WHERE 'uid' = '1 ';
+ ---------------------------------- + -------- +
| Password | salt |
+ ---------------------------------- + -------- +
| 0127ba3a48962bac0faefbf0f7274604 | 882693 |
+ ---------------------------------- + -------- +
1 row in set (0.00 sec)
 
(3) upgrade DZ 7 to DZ 7.2
No changes
 
(4) install DX 2 www.2cto.com
 
 
234 Query replace into pre_common_member (uid, username, password, adminid, groupid, email, regdate) VALUES ('1', 'admin', '9503092fc99906246aa57a7b189c982c ', '1 ', '1', 'admin @ admin.com ', '123 ')
 
At this time, the uid is 1 and a harmless treatment has been performed:
 
Mysql> SELECT 'Password' FROM 'pre _ common_member 'WHERE 'uid' = '1 ';
+ ---------------------------------- +
| Password |
+ ---------------------------------- +
| 9503092fc99906246aa57a7b189c982c |
+ ---------------------------------- +
1 row in set (0.00 sec)
 
 
(5) DZ 7.2 data is imported to DX 2
During the DZ cdb_members-> DX pre_common_member import, the conversion script returned md5 (123) because the password was not harmless.
 
120321 12:22:40 240 Query ......
240 Query use 'test _ dz6'
......
240 Query use 'test _ dx2utf8'
240 Query TRUNCATE 'test _ dx2utf8'. pre_common_member
240 Query SELECT * FROM 'test _ dz6 '. cdb_members WHERE uid> ''order by uid LIMIT 1000
......
240 Query insert into 'test _ dx2utf8 '. pre_common_member SET 'uid' = '1', 'username' = 'admin', 'Password' = '202cb962ac59075b964b07152d234b70', 'adminid' = '1 ', 'groupid' = '1', 'groupexpiry' = '0', 'extgroupid' = '', 'regdate' = '20170', 'credit' = '0 ', 'email '= 'name @ domain.com', 'timeoffset '= '000000', 'accesssmask' = '0', 'allowadmincp' = '1 ', 'categorysound' = '0'
......
 
 
Mysql> SELECT 'Password' FROM 'pre _ common_member 'WHERE 'uid' = '1 ';
+ ---------------------------------- +
| Password |
+ ---------------------------------- +
| 202cb962ac59075b964b07152d234b70 |
+ ---------------------------------- +
1 row in set (0.00 sec)
Solution:
 
 
Historical problems should be properly solved. Including processing of historical data, especially sensitive information, when creating upgrade scripts.
In this case,
 
 
My previous temporary solutions:
 
UPDATE pre_common_member SET 'Password' = md5 (rand ());
However, there may be a cookie string problem. Due to the time relationship, I did not go into depth ......
 
Author horseluke