Nedbank fraud: Phising with anti-phising

A couple of days ago I received one more e-mail appearing to originate from Nedbank Limited. The e-mail was about some new security measures taken by the bank to prevent fraud. The e-mail, as you can see bellow, is asking the user to download the attached file which is a link to the false logon page. Having tried to access the link today appeared to not work. Probably the service provider realised this was a fake page or the incident has been reported and disabled the account. Banks never send such e-mails, never require users to confirm their details in that way. Only the bank’s official page (assuming there’s no DNS poisoning) is the most secure way to keep up to date. Even if you think there is something suspicious with the banks website, you can always call them and ask for assistance.

Nagios remote resources monitoring using SSH (check_by_ssh)

Recently I have been setting up Nagios as the increasing number of machines and services per machines can make it difficult to monitor and tell what’s wrong and what’s not or when you should pay more attention at a system or a service.

Following Nagios documentation is pretty much straight forward to set up the monitoring server. Start monitoring exposed services such as SSH, HTTP, FTP, MySQL, PostgreSQL is also straight forward. Plugins such as check_tcp and check_udp provide also an easy way to see if a service is actually running. For instance, for a CVS pserver, you can use the check_tcp script to check if port 2401 is open or not. Not the best way you should actually test a service but works OK when you want to do a check.

The systems I had to get monitored regarding their local resources were of three types: LCFG Linux, self-managed Linux and self-managed Solaris. This differentiation brings a bit of complexity on its own as they need different ways of sorting monitoring with SSH but still of course using the same principles and techniques. The easiest one is the LCFG ones as a configuration header was created and “included” in every system that needed to be monitored. That looks something like the following:

/** Configuration for monitored remote hosts.
*   This header will allow Nagios server to monitor
*   services on remote system that use this header by
*   running check_by_ssh.
**/

/** Nagios will fail to run remote command if an SSH banner is displayed **/
!openssh.sshdopts       mREMOVE(Banner)

!tcpwrappers.allow_sshd mCONCATQ(" <Nagios_server_hostname_goes_here")

!auth.extrapasswd       mADD(nagios)
auth.pwent_nagios       nagios:*:007:007:Nagios:/home/nagios:/bin/bash
!auth.extragroup        mADD(nagios)
auth.grpent_nagios      nagios:*:007:apache

/** You may add "nagios" user to the user access list of the machine depending the
authentication method **/

/** Public key authentication for 'nagios' user **/
!file.files             mADD(nagiosKey)
file.file_nagiosKey     /localdisk/home/nagios/.ssh/authorized_keys
file.type_nagiosKey     literal
file.mode_nagiosKey     0644
!file.tmpl_nagiosKey    mCONCATQ("<hey_goes_here>")

!profile.packages       mEXTRA(+nagios-plugins-1.4.13-4.el5)

/** List of plugins to be installed remotely **/
!profile.packages       mEXTRA(+nagios-plugins-disk-1.4.13-4.el5)
!profile.packages       mEXTRA(+nagios-plugins-load-1.4.13-4.el5)
!profile.packages       mEXTRA(+nagios-plugins-procs-1.4.13-4.el5)
!profile.packages       mEXTRA(+nagios-plugins-swap-1.4.13-4.el5)
!profile.packages       mEXTRA(+nagios-plugins-users-1.4.13-4.el5)

The self managed systems would make use of either a local or network “nagios” account using public key authentication and each remote system would need to have installed manually its own set of required plugins. A single compile of the plugins in the NFS home directory of the network “nagios” account might not work when you have multiple different *NIX operating systems.

I have configured the Nagios config files for remote services based on this *very* helpful and clear guide http://wiki.nagios.org/index.php/Howtos:checkbyssh_RedHat

The key point with the remote commands is to define the right commands for Nagios, pointing at the right location of the plugins remotely and passing the correct arguments. So, five remote services have been defined, as can be seen from the RPMs above: check_disk, check_load, check_procs, check_swap, check_users.

To call each remote plugin, new command definitions need to be added in /etc/nagios/commands.cfg

define command{
        command_name    check_remote_disk
        command_line    $USER1$/check_by_ssh -p $ARG1$ \
        -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_disk \
        -w $ARG2$ -c $ARG3$ -p $ARG4$'
        }

define command{
        command_name    check_remote_users
        command_line    $USER1$/check_by_ssh -p $ARG1$ \
        -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_users \
        -w $ARG2$ -c $ARG3$'
        }

