Webserver gehacked

[sweebee]

Ten eerste, het is niet mijn server. Ik heb enkel een webapplicatie geschreven die op de server draait.

Dus op een server waar ik een applicatie voor had gemaakt is gehacked. Ze hadden toegang tot alle bestanden. Ze hadden in eerste instantie de link naar de betaalprovider aangepast. Nadat we hier achter kwamen en we alle wachtwoorden hebben aangepast, en de bestanden hebben terug gezet zijn ineens bepaalde mappen verwijderd en is er op de index pagina de volgende tekst geplaatst:

We have taken overyour whole server including ALL PERSONAL USER DATA. Contact *** to negotiatie. No contact or contact with police = Publish ALL website DATA + USER DATA. Proof: ... (db wachtwoorden ed).

Mijn vraag, hoe kunnen ze binnen gekomen zijn? Kan dit een fout van mij zijn? Op de databases staan klantgegevens (naam, email, gehashte wachtwoorden).

Kunnen ze alleen via ftp binnenkomen? Of ook op een andere manier.

[gambieter]

Zal moeilijk te zeggen zijn zonder informatie. Welk OK, software, wat staat er open, is alles up to date, enzovoort

[Fish]

Bij gebrek aan details kan dat op vele manieren gebeurt zijn

Dit kan een fout nijn van jou ja. maar ook ven de netwerkbeheerder, of degene die de server onderhoud, of het platform waar je webapplicatie draaid of je os en updates. verkeerde rechten op je db. toegang van buitenaf. sql injectie. weet ik veel zomaar een paar suggesties

[Daos]

Sowieso wel naar de politie gaan. Misschien kan in samenwerking met hun de daders in de val gelokt worden.

[sweebee]

De webapplicatie draait op PHP. De server weet ik verder niks over, behalve dat die draait bij heart internet.

Enige waar ik toegang tot had was de ftp server om bestanden naar te uploaden, en het controlpanel van heart internet om databases aan te maken.

De politie is inmiddels ingelicht.

[sweebee]

Er stond ook een wordpress site op de server, via de apache log vond ik het volgende:

code:

/wp-includes/data1.php?act=sql&sql_login=XXX&sql_passwd=XXX%5E/Ks&sql_server=10.16.16.12&sql_port=3306

/wp-includes/data1.php?act=ls&d=%2Fhome%2Fcluster-sites%2F5512%2Fb%2Fvcxvcxvxc&sort=0a

[AW_Bos]

Klinkt als een PHP-shell (data1.php) die op een manier geupload is, en vervolgens uitgevoerd is. Verwijder deze direct, en probeer uit te zoeken hoe deze geupload is. Ik vermoed dat je een lekke plug-in hebt.

Als er wachtwoorden van gebruikers in de data staan, reset deze direct en laat de gebruikers een nieuw wachtwoord nemen. Licht dan ook even de ACM in.

[ Voor 14% gewijzigd door AW_Bos op 05-09-2016 00:59 ]

[Wim-Bart]

sweebee schreef op maandag 05 september 2016 @ 00:52:
Er stond ook een wordpress site op de server, via de apache log vond ik het volgende:

code:

/wp-includes/data1.php?act=sql&sql_login=XXX&sql_passwd=XXX%5E/Ks&sql_server=10.16.16.12&sql_port=3306

/wp-includes/data1.php?act=ls&d=%2Fhome%2Fcluster-sites%2F5512%2Fb%2Fvcxvcxvxc&sort=0a

Ja, ze zijn via Wordpress binnengekomen en hebben zo de rest ontdekt. Reden te meer om nooit Wordpress en Joomla sites met andere sites te mixen als je geen actief patch beleid hebt en bijna dagelijks je logs bekijkt op rare zaken.

[Verwijderd]

Ok, 1 vraag; welke versie PHP heb of had je op de server?

Vraag 2: stond de wordpress site als ROOT zijnde geinstalleerd of als user?

Vraag 3: waarom heb je geen beveiliging op je wordpress site gehad (Malafide uploads, etc) zie wordfence

Niet om het een of ander, maar dit had eenvoudig voorkomen worden als 1, 2 en 3 op orde was. Het is makkelijk de vinger te wijzen naar iemand die een applicatie heeft geschreven, terwijl ik mijn vraagtekens stel bij 1, 2 & 3.

Is daar bewijs van dat de exploit te wijten was aan jouw applicatie? Sorry maar ik zie voldoende "website" bouwers volledig de bocht omgaan met een verkeerde configuratie en beveiliging van zowel server als wordpres zelf, en dan de vinger op een andere partij (vaak genoeg) leggen.

