Sending mail in powershell (poor man's ssmtp in Windows)

A lot of times in a server you want to have a service be able to send and email. Sometimes this service is nothing but a script you wrote. As mentioned in a previous post, sometimes you just want a lightweight solution. In Linux I like to use ssmtp, but it is not available in Windows. So let's see if we can come up with the next best thing.

If you know me or my posts long enough, this is usually the cue for Powershell. And you would be right: it does provide the function send-mailmessage that allows you to craft an email which can then be sent to a proper SMTP.

Here's a quick proof of concept that I called mailtest.ps1:

$touser = "That guy <80sguy@email.example.com>"
$hostname = hostname
$SMTP = "smtp.example.com"
$fromuser = "Me "
$body = "Nothing to see. Move along"

send-mailmessage -to $touser `
                 -from $fromuser `
                 -subject "Test mail from $($hostname)" `
                 -body $body `
                 -SmtpServer $SMTP

All it does is send a test mail to that guy from the machine we are currently at. It does grab the hostname and creates a return address based on that. I did that because in a production script I like to know where my email came from. How would I used it in a production system? Let's say I have a script that monitors the default gateway and let's me know if it changed (long story). In that script I might have something like

$touser = "Me "
$hostname = hostname
$SMTP = "smtp.example.com"
$fromuser = "Gateway monitoring on $hostname "

function Send-Mail ($message) {
    send-mailmessage -to $touser `
                     -from $fromuser `
                     -subject "Default Gateway on $($hostname) Changed!!!" `
                     -body $message `
                     -SmtpServer $SMTP 
}

Now, we have a function that sends an email to Me indicating the default gateway has changed. It could be called by something like this

function Verify-Gateway($originalGateway){
    [...]
        if( $currentGateway -ne $originalGateway ){
            $Card.SetGateways($originalGateway)
            $message = @"
$hostname lost its default gateway. 
It thinks it is $currentGateway, but it should 
be $originalGateway. So, we changed it back.
"@
            # Let's write to a log
            Log-Msg ($message)
            # Then email message
            Send-Mail($message)
        }
    }
}

Makes sense? You can add more features to it, but the above works fine to me including my multiline string. Noticed in my example the smtp server does not require me to authenticate since I am in a "blessed" network. If that was not the case, fear not since send-mailmessage has a way to use authentication. I will leave that as an exercise to you.

Comments on a better than average Phishing Expedition

I take quite a few of you have received phishing emails. You know, some email that tries to compel the reader to click on a link to a site where for whatever reason they enter all their information so their identity, and credit card, can be stolen. And, maybe also get infected with a trojan in the process.

Some, with all respect, are rather lame. By that I mean the authors could not be bothered to

1. Spell and grammar check the letter. Yes, I know that those phishers might not speak natively the language of their target audience, but can't you be bothered to find someone to check it out for you?
   
2. Read it and make sure it make sense. I have received some that I read it 10 times and cannot figure out what is the point. There is nothing relating the text in the paragraphs and the reason to click on the link.
   
3. Take a few moments to study the target. Chances are our phisher phriend wants to hit a corporation or someone who is using a corporate service like facebook or microsoft or gmail. If you are trying to impersonate them, why not try to find out what the real letter you are trying to fake looks like?

Come on! I know it is harder than run the "EZ-Phisher" program and hit a button, but please try to make me feel pleased to see the phishing email instead of insulted. The fact those badly crafted phishing attacks work tells more about the target than the phisher, and what it tells is not pretty. If it comes as a shock to you that I

So this morning I received an impressive-looking phishing email that claimed to be from google. You probably want to know how it looks like, so I did a screen capture and put it here to the left. Don't panic, it is safe: you can click on it until you get a sore finger and it will not take you anywhere.

Now, this one I think is much better than your everyday phishing email. I mean, it is in a totally different timezone. Let's examine the phishing email and see what they did right and wrong:

What went right

