Onderwerp: 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

Oorspronkelijk geplaatst door 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/tu...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

Oorspronkelijk geplaatst door handy

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.

Oorspronkelijk geplaatst door Mikey

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:

PHP Code:

        $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

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.

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.

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?

Oorspronkelijk geplaatst door V. Kleijnendors

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:

Code:

  $sender = trim($_POST['sender']);
  $headers = "From: " .$sender;

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.

Oorspronkelijk geplaatst door V. Kleijnendors

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.

Oorspronkelijk geplaatst door V. Kleijnendors

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.

Oorspronkelijk geplaatst door V. Kleijnendors

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_ond...p?owid=240#830 , vanaf "Oplossing" zal wellicht wat duidelijker zijn.