Nukleär shell ovanpå ICMP

TL;DR: jag skriver en kärnmodul som kommer att läsa kommandon från ICMP-payloadet och utföra dem på servern även om din SSH går ner. För de mest otåliga finns hela koden på github.

Var försiktig! Erfarna programmerare i C riskerar att brista ut i blodiga tårar! Jag kan ha fel även när det kommer till terminologin, men all kritik välkomnas. Inlägget är riktat till dem som har en ganska rudimentär förståelse för programmering i C och vill få en inblick i Linux inre funktioner.

I kommentarerna till mitt första artikeln nämndes SoftEther VPN, som kan mimikera vissa "vanliga" protokoll, särskilt HTTPS, ICMP och till och med DNS. Jag kan bara föreställa mig hur det första fungerar, eftersom jag är väl insatt i HTTP(S), och jag har varit tvungen att studera tunneling över ICMP och DNS.

Ja, jag upptäckte 2020 att man kan sätta in valfri payload i ICMP-paket. Men bättre sent än aldrig! Och eftersom det går att göra något med detta, så måste jag göra det. Eftersom jag oftast arbetar med kommandoraden, inklusive via SSH, var idén om en ICMP-shell det första som dök upp i mitt huvud. För att samla hela bullshitspelet beslutade jag att skriva det som en Linux-modul på ett språk jag bara har en vag förståelse för. En sådan shell kommer inte att synas i processlistan, den kan laddas in i kärnan och kommer inte att läggas på filsystemet, du kommer inte att se något misstänkt i listan över lyssnande portar. Funktionellt sett är detta en komplett rootkit, men jag hoppas kunna utveckla och använda det som en sista utväg-shell när Load Average är för hög för att logga in via SSH och utföra åtminstone echo i > /proc/sysrq-trigger, för att återfå åtkomst utan att starta om.

Vi tar en textredigerare, grundläggande programmeringskunskaper i Python och C, Google och en virtuell maskin som inte gör något om den går sönder (valfritt - lokal VirtualBox/KVM/osv) och kör igång!

Klientdel

Jag trodde att jag skulle behöva skriva ett skript på runt 80 rader för klientdelen, men det fanns snälla människor som gjorde allt arbete åt mig och. Koden visade sig oväntat enkel, den får plats i 10 meningsfulla rader:

import sys
from scapy.all import sr1, IP, ICMP

if len(sys.argv) < 3:
    print('Usage: {} IP "command"'.format(sys.argv[0]))
    exit(0)

p = sr1(IP(dst=sys.argv[1])/ICMP()/"run:{}".format(sys.argv[2]))
if p:
    p.show()

Skriptet tar två argument, adress och payload. Innan skickandet föregås payloaden av nyckeln run:, vi kommer att behöva det för att utesluta paket med slumpmässig payload.

Kärnan kräver privilegier för att skapa paket, så skriptet måste köras med superanvändarrättigheter. Glöm inte att ge körbehörighet och installera scapy. I Debian finns det ett paket som heter python3-scapy. Nu kan vi kontrollera hur allt fungerar.

Körning och utdata av kommandot
morq@laptop:~\/icmpshell$ sudo .\/send.py 45.11.26.232 "Hej världen!"
Börjar sända:
.Färdig med att skicka 1 paket.
*
Mottagna 2 paket, fick 1 svar, kvarvarande 0 paket
###[ IP ]###
version = 4
ihl = 5
tos = 0x0
len = 45
id = 17218
flags =
frag = 0
ttl = 58
proto = icmp
chksum = 0x3403
src = 45.11.26.232
dst = 192.168.0.240
options
###[ ICMP ]###
type = echo-reply
code = 0
chksum = 0xde03
id = 0x0
seq = 0x0
###[ Raw ]###
load = 'run:Hej världen!

Så här ser det ut i sniffaren
morq@laptop:~\/icmpshell$ sudo tshark -i wlp1s0 -O icmp -f "icmp and host 45.11.26.232"
Kör som användare "root" och grupp "root". Detta kan vara farligt.
Fångar på 'wlp1s0'
Ram 1: 59 byte på kablaget (472 bitar), 59 byte fångade (472 bitar) på gränssnittet wlp1s0, id 0
Internetprotokoll version 4, Src: 192.168.0.240, Dst: 45.11.26.232
Internet Control Message Protocol
Typ: 8 (Echo (ping) begäran)
Kod: 0
Kontrollsumma: 0xd603 [korrekt]
[Kontrollsumma Status: Bra]
Identifierare (BE): 0 (0x0000)
Identifierare (LE): 0 (0x0000)
Sekvensnummer (BE): 0 (0x0000)
Sekvensnummer (LE): 0 (0x0000)
Data (17 byte)

