09-Apr-2014

Webserver updates
The WASD mailing list sent out a notice of a vulnerability of OpenSSL, nicknamed “heartbleed” and since this server is built using OpenSSL (be it the WADS version) it coul be effected as well. Mark Daniel has taken a look into his sources and plugged the hole – and the new kit has been made available, send out word and recommended a rebuild of WASD.
And since the latest version (10.3) was already planned, I did both in one go. So now the server runs WASD 10.3, linked with (WASD) OpenSSL 1.0.1G. In the process, I also updated the webmail program (now 1.7.0), and some other products are waiting. But Soymail returns an error:
Internal consistency failure ... language file. and WATCH doesn’t show anything weird..
It’s not something to be worried about too much. Just a nuisance.

31-Jan-2014

Coïncidence: NTP DOS?
Yesterday morning, Thomas Heim send out a warning on the OpenVMS SIG list that he had seen evidence on his systems of an exploit of a hole in older versions of NTP, and his warning was “Beware”.

That evening, when heading for bed, I heard my VMS server beep every few seconds. It normally does if a mail message comes in but at this rate, that means trouble.

And yes, I got loads of messages, that all concerend massive outgoing UDP traffic on port 123 – the NTP server, to a limited number of addresses but dirfferent ports on each of them. At times, there was a message concerning traffic to port 80 that was suspected to be torrent-based (quite unlikely to have UDP-traffic to a webserver…) so I got these as well.

Quite a coincidence?

Stopping the NTP server stopped the flood of messages, but after I restarted it, it restarted within a minute. So I turned my attention to the fireewall where port 123 (the standard NTP port) was still open. So I closed it and blocked all incoming traffic on port 123 – from any address.

Restarted NTP and after that, at least the flood of mail messages stopped so I wouldn’t be kept from sleeping. Whether I have to worry about time keeping remained to be seen. But a quick glance this morning reveled that time services still ru and do get an answer (the log states [Pass], so I think I don’t have to worry anymore for my time-keeping.

But there is still a lot of investigation to be done. The whole sequence styarted just after 21:00 and went on to justr after 22:00 when I stopped the NTP server; Restarted it at 22:10, the circus commenced so stopped it again at 22:11. Blocked the port in the firewall and restarted NTP at 22:16.
Just one (!) message blocked, and no problems ever since.

Next step is to investigate – as far as possible. I’ll keep the logfiles at hand (tonight they will be moved to the archives by the monthly maintenance job…).

27-Sep-2013

It’s a phisherman!
One of the sites I encountered a few days ago now appears to be a bad guy. Though the header appears to be valid:

Return-Path: internationalcardservices.notificationiare@mailing.internationalcardservices.nl
Received: from DIANA.INTRA.GROOTERSNET.NL (192.168.0.2)
by diana.intra.grootersnet.nl (V5.6-ECO5, OpenVMS V8.3 Alpha);
Fri, 27 Sep 2013 10:57:27 +0000 (UTC)
X-PMAS-MAIL-FROM:
internationalcardservices.notificationiare@mailing.internationalcardservices.nl
Received: from unknown ([87.106.96.232] EXTERNAL) (EHLO s16978676) by
diana.INTRA.GROOTERSNET.NL ([192.168.0.200]) (PreciseMail V3.2); Fri, 27 Sep
2013 10:05:41 +0000
Received: from mailing.internationalcardservices.nl ([127.0.0.1]) by s16978676
with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 12:05:28 +0200
From: International Card Services
<internationalcardservices.notificationiare@mailing.internationalcardservices.nl>
To: (my address)
Subject: Uw rekeningoverzicht bekijken en betalen
Date: 27 Sep 2013 12:05:26 +0200
Message-ID:
<20130927112751.4EA0D4FB379FEEC7@mailing.internationalcardservices.nl>
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_NextPart_000_0012_219D19A8.7D241EFA"
Return-Path:
internationalcardservices.notificationiare@mailing.internationalcardservices.nl
X-OriginalArrivalTime: 27 Sep 2013 10:05:28.0797 (UTC)
FILETIME=[17F140D0:01CEBB69]
<internationalcardservices>

and the content as welll, it is a phising attempt.
First, ICS normally sends just one reminder, and not two within a few hours. Nor will ISC send from an unknown address:

Received: from unknown ([87.106.96.232] EXTERNAL) (EHLO s16978676)

So I was triggered to check the included URL, and that is definitly NOT an ISCCards address:

href="http://www.lemrith.net/images/ICS.php"

Of course, the address has no longer access to the my network.
Lemmrith.net is actually a valid site: a small town in Germany (it is safe to check www.lemrith.net) but they have not secuired their site – given the fact that someone dropped a .PHP file on thein images directory. They have been notified.

One message, many phishing attempts

The spam filter does a good job in blocking messages, and at times I take a look on what reasons a message is blocked – especially where the reported sender (From: in the header) is one I could expect a mail from.

One such message I received today, it appears to be sent by LinkedIn, but the ful header told me otherwise:
From: "LinkedIn.Invitations" <4930A7EA@binggu.net>
Forged, no doubt.
The full header showed more information on why:
Return-Path: 4930A7EA@binggu.net
Received: from DIANA.INTRA.GROOTERSNET.NL (192.168.0.2)
by diana.intra.grootersnet.nl (V5.6-ECO5, OpenVMS V8.3 Alpha);
Wed, 17 Oct 2012 07:32:51 +0000 (UTC)
X-PMAS-MAIL-FROM: 4930A7EA@binggu.net
Received: from unknown ([190.65.67.127] EXTERNAL) (EHLO [190.65.67.127]) by
diana.INTRA.GROOTERSNET.NL ([192.168.0.200]) (PreciseMail V3.2); Wed, 17 Oct
2012 02:45:11 +0000
From: "LinkedIn.Invitations" <4930A7EA@binggu.net>
To: <willem@grootersnet.nl>
Date: Tue, 16 Oct 2012 21:44:55 -0500
Subject: Invitation
Message-ID: <20121016214455.5D4E447FEC53518BE995C.JavaMail.app@WISAJUWIJHO-PC>
Accept-Language: en-US
Content-Language: en-US
x-linkedin-template: inv_exp_member_02
x-linkedin-class: INVITE-MBR
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-PMAS-External: unknown [190.65.67.127] (EHLO [190.65.67.127])
X-PMAS-Software: PreciseMail V3.2 [121016] (diana.intra.grootersnet.nl)
X-PMAS-REP_URI-PHISH: URI reputation check: Known phishing URI (5.000)
X-PMAS-REP_URI-PHISH: URI reputation check: Known phishing URI (5.000)
X-PMAS-REP_URI-PHISH: URI reputation check: Known phishing URI (5.000)
X-PMAS-REPUTATION_URI_SPAM: URI reputation check (1.000)
X-PMAS-VMF-OK: Envelope FROM: check: Source accepts mail for address (0.000)
X-PMAS-HDR-FROM_HAS_MIXED_NUMS: From: contains numbers mixed in with letters
(0.000)
X-PMAS-HDR-CTYPE_JUST_HTML: HTML-only mail, with no text version (1.500)
X-PMAS-HDR-RCVD_FROM_UNKNOWN: Message received from host without DNS entry
(4.000)
X-PMAS-BDY-TEENY_FONT: Message tries to hide text in teeny-tiny font (5.000)
X-PMAS-META-DEAR_EMAIL_ADDR: Message has "Dear user@domain" greeting (4.000)
X-PMAS-Final-Score: 20.500
X-PMAS-Spam-Level: ********************+
X-PMAS-Spam: Yes
X-PMAS-Quarantined: PreciseMail
X-PMAS-Filename:
PMAS_ROOT:[QUARANTINE.121017.C]SPAM$2012101702451912WIL279F70EA.SPAM

The fact it was sent from another domain than LinkedIn is sufficient reason, and so is each of the known phishing URI messages. To get some insight, I accepted it for easier examination (PMAS’ output is not really helpfull in these), and examined it using the webmail client:

Apart that the greeting is weird (Why would LinkedIn use my email address?) and the content is absolutely rediculous – if some company would request something like this, I would most cetainly NOT accept…), that should raise suspision in the first place. And as it turned out, each link shows a site that appears to be hacked, but some have taken action already (or the hack missed it’s target):

