Making Custom Elevators for R&C1 Multiplayer

For the multiplayer mod I've made for Ratchet & Clank (2002), I wanted to recreate the behavior that the vanilla in-game elevators have. Basically, I wanted to have a platform the player can stand on they move with. The game doesn't move the player with mobys (Insomniac's name for "game objects") without extra work and configuration. It took me far too long to figure out how to properly configure mobys as elevators.

All mobys use the same 0x100-byte struct that the game engine reads to place and give behavior to mobys. This struct has info about which model type it is, flags, color, state, collision data, and much more. Importantly, it also has a pointer to the moby's update function, which is called every game tick to allow it to control its behavior.

Setting the right mode bit

The moby instance struct also has a field for flags, or mode_bits as Insomniac calls it. mode_bits decides a bunch of different properties for mobys like

Interactive Guide to Buffer Overflow exploitation

A Buffer Overflow is a bug class in a program typically written in a memory unsafe language like C or C++. Buffer Overflow bugs from user-input can often allow someone to overwrite some data in memory they weren't supposed to. Before we dive into how to exploit Buffer Overflow bugs, we will do a quick introduction to Assembly.

Assembly is a language that describes raw machine code. Assembly is the lowest level programming language, and the processor executes exactly what you write in Assembly. This means that we can also directly translate machine code bits and bytes back to Assembly without losing any information. Languages like C, C++, Rust, etc. on the other hand translate what you write to machine code, which we can translate back to Assembly, but we can't translate it back to exactly what the code was in C, C++ or Rust, only approximations based on the Assembly. For all intents and purposes, Assembly is the

DACL Permissions Overwrite Vulnerability in Check Point VPN

A couple of months ago, I found a DACL permissions overwrite vulnerability in the Check Point Endpoint Security VPN client. This vulnerability allows any user on a Windows system to set permissions for any file to Full Control for the Authenticated Users security group (the only limitation being that the SYSTEM user needs to have access to edit permissions on the file, so some system files owned by TrustedInstaller can not be overwritten).

The VPN client has two counterparts, a Windows service running as SYSTEM and a userland client running as current user. For this vulnerability, we don't really need to interact with the serivce, other than restarting it. However, I did look at the communication between the user client and the service, and it's an interesting type of custom-looking RPC protocol that is probably interesting to look at.

While I did find this vulnerability individually, I was not the first to report it to

Privilege Escalation vulnerability in CrashPlan

Recently, I enountered a vulnerability in the CrashPlan clients for Windows, Mac (and possibly Linux, but I didn't bother to test it there) that allows for privilege escalation.

The vulnerability is in the handling of Proxy Auto-Config (PAC) files. PAC-files are used for automatic proxy-configuration and is widely deployed in various software and operating systems. In short, PAC-files are JavaScript-files with a function whose return-value dictates the URL to the relevant proxy server. In CrashPlan, the JavaScript runtime, Rhino, allow for bridging JavaScript into Java, or "Scripting Java" as Mozilla calls it. Ultimately, this means that if we introduce a line of code into this file with new java.lang.ProcessBuilder["(java.lang.String[])"](["cmd.exe"], ["/c \"SomeCommand\""]).start(); we can execute arbitrary commands in the context of CrashPlan's service, which is running as SYSTEM.

Exploitation

This vulnerability can be exploited

Debugging Windows services

Prerequisites

• Windbg
• A burning wish to debug a service at startup-time instead of just attaching to the process after it has started.

This guide is mainly for Windows 10.

Same or very similar procedure works for pretty much all major versions (at least from XP and up) of Windows, but the gflags application might look a bit different for some versions of Windows.

Set global flags

Open gflags.exe at C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe

Go to the tab Image file, type the process name of the service you'd like to debug.

Set "debugger" to whichever debugger you'd like, windbg in my case: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe -server tcp:port=5005 -c "g"

Which will make windbg the parent process of the image you specified when it launch. Windbg in this case spawns in the so-called "session 0" which is locked down and can't be interacted with in the latest versions of Windows 10 (there is of course software

Interactive Beginner's Guide to ROP

Return-oriented Programming (ROP) is a binary exploitation technique that leverages existing code in the binary in order to execute attacker code.

To follow this post it might be useful to have at least a little understanding of x86 assembly.

As most modern computers running on Intel chips are 64-bit, this guide is also using 64-bits. Note however, that because of limitations of JavaScript and the developer of the emulator, registers can not actually hold 64-bit values and they will be rounded down when too large. If anybody wants to help me with that (without BigInt), that would be really helpful. Emulator repository: http://github.com/bordplate/js86

Note that the interactive demos will not work in Edge and Internet Explorer because the demos use JavaScript-functionality not present in those browsers. Browsers that have been tested to work are Firefox, Safari, Opera and Google Chrome.

Note on endianness: I have chosen to not address

Securing the Lua interpreter in PHP

I'm contemplating adding simple Lua-scripting to an export-module in software I'm developing, but it needs to be secure. The Lua module for PHP seems to assume the Lua code is coming from a trusted space, not user input. I explored a bunch of different ways to properly secure it and I believe I landed on a satisfying solution in the end.

Running Lua without any modifications

Purely running Lua from user input in PHP executes it as the currently running process, no surprise there.

1
2

$lua = new Lua();
$lua->eval($userinput);

The above code would easily grant anyone shell access to the server as they could easily use the builtin Lua command/package os.execute(). As this blog post points out, the PHP Lua module loads all available Lua libraries in lua.c at line 765 (at the time of writing). You could fork and recompile the library loading only the libraries you'd want, but that's not really something normal people would want to spend time on.

Usin

Temporarily mitigating SQL injection by custom Python proxy

We recently had a 3rd party come in and create a service for us that was tied up to a small set of different systems. The system had a public facing part for our customers and it quickly became a crucial system to keep online. During a quick check of their work it was discovered that a critical SQL injection bug had found a place in there.

Keeping a system running with SQL injection that could possibly lead to an OS shell (Windows) is not a question. The bug needed to be fixed ASAP, and we could not take down the system for several hours while we waited for the 3rd party to respond.

The system's backend was running on ASP, our customers would interact with only one page and they could upload a picture and enter some personal details (name, birthday, address, etc.). We needed something quickly that would somehow mitigate the SQL injection.

Besides taking down the service and editing the source code, what are our options?

Escalating privileges on Windows through services

An easy and powerful way to gain SYSTEM-privileges can be to abuse a service in Windows. We all know they run as the user SYSTEM, so gaining code execution in any one of them can gain you a "root shell" on the system.

Sometimes, a developer or some intern who creates the installer package for some software, will accidentally give Everyone full access to the service executable. Overwrite the file with your own payload (reverse shell or whatever). This means that even if you just have access to a low privileged user on the system, this is a low hanging fruit.

Going through each of the permissions on the system one-by-one is tiresome and just not something one has the privilege of having the time for on a compromised system, so I created a VBScript for that:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colListOfServices = objWMIService.ExecQuery ("Select * from Win32_Service ")
Set objShell = CreateObject("Wscript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
For Each objService in colListOfServices
        Dim path, x
        path = objService.PathName
        x = Instr(path,"-")
        If x Then path = Left(path,x-1)
        x = Instr(path,"/")
        If x Then path = Left(path,x-1)
        path = Trim(path)
        wscript.echo path
        objShell.Run "cmd /c icacls """ & objService.PathName & """ >> services.txt", 0, True
Next

What is Return-Oriented Programming?

For a long time I've been casually wondering about how ROP really works and what it is. I understand buffer overflows and shellcode in stacks and heaps, but a simple explanation to ROP was apparently hard to find. I was reading about something else when it hit me how this concept works, but further reading was still a bit hazy to me.

While it is a powerful way to avoid Data Execution Prevention (when CPU will not execute code in heap and stack), it a really simple concept.

In simple terms, a buffer overflow on the stack introduces a return address and then some shellcode the return address should goes to. Data Execution Prevention (DEP) prevents the shellcode from being executable in the stack (and the heap), so that is a no-go in modern computing. When doing ROP, instead of introducing shellcode, you just introduce a whole bunch of return addresses pointing near the bottom of subroutines already established in the program.

Instead of creating