PDA

Bekijk Volledige Versie : R0nin



aaverkleij
25/07/05, 17:42
Hallo,

Mijn hosting provider heeft mij voor een fors bedrag aansprakelijk gested omdat ik mijn ruwe install (testversie) niet had beveiligd. Hierdoor waren er twee files met schrijfrechten. Tevens was de admin niet beveiligd. de shop had verder geen inhoud, het was puur even een test versie.

Een hacker heeft via mijn site r0nin geinstalleerd en heeft vervolgens toegang gekregen dat de complete server van de provider, waar hij mij nu dus voor aansprakelijk stelt.

Ik ben nu dus benieuwd naar de werking van R0nin en hoe men met behulp van dit programma ook op de server kan komen. Mijns inziens vooral een probleem van de hosting provider die toch de gelegenheid geeft om via specifieke poorten op de server te komen. Graag jullie mening hieromtrent.

mvg. Arno

veenman
25/07/05, 17:44
Dit is compleet belachelijk, je hostingprovider had blijkbaar zijn eigen beveiliging niet op orde want hoe kan het anders dat er via jouw account root rechten kunnen worden verkregen.

Als ik jou was zou ik je spullen bij je huidige provider zo snel mogelijk backuppen en zo snel mogelijk een nieuwe provider zoeken. Het feit dat deze je verantwoordelijk stelt is compleet achterlijk en kun je dus simpelweg negeren.

jinxedworld
25/07/05, 18:09
Dit slaat inderdaad helemaal nergens op. r0nin maakt gebruik van de do_brk() kernel-exploit, waar je veilig voor moet zijn als je je kernel bijpatched (de exploit is sowieso al vanaf december 2003 bekend).

Op de kernel heb jij als eindgebruiker helemaal geen invloed, en dit is een probleem van de hostingprovider.

maxnet
25/07/05, 18:37
Origineel geplaatst door jinxedworld
Dit slaat inderdaad helemaal nergens op. r0nin maakt gebruik van de do_brk() kernel-exploit, waar je veilig voor moet zijn als je je kernel bijpatched (de exploit is sowieso al vanaf december 2003 bekend).


Misschien dat er versies met ingebouwde do_brk() exploit in omloop zijn, maar zover ik weet is r0nin een vrij simpele trojan die een poortje open zet en er een shell aan hangt.

---


Mijns inziens vooral een probleem van de hosting provider die toch de gelegenheid geeft om via specifieke poorten op de server te komen.

Daar ben ik het niet mee eens. Dat de provider niet alle poorten standaard in zijn firewall dicht heeft gezet, is op zich niet nalatig. Hoewel de indringer in dit geval een inkomende poort heeft opengezet, had deze met hetzelfde gemak een uitgaande verbinding (reverse shell) kunnen opzetten.
Dat kan alleen worden tegengegaan door alle uitgaande verbindingen van gebruikers met de buitenwereld niet toe te staan. Hoewel dit technisch wel mogelijk is, zorgt dit voor problemen op het moment dat een website bijvoorbeeld RSS feeds van andere sites wil gebruiken.

De vraag wie aansprakelijk is, lijkt me eerder afhankelijk van wat de geleden schade precies is.

Indien de indringer toegang heeft weten te verschaffen tot bestanden van anderen, dan kan het zijn dat de webhoster nalatig is geweest met het afschermen van accounts.

Is het account van de TS echter op een andere manier misbruikt, bijvoorbeeld door via het account warez te hosten, met als gevolg een torenhoge dataverkeer rekening, dan kan ik mij voorstellen dat de webhoster de kosten op de TS wil verhalen.

aaverkleij
26/07/05, 09:14
Hallo allemaal,

De schade is samengesteld uit winstderving, klanten die bij hem vertrekken (en terecht denk ik) en zgn. bereddingskosten. Totaal niet minder dan € 28.000 !!

Raakt kant nog wal denk ik, maar goed zit er op dit moment wel even mee.

Gr. Arno

