LuaJIT trickery

In this blog-post I will bring together two cool things: ELF DSO injection into runtime processes and LuaJIT. Lua itself is a very nice scripting language and LuaJIT integrates a very decent FFI module which contains a cdecl parser and other interesting things. I do not need the speedup of LuaJIT over Lua so much, but the C-binding and -inter-operability is "awesome".

I wrote my first ELF injection tools >20y ago, so my actual injectso project needed some polishing first to work with current distros at all. Not only did the ld.so impl and glibc pathnames change, CPUs also feature new extensions like SSE2 and compilers make use of it for string and memory related functions like memset(). The drawback in this particular case was that SSE2 instructions add 16byte alignment requirements for the address operands (in this case indirectly the stack) which made injectso fail on distros that make use of it. Now that was fixed and injectso runs on most glibc based distros again, it was time to add LuaJIT support to allow loading of Lua scripts into "foreign" processes in order to do similar things that you know from frida: accessing memory locations, hooking functions, dumping parameters etc. but with much less bloat.

Here is how it would look in Lua:

It was necessary to add peek/poke primitives to LuaJIT as well as a trap mechanism for functions in order to hook/unhook functions and dump their parameters or otherwise access memory at this point. Changing of function parameters on entry is not yet supported, but would be easy.

When you hook a python interpreter with this script, it would look like this:

Is that cool? Running Lua code when Python calls into a C function to do some things. Some fun that AI assisted coding will never give you. You can try out yourself here.

QUIC trickery

Its probably lesser known that OpenSSL in their recent 3.5.0 Beta version has added full support (client and server side) for TLS over QUIC.

RFC9001 runs the TLS messages - including handshake and anything - on top of the QUIC transport layer. This is somewhat exciting, as it means that - if you already have an OpenSSL infra - you can get QUIC support with relatively little effort into your app. So I went ahead and added QUIC support for crash. As roaming/mobility is not yet supported with OpenSSL's QUIC impl, so it is neither supported in crash. For roaming and suspend/resume you still use DTLS. But SOCKSing your connections through GfW with QUIC is working.

As a funny side-note, as the QUIC support within OpenSSL is pretty new, it would not have been possible to use AI coding agents to add support for it, as they could not have learnt about it yet. This kind of model-rot has implications about malware development and forensics which I am not yet digging into here.

Whats the benefits and drawbacks of using QUIC in general and where is the fun ahead?

QUIC itself effectively was designed for HTTP/3 - as a replacement for HTTP/1 and HTTP/2 over TCP. It runs on top of UDP and has its own ordering, reliability and security layer. Unlike DTLS, which does not offer reliability beyond the handshake.

One of the drawbacks for me is, that it requires a minimum MSS of 1200, which means that QUIC is not a tunneling-friendly protocol, since it requires a lot more effort to tunnel it across links with a lesser MTU, e.g. DNS or reduced NTP (Tier1 networks sometimes limit NTP pkt sizes). But of course you can tunnel other protos across QUIC.

So, whats good about QUIC? It adds new attack surfaces from many sides: Implementation wise with many new software stacks that could potentially contain bugs as well as from protocol side since its not using TCP and therefore it is easier to spoof and confuse monitoring systems and firewalls. This brings me to the point that QUIC is an exfiltration-friendly protocol. As there basically is no notion of [IP:port] endpoint pairs but IPs and ports can be floating. It is much harder, if not impossible, to detect or supress UL/DL of large amounts of data between networks. As there is no network-level connection as with TCP, there is no connection that could be resetted and blocking only works for that particular [IP:port] pair, which is a moving target. Whats more, as QUIC does not require OS/Kernel support, it would be possible by malware to carry free-standing implementations and run it on the most ancient systems, if it just speaks UDP.

I will not dig further in the pro's and con's of QUIC and TLS-over-QUIC, since the nifty details should be reserved for paying customers. :)

New bridge protocol trickery

The Network Time Protocol in its newest version (NTP4) allows to add extension fields beyond their standard header.

So we are going to shamelessly use it for our own profit, which means I am integrating NTP4 into fraud-bridge to have another protocol at hand when someone is blocking traffic.