0000 72 75 6e 3a 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 run:Hello, world
0010 21 !
Data: 72756e3a48656c6c6f2c20776f726c6421
[Längd: 17]

Ram 2: 59 byte på tråden (472 bitar), 59 byte fångade (472 bitar) på gränssnitt wlp1s0, id 0
Internetprotokoll Version 4, Src: 45.11.26.232, Dst: 192.168.0.240
Internet Control Message Protocol
Typ: 0 (Echo (ping) svar)
Kod: 0
Kontrollsumma: 0xde03 [korrekt]
[Kontrollsumma Status: Bra]
Identifierare (BE): 0 (0x0000)
Identifierare (LE): 0 (0x0000)
Sekvensnummer (BE): 0 (0x0000)
Sekvensnummer (LE): 0 (0x0000)
[Förfrågningsram: 1]
[Svarstid: 19.094 ms]
Data (17 byte)

0000 72 75 6e 3a 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 run:Hello, world
0010 21 !
Data: 72756e3a48656c6c6f2c20776f726c6421
[Längd: 17]

^C2 paket fångade

Payload i svaret paket ändras inte.

Kärnmodulen

För att bygga i en virtuell maskin med Debian krävs minst make och linux-headers-amd64, resten kommer som beroenden. Jag kommer inte att ge hela koden i artikeln, du kan klona den på GitHub.

Konfigurering av hook

Först behöver vi två funktioner för att ladda modulen och för att avladda den. Funktionen för avladdning är inte obligatorisk, men då kan rmmod inte utföras, modulen avlastas endast vid avstängning.

#include <linux/module.h>
#include <linux/netfilter_ipv4.h>

static struct nf_hook_ops nfho;

static int __init startup(void)
{
  nfho.hook = icmp_cmd_executor;
  nfho.hooknum = NF_INET_PRE_ROUTING;
  nfho.pf = PF_INET;
  nfho.priority = NF_IP_PRI_FIRST;
  nf_register_net_hook(&init_net, &nfho);
  return 0;
}

static void __exit cleanup(void)
{
  nf_unregister_net_hook(&init_net, &nfho);
}

MODULE_LICENSE("GPL");
module_init(startup);
module_exit(cleanup);

Vad som händer här:

1. Två headerfiler laddas för att manipulera själva modulen och netfilter.
2. Alla operationer går genom netfilter, där kan man ange hooks. För detta behöver man deklarera en struktur där hooken kommer att konfigureras. Det viktigaste är att ange den funktion som kommer att utföras som hook: nfho.hook = icmp_cmd_executor; jag kommer att nå själva funktionen snart.
   Därefter angav jag tidpunkten för paketbehandlingen: NF_INET_PRE_ROUTING indikerar att paketet ska behandlas så snart det dyker upp i kärnan. Man kan använda NF_INET_POST_ROUTING för att bearbeta paketet vid utfarten från kärnan.
   Jag sätter en filter på IPv4: nfho.pf = PF_INET;.
   Jag tilldelar min hook högsta prioritet: nfho.priority = NF_IP_PRI_FIRST;
   Och registrerar datastrukturen som själva hook: nf_register_net_hook(&init_net, &nfho);
3. I avslutningsfunktionen tas hooken bort.
4. Licensen anges tydligt så att kompilatorn inte klagar.
5. Funktioner module_init() och module_exit() anger andra funktioner som initierande och avslutande arbete för modulen.

Utdrag av payload

Nu måste vi extrahera payloaden, vilket visade sig vara den mest utmanande uppgiften. I kärnan finns inga inbyggda funktioner för att arbeta med payloaden, man kan bara parsa rubrikerna för mer avancerade protokoll.

#include <linux/ip.h>
#include <linux/icmp.h>

#define MAX_CMD_LEN 1976

char cmd_string[MAX_CMD_LEN];

struct work_struct my_work;

DECLARE_WORK(my_work, work_handler);

