ULX exploit and/or bug.

[JamminR]

In theory- I imagine that the same Source exploit is being used. Now however, because the exploiter can no longer spoof the admin themselves, they now have to use/run a lua command on the admin rejoining that either 1) Show's ULX's key given to them or 2) just has the admin run the command for them.

Remember, the original exploit was never about ULX, it was direct access to exploitees client console through a Source exploit.
Admin mods (ULX included) just made it easier for them just like it makes it easier for you to administer a server.

Are you still using Voice in Steam and Source games? If so, by all means disable it and see if it stops.

[Megiddo]

Unfortunately, we discovered that the exploit is now working in such a way that it can't be blocked by Lua. The protection we added before was aimed at a very particular way that we assumed the exploit might work, and it's clear it doesn't work that way anymore.

I still recommend following the commands I gave a few pages back. You can't stop the exploiters, but perhaps you can minimize damage. Another note of concern is that I don't think that the attacker needs to be connected to a server in order to attack it.

[ceribik]

In theory- I imagine that the same Source exploit is being used. Now however, because the exploiter can no longer spoof the admin themselves, they now have to use/run a lua command on the admin rejoining that either 1) Show's ULX's key given to them or 2) just has the admin run the command for them.

Yeah i figured it was much the same


Remember, the original exploit was never about ULX, it was direct access to exploitees client console through a Source exploit.
Admin mods (ULX included) just made it easier for them just like it makes it easier for you to administer a server.

Exactly. Although it's not really an exploit per se, i'd call it more of an attack vector.


Are you still using Voice in Steam and Source games? If so, by all means disable it and see if it stops.

We originally stopped using voice in game, but after we discovered it was done via steam friends, we stopped bothering. We did figure out a temporary solution; that is to not reconnect after timing out, but yeah.

Unfortunately, we discovered that the exploit is now working in such a way that it can't be blocked by Lua. The protection we added before was aimed at a very particular way that we assumed the exploit might work, and it's clear it doesn't work that way anymore.
Can you explain exactly how it's working (either on here or privately?). We have a pro coder on our team, and we might be able to block it outside of gmod/lua depending on how it works.


I still recommend following the commands I gave a few pages back. You can't stop the exploiters, but perhaps you can minimize damage. Another note of concern is that I don't think that the attacker needs to be connected to a server in order to attack it.

We might end up having to do that. What we discovered was, that attacker actually connects with a (legit) steam attack (i.e. we have their real steam id), although they can still spoof/proxy their connecting ip address.

Thanks

[krooks]

When this exploit first came out we had 2 people try it on us, but, we have connections to a steam mod, and after showing them logs, those people were vac banned. Since then, we have seen _many_ people vac banned for this exploit, and the fact that we have not had another attack since, tells me the word has gotten out within that community.

Hacks cost you (or in their case, their parents) MONEY! LOL

[AzuiSleet]

The nonce method was good except for the fact that attackers can execute Lua on the client. A more foolproof method is to have an after the fact challenge, such that:

A client will send a command to the server normally like "my admin command kick xyz." The server will buffer the command and challenge the client (with something random), and the client must send the challenge back to the server without storing it. This way it doesn't matter what the attacker can run on the client because they would have to get the challenge after their command has been injected. Because of the way the attack works (desynchronization of the net channel), the client could never get the challenge regardless of anything they do to the lua state.

[Megiddo]

I'm not ignoring this thread, but I'm going to take some time to consult my network security books before making further comments. I've got three tests this week though, so I'll likely get to it this weekend. Thanks for the input, though!

[JamminR]

Meh, I'll bite.
First, Welcome, and nice to see you here AzuiSleet.

Second, It's a good idea in theory. It would prevent abuse of ULX, if not all other client capable console commands (lua or not)
As discussed (overly perhaps) in the FP thread, it would stop the general 'script kiddy' type folks who simply run the simple stuff, and are unfamiliar or have patience for higher console learning (or lower, as the case may be when it comes to abuse)