mguilmot
26/07/05, 10:14
Beveiliging moet door de hoster gebeuren.
Wordt zijn bakje ingenomen dan is het zijn schuld.

Gewoon bullshit dat hij die kosten aan jou wil doorrekenen.

Gewoon vertrekken naar een andere hoster die zijn omgeving wel degelijk beveiligd heeft.

veenman
26/07/05, 10:38
Nogmaals het is gewoon belachelijk dat je hoster een claim bij jou neer legt als de hoster zijn beveiliging niet op orde is, dat bestaat gewoon niet. Je huurt namelijk een gespecialiseerd bedrijf in om een stabiele en veilige omgeving voor je website te hebben. Hier is je hoster dus in gebreken gebleven en niet jij.

Om het toe te lichten: Als een 'hacker' toegang tot je account krijgt door een bug in je code, dan is dat jouw verantwoordelijkheid, maar als een 'hacker' hiermee toegang krijgt tot de rest van het systeem dan is dat de fout van je hoster. Simpelweg omdat jij hier zelf ook geen toegang tot zou mogen hebben.

Unixadmin
26/07/05, 11:06
Origineel geplaatst door aaverkleij

De schade is samengesteld uit winstderving, klanten die bij hem vertrekken (en terecht denk ik) en zgn. bereddingskosten. Totaal niet minder dan € 28.000 !!

Raakt kant nog wal denk ik, maar goed zit er op dit moment wel even mee.

€ 28.000, valt alleszins nog wel mee. :)
Laat hem toch lekker lullen. Hij kan je niets maken.

ensermo
26/07/05, 15:00
Ik ben geen beveiligingsexpert, maar als je via osCommerce root toegang kan krijgen tot een server dan zouden volgens mij bijna alle hosters hier een probleem hebben.

luser
26/07/05, 15:20
Nee, dat kan niet met oscommerce...

De techniek loopt als het volgende:
- slecht gescript ding dat men hiermee aan de linux cmd's kan uitvoeren (zelfde als system in php).
-> Dan wordt er ahv wget/fetch/andere... een file gedownload op een plek die schrijfbaar is voor de user apache (/tmp /dir die user 777 geeft)
-> Die file opent een reverse shell richting de hacker, hij zit nu gewoon op het systeem onder de user apache.
-> Nu bekijkt ie de versies van software op de server die exploitable kan zijn, de kernel bv.
-> Hij download de exploit, compiled hem, runned hem en tata root is hij.

Rest kan je je wel inbeelden dan.


EDIT: Ik had een lijst dingen getypt wat kan helpen, op een of andere manier na internal server error verdwenen, sebiet nog opnieuw posten.

*kloote mod_security @ wht, dan kan helpen maar uiterst lastig te posten dan *

EDIT2:
- /tmp op nodev,nosuid,noexec zetten, zo kan wel gedownload worden maar niet meer uitgevoerd (moet schrijfbaar blijven voor bv session koekjes).
- chroot toestanden (als er dan al is via user misbruik is is de rest van systeem niet bevallen).
- wget/fetch/enz alleen door root laten werken (door juist chmod)
- alles op de server van software up-to-date houden, (enkele belangrijke, proftpd (laatste tijd vol gaten)/kernel/openssl/openssh
- php niet zomaar alles laten uitvoeren (je kan limiteren dat ie alleen system dinge kan doen in bep dir).
- security toestanden zoals grsecurity gebruiken
- firewall die limitatie doet van inbound & outbound traffic
- ... en nog veel meer dingen

cashmere
26/07/05, 15:31
Sla er anders de algemene voorwaarden van je provider eens op na. Wellicht krijg je dan meer duidelijkheid. Echter zou ik als ik jou was mijn zaakjes backuppen en vertrekken naar een andere provider en verder niet teveel aanstoot nemen van zijn dreigementen.

SebastiaanStok
26/07/05, 17:03
Is er eigenlijk een fijlige manier om de kernel uptedaten ? Dus zonder problemen en zo :)

Ik heb op me server Redhat 9 staan met de oude kernel versie :X