1. Got the corporate colours right. The email claims to be coming from google, so they took the time to get the google icons and colours and even layout close enough to look credible.
   
   
2. Used knowledge of the official corporate website to hide their real url. If you hover the button, it would show the following link (am allowing it to overflow):
   
   Note they crafted their link so it is hidden after a few proper -- from the company they claim the email is coming from, google -- links. The link is long since our phisher phriends hope the real link will fall off the screen. Also, the last link, the one the probably points to their fake site, is behind a goo.gl link: you would need to click on it to first see what the link is, and then you are attacked. Specially if you use Internet Explorer a browser that does like to be cross site scripting vulnerable.
   
   
3. Hid the return email behind corporate-looking address. I like to see the source of the email, what gmail would call "Show Original". That usually is the 4th item from the bottom:
   
   When I tried to open it, the return address overwhelmed the menu bar, hiding all other options:
   
   Note that also worked when the email showed the return address (first picture on this article). That is good for a phishing email as it would make most users to not bother examining the email. Since we know what is the location of the option -- Show Original -- we want, we can use it regardless.
   
   
4. Avoided whenever possible relaying emails across too many non-corporate sites. The email looks like this:
   

   Delivered-To: phishing-victim@gmail.com
   Received: by 10.112.204.33 with SMTP id kv1csp2118911lbc;
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   X-Received: by 10.180.108.35 with SMTP id hh3mr31922715wib.48.1439282133631;
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   Return-Path: <perry_rhodan@interplanetary.edu>
   Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com. [209.85.212.194])
           by mx.google.com with ESMTPS id bl10si2265464wib.9.2015.08.11.01.35.33
           for <phishing-victim@gmail.com>
           (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   Received-SPF: pass (google.com: domain of perry_rhodan@interplanetary.edu designates 209.85.212.194 as permitted sender) client-ip=209.85.212.194;
   Authentication-Results: mx.google.com;
          spf=pass (google.com: domain of perry_rhodan@interplanetary.edu designates 209.85.212.194 as permitted sender) smtp.mailfrom=perry_rhodan@interplanetary.edu
   Received: by mail-wi0-f194.google.com with SMTP id p15so26093395wij.0
           for <phishing-victim@gmail.com>; Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
           d=1e100.net; s=20130820;
           h=x-gm-message-state:mime-version:from:date:message-id:subject:to
            :content-type;
           bh=LsemyedQTWVhfKEpSMfhlXsF9zPIYwDrlKawPrrmsog=;
           b=XAxoOiKIC3vJ4RIxmejkhdVXXBox3/I4nQYeu5Ml9F8Rq0Sjh+QKaY5M26FkPjX0fa
            Fu/v9fj+a451Aoc5AijUjqtrLEL8vH3Rhx7Kln7m6XrDo1P17HRVSDQCpoc7PlLZicSQ
            Mrnh6AFmYJ7PDCf1RuiJ8ACBZZ7+RwLLYtyEHnwxphUkCglVnJn75Vd8GDEBBv+G/BZw
            PISTui9PGA/jET733HHcLyA1FdYmYjJfWnOkM7oQBQv2/uR/xx9N06k21hbXKvYdOkkN
            oUafnLsuWnI8yBzJUaw2YpCr2HB2vw+ap9kTa4EkCzRntOhuBlpwzg60ukF6J+bdvbVf
            TpgQ==
   X-Gm-Message-State: ALoCoQmFD3lES/88ZcNCZQPJfj+ifiEDNpX5k0tRWJ0tphpzP282BDg6hmsHzb7Cf5n0u26AsTME
   X-Received: by 10.180.84.72 with SMTP id w8mr23619994wiy.71.1439282133247;
    Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   MIME-Version: 1.0
   Received: by 10.28.48.198 with HTTP; Tue, 11 Aug 2015 01:35:13 -0700 (PDT)
   From: "Google <no-reply@accounts.google.com> Google<no-reply@accounts.google.com> Google<no-reply@ac..." <perry_rhodan@interplanetary.edu>
   Date: Tue, 11 Aug 2015 09:35:13 +0100
   Message-ID: 
   Subject: Our Final Report
   To: undisclosed-recipients:;
   Content-Type: multipart/alternative; boundary=f46d044403ba48b9da051d04fc2f
   Bcc: phishing-victim@gmail.com
   
   --f46d044403ba48b9da051d04fc2f
   Content-Type: text/plain; charset=UTF-8
   Content-Transfer-Encoding: quoted-printable
   
   =E2=80=8B

   One of the classic telltales that an email is scam or phishing is found in by following the Received: headers. So, this email pretends to be from Google. A lousily put together phishing one might have the last hop on google, but then the previous hops would bounce all over the place. This one, however, came from Google. We even know it was submitted directly to a google SMTP server and when.
   

   Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com. [209.85.212.194])
           by mx.google.com with ESMTPS id bl10si2265464wib.9.2015.08.11.01.35.33
           for <phishing-victim@gmail.com>
           (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)

   And we know who supposedly submitted it:

   Received-SPF: pass (google.com: domain of perry_rhodan@interplanetary.edu designates 209.85.212.194 as permitted sender) client-ip=209.85.212.194;

   It was someone from an university. Now, why would this person use gmail from SMTP? Well, let's ask the university itself:
   

   bash-3.2$ dig interplanetary.edu MX
   
   ; <<>> DiG 9.8.5-P1 <<>> interplanetary.edu MX
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21325
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 6, ADDITIONAL: 7
   
   ;; QUESTION SECTION:
   ;interplanetary.edu.                     IN      MX
   
   ;; ANSWER SECTION:
   interplanetary.edu.     3077    IN      MX      5 alt2.aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      5 alt1.aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      1 aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      10 alt4.aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      10 alt3.aspmx.l.google.com.
   
   ;; AUTHORITY SECTION:
   edu.                    46983   IN      NS      a.edu-servers.net.
   edu.                    46983   IN      NS      c.edu-servers.net.
   edu.                    46983   IN      NS      f.edu-servers.net.
   edu.                    46983   IN      NS      d.edu-servers.net.
   edu.                    46983   IN      NS      g.edu-servers.net.
   edu.                    46983   IN      NS      l.edu-servers.net.
   
   ;; ADDITIONAL SECTION:
   a.edu-servers.net.      46983   IN      A       192.5.6.30
   c.edu-servers.net.      46983   IN      A       192.26.92.30
   d.edu-servers.net.      46983   IN      A       192.31.80.30
   f.edu-servers.net.      46983   IN      A       192.35.51.30
   g.edu-servers.net.      46983   IN      A       192.42.93.30
   g.edu-servers.net.      46983   IN      AAAA    2001:503:cc2c::2:36
   l.edu-servers.net.      46983   IN      A       192.41.162.30
   
   ;; Query time: 34 msec
   ;; SERVER: 10.0.0.10#53(10.0.0.10)
   ;; WHEN: Tue Aug 11 08:55:08 EDT 2015
   ;; MSG SIZE  rcvd: 380
   
   bash-3.2$

   So, this university uses gmail to send its emails. I guess that means it decided to move to the cloud by outsourcing its emails. I know a lot of people who are rabbid avocates to pushing as much of the IT infrastructure to be hosted by commercial vendors in the cloud. I wonder how many did the due diligence, but I digress. The upshot is that it makes it easier for a careful phisher to do research on targets: instead of having to go to many different sites, the eggs of many business are now literally being held in few baskets. For instance, if the target companies are, say, using the Microsoft cloud, a Microsoft-looking email to all the users in the target corportations would look legit. And that allows phishers and other hackers with criminal intents to concentrate their efforts.