Stel altijd m'n vragen als je welke willekeurige website dan ook op basis van wordpress in elkaar gaat drukken daar waar betaalgegevens en dergelijk in omgaan. Wordpress is te risicovol omdat met regelmaat exploits en zelfs tegen betaling ongekende wordpress exploits in omloop zijn.

Elke debiel met een beetje kennis kan relatief makkelijk een exploit in een plugin vinden. Het is ook makkelijk te checken welke plugins een wordpress site draait. En sterker zelfs mensen weigeren of zijn zelfs blind voor het updaten van hun wordpress core iedere keer. Ik volg dat niet.

Ik bouw meerdere jaren websites en heb nog geen 1 site gehacked zien worden, omdat configuratie, basis en methode gewoon het allerbelangrijkste is. Ga geen site met betaalgegevens op wordpress zetten, zeker niet op verouderde PHP, zonder security (op wordpress of server niveau) draaien. Dat is vragen om problemen.

[ Voor 35% gewijzigd door Verwijderd op 05-09-2016 05:22 ]

[Jester-NL]

De eerste vraag die ik heb op basis van de titel is inderdaad: is de server gehackt, of alleen het stukje shared hosting waar jou applicaties draait?
Het eerste zie ik niet heel gauw gebeuren (hosters zorgen er wel voor dat ze daar niet zomaar last van hebben)... het tweede is schering en inslag, en de verantwoording van de eigenaar van dat stukje van de server. En de meeste webhosting-pakketten hebben aandacht nodig.

Sowieso... ik zie dat er met Wordpress gewerkt wordt. WP is populair, niet alleen bij website-bouwers, maar ook bij hackers. Het is (vreselijk) van belang om dat up-to-date te houden. En (hou aanlokkelijk ook) gebruik geen plugins die uit het donkergrijze circuit komen...
Dus... NIET via een torrent een plugin of een thema aanschaffen, maar als het geld kost, moet je dat ook gewoon betalen. Die donkergrijze varianten komen vaak zonder updates (en met extra toegangsrechten(??))

[Verwijderd]

Indien het de volledige server is kan het ook zijn dat ze via ftp binnengeraakt zijn.
Ik weet dat er vroeger wel wat virusen de ronde deden die inloggegevens van bv Filezilla targeten.

[Blankinho]

Tot op heden vind ik de informatie van TS nogal summier. Ik kan me voorstellen dat TS op dit moment nog erg druk is met uitzoeken ipv met ons te delen? Doorgaans gebeurd een hack door slecht patchbeheer, verlies van gebruikersgegevens, openstaande poorten naar het internet toe welke vervolgens niet goed zijn beveiligd en gemonitord. Hieronder heb ik een korte opsomming van mogelijke hack ingangen.

Netwerktoegang:
- FTP, SSH, TELNET(hoop het niet) of een andere poort/applicatie die openstaat naar de betreffende webserver in combinatie met slecht passwordbeheer/complexiteit.

Applicatietoegang:
Hierover zijn in bovenstaande reacties al voldoende zaken gezegd met aanzien van Joomla en andere rechten voor applicaties op het besturingssysteem.

Menselijke fout:
Verkeerde configuratie, username en wachtwoordcombinaties voor veel verschillende websites etc gebruiken, etc etc.

Fysieketoegang:
Aangezien de server bij een hostingprovider staat doe ik de aanname dat de fysieke beveiliging oke is en dat niet zomaar iemand een USB-stick kan laden.

[emnich]

Blankinho schreef op maandag 05 september 2016 @ 08:53:
Tot op heden vind ik de informatie van TS nogal summier. Ik kan me voorstellen dat TS op dit moment nog erg druk is met uitzoeken ipv met ons te delen? Doorgaans gebeurd een hack door slecht patchbeheer, verlies van gebruikersgegevens, openstaande poorten naar het internet toe welke vervolgens niet goed zijn beveiligd en gemonitord. Hieronder heb ik een korte opsomming van mogelijke hack ingangen.

Netwerktoegang:
- FTP, SSH, TELNET(hoop het niet) of een andere poort/applicatie die openstaat naar de betreffende webserver in combinatie met slecht passwordbeheer/complexiteit.

Applicatietoegang:
Hierover zijn in bovenstaande reacties al voldoende zaken gezegd met aanzien van Joomla en andere rechten voor applicaties op het besturingssysteem.

Menselijke fout:
Verkeerde configuratie, username en wachtwoordcombinaties voor veel verschillende websites etc gebruiken, etc etc.