The accept button refers to “http://www.erlebnistour-lausitz.de/a5KYrCG/index.html” (404: Not Found)
The Ignore button refers to “http://mardamusic.com/frH62gSL/index.html”
The signature refers to “http://www.cypressgardenservices.org.uk/AN7iR9/index.html” (403: Forbidden)
“Unsubscribe” refers to “http://www.datalogger.gen.tr/Gw5enj3X/index.html”
“Learn why we include this” refers to “http://ftp.koneks.com.tr/G6mWAUPs/index.html” (404: Not Found)

I’ve investigated similar attempts before, but normally, all possible links refer to the same site. So this one is more elaborate.

Each site does exist, and each site now has a directory added that has a random name. I’m rather suspicious in these cases, my expectation is that the docroots of these sites are not set to ReadOnly, or even inaccessable from the outside, and that someone was able to push data onto these roots – phishing, for instance, or for installing a trojan.

So I installed lynx on Diana. This is a text-only web-browser that allows you to examine the full content, and does not execute any scripting immediately – you are able to store it on disk. Though it is available on many platforms, including Windows, the investigation is done on VMS – because that is virtually immune for malware 🙂
Next, I accessed the first site, and I got the message “Connecting to server”. It comes from the HTML source like:

<html>
<table width="275" border="1" cellpadding="3" bordercolor="#0000FF"><tr><td><div align="center">Connecting to server...</div></td></tr></table></html>

next, there are three pieces of javascript, different per accessable site:
<script type="text/javascript" src="http://mediaess.com/LBXxwGQa/js.js"></script>
<script type="text/javascript" src="http://s154138659.onlinehome.us/FDaCCZkr/js.js"></script>
<script type="text/javascript" src="http://www.baumbach-keramik.de/LwAH4gUo/js.js"></script>

