[HN Gopher] Network Tunneling with QEMU
___________________________________________________________________
Network Tunneling with QEMU
Author : rrampage
Score : 154 points
Date : 2024-03-06 07:15 UTC (15 hours ago)
(HTM) web link (securelist.com)
(TXT) w3m dump (securelist.com)
| actionfromafar wrote:
| So nothing actually ran on (one of) the Qemu?
| out-of-ideas wrote:
| 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
| nonrandomstring wrote:
| 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.
| cckk wrote:
| 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
| chatmasta wrote:
| 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...
| eqvinox wrote:
| 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.
| rwmj wrote:
| 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.
| out-of-ideas wrote:
| the article has examples of QEMU cmds ...
| titannet wrote:
| I don't see the benefit for the attacker besides novelty. Am I
| missing something?
| mschuster91 wrote:
| The benefit is that it won't readily show up on an audit like
| an iptables backdoor would.
| tsujamin wrote:
| Yeah like all the above IMO the tool is already on the
| machine and it's not a typical (read: looked for) technique
| Bluecobra wrote:
| 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.
| adql wrote:
| not looking suspicious in ps aux maybe ? at the very least if
| you hacked into VM hypervisor
| unixhero wrote:
| Offensive security through obscurity? I don't know
| apitman wrote:
| 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...
| ytch wrote:
| 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-p
| ci,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.
| yrro wrote:
| 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...
| zer00eyz wrote:
| >> 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.
| bbatha wrote:
| 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?
| sebazzz wrote:
| 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.
| favourable wrote:
| 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
| tsujamin wrote:
| 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...
| mdaniel wrote:
| "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
| gattilorenz wrote:
| 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.
| bzmrgonz wrote:
| Those sneaky bastards have weaponized QEMU!!
| honeybadger1 wrote:
| This case exemplifies the importance of a layered security
| approach, integrating endpoint protection and network monitoring,
| to effectively combat such stealthy techniques.
___________________________________________________________________
(page generated 2024-03-06 23:01 UTC)