Niet ontvangen...

Was ik al een beetje bang voor..

[email]Abuse@virusalert.nl[/email] is inmiddels op de hoogte.

De tekst is overigens als volgt:

Nou, dit is geen vraag maar een weet. VirusAlert ken ik al
jaren, maar dit soort mail heb ik nog nooit van ze
ontvangen. Gezien de vraagstelling (win prijzen en vul onze
enquete in) denk ik dat je er van uit mag gaan dat men aan
het hengelen is geslagen.

Krijg je wantrouwen bij een mail, dan is het ook meestal
foute boel...

Trouwens je kunt de header eens onderzoeken via de website van
SpamCop. Dan vallen automatisch de IP-adressen van de bron eruit.

Zie ook: http://vww.spamcop.com/

Laat ons even weten SirDice wat VirusAlert hierover zegt (interessant)

Yep. Ik ken virusalert ook al tijden. Het is ook al lang geleden dat ik uberhaubt iets heb mogen ontvangen van ze.

En ja, als je er uit ziet als een phish en het ruikt naar phish dan is het waarschijnlijk phish.

Headers nakijken doe ik wel met het handje, da's niet zo heel moeilijk ;)

Niet iedereen kan dat. Hoe doe je dat?

Ok.. Ik gebruik hiervoor meestal een paar tools als whois, nslookup en dig. Linux/BSD hebben deze standaard. Voor windows zijn er tools beschikbaar om te installeren maar er zijn ook websites waar je ze kan gebruiken. Bijv. http://www.dnsstuff.com/

Bekijk de bron van de e-mail. In thunderbird kun je dat doen met ctrl-U. Zoek naar de regels met Received:.

De received headers geven aan langs welke mailservers de e-mail is verzonden. Elke mailserver voegt er z'n eigen aan toe. Begin bij de Received headers van je eigen provider. Deze zijn meestal wel te vertrouwen en werk daar vandaan terug.


De regels zijn als volgt opgebouwd:
from HELO string ( dnsnaam [ ip adres ]) by ontvangende_mailserver (versienummers)
Er staat nog meer op z'n regel maar dat is voor het tracen niet zo interessant. Met het id zou je op de mailserver zelf de e-mail terug kunnen vinden. Als ontvanger kun je dat niet.

De HELO string wordt door de verzender opgegeven en is niet te vertrouwen. De dnsnaam hoeft niet altijd aanwezig te zijn. Het ip adres is het adres van de verzender. Dnsnaam en ip worden door de ontvangende mailserver gelogd.

Als je alleen al naar deze 2 regels kijkt dan zou de ontvangende mailserver kenny1.webpower.nl (in de tweede received) als verzender moeten staan in de eerste Received (van onder naar boven lezen). Hier klopt al iets niet. Als je verder kijkt naar die tweede received zie je daar als verzendend ip een RFC-1918 adres (private reeks) staan. En omdat het niet aansluit met de eerste received header kun je de tweede als fake beschouwen.

dig -x 194.9.84.153 geeft als resultaat
153.84.9.194.in-addr.arpa. 3600 IN PTR tapps.mail.dmdelivery.com.
Dat klopt dus. Een whois dmdelivery.com laat zien wie de eigenaar is.
Een whois 194.9.84.153 laat zien wie de eigenaar is van dat ip adres.
Een hosting bedrijf dus.

De whois info van het domain laat ook zien welke dns server "authoritive" zijn. Dit zijn de dns servers waar het domain op aangemaakt is. In dit geval servers van site4u.com. Creatief met nslookup
Het vetgedrukte is wat ik ingetypt heb. De mail exchange adressen zijn de mailserver die e-mail kunnen ontvangen voor dat domain. Let wel op, de ontvangende mailservers hoeven niet dezelfde te zijn als de verzendende. Hier gaan een hoop, te strak afgestelde spamfilters meestal de mist in. Een mailserver die alleen maar e-mail verstuurt hoeft geen MX (Mail eXchange) record te hebben. MX records zijn uitsluitend voor ontvangende mailservers. Bij grote bedrijven is het normaal dat binnenkomend en uitgaande mail gescheiden verwerkt worden.

Wat weten we nu? De tweede received header is fake en kan buiten beschouwing gelaten worden. De e-mail komt bij dmdelivery.com vandaan, dit lijkt een marketing bureau te zijn ( http://www.dmdelivery.com ). Deze heeft z'n mailserver gehost staan bij Trueserver.

Spam werkt op een soortgelijke manier. Alleen zul je dan waarschijnlijk bij een consumenten ISP uitkomen. Over het algemeen kun je dit middels een reverse lookup dig -x ipadres en whois ipadres zien. Meestal staat daar ook een abuse adres. Daar zou je de bron van de e-mail heen kunnen sturen zodat zij die klant kunnen waarschuwen. Zet in de abuse e-mail verder geen whois, nslookup en/of andere traces. Dat doen ze zelf wel en door dat allemaal mee te sturen loop je het risico dat jouw abuse e-mail genegeerd wordt.

Het is een heel verhaal geworden en ik hoop dat het een beetje over komt. Door dit een paar keer zelf gedaan te hebben wordt het vanzelf duidelijk. Anders hoor ik het wel ;)


Edit: Nog even verder gekeken naar die kenny1.webpower.nl. Opvallend is namelijk dat in de SPF string van dmdelivery.com ook een kenny1 staat. Kenny1.webpower.nl resolved niet, kenny1.dmdelivery.com wel. Er is een dikke kans dat de tweede received header gegeneerd is door een interne server van dmdelivery. Dat verklaart ook het rfc-1918 adres. Leuk om te zien zo dat er op deze manier interne netwerk informatie wordt prijsgegeven, wat wel vaker voorkomt. Als security professional bij een bedrijf moet je hier dus ook op letten. Meestal kun je de uitgaande mailserver wel zo configureren dat de received headers van de interne mailservers verwijderd worden voordat de e-mail het internet op geslingerd wordt.

Heb deze phish hierjuist ook ontvangen, zeer vreemd....

Ik heb helaas nog geen reactie van virusalert gekregen. Maar omdat het van een marketing bureau afkomt lijkt het een
legitieme enquete. Wat ik altijd zo jammer vind is dat dit soort e-mails nooit echt terug te leiden zijn naar de
opdrachtgever. Verder ook geen berichtje op de website van de opdrachtgever. Stel je voor dat het van je bank is. We
worden plat gegooid met phishing e-mails, iedereen waarschuwt dat je goed moet kijken waar de links naar
toegaan etc. en dan doen ze dit soort acties..