r3dux.org

I had a PDF the other day which required me to enter a password before viewing it, which is something I’d never seen before, so being a chancer I just slapped enter and it worked (i.e. there was no password, or more accurately the password was blank). However, keeping a file in that state is just stupid, so I wanted the “password” removed – and it turns out that it’s dead simple to do in Linux.

Two Stepper

1. Install qpdf with synaptic or the command:

   sudo apt-get install qpdf

2. Issue the following command:

   qpdf --password=YOURPASSWORD-HERE --decrypt INPUT-FILE.pdf OUTPUT-FILE.pdf

   So, if your password protected pdf is called foo.pdf and the password is empty (i.e. “”) like in my case, you just issue something like this:

   qpdf --password= --decrypt foo.pdf foo-no-password.pdf

Job done!

While reading around on how to break into Linux accounts the other day I stumbled across the interesting tidbit of information that the password hashes stored in the /etc/shadow file can be hashed using different methods, some more preferable than others.

Here’s an extract from my shadow file:

root:!:15097:0:99999:7:::
kernoops:*:15089:0:99999:7:::
pulse:*:15089:0:99999:7:::
saned:*:15089:0:99999:7:::
kdm:*:15174:0:99999:7:::
test:$6$lAlAzXs6$kooivqlkaHwH5jFYZ2a3SGUim8w9Ib4XeEjffgbuqjVjwh/gqEdb7zPSTHHL/eRvvhtqv7UzR9Np3J3T29/8l0:15179:0:99999:7:::

From looking at the information in man shadow, there are 9 fields in the following format:

• Account name,
• Password hash. A value of ! or * indicates the account cannot be logged in with, but may still be used by processes, and !! means the account has expired
• Date of last password change (expressed as the number of days since Jan 1, 1970),
• Minimum password age before change (minimum days before you can change the password),
• Maximum password age before change (maximum days before you must change the password),
• Password warning period (how many days before the password expires should the user be warned their password will expire soon),
• Password inactivity period (the number of days an account may still change their password after expiry)
• Account expiration date (expressed as the number of days since Jan 1, 1970), and finally,
• A reserved field

So, taking the pulseaudio account pulse as an example, pulse:*:15089:0:99999:7::: means:

• Account name = pulse,
• Account may be used but cannot log in,
• Password set 15089 days since 01/01/1970 (which will be around May 2011),
• 0 days must elapse before password change,
• 99999 days (so roughly 273 years) may elapse before password change,
• 7 day password warning period,
• No password inactivity period,
• No account expiration date,
• No data in the reserved field.

All fair enough – but now take another look at the test user account:

test:$6$lAlAzXs6$kooivqlkaHwH5jFYZ2a3SGUim8w9Ib4XeEjffgbuqjVjwh/gqEdb7zPSTHHL/eRvvhtqv7UzR9Np3J3T29/8l0:15179:0:99999:7:::

The password field has a stored password hash (which in this case is a SHA-512 hash of the phrase thisisstupid2) – and the first three characters are $6$. This is where the strong hashing comes in…

Choose Your Hashing Algorithm Wisely

There are a number of first-three-character combos which mean different things, and some are definitely better than others:

• $1$ – password is hashed with MD5,
• $2$ or $2a$ – password is hashed with a blowfish variant,
• $5$ – password is hashed with 256 bit SHA-2 bit resulting in 32-byte output, and
• $6$ – password is hashed with 512 bit SHA-2 resulting in 64-byte output.

MD5 is broken, by which I mean it can be manipulated to give the same hash for different sources. SHA-256 and SHA-512 on the other hand are significantly stronger and to the best of my knowledge do not currently have working attacks, so they’re definitely the way to go. There’s a great article on shadowed passwords by Aaron Toponce over at GuruLabs which will tell you pretty much anything you might want to know, and which can be found here.

