News items for tag security - Koos van den Hout

Usernames seen in ssh attempts: 0 1 a a0 adm admin admln agnes ajay apache ask bin byte cactiuser CarpeDiem cisco cs daniel data db2inst1 debian D-Link erp ezrena faxadmin ftp ftpuser glassfish gpadmin guest help jesus lancer maile mailers marifer maronique media mis mysql nodeclient ooooooooo opuser oracle perl personnel pi pig PlcmSpIp postmaster postpone remote root roote rppt sales shop student support test testing ts ts3 turbo ubnt ubuntu user vnc wildfly willy xbmc And the '' username (empty string). By numbers root has the highest number of attempts.

We zijn verzekerd bij Unive, en daarover ontvang ik een mailtje:

Subject: Document(en) bij uw pakket xxxxxxxx

Geachte heer ..

Hierbij ontvangt u het overzicht van uw verzekeringspakket. Wilt u
controleren of de gegevens juist zijn?

Mijn eerste gedachte was om het attachment direct naar een analysestraat voor malware te sturen, maar we zijn inderdaad bij hun verzekerd en het mailtje was gericht aan het adres wat ik gebruik om met Unive te communiceren. Alleen lijkt het subject wel erg op de mailtjes die ik zie met de nieuwste ransomware.

Dus toch maar eens de pdf geopend en daar bleek ook een 'acceptgiro' in te zitten. Dus het was nogal vitaal om dat bestand te openen en door te lezen.

Ik wilde dus Unive op de hoogte stellen van het feit dat ze nogal onhandig communiceren. In het e-mail bericht staat:

Heeft u nog vragen of opmerkingen, neem dan gerust [2]contact met ons op.

Met een verwijzing naar https://www.unive.nl/klantenservice. Alleen als ik daar mijn verbetersuggestie probeer in te voeren moet ik om het bericht te mogen versturen ook perse een adres en een geboortedatum geven, en is het optioneel om zelfs mijn burgerservicenummer te geven.

Voor het verwerken van mijn suggestie zijn die gegevens niet nodig en het zou dus heel handig zijn als er een contactoptie was waarbij die gegevens niet gevraagd worden. Dit is geen privacy by design.

I was plagued by thunderbird/enigmail in one installation not wanting to send PGP-encrypted messages. It took me a while to debug because I seemed to be the first one to come across it. The error messages are not very helpful with a lot of SIGEXPIRED in them followed by a KEYEXPIRED. I found someone with probably the same problem at Enigmail stopped working: KEYEXPIRED/SIGEXPIRED - Super User but no usable answer at that time.

Searching further found me [Enigmail] enigmail won't let me encrypt messages anymore which does show another problem with old keys in the further thread. I started removing old keys showing with '00 00 00' fingerprints until I found my old 'home' key in the ring (0x2C663B5DF0D7C263). After that the error message changed to the key being unavailable. I dug through ~/.gnupgp/gpg.conf looking for mentions, and found:

#default-key F0D7C263

already disabled, and:

encrypt-to F0D7C263

when I changed that last one to a newer and better fitting key the problem was solved. There was a mention of F0D7C263 at the end of the enigmail error message but it was hard to draw conclusions about what it was doing there.

So as usual: good encryption is hard. And good error messages are hard too. I added a suggestion to the superuser.com message so others may spend less time debugging this problem.

At work we (indirectly) get the scanning results from Shadowserver which now includes open VNC servers which is yet another service we don't really want left open to the Internet in general. A few were found which are now actively chased after to get them firewalled/disabled.

I really like the concept of shadowserver. ISPs that want the information can get full overviews of insecure services and botnet activity on their network. A full overview of what shadowserver looks for can be found at The scannings will continue until the Internet improves - Shadowserver.

Currently over half of the incoming TCP SYN packets logged and dropped in my firewall are for port 23 or port 2323. According to on-line sources this is all related to the Mirai botnet and copycats of that botnet.

An interesting scam mail received in several of my inboxes:

To: abuse@...
Subject: you've been scammed

Your email abuse@... has been hacked and spam is sent to all your contacts!
If you don't have a lawyer, you may contact me at mark.silberman78@gmail.com