5. Email passed DKIM and SPF, which adds to its legit feel.
   

What went Wrong

Unfortunatley this phishing email was not perfect. The issues are few and far between but are there.

1. Grammar. It is not horrible, but it does made me stop too long to see it was spam/phishing. The We always protect you and Our Final Report did sound a bit odd. The first one was close to what Google might have written but no cigar. Still, since it does not have the usual chicken little warning messages bad phishing uses, I honestly passed through it without noticing much. And besides, We always protect you gives a warm and fuzzy feeling, not as much as a box of kittens but you get my point.

   The first paragraph is a different story. It does not sound like what a native English speaker would say -- it is too wordy and convoluted -- and Google would have spent the money to put their message in nice clear 8th grade English. The second paragraph started with a lowercase; don't know any language that has upper and lower cases that would do so.
   

2. No spaces between paragraphs. The paragraphs are short as they would in a Google announcement -- keep it simple and fast so user won't lose interest -- but because of the lack of spaces between them they look too cluttered. Still from a distance it looks clean and pleasant.
   

Overall I would give it a 7/10: good effort, better than average delivery, and took some time to know target. But, this phishing attempt could be better.

Keep up with the good work!

Using a juniper SRX router as ntp proxy

I am in a Juniper router mood since last week, so we will talk about another quick and easy project: ntp proxy. I know that before I have said a given article would be fast and easy and it ended up longer than planned, but I feel lucky today!