Fysieketoegang:
Aangezien de server bij een hostingprovider staat doe ik de aanname dat de fysieke beveiliging oke is en dat niet zomaar iemand een USB-stick kan laden.

Hoewel het allemaal kan is het meest logische scenario dat ze via Wordpress binnengekomen zijn. Als ze op een andere manier (FTP, SSH, fysiek, etc) toegang hadden dan hoefden ze niet te stuntelen met de wp-includes.

Verder no-offense voor TS maar als je een webapplicatie hebt gemaakt en je afvraagt of ze ook op andere manier binnen kunnen komen dan via FTP dan denk ik dat je eerst verder moet gaan leren of een ander vak moet kiezen.

[Felicia]

sweebee schreef op zondag 04 september 2016 @ 21:30:
Ten eerste, het is niet mijn server. Ik heb enkel een webapplicatie geschreven die op de server draait.

Dus op een server waar ik een applicatie voor had gemaakt is gehacked. Ze hadden toegang tot alle bestanden. Ze hadden in eerste instantie de link naar de betaalprovider aangepast. Nadat we hier achter kwamen en we alle wachtwoorden hebben aangepast, en de bestanden hebben terug gezet zijn ineens bepaalde mappen verwijderd en is er op de index pagina de volgende tekst geplaatst:

We have taken overyour whole server including ALL PERSONAL USER DATA. Contact *** to negotiatie. No contact or contact with police = Publish ALL website DATA + USER DATA. Proof: ... (db wachtwoorden ed).

Mijn vraag, hoe kunnen ze binnen gekomen zijn? Kan dit een fout van mij zijn? Op de databases staan klantgegevens (naam, email, gehashte wachtwoorden).

Kunnen ze alleen via ftp binnenkomen? Of ook op een andere manier.

Zonder al te veel in te gaan op het hoe lijkt me dat bovenstaande server direct van het internet afgekoppeld moet worden i.v.m. bewijsvoering. Daarnaast lijkt me dit een datalek welke volgens de nieuwe wetgeving gemeld moet worden (je hebt het over een betaalprovider dus mogelijk zijn er ook klantgegevens buitgemaakt)!

[sweebee]

Sorry voor de weinige informatie, het is voor mij ook gissen omdat ik ook bijna nergens in kan kijken. Het betreffende hosting bedrijf heeft apache logs gestuurd en hier is in te zien dat er 1 ip elke keer van alles uitvoert via het bestand in de wp_includes. Natuurlijk via een proxy. Ik heb zelf ook geen contact met het hosting bedrijf, alles gaat weer via het (web)bedrijf waarvoor ik toen die applicatie gemaakt heb.

De php versie die draait is 5.4.45.

De user heeft alleen toegang tot de root folder van de desbetreffende domeinnaam (public_html).

Ik heb verder zelf ook niets van doen met de wordpress website, die is geïnstalleerd door het (web)bedrijf waar ik dus die applicatie voor gemaakt heb. Wel kon ik zien dat deze wp site draaide met een template van Avada, en had tientallen plugins geïnstalleerd.

Ook heeft het (web)bedrijf uit paniek alle bestanden van de server verwijderd. Het hosting bedrijf heeft wel een backup van 1 september gestuurd. Dus inzage in het data1.php heb ik ook niet. Wel is het hosting bedrijf het een en ander nog aan het uitzoeken, ze geven zelf al aan dat de kans heel groot is dat het een wordpress plugin was. De ftp hebben ze al uitgezocht en hier is niets in te vinden.

Lijkt er tot nu toe op dat het niet mijn fout is. Al werd de fout wel snel naar mij verschoven.

[ Voor 6% gewijzigd door sweebee op 05-09-2016 10:17 ]

[hackerhater]

Euhm sweebee,
Zoek per direct een andere webhoster.
PHP 5.4 is zwaar verouderd en niet meer ondersteund.
Als ze nog 5.4 draaien zal de host zelf en apache ook wel verouderd zijn.
Vatbaar voor poodle ed.

Grote kans dat ze binnen zijn gekomen door een verouderde WP-site (welbekend probleem), maar die hoster is waardeloos.
me => webhost

[q-enf0rcer.1]

Het is wel zorgelijk dat je over jezelf twijfelt, ik hoop dat dit een les voor je is om je code op het gebied van veiligheid beter dicht te timmeren. Gelukkig dat het dit keer in ieder geval niet jouw fout is

[copywizard]

ik zal geen reclame maken maar het bedrijf waarvoor ik werk is hierin gespecialiseerd mocht je hulp nodig hebben stuur me gerust een PM.