Best Regards,
Mark

I guess 'Mark' bought the cheapest available list of spammable addresses and is now trying to profit from the people spammed.

The other variation is with

Subject: You are hacked!

But with everything else exactly the same.

Update: I am getting some responses to this post, other people are seeing this spam too. I guess I was just the first one to write a post about it, since I usually like to link to posts showing I am not the only one. Hello visitors puzzling about this spam!

Update II: It's not just me! Also noted at You are hacked or scammed - hoax.co

I noted some weirdness:

tcp        0      0 xx.xx.xx.xx:http    141.138.130.37:http     SYN_RECV   

Variation on earlier Don't try to use my system to attack another. I viewed the traffic with p0f and noticed there isn't variation in the sources now:

95.131.186.32:80 - UNKNOWN [8192:59:1:40:.:.:?:?]
  -> xx.xx.xx.xx:80 (link: unspecified)
95.131.186.32:80 - UNKNOWN [8192:59:1:40:.:.:?:?]
  -> xx.xx.xx.xx:80 (link: unspecified)
141.138.130.37:80 - UNKNOWN [8192:51:1:40:.:.:?:?]
  -> xx.xx.xx.xx:80 (link: unspecified)
141.138.130.37:80 - UNKNOWN [8192:39:1:40:.:.:?:?]
  -> xx.xx.xx.xx:80 (link: unspecified)
141.138.130.37:80 - UNKNOWN [8192:39:1:40:.:.:?:?]
  -> xx.xx.xx.xx:80 (link: unspecified)
95.131.186.32:80 - UNKNOWN [8192:67:1:40:.:.:?:?]
  -> xx.xx.xx.xx:80 (link: unspecified)
95.131.186.32:80 - UNKNOWN [8192:43:1:40:.:.:?:?]
  -> xx.xx.xx.xx:80 (link: unspecified)

All trying to make my system take part in an attack on 141.138.130.37 and 95.131.186.32, both part of "William Hill Organization" on Gibraltar.

The rules saying that I want to limit the amount of outgoing tcp syn/ack packets to one IP are working. Of course the real source of the attack is some network that does not implement BCP38 source address filtering.

Lots of reporting on the recent DDoS attack on Dyn infrastructure tells that (part of) the attack came from insecure "Internet of Things" (IoT) devices.

Lots of devices with some 'Internet' network capabilities are being produced, and the new owners of those devices have little interest in patching them being only a reasonable small part of the DDoS attacks and the makers have little interest in securing them since that will not sell one more device.

In the mean time, I see an increase in scans on ports 23 and 2323 which seem to be the default ports used to remotely access some of the vulnerable devices.

Don't fall for it..

I received spam which translates (to me) very clearly to 'be a money mule':

[..] is looking for a qualified representative, reliable, efficient and dedicated to help facilitate their business transactions in Australia. The work is based on administrative / customer service support improving productivity and above all performing basic banking transactions.

We are located in the London If you are satisfied with all the conditions and wish to register, please contact our Human Resources department at [.. generic webmail account ..]

Alerting items:

• Unsollicited e-mail (spam) sent to a random address
• Lots of buzzwords but the work seems to be "basic banking transactions"
• Doing transactions in Australia but located in London
• Using a generic webmail account

In the incoming spam this morning:

See attached Bill Of Laden.

