antipaucity

fighting the lack of good ideas

on using nmap to help find tlstorm-affected devices

You may have heard of the recently-discovered/-published TLStorm vulnerability that affects – at least – APC SmartUPS devices.

One of the prime issues highlighted is the embedded nanoSSL library that APC has used on these systems.

If you want to find out if your system is affected, the following nmap except should start you towards a solution:

for octet in {30..39}; do (nmap -A -T4 192.168.0.$octet > nmap-192.168.0.$octet.out &) ; done

This will kick-off nmap to run in parallel. When they all finish (you can monitor how many are running using ps aux | grep nmap), you can then process the files rapidly thusly:

grep -i nano nmap*.out

If nanoSSL has been found, you’ll get a listing of all IPs running it (since you cleverly named your files with the IP in the name).

The mitigations you choose to implement have been explained well in the articles linked above, but finding these systems can be a pain.

Hope this helps someone 🙂

a semi-permanent psa on passwords

Passwords should never expire: https://www.sans.org/security-awareness-training/blog/time-password-expiration-die

Passwords should not be changed often: https://www.schneier.com/blog/archives/2016/08/frequent_passwo.html

Password “complexity” is – mostly – a joke: https://www.xkcd.com/936

You have been breached: https://blog.augustschell.com/passwords-passphrases-complexity-length-crackability-memorability-data-breaches

Passphrases are better than passwords – and https://password.ga will generate them for you (it will also generate random passwords that pass complexity requirements)

Use a password manager of some kind

do you leak?

It would seem I have configured OpenVPN, Squid proxy, and, to a lesser extent, Pi-hole well – none of the major sites that report IP, DNS, and other connection-related security issues find anything out of the ordinary when I’m either running “just” proxied, or VPN, or VPN+proxy.

You should check yourself hereon:

  1. https://ipleak.net
  2. http://ip-check.info/?lang=en (ironic this site isn’t serving itself over https)
  3. https://doileak.com
  4. https://whatismyip.com
  5. https://browserleaks.com/ip

And, of course, if you just want to see what your pubic IP address is, go hit my service – IPv4.cf

4 places to check your website’s ssl/tls security settings

Qualys – https://www.ssllabs.com/ssltest

High-Tech Bridge – https://www.htbridge.com/ssl

Comodo – https://sslanalyzer.comodoca.com

SSL Checker – https://www.sslchecker.com/sslchecker

on entropy, password/passphrase complexity, and if you’ve been part of a data breach (spoiler alert: you have)

I wrote an article on passwords, passphrases, entropy, and data breaches for my employer’s blog: https://augustschell.com/passwords-passphrases-complexity-length-crackability-memorability-data-breaches

what is “plan b” for iot security?

Schneier has a recent article on security concerns for IoT (internet of things) devices - IoT Cybersecurity: What’s Plan B?

We can try to shop our ideals and demand more security, but companies don’t compete on IoT safety — and we security experts aren’t a large enough market force to make a difference.

We need a Plan B, although I’m not sure what that is. Comment if you have any ideas.

There are loads of great comments on the post.

Here’s the start of some of my thoughts:

There are a host of avenues which need to be gone down and addressed regarding device security in general, and IoT security in particular.

Any certification program could be good .. right up until the vendor goes out of business. Or ends the product line. Or ends formal support. Unless we go to a lease model for everything, you’re going to have unsupported/unsupportable devices out there.

We can’t have patches ad infinitum because it’s not practical: every vendor EOLs products (from OSes to firearms to DB servers to cars, etc).

A few things which would be good:

  • safe/secure by default from the vendor – you have to manually de-safe it to use it (like a rifle which only becomes usable/dangerous/operable when you load a cartridge and put the safety off)
  • well-known, highly-publicized support lifecycles (caveating the vendor going out of business)
  • related to the above, notifications from the device as it nears end of support
  • notifications from the device as well as the vendor that updates/patches are available
  • liability regulations – and an associated insurance structure – affecting businesses which choose to offer IoT devices across a few levels:
    1. here it is :: you deal with it || no support, no insurance, whatever risk is there is your problem
    2. patches / updates for 1 year || basic insurance / guarantee of operation through supported period, as long as you’re patched up to date
    3. patches / updates for 3 years ||
    4. patches / updates for 5 years || first-level business offering || insurance against hacks / flaws that have been disclosed for more than 90 days so long as you have patched
    5. patches / updates for 10 years || enterprise / long-term support || “big” insurance coverage (up to a year, so long as you’re yp-to-date) || proactive notifications from the vendor to customers regarding flaws, patches, etc

There are probably other things which need to be considered.

But there’s my start.

how did i never know about .ssh/config?

I’m sure folks have tried to explain this to me before, but it wasn’t until today that it finally clicked – using .ssh/config will save you a world of hurt when managing various systems from a Linux host (I imagine it works on other platforms, too – but I’ve only started using it on CentOS).

Following directions I found here, I started a config file on a server I use as a jump box. In it I have an entry for my web server, and I’ll be adding other frequently-accessed servers to it as time goes on.

Thanks, nerderati, man pages … and whomever else tried to explain this to me before but I didn’t grok.