A couple of days back I received an e-mail from Deutsche Bank. I’m not a customer from DB. About a year ago I applied for some information and I guess my email addresses ended up in their mailinglist.
The mailing warns customers that there is a phishing attack ongoing. According to the mail, once infected, a virus on your computer lures you to a fake page where you are asked to enter your details.
So far so good. It seems like a good practice that banks try to warn their customers.
The mail contains a couple of links that should point you to sites that allow you to check if you are infected or not. Unfortunately the links point to another website. That website seems to have nothing to do with DB. It is a website for a “relationship marketing suite”. It is understandable that DB uses an external company to handle their mailings but I don’t get it … The message to their customers is “be on your guards” and then they ask you to click on a link that has nothing to do with DB?
The video of the Dan Kaminsky presentation of the DNS cache bug is available on the Black Hat site. It’s a 100 MB download but it sure is worth it. There’s also an MP3-version.
Op m’n werk moet ik vrij regelmatig meldingen in verband met malware doorsturen naar de abusedesk van Skynet / Belgacom. De meldingen bevatten altijd de url met de malware, ip-adres van de machine, ‘n timestamp en tijdzone en ‘t type van malware. Veel meer kan je moeilijk aanleveren dacht ik.
Wat krijg je dan na 7 dagen (je kan dan nog moeilijk van ‘n auto-responder spreken) :
Unfortunately, we do not have enough information to search for the perpetrator.
Therefore we need the following information:
* a logfile with the date, hour, IPaddress and GMT time.
With this information there is a bigger chance that we find the perpetrator.
“A logfile”. Van wat? Van de machine met de malware, euh, die door Belgacom / Skynet beheerd is? Je zou er kunnen meelachen … mocht’t niet zijn dat de malware er simpelweg wel blijft staan … Zucht.
The DNS cache poisoning attacks (see VU#800113) / vulnerabilities that are going to be disclosed on the next Black Hat are attracting a lot of attention.
People are commenting (here and here) whether or not the cat has been let out of the bag or not. The exploit has been out there all the time … so what’s the (new) fuzz? Deal with it and apply the patches. Because of the nature of the patch (using ‘random’ ports) proper testing is required and certain environments might require a change in their firewall policy.
The people at DNS-OARC have a dns server that you can use to test if your resolver is using random ports.
$ dig +short porttest.dns-oarc.net TXT
Alles voor de kunst. Ook het goed fatsoen door de afvoer me dunkt.
Op Dimva 2007 een heel interessante lezing gevolgd van Bojan Zdrnja. Hij vertelde op’n heel simpele manier hoe hij aan de hand van de queries op DNS-servers het gedrag van botnets (en malware in het algemeen onderzocht).
… later meer …
Powered by ScribeFire.
Op de blog van Neil Carpenter, een medewerker van Microsoft van het PSS Security Support Team, valt er een interessant artikel te lezen over een ARP Cache Poisoning Incident.
De auteur beschrijft een situatie waarbij bij welke web-request een iframe werd ingevuld. Na hun onderzoek kwamen ze er op uit dat de invoegingen gebeurden via’n gehackte machine die zich via ARP packets als de nieuwe default gateway bekend maakte.
De worm Worm.Delf.fs is één van de nieuwe wormen die gebruikt maakt van deze techniek.
Beroepshalve spendeer ik heel wat tijd met het doorsturen van computerbeveiligingsincidenten (phishing, botnetcontrollers, open relays, …). Wanneer het om ip’s in onze eigen (klanten)range gaat dan kan ik terugvallen op een interne database van contactpersonen en is het over het algemeen heel eenvoudig om de juiste persoon te bereiken.
Oh ramp als er iemand “extern” moet gecontacteerd worden.
Ik hou onderhand de tel niet meer bij maar de hoeveelheid websites waarbij het ontbreekt aan een “about”, “contact” of iets dergelijks pagina is gigantisch. Als het om een .be adres gaat dan zou je mogen verwachten dat het licensee-e-mailadres dat opgegeven is bij de dns-registratie soelaas zou brengen. Lekker niet dus. Nog leuker gaat het worden als het e-mailadres van de technische contactpersoon een mooie bounce geeft. Het telefoonnummer van de licensee en de tech-contact blijft tot in Sint Juttemis bellen zonder antwoord.
Er is een mooie vette RFC 2142 die poogt te beschrijven welke mail adressen er zoal zouden moeten zijn. Mooi niet dus. De bedoeling van een website is, dacht ik, informatie overbrengen. Sleutelpunt hierin lijkt mij dan ook dat bezoekers jou suggesties of opmerkingen kunnen bezorgen. Maak ze het dan ook even gemakkelijk en zorg er minstens voor dat je duidelijk weergeeft hoe je te bereiken bent.
Misschien te éénvoudig? Zorg voor dit (en dit is enkel vanuit mijn standpunt, sales ed. zullen toch andere noden hebben) :
- mailbox “abuse@mydomain” voor abuse-meldingen (zoals spam ed.)
- mailbox “security@mydomain” en “cert@mydomain” voor andere beveiligings-gerelateerde zaken
- mailbox “webmaster@mydomain”
- plaats je “abuse@mydomain” in de RIPE-database ergens bij de comments.
Oh ja, zorg er liefst voor dat de mailbox geen quota’s heeft en zo heel af en toe ook eens bekeken word.
Dank u. *cough*