Some tests in Germany showed that large providers block NTP packets larger than 256 bytes (presumably "DoS protection"?), so I made the MSS option configurable in fraud-bridge so that the TCP stack is sending segments small enough to fit. It still allows for good enough performance to tunnel web-sessions and messengers.

AI 0day trickery

This month I declared Month of AI framework bugs, and here are the 0days that came around. I analyzed the two most common AI frameworks, PyTorch, (with TorchVision) and TensorFlow which are mostly Python with C++ at the lower level (for serving trained models or deploying the actual training to GPUs via CUDA libs). Both frameworks were/are actively developed and backed by Big Tech, which results in certain company repos being hardcoded in the Python code as trusted, among other artefacts.

For classical security - i.e. keeping your infra safe from intruders - you can basically divide the attack surface in two parts.

1. Server-side to get RCE on the deployed servers or somehow get a shell by the prompt or REST/gRPC interfaces.

2. Client-side to get RCE on either developer machines or also on the deployed instance at the server, but by other means than the REST/gRPC interface.

I skipped the Pickle/Deserialization surface this time, as this is a known breaking point being addressed already (although not with great results). All results of my research can be found in my tensor-pwn repo.

The actual results:

* File overwrite in all Python's core tar extractor module can lead to  RCE by overwriting either ~/.bashrc or Python code in the .local cache.

* When obtaining datasets for training and/or deployment on the server, the fetched tar archives will be extracted and the previous issue manifests. This is bad enough for https:// URLs already, as its known that relying on CA-bundle is not sufficient to prevent RCE attacks. But ...

* ... some frameworks replace https:// URLs by http:// on failure, so that the archives will eventually be fetched in plain-text and can be replaced on the network-path even by attackers who are not capable of infecting HTTPS sessions (this is far easier than it sounds). This leads to unauthenticated RCE when deploying torchvision-based models. Note, that the training data fetch and extract (read: overwrite/RCE) often happens automatically when the class of the model is instanciated and there is no manual download necessary. Therefore this resembles more of a 0click RCE. Some training data downloaders contain MD5 hashsum-"protection" but this is not the case for the Kinetic model thats shown in the screenshot below. MD5 is considered broken anyways, so downloaders that rely on it are eventually subject to bespoken RCE conditions too.

* RCE and LPE opportunities when downloading and executing scripts when developers handle with the `cuda.memory` module.

So, whatever preference you might have you can choose which bug you like most and give it the best chances for owning AI deployments in your pen-tests. 

Enjoy the repo!

More censorship trickery

I updated some of my git repos. crash can now be used with Disguise Filters to serve an innocent redirect webpage when certain secrets are not passed beforehand so nobody except you will ever see that there is a shell server inside, even if they observe the SNIs that are in use. I also updated the docu on how you setup WA proxies with it since this changed in newer versions of the app.

Then there is an entirely new PoC repo to tunnel traffic through passkey servers. Thx to the ppl that tested it with me. Check it out, its fancy new Perl code!

Easterbug trickery

 Happy Easteregg searching.

rustup client sides trickery

I tried to understand some things about the rust build/eco system and were surprised how easy it is to pwn. Wonder whether its the same for golang.

crash + psc 37c3 release

crash and psc now build and run on Windoze systems. psc contains a new feature that lets you bounce binary data back and forth through your local pty to a e.g. remote netcat, dd or other utilities so you can fwd SSH connections directly through your terminal or up/download binary data without any remote agent.

Roaming trickery

I added support for roaming and suspend/resume to crash. Now you can change your IP, VPN, physlayer, NAT, VM-routing etc. at runtime and stay connected to your remote shell. You may also suspend the session to a ticket and resume it from a different laptop from the other side of the globe while keeping your shell.

Privacy side note: As always, this implies that you know what you are doing when using VPNs. Disrupted VPN routing may leak your IP address regardless of roaming but with roaming enabled you wouldn't immediately notice as the session just continues. However, to reveal the IP a single leaked packet suffices.

It is now also possible to build and run crash and psc on Windows, including all the nice features.

More crash + psc trickery

I reworked the local address binding and connecting part of my anti censorship tools crash and psc, so it is now possible to use SOCKS5 client side connects by using -x (similar to curl) and to let the SOCKS5 proxy resolve DNS names (-N) in order to allow browsing with chrome (but check README).

