Onderwerp: WHMCS gebruikers opgelet!

Oorspronkelijk geplaatst door maxnet

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...

Je moet dan wel net de attachments directory raden, tenzij deze standaard is werkt dit niet.

Oorspronkelijk geplaatst door Yourwebhoster

Je moet dan wel net de attachments directory raden, tenzij deze standaard is werkt dit niet.

Naam is standaard.
Op welke locatie je whmcs geinstalleerd hebt maakt niet uit, doodat met ../ gewerkt wordt...

Oorspronkelijk geplaatst door maxnet

Naam is standaard.
Op welke locatie je whmcs geinstalleerd hebt maakt niet uit, doodat met ../ gewerkt wordt...

Correctie: bedoel als je de standaard gebruikt. Dit is namelijk aan te passen: http://docs.whmcs.com/Further_Security_Steps

En die aangepaste waarde komt dan in configuration.php te staan.
Je weet wel, dat bestandje dat met de oorspronkelijke voorbeeld exploit getoond wordt...

Oorspronkelijk geplaatst door maxnet

En die aangepaste waarde komt dan in configuration.php te staan.
Je weet wel, dat bestandje dat met de oorspronkelijke voorbeeld exploit getoond wordt...

Ooops, scherp. Er is trouwens een manier waarmee je dat kan voorkomen (standaard php include, met de hack kan je geen php variabelen uitlezen die in php geladen zijn) maar hoe ver wil je gaan om je systeem veilig te krijgen? WHMCS zou dit standaard zelf moeten doen, maar ik denk eigenlijk, zeker na dit voorbeeld, dat het niet gek is om de configuration.php leeg te laten en een standaard php include te doen waar je de settings in zet. Ik heb dit nog niet met whmcs getest, maar hiermee voorkom je in ieder geval dat je een standaard bestand hebt waar je login gegevens in staan en andere settings.

Let dan wel op dat je dit niet in de htaccess zet maar in een vhost die niet uitleesbaar is en dat je het bestandje niet een te logische naam geeft (zoals config.php).

Oorspronkelijk geplaatst door maxnet

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....

Wat jij omschrijft == "de mogelijkheid om als niet-beheerder verbinding te maken met de database"

Maar ik begrijp je punt: om deze hack (bemachtigen van mysql gegevens) in de eerste plaats te kunnen gebruiken, is de hacker al ver genoeg ingebroken om ook MySQL commando's the kunnen versturen.

Oorspronkelijk geplaatst door Apoc

Wat jij omschrijft == "de mogelijkheid om als niet-beheerder verbinding te maken met de database"

Maar ik begrijp je punt: om deze hack (bemachtigen van mysql gegevens) in de eerste plaats te kunnen gebruiken, is de hacker al ver genoeg ingebroken om ook MySQL commando's the kunnen versturen.

Jij noemt het bemachtigen van MySQL gegevens deze hack.
Maar de TS heeft het over rare php code die hij bij zijn support tickets zit.
Vandaar mijn vermoeden dat de door mij beschreven methode niet lauter theoretisch is, maar juist de methode is die op dit moment in de praktijk door aanvallers gebruikt wordt.


Mijn punt is dat je op moet passen met het downplayen van beveiligingsproblemen.
Mensen die jou post (en die van Cybafish) lezen zouden ten onrechte het gevoel kunnen krijgen: "oh, mijn setup is veilig, die patch kan wel tot na het weekend wachten"
Terwijl je dan wel eens te laat zou kunnen zijn.

Oorspronkelijk geplaatst door maxnet

J
Mensen die jou post (en die van Cybafish) lezen zouden ten onrechte het gevoel kunnen krijgen: "oh, mijn setup is veilig, die patch kan wel tot na het weekend wachten"
Terwijl je dan wel eens te laat zou kunnen zijn.

En vergeet tevens niet het mysql pw te wijzigen samen met de apikey, als nog niets gebeurt is betekend het niet dat de gegevens niet gepakt zijn. De dader kan blijven wachten en het later alsnog proberen te misbruiken.

Oorspronkelijk geplaatst door maxnet

Mijn punt is dat je op moet passen met het downplayen van beveiligingsproblemen.
Mensen die jou post (en die van Cybafish) lezen zouden ten onrechte het gevoel kunnen krijgen: "oh, mijn setup is veilig, die patch kan wel tot na het weekend wachten"
Terwijl je dan wel eens te laat zou kunnen zijn.

Goed punt, want zo was dat uiteraard niet bedoeld. Sterker nog; het was juist bedoeld om daarmee aan te geven dat er in zo'n geval meer aandacht aan beveiliging gegeven zou moeten worden (hetgeen in het geval van bijvoorbeeld patrickekkel ook precies het geval bleek te zijn)

