Keeping my family safe online is a topic I worry about all the time. Being a little paranoid about security always helps.
I’ve been reading this Ask HN thread on Hacker News on the topic and thought of jotting down a TLDR in case someone finds it useful. Some of the points are in verbatim.
- Enable automatic updates and take away their admin privileges.
- Force them to only use pre-installed apps on the tablet/phone that you’ve selected. By pre-installed, I mean pre-installed by you.
- Install ad-blockers on all devices. Preferably something like uBlock Origin.
- Set up a Pi-hole and configure on their devices
- When buying devices for them always prefer iOS. iPads seem to be the general go-to choice of the HN community.
- Create desktop shortcuts for common tasks. Eg: if your dad checks news first thing in the day, create a desktop shortcut to that news site.
- Tell them to be suspicious of email links that require them to log in
- Talk to them about being conned / scammed. That’s by far the most likely way for them to get victimized online.
- Talk to them about real world analogs to pop-up ads that look like virus scanner alerts, talk to them about people pretending to be someone they know
- Get them to consider “what do I really know, and is this too good to be true”
- Make sure they know to call you if they get a virus / malware popup they think could be real
- Tell them about phone scams
While some of these expect you to be fairly technical (eg: setting up a Pi-hole), a majority of them do not.
Another point that wasn’t mentioned in the comments but I highly recommend – be kind and attentive when parents call you about technical issues. I used to be (or used to act) busy which led them to call me only on dire circumstances – something you would not want to happen.
Mac security specialist Patrick Wardle digs into the root cause (pun intended) behind why a blank password gave you root permissions:
* For accounts that are disabled (i.e. don’t have ‘shadowhash’ data) macOS will attempt to perform an upgrade
* During this upgrade, od_verify_crypt_password returns a non-zero value, and an error code which is not checked
* The user (or attacked) specified password is then ‘upgraded’ and saved for the account
It appears that od_verify_crypt_password should fail (update: it does and Apple just didn’t check for this!).
It might be an oversimplification, but what I gather from the post is that proper handling of the function’s return value (error code) could have prevented this on hindsight.
Now I’m pondering about all those times we ignore the error codes returned by the OS for file I/O operations and whatnot.
It has been discovered that you can get root permissions on a macOS system running High Sierra without any password. To test, click on the padlock in any System Preferences dialog and enter root as the username and keep the password to blank. Now click Ok (or whatever the confirmation button is) twice and you have root privileges!
This is like the worst nightmare ever, but note that the attacker needs to have physical access to the machine. Until Apple sends the patch, the easiest way to secure the system is by changing the root password as described here: https://support.apple.com/en-us/HT204012
Unfortunately it looks like the vulnerability was publicly disclosed without letting Apple know and waiting for a patch.
Imgur has apparently been hacked in 2014 and this has come to light only a few days back. 1.7 million emails and passwords have been leaked – passwords encrypted with SHA256. (Imgur has been using bcrypt since 2016, though)
From the article:
Although in an ideal world Imgur would never have been hacked in the first place, I believe that the company should be commended on two counts.
Firstly, Imgur didn’t ask users when they created accounts to enter any extraneous unnecessary information – such as real names, dates of birth, addresses, or phone numbers that could have made this breach much more damaging to its victims. There’s a great deal to be said for companies limiting the amount of information that they ask from their users – the less they store about you, the less they can lose.
One of the key requirements in GDPR is that websites collect only the minimum personal data necessary to perform its operations. It will be very hard to keep the user stores from being pwned, but having the least possible amount of data in them definitely helps lessen the damage.
TLDR: You can’t
There’s a writeup on a newly found vulnerability in Adobe Acrobat Readers:
We all know that void pointers are by definition typeless, may point to any object, and any object may be cast to it. But surely, after we’ve cast an object pointer to a void pointer, it’s still possible somehow to detect its origin type, right? Not quite.
Once an object is cast to a void pointer, it’s absolutely impossible to detect its origin type. So, how do we check the type of a void*? The answer is that we don’t. And when you try, what you get is a vulnerability.
In case you’re not familiar with void pointers in C/C++, you can assign _any_ pointer to a void pointer, regardless of the type.
void *ptr = any_ptr;
This can be helpful if you don’t know what kind of a pointer you will receive in a function, etc. But usually it’s better to avoid them like the plague.
Troy Hunt has a nice article about inline-scripts and CSP with some practical examples.
By default the following CSP directive will block all inline scripts:
Content-Security-Policy: default-src 'self'
The most straight-forward way to remove the restriction is to add unsafe-inline but it disables all the defenses against inline scripts and XSS. Thankfully you have two alternatives: using a hash or a nonce. (TIL!)
If the script is static (the content does not change), you can add a SHA-256 hash of the script to the CSP directive, so the script will be whitelisted.
Content-Security-Policy: default-src 'self'; script-src 'sha256-blLDIhKaPEZDhc4WD45BC7pZxW4WBRp7E5Ne1wC/vdw='
However, if the script is prone to change, you have the option of adding a base64-encoded nonce (random value) to both the CSP directive and the script tag.
Content-Security-Policy: default-src 'self'; script-src 'nonce-4AEemGb0xJptoIGFP3Nd'
<script type="text/javascript" nonce="4AEemGb0xJptoIGFP3Nd">
Antonio Sanso writes:
This means that if I present to a ServiceProvider A an assertion meant for ServiceProvider B, then the ServiceProvider A shoud reject it.
Well between all other things I tried this very really simple attack against a Slack’s SAML endpoint /sso/saml and guess what? It worked 😮 !!
To be more concrete I used an old and expired (yes the assertion was also expired!!) Github’s Assertion I had saved somewhere in my archive that was signed for a subject different than mine (namely the username was not asanso aka me) and I presented to Slack. Slack happily accepted it and I was logged in Slack channel with the username of this old and expired Assertion that was never meant to be a Slack one!!! Wow this is scary….
Scary indeed. And it isn’t a particularly sophisticated hack either. Slack has now patched the issue.
Over time, you end up having granted access to a lot of apps from your social accounts. It’s a good idea to go over these periodically and clean up any apps you don’t need.
Some providers make it really difficult to find where to revoke these apps (I’m looking at you, Micro$oft). So here’s a list of direct links to different services I use to check the permissions every now and then:
[1] If you have signed in to multiple Google accounts, change 0 to 1, 2, etc for other accounts.
Smashing Magazine has a well-written article on firewalls: A Comprehensive Guide To Firewalls. The writing must be comprehensible to anyone even if he’s not aware of the technical jargon involved. The writer does the trick by some similes that make sense.
A computer is like a big housing complex. Every computer on the Internet has a numerical address, known as an IP address. At each address are two very large blocks of apartments. Each block contains 65,535 individual apartments. The vast majority of them are empty, but a few, especially the lower ones, have very communicative residents. All communication is by mail.
If you are lost about firewalls or if your knowledge is limited, give it a read.
