You want to pass TCP traffic from one computer to another, but there’s a doggone firewall in the way. Can they both see a shared file? Turns out, that’s all you need. Well, that and some software from [fiddyschmitt].
If you think about it, it makes sense. Unix treats most things as a file, so it is pretty easy to listen on a local TCP port and dump the data into a shared file. The other side reads the file and dumps the same data to the desired TCP port on its side. Another file handles data in the other direction. Of course, the details are a bit more than that, but that’s the basic idea.
Performance isn’t going to be wonderful, and the files keep growing until the program detects that they are bigger than 10 megabytes. When that happens, the program purges the file.
The code is written in C# and there are binaries for Windows and Linux on the release page. The examples show using shared files via Windows share and RDP, but we imagine any sort of filesystem that both computers can see would work. Having your traffic stuffed into a shared file is probably not great for security but, you know, you are already jumping a firewall, so…
Of course, no firewall can beat an air gap. Unless you can control the fans or an LED.
I can see this used by the bad guy’s.
Possibly, but sounds like it could be easily monitored.
They are already using netcat/socat with a fifo to do the same thing.
This is hilarious, love to see some creative work arounds.
yuck. i used to use novell netware filesharing this way because i didn’t understand any of the other ways to pass messages across a network back then. made a stupid interactive chat system that worked by creating a bunch of temporary files on the shared volume.
really, lots of things still work this way…some component uses ftp or smb as if it was a remote procedure call API and uploads a file with its request, and then a cron job periodically services / cleans up all the requests sitting in the ftp incoming directory.
*plan 9 has entered the chat*
I realise this is for fun, and I can appreciate that, but given that it effectively tunnels TCP over TCP (in the form of an SMB connection), won’t it run into the same problem that affects any attempt to do that?
When the “real” TCP connection loses a packet, it will retransmit it, but the tunneled connection (which doesn’t know it’s being tunneled) will also retransmit, and you can get feedback that jams the connection, which is notoriously a problem for TCP-based VPNs.
Or maybe the deep buffer / high latency of this system avoids that problem? Perhaps I should find time to read through the github.
The tunneled connection won’t know it lost a package, since it’s been retransmitted and received already by the time it would be missed… Is my guess at least. Since the Real tcp connection ends in a file write, all bits of the next write must be present before the write, and this be able to happen (and read/retransmit) before its considered lost.
I’d guess it’s a matter of configuration. Or possibly there was never any packages lost during testing?
(I didn’t read it either ;)
Ugh. Was just at the CIO Peer Forum in Calgary AB last week and the main security nightmare discussion was about citizen developers using new AI tools to leverage protocols like this that they don’t understand. Some major, major players turning from attempting to prevent shadow IT to managing it resignedly. This existing on the ‘net is all it takes to feed someone’s LLM and make it past customs into citizen development country.
I mean cool idea though, just hard being both a hacker (in all senses of the word) AND a CIO…
Best way to fight shadow IT is to provide managed IT that actually gets work done instead of getting in the way of work.
Figuratively, you can provide an unbreakable cordless, lightweight, ergonomic nailgun hand-tailored to fit the expressed needs and desires of an individual, but they’ll still turn around and hammer nails with a rock as soon as the training is over. People won’t use a solution just because it’s beneficial, they have to want it.
Maybe IT could listen to what people want?
What part of that did I not say?
Use named pipes. Same principle without the hassles of real files.
Why not simply use the scp command, in Linux and Windows?