Nieuwe ransomware richt zich op Linux-webservers die Magento draaien - update

Een nieuw soort ransomware is ontdekt die zich richt op webservers die Linux draaien. De ransomware, genaamd Linux.Encoder.1, buit in ieder geval kwetsbaarheden in e-commerce-software Magento uit, maar andere attack vectors zijn niet uitgesloten.

De ransomware werd eind vorige week geïndentificeerd door Dr.Web. Wanneer de ransomware toegang heeft tot een systeem, worden meerdere mappen met standaardbenamingen binnengedrongen en de inhoud ervan versleuteld met aes-cbc-128. In iedere map wordt vervolgens een readme_for_decrypt.txt-bestand geplaatst met daarin de losgeld-eis. Onder andere de mappen voor MySQL-servers en de web-mappen van Apache- en Nginx-webservers zijn het doelwit. Het besturingssysteem zelf wordt juist met rust gelaten om de beheerder alle gelegenheid te geven om de eis om losgeld te vinden.

Volgens bronnen van Krebs on Security vindt de infectie plaats via beveiligingsgaten in de e-commerce-software Magento. Het gat in die software is begin dit jaar al gedicht, maar beheerders zijn zelf verantwoordelijk voor het up-to-date houden van de software. Het is op dit moment echter niet uit te sluiten dat de ransomware zich alleen via het gat in Magento verspreidt en geen andere attack vectors heeft.

Volgens de bronnen van Krebs on Security worden de bestanden wel automatisch ontsleuteld door de ransomware wanneer men het losgeld betaalt, hoewel er zeer kleine variaties in bestanden optreden. Op het moment van schrijven weten slechts 13 van de 54 antivirusdiensten van Googles Virustotal Linux.Encoder.1 in de kraag te vatten.

Update, dinsdag, 09:55: Inmiddels heeft BitDefender weten te achterhalen hoe de ransomware zijn sleutel genereert. Het bedrijf heeft een script gepubliceerd waarmee gebruikers gemakkelijk deze key kunnen laten achterhalen en hun bestanden kunnen ontsleutelen.

 

Afbeelding: Dr.Web

Reacties (105)

Het lijkt erop dat Bitdefender een decryption tool heeft vrijgegeven.

"Bitdefender is the first security vendor to release a decryption tool that automatically restores affected files to their original state. The tool determines the IV and the encryption key simply by analyzing the file, then performs the decryption, followed by permission fixing. If you can boot your compromised operating system, download the script and run it under the root user."

Meer informatie is hier te vinden:
http://labs.bitdefender.c...edictable-encryption-key/

Dit is best wel kritieke informatie die wat mij betreft in 't artikel geplaatst mag worden.

ik kan bevestigen dat ook wij als webhost, dit de afgelopen week ineens tegenkwamen op ubuntu servers van onze klanten.
Volgens 1 van onze beveiliginsexperts, kwam dit binnen door een geinfecteerde repo na een update/upgrade van het systeem.

Gewoon met apt-get update of upgrade

Blijkbaar zit er ergens een repo dwars, maar goed zoek maar uit welke
Alle versies zijn gelijk, ubuntu 12.04.5 server met daarover heen ubuntu desktop geinstalleerd.

Het is gewoon niet weg te krijgen trouwens, reinstall was nodig.
Ook meteen sources aangepast via source generator, dat bleek wel schoon.

We zijn druk bezig met het achterhalen hoe en wat, maar goed zoals eerder vermeld, zoek maar eens uit.

Erg vervelend allemaal

Edit: Ik hoor nu net dat het land heel veel verschil maakt voor de source.
US source blijkt dus hiermee te kampen, we gebruiken NL en daar geen last van.
Hoe en wat weet ik niet, niet mijn ding, maar een test machine kreeg met US source dit binnen en NL niet word hier geroepen. vaag

[Reactie gewijzigd door velenski op 10 november 2015 05:06]

Nu moet ik eerlijk bekennen niet zo heel bekend te zijn met Ubuntu en meer met RedHat bezig ben, maar ik neem wel aan dat je dan third-party repositories had ingeschakeld staan dan?

De normale repositories zeker vergelijken alles netjes met md5sum/shasum om te controleren of er geen malicious code meekomt in de update; of althans: dat de update hetzelfde is als de mirror hoort aan te bieden. Als dit afwijkt, dan wordt het discarded en wordt er opnieuw geprobeerd te downloaden uit een andere mirror. Dan zou er dus grootschalig heel veel Ubuntu servers geinfecteerd geraakt moeten zijn, maar daar lees ik dan eigenlijk weer helemaal niets over.

Daarom ben ik dus ook benieuwd:
1.) Third party repo, toevallig?
2.) Was het niet gewoon toeval dat er upgrades plaats hadden gevonden voor de hack, maar dat de attack vector eigenlijk iets heel anders was?

Kortom: vanwaar die zekerheid dat het uit een repo van Ubuntu zou hebben moeten komen?
Dat was wel opgevallen dunkt mij... Zeker omdat er dan een mismatch met de officiele software had moeten plaatsvinden.

dat is een juiste aanname.
voor bepaalde software hebben we 3rd party repos nodig namelijk anders installeert het niet vanwege dependencies.

het vreemde is dat het alleen source uit US betreft en dezelfde repos via NL binnengehaald, tonen de problemen niet.

Ik moet zeggen dat ik zelf niet erg thuis ben hierin maar onze expert staat verbluft van het feit dat het niet op NL sources gebeurt want uiteindelijk connect het naar dezelfde repo's
We zijn met leaseweb en dataplace gezamelijk een onderzoek gestart.

Het feit dat je Ubuntu desktop op een webserver installeert is natuurlijk als een veiligheidsrisico opzich.

betreft seedboxen, klanten hebbeb desktop nodig vaak, vandaar dat we dar bieden.

