Date</th>	Event</th></tr></thead>
2019-06-25</td>	First message to an employee from Liberty Global</td></tr>
2019-06-26</td>	First response as well as transfer of my issue to a superior</td></tr>
2019-06-28</td>	Submission of a written report to Liberty Global. Proposed date for full-disclosure is +90 days</td></tr>
2019-06-28</td>	Submission of the CVE ID request (CVE-2019-13025)</td></tr>
2019-09-22</td>	I noticed an automatic firmware update (`CH7465LG-NCIP-6.12.18.25-2p6-NOSH</code>) on my device, which patches the vulnerability</td></tr>`
2019-09-25</td>	Originally planned date for full-disclosure (90-day deadline) of the vulnerabilities</td></tr>
2019-10-01</td>	Publication of this article and the GitHub Repository. Contacted CVE team in order to release the CVE entry to the public</td></tr>
2019-10-02</td>	German news portals report about the found vulnerabilities ^{3</a></sup> and publish a statement by Unitymedia, stating that 95% of the affected 2.2 million devices deployed by Unitymedia have been patched</td></tr> </tbody></table> References</a></h1> ^1</sup>Gezielter Austausch bei 300.000 Kunden: Connect Box ersetzt technisch veraltete Router</a></p> </div> ^2</sup>libhttp_plugin.so</a></p> </div> ^3</sup> Unitymedia: Fatale Sicherheitslücke in Millionen Routern</a></p> </div> VAC3 Modules Dumper Linux 2018-09-17T18:00:00+01:00 I just released a VAC3 module dumper for Linux on Github</a> (with pre-compiled binary).</p> Additionally I uploaded the six modules</a> I dumped at the end of August in case anyone wants to do some analysis himself. Furthermore I'm planing to post some more in-depth analysis of the respective modules soon.</p> While I want to start a new post series on this blog soon, I am not quite sure yet about which topic. Currently I am thinking about building an VAC3 emulation system or working on a self-made Linux anti-cheat to demonstrate and explain some well-known (and not so well-known) techniques used in modern anti-cheats.</p> Path of Exile Bot 2018-07-09T18:00:00+01:00 I uploaded a little showcase video to show the current state of my Path of Exile bot named Pathil</strong>.</p> Current Features:</strong></p> Dynamic Pathfinding</li> Basic Combat Routine (spells, buffs, flasks, reviving)</li> Basic Loot Filter (only loots specified items)</li> Automatic Map Runs (runs new maps from the hideout in a loop)</li> User Interface In-game (basic settings in different windows rendered in-game)</li> Fully Background Compatible (does not need an active window at all)</li> </ul> Hopefully I will be able to finish the basic functionality left as for example customized combat routines and improved inventory and looting soon.</p> The video shows the work of one week which included a complete rewrite from the first version which was implemented in Rust and fully external (out of process).</p> </iframe></div> Since I wanted to support background botting and multiple game clients on one machine as well was some other features I decided to go internal and rewrite the bot in C++.</p> Currently I am working on reversing the new anti cheat deployed in late June. It was deployed to finally fight against PoEHud and other tools.</p> It is not always active but can be armed at any point. Usually when a new league or season starts. The anti cheat modules get streamed and manually map during runtime to prevent static analysis of the anti cheat (if you only have the game client to your hands).</p>}

marcel.re

Rust UEFI Runtime Driver

2020-10-08T22:00:00+01:00

Introduction</a></h1>
In the last few months I've started working with Rust in the UEFI world, in order to write a hypervisor as a UEFI runtime driver for educational purposes.</p>
At first, I evaluated uefi-rs</a> as a wrapper between UEFI interfaces and Rust. According to the developers, its main goal is to "to provide safe and performant wrappers for UEFI interfaces, and allow developers to write idiomatic Rust code". Philipp Oppermann</a>, the author of "Writing an OS in Rust"</a>, uses the library for example to create an experimental x86 UEFI bootloader</a>.</p>
Unfortunately, I've quickly ran into the first problems, since the library in its current state does not cover all the interfaces and functionality needed for my purposes. As a result, I've decided to use r-efi</a>, which provides all protocol constants and definitions of the UEFI Reference Specification</a> without any safe wrappers implemented in Rust.</p>

Features</a></h1>
Today I've written down my insights over the past months and created a GitHub repository</a>, which serves as a foundation for UEFI runtime driver development in Rust. Its equipped with various useful features for developing and prototyping and aims to help getting started.</p>

Before the release of nightly 2020–07–15</code>, using cargo xbuild</code></a> was the recommended way to cross compile the sysroot crates core</code>, compiler_builtins</code> and alloc</code> for custom targets. Fortunately, Cargo by now supports build-std</code></a> and as a result is able to cross compile the sysroot without any extra tools. Furthermore, we can remove rlibc</code></a> as a dependency, since nightly 2020-09-30</code> allows to use compiler_builtins</code> mem</code> feature to provide the implementations of memset</code>, memcpy</code>, etc.</p>

We can activate both of these features by creating a .cargo/config.toml</code></a> in our project root file containing:</p>

[</span>build</span>]
</span>target = "x86_64-unknown-uefi"
</span>rustflags = ["-Z", "pre-link-args=/subsystem:efi_runtime_driver"]
</span>
</span>[</span>unstable</span>]
</span>build-std = ["core", "compiler_builtins", "alloc"]
</span>build-std-features = ["compiler-builtins-mem"]
</span></code></pre>
Furthermore, we set our build target to be x86_64-unknown-uefi</code> and provide an additional argument to the linker, in order to create a UEFI runtime driver instead of an UEFI application.</p>
Serial port logging</a></h2>
Using UEFIs Simple Text Output Protocol</code> for logging is only viable for UEFI applications which operate before ExitBootServices()</code> is called. Since we want our logger to work even after the boot services are not safe to call anymore, the custom logger</a> writes to a serial port (COM1, 0x3F8</code>) instead. As a result, we are able to use our logging macros such as debug!</code> and info!</code> even after the operating system is loaded.</p>
Setup</a></h1>
Building</a></h2>
Compiling our template project is as simple as building any other Rust project.</p>
$ cargo build
</span>Finished dev [unoptimized + debuginfo] target(s) in 0.02s
</span>$ file target/x86_64-unknown-uefi/debug/rust-efi-runtime-driver.efi 
</span>target/x86_64-unknown-uefi/debug/rust-efi-runtime-driver.efi: PE32+ executable (EFI runtime driver) x86-64, for MS Windows
</span></code></pre>
As intended, we've successfully built a PE32+ executable</code> containing a EFI runtime driver</code>.</p>
VMware</a></h2>
With the driver ready to go, we will update the VMware configuration of our guest machine to allow for proper debugging.</p>

    
        VMware Workstation</strong> is required for UEFI support.</p>

    </div>

To do so, we append the following to our .vmx</code> configuration file.</p>
debugStub</span>.</span>listen</span>.</span>guest64 </span>= </span>"TRUE"
</span>debugStub</span>.</span>listen</span>.</span>guest64</span>.</span>remote </span>= </span>"TRUE"
</span>debugStub</span>.</span>hideBreakpoints </span>= </span>"1"
</span></code></pre>
The GDB-based guest debug stub while now await connections (local and remote) on port 8864.</p>
In the repository, a create_disk.sh</code></a> script is provided to automatically create a .vmdk</code> (Virtual Machine Disk) file containing the driver, which can then be mounted by the guest machine.</p>
To now load the runtime driver, we select Power On to firmware</code>, boot into an EFI shell and use the load</code> command to load the driver.</p>
Beware:</strong> If you built the driver as a debug build, loading the driver will freeze the machine until a debugger connects and breaks the waiting loop.</p>
Windows</a></h2>
Receiving serial port output for logging is incredibly useful, especially during the runtime of the operating system. In order to receive the serial port output on Windows after ntoskrnl</code> has been initialized, we need to activate the Debug mode</code> on our test machine by executing msconfig</code> as shown below and rebooting the machine afterwards.</p>
</p>
GDB & CLion</a></h2>
By today's standards, debugging with GDB on the command line is not as convenient as source-level debuggers in IDEs such as Visual Studio or CLion. Luckily, we can make use of CLions GDB Remote Debug</a> feature to debug our runtime driver and therefore be able to use advanced debugging features such as conditional breakpoints, Rust language support and built-in visualizers (strings, vectors and other standard types).</p>
</p>
By creating a new debug configuration we can specify a remote target, containing the address of the host machine as well as the previously mentioned port 8864.</p>
An additional step is needed to enable GDB to load the debug symbols of our runtime driver. At this point, the driver is already loaded in memory and stuck in the debug waiting loop. While GDB can load the debug symbols of our PE file out-of-the-box, it lacks information on where the respective sections are mapped in memory. The following code snippet is part of the load-symbols.py</code></a> script I've provided in the repository.</p>

    

        Make sure to install pefile</strong> within the Python environment used by GDB.</p>

    </div>

argv </span>= </span>gdb</span>.</span>string_to_argv</span>(args)
</span>
</span># Parse arguments.
</span>address </span>= </span>get_number</span>(argv[</span>0</span>])
</span>path </span>= </span>get_string</span>(argv[</span>1</span>])
</span>print</span>(</span>f</span>'</span>{path}</span>: </span>{address:02x}</span>'</span>)
</span>
</span># Find the base address of the PE.
</span>base_address </span>= </span>address </span>& </span>0xfffffffffffff000
</span>while </span>get_number</span>(</span>'*(unsigned int *)</span>{}</span>'</span>.</span>format</span>(base_address)) </span>!= </span>pe_magic:
</span>    base_address </span>-= </span>0x1000
</span>
</span># Print base address.
</span>print</span>(</span>f</span>'Base (</span>{path}</span>): </span>{base_address:02x}</span>'</span>)
</span>
</span># Parse PE.
</span>sections </span>= </span>{}
</span>pe </span>= </span>pefile</span>.</span>PE</span>(path)
</span>for </span>section </span>in </span>pe</span>.</span>sections:
</span>    name </span>= </span>section</span>.</span>Name</span>.</span>decode</span>()</span>.</span>rstrip</span>(</span>'</span>\x00</span>'</span>)
</span>    address </span>= </span>section</span>.</span>VirtualAddress </span>+ </span>base_address
</span>    </span>if </span>name[</span>0</span>] </span>!= </span>'/'</span>:
</span>        </span>print</span>(</span>f</span>'Section: </span>{name}</span>: </span>{address:02x}</span>'</span>)
</span>        sections[name] </span>= </span>address
</span>
</span># Remove previous symbol file.
</span>try</span>:
</span>    gdb</span>.</span>execute</span>(</span>'remove-symbol-file </span>{path}</span>'</span>.</span>format</span>(path</span>=</span>path))
</span>except </span>Exception </span>as </span>_error:
</span>    </span>pass
</span>
</span># Add the symbol file.
</span>gdb</span>.</span>execute</span>(</span>'add-symbol-file </span>{path} {textaddr}</span> -s </span>{sections}</span>'</span>.</span>format</span>(
</span>    path</span>=</span>path</span>, </span>textaddr</span>=</span>sections[</span>'.text'</span>]</span>,
</span>    sections</span>=</span>' -s '</span>.</span>join</span>(
</span>        </span>' '</span>.</span>join</span>((name</span>, </span>str</span>(address))) </span>for </span>name</span>, </span>address </span>in </span>sections</span>.</span>items</span>() </span>if </span>name </span>!= </span>'.text'</span>)
</span>))
</span></code></pre>
The approach is to take the current rip</code> and iterate backwards until we find the PE file signature at the beginning of our driver. This works, since the rip</code> currently points to the instructions of our waiting loop within the .text</code> section. We parse the PE binary to recover the virtual addresses of the sections and add them to the previously calculated base address. The created mapping is then fed back into GDB to make use of the contained debugging information and allow for source-level debugging.</p>
We create a custom GDB command called dbg</code> to combine the needed commands into a single command. By storing the command in a file named .gdbinit</code> at the root folder of the project, GDB is able to automatically import our new command during startup.</p>
define</span> dbg
</span>  source </span>./</span>load</span>-</span>symbols</span>.</span>py
</span>  file
</span>  load-symbols $rip </span>"./target/x86_64-unknown-uefi/debug/rust-efi-runtime-driver.efi"
</span>  set </span>GDB_ATTACHED </span>= </span>1
</span>end
</span></code></pre>
Notice how the command sets the the variable GDB_ATTACHED</code> to 1</code> after loading the symbols, in order to break the waiting loop the driver is currently stuck in.</p>
Debugger Showcase</a></h1>
</iframe></div>
Future Work</a></h1>
In the next weeks, I plan to finally polish my UEFI runtime driver + user mode library, which allows to read and write virtual and physical memory as well as execute kernel code from user mode. Eventually, I also hope to finish and release my UEFI hypervisor together with a user mode library comprising various Virtual Machine Introspection (VMI) related features. Both projects showcase various UEFI-related characteristics and features such as memory allocations in combination with Rust or UEFIs multi-processor protocol.</p>

Connect Box CH7465LG: Unauthenticated Remote Code Execution (CVE-2019-13025) 2019-10-01T18:00:00+01:00 Introduction</a></h1> The following work was conducted on the Connect Box CH7465LG</code> with the firmware version CH7465LG-NCIP-6.12.18.24-5p8-NOSH</code> running Linux 3.12.14</code> on a Intel XScale CPU (armv6b). The device was supplied to me in February 2019 by Unitymedia</a> as the default cable modem for new customers.</p> According to Unitymedia itself there are currently about 1.8 million customers using the Connect Box alone in Germany. 1</a></sup> Since the Connect Box is also used by other ISPs such as KabelBW, UPC Austria and more the number of affected customers is even higher.</p> The device and firmware itself is produced by Compal</a> and only branded by the different ISPs.</p> It is important to note, that the vulnerability listed below need access to the web interface of the cable modem. This can be achieved in two different ways:</p> Being a client in the local network of the device.</li> Accessing the web interface over the Internet via the remote maintenance feature.</li> </ol> Shodan</strong> is a search engine that lets you find specific types of devices, such as routers, which are connected to the internet by using a variety of filters.</p> </div> A quick search of devices with open ports revealing the web interface with the help of Shodan</a> shows several thousand affected devices. Not to mention that every single device is vulnerable if local access is available.</p> Remote Code Execution</a></h1> The web interfaces offers ping</code> and traceroute</code> functions to test the network connection to other hosts. Although the web interface is protected by a password, most of the APIs do not require any form of authentication.</p> Vulnerability</a></h2> Internally the implementation on both functions builds upon calling the ping</code> and traceroute</code> binaries on the shell provided by the operating system. The input parameters are only verified on the client-side in the web interface but not correctly escaped or verified within API endpoint itself. Therefore the endpoint is vulnerable to command injection by manipulating the POST parameters sent to the endpoint by including an escape sequence as well as the desired command(s).</p> Implementation</a></h1> The ping and traceroute function both can be found in libhttp_plugin.so</code>2</a></sup> named cbn_http_xml_start_pin</code> and cbn_http_xml_start_tracert</code>. I've attached the shared library for readers which may be interested in having a closer look on their own.</p> Furthermore I'm planning to release a more detailed post about the whole process of:</p> Finding the first vulnerability while examining the web interface.</li> Gaining remote code execution.</li> Dumping the firmware of the device.</li> Further analysis of the firmware and the discovery of more vulnerabilities.</li> </ol> Nevertheless, I would like to point out (even if it should be obvious) that it is essential to always escape and verify the user input arguments when executing commands on the shell. It's also recommended to avoid invoking the shell in general by using exec()</code> instead of system()</code>.</p> Proof of Concept</a></h1> A PoC to sent arbitrary commands to be executed on the shell of the device can be found in my GitHub repository</a>. By doing so we can for example start a telnet server on the device and connect to the provided debug CLI.</p> {{< asciinema "dKJ2wyz3PTgwU3IYIfDPmuXVi" >}}</p> Timeline</a></h1> Date</th> Event</th></tr></thead> 2019-06-25</td> First message to an employee from Liberty Global</td></tr> 2019-06-26</td> First response as well as transfer of my issue to a superior</td></tr> 2019-06-28</td> Submission of a written report to Liberty Global. Proposed date for full-disclosure is +90 days</td></tr> 2019-06-28</td> Submission of the CVE ID request (CVE-2019-13025)</td></tr> 2019-09-22</td> I noticed an automatic firmware update (CH7465LG-NCIP-6.12.18.25-2p6-NOSH</code>) on my device, which patches the vulnerability</td></tr> 2019-09-25</td> Originally planned date for full-disclosure (90-day deadline) of the vulnerabilities</td></tr> 2019-10-01</td> Publication of this article and the GitHub Repository. Contacted CVE team in order to release the CVE entry to the public</td></tr> 2019-10-02</td> German news portals report about the found vulnerabilities ^{3</a></sup> and publish a statement by Unitymedia, stating that 95% of the affected 2.2 million devices deployed by Unitymedia have been patched</td></tr> </tbody></table> References</a></h1> ^1</sup>Gezielter Austausch bei 300.000 Kunden: Connect Box ersetzt technisch veraltete Router</a></p> </div> ^2</sup>libhttp_plugin.so</a></p> </div> ^3</sup> Unitymedia: Fatale Sicherheitslücke in Millionen Routern</a></p> </div> VAC3 Modules Dumper Linux 2018-09-17T18:00:00+01:00 I just released a VAC3 module dumper for Linux on Github</a> (with pre-compiled binary).</p> Additionally I uploaded the six modules</a> I dumped at the end of August in case anyone wants to do some analysis himself. Furthermore I'm planing to post some more in-depth analysis of the respective modules soon.</p> While I want to start a new post series on this blog soon, I am not quite sure yet about which topic. Currently I am thinking about building an VAC3 emulation system or working on a self-made Linux anti-cheat to demonstrate and explain some well-known (and not so well-known) techniques used in modern anti-cheats.</p> Path of Exile Bot 2018-07-09T18:00:00+01:00 I uploaded a little showcase video to show the current state of my Path of Exile bot named Pathil</strong>.</p> Current Features:</strong></p> Dynamic Pathfinding</li> Basic Combat Routine (spells, buffs, flasks, reviving)</li> Basic Loot Filter (only loots specified items)</li> Automatic Map Runs (runs new maps from the hideout in a loop)</li> User Interface In-game (basic settings in different windows rendered in-game)</li> Fully Background Compatible (does not need an active window at all)</li> </ul> Hopefully I will be able to finish the basic functionality left as for example customized combat routines and improved inventory and looting soon.</p> The video shows the work of one week which included a complete rewrite from the first version which was implemented in Rust and fully external (out of process).</p> </iframe></div> Since I wanted to support background botting and multiple game clients on one machine as well was some other features I decided to go internal and rewrite the bot in C++.</p> Currently I am working on reversing the new anti cheat deployed in late June. It was deployed to finally fight against PoEHud and other tools.</p> It is not always active but can be armed at any point. Usually when a new league or season starts. The anti cheat modules get streamed and manually map during runtime to prevent static analysis of the anti cheat (if you only have the game client to your hands).</p>}

marcel.re

Rust UEFI Runtime Driver

VMware</a></h2> With the driver ready to go, we will update the VMware configuration of our guest machine to allow for proper debugging.</p> VMware Workstation</strong> is required for UEFI support.</p> </div> To do so, we append the following to our .vmx</code> configuration file.</p>

Connect Box CH7465LG: Unauthenticated Remote Code Execution (CVE-2019-13025)

VAC3 Modules Dumper Linux

Path of Exile Bot