Verder zag ik al goede tips voorbij komen sluit het systeem niet geheel af maar trek de netwerk verbinding eruit en verander zo min mogelijk vanwege bewijsvoering en eventueel forensisch onderzoek.
En inderdaad melden bij de ACM!

[AW_Bos]

hackerhater schreef op maandag 05 september 2016 @ 11:20:
Euhm sweebee,
Zoek per direct een andere webhoster.
PHP 5.4 is zwaar verouderd en niet meer ondersteund.
Als ze nog 5.4 draaien zal de host zelf en apache ook wel verouderd zijn.
Vatbaar voor poodle ed.

Beetje onnodig om meteen te roepen om over te stappen? Misschien is het de keuze van de TS geweest om die versie te gebruiken, en kan hij met een kleine instelling in een webhosting paneel door naar versie 5.6.

[hackerhater]

AW_Bos schreef op maandag 05 september 2016 @ 13:24:
Beetje onnodig om meteen te roepen om over te stappen? Misschien is het de keuze van de TS geweest om die versie te gebruiken, en kan hij met een kleine instelling in een webhosting paneel door naar versie 5.6.

Omdat een beetje fatsoendelijke webhost unsupported software-versies uberhaupt al niet aan bied?
https://secure.php.net/supported-versions.php

Mijn klanten hebben de keuze tussen 5.6 of 7. Meer niet.
Wij weigeren zelfs VPS'en te supporten met out of date software.

[ Voor 5% gewijzigd door hackerhater op 05-09-2016 13:40 ]

[Basz0r]

hackerhater schreef op maandag 05 september 2016 @ 13:37:
[...]


Omdat een beetje fatsoendelijke webhost unsupported software-versies uberhaupt al niet aan bied?
https://secure.php.net/supported-versions.php

Mijn klanten hebben de keuze tussen 5.6 of 7. Meer niet.

In CentOS 7 is PHP 5.4 nog gewoon supported. Er komen dan wel geen nieuwe features meer uit, maar security patches worden gewoon nog gebackport. Dus zo raar hoeft die keuze niet te zijn.

[hackerhater]

Basz0r schreef op maandag 05 september 2016 @ 13:41:
In CentOS 7 is PHP 5.4 nog gewoon supported. Er komen dan wel geen nieuwe features meer uit, maar security patches worden gewoon nog gebackport. Dus zo raar hoeft die keuze niet te zijn.

Dat had ik niet verwacht dat ik een major versie dat nog gesupport was.
Maar laten we eerlijk zijn. 99% van de hosts die nog 5.4 aanbieden is verouderde onveilige troep.
Zonder url is dat lastig te achterhalen, maar het zou me niks verwonderen.

Evengoed bieden we het niet aan. Te veel verschillen tussen PHP 5.4 en 5.6 qua werking. Geen zin in vragen op dat gebied.
En als je site nog niet geschikt is voor 5.6 moet je je leverancier/devs een rotschop verkopen. Dan loop je echt jaren achter.

[Basz0r]

hackerhater schreef op maandag 05 september 2016 @ 13:46:
[...]


Dat had ik niet verwacht dat ik een major versie dat nog gesupport was.
Maar laten we eerlijk zijn. 99% van de hosts die nog 5.4 aanbieden is verouderde onveilige troep.
Zonder url is dat lastig te achterhalen, maar het zou me niks verwonderen.

Evengoed bieden we het niet aan. Te veel verschillen tussen PHP 5.4 en 5.6 qua werking. Geen zin in vragen op dat gebied.
En als je site nog niet geschikt is voor 5.6 moet je je leverancier/devs een rotschop verkopen. Dan loop je echt jaren achter.

Het hoeft niet persé troep te zijn hoor, ken genoeg PHP installaties die op zo'n stabiele PHP versie draaien. En verder ook nooit problemen hebben.

Een installatie qua code up-to-date houden met de laatste PHP versies kost (als de codebase vrij groot is) relatief veel tijd. En ook geld. Dus het is vaak een afweging om daar tijd in te steken.

Wat wel noodzakelijk is om Wordpress, Joomla, Drupal, thema's en plugins up to date te houden. Als je dat niet doet is de kans om gehackt te worden vrij groot. Ik zie zelf relatief veel van dat soort aanvallen, waarbij het doel is om zoveel mogelijk SPAM in een korte tijd te versturen.

Verder is het verstandig om de PHP variable open_basedir te gebruiken. En iets als PHP-FPM om websites onder aparte users te draaien. Back-up scripts voor bijv databases (met een wachtwoord er in) niet voor web users te exposen. En sowieso om per aparte PHP installatie een andere MySQL login te gebruiken.