define command{
        command_name    check_remote_load
        command_line    $USER1$/check_by_ssh -p $ARG1$ \
       -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_load \
       -w $ARG2$ -c $ARG3$'
        }

define command{
        command_name    check_remote_procs
        command_line    $USER1$/check_by_ssh -p $ARG1$ 
       -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_procs \
       -w $ARG2$ -c $ARG3$ -s $ARG4$'
        }

define command{
        command_name    check_remote_swap
        command_line    $USER1$/check_by_ssh -p $ARG1$ \
        -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_swap \
        -w $ARG2$ -c $ARG3$'
        }

Depending on the setup you might need to change the location of the plugins or use more options such as desirable user to login, location of keys, IPv4 or IPv6 connection, use of SSH1 or SSH2 etc… Once having defined the commands, they can be used to define services within host configuration files.

The main reason I wanted to avoid using NRPE was the fact that one more services should be exposed, even internally, from system that you want to expose only what is necessary. NRPE would be useful if Windows servers should be monitored for their resources.

Εθνική Τράπεζα Phishing

Έλαβα πρόσφατα 2 phishing emails υποτίθεται απο τη Εθνική Τράπεζα Τα μήνυμα και στα δύο ήταν όπως στη παρακάτω εικόνα:

NBG phising email

Το κείμενο του συνδέσμου μπορεί να σε πείσει αλλά σίγουρα όχι ο πραγματικός σύνδεσμος. O υποτιθέμενος σύνδεσμος στη Εθνική Τράπεζα δεν ισχύει. Ακολουθώντας τον όμως ο χρήστης βρίσκεται μπροστά από την εξής φόρμα:

Picture 2

Επίσης αρκετά πειστική για κάποιον που δεν κοιτάει το URL. Οι σύνδεσμοι πάνω δεξία είναι σωστοί και πάλι εύκολα μπορεί κάποιος να πέσει στη παγίδα. Ένα γρήγορα lookup για το domain 4unow.net δείχνει ότι ο server βρίσκεται στις ΗΠΑ:

Picture 1

Ένα whois εύκολα δείχνει τον ιδιοκτήτη:

$ whois 4unow.net
Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered

with many different competing registrars. Go to http://www.internic.net

for detailed information.

   Domain Name: 4UNOW.NET

   Registrar: GODADDY.COM, INC.

   Whois Server: whois.godaddy.com

   Referral URL: http://registrar.godaddy.com

   Name Server: NS11.DOMAINCONTROL.COM

   Name Server: NS12.DOMAINCONTROL.COM

   Status: clientDeleteProhibited

   Status: clientRenewProhibited

   Status: clientTransferProhibited

   Status: clientUpdateProhibited

   Updated Date: 01-mar-2008

   Creation Date: 21-nov-2007

   Expiration Date: 21-nov-2009

[...]

Registrant:

   4unow

   39 Waghorn Road

   Harrow, Middlesex HA3 9ET

   United Kingdom

   Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)

   Domain Name: 4UNOW.NET

      Created on: 21-Nov-07

      Expires on: 21-Nov-09

      Last Updated on: 01-Mar-08

   Administrative Contact:

      Beech, Colin  colin@4unow.co.uk

      4unow

      39 Waghorn Road

      Harrow, Middlesex HA3 9ET

      United Kingdom

      7807821626

   Technical Contact:

      Beech, Colin  colin@4unow.co.uk

      4unow

      39 Waghorn Road

      Harrow, Middlesex HA3 9ET

      United Kingdom

      7807821626

   Domain servers in listed order:

      NS11.DOMAINCONTROL.COM

      NS12.DOMAINCONTROL.COM
Κάνοντας ένα lookup και για το πραγματικό domain της Εθνικής Τράπεζας:

Picture 4
Για να είμαι ειλικρινής δε περίμενα να είναι στην Αυστραλία!

Acrobat Reader buffer overflow vulnerability

A critical vulnerability has been identified in Adobe Reader 9 and Acrobat 9 and earlier versions. This vulnerability would cause the application to crash and could potentially allow an attacker to take control of the affected system. There are reports that this issue is being exploited.

Adobe is planning to release updates to Adobe Reader and Acrobat to resolve the relevant security issue. Adobe expects to make available an update for Adobe Reader 9 and Acrobat 9 by March 11th, 2009. Updates for Adobe Reader 8 and Acrobat 8 will follow soon after, with Adobe Reader 7 and Acrobat 7 updates to follow. In the meantime, Adobe is in contact with anti-virus vendors, including McAfee and Symantec, on this issue in order to ensure the security of our mutual customers. A security bulletin will be published on http://www.adobe.com/support/security as soon as product updates are available.

