De database.. en hoe zit het met de webserver? Draait die wel op een klantenserver? Dan heb je in dat geval dus ook de MySQL username en password van WeFact in een configuratiebestandje op je klantserver staan..
Doe dat nou niet..
De database.. en hoe zit het met de webserver? Draait die wel op een klantenserver? Dan heb je in dat geval dus ook de MySQL username en password van WeFact in een configuratiebestandje op je klantserver staan..
Doe dat nou niet..
Webserver draait wel op een klanten server
Maar ik heb nu de volgende Constructie in gedachte !
Whmcs op een aparte Server
wefact op een aparte Server
en dan 2 Servers voor een db van whmcs en een db van wefact
Dan is alles apart en heb ik dit probleem niet meer lijkt mij
DB op aparte servers draaien geeft niet echt een meerwaarde, aangezien ze het database wachtwoord uit kunnen lezen in het configuratie bestand. Vaak kunnen ze ook nog een phpshell uploaden en hiermee de database dumpen.
Zorg gewoon dat je 2 aparte servers hebt voor WHMCS en Wefact en die laat beveiligen door iemand die daar alle verstand van heeft.
Waarom wil je een scheiding van je web- en databaseserver? Wat is de toegevoegde waarde hiervan?
Het scheiden van WHMCS en WeFact kan nog enige toegevoegde waarde hebben, zodat een beveiligingslek in het ene systeem geen invloed heeft op het andere systeem.
Als ik jou was zou ik gewoon een nieuwe fysieke bak pakken, die virtualiseren en 2 VM's aanmaken; 1 voor WHMCS, 1 voor WeFact. En uiteraard het geheel dicht timmeren (er hoeft niets open te blijven behalve poort 443 + enkele uitzonderingen voor APIs).
Zoals Ron al zei; als je over dit soort kwesties nog niet eerder nagedacht hebt, doe je er goed aan om iemand een dagje in te huren en het voor je te laten regelen. Dit soort zaken dien je op orde te hebben voordat je überhaupt met je bedrijf van start gaat..
Echoooo! oo.. oo..
Kwetsbare installaties spugen kennelijk de waardes van configuration.php uit als je waardes voor $templatefile injecteert. Als je SQL dus naar externe IP's antwoordt, kunnen ze in je db. Ik weet niet hoe dat bij jullie zit, maar onze servers antwoorden standaard alleen op localhost...
Zie: http://gregorydevans.com/2011/11/30/...-exploit-tool/
Hmm als ik het zo zie dan is whmcs wel erg slecht geschreven, dit zijn één van de basic dingen waar je rekening mee moet houden. Een simpele preg_match had dit voorkomen kunnen hebben. Ik vraag me af of het niet slimmer is om whmcs helemaal af te gaan schermen van publiekelijke toegang (inclusief de API) en zelf een front-end niet beter is. Goed het kost tijd maar dan heb je de zekerheid dat het veilig is en hoef je niet een compleet nieuw systeem te gaan ontwikkelen.
Ik heb het echter niet kunnen reproduceren, front is al gepatched maar dev versie (V5) is ongepatched (wel afgesloten voor publiek) maar krijg ik met de tool geen waardes. Mogelijk was dit al gepatched maar is de patch pas later gepubliceerd?
Met vriendelijke groet, Yourwebhoster.eu - Managed VPS diensten met Epyc performance op 100% SSDs
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
hier ook geupdate, gelijk upgrade naar versie 5 uitgevoerd, die moest nog gebeuren. WHMCS heeft overigens de full download ook al gepatch. Desondanks wel even checken bij dit soort ernstige meldingen.
Met vriendelijke groet, Yourwebhoster.eu - Managed VPS diensten met Epyc performance op 100% SSDs
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
de release was van voor de patch, maar toen ik hem vanmiddag downloadde was de release al gepatcht. de extra patch was dus niet nodig. (maar toch altijd even checken natuurlijk)
Weet je dat wel zeker?
Zou mij namenlijk niets verbazen als het lek net zo simpel te misbruiken is met een wel afschermde MySQL.
- ja, in het voorbeeld dat hier gelinkt wordt het lek gebruik wordt om de inhoud van configuration.php te laten zien.
- maar let goed op: de misbruikte parameter heet niet voor niets "templatefile". Het lokale bestand dat in de URL wordt genoemd wordt niet zomaar ingelezen, maar als template uitgevoerd!
- in smarty templates kan PHP code worden ge'embed.
- iemand die dus een bestand naar je server kan uploaden en daar de locatie van weet, kan met het lek willekeurige php code uitvoeren op je server.
En ik denk dat de aanvallers er inmiddels ook wel achter zijn hoe ze een bestand op jouw server kunnen krijgen.
De TS heeft het over rare PHP code als bijlage bij een support ticket....
Hier ook meteen geupdate toen de nieuwe versie 5 uit was.
En tevens meteen alle andere bugfixes verholpen die erbij zaten.
Hangt er van af, in dit geval gaat het alleen om het includen/lezen van een file. Als er dus een mysql pw is en deze zou anders moeten zijn dan je ftp/directadmin login, dan is er nog geen toegang tot de whmcs omgeving. Ik moet hier echter wel een kanttekening bij maken dat als toegang tot de database verkregen is dat dus ook de admin login gegeven kan worden en als je in whmcs een module hebt die bestanden weg schrijft naar je server dat je een groter beveiligingsprobleem hebt.
Met vriendelijke groet, Yourwebhoster.eu - Managed VPS diensten met Epyc performance op 100% SSDs
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
Die file wordt niet alleen ingelezen, maar als template bestand uitgevoerd.
In het geval van cart.php?a=account.php&template=../../../include/configuration.php%00 zitten er geen smarty tags in configuration.php en word het bestand daarom alleen weergegeven.
Maar als je via de support ticket functie een bestand upload waar "{php}kwaadaardige code{/php}" in staat en vervolgens ipv configuration.php ../../../attachments/naam%00 aanroept dan wordt die code uitgevoerd.
Een afgeschermde database server helpt je daar niet tegen. Denk dus niet dat het allemaal wel mee valt, en de patch wel tot na het weekend kan wachten...