[hackerhater]

Als je site nu nog niet PHP 5.6 compatibele is heb je serieus problemen in de toekomst.
Op 5.4 draaien is alsof je nog XP draait op je desktop. Het kan werken, maar zo slecht als maar kan.

Denk je echt dat een moderne WP/Joomla/Drupal e.d. uberhaupt nog draait op 5.4? Als het toevallig draait kan het elk moment omvallen omdat er niet op getest wordt.
Een van de dingen die met 5.6 geïntroduceerd werd waren namespaces. Die zijn niet backwards compatible.
In 2014 werd al gezegd dat je de code basis moest aanpassen voor 5.6 zodat de boel bleef werken, we zijn nu 2 jaar verder.

Wordpress : PHP 5.6 or greater

[ Voor 7% gewijzigd door hackerhater op 05-09-2016 14:04 ]

[Basz0r]

hackerhater schreef op maandag 05 september 2016 @ 14:03:
Als je site nu nog niet PHP 5.6 compatibele is heb je serieus problemen in de toekomst.
Op 5.4 draaien is alsof je nog XP draait op je desktop. Het kan werken, maar zo slecht als maar kan.

Denk je echt dat een moderne WP/Joomla/Drupal e.d. uberhaupt nog draait op 5.4? Als het toevallig draait kan het elk moment omvallen omdat er niet op getest wordt.
Een van de dingen die met 5.6 geïntroduceerd werd waren namespaces. Die zijn niet backwards compatible.
In 2014 werd al gezegd dat je de code basis moest aanpassen voor 5.6 zodat de boel bleef werken, we zijn nu 2 jaar verder.

Wordpress : PHP 5.6 or greater

Ik ben het ook met je eens dat het beter is om een nieuwere versie te draaien. Het is vaak ook veel sneller. Maar of het veel veiliger is, dat denk ik zelf niet. Ik ken de requirements van Wordpress. Een paar alinea's verder staat er ook dit:

Note: If you are in a legacy environment where you only have older PHP or MySQL versions, WordPress also works with PHP 5.2.4+ and MySQL 5.0+, but these versions have reached official End Of Life and as such may expose your site to security vulnerabilities.

[DJMaze]

hackerhater schreef op maandag 05 september 2016 @ 13:46:
Dat had ik niet verwacht dat ik een major versie dat nog gesupport was.
Maar laten we eerlijk zijn. 99% van de hosts die nog 5.4 aanbieden is verouderde onveilige troep.

Ik zal je vertellen dat ik voor veilige systemen toch liever 5.4 of 5.5 gebruik dan 5.6 of 7
Er zit namelijk een heel gevaarlijk gat in het nieuwe geheugen management van 5.6 en 7 dat noch steeds niet is opgelost (ja ik heb het al meerdere malen gerapporteerd)!

sweebee schreef op maandag 05 september 2016 @ 10:13:
Lijkt er tot nu toe op dat het niet mijn fout is. Al werd de fout wel snel naar mij verschoven.

Je stuurt het (web)bedrijf toch wel een rekening?
Voor niks gaat de zon op, maar die hoeft niet naar de supermarkt om brood te kopen.
Daarnaast heeft het (web)bedrijf al veel fouten gemaakt zo te lezen, en hun indekken is echt niet goed.

[ Voor 5% gewijzigd door DJMaze op 05-09-2016 14:10 ]

[hackerhater]

DJMaze schreef op maandag 05 september 2016 @ 14:09:
Ik zal je vertellen dat ik voor veilige systemen toch liever 5.4 of 5.5 gebruik dan 5.6 of 7
Er zit namelijk een heel gevaarlijk gat in het nieuwe geheugen management van 5.6 en 7 dat noch steeds niet is opgelost (ja ik heb het al meerdere malen gerapporteerd)!

Wat voor gat? (details mogen per PM)
Daaraantegen zijn verschillende gaten van PHP 5.4 in 5.6 en hoger opgelost. oa het uitschakelen van die rot globals.
Dus ja. Maar de PHP versie nog aan toe. De kans is helaas groot dat die host ook een verouderde Apache draait en verouderde openSSL en dan wordt het echt gevaarlijk.

@TS
Linkje zodat we de host kunnen checken ?

[ Voor 3% gewijzigd door hackerhater op 05-09-2016 14:14 ]

[DJMaze]

hackerhater schreef op maandag 05 september 2016 @ 14:13:
Wat voor gat? (details mogen per PM)

