Network Tunneling with QEMU | Hacker News Reader

Network Tunneling with QEMU

securelist.com

187 pointsrrampage27 comments

I've use this method recently. Our VM service is based on libvirt, which doesn't support QEMU socket type interface natively, so I need to add the following to the XML:

  <qemu:commandline>
    <qemu:arg value='-netdev'/>
    <qemu:arg value='socket,id=mynet0,listen=10.6.0.1:12200'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='virtio-net-pci,netdev=mynet0,id=net1,mac=58:a4:c0:a8:bf:51,bus=pci.0,addr=0x3'/>
  </qemu:commandline>

On the other endpoint, a Linux TAP tunnel daemon is responsible for encapsulating packet to the Length-Value data as the article said.

In this way, I can create a L2 tunnel from remote site to the VM, also keep the VM untainted.

After initially being keen on running qemu directly, I've really come to appreciate libvirt, even thought you do have to be willing to peer past all the XML...

>> willing to peer past all the XML

Does xml suck. Meh yea it mostly does. Was it a crappy format for everything. Yes, XML over the wire, not so great.

Would I rather have xml configs than yaml, or json... The more I think about it, yes, I would.

1. The dom sucks in a browser, it's gross when it gets huge. If your config files are THAT large then, we have OTHER problems.

2. Validation. It validates. Not only on a syntax level (is this document complete, does it have a final close tag). You can also run checks against a DTD, an xml schema and XSD(??? its been a while, I think this was a way).

3. XSLT: I have mixed feelings on this, but there was a way to merge, change and transform... IT was powerful and testable, way better than templated config files.

Maybe I am looking at it wrong, maybe this is me having rose colored glasses for an ex. But I sure would like all those features BACK.

All of these exist for json, and since yaml has the same object structure as json these tools can mostly be reused

1. Plain old hash maps and arrays. No special stuff required 2. JSON schema exists and works pretty well 3. JSON path and json patch cover this. Though because json follows a plain object model there just isn’t as much need.

Contrary to xml having clean object structure and not having to worry about using nested data or props makes all of the above easier and require fewer special tools. Additionally in the qemu example you can see problems with xml right away look at this extra “qemu:” structures, yay more stuff to parse. Then the args come in as repeated elements, are those an array or not?

Mostly because it is only partially documented, on a few RedHat pages. This is where GPT shines because it is able to make something better from the incomprehisible mess of RedHat.

Slightly related, I remember reading once of malware that uses a virtual machine running TinyXP[0] to obfuscate itself from the host OS. The footprint of TinyXP is tiny compared to the latest versions of Windows and runs on very little RAM, and gets past reverse engineering ploys which aim to unravel what the malware does.

[0] https://archive.org/details/tiny-xp-rev-11

This reminds me of the Australian National University hack, where the threat actor downloaded and spun up their own XP/Kali VMs on servers they compromised

https://theuniguide.com.au/news/anu-releases-details-of-data...

"tiny" ... "I do not think that word means what you think it does":

  - AllSnap v1.33.2
  - Comodo Internet Security v5.0.163652.1142 (requires reboot)
  - DirectX 9c June 2010 
  - Everything v1.2.1.371
  - Foxit PDF Reader Pro v3.0.1301
  - GetDiz v4.4.0.0
  - HashCheck v2.1.11
  - Prio v1.9.9.2091
  - Visual-C++ Runtimes 2005 and 2008
  - WinRAR v3.91

and even the Archive entry is tagged 691MB

That's software not installed by default but available on the ISO, should you decide to install it. Earlier ISOs of TinyXP were less than 150 Mb in size.

The "MicroXP" variant (also from the same ISO) installs in <10 minutes and takes about 250 Mb if you disable the page file. It can even be reduced a bit more if you know you're not going to use some components (e.g. a browser), I assume.

That's the one. I got them mixed up. Link for it is here: https://archive.org/details/MicroXP-0.82

I don't see the benefit for the attacker besides novelty. Am I missing something?

The benefit is that it won't readily show up on an audit like an iptables backdoor would.

Yeah like all the above IMO the tool is already on the machine and it’s not a typical (read: looked for) technique

The article mentioned that it was used to gained a large company so I’m sure that was a huge benefit for the attacker. A lot of other tunneling mechanisms might have been blocked and easy to overlook QEMU.

not looking suspicious in ps aux maybe ? at the very least if you hacked into VM hypervisor

Offensive security through obscurity? I don't know

Main thing that comes to mind is code signing and executable reputation. Here's my understanding: an unsigned exe on Windows throws up scary warnings to users before it will run, until that specific exe is trusted by enough users and added to some central database. If you signed with a legit EV certificate (at least ~$400/year) it's trusted implicitly and no warnings. If you sign with an OV[0] it will give warnings until the cert is trusted, but you can then use the cert to sign new exes (ie updates to the program).

I just ran `osslsigncode verify qemu-w64-setup-20231224.exe` and it appears it's signed but the 1 year cert expired in December 2023. Still, I would expect that QEMU releases tend to be trusted fairly quickly assuming a decent number of users.

[0]: open source options available for free[1] or ~$50/year[2]. If you get your app on the Microsoft App Store, they'll sign it for you which is also free ($19 lifetime account IIRC).

[1]: https://signpath.org/

[2]: https://shop.certum.eu/data-safety/code-signing-certificates...

So nothing actually ran on (one of) the Qemu?

the company-system had a qemu "client" that opened up a connection to the attacker's IP (1 MB ram, no disk space, just tcp socket); the attackers then used qemu on their own systems, listening to the tcp-connect from the compromised system, in order to establish a tunnel.

securelist.com also states the tunnel made by qemu is not encrypted

AFAICS, other than easy point to point tunnel via twin VM instances the win here was the TCP encapsulation. The investigators had to strip that back using pcap edit, so presumably it wasn't an easy spot for the firewall either.

sorry noob q, but do you mean that the company probably didn't think to search for the unencrypted traffic? I'm not sure if I understand why the encapsulated traffic being unencrypted is "advantageous" for the adversary

I think it's just that most scanning tools aren't trying to unwrap a TCP packet inside a TCP packet, so it bypassed their naive filters. Once a researcher spotted it, it was trivial to unwrap, but automated tooling would just see it as the outer TCP packet with some opaque data inside of it.

I would assume that the attacker's destination IP would show up on some dashboards somewhere though...

The VM itself was presumably idling on a BIOS "no bootable device" prompt. I don't think QEMU has an option to not start the VM at all and just do networking.

You can use -S. There's still a guest but it doesn't start the virtual CPU running. It would make no practical difference for this "use case" though.

the article has examples of QEMU cmds ...

Those sneaky bastards have weaponized QEMU!!

This case exemplifies the importance of a layered security approach, integrating endpoint protection and network monitoring, to effectively combat such stealthy techniques.

Reply on news.ycombinator.com