[conspire] phishing, security, cons, ...

[Michael Paoli]

> Date: Fri, 24 Mar 2017 10:11:00 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Subject: [conspire] 'Frighteningly effective' GMail phishing
> Message-ID: <20170324171059.GD5838 at linuxmafia.com>
> Content-Type: text/plain; charset=utf-8
>
> I follow several publication sources on security: most frequently,
> Bruce Schneier's blog, and with more occasionally RISKS Digest and
> Brian Krebs's blog 'Krebs on Security'.  (I recommend all of those.)

Yes, highly recommended. :-)

> The fortune article is about a new twist on how to craft a phishing
> e-mail, aimed at a GMail user.
>
> As is often the case, the mail is forged to make it appear to come from
> a 'trusted' (or at least frequent) correspondent.  Or possibly not
> forged, but instead coming from a correspondent whose webmail access has
> previously been stolen.
>
> There's an attached image file.  You click to show an image preview.
> The location bar shows a URL that _includes_ 'account.google.com', but
> you see what appears to be a new browser tab prompting you to sign in
> (to GMail) again.  You sign in.  Oops, you got fooled.  The bad guys now
> instantly have the keys to your account.

Yeah, that's the kind'a thing that catch my spidey sense, and I'd be
rather to quite suspicious of.  Good to be cautious and reasonably
suspicious ... not so good to be paranoid ... sometimes a fine line
between them.  8-O

Can't say I've *never* been (slightly) bitten by some deception or
such, ... but at least never significantly.  But always good to be
quite prudent and cautious.

So ... a few additional/related tips.  (Okay, maybe mostly preaching
to the choir - but to cover the bases ... and some of these ideas
may be useful to help educate others ... so I do so much by 2nd
nature I don't even thing exactly what/how I'm doing it).

So, if I'm already logged in / authenticated to some web site ... let's
say gmail ... I'm *generally* not going to be seeing or expecting it to
give me some web form or whatever to reauthenticate.  Really only about
two cases where that happens - and that's more generally applicable to
*most* web sites - not unique to gmail.
Most commonly the cookie has expired - the one that had me authorized
for however many minutes/hours/days/whatever.  But that I generally
revalidate, I don't presume something that popped up or is or looks like
another tab is legitimate.  Hey I already am on a legitimate URL for
starters, right?  May even have other tabs that are (or at least were)
logged in and authenticated to that site.  So, what will I typically
do?  Refresh/reload one of those.  If it requests reauthentication, then
oh, gee, cookie expired, time to reauthenticate.  If it *doesn't* do that
and *something else* is trying to get me to give authentication credentials,
and especially purportedly to the same site, it's a pretty sure bet that
something squirrelly, and likely phishy and a scam - is up.
About the only other time authentication comes up again on a site I've
already authenticated on earlier, is if I'm about to access or change
more sensitive information, e.g. certain account setting such as
changing password - but in that case *I* initiated the request to do
such, it didn't just "pop up" or the like.  And, I initiated it from
known good location to start with.

And ... anything that gives window, tab, pop-up, whatever, or via link
or whatever, to authenticate (purportedly) to some *other* site,
very simple - do *not* trust that URL.  Don't even trust your
eyes to read and interpret it 100% correctly - can be a typo domain,
or some characters changed to non-ASCII that look highly similar to
the expected ASCII characters, etc.  Use URL that you know to be
legitimate, and go from there to whatever one needs/wants to do.

> The 'attached image file' wasn't actually an attached image file.  It wa
> a 'data URI', a very long string that starts out with
> 'data:text/html,https://accounts.google.com/ServiceLogin?service=mail'

> Ask yourself:  Why should the user trust a login screen that suddenly
> just shows up?

Yup - that's a key point ... be suspicious, don't (automatically) trust,
take reasonable steps to verify.