Maar dit is uiteraard hardstike gevaarlijk, dus wat kan doen om deze een update te geven ?

luser
26/07/05, 17:04
Kernel updaten is altijd veilig als je weet wat je doet ;) Bij redhat kan het zelf ahv rpm's, wil je grsecurity erin zal je toch wel moeten werken vanuit source.

EDIT: Owja, reboot is een must (als je niets zoals kexec gebruikt), leek me logisch maar zal het toch maar ff vermelden ;)

SebastiaanStok
26/07/05, 17:09
Ja die RPM ken ik :)

Ik heb eerst via up2date aangegeven dat hij hem moet installeren.

Maar dan nog is die versie niet geüpdatet :huh:

Moet ik hier voor nog iets aparts doen, en ik heb ook driver geinstalleerd staan moeten deze dan niet opnieuw worden geinstalleerd ?

xYnta
26/07/05, 17:12
Ik zou als ik hou was even de algemene voorwaarden van je hosting provider raadplegen, opzich is het zeer ongewoon dat een hosting provider zijn klant verantwoordelijk houdt voor een inbraak op zijn of haar server. Het lijkt me namelijk de verantwoordelijkheid van de desbetreffende provider om ervoor te zorgen dat deze server goed beveiligd is.

Een hele dubieuze zaak dus, ik zou gewoon eventjes hun algemene voorwaarden goed doorspitten en mocht je vervolgens niks hierover terug vinden in de algemene voorwaarden sla je deze op en neem je contact op met je provider dat je het bedrag gewoon simpel weg niet betaald. Veel success!

luser
26/07/05, 17:13
@Rollerscapes is ff je lilo.conf (of grub) bekijken of ie er bij staat en is kijken of ie in de /boot staat.

SebastiaanStok
26/07/05, 17:23
Oke ik heb echt zooi er instaan :)



[root@server boot]# ls -all
totaal 22318
drwxr-xr-x 6 root root 2048 okt 23 2004 .
drwxr-xr-x 20 root root 4096 mei 17 13:00 ..
drwxrwxr-x 4 root root 1024 okt 21 2004 aarich-backup-0
drwxr-xr-x 5 root servers 1024 okt 22 2004 aarich-backup-1
-rw-r--r-- 1 root root 5824 jan 25 2003 boot.b
-rw-r--r-- 1 root root 612 jan 25 2003 chain.b
-rw-r--r-- 1 root root 44762 apr 14 2004 config-2.4.20-31.9
-rw-r--r-- 1 root root 44814 apr 14 2004 config-2.4.20-31.9smp
-rw-r--r-- 1 root root 44309 mrt 14 2003 config-2.4.20-8
-rw-r--r-- 1 root root 44361 mrt 13 2003 config-2.4.20-8smp
drwxr-xr-x 2 root root 1024 okt 22 2004 grub
-rw-r--r-- 1 root servers 556158 okt 22 2004 initrd-2.4.20-8.img
-rw-rw-r-- 1 root root 371846 okt 21 2004 initrd-2.4.20-8.img.3543
-rw-r--r-- 1 root servers 562188 okt 22 2004 initrd-2.4.20-8smp.img
-rw-rw-r-- 1 root root 377192 okt 21 2004 initrd-2.4.20-8smp.img.3543
-rw-r--r-- 1 root root 477 okt 23 2004 kernel.h
drwx------ 2 root root 12288 okt 21 2004 lost+found
-rw-r--r-- 1 root root 23108 feb 25 2003 message
-rw-r--r-- 1 root root 21282 feb 25 2003 message.ja
lrwxrwxrwx 1 root root 23 okt 21 2004 module-info -> module-info-2.4.20-31.9
-rw-r--r-- 1 root root 15438 apr 14 2004 module-info-2.4.20-31.9
-rw-r--r-- 1 root root 15438 apr 14 2004 module-info-2.4.20-31.9smp
-rw-r--r-- 1 root root 15436 mrt 14 2003 module-info-2.4.20-8
-rw-r--r-- 1 root root 15436 mrt 13 2003 module-info-2.4.20-8smp
-rw-r--r-- 1 root root 640 jan 25 2003 os2_d.b
lrwxrwxrwx 1 root root 22 okt 23 2004 System.map -> System.map-2.4.20-8smp
-rw-r--r-- 1 root root 522619 apr 14 2004 System.map-2.4.20-31.9
-rw-r--r-- 1 root root 548551 apr 14 2004 System.map-2.4.20-31.9smp
-rw-r--r-- 1 root root 520129 mrt 14 2003 System.map-2.4.20-8
-rw-r--r-- 1 root root 546061 mrt 13 2003 System.map-2.4.20-8smp
-rw-r--r-- 1 root root 3216789 apr 14 2004 vmlinux-2.4.20-31.9
-rw-r--r-- 1 root root 3660698 apr 14 2004 vmlinux-2.4.20-31.9smp
-rw-r--r-- 1 root root 3193503 mrt 14 2003 vmlinux-2.4.20-8
-rw-r--r-- 1 root root 3637412 mrt 13 2003 vmlinux-2.4.20-8smp
lrwxrwxrwx 1 root root 19 okt 21 2004 vmlinuz -> vmlinuz-2.4.20-31.9
-rw-r--r-- 1 root root 1134059 apr 14 2004 vmlinuz-2.4.20-31.9
-rw-r--r-- 1 root root 1219671 apr 14 2004 vmlinuz-2.4.20-31.9smp
-rw-r--r-- 1 root root 1122186 mrt 14 2003 vmlinuz-2.4.20-8
-rw-r--r-- 1 root root 1211291 mrt 13 2003 vmlinuz-2.4.20-8smp


