Nieuwe 64-bit rootkit besmet Linux-servers
Er is een nieuwe 64-bit rootkit ontdekt die Linux-webservers infecteert om bezoekers van gehoste websites met malware te infecteren. De rootkit werd vorige week voor het eerst op de Full-disclosure mailinglist opgemerkt. De malware is ontwikkeld voor Linux kernelversie 2.6.32-5-amd64, wat de laatste kernel in de 64-bit Debian Squeeze distributie is.
De rootkit voegt zichzelf toe aan het /etc/rc.local script, zodat het bij het starten van het systeem wordt geladen. Vervolgens worden van bepaalde kernelfuncties en variabelen de geheugenadressen uitgelezen en voor later gebruik in het geheugen opgeslagen, zegt Marta Janus van Kaspersky Lab.
Om de bestanden en opstartvermelding in het script te verbergen kaapt de rootkit verschillende kernelfuncties, zodat de beheerder van de server niets opmerkelijks ziet.
Iframes
Het doel van de malware is het injecteren van iframes in de website of websites die op de server gehost worden. Hiervoor vervangt de rootkit de tcp_sendmsg functie, die verantwoordelijk is voor het maken van TCP-pakketten, met een eigen functie die de iframes in het HTTP-verkeer injecteert.
Bezoekers van de website worden hierdoor naar kwaadaardige sites doorgestuurd die vervolgens via een drive-by download malware op de computer proberen te plaatsen.
Toekomst
"Het is een uitstekend exemplaar, niet alleen omdat het 64-bit Linux platformen aanvalt en geavanceerde technieken gebruikt om zichzelf te verbergen, maar voornamelijk vanwege de ongewone functionaliteit om op de aangevallen HTTP server gehoste websites te infecteren", aldus Janus.
Ze stelt dat de rootkit zich nog in de ontwikkelfase bevindt, maar dat het een nieuwe aanpak voor drive-by downloads toont en we in de toekomst meer van dit soort malware kunnen verwachten.
Programmeur
Volgens beveiligingsbedrijf Crowdstrike gaat het niet om de aanpassing van een al bestaande rootkit. "Het lijkt erop dat dit contractwerk is van een middelmatige programmeur met geen uitgebreide kernel-ervaring", stelt onderzoeker Georg Wicherski. Zeer vermoedelijk is de malware in Rusland ontwikkeld, maar hoe het tot deze aanname komt wil Crowdstrike niet zeggen.
Update: typo verholpen
Reacties (26)
20-11-2012, 09:39 door
Invader Zim
"met geen"? Echt waar?
En hoe lopen deze debian servers de infectie op?
En hoe lopen deze debian servers de infectie op?
Door Invader Zim: "met geen"? Echt waar?
En hoe lopen deze debian servers de infectie op?
En hoe lopen deze debian servers de infectie op?
In de Crowdstrike analyse staat:
"It remains an open question regarding how the attackers have gained the root privileges to install the rootkit. However, considering the code quality, a custom privilege escalation exploit seems very unlikely."
Dit is maar weer zo'n geval dat je niet alleen moet uitkijken op Windows machines, maar op elk OS.....
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
20-11-2012, 09:48 door
varttaanen
En is t nou Squeeze, of Wheezy?
"Het is een uitstekend exemplaar, niet alleen omdat het 64-bit Linux platformen aanvalt en geavanceerde technieken gebruikt om zichzelf te verbergen (....)
De rootkit voegt zichzelf toe aan het /etc/rc.local script, zodat het bij het starten van het systeem wordt geladen.
Door Anoniem:
"Het is een uitstekend exemplaar, niet alleen omdat het 64-bit Linux platformen aanvalt en geavanceerde technieken gebruikt om zichzelf te verbergen (....)
Maar eerder:
De rootkit voegt zichzelf toe aan het /etc/rc.local script, zodat het bij het starten van het systeem wordt geladen.
Dat klinkt nou niet echt als een geavanceerde techniek om een rootkit te verbergen :-)
"Het is een uitstekend exemplaar, niet alleen omdat het 64-bit Linux platformen aanvalt en geavanceerde technieken gebruikt om zichzelf te verbergen (....)
De rootkit voegt zichzelf toe aan het /etc/rc.local script, zodat het bij het starten van het systeem wordt geladen.
Blijven lezen, blijven lezen:
Om de bestanden en opstartvermelding in het script te verbergen kaapt de rootkit verschillende kernelfuncties, zodat de beheerder van de server niets opmerkelijks ziet.
Ik vroeg laatst al naar een Linux rootkit scanner. Iemand verwees me naar rkhunter-1.4.0 maar ik krijg het idee
dat die dit soort rootkits niet gaat vinden.
Het is Squeeze. Dit staat in het full disclosure linkje.
Verder komt wheezy met 3.2.X als kernel en niet met 2.6.32.
Verder komt wheezy met 3.2.X als kernel en niet met 2.6.32.
20-11-2012, 10:30 door
Rasalom
Door Anoniem:
Ik gok eigenlijk dat het feest pas vanaf dat moment begint. Om binnen te komen werken de eenvoudigste trucs vaak het beste. Als je eenmaal binnen bent dan kan je aan het werk om je zo goed mogelijk te verbergen.De rootkit voegt zichzelf toe aan het /etc/rc.local script, zodat het bij het starten van het systeem wordt geladen.
Dat klinkt nou niet echt als een geavanceerde techniek om een rootkit te verbergen :-)Ik hoop dat deze nieuwe aanpak snel de weg wordt afgesneden.
Door Anoniem: Dit is maar weer zo'n geval dat je niet alleen moet uitkijken op Windows machines, maar op elk OS.....
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
Of zoals hier geimpliceerd: De systeembeheerder.
Wat jij hier overigens impliceert is overigens niet waar: Er is wel degelijk verschil tussen verschillende systemen, al is het er een van gradaties en niet van absoluten. Windows zit nog steeds aan het extreme "jongleert graag met zeep in de gevangenisdouche" eind van wat er gangbaar is tegenwoordig, en de dichtstbijzijnde volgende zit er verder van af dan die tot diens volgende buur. Je zal mij dan ook niet horen zeggen dat mijn favoriete systeem "100% veilig" is, maar wel dat ik het duidelijk verkies boven zekere meer gangbare alternatieven.
Neem bijvoorbeeld eens hoe deze rootkit verzekert dat'ie gestart wordt: Door een instructie zichzelf op te starten aan een welbekend tekstbestandje toe te voegen. Wellicht kun je het vergelijken met een rootkit die zich aan het "startup"-submenu van het startmenu van de Aministrator toevoegt. DWZ redelijk makkelijk te vinden en niet te vergelijken met de ondoorzichtige trukerij waar zekere andere systemen bekend om staan. Je hebt er namelijk niet een derdepartijprogramma voor nodig om /etc/rc.local voor je uit te pluizen, zoals dat met, oh, netinfo of gnome config of de registry wel noodzakelijk is.
En een netjes beheerd serverpark merkt op wanneer er dingen in zulke bestanden gewijzigd worden, en dat wordt dan netjes onder de aandacht van het systeembeheerteam gebracht. Als het samenvalt met een change request ticket dan is het goed, anders is het reden te gaan kijken hoe dat nou weer kon gebeuren. Ook zo'n systeem is hier makkelijker te bouwen.
20-11-2012, 11:30 door
SirDice
Door Anoniem: Neem bijvoorbeeld eens hoe deze rootkit verzekert dat'ie gestart wordt: Door een instructie zichzelf op te starten aan een welbekend tekstbestandje toe te voegen. Wellicht kun je het vergelijken met een rootkit die zich aan het "startup"-submenu van het startmenu van de Aministrator toevoegt. DWZ redelijk makkelijk te vinden en niet te vergelijken met de ondoorzichtige trukerij waar zekere andere systemen bekend om staan. Je hebt er namelijk niet een derdepartijprogramma voor nodig om /etc/rc.local voor je uit te pluizen, zoals dat met, oh, netinfo of gnome config of de registry wel noodzakelijk is.
Helaas, maar die vlieger gaat niet op.Om de bestanden en opstartvermelding in het script te verbergen kaapt de rootkit verschillende kernelfuncties, zodat de beheerder van de server niets opmerkelijks ziet.
Neem bijvoorbeeld eens hoe deze rootkit verzekert dat'ie gestart wordt: Door een instructie zichzelf op te starten aan een welbekend tekstbestandje toe te voegen. Wellicht kun je het vergelijken met een rootkit die zich aan het "startup"-submenu van het startmenu van de Aministrator toevoegt. DWZ redelijk makkelijk te vinden en niet te vergelijken met de ondoorzichtige trukerij waar zekere andere systemen bekend om staan. Je hebt er namelijk niet een derdepartijprogramma voor nodig om /etc/rc.local voor je uit te pluizen, zoals dat met, oh, netinfo of gnome config of de registry wel noodzakelijk is.
De ondoorzichtige trukerij op andere systemen is waarschijnlijk ook begonnen met het zichzelf toevoegen aan
dit soort opstartbestanden. (autoexec.bat en/of config.sys ??)
20-11-2012, 11:47 door
varttaanen
Mooi dat ik Wheezy (of beter: testing) draai, hoef ik me hierover niet druk te maken :)
Door Anoniem:
Of zoals hier geimpliceerd: De systeembeheerder.
Wat jij hier overigens impliceert is overigens niet waar: Er is wel degelijk verschil tussen verschillende systemen, al is het er een van gradaties en niet van absoluten. Windows zit nog steeds aan het extreme "jongleert graag met zeep in de gevangenisdouche" eind van wat er gangbaar is tegenwoordig, en de dichtstbijzijnde volgende zit er verder van af dan die tot diens volgende buur. Je zal mij dan ook niet horen zeggen dat mijn favoriete systeem "100% veilig" is, maar wel dat ik het duidelijk verkies boven zekere meer gangbare alternatieven.
Neem bijvoorbeeld eens hoe deze rootkit verzekert dat'ie gestart wordt: Door een instructie zichzelf op te starten aan een welbekend tekstbestandje toe te voegen. Wellicht kun je het vergelijken met een rootkit die zich aan het "startup"-submenu van het startmenu van de Aministrator toevoegt. DWZ redelijk makkelijk te vinden en niet te vergelijken met de ondoorzichtige trukerij waar zekere andere systemen bekend om staan. Je hebt er namelijk niet een derdepartijprogramma voor nodig om /etc/rc.local voor je uit te pluizen, zoals dat met, oh, netinfo of gnome config of de registry wel noodzakelijk is.
En een netjes beheerd serverpark merkt op wanneer er dingen in zulke bestanden gewijzigd worden, en dat wordt dan netjes onder de aandacht van het systeembeheerteam gebracht. Als het samenvalt met een change request ticket dan is het goed, anders is het reden te gaan kijken hoe dat nou weer kon gebeuren. Ook zo'n systeem is hier makkelijker te bouwen.
Door Anoniem: Dit is maar weer zo'n geval dat je niet alleen moet uitkijken op Windows machines, maar op elk OS.....
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
Of zoals hier geimpliceerd: De systeembeheerder.
Wat jij hier overigens impliceert is overigens niet waar: Er is wel degelijk verschil tussen verschillende systemen, al is het er een van gradaties en niet van absoluten. Windows zit nog steeds aan het extreme "jongleert graag met zeep in de gevangenisdouche" eind van wat er gangbaar is tegenwoordig, en de dichtstbijzijnde volgende zit er verder van af dan die tot diens volgende buur. Je zal mij dan ook niet horen zeggen dat mijn favoriete systeem "100% veilig" is, maar wel dat ik het duidelijk verkies boven zekere meer gangbare alternatieven.
Neem bijvoorbeeld eens hoe deze rootkit verzekert dat'ie gestart wordt: Door een instructie zichzelf op te starten aan een welbekend tekstbestandje toe te voegen. Wellicht kun je het vergelijken met een rootkit die zich aan het "startup"-submenu van het startmenu van de Aministrator toevoegt. DWZ redelijk makkelijk te vinden en niet te vergelijken met de ondoorzichtige trukerij waar zekere andere systemen bekend om staan. Je hebt er namelijk niet een derdepartijprogramma voor nodig om /etc/rc.local voor je uit te pluizen, zoals dat met, oh, netinfo of gnome config of de registry wel noodzakelijk is.
En een netjes beheerd serverpark merkt op wanneer er dingen in zulke bestanden gewijzigd worden, en dat wordt dan netjes onder de aandacht van het systeembeheerteam gebracht. Als het samenvalt met een change request ticket dan is het goed, anders is het reden te gaan kijken hoe dat nou weer kon gebeuren. Ook zo'n systeem is hier makkelijker te bouwen.
Je hebt zeker een punt, dat het hier om de systeembeheerder gaat.
Echter wat ik bedoelde te zeggen is dat ondanks welk OS je gebruikt, als er een "beheerder" een zooitje van maakt, kan je altijd problemen krijgen...
Tuurlijk kan het ene OS default al beter opgebouwd zijn dan het andere, maar "beheerders" die echt erin verdiept hebben weten precies hoeveel zaken op te vangen zijn.
"Beheerders" die net om de hoek komen kijken (of wel denken dat ze het zo goed weten) blijven een probleem, dat ligt niet aan het OS.
Wat me altijd verbaasd zijn de Servers die een Internet Verbinding hebben en waarop dan ook de browser gebruikt wordt om even op Facebook te kijken, die beheerders zouden ze direct moeten degraderen naar de Service Desk.
Dat er een Internet Verbinding aanwezig is op een Server vind ik al apart, maar goed zou om bepaalde redenen goed te praten kunnen zijn, maar een browser sessie om te internetten hoort gewoon op de werkplek.... (Tenzij een Terminal Sessie of iets dergelijks...)
Ah dus nu ligt het weer aan de beheerders, maar als er een windows machine geïnfecteerd geraakt,
dan ligt het nergens anders aan dan aan het programmeerwerk in redmond...
dan ligt het nergens anders aan dan aan het programmeerwerk in redmond...
Door Anoniem:
Je hebt zeker een punt, dat het hier om de systeembeheerder gaat.
Echter wat ik bedoelde te zeggen is dat ondanks welk OS je gebruikt, als er een "beheerder" een zooitje van maakt, kan je altijd problemen krijgen...
Tuurlijk kan het ene OS default al beter opgebouwd zijn dan het andere, maar "beheerders" die echt erin verdiept hebben weten precies hoeveel zaken op te vangen zijn.
"Beheerders" die net om de hoek komen kijken (of wel denken dat ze het zo goed weten) blijven een probleem, dat ligt niet aan het OS.
Wat me altijd verbaasd zijn de Servers die een Internet Verbinding hebben en waarop dan ook de browser gebruikt wordt om even op Facebook te kijken, die beheerders zouden ze direct moeten degraderen naar de Service Desk.
Dat er een Internet Verbinding aanwezig is op een Server vind ik al apart, maar goed zou om bepaalde redenen goed te praten kunnen zijn, maar een browser sessie om te internetten hoort gewoon op de werkplek.... (Tenzij een Terminal Sessie of iets dergelijks...)
Surfen op een server is in principe altijdt fout maar er kunnen het kan zijn dat er een update gedownload moet worden waarvoor een internet verbinding vereist is.Door Anoniem:
Of zoals hier geimpliceerd: De systeembeheerder.
Wat jij hier overigens impliceert is overigens niet waar: Er is wel degelijk verschil tussen verschillende systemen, al is het er een van gradaties en niet van absoluten. Windows zit nog steeds aan het extreme "jongleert graag met zeep in de gevangenisdouche" eind van wat er gangbaar is tegenwoordig, en de dichtstbijzijnde volgende zit er verder van af dan die tot diens volgende buur. Je zal mij dan ook niet horen zeggen dat mijn favoriete systeem "100% veilig" is, maar wel dat ik het duidelijk verkies boven zekere meer gangbare alternatieven.
Neem bijvoorbeeld eens hoe deze rootkit verzekert dat'ie gestart wordt: Door een instructie zichzelf op te starten aan een welbekend tekstbestandje toe te voegen. Wellicht kun je het vergelijken met een rootkit die zich aan het "startup"-submenu van het startmenu van de Aministrator toevoegt. DWZ redelijk makkelijk te vinden en niet te vergelijken met de ondoorzichtige trukerij waar zekere andere systemen bekend om staan. Je hebt er namelijk niet een derdepartijprogramma voor nodig om /etc/rc.local voor je uit te pluizen, zoals dat met, oh, netinfo of gnome config of de registry wel noodzakelijk is.
En een netjes beheerd serverpark merkt op wanneer er dingen in zulke bestanden gewijzigd worden, en dat wordt dan netjes onder de aandacht van het systeembeheerteam gebracht. Als het samenvalt met een change request ticket dan is het goed, anders is het reden te gaan kijken hoe dat nou weer kon gebeuren. Ook zo'n systeem is hier makkelijker te bouwen.
Door Anoniem: Dit is maar weer zo'n geval dat je niet alleen moet uitkijken op Windows machines, maar op elk OS.....
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
Ongeacht hoe het systeem besmet wordt, of nou door Drive-By downloads of wat voor oorzaak dan ook erop komt.
Geen enkel OS is perfect, in combinatie met de menselijk factor : de eindgebruiker
Of zoals hier geimpliceerd: De systeembeheerder.
Wat jij hier overigens impliceert is overigens niet waar: Er is wel degelijk verschil tussen verschillende systemen, al is het er een van gradaties en niet van absoluten. Windows zit nog steeds aan het extreme "jongleert graag met zeep in de gevangenisdouche" eind van wat er gangbaar is tegenwoordig, en de dichtstbijzijnde volgende zit er verder van af dan die tot diens volgende buur. Je zal mij dan ook niet horen zeggen dat mijn favoriete systeem "100% veilig" is, maar wel dat ik het duidelijk verkies boven zekere meer gangbare alternatieven.
Neem bijvoorbeeld eens hoe deze rootkit verzekert dat'ie gestart wordt: Door een instructie zichzelf op te starten aan een welbekend tekstbestandje toe te voegen. Wellicht kun je het vergelijken met een rootkit die zich aan het "startup"-submenu van het startmenu van de Aministrator toevoegt. DWZ redelijk makkelijk te vinden en niet te vergelijken met de ondoorzichtige trukerij waar zekere andere systemen bekend om staan. Je hebt er namelijk niet een derdepartijprogramma voor nodig om /etc/rc.local voor je uit te pluizen, zoals dat met, oh, netinfo of gnome config of de registry wel noodzakelijk is.
En een netjes beheerd serverpark merkt op wanneer er dingen in zulke bestanden gewijzigd worden, en dat wordt dan netjes onder de aandacht van het systeembeheerteam gebracht. Als het samenvalt met een change request ticket dan is het goed, anders is het reden te gaan kijken hoe dat nou weer kon gebeuren. Ook zo'n systeem is hier makkelijker te bouwen.
Je hebt zeker een punt, dat het hier om de systeembeheerder gaat.
Echter wat ik bedoelde te zeggen is dat ondanks welk OS je gebruikt, als er een "beheerder" een zooitje van maakt, kan je altijd problemen krijgen...
Tuurlijk kan het ene OS default al beter opgebouwd zijn dan het andere, maar "beheerders" die echt erin verdiept hebben weten precies hoeveel zaken op te vangen zijn.
"Beheerders" die net om de hoek komen kijken (of wel denken dat ze het zo goed weten) blijven een probleem, dat ligt niet aan het OS.
Wat me altijd verbaasd zijn de Servers die een Internet Verbinding hebben en waarop dan ook de browser gebruikt wordt om even op Facebook te kijken, die beheerders zouden ze direct moeten degraderen naar de Service Desk.
Dat er een Internet Verbinding aanwezig is op een Server vind ik al apart, maar goed zou om bepaalde redenen goed te praten kunnen zijn, maar een browser sessie om te internetten hoort gewoon op de werkplek.... (Tenzij een Terminal Sessie of iets dergelijks...)
Maar de vraag is hoe verberg je met een kernel functie de inhoud van /etc/rc.local????
De volgende vraag is hoe kun je iets in de root zetten als je geen rechten hebt laat staan iets in de /bin cq /sbin pad zetten zodat het opgestart kan worden door rc.local?????
Dit is weer een verhaal die alle schijn heeft van FUD, bangmakerij en oja koop ook ons hele dure beveiligingspakket...
De volgende vraag is hoe kun je iets in de root zetten als je geen rechten hebt laat staan iets in de /bin cq /sbin pad zetten zodat het opgestart kan worden door rc.local?????
Dit is weer een verhaal die alle schijn heeft van FUD, bangmakerij en oja koop ook ons hele dure beveiligingspakket...
20-11-2012, 16:00 door
[Account Verwijderd]
[Verwijderd]
@Miriam4711
http://esec-lab.sogeti.com/post/2010/11/21/Presentation-at-Hack.lu-:-Reversing-the-Broacom-NetExtreme-s-firmware
http://esec-lab.sogeti.com/post/2010/11/21/Presentation-at-Hack.lu-:-Reversing-the-Broacom-NetExtreme-s-firmware
Door Anoniem: Wat me altijd verbaasd zijn de Servers die een Internet Verbinding hebben en waarop dan ook de browser gebruikt wordt om even op Facebook te kijken, die beheerders zouden ze direct moeten degraderen naar de Service Desk.
Dat er een Internet Verbinding aanwezig is op een Server vind ik al apart, maar goed zou om bepaalde redenen goed te praten kunnen zijn, maar een browser sessie om te internetten hoort gewoon op de werkplek.... (Tenzij een Terminal Sessie of iets dergelijks...)
Dat er een Internet Verbinding aanwezig is op een Server vind ik al apart, maar goed zou om bepaalde redenen goed te praten kunnen zijn, maar een browser sessie om te internetten hoort gewoon op de werkplek.... (Tenzij een Terminal Sessie of iets dergelijks...)
Servers en internetverbindingen, tjsa, als ze het publiek dienen dan hebben ze zoiets wel nodig ja. Maar echte servers zijn "headless", hebben helemaal niets met grafische omgevingen, eigenlijk niet eens een grafische kaart.
En ja, dan valt windows af. Wat jammer nou. Is ook niet gek: Het is gemaakt om "gebruiksvriendelijk" te zijn voor "de gemiddelde gebruiker". En ja, als je je beheerders uit hetzelfde gemiddelde potje haalt, dan krijg je waar je om vroeg. Dit zal ook best een factor zijn in het veiligheidsverhaal, ja.
Serieuze serverparken bestaan uit genoeg servers in dat je ze niet meer individueel gaat beheren, en dan wil je er dus ook niet meer individueel op inloggen om knopjes te klikken. Alles per script, alles automatiseren. En daar hebben we toevallig al een jaar of... ruim veertig ondertussen, betere oplossingen voor.
Als je een serieuze ISP bent en een pool van WWW servers draait, draai je die inderdaad headless en je haalt de htttpd.conf/php.ini ergens centraal vandaan binnen de gehele server pool. Verder gooi je alles dicht en geef je in geval van shared hosting geen groep rechten( alleen user-rw(ftp/shh) en world read-only_www_root ). Dit maakt het vrijwel onmogelijk dat de shared users ook maar iets ondermijnend kunnen doen omdat zij alleen read-only rechten hebben van de config-server ze zijn immers geen groeps lid van wheel,sudo enzovoorts.
[/quote]Surfen op een server is in principe altijdt fout maar er kunnen het kan zijn dat er een update gedownload moet worden waarvoor een internet verbinding vereist is.[/quote]
Ook dan hoeft er geen internet op de server aanwezig te zijn, in Windows omgevingen wordt hier bijvoorbeeld WSUS/SCCM voor gebruikt, de server neemt dan contact op met een interne Update Server. Deze server is dan voorzien van alle Windows Updates die nodig zijn voor dat bedrijf.
Het beheren van servers zou zelfs niet op de Console van de Server moeten, maar via Management-Snapins via een Remote Werkstation. Hierdoor is de kans dat je server blootgelegd wordt aan rotzooi goed te minimaliseren.
Met Windows Server 2012 zie je al dat ze deze kant op gaan en ook de optie het OS zonder GUI te installeren is goed. (Kan al in 2008 Server).... Je merkt dat Systeem Beheerders zonder of met weinig kennis het al niet durven zulke servers aan te pakken, dus alleen de beheerders die het snappen zullen hierop wijzigingen aanbrengen.
Ook dan hoeft er geen internet op de server aanwezig te zijn, in Windows omgevingen wordt hier bijvoorbeeld WSUS/SCCM voor gebruikt, de server neemt dan contact op met een interne Update Server. Deze server is dan voorzien van alle Windows Updates die nodig zijn voor dat bedrijf.
Het beheren van servers zou zelfs niet op de Console van de Server moeten, maar via Management-Snapins via een Remote Werkstation. Hierdoor is de kans dat je server blootgelegd wordt aan rotzooi goed te minimaliseren.
Met Windows Server 2012 zie je al dat ze deze kant op gaan en ook de optie het OS zonder GUI te installeren is goed. (Kan al in 2008 Server).... Je merkt dat Systeem Beheerders zonder of met weinig kennis het al niet durven zulke servers aan te pakken, dus alleen de beheerders die het snappen zullen hierop wijzigingen aanbrengen.
21-11-2012, 10:31 door
dutchfish
Door Anoniem:
In de Crowdstrike analyse staat:
"It remains an open question regarding how the attackers have gained the root privileges to install the rootkit. However, considering the code quality, a custom privilege escalation exploit seems very unlikely."
Door Invader Zim: "met geen"? Echt waar?
En hoe lopen deze debian servers de infectie op?
En hoe lopen deze debian servers de infectie op?
In de Crowdstrike analyse staat:
"It remains an open question regarding how the attackers have gained the root privileges to install the rootkit. However, considering the code quality, a custom privilege escalation exploit seems very unlikely."
<sudo privilige escalation>
21-11-2012, 10:55 door
SirDice
Door Anoniem: Maar de vraag is hoe verberg je met een kernel functie de inhoud van /etc/rc.local????
Dat is niet zo heel moeilijk. Als je het Kaspersky artikel leest, daar staat 't in:In order to hide files and the startup entry, the rootkit hooks the following kernel functions, either by inline hooking or by replacing their addresses in memory with pointers to its own malicious functions:
vfs_readdir
vfs_read
filldir64
filldir
Bedenk dat je wel zoiets zou kunnen maken als
if ( filename = "/etc/rc.local" ) {
if ( line = "insmod blah" ) {
next;
} else {
continue;
} else { continue; }
De volgende vraag is hoe kun je iets in de root zetten als je geen rechten hebt laat staan iets in de /bin cq /sbin pad zetten zodat het opgestart kan worden door rc.local?????
Ook dat is simpel. Wel eens van een local root exploit gehoord? Je weet wel, die bugs die altijd gebagatelliseerd worden omdat ze toch alleen maar "local" werken. Bedenk dat "www" of "nobody" gewoon lokale accounts zijn en dat ze niet zo heel erg "beperkt" zijn als iedereen denkt.Dit is weer een verhaal die alle schijn heeft van FUD, bangmakerij en oja koop ook ons hele dure beveiligingspakket...
Nee, FUD is wat jij hier probeert te verspreiden.
21-11-2012, 11:03 door
dutchfish
Beste SirDice,
Niet helemaal ....
Wat je steeds vaker ziet is dat hosting bedrijfjes al snel shell access (geen root access) verschaffen op verzoek. Dan is in principe je security "invalidated".
Ik ben het nog steeds met je eens, dat (mits je hiervoor de juiste maatregelen neemt) je linux systeem op LAMP absoluut veilig is te maken. Een dergelijke genoemde root exploit komt van binnen uit.
voorbeeld: <sudo privilige escalation> en sommige apache extensies. ook mysql heeft enkele steekjes laten vallen recentelijk. ook hier geld weer: Alles heeft onderhoud nodig om de boel op tijd te patchen.
Mijn 2 centen
Niet helemaal ....
Wat je steeds vaker ziet is dat hosting bedrijfjes al snel shell access (geen root access) verschaffen op verzoek. Dan is in principe je security "invalidated".
Ik ben het nog steeds met je eens, dat (mits je hiervoor de juiste maatregelen neemt) je linux systeem op LAMP absoluut veilig is te maken. Een dergelijke genoemde root exploit komt van binnen uit.
voorbeeld: <sudo privilige escalation> en sommige apache extensies. ook mysql heeft enkele steekjes laten vallen recentelijk. ook hier geld weer: Alles heeft onderhoud nodig om de boel op tijd te patchen.
Mijn 2 centen
21-11-2012, 11:36 door
SirDice
Door dutchfish: Wat je steeds vaker ziet is dat hosting bedrijfjes al snel shell access (geen root access) verschaffen op verzoek. Dan is in principe je security "invalidated".
Totaal niet nodig als de web applicatie een command injection of file inclusion heeft. Je kunt dan prima een local exploit injecteren. Daar heb je echt geen lokaal account voor nodig.Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