> Once when I was working at VA Linux Systems, an incoming call was routed
> to me, from someone who said he was Sergeant So-and-So from Sunnvale PD,
> seeking to return some recovered stolen VA Linux Systems stolen gear to
> its rightful owners.  I checked with my boss that giving out owner
> contact information is OK, and said 'Sergeant, can I call you back via
> the Sunnyvale PD main public number?'
>
> 'Sure, but but may I ask why?'
>
> 'Absolutely no offence intended, Officer, but I have no way of knowing
> that an actual Sunnyvale PD officer is calling, because you initiated
> this call, not me.'
>
> 'Oh, OK.  Let me give you my direct number.'
>
> 'Again, absolutely no offence intended, sir, but given that I don't know
> for certain that you're Sunnyvale PD, I also don't know that a number
> you give me is that of Sunnyvale PD.  Can I be patched to you from the
> main public number?'
>
> 'Yes.'
>
> 'Talk to you in a jiffy.'
>
> When we were reconnected, he said that in decades of police work, nobody
> had ever taken that precaution before.  I said I was not surprised.

Yes, had quite similar before ... actually multiple occasions - I believe
I've mentioned on multiple occasion(s) on list(s) (this and/or others).

E.g. one that happened >~=20 years ago, was working at a major financial
institution.  Had some issue with or related to a two-factor-authentication
(2FA) device, had called or opened a ticket about it or whatever.  So, I
get a call from someone to go over and resolve the issue.  So far fine.
Then they asked for some particular bit of sensitive information - relevant
for resolving the issue.  I then asked how could I know they were who they
claimed to be - notably from the relevant department that would handle
that issue.  I caught them rather by surprise on that ... took him several
seconds ... then he was able to come up with something that was quite
sufficiently convincing for the level of sensitive information asked (had
it been more sensitive, I probably would've further upped the verification
level).  He also responded that I was the first person that had ever
challenged him on that.  Must say, at least at that time, I found that
surprising.

And yes, I've seen, e.g. (other) financial institutions significantly
screw that up.  E.g. they leave me a voice-mail.  unsurprisingly it's
rather vague ... after all, they've only verified the number, not who
might pick up the voicemail.  So ... I've got a number and a name and
name of the financial institution, but pretty much nothing else.
So ... I try to validate the number ... financial institution's web site
... no matches there for name or number ... check 'da vast Interwebs on
the number ... scam, or legit, or ??? ... nothin' definitive (really nothing
at all, or close to it).  Call the financial institution, ... *they*
are not able to verify it ... well, at least not immediately, it's more
like call this number, call this branch/department, call ... during their
regular business hours ... eventually got it validated, but they shouldn't
make it *that* hard to do so - especially when I gave them both number *and*
name.

Also, I think at least in significant part, we as technologists fail.  8-O
Yeah, sure come con jobs, there is no tech element, or if there is,
technology isn't relevant to the exploit in a con.  But, with technology
in many cases, many elements of poor design, etc., make it difficult for
the average user (and user's mom, and grandma) to be and keep themselves
safe on-line.  E.g. try and think how one would have to explain to
mom/dad/grandma/granddad/... what they need to do and not do to keep  
themselves
safe and secure on-line.  Much of it isn't exactly highly obvious and
intuitive.  And I think much of it goes back to design ... user interface
design and how things do/don't interact with users (and can and cannot),
and often technology and protocols and implementations thereof - there are
many cases where the protocols or implementations - or in combination, they
are at best inherently hazardous.  So ... there is lots of room for
improvement.  And seems like at least some of those improvements ought be
pretty simple to implement.  E.g. web browsers.  So, let's say you've got
user, they've got their computer and browser configured for US-English.
Internationalization - okay, fine, quite needed.  So ... URL with
non-ASCII characters - how 'bout clearly highlight that well in a clear
warning/cautionary way, rather than allow some non-ASCII unicode caracter
to be used in a look-alike scam domain that appears nearly identical
visually?  And if the user and browser are set for some other country
and language, how 'bout likewise clearly flagging characters from other
languages?  How 'bout clearly flagging URL that contains characters from
multiple distinct unrelated languages?  If the user uses multiple languages,
perfectly fine, set those with the operating system and/or browsers, e.g.
list of languages and preferred order - if characters don't match that
or are otherwise oddly and likely not legitimately matched - flag that.
Anyway, just one possible *partial* example (not intended as a complete
solution - even for that).