Luigi Auriemma

This has been around forever, I thought I might share the concept.

Very easy really... While connecting to a source engine game, as soon as you've got 2 loading bars it seems to work.
You send a command to the server that requires your entity to be present.
Any command that would require the creation of a TraceRay for example.
The server tries to create a trace from your entity(null pointer), which doesn't exist yet, and dies.

I was wondering if you could code something that would create a connection long enough to send a command that would cause this. It could be done much faster than you would be kicked for having an invalid steamID.

if the problem is only making the connection longer you could test something for delaying the outgoing packets (a sendto hooker or a customized udp proxy and so on), only an idea

My question mainly was, have you ever tried to write a fake players application for source engine games. If it worked well or not, it would connect long enough to send the command that would create the seg fault probably.

personally I have never touched a source-based game so I don't know if it's enough to add one or more custom parameters to hlfill or what.
have you already check if hlfill is compatible with the source dedicated server?
do you have a sniffed session containing the first packets exchanged by your real client (for example hl2) with a server?

Here is a pcap file of the first 10 packets while connecting to a counter-strike source server (69.90.135.112:27015).

thx soma, it looks like the protocol has been redesigned completely.

the second packet of the client uses an unknown compression, then I see the usage of bzip2 in one of the server's packet but it's not much clear.
seems that I'm forced to download the dedicated server (which is free) for understanding something more... mah.

anyway would be interesting to check if that q0000000 packet is only a query or something more (maybe used for occupying a resource or a slot), in the meantime I download the server if someone wants to make a quick test which his own server: udpsz -l 10 -C ffffffff71303030303030303030303030303000 127.0.0.1 27015 -1

I tested it on a server, It DOES NOT crash it but it stops people from joining , it makes the server say <server not repsonding> but inside the game the game server is running fine.


So I guess it is like a invisible DoS. As it only stops people from joining.(at least in my test)

here I have downloaded the dedicated server but it has no effect, it only stops the packets from the same IP address.
you can test it using your ethernet interface for the test (like 192.168.0.1) and then joining on 127.0.0.1.

anyway in the previous post I forgot the -S option (different source ports) which is useful in these types of tests (although probably useless in this case).

Yea if you send too much traffic from one IP the server will temporarily block it out (for maybe 15 seconds). I always notice this when I try to join a game server that is full, but I keep hitting "join game" anyway to try and get the next available slot. It will eventually stop refreshing the player count, scores, etc.. and just say "not responding" for about 15 seconds. And this is probably just to block DoS attempts and/or fake players in general.

I have attached some additional pcaps if they could be of any use. They are for Team Fortress 2 this time, which also uses the source engine. One is a query packet, the other is just the connection to a server (first 20 packets). I will also do some testing with spoofing to see if the first packet reserves a player slot or not.

edit: tested with random spoofed ip/source addresses, but it still doesn't reserve a slot. it appears the slot is reserved further along in the connection. also, i know the actual spoofing was working because i tested it on bf2 right before that, and it worked.

Okay, I've captured the packets that are sent when I used source's threaded scripting to connect & send the console command that causes the server crash.

At the end of this log the server was no longer responding and I had stopped trying to connect to the server by hitting the cancel button.

Here's a log of what the server's console said when I connected.

very good, it works and I have figured the format of the join packet and that of the other packet (it uses bitstrings).
now I'm building some code to learn better the protocol and maybe testing this vulnerability.

tested source server version:
P.S.: do you know who is the original author who found this bug?

An exploit similar to this originated in Garry's Mod using it's client sided lua scripting. I think I may be the first person to adapt it to other source engine games, by using a not very well known method of scripting in source.

By the way, I forgot to mention that those packets I sniffed were from a server running Counter-Strike Source.

P.S. : I'll try and find the old thread on facepunch(Garrysmod forums)

Okay, it looks like the first record of it was a player in Garry's Mod named, Chrisaster; who went around mass crashing servers.
Although the exploit was soon figured out and patched, it still remains using other methods. I don't know of ANY instances of this even occurring outside of Garry's Mod besides what I've discovered myself.

