ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ NetWork Distributed Viruses ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ by Bumblebee/29A Introduction ÄÄÄÄÄÄÄÄÄÄÄÄ This article makes a little approach to network distributed viruses, thinking it as a way to update viruses. We've seen different people trying to make viruses updatable. I was thinking in the idea and i've found a problem when you update your virus via network, let's say internet. Some interesting viruses try to download the update from a web site using HTTP. That is very good but when avers check the virus your update site is sure removed :/ The same will happen with FTP. heh But news could be different. But not in this article :) But i think could be made that the virus updates itself from a more advanced virus. Of coz for this issue we need to define at least, and may be not at last, two protocols: for network communication and an interface for updating. I'm going to expose here an example of network protocol. As i wrote a MVI (modular virus interface) article for 29a#4 i'll not discuss here again the interface for updating. Ask our distributor for old zine numbers hehehe. Network Protocol ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The idea i have in mind is that a virus can be server or client. The way the virus acts depends on some noise to avoid more than one server on the same sub-network. For the idea i want to use UDP protocol that is simple to manage and coz we're coding a virus no matter of packet loss :) Let me use something like a finite state machine (M.E.F. in spanish). Some defines: RANDOM: random number WAITTIME: time to wait for a server READY2SERVE: message that send servers waiting client connections PUBLICPORT: port that avers will know :) HEREIAM: message that sends a client that wanna join the server. it includes the module list with versions to allow server to know if there are new versions PRIVATEPORT: port where server talks with clients. it includes the list of modules with versions that has the server (random port>1024 per session) IP: client/server IP from request BC: our network broadcast addr (thats 10.221.1.0 for IP 10.221.1.10 as ex.) you can put here the broadcast of network size C,B,... but i think C its ok (mask 255.255.255.0) WANNAUPDATE: module update request MODULEUPDATE: that's the module requested We have following states (only four... heh): E0: Wait listening BC:PUBLICPORT (start WAITTIME+RANDOM) E1: Wait listening BC:PUBLICPORT (start WAITTIME+RANDOM) Wait listening BC:PRIVATEPORT+1 E2: Wait update (start WAITTIME+RANDOM) E3: Wait listening BC:PUBLICPORT+1 (start WAITTIME+RANDOM) Wait listening BC:PRIVATEPORT Some actions (inputs): A0: Update received A1: Self not updated A2: Update requested A3: WAITTIME+RANDOM out A4: HEREIAM received A5: READY2SERVE received Let's begin! Initial state: E0 E0 -- A3 --> E3 (we are server) E3 -- A3: out READY2SERVE@BC:PUBLICPORT --> E3 | -- A4: out PRIVATEPORT@IP:PUBLICPORT --> E3 | -- A1: out WANNAUPDATE@IP:PRIVATEPORT+1 --> E2 | -- A2: out MODULEUPDATE@IP:PRIVATEPORT+1 --> E3 E0 -- A5: out HEREIAM@IP:PUBLICPORT+1 --> E1 (we are client) E1 -- A1: WANNAUPDATE@IP:PRIVATEPORT --> E2 | -- A2: out MODULEUPDATE@IP:PRIVATEPORT --> E1 | -- A3 --> E3 (we are server) | -- A5: out HEREIAM@IP:PUBLICPORT+1 --> E1 (we are still client) E2 -- A0 --> E1 if we're client | --> E3 if we're server | -- A5 --> E0 if we're client (server down?) --> E3 if we're server (client update loss) It may seem a bit complex, but it isn't! It has a non efficient way in data terms to manage network errors, that's UDP packes loss. But it is easy to code without annoying ACK's and NACK's going up and down the wire. What the hell we get with this protocol? We have a different servers in different sessions (and may be in the same session hehe ;) And the best is that sysadmin only knows the server IP, that's only one machine infected. To get the others you must wait to another virus to become server and this will took WAITTIME+RANDOM (random noise to avoid two or more servers running at time... but is not needed and really doesn't works very fine if machines swich on in a random way). Of coz avers can code a fake server... but sure this is annoying for them, isn't it? Battlefield ÄÄÄÄÄÄÄÄÄÄÄ May be you (lo reader!) are a bit lost with my M.E.F. so i'm going to write here an example of protocol working: - We are a virus made by coder 'X' and we go resident by a way that it doesn't concern here. We start to listen PUBLIC port (let's say 6000). We start also a counter. Suppose the counter reaches zero. We assume there is no server working and we are the overlords. So we become server. We get a random port for PRIVATEPORT (let's say 10200) and we start listening 10200 for requests and port 6001 (that's public +1) for HEREIAM messages. Just send the READY2SERVE message. We start another counter. If this counter reaches zero we will send the READY2SERVE. That's avoid there are more than us as server :) Let's say that a virus made by coder 'Y' starts in another machine in our network. And it receives one of our READY2SERVE. hehe Eat shit! We are the server! This sad virus then will send us at 6001 the HEREIAM message. This message includes his module list. We get it and check our list. But before requesting a module (if needed) we need to send the PRIVATEPORT to the client plus out list before update shit. erm... our virus is awesome and has two modules with higher version that the client virus. So will not ask for module. But oh! we receive a little WANNAUPDATE message in our PRIVATEPORT. Then we send the MODULEUPDATE to this 'piltrafilla*' hehe. Later we receive another WANNAUPDATE and we reply as required. But shit happens and the lame user in our machine ends the session :/ ouch. Our glory time ends by now. But there's another virus (remember 'Y'). When its counter reaches zero it becomes server and next viruses sending HEREIAM when 'Y' sends READY2SERVE will get its PRIVATEPORT. And viral life will continue. As you can see it's not as complex as it seems. It's hard to get it at first time but soon you will start to think adding more things to it :) From theory side that's all folks. But let's walk a bit into a simple implementation. UDP sockets are not blocking. But it means too that you're not sure packets arrives. As i say before don't care. We are coding a virus and moreover UDP are quite secure at local networks (the machines in the same ISP than you when you're connected to internet are very nice to receive those packets). And more than one server is not bad after all coz each client will use ONLY ONE server. The worst case will be 'n' viruses and 'n' servers, that's no communication! Implementin server-to-server communication it's very hard, forgive it! A nice idea should be add a CRC to the messages to avoid errors, at least in big messages. An encryption layer could be easily supported too. Crypt key could be provided by the server with the PRIVATEPORT. And something better: server could send with PRIVATEPORT a pieze of code that has the crypt algo. Each virus could have it's own algo. The client only need the encryptor. Packets must be as small as possible. Let's say 32 bytes for simple communication and ever less than 512 bytes. So we can add a review for the protocol and the WANNAUPDATE could provide a port to make a TCP connection with server to send module data in a more reliable way. It could be more easy than manage a message in several UDP packets ugh :/ Btw we are coding a virus. Try to not code modules of 10 kbs or so ok? That's enought by now. If you want you can send me your ideas and comments. Let's start our own RFC! hehe Last turn off the lights ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ I hope you're not thinkin: 'I'm lost. It really will update a virus?' The idea is you add to your updatable virus a new module and the you can spread it to see how it updates your other samples out there. At leat next generations will be updated :) That improves the machine-to- machine uptade approach using networks. And don't rely in web address anymore! Another point is you can use this distributed system for other things like the payload. What happens if the server triggers a SHUTDOWN mess? Just imagine several machines closing windows at the same time... it is not a wonderful world? If you're thinkin: 'That's impossible.' hehe i don't care what are you thinking, else i'll write here a M.E.F. about what's in your mind. Btw in the 2000 Valencian VX meeting Billy Belcebú, YbY, ... and me where speaking about this shit... and who knows? be scared! The way of the bee *piltrafilla: little pieze of shit.