Bekijk Volledige Versie : hoe te beveilligen tegen sendmail hacks?
Steeds vaker zijn onze klanten en server doelwit van sendmail hacks.
Via bestanden als sendmail.php of contact.php weten hackers door middel van relatief eenvoedige scripts spam te versturen via deze bestanden.
Dit heeft er inmiddels toe geleid dat 1 van onze ip adressen momenteel staat vermeld in diverse spam lijsten.
Wij raden al onze klanten aan om gebruik te maken van formmail, maar er zijn veel klanten die nog steeds gebruik maken van php mail.
Zelf willen we dan ook deze functie gewoon behouden, echter is het mogelijk om aan sendmail een limiet te stellen?
jinxedworld
05/02/06, 13:56
Ik zou ook eens beginnen met mod_security. Met een goede ruleset kan je dit ook gebruiken tegen lekke PHP-scriptjes zodat je spammers buiten de deur houd.
Is dat bij mij aan Dennis ?
De php mail() functie is eigenlijk de schuldige.
Deze laat de header injection toe.
Wanneer een script dus niet checked of er meerdere adressen staan in de TO: zullen deze dus ook gemailed worden.
Misschien is het geen optie, maar gewoon afchecken in je script(s) of er maar een enkel mail adres in de header staat (check bijv. op "\n" en "\r" of aantal "@") zal het probleem verhelpen.
Ik betwijfel of je dit met mod_security kunt tegengaan?
Geen idee of dit kan, maar misschien kan je in je eigen mailserver een verstuurlimiet instellen.
Aloha,
Martin
Origineel geplaatst door Easewood
De php mail() functie is eigenlijk de schuldige.
Deze laat de header injection toe.
Die funtie is hardstikke goed, de scripter is hier toch echt wel de schuldige!
Origineel geplaatst door Easewood
Wanneer een script dus niet checked of er meerdere adressen staan in de TO: zullen deze dus ook gemailed worden.
Misschien is het geen optie, maar gewoon afchecken in je script(s) of er maar een enkel mail adres in de header staat (check bijv. op "\n" en "\r" of aantal "@") zal het probleem verhelpen.
Zoals al gezegd, het gaat hier om scripts van klanten, dus heb je niks aan het checken!
Origineel geplaatst door galious
Geen idee of dit kan, maar misschien kan je in je eigen mailserver een verstuurlimiet instellen.
Aloha,
Martin
dit zou wel mogelijk zijn, echter betwijfel ik het of het werkt.
betreft mod secerety ben ik nog niet helemaal uit.
dit levert een hoop andere problememen op zoals niet meer kunnen verzenden, posten en dat soort dingen.
ik zou graag een soort monitor willen zien dat als er meer dan 500 mails worden verstuurd dat er een mailtje naar mij wordt gestuurd, deze wordt dan weer door gestuurd naar mijn gsm.
Je zou een sendmail wrapper kunnen (laten) schrijven die dit voor je doet. Volgens mij hebben we vroeger nog wel eens een sendmail wrapper gebruikt. Moet ik even opzoeken dan.
Kijk, dat ging vrij vlot.
Ongetest, maar zou moeten werken. Wat het doet is een log entry maken voor elke keer dat sendmail wordt aangeroepen. Iemand met perl kennis zou er vast iets leukers van kunnen maken.
# service exim stop
# mv /usr/sbin/sendmail /usr/sbin/sendmail.wrapper
# nano /usr/sbin/sendmail
Het volgende pasten:
#!/usr/local/bin/perl
# use strict;
use Env;
my $date = `date`;
chomp $date;
open (INFO, ">>/var/log/spam_log") || die "Failed to open file ::$!";
my $uid = $>;
my @info = getpwuid($uid);
if($REMOTE_ADDR) {
print INFO "$date - $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME n";
}
else {
print INFO "$date - $PWD - @infon";
}
my $mailprog = '/usr/sbin/sendmail.wrapper';
foreach (@ARGV) {
$arg="$arg" . " $_";
}
open (MAIL,"|$mailprog $arg") || die "Cannot open $mailprog: $!n";
while (<STDIN> ) {
print MAIL;
}
close (INFO);
close (MAIL);
Saven en nano afsluiten.
# chmod +x /usr/sbin/sendmail
# touch /var/log/spam_log
# chmod 0777 /var/log/spam_log
Exim starten:
# service exim start
Monitoren:
# tail -f /var/log/spam_log
Werkt het niet, kun je alles weer terugzetten via
# service exim stop
# rm -f /usr/sbin/sendmail
# mv /usr/sbin/sendmail.wrapper /usr/sbin/sendmail
# service exim start
Nogmaals, dit is ongetest, dus echt op eigen risico.
kan je even uitleggen wat dit doet?
Snap er geen reed van namelijk :-)
Dit logt alleen, ...
Er is dit weekend voor ongeveer 100GB aan spam mail verstuurd via 3 accounts.
een beetje vervelend voor de klant maar ook voor ons.
Dennie-DeTi
06/02/06, 10:37
Het limiteren lijkt me ook niet heel handig, als iemand zelf wel een mailing wil versturen kan die dat niet doen.
Ik zou gewoon alle klanten op de hoogte brengen van dit soort problemen en hun uitleggen hoe ze hun script aan kunnen passen zodat het niet kan gebeuren. Volgens mij is dat 1 of 2 regeltjes extra code die ze moeten gebruiken.
- Dennie
[blabla over PHP 4.4.2]
Edit: Te vroeg gejuicht, PHP 4.4.2 fixt dit helemaal niet :(
wij adviseren alle klanten om gebruik te maken van formmail.pl dit is toch weer iets veiliger.
Ik ben van mening als we dit willen tegen gaan dat er inderdaad anderde dingen niet meer werken.
Hmm we kijken het maar even aan.
upgraden naar 4.4.2 is een goed idee, onze nieuwe servers gebruiken dit al, oudere servers nog niet.
Origineel geplaatst door snaaps
kan je even uitleggen wat dit doet?
Snap er geen reed van namelijk :-)
Dit logt alleen, ...
Er is dit weekend voor ongeveer 100GB aan spam mail verstuurd via 3 accounts.
een beetje vervelend voor de klant maar ook voor ons.
Dit logt ook de locatie van het bestand die mogelijk spam verstuurt, niet het bestand zelf zover ik me kan herinneren.
Geeft je in ieder geval iets om verder mee te werken.
Ik vraag me eigelijk af wat jullie nu doen in zo,n geval.
Zijn er hosters die die door rekenen aan hun klanten?
(ergens gelezen)
Ik vindt niet dat de klant hier de dupe van hoeft te zijn.
Wel hebben wij 1 klant gewaarschuwd dat als het nog een keer gebeurd dat wij het dataverkeer zullen gaan door rekenen. Dit omdat wij verleden week al vermeld hadden dat zei hun script moesten aanpassen naar formmail. dit was niet gebeurd. en hopa weer 50GB aan spam verstuurd.
Origineel geplaatst door Mikey
Die funtie is hardstikke goed, de scripter is hier toch echt wel de schuldige!
Toch echt niet.
De functie laat het toe dat je meerdere e-mail adressen 'inject' in een variabele die expliciet bedoeld is voor een enkel e-mail adres of subject e.d.
Verderop in de functie kun je namelijk je additionele headers (dus BCC: e.d.) toevoegen.
Kortom; het is het wel degelijk een foutieve implementatie in PHP zelf.
Neemt niet weg dat scripters in hun code moeten voorkomen dat deze misbruikt wordt.
//edit: typo
Ik denk dat je beter een dergelijk script als onderstaand kunt verspreiden onder je klantenkring, of aan de mensen die er problemen mee hebben:
<?php
function secure($input) {
return str_replace("\n", "", str_replace("\r", "", $input) );
}
foreach($_POST AS $name => $value) {
$_POST[$name] = secure($value);
}
?>
Ik zou (in het geval van alle scripts aanpassen) de mail() functie laten stoppen op het moment van header injection.
Anders krijg je alsnog 50000 bouncemails terug :(
Origineel geplaatst door Easewood
Ik zou (in het geval van alle scripts aanpassen) de mail() functie laten stoppen op het moment van header injection.
Anders krijg je alsnog 50000 bouncemails terug :(
Of een php-explode op de newlines waardoor je enkel het eerste mailadres gebruikt ;)
Wat is een voorbeeld van een inject ?
Nee, het is niet dat ik het zelf wil doen.
In het Subject form field iets zetten van
"Hallo\n
Bcc: aaaa@aol.com, bbbb@aol.com, cccc@aol.com\n\n
Hello do you want VIAGRA?\n\n"
Waarbij \n een regeloverloop is.
Klote PHP.
FransVanNispen
07/02/06, 14:49
Je mail form wordt dan op een andere server gedraaid, of een verzend script wordt aangeroepen, en de spammer vult zelf de data.
Op regels als 'Subject' wordt dan via het eigen script een '\nbcc: spam@email.tld' toegevoegd, waardoor de mail header dus wordt uigebreid.
Je moet er dus voor zorgen dat het niet mogelijk is om voor velden die bedoeld zijn voor 1 regel tekst, er meerdere in te stoppen.
Origineel geplaatst door WH-Tim
Of een php-explode op de newlines waardoor je enkel het eerste mailadres gebruikt ;)
Dan verstuur je nog steeds een spambericht :D
Nja, ik zelf gebruik gewoon een reguliere expressie voor mailforms. Misschien wel wat onhandiger qua leestekens, maar wel op en top veilig.