[BreachExchange] Tick-tock, tick-tock. Oh, that's just the sound of compromised logins waiting to ruin your day

[Destry Winant]

https://www.theregister.co.uk/2018/09/17/compromised_credentials/

Comment It has never been easier to conduct a cyber attack. There now
exists a range of off-the-shelf tools and services that do all the
heavy lifting – you just need to pick an approach and tool you like
best.

There's ransomware-as-a-service with its "here's one I made earlier"
code, search engines that show connected interfaces with known
vulnerabilities, and downloadable and easy-to-use scanning tools for
the discerning script kiddie.

Heck, why bother with tools that need time and effort to find
vulnerable systems? Why not just steal credentials and log in via the
front door?

Using Troy Hunt's site Have I Been Pwned?, you can check your user ID
against almost 5.4 billion sets of credentials that have been stolen
over the last few years. 5.4 billion. One would hope that the majority
don't work any more due to breached sites shutting down, people
deleting their logins for those sites, and many more changing their
passwords. But of 5.4 billion sets of credentials, plenty will still
be valid.

Alongside Hunt's project is the flood of credentials that continue to
be stolen. One security vendor reckoned eight million per day in 2016.
Even with a pinch of "they would say that, wouldn't they" salt, that's
rather a lot.

Why does it take so long to detect threats?

You can't detect something you don't see. Imagine, for example, that
one of your staff falls for a phishing campaign. How would you know?

With good training, many of them will tell you. They'll realise they
gave away their credentials and will call the security or IT team, who
will help them change their passwords to avoid compromise. Unless, of
course, dishing up the credentials kicked off an automated attack and
the exploit has happened already.

Could the threat have been detected? These days, yes, as phishing is a
by-numbers game that employs suspicious domains which are easy to
spot. That said, there will still be instances where phishing emails
do succeed and you're left on clean-up duty.

But the industry is turning its attention to "behaviour". In this
context AI-based monitoring tools are discussed – systems that watch
the network, the user PCs and servers to see what people and
applications are doing, and looking out for abnormal behaviour.

Now, it is possible to identify abnormal behaviour without such tools.
It's straightforward to log the sources of your cloud service logins
and run scripts that will smell a virtual rat. In many cases this is
an out-of-the-box service that's turned on by default. Yes, AI tools
are much cooler and more effective, but you can do the basics with
free features and simple scripts.

This approach can and does fail, however, when – as often happens –
people either don't turn on logging or they do turn it on but don't
monitor the results.

R3alC0mplexP4ssword44

So all kinds of systems are open to attack because the unifying
factors in each are the means of authentication, the password, and the
presence of humans.

Let's say the user gave away their password, it wasn't detected but
you were lucky: it simply got squirrelled away in a database rather
than deployed in an automatic attack. The user has changed the
password.

What have they changed their password to? Something completely
different, I hope. In many cases, the previous password isn't a
million miles away from the old: if they had R3alC0mplexP4ssword43,
the new one is likely to be R3alC0mplexP4ssword44.

You'll have configured the system not to let them use something too
short, or something that's not complex, or something they've used
before: checking to see if they've used something sufficiently
different from their old ones is harder.

And that's because systems are secure. They don't store passwords in
plain text – they hash them first. Which means it's non-trivial to
check new passwords for similarities with old ones. All you can do is
take a set of variations of the new one, hash them, and compare them
with the database – which is far from exhaustive, and attackers will
always be able to try more alternatives at their leisure than your
system can in the few seconds you have in a password change function.

The point is that compromised credentials have longevity. Even if you
changed them instantly, they could be used months or years later with
some cunning heuristic algorithm to help guess the passwords that
succeeded them. A ticking time bomb, as it were, except you can't hear
the ticking.

Are we configuring systems correctly?

Have a cloud-based email system without multi-factor authentication?
You and thousands of others, yet there's no way you can configure a
single-factor authentication mechanism securely. Make passwords as
complex as you like, force changes as often as you like, but someone
will eventually give up their credentials and the hackers are in.

Do we know how to configure our systems properly anyway? Not so long
ago I port-scanned a client's LAN and found a SAN controller. Google
told me the default "admin" and "root" passwords. The "admin" password
didn't work (they'd clearly changed it) but the "root" one let me
straight in. Why? The client didn't know the "root" login existed.
True, I had to be in their office to get on their LAN, but that's not
always the case. And they had MAC address whitelisting, but I just
configured my Mac's LAN card to pretend to be the meeting room PC.

How bad is this situation? Search engines such as Shodan.io will serve
up screen after screen of vulnerable systems with default credentials
set. So it's pretty bad.

Are systems more susceptible than others?

Top of the list: anything in the cloud, especially email. By default
the average cloud-based mail application is more accessible than
something hidden in a corporate LAN behind a NAT firewall.

Next is anything web-facing by necessity: if you have to make it open
to the world, the world can probe it for insecurities. The majority of
attacks you can do in this context are by probing software
vulnerabilities not using compromised credentials, but there are so
many it has to be stated.

Then anything "old". This source of attack might not come from
compromised credentials but, again, vulnerabilities as systems go
unpatched through oversight or by falling off their vendor's support
roadmap by dint of their age.

Finally, anything on a network. Even if something isn't directly
vulnerable, it may be possible to reach it via something else in your
infrastructure and then hop off over the LAN using trust relationships
or – yes – compromised credentials from internal application or
database logins.

What can we do?

First we can make our passwords as complex as we can, and change them
regularly. That's a pain for users, but we find compromises that work.
Most importantly we need to stop thinking that user IDs and passwords
are enough. Multi-factor authentication is absolutely mandatory for
anything that can be accessed from the internet, and since our people
are getting so used to it – and because it's so simple to put tools
such as face recognition or fingerprint scanners on our devices – why
not use it internally too?

Next, provide rigorous, regular training to help our users stop
falling for scams. I've done face-to-face awareness training
programmes whose outcome has demonstrably been to double user reports
of suspicious activity and halve the number of accidental breaches.

Finally, stop making stupid mistakes. If your connected device has any
default credentials, or has any services running that you don't need,
you need a kicking. And a good slap if you're not updating the
software and firmware, but that's a separate issue. We need to train
our techies properly: if they don't know how to secure it, they can't
secure it properly.

Rethinking passwords

If we can't prevent passwords being stolen and systems compromised, we
have two options. One is to search for ways to prevent passwords from
becoming such a weak link.

The best way to do this, ironically, is to share information about our
security with others in the same situation. Remember I talked about
tools that flag activity that isn't "normal"? The best way to teach AI
what "normal" constitutes would be to pour data into the right machine
models. In this case, the sources for this data should be companies
and organisations like us. Not only would our contribution help
others, but their contributions would help to alert us when someone
tries to re-use or abuse our users' credentials.

The other option is for greater monitoring, using things like rules to
spot signs of a breach – such as a user's access from new and exotic
locations, for example – with the addition of automatic alerts. Also,
for more intelligence that can learn to differentiate more subtle and
hidden forms of rogue behaviour.

Monitoring means you don't just find the bad guys but also identify
whose IDs have been nicked.

Compromised credentials are an existential risk that manifests itself
as a practical threat. We can protect ourselves because the tools are
getting better – we just need to recognise that that ticking sound
inside our IT systems is a wake-up call.