R0nin

[aaverkleij]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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


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

[luser]

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]

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

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

[xYnta]

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!