Pushing files around with silly and unusual methods

Pushing files around with silly and unusual methods

Over the holidays, I had a bunch of time on my hands and found myself digging around in old boxes and cupboards, looking for things to clean up. In my travels through all of that junk, I turned up an old VHS cassette with some fun stuff on it, and decided I wanted to bring it onto the computers. More digging turned up an ancient USB capture device and a VCR that still worked.

That capture device no longer works on any of my Macs, but it DID work on the one cheapest-possible-laptop-from-Frys Windows box I keep around for those annoying things which won't work anywhere else. (Yes, even in 2020, there's still stuff that requires Windows to work, even though it's just twiddling files on a USB mass storage device. Uniden, I'm looking at you.)

90 minutes later, I had a 2 GB "m2ts" file hanging out on the disk of this cursed machine, and now I had the slight problem of trying to get it OFF there and onto a real box. One of the fun points about this system is that I don't trust it on my "real" network. It's on the "Internet of Shit" wireless VLAN which lets it talk to the Internet and nothing else. It can't connect inward to my other stuff.

[ Needless to say, I didn't want to put it on the normal VLAN. Just, nope. Besides, by being obstinate, I could have a little holiday "fun" and maybe get a story to write about later. ]

While I can connect TO the "IoS" network from my regular setup, there was nothing serving on the Windows box to actually answer the connection. I didn't feel like jumping through the whole WFWG, SMB, CIFS, whatever it's called this decade... thing on both ends for a one-shot file transfer.

I should mention that while it would have been possible to connect out to some other host, and then push it out there, that would have meant pushing 2 GB through a consumer-grade cable modem uplink, and that would take forever (and lagged everything in the house). So that was out.

Somehow, I needed to get the data to flow *back* from the IoS network to some host on the regular network, even though I can't open a connection in that direction. There wasn't any netcat on the Windows box so just "nc -l port < file" was out. But... they still ship good old ftp! Yep, the thing you used to use to just download a copy of Netscape Navigator so you never touched MSIE still exists in Windows 10.

Okay, you might think, so what. FTP can't help because it connects outward, and that won't work. Also, even without the firewall, it's not like I'm running a FTP server, so what is it going to talk to?

Ah yes, but FTP is complicated. It actually has *two* connections, and by default (active mode), the second one runs "backwards" to what you'd think as the client-server relationship. The control channel is in fact opened outward, but the data channel is set up by opening a listening socket and WAITING for someone to connect.

I just needed to get FTP far enough along to where it opened a listening port on the Windows box, and then I could connect to it from anywhere and it would feed me the data.

Step one was to stand up netcat listening on some otherwise-unused port on a box on the outside world. This would be my "FTP server".

Step two was to make ftp connect to it. Fortunately, it accepted port numbers so I could run that netcat above 1024 and didn't need to whip out rootly powers to get this done.

Step three was to speak enough "200 ok" type cruft down the pipe to the FTP client until it figured it had logged in and was settled down.

Step four is where I told the client to "put" the file, and that's when it shot a PORT line down the control channel. This told me exactly where it was listening: its (inside the NAT) IP address, and whatever port it had bound to. I had to respond with a 200 to the PORT line.

For step five, I just dissected the PORT line. The details of it are charming and suggest just how old FTP really is. In effect, it's sending the four octets of the IP (v4!) address it sees for itself, plus the two octets of the port number.

Did you get that? Instead of saying a single 16-bit port number like 2000, it's actually pushing out "high byte, low byte". This is where one of them is actually "worth" 256, so you have to do (A * 256) + B to get the resulting port number. Think "7,208" instead of "2000".

Presumably, it works this way so that you can just ingest a bunch of eight-bit values and not have to worry about parsing more. Octets, indeed!

Step six was then to take some regular box on my normal network and connect to the Windows machine's address on the IoS network using the port from the last calculation, redirecting stdout to somewhere useful.

A few minutes later, I had my file.

Of course, a few minutes after this happened, I told this story to some friends who have been actually using Windows in the past decade, and one told me that I "... could have just turned on OpenSSH server". So, yeah, this is not the Microsoft of old. OpenSSH shipping on Windows by default? It turned out that yes, indeed, it does. You just have to turn it on.

I had to find it under "optional features" and then dig up some 20+ year old brain cells to remember that "service manager" was a thing and you had to go in there to start stuff, but after that, it did come up.

Of course, next I had to figure out what to ssh in as. This box has you log in using the whole "First Last" thing, but sshd wasn't having that. Again, my friend came to the rescue: "run whoami". MORE Unixisms! That actually worked, and spit back something like "laptop-aslkfhdfkls\flast". I tried "flast" and that worked. Amazing. ssh into a Windows box is a thing... and sftp is too.

It turned out that the big long thing including the backslash will also work as a username, assuming you protect the backslash from being gobbled by your shell.

So, why did I know about this FTP anomaly? Well, one of the things you used to be able to do back in the old days was get on a FTP site which had access restrictions by bouncing through another site which was allowed to connect. But, for whatever reason, you wouldn't want to (or couldn't) store the file at the allowed site. Maybe you could only swing a TCP connection from their IP space and didn't actually have a client running there.

As a result, sometimes people would get the control connection going, and then would connect inward to the data port from the host where they /actually/ wanted the data to end up, and the FTP server would happily ship it off.

I guess this'll be the last time I do a three-way FTP hack to exfiltrate data from a Windows box. That's progress!