[-- Attachment #2: Shipping_Documents.ace --]

I had never heard of .ace files, but I miss some developments. So I asked:

$ file Shipping_Documents.ace
Shipping_Documents.ace: ACE archive data version 20, from Win/32, version 20 to extract, contains AV-String (unregistered), solid

So it is an archiving format, better described at ACE (compression file format) - Wikipedia. There is an unace for linux, and this gave me:

RFQ#0929919882.exe: PE32+ executable (GUI) x86-64 Mono/.Net assembly, for MS Windows
c04e10a084657473828a03a97c82f0a9  RFQ#0929919882.exe

Which is obviously not shipping documents but an executable. Looking at the file showed some dangerous function names.

In the incoming spam I noticed some unsollicited attachments, always a sign of danger. In this case with excel files (application/vnd.ms-excel) so I checked those with olevba, part of the oletools package.

And indeed there was macro code to be run at startup, with multiple warnings about suspicious behaviour, such as usage of "command" which can run PowerShell commands.

Having a look at the code showed very clearly that the macro was up to no good! I am used to quite interesting attempts at obfuscating macro code, so it was funny to see this bit with olevba:

Call Shell("rund" & "ll32.exe " & firmaVENIKOVNETUUUKA & ",qwerty", vbHide)

The url where the malware is downloaded was also quite readable in the macro.

In eerdere berichtgeving over de inval bij Ennetcom moest ik wel heel goed luisteren om niet de conclusie te trekken dat PGP 'alleen' gebruikt wordt door criminelen, NOS Journaal 20:00 19 april 2016, Paniek in onderwereld door gekraakte telefoons - EenVandaag.

Maar vandaag viel me op in artikel Politie krijgt toegang tot versleutelde communicatie criminelen - nos.nl dat er een paragraaf staat:

PGP is een veelgebruikte methode om veilig te communiceren en wordt niet alleen door criminelen maar ook door bijvoorbeeld journalisten en klokkenluiders gebruikt. Bij PGP worden berichten door elkaar gehusseld, zodat ze alleen leesbaar zijn voor mensen met een bepaalde encryptiesleutel.

Hier kan ook aan toegevoegd worden dat computerbeveiligers graag PGP gebruiken om hun berichten te ondertekenen en/of te versleutelen.

Uit de bijbehorende beslissing van de Canadese rechter op het internationale rechtshulpverzoek (Engelstalig) blijkt wel dat er helemaal geen lek in PGP is gevonden maar dat Ennetcom niet zo heel goed was in cryptobeheer:

In this case, the Dutch authorities discovered that the Ennetcom PGP BlackBerry devices were only able to communicate via PGP encrypted e-mail with other Ennetcom PGP BlackBerry devices connected to the same Ennetcom network. The Dutch authorities also discovered that the “keys” for the PGP encryption system were generated by the server, rather than by the device. As a result, the Dutch authorities came to believe that the keys to decrypt the PGP encrypted information, on the Ennetcom PGP BlackBerry devices, are stored on Ennetcom’s BlackBerry Enterprise Servers.

The whole news about the "Evil32" attack on PGP keys made me have a long look at the key I used at home for my private e-mail, which was already almost 18 years old. Opinions about the best use of PGP have changed, risks have changed. So I followed some advice from Creating the perfect GPG keypair - Alex Cabal although 'perfect' is a bit overdone. I added the subkey for normal use, added a picture and cross-signed the new key with the old key. But in the end, the new key for my private e-mail addresses is:

pub   4096R/0x5BA9368BE6F334E4 2016-09-05 [expires: 2021-09-04]
      Key fingerprint = 979B CF89 EBBF 9AC9 6A14  F56A 5BA9 368B E6F3 34E4
uid                            Koos van den Hout <koos@kzdoos.xs4all.nl>
uid                            Koos van den Hout (http://idefix.net/) <koos+website@idefix.net>
uid                            [jpeg image of size 11615]
uid                            Koos van den Hout <koos@idefix.net>
sub   4096R/0x308216DA78517E3D 2016-09-05 [expires: 2021-09-04]
sub   4096R/0x3B17C9ABE4A3C916 2016-09-05 [expires: 2021-09-04]

The key is now available via my PGP page and via the keyservers: 0x5BA9368BE6F334E4 on the keyservers

Now the next step is to start collecting signatures.

Recently there was some news about Duplicate PGP Keys and I looked up the keys associated with my e-mail address / short PGP id:

koos@greenblatt:~$ gpg --search-key F0D7C263
gpg: searching for "F0D7C263" from hkp server pgp.surfnet.nl
(1)     Koos van den Hout <koos@kzdoos.xs4all.nl>
          1024 bit RSA key 7BB7472D18B1B64D20BD63E9B81DABE5F0D7C263, created: 2014-06-16 (revoked)
(2)     Koos van den Hout <koos@idefix.net>
        Koos van den Hout <koos@wu-ftpd.org>
        Koos van den Hout <koos@pizza.hvu.nl>
        Koos van den Hout <koos@kzdoos.xs4all.nl>
        Koos van den Hout (http://idefix.net/) <koos+website@idefix.net>
          1024 bit DSA key 1B8F6AA16EF5949871CBE48E2C663B5DF0D7C263, created: 1998-12-17
Keys 1-2 of 2 for "F0D7C263".  Enter number(s), N)ext, or Q)uit > q

As visible the "fake" key is already revoked. The NCSC article has a lot more explanation.

The key I currently use for my private e-mail has:

pub   1024D/0x2C663B5DF0D7C263 1998-12-17
      Key fingerprint = 1B8F 6AA1 6EF5 9498 71CB  E48E 2C66 3B5D F0D7 C263
uid                            Koos van den Hout <koos@kzdoos.xs4all.nl>
uid                            Koos van den Hout <koos@idefix.net>
uid                            Koos van den Hout (http://idefix.net/) <koos+website@idefix.net>
sub   2048g/0x85019597CD125A2B 1998-12-17
sub   4096g/0xCC166EB91F480E9A 2011-01-11 [expires: 2017-09-14]
sub   2048R/0x8F414665C4B517C1 2015-09-15 [expires: 2017-09-14]

And on 2016-09-05 I decided it was time for a new private e-mail GnuPG/PGP key anyway:

pub   4096R/0x5BA9368BE6F334E4 2016-09-05 [expires: 2021-09-04]
      Key fingerprint = 979B CF89 EBBF 9AC9 6A14  F56A 5BA9 368B E6F3 34E4
uid                            Koos van den Hout <koos@kzdoos.xs4all.nl>
uid                            Koos van den Hout (http://idefix.net/) <koos+website@idefix.net>
uid                            [jpeg image of size 11615]
uid                            Koos van den Hout <koos@idefix.net>
sub   4096R/0x308216DA78517E3D 2016-09-05 [expires: 2021-09-04]
sub   4096R/0x3B17C9ABE4A3C916 2016-09-05 [expires: 2021-09-04]

But if you really want to be sure check in person.

I updated my .gnupg/gpg.conf with:

keyid-format 0xlong

to always show the longer key ID.

Today I saw an incoming e-mail about a voicemail message, while I was expecting a voicemail message. The format was quite similar to the format used by my telephone provider so I tried opening it in thunderbird under Linux. That saved me, it was aimed at opening in Windows, probably only working in Microsoft Outlook.

This is what it looked like in mutt:

Dear koos :
        There is a message for you from 01427157659, on 2016/08/23 15:52:17 .
You might want to check it when you get a chance.Thanks!



[-- Attachment #2: Voicemail sound attachment. --]
[-- Type: audio/x-wav, Encoding: base64, Size: 10K --]

[-- audio/x-wav is unsupported (use 'v' to view this part) --]

The attachment is Message_from_01427157659.wav.zip but with mimetype audio/x-wav. The zip file contains:

Archive:  Message_from_01427157659.wav.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
    30764  2016-08-23 12:18   614007286106.wsf
---------                     -------
    30764                     1 file

With a lot of obfuscated scripting.

What saved me this time was opening it in a mailreader/environment which tries to play an audio/x-wav file with a mediaplayer which complained about something being invalid in it.

For the first time I brought my new personal laptop to a place where I could use eduroam wireless network. This gave some trouble, eduroam did not work out of the box. I had to set the authentication method to 'Protected EAP (PEAP)' and set the inner authentication correct. And I had to set the CA-Certificate to check. If you don't set it, network manager settings will ask if you are sure, but if you say you are sure the net result in the background is that the request for a valid certificate is set but there is no certificate set to check against, resulting in the connection not working.

I wanted to look at some suspicious word files to see whether the macros tried anything funny. Some searching showed me oletools which can do this and report. A sample:

Public Sub ZkBWG(ByVal uSHdvTl As String)
Dim RxXFgnMOu As Integer
VOyiBpZDIb.cFRHErvQ OdAkk.VWUUdYKG(553, JocsGn("PlJlXeAhESM.MtxpOizrMccS2W")), _
uSHdvTl, JocsGn("LcxeVxVE")
End Sub
Private Function xcOdDXhiP() As Integer
Dim NJuBRTz As String
Dim RemmeQk As Integer
xcOdDXhiP = 400
End Function
Private Function JocsGn(ByVal gAVndNSJ As String) As String
JocsGn = ZYkwp.kYxFEH(gAVndNSJ)
End Function

+------------+----------------+-----------------------------------------+
| Type       | Keyword        | Description                             |
+------------+----------------+-----------------------------------------+
| AutoExec   | Document_Open  | Runs when the Word document is opened   |
| Suspicious | CreateObject   | May create an OLE object                |
| Suspicious | CallByName     | May attempt to obfuscate malicious      |
|            |                | function calls                          |
| Suspicious | Hex Strings    | Hex-encoded strings were detected, may  |
|            |                | be used to obfuscate strings (option    |
|            |                | --decode to see all)                    |
| Suspicious | Base64 Strings | Base64-encoded strings were detected,   |
|            |                | may be used to obfuscate strings        |
|            |                | (option --decode to see all)            |
+------------+----------------+-----------------------------------------+

Ik ben geen klant van ICScards maar toch wil ik soms interresante nieuwe phishing pogingen melden bij ze. Volgens Phishing: valse e-mails die in omloop zijn is de manier gewoon via e-mail naar het valse-email@ adres.

Maar helaas lukt het niet:

   ----- The following addresses had permanent fatal errors -----
<valse-email@.......>
    (reason: 550 Denied by policy)

   ----- Transcript of session follows -----
... while talking to mail01.icscards.nl.:
>>> DATA
<<< 550 Denied by policy
554 5.0.0 Service unavailable

het valse-email@ adres zit achter mailfilters die blijkbaar duidelijk herkenbare phishing mail blokkeren. Misschien moeten ze dat adres apart behandelen zodat ze dit soort meldingen wel binnenkrijgen...

I am slowly gaining trust in my Let's Encrypt setup and today I renewed my certificate. One thing I noticed on the first tries was that the whole process left me with a .well-known/acme-challenge directory in every website. Solution: use the options for a general configuration item available in Apache which is then inherited by all virtual hosts. So now I have in the general configuration:

Alias /.well-known/acme-challenge/ "/home/httpd/html/.well-known/acme-challenge/"

<Directory "/home/httpd/html/.well-known/acme-challenge/">
        AllowOverride None
        Order allow,deny
        Allow from all
</Directory>

So now there is only one directory filling up with challenge-response files which is easier to clean out. I have seen filenames for challenge response with a - at the start so rm * started to complain.

The first complete change to https is on Camp Wireless, Wireless Internet access on campsites.

This does not work as planned in mutt:

Subject: hi prnt
Content-Type: multipart/mixed; boundary=31BE31246BD934D65C63831D7238

--31BE31246BD934D65C63831D7238
Content-Type: multipart/alternative; boundary=31BE31246BD934D65C63831D7238

--31BE31246BD934D65C63831D7238
Content-Type: text/plain; charset=UTF-8



--31BE31246BD934D65C63831D7238
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br></div>

--31BE31246BD934D65C63831D7238--
--31BE31246BD934D65C63831D7238
Content-Type: application/zip; name="816847_304695.zip"
Content-Disposition: attachment; filename="816847_304695.zip"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_519392564

UEsDBBQAAgAIAPVmnUiLxtYfTRIAAA0pAAAUAAAANzM1NzE1NjJfODYzNjA4MTYuanO1Wmt3
2zaT/tye0/+A8rSvxViW7eRt0tp1u4osx67vlyTOOt4ekIQkRCRA8yJZNv3f9xmApKjY6abd

Shows as

  I     1                      [text/plain, 7bit, us-ascii, 0K]
  I     2                       [text/plain, 7bit, utf-8, 0.1K]
  I     3                        [text/html, 7bit, utf-8, 0.1K]