Done

hackerhater schreef op maandag 05 september 2016 @ 14:13:
Daaraantegen zijn verschillende gaten van PHP 5.4 in 5.6 en hoger opgelost. oa het uitschakelen van die rot globals.
Dus ja. Maar de PHP versie nog aan toe. De kans is helaas groot dat die host ook een verouderde Apache draait en verouderde openSSL en dan wordt het echt gevaarlijk.

Die "rot globals" is geen gat, het is puur het oplossen van "slechte programmeur" gaten. Net zoals "magic_quotes" en "safe_mode" ooit waren.

Ik ben het wel eens met je opmerkingen over een verouderde apache en openssl.
Maar dan nog vindt ik SSH zonder sleutels (allow password login) een veel gevaarlijkere instelling.

[hackerhater]

DJMaze schreef op maandag 05 september 2016 @ 14:42:
Maar dan nog vindt ik SSH zonder sleutels (allow password login) een veel gevaarlijkere instelling.

Dat is vooral gevaarlijk voor de root-user en als er niet iets als fail2ban mee draait

[pennywiser]

root login moet gewoon uit. Username EN password raden is niet realistisch uitgaande van veilig password gebruik. F2b ervoor en je hebt 5 pogingen zie ze elke dag voor bij komen al jaren.

[hackerhater]

Mwah wij hebben root-login voor onze servers wel aan staan, maar public-key only.
Laat ze maar proberen, het gaat toch niet werken.
Geeft alleen leuke lijstjes in de blocklijst van fail2ban

[TheNephilim]

Wat betreft de WordPress installatie; de kans is (denk ik) groot dat ze op die manier binnengekomen zijn. Wellicht kun je inventariseren welke versie WordPress er op staat en welke plugins/thema's er gebruikt worden. Met name de plugins kunnen voor problemen zorgen, waardoor er toegang tot php bestanden op de server verkregen is.

[Mathijs]

Grappig dat ze jou direct de schuld in de schoenen wilden schuiven terwijl er een niet up to date WP site draait.
Ik zou nog wel even aangeven dat je in het vervolg toch graag zou zien dat ze eerst zelf gedegen onderzoek doen alvorens jou lastig te vallen met een gevoel dat je misschien iets niet goed gedaan hebt.
In dit geval is het zo klaar als een klontje. De oudere PHP versie zegt niets op zich, maar de combinatie met Wordpress maakt het direct overduidelijk. Zeker met vele plugins kunnen we stellen dat het nog lang geduurd heeft.
Het is hierbij dus ook hun eigen verwijtbare fout dat de data van hun klanten op straat ligt, door nalatigheid!

Naar mijn mening kom je zelf nog wat vers en naief over, lees jezelf goed in. Google op bijvoorbeeld "security threats web developers" "sql injection" "cross site scripting" "session hijacking"

[sweebee]

Ik heb me destijds goed verdiept in de veiligheid, met name sql injections. Meerdere scenario's getest. Sommige gegevens worden in cookies opgeslagen, deze data is ook encrypted, ook zijn wachtwoorden met verschillende salts/peppers opgeslagen. En alles draait onder SSL.

Daarom ook dat ik me ineens "zorgen" maakte, aangezien ik al van alles had gedaan om hacking tegen te gaan. En het me sterk leek dat het aan mij zou liggen.

Inmiddels draait alles weer (muv wordpress), er is geen geld ontnomen (ze hadden betaallink naar een ideal/bitcoin pagina veranderd). Qua gebruikers data had 95% geen wachtwoord omdat dit niet nodig is voor de standaard diensten die afgenomen worden. Sommige wel, maar die wachtwoorden zijn versleuteld.

Verder moet het web-bedrijf de rest maar eens oplossen qua wordpress, brakke shared hosting ed. en melden bij ACM. Het hosting bedrijf heeft verder ook aardig wat mankementen zoals:

ftp accounts aanmaken kan, maar die werken niet
cronjobs kun je niet aanpassen nadat ze gemaakt zijn
log bestanden uit controlepanel downloaden werkt niet
PHP versie moet aan te passen zijn, maar geeft foutmelding
etc. etc.

[Verwijderd]

Als je een kale wordpress installatie zonder security opzet, dan is het vragen om problemen. Er komt zoveel ruis mee met verkeer dagelijks, voornamelijk bots dat speurt naar lekke theme's, plugin's en dergelijk.

Je schreef het Avada theme; de kans is groot dat dit een verouderd avada theme kan zijn en aan de hand van lekke javascripts, ze erin gekomen zijn. Recent zo'n site opgeruimd. Heel naar, want 'security' bij wordpress is ook 10x shit.