Just to let you know, this post is really not about how to do the deed, but why.

The reason we want to use the router, uranus, as ntp proxy is that the vlans we care about for this discussion have to go through it to get somewhere else. So, if they have to see uranus every day, they might as well do something with it. Why not tell them their ntp server is the router as seen in their network, letting then the router talk to the actual ntp server?

The Steps

1. Get the name of the ntp servers you want to use. We'll be lazy and use pool.ntp.org as primary server for now. Before you ask, yes we could have used an internal ntp server by just providing its hostname or IP.
   
2. Set them
   

   set time-zone America/New_York
   set system ntp server pool.ntp.org version 4 prefer
   set system ntp boot-server pool.ntp.org
   

   boot-server is the default ntp server to use when the router is booted. server is one of the other ntp servers to pick if the boot-server does not like us anymore; we can have more than one here.
   

   We should end up with something like this
   

   system {
       ntp {
           boot-server 198.55.111.50;
           server 198.110.48.12 version 4;
       }
   }

   Note that even though we enter pool.ntp.org for both boot-server and server, the IPs used are different. All that means is that, as the name hints at, pool.ntp.org is a pool of machines. Every time the router resolves pool.ntp.org it might get a different IP.
   
3. Check. We could see how off we are

   janitor@uranus# run show system uptime | match current
   Current time: 2015-08-06 12:33:56 EDT
   janitor@uranus#
   

   Or be a bit more blunt:

   janitor@uranus> show ntp associations
        remote           refid      st t when poll reach   delay   offset  jitter
   ==============================================================================
   *time01.muskegon 204.9.54.119     2 -  706 1024  377   60.728   -4.806   2.384
   
   janitor@uranus>

   I don't know about you but that sure reminds me of the output of ntpq -p. If we need more verbose, we could say
   

   janitor@uranus> show ntp status
   status=06c4 leap_none, sync_ntp, 12 events, event_peer/strat_chg,
   version="ntpd 4.2.0-a Wed Apr 23 21:04:45 UTC 2014 (1)",
   processor="octeon", system="JUNOS12.1X45-D25.1", leap=00, stratum=3,
   precision=-17, rootdelay=70.394, rootdispersion=85.850, peer=10620,
   refid=198.110.48.12,
   reftime=d96e9a76.c04e615d  Thu, Aug  6 2015 22:46:14.751, poll=10,
   clock=d96ea14a.a9c6ff3a  Thu, Aug  6 2015 23:15:22.663, state=4,
   offset=-2.422, frequency=17.545, jitter=1.532, stability=0.115
   
   janitor@uranus>