Met de sha1 hashes van http://vms.drweb.com/virus/?i=7704004&lng=en kun je clamav signatures maken. Ik heb nu dit gemaakt, maar zonder die werkelijke files is dat natuurlijk niet te testen. Iemand een idee of die ergens te vinden zijn?

Dit is de signature file voor clamav:

a5054babc853ec280f70a06cb090e05259ca1aa7:*:Linux.Encoder.1/x64_UPX:73
98e057a4755e89fbfda043eaca1ab072674a3154:*:Linux.Encoder.1/x64_unpacked:73
810806c3967e03f2fa2b9223d24ee0e3d42209d3:*:Linux.Encoder.1/x64_FreeBSD:73
12df5d886d43236582b57d036f84f078c15a14b0:*:Linux.Encoder.1/x86_UPX:73
5bd6b41aa29bd5ea1424a31dadd7c1cfb3e09616:*:Linux.Encoder.1/x86_unpacked:73

.. dat moet dan in een .hsb bestand zitten.

Wij scannen dan met modsecurity de http en ftp uploads en dan zou die binary er niet meer doorheen mogen komen.

[edit/toevoeging]

Op https://malwr.com/ kun je een sample file downloaden die aan de eerste sha1 hash matchet. ClamAV ziet deze met de bovenstaande signatures:

# clamdscan --fdpass /root/fd042b14ae659e420a15c3b7db25649d3b21d92c586fe8594f88c21ae6770956.bin
/root/fd042b14ae659e420a15c3b7db25649d3b21d92c586fe8594f88c21ae6770956.bin: Linux.Encoder.1/x64_UPX.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Infected files: 1
Time: 0.017 sec (0 m 0 s)

[Reactie gewijzigd door ISaFeeliN op 10 november 2015 10:05]

Enig idee hoe die ransomware toegang krijgt to de mappen van MySQL Server? Ik kan met inbeelden dat men toegang heeft tot de database (via MySQL, niet via filesystem) en tot de mappen waar de user waaronder het PHP/Webserver proces draait, maar als de hoster iets of wat zijn werk goed heeft gedaan, zou dat normaal gezien enkel een non-elevated user mogen zijn.

[Reactie gewijzigd door Tom C op 9 november 2015 20:21]

According to the security researchers, the ransomware in question needs root privileges to work.

bron:

https://thehackernews.com/

Wellicht voor sommige delen, maar niet alles. Ik heb deze malware zelf in actie gezien. Het start zichzelf op met het volgende commando:
./host encrypt publickey.pub /path/to/file

Ik vermoed dat /path/to/file het eerste bestand is dat het encrypt. Daarna gaat het verder onder de rechten van de gebruiker en versleuteld het vrijwel alle bestanden, inclusief mails, waar de malware de rechten toe heeft.

Verschillende Magento sites zijn getroffen, allemaal hadden ze de laatste patch van een week of 2 terug niet geinstalleerd - SUPPEE-6788

Maar toch als de server goed geconfigureerd staat zou het nooit verder moeten komen dan de bestanden van de user waaronder het draait. Als het goed is heeft mysql zijn eigen user waar je in principe nooit op inlogt. Ik ben ook erg benieuwd hoe deze malware de hele server langs gaat. Als hij het inderdaad voor elkaar krijgt om root te krijgen zonder user input dan kan je bijna spreken van dat de hele unix security omzeep is.

Anders dan dat kan ik niet anders concluderen dat jij je magento scripts als root laat draaien wat natuurlijk een big no no zou zijn!

[Reactie gewijzigd door ro8in op 9 november 2015 22:13]

Er zijn er zoveel die wordpress, magento, drupal en troep onder ROOT installeren..... Ik ontdekte het niet zo lang geleden nog dat een bedrijf zijn gehele wordpress ( ) omgeving had draaien onder root. CSF was hun ook onbekend ... ze wisten bij god niet hoe ze van die bruteforce aanvallen afkwamen.

Echt als je een eigen server in beheer neemt en het niet kunt managen zorg dan voor iemand die dat voor je kan en op een goede manier ook.

Een variant op linux webservers en straks Andriod of Ios is een kwestie van tijd.

Er zijn er zoveel die wordpress, magento, drupal en troep onder ROOT installeren..... I

Onder root installeren is geen probleem. Het laten draaien van de webserver onder root account wel. Ken alleen Drupal en die draait onder een webserver. Staat los van Drupal installatie zelf.

Het installeren onder root is wel degelijk een probleem.

Zeker voor het installeren van een script als Drupal is het nergens voor nodig om als root te werken. Je creëert alleen maar onnodig risico (ook al is die misschien erg klein). Drupal valt prima te installeren als user en moeten er bepaalde php modules etc bij geïnstalleerd worden kan je dat tijdelijk elevated als root doen met sudo.

Helaas lopen er heel veel ITers rond waarvan het voor de leek lijkt alsof ze heel veel kunnen, maar in werkelijkheid er geen bal van snappen. Vaak in dienst bij kleine maar soms ook grote offline bedrijven als systeembeheerder. Rommelen maar een beetje wat aan, de website is online en de PC's kunnen printen dus de baas is tevreden en vind het allemaal prachtig. Elke keer dat ik een vacature open heb staan krijg ik weer tientallen van dit soort jongens op bezoek. Bijna zorgwekkend soms hoeveel van dit soort jongens gewoon al in IT banen rond lopen zonder daadwerkelijk echt diepgaande kennis te bezitten.

Tja in de IT is het soms in het land der Binden is 1 Oog koning en dat beschrijf je hierboven.