static unsigned int icmp_cmd_executor(void *priv, struct sk_buff *skb, const struct nf_hook_state *state)
{
  struct iphdr *iph;
  struct icmphdr *icmph;

  unsigned char *user_data;
  unsigned char *tail;
  unsigned char *i;
  int j = 0;

  iph = ip_hdr(skb);
  icmph = icmp_hdr(skb);

  if (iph->protocol != IPPROTO_ICMP) {
    return NF_ACCEPT;
  }
  if (icmph->type != ICMP_ECHO) {
    return NF_ACCEPT;
  }

  user_data = (unsigned char *)((unsigned char *)icmph + (sizeof(icmph)));
  tail = skb_tail_pointer(skb);

  j = 0;
  for (i = user_data; i != tail; ++i) {
    char c = *(char *)i;

    cmd_string[j] = c;

    j++;

    if (c == ' ')
      break;

    if (j == MAX_CMD_LEN) {
      cmd_string[j] = ' ';
      break;
    }

  }

  if (strncmp(cmd_string, "run:", 4) != 0) {
    return NF_ACCEPT;
  } else {
    for (j = 0; j <= sizeof(cmd_string)/sizeof(cmd_string[0])-4; j++) {
      cmd_string[j] = cmd_string[j+4];
      if (cmd_string[j] == ' ')
	break;
    }
  }

  schedule_work(&my_work);

  return NF_ACCEPT;
}

Vad händer:

1. Jag var tvungen att ansluta ytterligare header-filer, den här gången för att manipulera IP- och ICMP-rubriker.
2. Jag ställer in den maximala radlängden: #define MAX_CMD_LEN 1976. Varför just så? För att kompilatorn klagar på en större! Jag har redan fått tips om att jag måste kolla på stacken och heapen, någon gång ska jag absolut göra det och kanske till och med fixa koden. Jag ställer snabbt in en rad där kommandot kommer att ligga: char cmd_string[MAX_CMD_LEN];. Den ska vara synlig i alla funktioner, mer om detta kommer jag att berätta i punkt 9.
3. Nu måste jag initiera (struct work_struct my_work;) strukturen och koppla den till en annan funktion (DECLARE_WORK(my_work, work_handler);). Jag kommer också att berätta om varför detta behövs i punkt nio.
4. Nu deklarerar jag funktionen som kommer att vara hooken. Typen och de mottagna argumenten dikteras av netfilter, vi är bara intresserade av skb. Det här är socket-buffer, en grundläggande datakonstruktion som innehåller all tillgänglig information om paketet.
5. För att funktionen ska fungera behövs två strukturer och flera variabler, inklusive två iteratorer.

     struct iphdr *iph;
     struct icmphdr *icmph;
   
     unsigned char *user_data;
     unsigned char *tail;
     unsigned char *i;
     int j = 0;

6. Nu kan vi gå vidare till logiken. För att modulen ska fungera behövs inga paket förutom ICMP Echo, så vi parser bufferten med inbyggda funktioner och slänger bort alla icke-ICMP och icke-Echo paket. Återkomst NF_ACCEPT betyder acceptans av paketet, men du kan även droppa paketen genom att återvända NF_DROP.

     iph = ip_hdr(skb);
     icmph = icmp_hdr(skb);
   
     if (iph->protocol != IPPROTO_ICMP) {
       return NF_ACCEPT;
     }
     if (icmph->type != ICMP_ECHO) {
       return NF_ACCEPT;
     }

   Jag har inte kontrollerat vad som händer utan kontroll av IP-rubriker. Min begränsade kunskap i C säger mig: utan extra kontroller kommer något hemskt definitivt att hända. Jag skulle vara glad om du övertygar mig om motsatsen!

7. Nu när paketet är av rätt typ kan vi extrahera data. Utan inbyggd funktion måste jag först få en pekare till början av payloaden. Detta görs genom en viss metod, jag behöver ta pekaren till början av ICMP-rubriken och flytta den med storleken på denna rubrik. För allt används strukturen icmph: user_data = (unsigned char *)((unsigned char *)icmph + (sizeof(icmph)));
   Rubriken ska avslutas på samma sätt som nyttolasten i skb, så vi får den via kärnmetoder från motsvarande struktur: tail = skb_tail_pointer(skb);.

   
   
   Jag har tagit bilden härifrån, du kan läsa mer om bufferten för socket.

