Bitcoin Forum
December 11, 2017, 08:02:24 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: vulnerability on SMF forums  (Read 8273 times)
apetersson
Hero Member
*****
Offline Offline

Activity: 666



View Profile
January 25, 2013, 03:27:34 PM
 #1

i have not looked in-depth into this, but this might be relevant:

http://www.reddit.com/r/netsec/comments/178z09/admin_password_reset_in_all_versions_of_simple/
http://raz0r.name/vulnerabilities/simple-machines-forum/
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513022544
Hero Member
*
Offline Offline

Posts: 1513022544

View Profile Personal Message (Offline)

Ignore
1513022544
Reply with quote  #2

1513022544
Report to moderator
1513022544
Hero Member
*
Offline Offline

Posts: 1513022544

View Profile Personal Message (Offline)

Ignore
1513022544
Reply with quote  #2

1513022544
Report to moderator
greyhawk
Hero Member
*****
Offline Offline

Activity: 924


View Profile
January 25, 2013, 03:37:38 PM
 #2

I for one welcome our new overlords.
deepceleron
Legendary
*
Offline Offline

Activity: 1512



View Profile WWW
January 26, 2013, 03:16:53 PM
 #3

Official response: http://www.simplemachines.org/community/index.php?topic=495809.0 - delete the bug report.

Quote
I moved a topic like this before. Removed content and lock. Refrain from posting a topic like this again.

and

Quote
Quote
Quote
Hello Raz0r,

> This time I found a more interesting vulnerability however at Positive Technologies we didn’t manage to raise awareness of SMF developers.
May I ask you when did you send the report?

Raz0r, 26. Январь 2013, 1:57

Hello! We sent it in August 2012
Raize
Donator
Legendary
*
Offline Offline

Activity: 1409


View Profile
January 29, 2013, 06:49:38 AM
 #4

GD it. I just tested this on one of my lower-traffic forums. It is a real exploit. It does require some programming skill to exploit, but it's a very real threat unfortunately. It's actually easier to do on SMF 1.X than 2.X, but it still requires a boatload of custom programming. Basically it comes down to attempting a ton of hex codes.

The faulty code is this:
Code:
if (empty($_POST['code']) || substr($realCode, 0, 10) != substr(md5($_POST['code']), 0, 10))

It should be found in /Sources/Reminder.php, though the line # is going to vary based on mods. Changing it to !== should do the trick, as one of the redditors pointed out.

Just FYI, it's always better to PM theymos with these sorts of things so he can apply custom patches/edits. Making a thread about it does increase the likelihood it will be patched, but it kind of assists anyone wanting to target this forum in particular.

OrganofCorti's Neighbourhood Pool Watch - The most informative website on blockchain health
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2870


View Profile
January 29, 2013, 07:06:59 AM
 #5

inbox informed me of this previously and I fixed it.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2870


View Profile
January 29, 2013, 07:16:59 AM
 #6

I'm sure there are more exploits like this. SMF was not carefully designed. Authentication stuff is spread all over the place.

I found another possible vulnerability a while ago (and fixed it here), though it'd be very difficult to exploit. When the session ID is compared to the one in the database, the comparison ends at the first differing character. So a session ID that is partially correct takes longer to be rejected than one that is entirely incorrect. I was able to measure a noticeable time difference, but the difference is small enough that the attack may be impractical.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
TradeFortress
VIP
Legendary
*
Offline Offline

Activity: 910


View Profile
January 29, 2013, 07:53:43 AM
 #7

I'm sure there are more exploits like this. SMF was not carefully designed. Authentication stuff is spread all over the place.

I found another possible vulnerability a while ago (and fixed it here), though it'd be very difficult to exploit. When the session ID is compared to the one in the database, the comparison ends at the first differing character. So a session ID that is partially correct takes longer to be rejected than one that is entirely incorrect. I was able to measure a noticeable time difference, but the difference is small enough that the attack may be impractical.
Really?

Did the SMF devs loop through every single character and compare them individually?
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2870


View Profile
January 29, 2013, 08:05:59 AM
 #8

Really?

Did the SMF devs loop through every single character and compare them individually?

Not explicitly, but that's what happens when you compare strings normally.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
dree12
Legendary
*
Offline Offline

Activity: 1246



View Profile
January 29, 2013, 02:26:26 PM
 #9

Really?

Did the SMF devs loop through every single character and compare them individually?

Not explicitly, but that's what happens when you compare strings normally.

How would you circumvent this? Perhaps compare the remaining characters anyways, even though it's not computationally optimal? Store a hash of the session id instead of the actual session id?
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2870


View Profile
January 29, 2013, 02:41:10 PM
 #10

How would you circumvent this? Perhaps compare the remaining characters anyways, even though it's not computationally optimal? Store a hash of the session id instead of the actual session id?

Those are both good solutions. The easiest way, which I did, is to hash each side of the comparison before comparing.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
TradeFortress
VIP
Legendary
*
Offline Offline

Activity: 910


View Profile
January 30, 2013, 12:33:53 AM
 #11

Perhaps === in PHP should compare the remaining characters anyways in cause of a failure.
dree12
Legendary
*
Offline Offline

Activity: 1246



View Profile
January 30, 2013, 12:45:40 AM
 #12

Perhaps === in PHP should compare the remaining characters anyways in cause of a failure.

That would be inconsistent in a short-circuited language. If I'm not mistaken, the following in PHP:

Code:
1 && ($var = 1);
if (isset($var)) echo "Set.";
else echo "Unset.";

produces the output:

Code:
Unset.

String comparison should also be similarly short-circuited for consistency's sake.
ldrgn
Member
**
Offline Offline

Activity: 118


View Profile
January 30, 2013, 03:52:46 AM
 #13

How would you circumvent this? Perhaps compare the remaining characters anyways, even though it's not computationally optimal? Store a hash of the session id instead of the actual session id?

This is called a timing attack and the usual way to beat it is to subtract the two hashes and test to see if the result is zero.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!