Klopt helemaal! Bij ons in de klas snapte 8 van de 10 der niet veel van. Ze kregen herkansing na herkansing totdat ze net een voldoende hadden. Ik vind opzich wel grappig, dat bijna iedereen nu een baan heeft of aangenomen is bij HBO. Ik daarintegen zit nu nog zonder baan ookal heb ik de opleiding versneld afgerond.

Klopt helemaal. Op de servers waar ik het heb gezien betrof het alleen bestanden waar de gebruiker zelf ook de owner van was. Dus alleen /home/username/*

Met MySQL was ook niks aan de hand, voor zover ik kon zien ook geen bijzondere dingen in de database die in de Magento config zelf staat, al zijn backdoors altijd mogelijk - zoals bijvoorbeeld een extra admin user aanmaken die later alsnog misbruikt kan worden.

Klopt helemaal. Op de servers waar ik het heb gezien betrof het alleen bestanden waar de gebruiker zelf ook de owner van was. Dus alleen /home/username/*

De ransomware komt binnen via een webserver. Deze draait op zich toch in een omgeving/onder een gebruikersnaam waar niet veel mee gedaan kan worden (en waarbij vaak /home/{www-data,http}/ leeg is of niet bestaat)?

Met MySQL was ook niks aan de hand, voor zover ik kon zien ook geen bijzondere dingen in de database die in de Magento config zelf staat, al zijn backdoors altijd mogelijk - zoals bijvoorbeeld een extra admin user aanmaken die later alsnog misbruikt kan worden.

Op je webserver draaien toch geen applicaties die SQL rechten hebben hoger dan het strikt noodzakelijke? Een account met alle rechten ('root') aanmaken in MySQL zou toch alleen moeten kunnen met gebruikersaccounts die root rechten hebben?

Of je draait de MySQL-instantie lokaal en geeft het account waaronder websoftware draait rechten om hier direct mee te werken, wat volgens mij ook niet de bedoeling kan zijn.

[edit]
Ah, ik begrijp wat je bedoelt. Een extra Magento admin aanmaken. Daar moet je inderdaad voor opletten. Je kan natuurlijk ook een rollback van de database doen voor het moment van infectie. Dat is het voordeel van webapplicaties die alles via een database doen, mits goed beheerd.

[Reactie gewijzigd door The Zep Man op 10 november 2015 08:01]

Enig idee hoe die ransomware toegang krijgt to de mappen van MySQL Server?

• Wachtwoord verkrijgbaar via FTP, toegang via verkeerd ingestelde chroot etc;
• Via makkelijk te raden wachtwoorden, vooral van de root account.

En, niet te vergeten, sommige cms-en (in iedergeval wordpress) hebben vaak ftp toegang tot zichzelf. Lekker makkelijk voor updates he...

En, niet te vergeten, sommige cms-en (in iedergeval wordpress) hebben vaak ftp toegang tot zichzelf. Lekker makkelijk voor updates he...

Meer gemak = minder beveiliging (over het algemeen).

Maar leg dat maar eens uit aan de chef, als jij elke keer een uur bezig bent met de updates, en een collega kan het 'met een scriptje', maar moet dan wel de beveiliging uitzetten, hoeveel managers offeren er dan hun beveiliging op? Best wat denk ik, zeker als ze ook van hogerop gepushed worden om uren te besparen, want duur. Dat ze vergeten hoeveel een nare hack ze kost wordt ze vergeven totdat ie echt plaatsvindt.

Maar leg dat maar eens uit aan de chef, als jij elke keer een uur bezig bent met de updates, en een collega kan het 'met een scriptje', maar moet dan wel de beveiliging uitzetten, hoeveel managers offeren er dan hun beveiliging op? Best wat denk ik, zeker als ze ook van hogerop gepushed worden om uren te besparen, want duur.

Precies! Het kost zoveel moeite om leken daarvan te overtuigen. Niemand zegt "sleutels geven zoveel ongemak, en daarom ik heb mijn voordeur voor het gemak laten verwijderen". Met computers gebeurt dat wel. Misschien omdat software geen tastbare onderdelen bevat, dat leken niet direct een beeld kunnen vormen van de oorzaken / gevolgen? (afgezien van wat jij zegt over "duur")

[Reactie gewijzigd door Jael_Jablabla op 10 november 2015 09:21]

Hopelijk wordt die bewustwording iets groter als in 2016 de nieuwe wetgeving omtrent datalekken van toepassing wordt. Aangezien men dan ook beboet kan worden op grond van nalatigheid. Alles onder root installeren of zaken voor het gemak open zetten zouden uiteindelijk problemen kunnen opleveren.

Aangezien men dan ook beboet kan worden op grond van nalatigheid. Alles onder root installeren of zaken voor het gemak open zetten zouden uiteindelijk problemen kunnen opleveren.

Voor IT-ers zou dat vanzelfsprekend moeten zijn. Bij leken lijkt het me juist een probleem. Je kunt het meest veilige vliegtuig laten besturen door een papegaai en het zal niet goed aflopen. Kortom, eindgebruikers vormen een belangrijk deel van de veiligheid. Het probleem is dat eindgebruikers (leken) niet het belang inzien van de veiligheid: "HTTP of HTTPS, wat maakt het uit, het werkt toch allebei???" Een bosjesman heeft geen voordeur in zijn huis, en hij zal jouw voordeur (en huissleutels) daarom als een ongemak beschouwen. Dat is, naast nalatigheid door IT-ers, een lastiger probleem lijkt me

Haha, die lijst ik in.

Zorg dan iig wel dat je zwart-op-wit hebt, dat die manager al die beveiliging onzin vindt.

Kan je zijn/haar baas uitleggen hoe jouw baas tegen beveiliging aankijkt.

Of voorkom je ten minste in de toekomst discussie over wie de opdracht gegeven heeft.

Via makkelijk te raden wachtwoorden, vooral van de root account.

Dat is dus een reden waarom ik de root account uitschakel, een sterke wachtzin voor mezelf instel per gebruiker en alleen gebruik maak van sudo.

Tuurlijk, alles is te kraken, maar ik hou mezelf graag voor dat ik het zo wat moeilijker maar voor de gemiddelde "op goed geluk" hacker.

[...]
Tuurlijk, alles is te kraken, maar ik hou mezelf graag voor dat ik het zo wat moeilijker maar voor de gemiddelde "op goed geluk" hacker.

Het is minder gemak voor jou, maar komt de beveiliging wel ten goede.

Minder gemak niet hoor. "sudo su - " is niet veel anders, en als ik echt lui ben maak ik er een alias voor, meestal ssu of iets anders korts.

Als het altijd Magento is staan de database credentials gewoon in je local.xml en kan je daar je slag slaan met een simpele connector. Het is danwel (mag je hopen) niet de hele MySQL server, maar je eigen klanten / store data kan wel de sjaak zijn.

Daar heb je toch backups voor? Ook op een linux server zijn die nodig, al is het alleen al omdat de hardware waar het op draait de geest kan geven.
Volgens mij zijn encrypted bestanden niet anders dan disk corruptie. Geen probleem dus voor een degelijke sysadmin. Alleen prutsers ondervinden hier problemen van.

In tegenstelling tot hardware failure kan een virus natuurlijk wel een tijdje in je netwerk zitten alvorens het actief wordt - een tijdbom, laat ons zeggen. Zo'n delay zou ik in ieder geval inbouwen als ik een virus zou maken. Op dat moment zijn je backups ook niet helemaal meer te vertrouwen. Gesteld dat je dan nog met zekerheid kan stellen dat de backup van vorige maand nog niet besmet was, dan heb je nog het probleem van gigantische data loss over die periode (afhankelijk waar de DB voor dient). Oude backups zijn vooral goed om data op te vissen die achteraf nodig bleek, niet voor een gehele system restore (of het moet al een zeer statische DB zijn).

Een mod_security regel instellen om POST acties naar /skin/error.php te blokkeren schijnt al een behoorlijk eind te helpen om de Magento hacks tegen te gaan.

Volgens mij is dit ook meer een bug in de (op PHP draaiende) software, waarbij ze vervolgens gewoon een crypto aanroepen om de boel te overschrijven; dan dat het om een kwetsbaarheid in Linux gaat.
Goede beveiligingsregels, een niet al te brede PHP configuratie (en goed hardened), plus agressief ingestelde bestandspermissies moeten al een relatief hogere beveiliging bieden dan een standaard installatie... Maar mensen zijn vaak gewoon te lui om bestands- en database permissies goed in te stellen; terwijl het maar een erg kleine moeite is. Maarja, het is immers makkelijker als je er zelf altijd bij kan in plaats van dat je eventjes een wijziging moet uitvoeren voordat je via je browser allerlei shit kan aanpassen... Dat dit de zaak voor hackers die een lek vinden ook een stuk makkelijker maakt is louter bijzaak, blijkbaar.

De hoeveelheid mensen die alles rustig naar "everyone can write and execute!" instellen, nog altijd, is gewoon schokkend hoog.

[Reactie gewijzigd door WhatsappHack op 9 november 2015 22:36]

Om eerlijk te zijn, ik vind bestands- en databasepermissies nog best lastig. Heb 2 servers (VPS) draaien. Op de eerste is het afkloppen, op de tweede al een stuk meer gehardend.

Bestandspermissies is, als je het eenmaal doorhebt, niet lastig meer. Zie het als een optel som. Voorbeeldje:

De "Owner" van een bestand moet ergens bijkunenn. Alleen lezen en schrijven, maar niet uitvoeren.

• Lezen is 4
• Schrijven is 2
• Uitvoeren is 1

Dat komt dus neer op een 6 (4+2) voor de owner. Herhaal dit voor "Group" en "Other" en je bent er. Als je iets niet meegeeft/meerekent telt dat als 0, vandaar dat ik in mijn voorbeeld uitvoeren niet meegepakt hebt. Anders is het 4+2+0 = 6, dat maakt dus geen verschil.

Het is eigenlijk binary duidelijker
0100 lezen
0010 schrijven
0001 uitvoeren

0110 lezen en schrijven
Etc...

Nou, laat ik me verduidelijken: ik heb geen moeite met chmod, chown en chgroup en dergelijke .. meer of de gebruikers (server) niet te veel rechten hebben. Heb natuurlijk netjes handleidingen en tutorials gevolgd, maar je zult maar net (onbewust) die ene achter- of zijdeur hebben opengelaten ..

En hoe doe je dan iets simpels als:

GroupA: read&create files, geen modify en delete
GroupB: ReadOnly
UserC: Full Control

Volgens mij is dat niet helemaal mogelijk.. Tenzij GroupA ' iedereen' is, in iedergeval niet met de standaard mogelijkheden.

Om even een voorbeeldje te pakken: 755
7 = Owner (rwx)
5 = Group (rx)
5 = Everyone (rx)

Het kan, maar niet via standaard Unix permissies. Je moet dan een Access Control List (ACL) gebruiken, dat in moderne Linux-systemen standaard ook beschikbaar is. Hiermee kun je permissies instellen zoals SirBlade beschrijft, dus vergelijkbaar met hoe Windows het doet. Niet moeilijk om te begrijpen, maar nogal onzichtbaar omdat het bijv. in ls -la niet getoond wordt.

Indien nodig kun je nog ACL gebruiken. Je maakt het dan wel wat ingewikkelder mede omdat men er meestal geen ervaring mee heeft.
Access Control List (ACL) provides an additional, more flexible permission mechanism for file systems. It is designed to assist with UNIX file permissions.

Dat gaat niet met klassieke Unix permissies. Daar heb je ACL's voor nodig. Ik weet niet hoe het zit met de adoptie van ACL's in de rest van Linux land maar in Fedora/CentOS/RHEL word dat gedaan met SELinux. Ubuntu/Debian heeft daar AppArmor voor geloof ik?

Vergeet niet de mensen die dan ook nog eens vergeten een firewall in te stellen, geen veilig root wachtwoord hebben (dat je de root account sowieso al open hebt staan.. a la..) en niet iets als fail2ban hebben draaien..

Klopt, dat wordt vaak over het hoofd gezien; al moet daarbij wel opgemerkt worden dat een redelijke PHP beveiliging (ik bedoel... je hebt idioten die het zo opzetten dat users zelfs bij elkaars bestanden kunnen) en goede permissies je vaak een stuk verder brengen dan de firewall an sich; de meeste hacks vinden plaats door achteloze PHP configuraties, brakke *** scripts en daarbij veels te ruim ingestelde permissies; al heb je tig firewalls maakt dat nog steeds weinig verschil. (Noot: daarmee wil ik absoluut NIET zeggen dat de firewall overbodig is, trouwens )

En dan te bedenken dat veelgebruikte scripts, zoals Wordpress, je zelfs uitgebreid uitleggen WAT je moet instellen en HOE je dat moet instellen om al een behoorlijk stuk veiliger te zijn dan de default configuratie. (http://codex.wordpress.org/Hardening_WordPress)
Men is te lui om te lezen, en om toe te passen. Of denken meteen al "dit gaat mij boven de pet", terwijl eigenlijk iedereen het kan met minimal effort.

Voor fail2ban valt in sommige productie omgevingen nog iets te zeggen over het niet aanwezig hebben daarvan trouwens, gezien al deze producten (fail2ban, LFD, BFD, etc.) allemaal last hebben van de self-DoS bugs; waarbij je met behoorlijk gemak via een lek PHP script (zoals in dit geval Magento dus ) log entries kan wegschrijven via de cron voorzieningen, waardoor de server alle IP reeksen in de ban lijst gooit; of in iedergeval een groot gedeelte; of zelfs zichzelf kan bannen of de database server (indien extern). Er zijn configuraties te bouwen waardoor brute-force aanvallen eigenlijk totaal geen nut hebben, en f2b dus relatief niet zo heel veel toegevoegde waarde meer heeft; maar je wel beveiligd bent tegen klootza... ehh... poeslieve script kindertjes die het voor elkaar krijgen om die brute-force detectors een loer te draaien en de server op die manier om zeep te helpen.

... MAARRRR ... over het algemeen ben ik het er absoluut wel mee eens dat het risico op dat soort aanvallen op dit moment nog behoorlijk klein is, en het wijzer is om het wél te gebruiken dan niet voor 99% van de doe-het-zelf admins met niet veel ervaring op dit gebied; ondanks dit kleine window of opportunity om de boel te verklooien. (En natuurlijk is het dan ook relatief simpel en snel opgelost )
En gelukkig zijn daar nog de whitelist > blacklist beveiligingen en "limit ban entries".
Het is dus zeker waar dat de meeste mensen met een VPSje oid het beter wel kunnen installeren dan niet, voor zowel hun eigen veiligheid als dat van eventuele (mede-)gebruikers.

Het blijft altijd een kat en muis spelletje tussen de beheerder, een serieuze hacker, en de eikeltjes die gewoon voor de lol de boel (tijdelijk) willen mollen (al dan niet met grove schade).
De balans zoeken is vaak lastig, dat geef ik snel toe; maar het probleem is gewoon dat 9 van de 10 mensen gewoon niet eens de moeite nemen om ook maar de helft van de best practices te volgen (want niet alle "best practices" zijn bruikbaar in alle situaties, dat moge duidelijk zijn.)...
Dan moeten ze eigenlijk ook niet al te hard klagen als ze alles kwijt zijn, al helemaal niet als ze geen back-ups maken.

Goede configuratie, goede basis-hardening, je permissies (zowel database user als bestanden) regelen, een basis firewall en back-ups... En nog eens back-ups.
Dat scheelt al zo enorm veel leed tegen zeer weinig moeite... Maar men is vaak te lui.

/skin/error.php? Een file die niet bestaat en schijnt te helpen tegen Magento hacks? Bron?

Dat is inderdaad geen officiele Magento file, maar een common file die door de hackers wordt geupload. Door deze te blokkeren ontstaan er problemen. Veel van die hacks gebeuren namelijk geautomatiseerd door een botnet, niet hoogstpersoonlijk door de krakers.
Zoek maar eens op: "skin/error.php" + Magento in Google. Dan krijg je er wat meer informatie over.

https://support.hypernode...er-a-hacked-magento-shop/
http://forum.kaspersky.co...on/index.php/t332205.html
https://www.virustotal.co.../141.0.23.18/information/ (Random, trouwens.)

Et cetera.

Zo te horen heeft de ransomware root toegang tot de gehele machine nodig. Dat is dus een gevalletje "geen enkel systeem is bestand tegen domme mensen". Bij een beheerder die weet waar hij mee bezig is zou de ransomware geen bodem mogen kunnen krijgen.

[Reactie gewijzigd door Amanoo op 9 november 2015 23:50]

Nee, dat is incorrect.
Toegang tot de user account (bijvoorbeeld via een brak PHP script) is al voldoende om alle bestanden (en databases gelinked aan dat account) geheel te encrypten. Als er dan geen back-ups zijn, heb je een behoorlijk groot probleem...

Dat de rest van de server/ander accounts op die server er dan niet per definitie last van ondervinden, betekend niet dat het alsnog een mega probleem is voor de mensen die er wel mee te maken krijgen; en lang niet altijd door eigen schuld. (Behalve het niet hebben van een back-up dan, dat is wel je eigen probleem... Tenzij je backups beloofd zijn en die niet gemaakt blijken te zijn oid; maar dan nog. Never trust a third party )

Het is dus zeker wel een probleem, en die ransomware is steeds lucratiever.
Moet je je voorstellen dat een site als tweakers.net opeens getroffen wordt door zo'n cryptolocker.
Tweakers heeft waarschijnlijk een heel scala aan backups liggen, dus kan wel recoveren: maar dat zal waarschijnlijk niet binnen slechts een paar minuutjes geregeld zijn (zeker niet als ze niet opnieuw de hacker een kans willen geven; en dus eerst even moeten uitzoeken wat er precies gebeurd is.); en dat kost een godsvermogen aan (advertentie-)inkomsten.

Root toegang is dus zeker geen vereiste. Root toegang is natuurlijk wel het grootste probleem, want dan kan je de hele PC/server encrypten. Maar op user-level toegang verkrijgen, al is het via een lek scriptje, is wel degelijk een groeiend probleem, en houdt dagelijks sysadmins bezig om te proberen te voorkomen dat lekken in populaire website scripts worden misbruikt.

Begrijp me niet verkeerd, maar ik vraag me dan wel af hoe jij aan de tag 'Beheer en Veiligheid' komt.
Maar zou je mij eens willen uitleggen hoe je, op een goed geconfigureerde server, als webuser een database wil gaan encrypten? Want dat lijkt me dus nogal onmogelijk.

Tja, als je al met jests wil beginnen: dat is dan waarschijnlijk ook de reden dat ik die tag heb, en jij niet.

Natuurlijk is dat niet onmogelijk, maar zelfs relatief simpel.
De meeste sites die gehacked worden draaien op PHP en mySQL. En de meeste mensen zijn te lui om te zorgen dat de database user zo is ingesteld dat hij niet meer *ALL* privileges heeft. (En eerlijk is eerlijk: daar wordt eigenlijk ook bijna nooit voor gewaarschuwd; en is vaak zelfs standaard gedrag bij control panels.) Na installatie zijn all privileges totale onzin, en eigenlijk gewoon een veiligheidslek; een soort van garantie dat er mee geklooid kan worden als iemand toegang weet te krijgen. Maar gezien 9 van de 10 gebruikers niet eens weten dat dit een probleem is, blijft het lekker zo geconfigureerd staan. En geen hond die de gebruiksaanwijzing leest natuurlijk, want er zijn best een aantal CMS/forum/gallery's, etc. die gewoon netjes in de handleiding zetten wat je na installatie moet doen. Al is dat ook een deel luiheid, want dan moet je bij een update/upgrade die database wijzigingen moet uitvoeren wel weer meer privileges toekennen. En stel je voor dat je even 1 minuutje daarvoor moet uittrekken...

Anyway, nu krijgt de hacker toegang tot het user account via een lek in een PHP bestandje. Hij bekijkt de files even en vind iets als een "*-config.php" or "settings.php". Hier staan uiteraard netjes de database credentials in, dus de databasenaam, en de gebruikersnaam en het wachtwoord om toegang te krijgen tot de db. Zo werkt dat.
Vervolgens kan de hacker dus prima op meerdere manieren de database encrypten... Door door de entries heen te loopen en on the fly te encrypten, of door een dump te maken van de database, vervolgens de tabellen te droppen, de data in de dump encrypten en die weer terugzetten naar de database, et cetera. Tal van opties! En natuurlijk wordt het des te simpeler om hier vooraf al iets voor te programmeren voor de populaire scripts; zoals wordpress, zoals Magento, zoals phpBB, et cetera: de database structuur is altijd hetzelfde; dus dat is vooraf allemaal te programmeren.
Hierna worden voor good measure dus ook even alle bestanden van de gebruiker encrypt, en voila... Bestanden + database zijn cryptolocked.

Het is niet verre van onmogelijk, het is zelfs kinderspel.
Ik weet niet waarom jij denkt dat het op de een of andere manier moeilijker is om een database te encrypten dan om normale bestanden te encrypten; zolang er lees/schrijf rechten zijn is een database niets anders dan bestanden die op een bepaalde manier opgeslagen zijn... En dus is encryptie prima mogelijk.

Afhankelijk van de server configuratie zal het op de ene server wat sneller te encrypten zijn dan de ander, en zal je op de ene server wat omslachtiger te werk moeten gaan dan de ander; maar gezien van vele sites die gehacked worden de database nogal klein is, blijft het binnen een paar minuutjes te fixen.

Het heeft niets met een goed of slecht geconfigureerde server te maken, maar het valt en staat bij de luiheid of juist de inzet van de gebruiker; en hoe die permissies instelt voor zowel de bestanden alsmede de database gebruiker.

[Reactie gewijzigd door WhatsappHack op 10 november 2015 18:38]

Hoewel je in principe gelijk heb zou ik het encrypten van velden in records in een bestaande database toch ook weer geen kinderspel noemen. Zoals het artikel aangeeft wordt data versleuteld middels AES-CBC-128 hetgeen een binary string oplevert. Om bestaande data correct en betrouwbaar op te slaan zul je dus de veldtypes moeten aanpassen van bijv. VARCHAR naar VARBINARY of TEXT naar BLOB.

Tevens dient ook rekening gehouden te worden met de mogelijkheid dat de encrypted string wel eens langer zou kunnen zijn dan de unencrypted string waardoor je de veldlengte mogelijk ook nog moet verhogen.

Deze acties moet je dan ook ergens loggen om ze te kunnen reversen op het moment dat het slachtoffer over zou gaan tot betaling. Maar goed, als crimineel zijnde zou je die stap natuurlijk achterwege kunnen laten.

In geval van standaard databases zoals die van een stock Drupal of Wordpress zou je veel van die conversies al kunnen voorzien weliswaar.
Als je dit afzet ten opzichte van het encrypten van een simpele file, dan lijkt me een correcte db encryptie (zeker van non-standaard databases) toch wel wat bewerkelijker.

Zeker, dat klopt.
Een stuk snellere, en eigenlijk ook betrouwbaardere, actie is dan ook gewoon de tweede methode die ik noemde in mijn reactie aan Civilian: dump de database, encrypt de dump, drop de database (of sloop de tabellen (drop/delete/truncate)) -> geef decryptie sleutel voor de dump zodat de database weer in ere hersteld kan worden.
Volledige cyclus is dan, indien betaald is voor decryptie:
dump, encrypt, drop -> decrypt, restore.

Maar in het geval van de meeste van die standaard scripts is het vaak helaas wel mogelijk om het gewoon on the fly te doen in de database zelf als er wat limitaties aanwezig zijn (zoals correct dumpen...). Zeker als je bijvoorbeeld te maken hebt met troep als WooCommerce; die propt sowieso al zo gigantisch veel data op de meest belachelijke plekken in enorme getalen; in principe maakt de encryptie dan vaak geen verschil voor de toegestane velden.
Maar je hebt gelijk, het is zeker niet altijd even makkelijk om het in de database zelf te doen. (Al heeft dat dan weer weinig te maken met de server configuratie in de zin hoe Civilian het bedoelt)

Ook kan het voor de hacker interessant zijn, mits een dump maken niet goed lukt, om slechts enkele cruciale delen van de database te encrypten in de database zelf; zoals besteldata van klanten als we het over webshops hebben, de complete inventory, et cetera. Dat zijn vaak behoorlijk grote velden, en zeker gebruikersgegevens zijn vaak al geschikt om encrypted data in op te slaan... Maar wel cruciale gegevens voor de beheerder. Dat dan niet de gehele database encrypt kan worden zal de hacker een worst zijn zolang de beheerder alsnog sterk geneigd zal zijn om te betalen om zijn meest cruciale database gegevens terug boven water te krijgen.


Het risico wat er echter aan vast zit met de dump methode is dat de dump, na encryptie, niet te herstellen valt; bijvoorbeeld doordat er een time-out was tijdens het dumpen ervan (al is dat ook weer om te omzeilen, het staat en valt met de hoeveelheid tijd die de hacker heeft; en hoe groot de database is. (na dump)) waardoor de dump nooit afgemaakt is. Dit is natuurlijk weer af te vangen door op foutmeldingen te controleren en het gebruik van methodes als bigdump, maar het wordt wel steeds complexer...
Niet dat de methode van on the fly in de database zelf zonder risico is natuurlijk, dat is nagenoeg waarschijnlijk een nog groter risico.
Anyway, de pest is dat er grof geld te verdienen valt, dus als ze extra kunnen vangen als ze ook databases "betrouwbaar" kunnen encrypten op zo'n manier: dan doen ze het. (Er zijn ook al gevallen bekend waarop het gebeurt is op de omschreven manier (dump, encrypt, drop)).

Of dat niet kunnen herstellen een crimineel zal boeien is nog maar de vraag natuurlijk, al is het vaak wel zo dat deze criminelen euhh... "Betrouwbaar" zijn. Ik zou ze bijna ethisch noemen.
Dat wil zeggen dat ze namelijk wél in 9 van de 10 gevallen na betaling ook inderdaad netjes de sleuteltjes overhandigen... In dat geval moet het natuurlijk wel zo zijn dat de integriteit van de bestanden, én de database, niet geschaad wordt...

Maar eerlijk is eerlijk, het is makkelijker om de dump te encrypten en de database vervolgens te droppen (of alle tabellen erin) dan om de database te encrypten *in de database zelf*. Helemaal mee eens.
Voor zover ik kan zien is dat in de gevallen waar databases encrypted zijn ook de gebruikte methode, en logisch ook: simpeler, doeltreffender en algeheel eigenlijk ook gewoon "veiliger".

Het scheelt een vermogen aan coding werk en compatibiliteit controles door het op deze manier te doen, en is in principe universeel inzetbaar op zo'n beetje elke database lay-out... Door de dump te encrypten zit je niet meer aan de limitaties van SQL zelf vast, maar is het gewoon "yet another file".
M'n complexere uitleg over wat *zou kunnen* (in de database zelf encrypten) was ook meer een voorbeeld van op welke manier dat kan, dan dat dit ook daadwerkelijk toegepast wordt. "In the field" zal je veel vaker zien dat er een encrypted dump is en je originele database gewoon gedropped is, dan dat je een database in je SQL server vindt die geheel encrypt is binnen de database zelf.

M'n punt was enkel dat het prima mogelijk is, en dat dit niet staat of valt bij een "goede server configuratie". Beide manieren die ik heb omschreven zijn mogelijk (dus zowel de lekker simpele manier alsmede de zeer complexe manier), zelfs op goed ingestelde/geconfigureerde servers!, zolang de gebruiker maar ALL privileges nog heeft ingesteld op de gebruiker... En helaas is dat bij het overgrote merendeel van die websites het geval, waardoor beide beschreven methodes inzetbaar zijn: ongeacht een prima server configuratie! (Die doet immers prima wat ie moet doen...)
Het ligt uiteindelijk aan de hacker hoeveel geld ie er aan denkt te kunnen verdienen; en dus hoeveel tijd hij er in wilt steken.

[Reactie gewijzigd door WhatsappHack op 11 november 2015 06:16]

Een van onze klanten was afgelopen week het haasje, maar dan door mallware op zijn pc.
Een telefoontje naar ons was genoeg voor de website. backups gecheckt (in orde) en direct rollback gedaan.
30 min na de actie was de site weer in de lucht

[Reactie gewijzigd door hackerhater op 10 november 2015 11:23]

Dus eigenlijk wordt er gebruik gemaakt van een lek in Magento?

Ik vraag mij dan af hoe /var/lib/mysql dan kan worden geencrypt aangezien apache daar niet standaard rechten op heeft.

Zodra de ransomware met beheerdersrechten kan starten zal die onder andere een bestand met instructies voor het slachtoffer downloaden en de bestanden versleutelen.

https://www.security.nl/p...wit+van+nieuwe+ransomware

De meeste servers zijn veilig, tenzij je hebt zitten klooien met je root logins.

[Reactie gewijzigd door DJMaze op 9 november 2015 20:29]

Ik interpreteer dit meer als dat webbestanden de rechten hebben om andere bestanden te wijzigen. Dat kan tegenwoordig steeds meer bij normale shared hosting, en heeft juist voordelen zodat CMSen zichzelf kunnen updaten en uploads kunnen verwerken zonder dat mappen individueel berecht hoeven te worden.

Het nadeel daar van is in dit geval dan dat alle bestanden verwijderd/geencrypt kunnen worden (binnen de eigen user), maar dat weegt in mijn optiek niet op tegen de voordelen. Als er een lek zit is de kans groot dat je sowieso al de sjaak bent. Verder gewoon goed backuppen en er hoeft niets aan de hand te zijn.

Onder andere de mappen voor MySQL-servers

Als je wat van GNU/Linux snapt, dan begrijp je dat de ransomware dat helemaal niet kan als "user".
Het artikel is onduidelijk en dan is de opmerking die jij maakt logisch, maar niet toepasbaar op deze ransomeware.

Ik kreeg toevallig een case van deze ransomware mee vorige week, hierbij waren slechts de public_html bestanden onder 1 user geëncrypt en was MySQL ongedeerd.

Het stukje over MySQL had ik net nog niet gezien, ik vermoed dat er simpelweg gekeken wordt welke rechten men heeft en roeit vervolgens met de riemen die men heeft. Of er lopen meerdere automatische bots van deze groep waarbij er een light versie webshops afstruint, je kan van alles bedenken.

[...]
Als je wat van GNU/Linux snapt, dan begrijp je dat de ransomware dat helemaal niet kan als "user".

Waarom zou een ransomware met root rechten dat niet kunnen? Ik zie in logboeken dat er met root wordt geprobeerd in te loggen. Als dat wachtwoord gekraakt wordt, dan is de webserver toch ook kwetsbaar?

Als je login as root toestaat, dan vraag je om problemen.

Als je login as root toestaat, dan vraag je om problemen.

Feit is dat het gebeurt.

Tja, FreeBSD heeft dat standaard uitstaan, en het 'su' commando is alleen maar beschikbaar voor users die lid zijn van de group 'wheel'.

Ik verbaas me altijd over de lakse default instellingen van de meeste Linux distro's. (En het gebrek aan interesse/kennis(?) van mensen om hier wat aan te doen voordat ze een machine aan het internet hangen).

Welke, excuus de krachtterm, prutser/beun de haas heeft er dan ook een open root account en niet iets als fail2ban draaien op zijn/haar/de baas z'n servers? Dan verdien je het (overdreven natuurlijk, beeldspraak) om hier last van te krijgen..

@DJMaze geeft aan dat het niet kan als user-level, jij hebt het over root.

@DJMaze geeft aan dat het niet kan als user-level, jij hebt het over root.

Iemand met rootrechten kan ook inloggen als user. Of zie ik iets over het hoofd?

Mijn relaas ging over hoe bestanden op user level geëncrypt worden, terwijl er daarvoor gesproken werd over de /var/lib/mysql map die werd geëncrypt, wat in principe niet kan op user level. Ik had dat gedeelte niet gezien, vandaar het misverstand. Wat ik in ieder geval tot nu toe bij elkaar kan leggen is dat er vanuit meerdere vormen geëxploiteerd wordt: vanuit user en vanuit root.

Als je als user inlogt heb je geen root rechten, het security model steekt wat dat betreft anders in elkaar. (ga ik er voor het gemak even vanuit dat er niet geknoeid wordt/is met het systeem en dat een reguliere user geen id 0 heeft)
Als je inlogt als user heb je normaal gesproken de daarbij horende rechten en dat zijn geen root rechten.

Een iets of wat goed geïnstalleerde webserver heeft sowieso geen toegang tot bestanden van andere services. In het ergste geval zouden dus alleen bestanden van de webserver geïmpacteerd mogen zijn, en die zijn eenvoudig van backup terug te halen of opnieuw te deployen.

Indien goed ingericht zelfs alleen de bestanden van die specifieke website.

En als dat Magento op Windows Server draait kan dan toch ook de boel encrypten?
Beetje aparte titel dan.

Waarschijnlijk zal de ransomware zich specifiek op Linux omgevingen richten (bv. bepaalde CLI tools die gebruikt worden om te encypten), omdat de kans dat een Magento nu eenmaal op Linux draait veel groter is dan Windows. Het idee kan uiteraard perfect op Windows worden toegepast ook.

[Reactie gewijzigd door Tom C op 9 november 2015 20:33]

Ik snap even niet wat dit met Linux te maken heeft. Volgens mij zijn magento installaties vatbaar voor deze ongein, en niet de server zelf.
Daarnaast wordt er gesuggereerd dat de hosted verantwoordelijk is, iets wat volgens mij een taak is voor de klant.
Misschien een idee om de titel aan te passen, zodat niet iedere systeembeheerder zich een hoedje schikt.

Gaat niet alleen om Magento. Alleen in het voorbeeld van Krebs. heb het stukje helemaal weggehaald, gaat in wezen niet daarom.