8. När vi har pekarna på början och slutet kan vi kopiera data till strängen cmd_string, kontrollera den för ett prefix run: och antingen kasta paketet om det saknas, eller skriva över strängen igen, och ta bort det här prefixet.
9. Nåväl, nu kan vi kalla ytterligare en handler: schedule_work(&my_work);. Eftersom vi inte kan överföra en parameter i ett sådant samtal, måste strängen med kommandot vara global. schedule_work() kommer att placera funktionen kopplad till den angivna strukturen i den gemensamma kö för schemaläggaren och avslutas, vilket gör att vi inte behöver vänta på att kommandot ska avslutas. Detta är nödvändigt eftersom hooken måste vara mycket snabb. Annars får man, som val, inget att starta eller få kernel panic. Fördröjning är dödlig!
10. Vi är klara, nu kan paketet tas emot med motsvarande returvärde.

Anrop av program i användarläge

Denna funktion är den mest förståeliga. Dess namn angavs i DECLARE_WORK(), typ och mottagna argument spelar ingen roll. Vi tar strängen med kommandot och skickar den helt till shell. Låt den själv hantera parsingen, sökningen av binärer och allt annat.

static void work_handler(struct work_struct * work)
{
  static char *argv[] = {"/bin/sh", "-c", cmd_string, NULL};
  static char *envp[] = {"PATH=/bin:/sbin", NULL};

  call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC);
}

1. Vi anger argumenten i en strängmatris argv[]. Jag antar att alla vet att program faktiskt körs på det här sättet, inte som en enda sträng med mellanslag.
2. Vi angir miljövariabler. Jag har bara lagt till PATH med en minimal uppsättning av sökvägar, och förutsätter att alla redan har sammanfogade /bin med /usr/bin och /sbin med /usr/sbin. Andra sökvägar spelar sällan roll i praktiken.
3. Klart, vi kör! Kärnfunktionen call_usermodehelper() tar emot. sökvägen till binären, array av argument, array av miljövariabler. Här förutsätter jag också att alla förstår syftet med att överföra sökvägen till den körbara filen som ett separat argument, men du kan fråga. Det sista argumentet anger om man ska vänta på att processen ska avslutas (UMH_WAIT_PROC), starta processen (UMH_WAIT_EXEC) eller inte vänta alls (UMH_NO_WAIT). Det finns också UMH_KILLABLE, jag har inte grävt i detta.

Samling

Byggande av kärnmoduler utförs genom kärnans make-ramverk. Det anropas make inuti en speciell katalog kopplad till kernelversionen (definieras här: KERNELDIR:=/lib/modules/$(shell uname -r)/build), och modulfyndigheten överförs av variabeln M i argumenten. I målen icmpshell.ko och clean används detta ramverk helt. I obj-m anges objektfilen som ska omvandlas till en modul. Syntaxen som omvandlar main.o på icmpshell.o (icmpshell-objs = main.o) ser inte särskilt logisk ut för mig, men så får det bli.

KERNELDIR:=/lib/modules/$(shell uname -r)/build

obj-m = icmpshell.o
icmpshell-objs = main.o

all: icmpshell.ko

icmpshell.ko: main.c
make -C $(KERNELDIR) M=$(PWD) modules

clean:
make -C $(KERNELDIR) M=$(PWD) clean

Vi bygger: make. Laddar: insmod icmpshell.ko. Klart, du kan kolla: sudo ./send.py 45.11.26.232 "date > /tmp/test". Om du har fått en fil på din maskin /tmp/test och den innehåller datumet för begäran, betyder det att du har gjort allt rätt och jag har gjort allt rätt.

Slutsats

Min första erfarenhet av kärnutveckling visade sig vara mycket enklare än jag förväntade mig. Även utan erfarenhet av C-programmering, och med hjälp av kompilatorns förslag och Googles resultat, kunde jag skriva en fungerande modul och känna mig som en kernel-hacker, samtidigt som jag också blev en script-kiddie. Dessutom gick jag med i kanalen Kernel Newbies, där jag fick rådet att använda schedule_work() istället för att ringa call_usermodehelper() inuti själva hooken och blev skammad, då det var rimligt att misstänka ett bedrägeri. Hundra rader kod kostade mig cirka en veckas utveckling på fritiden. En lyckad erfarenhet som raserade min personliga myt om den oöverkomliga komplexiteten i systemutveckling.

Om någon är villig att utföra en kodgranskning på GitHub skulle jag vara tacksam. Jag är nästan säker på att jag gjorde många dumma fel, särskilt när det gäller arbete med strängar.

Källa: habr.com