en grug.conf staat dit.


[root@server grub]# cat grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/hda2
# initrd /initrd-version.img
#boot=/dev/hda
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Linux (2.4.20-8smp)
root (hd0,0)
kernel /vmlinuz-2.4.20-8smp ro root=LABEL=/
initrd /initrd-2.4.20-8smp.img
title Red Hat Linux-up (2.4.20-8)
root (hd0,0)
kernel /vmlinuz-2.4.20-8 ro root=LABEL=/
initrd /initrd-2.4.20-8.img


* Putty zal ooit nog is een probleem geven :X *

Dus wat ik nu doen ?

The MAzTER
26/07/05, 23:39
begin maar eens met het installeren van een OS dat niet EOL is.

RH 9 is dit al voor 1.5 jaar!

luser
27/07/05, 00:04
EOL Maakt niks uit voor je veiligheid, alleen voor de fanncy update proggies.
@Roller, ik zou toch kijken naar een van de recente releases op kernel.org, 2.4.20 is nog te oud ;)

The MAzTER
27/07/05, 00:37
Origineel geplaatst door luser
EOL Maakt niks uit voor je veiligheid, alleen voor de fanncy update proggies.
@Roller, ik zou toch kijken naar een van de recente releases op kernel.org, 2.4.20 is nog te oud ;)

maakt wel uit als je alleen met up2date kan omgaan ;)

wij hebben ook nog een RH 9 box draaien, tot nu toe nooit problemen. Houd niet in dat ik er happy mee ben. Maar gelukkig gaat ie er over een paar dagen uit.

SebastiaanStok
27/07/05, 11:25
Ik weet hoe gevaarlijk het is de kernel een update te geven.

Dus ga ik als me test bak binnen is daar is mee romelen :)


Maar hoe kan ik van een RPM updaten, wand volgends mij is hij al geinstalleerd, alleen moet ik hem nog aanzetten.


Ps: Redhat was gekozen omdat het makelijst was voor en me (ex) partner.

Op de (als die er komt) volgende server komt FreeBSD :)

mguilmot
27/07/05, 11:37
Maar hoe kan ik van een RPM updaten, wand volgends mij is hij al geinstalleerd, alleen moet ik hem nog aanzetten.
Als je een rh rpm geinstalleerd hebt moet je de conf van je bootloader (grub of lilo) eens nalezen of de nieuwe kernel erin staat. Als je lilo gebruikt moet je 'lilo' wel eerst eens runnen voor de reboot :)