Het probleem is is dat ze inbreken op Apache niveau (een exploit in JS of PHP vinden) en daarmee heel wordpress plus de soft security layer mee omzeilen. Op het moment dat iemand een shell kan uploaden dan is het relatief makkelijk om deze shell aan te spreken en hiermee je kunstjes te doen.

In de regel is een verouderde PHP niet slecht, nee het wordt niet bijgewerkt, maar er zijn een honderduizendtal sites die nog steeds op 5.4 of zelfs lager werken, en niet mee willen op 5.5 of hoger.

Je kunt dat beveiligen, je moet de mogelijkheid tot een exploit weten te verkleinen. Het liefst geen wordpress, en als het niet anders kan, minimaal aantal plugins, overhead, bloatware en dergelijk installeren. Of een audit doen op je code die je upload.

Maar als ik dit verhaal zo lees:

- Avada theme exploit
- Vermoedelijk geen security plugins actief
- 10 onbekende plugins met mogelijk een exploit

Als ze wordpress binnen komen en de server op PHP 5.4 of minder draait dan is het een appeltje eitje om PHP te hacken en toegang tot heel de server verkrijgen.

Het in paniek verwijderen van bestanden werkt niet. Men had het gewoon op 600 moeten zetten (bestandsrechten) waarmee je de boel bevriest tijdelijk. Zo kan je het uitspeuren wat er mis ging.

Maar 1 plugin of stukje script? Ik denk dat het bij Avada ligt.

[WhiteDog]

Is nu heel de server gehacked of niet? Ik lees shared hosting dus ga ik er vanuit dat deze site (user) afgeschermd is en men enkel tot deze account toegang had. PHP draait dan als jouw user en niet als root.

Vind dat de hoster nog best goed meehelpt, al zijn al de zaken die je aanhaalt zoals logs en backups zaken die je bv. in cPanel zelf kan regelen. Welk controlepaneel en versie gebruiken ze?

[sweebee]

De hele server is niet gehackt, ze hadden enkel toegang via het script wat in de wordpress installatie stond. Het is een controlepanel van hun zelf, dus geen third party zoals cpanel, directadmin oid.

[NiGeLaToR]

Je had je datalek al gemeld toch?

[sweebee]

NiGeLaToR schreef op maandag 05 september 2016 @ 22:14:
Je had je datalek al gemeld toch?

Ik heb het gezegd tegen het bedrijf die de service verhuurt dat ze het moeten melden bij ACM. Het bedrijf waar ik destijds dus die web-app voor gemaakt had. (de politie was al wel ingelicht, dan mag ik er ook vanuit gaan dat zij hier op de hoogte van zijn?).

Al zeggen ze zelf dat ze het liever niet willen doen. Maar nog van de boete afgezien die ze kunnen krijgen, is het ook nogal onbeschoft dit onder de pet de houden tegen over de klanten.

De hacker zou dit ook publiekelijk kunnen maken, mocht het dan aan het licht komen dan kunnen ze het al helemaal vergeten.

[ Voor 6% gewijzigd door sweebee op 05-09-2016 22:22 ]

[Verwijderd]

Ik neem ieder bedrijf dat persoonsgegevens verwerkt op een wordpress site al niet serieus meer.

Is er een cached versie van de site ergens? Wellicht kan je uitdoktoren welke versie Avada werd gebruikt, en derhalve kijken of daar een exploit voor was. Belangrijk is ook mappen van themes volledig verwijderen als je die niet gebruikt. Er zijn gewoon hacks in omloop voor de eerste versie(s) van twentythirtheen, fourteen enz.

[sweebee]

in google cache kan ik versie 4.0.6 vinden, volgens mij een recente versie. Zo ook niet 1,2,3 iets over bekend met een exploit.

Ik ga er wel vanuit dat de standaard thema's nooit verwijderd zijn.

De wordpress website verwerkte geen persoonsgegevens, het stond alleen op de zelfde host, al maakt het dat niet minder erg natuurlijk.

[Verwijderd]

Alles onder 4.1.0 is lek. Eerste hit op google dus.

[Compizfox]

Verwijderd schreef op maandag 05 september 2016 @ 18:07:
Als je een kale wordpress installatie zonder security opzet, dan is het vragen om problemen. Er komt zoveel ruis mee met verkeer dagelijks, voornamelijk bots dat speurt naar lekke theme's, plugin's en dergelijk.