in attachment there is a plugin for proxocket which substituites the first packet of the source client with a custom one built at runtime containing the npc_speakall command which causes the problem.
there are two notes:
- I have not tested it (I don't have the client)
- I have written it on the fly during the writing of a test code for the bug (so with also the reversing of the protocol done on the fly exactly in this moment)

how to test:
- download proxocket: http://aluigi.org/mytoolz.htm#proxocket
- put the ws2_32.dll file located in the zip inside the folder of hl2 or css (where is located the main executable of the game)
- put the myproxocket.dll file attached to this post in the same folder
- join your test server

if it works I'm sure that some people could find it useful because it can be easily modified to send any custom command and because allows to set any desired cvar.
well, hope it helps.

Wow, it works perfectly. I'll try it with some other source games.

Works in CS:S. Doesn't look like it wants to work in TF2.
I don't have hl2mp/hl2dm

My results were similar: works in CS:S and HL2:DM, but not TF2. I don't know much about the source engine, and different 'versions' it has, but I do know that TF2 uses or does something that is at least slightly different from CS:S and HL2:DM. Dont get me wrong, they all are source games, but there are many things in TF2 that don't exist in earlier games (like the server console command sv_allow_voice_from_file), or things that are done slightly different.

I'm not sure how to explain it because I don't know what's actually different, but it's like they added stuff to the game/engine ...but it only exists in TF2. Maybe a slight tweak would be needed to get it working in TF2.

That's why I was wondering if this could be created to run outside of the game environment.

EDIT:


Now that I think about it, the server crashes far before you even submit your STEAM_ID it's very unlikely that VAC is even aware that you attempted to connect.

Yea I would definitely think an out of game PoC is possible. After watching the loading bars, it's merely 2-3 bars in before it stops responding (pretty much right away). Even if a valid steam account was required it would still be possible, but would just require further reverse engineering.

I'm sure it's possible, but It's not something that I could do on my own. :P

the only obstacle at the moment is the sending of a valid steam key which is something checked only on the server (so without packets sent to steam).

I guess I will take a look at it now at least to understand how this mechanism works although I guess it's similar to what happens with demonware where each server has a special unique key that the client retrieves when connects to the steam network or similar (it's only a hypotheis, I repeat that I have not verified this thing yet).

but isn't possible to disable VAC on the client during the test of the bug?
because are involved only 3 packets:
- the request of joining the server
- the packet with nickname, key and cookie
- the packet built by my code
so no VAC stuff involved

You're asking if you can disable VAC on your source server? That's easy, I would add -insecure to the command line of your srcds.

no no, I mean if you can disable it on the client.
something like cl_pb_disable for disabling punkbuster on the clients of the games which use it

I don't think you can disable VAC on the game client unfortunately.

well, if the hooking solution could be a problem for the tests due to VAC, the following solution will avoid any problem at all.

it's a plugin for sudppipe so the client connects to the proxy which modifies the packet and so sudppipe can be launched on the same machine or on a virtual machine or even another pc.

how to use:
- download sudppipe: http://aluigi.org/mytoolz.htm#sudppipe
- get the attached dll and put it in the same folder of sudppipe
- launch: sudppipe -l source_sendcmd_sudp.dll SERVER 27015 1234
- connect your client to 127.0.0.1:1234 (or if sudppipe is on the virtual machine specify its IP address)

oh, the reasons why the PoC doesn't work with TF2 are that:
- the first packet of this game is fdffffff and not 1
- it's compressed apparently with a lzss algorithm (although none of the lzss implementations I have here has given a good output).

anyway now I do a quick test to verify if it's simply enough to add 0xfffffffd in the original PoC for forcing the substituition of the compressed packet with the rebuilt one used in the PoC.
you can test it by yourself recompiling the code or placing a 0xfd at offset 0x863 of myproxocket.dll

Just tried placing 0xFD at offset 0x863 but TF2 still connects just fine.

The command that we're using might not work for TF2, although there are many others.

This one is one of the easier ones to patch. All you have to do is hook all commands and check if the person is in game (i.e., entity is created).

In SourceMod this is a simple two line code.


http://forums.alliedmods.net/showthread.php?t=72354