SebastiaanStok
27/07/05, 11:43
Ik heb zo tezien grub, maar wat ik nu aanpassen ?

Wand ik heb echt totaal geen verstand van de boot loader aanpassen of een kernel updaten.

En met google en rethad.com ben ik ook niet verder gekomen.

bvankuik
28/07/05, 22:48
Wellicht ten overvloede, maar stel nou dat je toch aansprakelijk wordt gesteld en het blijkt dat dat ook zo is. Dan heb je toch een aansprakelijkheidsverzekering?

maxnet
28/07/05, 23:03
Origineel geplaatst door bvankuik
Wellicht ten overvloede, maar stel nou dat je toch aansprakelijk wordt gesteld en het blijkt dat dat ook zo is. Dan heb je toch een aansprakelijkheidsverzekering?

Een bedrijfaansprakelijkheidsverzekering dekt meestal alleen maar fysieke schade. Dus als je een server van iemand anders uit je handen laat vallen, dan kan je bij de verzekering aankloppen.

Vermogensschade zoals gemiste inkomsten meestal niet, hoewel je daar andere verzekeringen voor hebt.

ProServe
28/07/05, 23:42
Origineel geplaatst door skunkah
Om het toe te lichten: Als een 'hacker' toegang tot je account krijgt door een bug in je code, dan is dat jouw verantwoordelijkheid, maar als een 'hacker' hiermee toegang krijgt tot de rest van het systeem dan is dat de fout van je hoster. Simpelweg omdat jij hier zelf ook geen toegang tot zou mogen hebben.
Ah, juist. Dus als je bij buren die op vakantie zijn plantjes water aan het geven bent, en op je weg terug vergeet je de voordeur dicht te doen, en er worden spullen gejat, is het de fout van je buren dat ze het huis niet verder beveiligd hebben?

ProServe
28/07/05, 23:47
Origineel geplaatst door aaverkleij Ik ben nu dus benieuwd naar de werking van R0nin en hoe men met behulp van dit programma ook op de server kan komen. Mijns inziens vooral een probleem van de hosting provider die toch de gelegenheid geeft om via specifieke poorten op de server te komen. Graag jullie mening hieromtrent.

Het argument dat de hacker controle over heel het systeem heeft gekregen is wat mij betreft iets wat los staat. Jij installeert iets op je site, wat schijnbaar vol zit met security problemen. Dan ben jij daar verantwoordelijk voor. Zelfs als ze geen root rechten verkrijgen, kunnen ze je hoster veel schade aanrichten. Ik zie het hier dagelijks gebeuren, servers die enorme DDoS attacks gaan versturen, servers die als warez ftp worden gebruikt, of scan machine, enz enz. Daarvoor heb je allemaal geen root nodig, en de schade is net zo groot.
En trouwens, zijn wij daar dan verantwoordelijk voor? Hadden we maar de server van de klant beter moeten beveiligen??

SebastiaanStok
29/07/05, 11:12
Bij een dedicated/colecated server is dit zaak van de klant maar bij shared server licht dit neem ik aan bij de host zelf, de klant kan wel als er iets door zijn toedoen aansprakelijk worden gehouden, dat is normaal.

Maar als host moet je zelf ook dingen zo goed mogelijk befijligen om toch de simpele gevalen tevoorkomen.

Mikey
29/07/05, 11:20
Origineel geplaatst door ProServe

Ah, juist. Dus als je bij buren die op vakantie zijn plantjes water aan het geven bent, en op je weg terug vergeet je de voordeur dicht te doen, en er worden spullen gejat, is het de fout van je buren dat ze het huis niet verder beveiligd hebben?

maw, als je de server niet up2date houd en de klant gebruikt helaas software die ook veiligheidslekken vertoont is de klant aansprakelijk ? Liujkt mij pure kul.

abcinternet2
29/07/05, 12:00
Op zich is de klant aansprakelijk te stellen tot het volgende:

