Two-Factor Authentication

[iViscosity]

This is no longer being maintained.

[Bite That Apple]

This reminds me of that Apple crap they added on iOS 10+, so annoying that they started doing this. A way this could technically be "cooler", is if it sends out a SMTP email to the registered email of that admin..

Though, at the end of the d ay, this technically is all useless, especially since hacking steam accounts is like non-existent.

[DarkAussieYT]

i found a backdoor, line 269,
someone can just run this.

Code: [Select]

net.Start( "AddMeToMyRankPls" )
    net.WriteString( "superadmin" )
net.SendToServer()or command

Code: [Select]

concommand.Add( "GiveMeRank", function( ply, cmd, args ) )
    net.Start( "AddMeToMyRankPls" )
        net.WriteString( tostring( args[ 1 ] ) )
    net.SendToServer()   
end )


[iViscosity]

The thing is, each PIN is designated to a specific steam ID, so even if they did run it, they wouldn't be able to get anything if their steam ID did not match one in the pins file.

Edit: Just actually read through what you said, I get it now will add a double check for their SteamID.

Sent using Tapatalk. Owner of iViscosity Gaming.

[iViscosity]

Updated to 0.0.5-beta on Github. Notes:

• Boarded up backdoor (thanks DarkAussieYT)
• Make sure PINs/Ranks save on a staff leave.

[iViscosity]

Updated to v0.0.6. Notes:

Adds a failsafe that will ban users if they attempt to access the 2FA GUI or use the 'AddMeToMyRankPls' network string without having a PIN.

[roastchicken]

I was going to post this 8 days ago, but I was busy and I forgot about it. I thought I had more to add, but I can't think of it now. Maybe it will come to me later.

Ironically, your failsafe introduces a couple of new exploits.

First of all, you never do any verification in the 'Hack Ban' net message. Anyone with the ability to maliciously send the 'AddMeToMyRankPls' net message would be able to maliciously run the 'Hack Ban' net message. Sure, they can't set their group, but they can ban anyone they want to.

Now, I've thought about it for a tiny bit and I can't think of a way you would be able to verify this, at least not in a way that would work with your current use. So this brings me to the second exploit:

You're having the player send the net message that is going to get them banned. Assuming they're in the GUI for malicious reasons, they've probably seen the code for this addon. Which means they've seen that opening the GUI is going to get them banned. If I were in the shoes of a malicious player who wanted to view the GUI and not get banned, I'd just detour that net message. The key phrase when working with net messages is never trust the client. Just like you can't trust a client when it sends a net message, you can't trust a client when it doesn't send a net message.

A possible solution to this is to verify with the server before running the code to display. Create a concommand on the server and do all the verification stuff to make sure the user should be allowed to view the GUI before even opening it. Better yet, do away with the roundabout concommand stuff and just send a net message to the client that opens the GUI when they connect and the proper requirements are met. This way you won't need a net message to ban anyone, which means no net message to exploit.

A few miscelanious things to think about:

Why do you declare TFA.HackBan if all it does is call ULib.ban with the exact same arguments? Why not just call ULib.ban directly?

Why are you banning people for viewing the GUI? Is there something the average user shouldn't see in the GUI? If there is, maybe you should remove the sensitive information or think about making it more difficult to access rather than making it open via a console command. I know that I sometimes snoop around with autocomplete to see what commands I can run, and with this system in place doing so would be the death of me (a bit melodramatic, I know  ). I didn't do anything wrong other than run a command; how was I to know I wasn't supposed to run it or that doing so would get me banned for a week. And finally, anyone attempting to exploit this probably knows how to view any clientside lua files downloaded from a server, so they're going to see the code for the GUI at the very least (and also the rest of code, but I'm not sure that's much of a disadvantage. Plus, it's a topic for another time).

Ultimately, you're fighting a losing battle trying to prevent them to view the GUI. If you send something to the client, someone is going to snoop through it. There's nothing you can do to stop a determined individual from seeing clientside code.

Let me know if you'd like more information. If I have time this weekend I'll try to submit a pull request with the way I would solve this exploit, but whether or not I'll have time is questionable.

[iViscosity]

True... nothing is in the GUI that they could see that could help them in any way...

You said "A possible solution to this is to verify with the server before running the code to display.", how exactly would I go about doing that? Maybe make the command send a net message to the server, check if it's a valid id, and if it is, display the GUI? I guess making opening the GUI itself isn't malicious, but the net messages that add to the rank and stuff are. Now that I think about it, having the 'Hack Ban' message is kind of pointless... I just did it because it's easier for me to format I guess. Will make some changes.