Right?Īfter a lot of attempts, I couldn’t quite solve this puzzle so I returned to the code and looked towards different directions that would allow me to bypass the frustrating printable characters only limitation so that I’d be able to call much more functions, and also be able to pass pointers and what not as my arguments. Unfortunately.īut looking at the bright side, we can still call certain functions and control the second argument with printable characters. Now that we’ve cleared this up, we can see why it won’t be possible to call system with our command, because demorecord itself is the first argument that is passed, upon this invocation - demorecord->write(data, len) not data. The way that it’s being done is via an implicit this argument. Let’s take a moment to discuss how methods or member functions, are called in C++ in a very abstract way, after all, write is a virtual method of demorecord.Ī method is a function like any other, with the small caveat that it needs to be able to reference the object’s members as well. Well, easy peasy, let’s just call system and our text message is already passed as an argument to the function, so that’s it, we can run commands on the server’s host, right? You guessed it, of course not. Hold on…Is the address of system completely printable? Function | Address in ASCII malloc: p}D _ZTVN10_cxxabiv120_si_class_type_infoE: H]D strstr: `D isxdigit: (`D socket: 0`D _ZSt9terminatev: 8`D recvmsg: accept: H`D strtoul: P`D fwrite_unlocked: X`D strchr: ``D uncompress: h`D _cxa_begin_catch: p`D strspn: x`D perror: aD system: (aD inflateInit2_: 0aD gmtime: 8aD openlog: _cxa_atexit: HaD time: PaD strcpy: XaD _ZdlPv: `aD select: haD _isoc99_sscanf: paD closelog: xaD gethostbyaddr_r: bD vfprintf: (bD fread_unlocked: 0bD shutdown: 8bD tmpfile: putchar: HbD strcmp: PbD strtol: XbD inflateReset: `bD fprintf: hbD tolower: pbD backtrace: xbD strcat: cD setsockopt: (cD remove: 0cD _cxa_guard_acquire: 8cD sqrtf: toupper: HcD frexp: PcD inet_pton: XcD _cxa_pure_virtual: `cD qsort: hcD fwrite: pcD close: xcD That’s why I couldn’t just call functions within the executable itself. Note that I had to limit the search to GOT functions because I needed a memory address that holds a pointer to a function, exactly like the vtable behaves. In order to deal with that, I wrote a script that returns all the GOT functions whose pointers are completely printable. This is pretty problematic because it drastically reduces the leverage of this attack, in effect, allowing us to only pass printable pointers.
Because of the call to filtertext here, it is not possible to send a message with unprintable characters, and the size of the message is limited to 260 bytes. Let’s rewind into the limitations for a second. So, we can both control the function that is called, and even choose an argument to pass it! Neato’.ĭemorecord itself is initialized only once at the start of the game and is of type gzstream : stream I quickly noticed that reading data from the client is done using functions like getstring and getint, etc. So I started going over the various updates that can be sent from the client, for instance, sending a text message or the player’s position on the map. This is the function that, according to the developers, does “server-side processing of updates”, looks like a good place to start. Pretty quickly I came across the process function at server.cpp. Right from the beginning I was looking for the code that takes input from the client and looked for ways to meddle with it, essentially providing unexpected data to the server.
So I opened up the game’s code and started to get familiar with the codebase. Escalating to admin, crashing the server, or writing some hacks (which I did by the way) were not what I was looking for. There’s also the possibilities of client →client, or server →client, but they both tend to be easier as the client is usually written in a more trustful manner.
The goal was clear and straightforward, achieving Remote Code Execution Client →Server.
0 kommentar(er)