Well, we got it running, but what about the ntp server choice we made? Ideally we might want to run our own ntp server, ntp.example.com, which then can be configured in the router, say

set system ntp server pool.ntp.org version 4 prefer
set system ntp server pool.ntp.org version 4 prefer
set system ntp boot-server ntp.example.com

Which would make ntp.example.com as the primary and would pick two servers off pool.ntp.org as failovers. However, what counts int he end of the day is that we are using uranus to abstract ntp to the ntp clients. As a result, they will be in sync so Kerberos and derivatives will be happy. So to show I am not lying, here is what my desktop thinks the ntp server is:

raub@desktop:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*uranus.example. 198.110.48.12    3 u  950 1024  377    3.519    0.043   1.605
raub@desktop:~$

As you can see, it does like uranus. Since it is so easy to change it (you can even push the changes using ansible) without having to reconfigure the ntp clients (they only have to reach uranus, why not just setup the ntp proxy thingie on uranus against an external source to get your network up and running and then worry about having a ntp.example.com later on? Pick your battles!

References

• Juniper docs on Configuring NTP
  
• ntp docs

Juniper SRX router booted from backup image (or, orange LED light again!)

So, uranus is in pain once more. Power went out and it was not properly shut down before the UPS gave its last gasp (I do need to do something about that). When I rebooted it, it seemed to have come back without an issue -- it was working fine -- but it had The Light on again just like it was in last time. I ssh'd into it and this is what the motd looked like:

raub@desktop:~$ ssh janitor@uranus.example.com
janitor@uranus.example.com's password:
--- JUNOS 12.1X45-D25.1 built 2014-04-23 20:45:48 UTC

***********************************************************************
**                                                                   **
**  WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE      **
**                                                                   **
**  It is possible that the primary copy of JUNOS failed to boot up  **
**  properly, and so this device has booted from the backup copy.    **
**                                                                   **
**  Please re-install JUNOS to recover the primary copy in case      **
**  it has been corrupted.                                           **
**                                                                   **
***********************************************************************

janitor@uranus>

Hmmm, so the normal image (does that mean the entire OS partition or just the boot stuff?) got corrupted when power went bye-bye. Good thing it keeps a backup. Out of curiosity, let's see if that is related to the LED being on:

janitor@uranus> show chassis alarms
1 alarms currently active
Alarm time               Class  Description
2015-02-26 05:38:12 EST  Minor  Host 0 Boot from backup root

janitor@uranus>

It seems to be the case. Funny that it is labelled minor but important enough to become the motd, but I digress. Personally, we should take care of that as soon as we have a scheduled maintenance window.

Ok, maintenance window time. Before rebooting, let's prepare a few things. If we know the backup copy is good (configuration files are also backed up, and you can push them back with ansible or whatnot if you feel uncomfortable), you could be lazy like me and copy the backup into the primary partition.

janitor@uranus> request system snapshot slice alternate
Formatting alternate root (/dev/da0s1a)...
Copying '/dev/da0s2a' to '/dev/da0s1a' .. (this may take a few minutes)
The following filesystems were archived: /

janitor@uranus>

If all went well, we should see the primary snapshot having the creation date of when we ran the ,tt>request system snapshot slice alternate command.

janitor@uranus> show system snapshot media internal
Information for snapshot on       internal (/dev/da0s1a) (primary)
Creation date: Apr 19 22:34:04 2015
JUNOS version on snapshot:
  junos  : 12.1X45-D25.1-domestic
Information for snapshot on       internal (/dev/da0s2a) (backup)
Creation date: Feb 26 05:33:18 2015
JUNOS version on snapshot:
  junos  : 12.1X45-D25.1-domestic

janitor@uranus>

As you noticed, I did this a while ago but never got around to making an article about it, but there it is. However, I still had the evil LED staring at me. Time to turn it off

request system reboot media internal

So I rebooted and did not get that motd anymore not the LED:

janitor@uranus> show chassis alarms
No alarms currently active

janitor@uranus>