I question efficiency though.
Many SVN revisions ago, after the major rewrite of ULib in the rev 70+ era, we tried using datastream for all of our commands.
What a mess that was. If the datastream hooks weren't stopped by some lame poorly written other mod using them, or Gmod's implementation itself placing them out of order or some such, then it was delayed many seconds due to various mods and other net server traffic flooding the channel.
(See http://forums.ulyssesmod.net/index.php/topic,4432.msg18093.html)

We want ULX commands to seem instantaneous.
Figuring the most reliable while fastest method of challenge dialogue may be more challenging than it seems.

[Stickly Man!]

I agree that, assuming there is a noticeable performance difference (especially on laggy servers), a delay can be pretty annoying. I did come up with a (somewhat complex) idea that may help with the problem:

If you think about it statistically, I'm guessing that well over 95% of commands that will go through this challenge process will pass. What would happen if we were to buffer the command like AzuiSleet mentions, but instead of waiting for the response from the client, go ahead and execute the command immediately? Then, after a specified amount of time, if no response from the client is received, "undo" the command.

This method obviously would require specific parameters on a per-command basis, like so:

For commands with opposites (ragdoll, jail, ignite), this causes no issues, and a fake command against another player would result in being ragdolled only for a second (or however long the wait time is).

For commands that change a state of a player (hp, armor, teleport, bring), we'd need to save the old parameters in order to properly "undo" the command.

For non-opposite commands (slap, whip, maul, asay, csay, thetime), perhaps they could be executed immediately, then a warning message can be displayed to all once ULX doesn't receive the challenge?

For non-important commands (in terms of it not really making a large difference on if it's executed a few seconds late), we can just leave these alone to wait for the challenge. (vote, votekick, voteban, votemap)

And for the most important commands (rcon, luarun, any user management commands), these should all wait for the challenge response. (User management commands could probably be undone, but it's better not to risk it).



Or, you know, we could just enable the challenge on only the most important of commands, then ignore it on the rest.
Handling logging on a method like this may be tricky, too

[JamminR]

Remember our motto Stickly Man... strive for simplicity.
(I know, you've already shot that out of the water with all the gui code, but, at least it counterbalances with making it simple for prefer-a-gui users)

[AzuiSleet]

When you say "dialogue" it seems to me that you are suggesting a prompt for the user. The requirement for the challenge I'm suggesting doesn't have to be a confirmation dialog, just a simple usermessage challenge/concommand response. I don't really see the delay being much worse than RTT (500ms if your ping is 250ms), which isn't that big of an issue if say you want to kick someone, since you spent the last 5 seconds clicking or typing the kick button/command.

[JamminR]

Sorry, no, didn't mean user prompted. I understood your idea (and like it).
Just meant the back-end communication dialog between server and client.

My concern still lies in that buffer time, especially if there is already some sort of response lag for any reason on the server or client.
I send command now, along with our current 'key' method, server sees it and goes 'OK'.
Even if delayed in any way to the server, as long as it reaches the server, the server will execute it as soon as it can.

With the challenge method you suggest, it triples (or more perhaps in some instances) that time, whatever it may be.
If delayed for any reason, that delay gets tripled too.

I'm not disagreeing with safety of the idea. It secures the command structure of ULX.
This additional time difference, and the additional buffer code/timeout complexity may outweigh the need for it.
At least, to be included within ULX by default.

Now that I reach that final statement, this sounds like a good module release idea for ULib itself, if not ULX.
ULib has a few functions that could halt and check for additional authorization before allowing commands to continue.

[AzuiSleet]

With the challenge method you suggest, it triples (or more perhaps in some instances) that time, whatever it may be.
If delayed for any reason, that delay gets tripled too.

I don't see how it's triple the normal time, since you have to wait for the command to be transmitted, and then wait for feedback, whether it's the user being kicked or an "OK" message, that's the RTT. The second trip for the challenge is the RTT again, which means there's two trips, so it would only take twice as long plus any network congestion.

[JamminR]

Maybe I'm confused.
Here's how I see it;
1) Original command to server - server buffers,
2) sends random as of that moment challenge back to client.
3) (Real) client back to server - yes, I'm real, see my (server sent key)...perform buffered command now please.
There are 3 trips there, all of which can be affected by various lag (network both ways, server i/o, client i/o)
Or am I totally getting your original idea incorrect? (I'm quite sure this is possible )

[AzuiSleet]

You're missing the return trip, in the normal case:

1) ->server, string command
2) ->client, feedback

In the case of the challenge we're still using that return trip, it's just not the feedback:

1) ->server, string command
2) ->client, challenge
3) ->server, challenge response
4) ->client, feedback

It only takes twice as long to get the same feedback, since it's not useful to measure the time it takes to go to the other end, but rather the time it takes for the other end to respond. I interpreted your concern as "response lag" not the actual time it executes on the server, which would be 3x as long.

Even in a case like a 250ms ping, that's 500ms to get a response, which is still within reason, and a delay of 375ms to execute the command. If the delay really is unacceptable, I suppose it wouldn't be unreasonable to make it an opt-in feature, but that does go against the principle of "security should be opt-out."

[iSnipeu]

Having a interesting chat with my host today, he send me a link to a facepunch thread, i will post the link & test below

http://www.facepunch.com/threads/1066753-Very-serious-exploit-hack-currently.

So, before you read this and say it's impossible there are several server owners who will have already experienced this.

How does the hack work:

All I know:
Attacker users steam to get the IP (Steam voice chat)
Attacker can now run any command on him. Logs will show the command came from the victims IP.
I was told, although I have no idea if reliable, that the attacker & victim have to be in the same server. Now this makes me think the attack could be a multitude of things. A friend or 2 believes it could be some form of packet injection, however this seems unlikely.

What does the hack involve:
Well, basically there are a few levels of the hack that someone is selling. Level 1 just gives you superadmin(ULX only), the highest level will allow the user to run any console command on that user.

The attacker just needs to obtain a victims IP and then they are allowed to run any console command on the victim, and I do mean any even the ones safeguarded by Valve. To make things worse, the person selling these tools also provides a simple DoS to knock offline the person there attacking.

Example:
(George = superadmin/owner)
Attacker1 makes George give him superadmin
Attacker1 attacks George and knocks his internet offline for a few hours.

Well, just read through this and I sound like a complete moron. But alas I'm to tired, I'm only posting this here to see who else has been victim of this & to bring it to Garry's attention.