Juist een kale WP-install is veiliger. 9 van de 10 keer is een brakke plugin de boosdoener in dit soort gevallen.

[Verwijderd]

Compizfox schreef op maandag 05 september 2016 @ 23:40:
[...]

Juist een kale WP-install is veiliger. 9 van de 10 keer is een brakke plugin de boosdoener in dit soort gevallen.

Je hebt helemaal gelijk, maar je krijgt constant bruteforce aanvallen te verduren en dat blijft aan de gang als je dat soort dingen niet kunt blokkeren.

En die bruteforce aanvallen veroorzaken constant een load op PHP & mysql, omdat wordpress een miljoen queries uitvoert om een login te controleren.

[ExilaaHH]

sweebee schreef op maandag 05 september 2016 @ 23:01:
in google cache kan ik versie 4.0.6 vinden, volgens mij een recente versie. Zo ook niet 1,2,3 iets over bekend met een exploit.

Ik ga er wel vanuit dat de standaard thema's nooit verwijderd zijn.

De wordpress website verwerkte geen persoonsgegevens, het stond alleen op de zelfde host, al maakt het dat niet minder erg natuurlijk.

Tja dat is natuurlijk ook vragen om problemen, Wordpress en een applicatie waarin persoonsgegevens worden verwerkt op dezelfde host. Wellicht ook direct een goede les voor het bedrijf om dit maar eens netjes te gaan scheiden...

De wijze waarop dit gebeurd lijkt wel iets op Weevely vanuit KALI Linux. Het zorgt ervoor dat er een geinfecteerd php bestand op de server wordt gezet waarna root rechten worden verkregen waardoor je eigenlijk alles kunt verwijderd of kopiëren.

[ Voor 15% gewijzigd door ExilaaHH op 05-09-2016 23:59 ]

[Verwijderd]

Ik kan je wel 10 php bestanden bieden die shells voor moeten stellen. Die worden na upload gewoon via een URL aangeroepen en doen allerlei dingen voor je zoals controleren welke php versie je hebt, on the fly PHP 'exploiten' met 1 druk op de knop en allerlei functies zoals een admin user toevoegen onder wordpress database en dat soort dingen.

Het is niet zo spannend, maar je merkt wel dat ook hackers meer geautomatiseerd tewerk gaan en echt binnen een minuut willen weten of ze je hele server mee kunnen nemen of niet.

Avada is een hele mooie basis, maar er komt zoveel unauditted javascript mee iedere keer dat die exploits zowat daarop allemaal gebaseerd zijn.

Als je met avada < 4.1.0 draait dan loopt elke site risico. Soms krijg je ook XML exploits voor je kiezen, dan roepen ze met een ander bestand op een ander host het e.a op je website aan, en als dat lukt dan zijn ze binnen.

De security van de meeste wordpress plugins stellen ook niets voor. Ze doen een 'soft' layer als security maar kan gewoon bypassed worden door te werken op apache niveau.

PHP 5.4 is gewoon verouderd, en ze zijn er hoogstwaarschijnlijk via avada erin gekomen, shell geupload en vervolgens een deel van de server meegenomen. Ik zag ooit 1 klant die op zijn bedrijfsserver, onder root wordpress zonder enige vorm van security had gezet, outdated was en waar geen CSF onder zijn directadmin installatie meedraaide.

Moet je je voorstellen als dat even gehacked wordt, bedrijfsgegevens van A tot Z van de afgelopen 10 jaar zo op straat kwam te liggen. Sommige mensen moeten zich niet met sites of servers bezighouden, vind ik.

[Thc_Nbl]

Ik heb de boel gewoon dicht getimmerd met Mod Security, scheelt 99.99% kan op problemen, mist goed ingericht. Iedereen zou een Web Application Firewall moet hebben.
maar ja.. het is gewoon een tering zooi qua hosters op het internet.

Ik erger me ook dood aan foute e-mail server configuraties. Banken maar klagen over phishing..
tsja als de SPF records er niet eens zijn. ..
of b.v. geen A/PTR voor client en geen A voor helo hostname., niet goed, jammer dan, ik meld de verzender netjes dat hun DNS niet klopt. of zoals bij 99% van de exchange server, dat de uitgaande SMTP connector niet is geconfigureerd dus er geidentifieerd wordt met .naam.intern.local

Bij mij is het simple, ik hanteer:
https://www.forumstandaar...verplicht-pas-toe-leg-uit
waar de SMTP RFC netjes bij staan.

en ook een goede is :
http://wetten.overheid.nl...tuk2_Paragraaf1_Artikel13
>> De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. <<