Bekijk Volledige Versie : exploit script
Best mede WHT,
Graag heb ik jullie hulp nodig voor ons volgende probleem.
Als beginnend bedrijf hebben wij voor een klant een soort gallery script gemaakt. Echter deze week kregen wij een melding van onze hoster dat het script was misbruikt voor een mailing exploit :(
Het viel ons op dat er in de hoofddir een bestand was geplaats die ervoor zorgde dat de server een mailque kreeg van 150k aan spam berichten.
Als bijlage heb ik de log file neergezet die wij van onze hoster hebben gehad.
Om ervoor te zorgen dat dit niet meer gebeurd willen wij graag advies.
Wie van jullie wil ons helpen om ons, eventueel tegen betaling, te helpen om dit en eventuele andere scripts veiliger te maken?
Met vriendelijke groet,
Orlam
Best mede WHT,
Graag heb ik jullie hulp nodig voor ons volgende probleem.
Als beginnend bedrijf hebben wij voor een klant een soort gallery script gemaakt. Echter deze week kregen wij een melding van onze hoster dat het script was misbruikt voor een mailing exploit :(
Het viel ons op dat er in de hoofddir een bestand was geplaats die ervoor zorgde dat de server een mailque kreeg van 150k aan spam berichten.
Als bijlage heb ik de log file neergezet die wij van onze hoster hebben gehad.
Om ervoor te zorgen dat dit niet meer gebeurd willen wij graag advies.
Wie van jullie wil ons helpen om ons, eventueel tegen betaling, te helpen om dit en eventuele andere scripts veiliger te maken?
Met vriendelijke groet,
Orlam
Zou zeggen, mod Mod_Security, voorkomt veel mailinjections.
Que leeg maken, zodat mails stoppen.
/sbin/service exim stop
cd /var/spool/exim/
rm -rf input
Installeren en configureren van Mod_Security, via google zijn er meer te vinden:
http://www.crucialp.com/resources/tutorials/secure-server-securing/how-to-install-mod_security-for-apache.php
Ik heb hetzelfde gehad met een gallery script. het was voor bezoerks ook mogelijk om scripts te plaatsen. Ik had een thumb_xxx.php in mijn userpics staan. Heel irritant om dat op te sporen. Je kijkt daar zo overheen.
Ik heb toen de gallery eruit geknikkerd en iets gebruikt wat veiliger was.
Het bestand verwijderen is de eerste stap. Vervolgens kan je eens je http access logs kijken of deze kiddos misschien een remote file include hebben gedaan. Dit zou je bijv zo kunnen doen:
cat access_log | grep "=http" | grep -v google
Als je hier output van krijgt zou ik eens kijken naar de gebruiket scripts.
Cheers
Het bestand verwijderen is de eerste stap. Vervolgens kan je eens je http access logs kijken of deze kiddos misschien een remote file include hebben gedaan. Dit zou je bijv zo kunnen doen:
Cheers
Ik ben zelf reseller, dus heb geen toegang tot de server.
Het enige wat ik heb gekregen was het log bestand. Wat betreft server ben ik van mening dat onze hoster zijn zaakjes in orde heeft en dat de fout bij ons in het script zit.
@Handy
Bestand is direkt verwijderd uiteraard.
je script include alles wat los aan vast staat doordat je de input niet controlleert. Gebruik in het vervolg een switch of een andere methode waarbij de input gecontrolleert wordt. Doordat je host tevens ook toestaat dat er extreern gegevens opgehaald mogen worden, worden deze txt bestanden geinclude en uitgevoerd als zijnde php files, alleen ditmaal gebeurt dat lokaal. Via deze weg kan men dus files aanpassen uploaden etc etc.
je script include alles wat los aan vast staat doordat je de input niet controlleert. Gebruik in het vervolg een switch of een andere methode waarbij de input gecontrolleert wordt. Doordat je host tevens ook toestaat dat er extreern gegevens opgehaald mogen worden, worden deze txt bestanden geinclude en uitgevoerd als zijnde php files, alleen ditmaal gebeurt dat lokaal. Via deze weg kan men dus files aanpassen uploaden etc etc.
Hier kunnen we wat mee.
Orlam
voorbeeldje:
$pagina= $_GET['pagina'];
switch ($pagina)
{
case "hoofdpagina":
include("include/hoofdpagina.php");
break;
default:
include("include/hoofdpagina.php");
}
Mijn frustraties hieromtrent heb ik al eens op het web gezet:
http://www.dsinet.org/?id=3983
V. Kleijnendorst
05/09/06, 16:19
Mijn frustraties hieromtrent heb ik al eens op het web gezet
De oplossing voor header injection is niet zo mooi. Vaak wordt een form gepost door eerst een request te doen zonder post en zo de benodigde velden op te halen. Je kunt beter de input valideren in plaats van een 'geheime' value te gebruiken.
Swiftway-UK
05/09/06, 16:22
Het grootste probleem, naar mijn idee, ligt hem in de vaardigheden van sommige programmeurs. Zij bieden scripts en scripting diensten aan, zonder dat zij de scripting taal volledig beheersen. Het feit dat een programmeur dan op een publiek forum om raad moet vragen, naar wat eigenlijk basiskennis is, vind ik persoonlijk zeer zorgwekkend.
V. Kleijnendorst
05/09/06, 16:27
Ach, blijft er nog werk over voor klanten die willen betalen voor kwaliteit.
@ts dit is het scriptje dat in je log staat: http://www.videosanimados.kit.net/script8.txt?
De oplossing voor header injection is niet zo mooi. Vaak wordt een form gepost door eerst een request te doen zonder post en zo de benodigde velden op te halen. Je kunt beter de input valideren in plaats van een 'geheime' value te gebruiken.
Niet goed gelezen(1) ;)? De geheime code is slechts een extra beveiliging, die (uit ervaring) goed werkt tegen bots. De bot weet namelijk niet welke code in het PHP gedeelte voor, achter, of tussen de geheime code geplakt wordt om een hash te genereren.
(1)
When someone enters a linebreak and carriage return (%0D%0A), it is possible to inject a Cc header field. Unless the input is santinized by trimming these characters:
$sender = trim($_POST['sender']);
$headers = "From: " .$sender;
V. Kleijnendorst
05/09/06, 16:41
trim haalt alleen whitespace weg aan het begin en einde van je string. Als er dus eerst een carriage return staat en daarna een nieuwe header in plain text, dan wordt deze extra header toch niet weggehaald?
Is het niet veel handiger om een e-mailadres te valideren met een regex?
Ik zie in logs dat bots vaak de formuliervelden ophalen en posten. Dat gedrag is dus niets anders dan dat van bezoekers.
trim haalt alleen whitespace weg aan het begin en einde van je string. Als er dus eerst een carriage return staat en daarna een nieuwe header in plain text, dan wordt deze extra header toch niet weggehaald?
De trim() functie in PHP doet wat meer dingen dan de trim() functie in ASP:
Deze functie verwijdert whitespace aan het begin en einde van een string en geeft de nieuwe string terug. Zonder het tweede parameter zal trim() de volgende tekens verwijderen:
* " " (ASCII 32 (0x20)), een normale spatie.
* "\t" (ASCII 9 (0x09)), een tab.
* "\n" (ASCII 10 (0x0A)), een new line (line feed).
* "\r" (ASCII 13 (0x0D)), een carriage return.
* "\0" (ASCII 0 (0x00)), een NUL-byte.
* "\x0B" (ASCII 11 (0x0B)), een verticale tab.
Is het niet veel handiger om een e-mailadres te valideren met een regex?Een fatsoenlijke, allesomvattende regex voor e-mailadressen is lang... En dan bedoel ik ook lang (O'Reilly had eens een regex van 3 regels op de website staan). Daarnaast kan je ook nog eens op gaan vragen over er een MX record voor het domain-part is, enz, enz.
Het is maar net hoe uitgebreid je het hebben wilt.
Ik zie in logs dat bots vaak de formuliervelden ophalen en posten. Dat gedrag is dus niets anders dan dat van bezoekers.
Je vergelijkt 2 codes met elkaar, een bekende en een onbekende. http://www.vevida.com/NL/service_onderwerp.asp?owid=240#830 , vanaf "Oplossing" zal wellicht wat duidelijker zijn.
V. Kleijnendorst
05/09/06, 17:29
De trim() functie in PHP doet wat meer dingen dan de trim() functie in ASP
Ik ben een PHP-ert. Ik doelde op het feit dat de tekens alleen aan het begin en eind verwijderd worden en niet in het midden. Als je eindigt met een header zal trim niets doen. Je laat nu iets anders zien en daar zie ik inderdaad een regex om ervoor te zorgen dat er geen 'foute' waarden in de string staan.
Je regex hoeft voor deze injection natuurlijk geen mx lookup gaan doen.
Als een bot een pagina opvraagt zoals een bezoeker dat doet en vervolgens een post doet zoals een bezoeker dat doet heb je nog steeds niets aan je geheime code. Je onderscheidt er geen bot van een bezoeker mee.
Ik ben een PHP-ert. Ik doelde op het feit dat de tekens alleen aan het begin en eind verwijderd worden en niet in het midden. Als je eindigt met een header zal trim niets doen. Je laat nu iets anders zien en daar zie ik inderdaad een regex om ervoor te zorgen dat er geen 'foute' waarden in de string staan.
Mea Culpa, de regex heb ik bij in het artikeltje geflantst, waarvoor dank :)
Als een bot een pagina opvraagt zoals een bezoeker dat doet en vervolgens een post doet zoals een bezoeker dat doet heb je nog steeds niets aan je geheime code. Je onderscheidt er geen bot van een bezoeker mee.
Ik heb nog nooit een bot op het "submit" formpje zien drukken :) Nee, alle gekheid op een stokje: ik heb nog nooit mee gemaakt dat een bot alle form-waardes ophaalt om deze later te gebruiken in het submitten van spam. Ik zeg niet dat het onmogelijk is, ik heb het alleen nog nooit gezien. Eens werd in nl.internet.www.server-side geopperd om een tijdafhankelijke waarde mee te geven via PHP. De waarde is dus constant anders.
Overigens, tegenwoordig worden tieners door spammers betaalt om van een lijst websites alle formulieren bij langs te gaan om te spammen. Geen enkele beveiliging heeft dan zin, helaas.