Going back to my own experience with this, when I checked some accounts on my VPS (which runs this site) the other day, I found that some of the hashes started with $1$, so were hashed with MD5. The fix for this? Simply reset the password and the newer, stronger hashing algorithms will be used.

You can reset the password for any account by issuing the following command and then providing a new password:

passwd <account-name>

For example:

passwd root

After this, check your shadow file to ensure your hashes start with the desired prefix. Once they do your machine will be a little bit more secure, and it isn’t that much of an ordeal to achieve.

Cheers!

I thought my Linux box was pretty safe. I mean, I use a strong password, I have my entire home directory encrypted, I should be alright, yeah? Ummm, no… I’ve been thinking about security a bit recently, and as much as I’ve always had an interest in the topic, it’s not my core field – I’m a software engineer at heart, so I build software, not secure it. But with 2011 being the year of the hack with Anonymous and LulzSec hacking site after site after site, along with the major Sony hacks – it can’t help be anything but my field anymore.

So with a strong password and disk encryption I thought I was safe in case my laptop was stolen – but really it isn’t at all. If you have physical access to a machine, then it’s yours. This definitely comes under the ten laws…

The Ten Immutable Laws of Security

There’s a very good Microsoft article called the Ten Immutable Laws of Security which you can read here. The article discusses each one, but I’ll just list them here:

1. Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore.
2. Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore.
3. Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
4. Law #4: If you allow a bad guy to upload programs to your website, it’s not your website any more.
5. Law #5: Weak passwords trump strong security.
6. Law #6: A computer is only as secure as the administrator is trustworthy.
7. Law #7: Encrypted data is only as secure as the decryption key.
8. Law #8: An out of date virus scanner is only marginally better than no virus scanner at all.
9. Law #9: Absolute anonymity isn’t practical, in real life or on the Web.
10. Law #10: Technology is not a panacea.

There are issues with these “laws” – but you can google that for yourself – what we’re thinking about today is #3 – physical access == potatowned…

Getting it Done

First, reboot the machine and instead of booting as normal, select recovery mode from the GRUB menu:

Next, opt to drop into a root shell:

You don’t need to enter any password at all for the above – you’re just given root access… At which point, you just reset the password for a user account (in this case I created an account called test, but you can reset the root password or the password on any other account just as easily):

That’s it – you own the box. Simply reboot again and log in with the password you just specified.

Safety is an illusion

I’ve got to say, when I first read about this my jaw just dropped – surely it’s not that easy? But it is. So good job on the disk encryption and strong password use, but it’s all for naught. You’re not asked for a root password, or for an account password before you can reset anything – you’re just given full root access because you asked for it nicely. And with a Windows machine you just boot the box from an OphCrack CD and wait a few minutes before it delivers the password via the use of rainbow tables.

Absolutely incredible.

When you connect to a NAS in Windows, it will often helpfully remember the username and password of the NAS account it got access through. Forever. So, if you want to log into the NAS as a different user, well – tough. Windows already has a working set of credentials, and by jingo it’s gonna use them. The fix? From the command prompt, enter:

net use * /delete /yes

This will get rid of all connected share credentials, however you may want to just get rid of the credentials for a specific share. If so, you can use:

net use \\YOUR-SHARE-LOCATION /delete /yes

For example, the get rid of the credentials for the “Code” share on my NAS:

net use \\ETHERNET_BD\Code /delete /yes

Now, to map the share to a drive and give it the credentials YOU want Windows to use, go with:

net use DRIVE-LETTER: \\YOUR-SHARE-LOCATION NAS-USER-PASSWORD /user:NAS-USER-NAME

So, if I wanted to map the Code share of my NAS to the Z: drive, and access it with a user called bob who has a password MyClevahPass123, I’d use:

net use Z: \\ETHERNET_BD\Code MyClevahPass123 /user:bob

Done & dusted.

Please Note: The credentials you supply must be the username/password of the user the SHARE knows to grant access to, not just your own Windows username/password. Just clarifying =D