and
<script type="text/javascript" src="http://location-vallee-aspe.com/xSmXWBZW/js.js"></script>
<script type="text/javascript" src="http://patitaspets.com/C44cbsPE/js.js"></script>
<script type="text/javascript" src="http://videosxxx.bz/yYJZQt0x/js.js"></script>

and the file ends normally

</body>
</html>

That code may cause the installation of malware, so next I accessed the first javascript file (at mediaess.com) and I got:
[trans.gif] [logo_sl_header.gif] HACKER SAFE certified sites prevent over 99.9% of hacker crime. [text_sl_pnums.gif]
[pic_sl_livechat.gif]

HOME PRODUCTS SUPPORT TESTIMONIALS AFFILIATES ABOUT US VDECK

[sl_snav_sublinks.gif]
Customer Login
Username:
_____________________
Password:
_____________________
Log In
[sl_indexv2_midcurve.gif]

This site has been suspended

If you manage this site and have a question about why the site is not available, please contact us directly.

Home | Hosting | Support | Testimonials | Affiliates | About Us | Site Map | Web Site Hosting
Copyright © 2007 StartLogic. Read our Terms of Service. All rights reserved.

[trans.gif]
so I wondered….If I would access the link under “Customer name” a cookie would have been placed – but I refused that.
Same for the third and sixth one, that directly referred to the home page, but without login and the third one requesting a cookie, that I did accept.
The second and fourth cannot be accessed (403, the fourth stating this access required authentication)
But the fifth indeed carried a javascript file js.js, that I store on disk to examine. It runs a piece of PHP code:

document.location='http://2.bajawinery.com/links/assure_numb_engineers.php';

but when I accessed that URL, the host 2.bajawinery.com, could not be found – from Diana anyway.
Running TCPIP$DIG however, did find that site, but not as expected:
$ dig bajawinery.com
;; reply from unexpected source: 188.142.0.6#53, expected 192.168.0.33#53

; < <>> DiG 9.3.1 < <>> bajawinery.com
;; global options: printcmd
;; connection timed out; no servers could be reached
$
but this is a DNS server at my ISP.

The state may have been changed and action taken, and I couldn’t find the cookie I saved…so there the trail ended….

11-Apr-2011

Identiy Theft
Since yesterday there seems to be quite some messages around that use my email-address in Return-Path:, From: (as the real address for a nickname) or Reply-To:. I _know_ these messages don’t come from my site, since they all lack the address of my mail server.

For example (of course, the email address of the recipient is removed)


Return-Path: <willem@grootersnet.nl>
Received: from [93.62.200.186] (93-62-200-186.ip24.fastwebnet.it [93.62.200.186])
by mx1.xxx.xx (8.13.1/8.13.1) with ESMTP id p3B88VmN013149
for <xxx@xxx.xx>; Mon, 11 Apr 2011 10:08:31 +0200
Message-ID: <c61a10a054ccaae438328276ee88c61a(JFR4IU1>
From: "clementius zhigang" <willem@grootersnet.nl>
To: "dionisio kaveh" <xxxx @xxx.xx>

Received: from [151.56.14.97] ([151.56.14.97] verified)
by post.yyyy.yy (CommuniGate Pro SMTP 4.2.8)
with ESMTP id 60263607 for yyyy@yyyy.yy; Mon, 11 Apr 2011 10:05:26 +0200
Date: 11 Apr 2011 08:31:04 +0100
From: “lane jamie” <willem@grootersnet.nl>
X-Priority: 3
Message-ID: <503249808.201104110902@grootersnet.nl>
To: “car zhigang” <yyyy@yyyy.yy>

This way, you may end up in any spam database – without your fault.

The addresses from where these messages were sent are as follows – if I read the headers well:

from [93.62.200.186] (93-62-200-186.ip24.fastwebnet.it [93.62.200.186])
from [151.56.14.97] ([151.56.14.97] verified)
from [84.14.117.130] (HELO host.86.241.23.62.rev.coltfrance.com)
from [208.124.242.230] ([208.124.242.230] verified)
from 15.Red-80-36-135.staticIP.rima-tde.net (80.36.135.15)
from [116.68.64.53] ([116.68.64.53])
from [95.76.105.228] (unknown [95.76.105.228])
from [151.56.14.97] (unknown [151.56.14.97])
from [117.194.41.73] (unknown [117.194.41.73]) (this is a tricky one)
from [194.152.245.26] (unknown [194.152.245.26])
from [117.194.41.73] [117.194.41.73]
from LSt-Amand-152-31-19-235.w193-253.abo.wanadoo.fr ([193.253.222.235])

and that may hold a clue to the originator of the message.

If a mail has it’s origin form my site, it will ALWAYS carry the mailserver as a receiver – either from itself, if I use the web mail client, or as the site’s mail server, as is described in this page

I’m not sure yet what the next step might be. Post the whole bunch at the police and let them have it? Because accessing each postmaster, or domain owner, is way too much work – and at times, even POSTMASTER@target.domain does not exist (despite the fact the standards prescibes the identity…)