Tag Archives: security

How the macOS root user vulnerability happened

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.

Root user vulnerability in macOS High Sierra

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 hacked

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.

How can you tell the type of a void pointer?

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.

Hashes and Nonces in CSP

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

Slack SAML authentication bypass

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.

Links to revoke app permissions from your social accounts

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.

Firewalls for the rest of us

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.