http://www.adobe.com/support/security/advisories/apsa09-01.html

Quick solution to avoid unexpected behaviour, use a different PDF viewer. Alternatives are available for Linux (Xpdf, Kpdf, Evince), *BSD (Xpdf), OS X (Preview) and Windows (Foxit).

TrackMeNot

Γνωρίζουμε λίγο πολύ όλοι πως ό,τι search query κάνουμε σε κάποια από τις μηχανές αναζήτησεις συλλέγεται και στη συνέχεια συγκαταλέγεται με άλλα στοιχεία και μέσω data-mining δημιουργείται ένα προφίλ για κάθε χρήστη. Τα περισσότερα queries θα έχουν κοινά θέματα πράγμα που σημαίνει ότι οι διάφορες εταιρείες μπορούν σχετικά εύκολα να έχουν μια γενική εικόνα των ενδιαφερόντων του χρήστη.
Μια πολύ απλή λύση για να κάνει το παραπάνω έργο λίγο πιο δύσκολο είναι η χρήση του Firefox plugin TrackMeNot. Το plugin αυτό μπορεί και στέλνει τυχαία queries σε 4 μηχανές αναζήτησης (Google, Yahoo, AOL και MSN) ανά τακτά χρονικά διαστήματα (πχ 10 queries το λεπτό). Με τον τρόπο αυτό, τα πραγματικά queries του χρήστη χάνονται μέσα σε μια άλλη πληθώρα queries και “ενδιαφερόντων” που προέρχονται φαινομενικά από τον ίδιο χρήστη. Έτσι η όποια εταιρεία είναι δυσκολότερο να δημιουργήσει μια εικόνα για τα ενδιαφέροντα του χρήστη.

Το TrackMeNot αναπτύσεται κυρίως από ερευνήτες του Media Research Lab του πανεπιστημίου της Νέας Υόρκης και βρίσκεται ακόμη σε alpha στάδιο. Πολύ απλό και εύχρηστο για τον μέσο χρήστη. Περισσότερα: http://mrl.nyu.edu/~dhowe/trackmenot/

Webmail encryption

Web mail services όπως το Yahoo για παράδειγμα και το Gmail δε προσφέρουν εξ’ αρχής κρυπτογράφηση μετά το login του χρήστη. Στο Gmail μπορείς ο ίδιος ο χρήστης να αντικαταστήσει το “http” με το “https” στη μπάρα διεύθυνσης προκειμένου να στέλνει και να διαβάζει κρυπτογραφημένα τα μηνύματά του. To Yahoo όμως δεν προσφέρει αυτή τη δυνατότητα. Αυτό σημαίνει πως κάποιος με πρόσβαση στο ίδιο δίκτυο με αυτό του χρήστη, εάν κάνει packet sniffing θα μπορέσει αν διαβάσει το περιεχόμενο των μηνυμάτων. Για του λόγου το αληθές. Με χρήση του Wireshark έκανα capture τα πακέτα του interface του δικού μου μηχανήματος και φυσικά τα αποτελέσματα είναι τα αναμενόμενα:

Sender: xxxx@yahoo.com
Reply-to: xxxx@yahoo.com
To: xxxx@gmail.com
Subject: yahoo test subject
Body: yahoo test body

Για να δούμε τα επιθυμητά στοιχεία πρέπει να κοιτάξουνε στο πρωτόκολλο HTTP για τη μέθοδο POST.

Δοκιμή και με το Gmail:

Sender: xxxx@gmail.com
Reply-to: xxxx@gmail.com
To: xxxx@yahoo.com
Subject: gmail test subject
Body: gmail test body

Όπως προαναφέρθηκε, το Gmail μπορεί να γίνει πιο ασφαλές με τη χρήση Secure Socket Layer.

Κάπιοι άλλοι providers, δεν παρέχουν κρυπτογράφηση ούτε κατά το login του χρήστη. Πράγμα που σημαίνει ότι το όνομα χρήστη και ο κωδικός στέλνονται στο δίκτυο ως απλό κείμενο. Τα δύο παραδείγματα που θα ακολουθήσουν είναι με το Mail.gr και Mail.com.

Mail.gr

Mail.com

Ακόμη και εάν δεν μπορείς να ασφαλίσεις τα δεδoμένα σου 100%, καλό είναι να γνωρίζεις ότι μπορεί να βλέπουν και άλλοι, εργοδότες ή μη…