The Quest for the Universal Fingerprint

Published: 2017-05-04
Last Updated: 2017-05-04 21:50:58 UTC
by Rob VandenBrink (Version: 1)
2 comment(s)

Gebhard pointed us to an article at Heise, which reports that researchers are working towards a "universal fingerprint" - a master pattern (or small number of master patterns) that ring enough bells to unlock any of today's fingerprint readers.  They are currently have an approach that takes partial impressions and combines them until it "matches enough" to unlock a phone (or otherwise match a biometric reader) - essentially a dictionary attack against your fingerprint.   They are currently at a 65% success rate, but of course that can only get better. 

Their advice?  Get better readers (that can read depth of fingerprint patterns, add in heartbeat sensors etc), or combine multiple authentication mechanisms if your plan needs to account for attacks of this type.  I'd say nation-state attacks, but this sounds like it's something anyone who's reasonably funded and motivated could take on, especially after the research is formally published.

Add this to the well-known fact that once compromised, you cannot revoke your fingerprints, or change them either.  If a successful and simple fingerprint attack is possible, either we need to look at better fingerprint readers going forward, or this takes fingerprint authentication off the table entirely.


Rob VandenBrink

2 comment(s)

Migrating Telnet to SSH without Migrating

Published: 2017-05-04
Last Updated: 2017-05-04 16:20:16 UTC
by Rob VandenBrink (Version: 1)
6 comment(s)

I recently had a security assessment / internal pentest project, and one of the findings was "I found an AS/400 running telnet services" (actually unencrypted tn5250, but it comes to the same thing)
The client's response was that this host was up for history purposes only, it was not longer production system.  So it was only used occassionally when they needed transaction history from before their migration to the current system.  Which doesn't really address risk around their client's information on that host.

We've all been there.  We've found a telnet service that should be migrated to SSH, but the affected device either doesn't support SSH, or the client for one reason or another can't put resources into enabling encrypted services.  In the case of the AS400 above, they'd need to do an OS update, which would require an application update to an app they had retired, on a system that isn't production anymore.

We see this in legacy systems, but in Industrial Control Systems (ICS) that control factories, water or hydro utilities we see this all the time in production - and the answer there is "the gear doesn't support ssh, and in some cases doesn't support credentials".  In ICS systems in particular, gear like this is often on the same 5,7 or 10 year depreciation cycle as might be seen on an industrial press or other manufacturing equipment, so upgrades are really a long-term thing, there are no quick fixes.  Even finding where all the vulnerable gear is (physically, not on the network) can be a challenge

So what to do?

In some cases, I've front-ended the problem child gear with a cheap SSH gateway.  A Raspberry Pi does  a decent job here for less than $100 per node. The Pi runs "real" linux, so you can secure it.  The solution looks like this:


Physically, it looks like this - often we'll just velcro the Pi to the host it's protecting, the "Unencrypted DMZ" ends up being a 1 ft ethernet cable: