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

Rick Moen rick at linuxmafia.com
Sun Mar 25 12:40:45 PDT 2018


Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

[snip my description of an allegedly super-effective phishing attack on
GMail users, that upon examination is nothing actually new except
popping up a new browser tab falsely purporting to be a fresh GMail
login required for no good reason]

> 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

Michael, I always appreciate your joining these discussions, even if
only belatedly, but sometimes what you write is just a little vexing
because you head off into the weeds and geek out over detail, creating
the risk that readers won't get the _main_ point that I (for one) was
trying to highlight.  So, I'm going to re-centre discussion on the main
point I was making, here -- and hammer on it until I've re-clarified
sufficiently:

The unifying red-flag warning sign present in _all_ phishing attacks, 
and many similar security attacks entailing social engineering, and most
con-artist scams, is a task suddenly thrust upon you, the target, in a
way that's irregular and unexpected, and especially one that asks you to
suddenly change your agenda for no good reason, or (in other cases) that
seems suspiciously convenient and out of nowhere.  In the discussed
case, suddenly the GMail user sees a browser tab that looks like a fresh
request for Gmail login.  That's a classic example of 'irregular and
unexpected' and 'asks you to suddenly change your agenda for no good
reason.'

And the point I made is that in _all_ such cases, your reaction should
be 'no' absent a really good explanation.

The phishing attack, the fooling of the user, relies on the user 
_not thinking_, and just mindlessly doing yet another task thrust upon
him/her by the Web browser.  A wary user, instead, would be stopping and
thinking 'Wait, where did that come from?  This is irregular at best.
It's not normal for an alleged GMail login tab to pop into existence
during the middle of my GMail session.'

The wary user would _avoid_ answering a security-sensitive login
dialogue that just showed up out of nowhere.  So, I'm being asked to
login to GMail again?  Wait, let me check my ongoing GMail session in
one of my older browser tabs.  Is it still working?  If so, then clearly
I don't actually need to login.

The wary user, if he/she thinks a new login _might_ be necessary, ought
to carefully ignore the suspiciously-convenient 'login' tab that just
popped open, and think, 'Wait, how do things normally work when *I*
initiate login?'  Answer:  The _user_ starts a tab or window, and
navigates via bookmark or typing 'www.gmail.com' into the location bar,
and loads the page.   So, that should be what the wary user, who for
some reason thinks a fresh GMail login is necessary, should do.  Do it
the _regular_ way, not the irregular, unexpected,
appearing-out-of-nowhere way

This user should bear in mind that login credentials are always a target
for theft, and thus should be entered only in _familiar_ settings that
are initiated by the user and under user control.  If anything seems
off, if anything seems unusual or unexpected or suspiciously convenient
and different, it is always appropriate to walk away and do it only the
tried-and-true way.

That habit will prtect the user against _all_ phishing attacks, past,
present, and future.  The IT press has an incentive to portray each
'new' phishing attack as novel and threatening in ways the old habits
cannot protect against, but that is totally false.  Basic caution
_always_ defeats the attacks.

Receive an e-mail saying you need to login to your Bank of America
account to fix a problem?  Never, ever rely on the URL it sends you,
even if you think you _might_ have a BofA problem.  Instead, use your
own regular methods (e.g., bookmark or manually typing the bank URL)
to reach the login page, and only then enter your credentials and look
for the alleged 'problem'.

Receive a telephone call from Sunnyvale PD saying they need your help
returning stolen property (as I did)?  Sure, it _might_ be Sergeant
So-and-So, but all you know is it's a voice.  So, _you_ take control, 
graciously turn down the suspiciously convenient situation of Sergeant
So-and-So calling you directly, and arrange to call him back via the
Sunnvale PD switchboard, looking up that switchboard's number for
yourself.  

All the same pattern.  Never take security-sensitive actions in a
scenario thrust on you by someone else, only in the _regular_ context
that is initiated and controlled by you.  Always decline suspicious
convenience in 'helping' you furnish sensitive data.

And this remedy always works.  Not just for one such social-engineering
attack, but all of them.



> 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.

Exactly.  That should immediately make the user wary.  And, even if the
user believes that it might be necessary to login again, the user should
on grounds of general caution decline the suspiciously-convenient new 
login tab that suddenly showed up out of nowhere.  If you think you
might need to login, go to a login page under your _own_ power, the
regular way.

The important thing is not the particulars of this specific phishing
attack, but rather the general and comprehensive wariness the user 
should cultivate, of politely declining unusual, unexplained
opportunities to take security-sensitive actions, and instead
leave and carry those actions out, if at all, the regular way in the
regular places.


> Most commonly the cookie has expired - the one that had me authorized
> for however many minutes/hours/days/whatever.

But you would be able to confirm this suspicion by seeing if your
existing GMail (or whatever) session still works.  If not, then maybe
you do need to login -- but, even then, you don't need to do so via a
supiciously-convenient login tab that popped up out of nowhere.



> 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.

Bingo.

> If it requests reauthentication, then oh, gee, cookie expired, time to
> reauthenticate.

And then, _never_ on some browser table that suspiciously popped up out
of nowhere.  Because you _know_ that is not the normal way to login, and 
you know that login is security-sensitive, so you should always politely
say 'no' and go do it the regular way.



> 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.

Bingo.

> 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.

Never ever.


> 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.

The critical part of the con isn't the technology, but rather the
_confidence story_, e.g., you make your page send the user's browser some
Javascript that pops up a tab that resembles a GMail login.  The whole
con hinges on the user's willingness to not think, and trust that GMail
login is required just because the thing looks like a GMail login, even
though the context of such a dialogue popping up makes no sense.

User wariness, insistance on using credentials _only_ in the customary
and familiar setting in a scenario under the user's control, completely
defeats those confidence games, no matter what the technology is.

Thus, this is not technologist failure.  This is user competence
failure.

> 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.

I do not concur at all.  And, again, you are IMO distracting from the
crucial point I was trying to make.

In every case, no matter what poor design might be used, the habit of
caution concerning when it's OK to enter sensitive information always
foils confidence-game attacks such as phishing.  Always.

> And I think much of it goes back to design 

I do not concur at all.

And I think people who listen to me are going to be inherently a lot
safer than people who listen to you saying the fault is poor UI design 
and the user cannot take effective measures.  The user _can_ take
effective preventative measures.  It's not even difficult.  

> 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?

Again, wrong problem, wrong solution.

The name for what you describe is a 'frogery'.  See:
http://linuxmafia.com/~rick/lexicon.html#frogery

Irrespective of Unicode and other mechanisms that introduce lookalike
characters and permit (e.g.) almost-correct fraud domains (not to
mention typo-exploiting domains), the user's preventative is always the
same and always works.  You don't rely on URLs supplied to you for
anything security-sensitive, period.  For your bank, your medical
provider, your domain registrar, etc., you rely on bookmarks or you
yourself entering the URL.  Never a source of that URL you have no
reason to trust.  And, my point:  This always works.

So, do it, and stop wasting time geeking out ofver character sets.





More information about the conspire mailing list