SSO Ticket exploit

[Rain]

So, the SSO ticket exploit from a while back where they get into staff account with a blank SSO ticket, it's just happened to me on habsay as my staff ID was 1.

I checked the emu to see if it was making sure the SSO wasn't blank and it was;

How was he able to do this?

When i set my SSO ticket to a value while i am online, he got on to an account called 'Hayley'

If it's checking for an empty SSO, and he still got on my account, why is that?
Is there a value he could've entered that's empty in mysql?

 

[Jaden]

He shouldn't be able to run any SQL if you're using prepared statements and binding the SSO variable.

 

[Rain]

He shouldn't be able to run any SQL if you're using prepared statements and binding the SSO variable.

He's not running an SQL, he's just connecting to the client with a blank SSO.
The SSO variable is bound -

You must be registered for see links

 

[Brad]

Not 100% sure if this will work or make a difference with the check in place for an empty string. But maybe try adding SSO.Length > 0

 

[Rain]

Not 100% sure if this will work or make a difference with the check in place for an empty string. But maybe try adding SSO.Length > 0

Cheers. What would be the downside of not clearing the auth ticket when they log in

 

[Jaden]

Cheers. What would be the downside of not clearing the auth ticket when they log in

nothing since you're most likely using prepared statements.

Not 100% sure if this will work or make a difference with the check in place for an empty string. But maybe try adding SSO.Length > 0

there is no difference

 

[Brad]

nothing since you're most likely using prepared statements.

there is no difference

Aye, but the issue should be fixed with what's there.

I'll take a better look at it tomorrow, pre tired right now.

 

[Jaden]

You can try modifying your SQL so your statement is like..

WHERE sso = @sso NOT "" --not blank

 

[Rain]

You can try modifying your SQL so your statement is like..

WHERE sso = @sso NOT "" --not blank

?

You must be registered for see links

?

 

[Zodiak]

?

You must be registered for see links

?

if (string.IsNullOrEmpty(SSO) || string.IsNullOrWhiteSpace(SSO) || SSO.Length < 15)
return;

No need for the extra code, because it shouldn't run anyway if the above if statement is triggered.

 

[Rain]

if (string.IsNullOrEmpty(SSO) || string.IsNullOrWhiteSpace(SSO) || SSO.Length < 15)
return;

No need for the extra code, because it shouldn't run anyway if the above if statement is triggered.

i feel as though there's a string that represents null or empty in an SQL query, that they could have used.

 

[Zodiak]

i feel as though there's a string that represents null or empty in an SQL query, that they could have used.

Prepared statement should fix that?

 

[Jaden]

i feel as though there's a string that represents null or empty in an SQL query, that they could have used.

Are you sure the exploiter did not secure the account before the exploit was patched?

 

[Rain]

Are you sure the exploiter did not secure the account before the exploit was patched?

Havn't had issues since i stopped clearing SSO tickets on login

 

[Damien]

Just separate the SSO tickets from the user table and delete them once the user has authenticated. I find is assuming how I got slated when I posted my version a while back, but yet I've seen people have nothing but trouble with this version.

Also if you're keeping the SSO's you're giving them the same opportunities to log onto random accounts (not as much, but still insecure).

The proper way it should be done is separate with a timeout, so if a connection isn't made within the given time. The SSO is destroyed automatically.

 

[Rain]

Just separate the SSO tickets from the user table and delete them once the user has authenticated. I find is assuming how I got slated when I posted my version a while back, but yet I've seen people have nothing but trouble with this version.

Also if you're keeping the SSO's you're giving them the same opportunities to log onto random accounts (not as much, but still insecure).

The proper way it should be done is separate with a timeout, so if a connection isn't made within the given time. The SSO is destroyed automatically.

tru, will look into it