- Gebruik onjuiste software dat verkeerde invloed kan hebben op het milieu

- Schade vloeiende uit bovenstaande kunnen indien bewezen worden verhaald

-Algemene Wetsovertreddingen als kinderporno, warez verspreiding, open misbruik vrijheid van meningsuiting in het openbaar(komt er nog;)) etc.

- Bovenstaande gaat op basis van een zorgplicht ook wel Best Effort basis.

Wil men dit kunnen aanvechten in de rechtbank denk ik dat je toch wel de lul bent hoor. Als de logs kloppen en er fysiek bewijs is dat het via jouw account is gebeurd kun je daartoe worden gehouden op nr 3.

Eventuele boetes etc zullen door de rechter worden bepaald. De hoogste boete/uitkering ooit gegeven naar mijn weten is 450 euro en dat persoon had het heel erg bont gemaakt met zijn shares account.

Dedicated server kan wat hoogliggen.

Echter bepaling: volgens mij is het zo dat je host elke dag een backup dient te maken en een verzekering hiervoor dient af te sluiten die eventueel werk wat heiraan vast zit kan claimen tegenover dataverlies. Dit valt niet te claimen op jou maar is een algemeen verlies/risico factoor.

jinxedworld
29/07/05, 12:03
Origineel geplaatst door abcinternet2
- Gebruik onjuiste software dat verkeerde invloed kan hebben op het milieu


Broeikaseffectje... :W: :D

abcinternet2
29/07/05, 12:04
O ja en wat betreft die buren... Dit valt onder de aansprakelijkheidsverzekering particulieren . Meestal vind je dit terug onder sectie groffe nalatigheid tenzij bewezen dat persoon er alles aan heeft gedaan om de deur normaal dicht te doen.


Het tv water princiepe valt onder combinatie AVP/Inboedel

Het tv/diefstal valt meestal onder inboedel/diefstal verzekering. Wanneer deuren opengelaten zijn: Groffe nalatigheid

Op digitale sporen is dit niet van toepassing. Een firewall is niet verplicht! er bestaat dus normaler wijs geen groffe nalatigheid. Onwetendheid kan voorkomen maar is gedeeltelijk strafbaar. Dit in verband met de zorgplicht die hierop valt.

abcinternet2
29/07/05, 12:05
Origineel geplaatst door jinxedworld


Broeikaseffectje... :W: :D

Lees mileu als internet mileu datacenter omgeving os-omgeving etc.

jinxedworld
29/07/05, 12:05
Origineel geplaatst door abcinternet2


Lees mileu als internet mileu datacenter omgeving os-omgeving etc.

I know, kon het echter niet laten. Het is vrijdag he :)

ProServe
29/07/05, 13:16
Origineel geplaatst door Rollerscapes
Maar als host moet je zelf ook dingen zo goed mogelijk befijligen om toch de simpele gevalen tevoorkomen.
Hoe moet je een lek script van een klant beveiligen dan? Ja, PHP safe mode aan zetten waarschijnlijk. Waardoor ongeveer 80% van z'n klanten die PHP gebruiken een probleem hebben.

ProServe
29/07/05, 13:18
Origineel geplaatst door Mikey
maw, als je de server niet up2date houd en de klant gebruikt helaas software die ook veiligheidslekken vertoont is de klant aansprakelijk ? Liujkt mij pure kul.
Ik vind de security van de server uiteindelijk ondergeschikt in deze issue. Ookal was deze server helemaal op en top secure, met alle updates die geinstalleerd waren, kan een kiddie nog enorm veel schade aanrichten door het lekke script. Daarvoor heeft 'ie echt geen root nodig :)

SebastiaanStok
29/07/05, 15:07
Met simpele dingen bedoel ik: Geen gebruik maken van mod_suphp of wat hier op lijkt.

Je kan altijd nog met auto_appent een php gebruiken die systeem() overschijft en dan kijken of die een security bug wil uitvoeren.

Dit wil gaan gebruiken voor de database quota :D