You can also check out @fullspectrumdev's blog writeups on pentest use-cases and cross-compilation.

Interestingly, OpenSSH now also supports traffic blinding, which is included in crash since years.

New 7350 0day trickery (cybah cybah)

 

Manjaro seems to be quite popular distro, according to distrowatch. LPE can be found here.

More tunneling trickery

In order to properly proxy messenger apps from censored networks to outside, I added the -X switch to crash and documented on how you would configure your setup within the contrib folder.

It is already field-tested in certain countries. Nevertheless, if you have deeper knowledge on censorship equipement or extra tips for better connectivity and can battle test the setups, just let me know.

Tunneling trickery

 

I re-polished a 10y old project that is one of the most complete tunneling solutions available for ICMP, ICMPv6, DNS over IP and DNS over IPv6 when it comes to setting up connectivity in restrictive environments. I added some fixes so it now properly also works behind NAT.

DTLS trickery

Probably the last post in 2022.

I fixed SOCKS5 handling in psc and crash so that it is now possible to use it with curl and IPv6. Also added DTLS (read: TLS over UDP) support for crash in order to make it possible to use anti censorship SOCKS proxies in countries that block outgoing TCP connections such as in Iran (see previous post).

When I read about LibreSSL having QUIC support, I tried to use this, but their bold announcement was a spoiler. They only "support" the QUIC handshake to obtain keying materials by means of TLS integration. I wouldn't really call this "QUIC support", although I love LibreSSL much more than OpenSSL (due to their permanent API changes). As DTLS has only reliability for its handshake, I had to add my own TCP-style data flow mechanisms to handle packet loss and re-orders. OpenSSL also wants to add QUIC support, so lets see in a couple of years how far this goes (hopefully with full proto and API support and not just the handshake) to finally have a usable QUIC lib.

Crash also switched from TLS v1.2 to v1.3 being mandatory, i.e. it is not proto compatible to the 2.x versions anymore. As soon as DTLS v1.3 will be widely deployed, it will also switch to DTLS v1.3. Due to all these new features and compat things the crash-3 versions are dubbed experimental (although working stable).

Wish you a nice rest of 2022 and a Guten Rutsch for 2023!

SNI trickery

We at c->skills know how the Hase läuft and therefore made a writeup on SNI probing and blocking.

Parallel find trickery

Since a parallel version of nftw() already existed inside my greppin project, it was only little effort to add a parallel find: spot

New commits trickery

 I commited some changes to some of my gh projects:

psc is now using an embedded AES and SHA-512 implementation, in order for easier builds for embedded systems w/o proper SDK support. E.g. it is now super easy to have Android binaries built with it, w/o messing with BoringSSL builds. It also contains a base64 en/decoder on the remote side callable via pscr -E or pscr -D for convenience. Last not least, you can script psc sessions via pscsh. Something similar you propably know from screen with shared sessions.

For harddns, my DoH solution - that was one of the first Open Source DoH implementations available at all - I added NXDOMAIN replies for PTR queries, in order to keep up with newer net-utils packages on current distributions which always try to reverse-resolve obtained A records to PTR records. I also updated the shipped default config to remove the PowerDNS DoH servers, as they recently have shutdown this service :(

Anniversary trickery

Some of you probably already noticed in past, but almost exactly one year ago, I founded my own company:

You can find more details about the exact services at our gh landing page. In order to celebrate our 1y, I pushed new commits to our performance flagship greppin. It is now basically lock-free and runs faster than ripgrep.

Thanks to our clients who made this possible! If things go well as before, I will also alloc() a merchandise budget, so you may ask me for free tee-shirts at the conferences.

OpenSSL 3.0.0 API trickery

 

I refactored opmsg for the new OpenSSL 3.0.0 API and put it into the openssl3-dev branch. Master branch is still the main development branch and both branches produce 1:1 identical output of messages, so one can cross-over test them. Over the long run it is probably necessary to switch to OpenSSL 3.0, but the downside is that it will lose compatibility with the LibreSSL API.

On the plus side, I learned a lot of the inner workings of OpenSSL while refactoring my own code. Including misleading man pages.That will definitely give me an adavantage for the next crypto project code review. :)

Wish you a nice pre-xmas time!

DevOps trickery

I released some DevOps research about self-replicating code  spreading across gits.