Overigens; dit type exploit is nagenoeg altijd gerelateerd aan upload functies. Het zou naar mijn mening dus ook geen verkeerd idee zijn om iedere mogelijke uploadfunctie te mijden in een bedrijfskritisch systeem zoals dit, en daarvoor een alternatieve oplossing te gebruiken (tenzij je echt 100% zeker bent dat de upload functie niet misbruikt kan worden, hetgeen vrij lastig te controleren is in een closed source systeem).

N.B. dit is geen advies, maar een ingeving

Oorspronkelijk geplaatst door Apoc

Overigens; dit type exploit is nagenoeg altijd gerelateerd aan upload functies. Het zou naar mijn mening dus ook geen verkeerd idee zijn om iedere mogelijke uploadfunctie te mijden in een bedrijfskritisch systeem zoals dit, en daarvoor een alternatieve oplossing te gebruiken (tenzij je echt 100% zeker bent dat de upload functie niet misbruikt kan worden, hetgeen vrij lastig te controleren is in een closed source systeem).

N.B. dit is geen advies, maar een ingeving

Bedenk me net, waarom moet het met de originele extentie opgeslagen worden en niet als een extentieloze file zonder uitvoer rechten?

Oorspronkelijk geplaatst door Yourwebhoster

Bedenk me net, waarom moet het met de originele extentie opgeslagen worden en niet als een extentieloze file zonder uitvoer rechten?

Wordt meestal ook niet met de originele extensie opgeslagen.
Maar is in dit geval ook niet nodig, omdat WHMCS het opgegeven bestand altijd als smarty template uitvoert ongeacht extensie.

Wel plakte WHMCS ".tpl" achter de bestandsnaam die je in de parameter opgaf.
Uiteraard met de gedachte dat je alleen maar ".tpl" bestanden op zou kunnen geven.
Maar door het plaatsen van de "%00" (null character) achter de naam, zorgt de aanvaller er voor dat de toegevoegde ".tpl" niet gebruikt wordt.

O.a. de Suhosin PHP patch ( http://www.hardened-php.net/hphp/a_feature_list.html "Filters ASCIIZ characters from user input") kan dergelijke tekens voor je eruit filteren.
Maar is alleen maar een lapmiddel, vereist afstelwerk (anders werken ook legitieme webapps niet meer goed) en is niet beschikbaar voor de nieuwere PHP versies.

Oorspronkelijk geplaatst door maxnet

Wordt meestal ook niet met de originele extensie opgeslagen.
Maar is in dit geval ook niet nodig, omdat WHMCS het opgegeven bestand altijd als smarty template uitvoert ongeacht extensie.

Wel plakte WHMCS ".tpl" achter de bestandsnaam die je in de parameter opgaf.
Uiteraard met de gedachte dat je alleen maar ".tpl" bestanden op zou kunnen geven.
Maar door het plaatsen van de "%00" (null character) achter de naam, zorgt de aanvaller er voor dat de toegevoegde ".tpl" niet gebruikt wordt.

O.a. de Suhosin PHP patch ( http://www.hardened-php.net/hphp/a_feature_list.html "Filters ASCIIZ characters from user input") kan dergelijke tekens voor je eruit filteren.
Maar is alleen maar een lapmiddel, vereist afstelwerk (anders werken ook legitieme webapps niet meer goed) en is niet beschikbaar voor de nieuwere PHP versies.

Ja en nee. Smarty opent configuration.php maar voert deze nog niet uit. Als je attachments directory publiekelijk te openen is en je kan je geüploade php bestand uitvoeren dan kan je dus gewoon een shell uploaden. Met alleen het uitlezen van een geüploade PHP file kom je niet ver, of bedoel je iets anders?

Oorspronkelijk geplaatst door Yourwebhoster

Ja en nee. Smarty opent configuration.php maar voert deze nog niet uit.

Met "uitvoeren" bedoel ik "als template bestand verwerken".

Ook configuration.php wordt bij gebruik van het lek als template bestand gezien en als zodanig verwerkt.
Omdat er echter geen smarty commando's in het bestand staan (zoals "{$variable}", "{if}" of "{php}") is het resultaat van het verwerken de inhoud van het bestand.

Had er wel "{php}" (niet te verwarren met "<?php") in configuration.php gestaan dan werd ook die code uitgevoerd.
Ongeacht dat het een .php bestand is, en geen .tpl

De concurrentie doet wel erg goed hun best om WHMCS zo goed mogelijk na te maken...
Zelfde bugs.

Hostbill Version: 3.1.2 Date: 12-05-2011

Bugs Fixed
[...]
Security: Potential security risk when using support tickets and Smarty library not in secure mode [12-05-2011]