Mar 192017
 

So every once in a while, you come across something in IT Security that just makes you want to cry.

Usually, these are chained exploits that when executed properly have devastating effects.

Take the latest Pwn2Own competition. One of the successful hacks there was epic. And scary.

In a nutshell, an ‘Edge’ browser exploit to get into the Windows 10 VMWare guest, then a bug in the VMWare guest to own the VMWare host. Yes, hacking the VMWare host – from a web page.

That’s scary.

Aug 022015
 

It’s been a while since my last post – and this one is a doozey.

So Bind is one of the most popular DNS servers on the planet. Just about everyone runs it. So when news breaks that a specially crafted request can cause the named process to exit, then a problem is presented.

Enter CVE-2015-5477.

The official report says:

named in ISC BIND 9.x before 9.9.7-P2 and 9.10.x before 9.10.2-P3 allows remote attackers to cause a denial of service (REQUIRE assertion failure and daemon exit) via TKEY queries.

This doesn’t really convey the severity of the issue. Thankfully, the ISC elaborate more. In it, they say:

The practical effect of this is that this bug is difficult to defend against (except by patching, which is completely effective) and will not be particularly difficult to reverse-engineer. I have already been told by one expert that they have successfully reverse-engineered an attack kit from what has been divulged and from analyzing the code changes, and while I have complete confidence that the individual who told me this is not intending to use his kit in a malicious manner, there are others who will do so who may not be far behind. Please take steps to patch or download a secure version immediately.
 
This bug is designated “Critical” and it deserves that designation.

Essentially, “You’re screwed. Upgrade now”.

If you’re a system admin, and you’re reading this, check your bind version now, make a coffee, then dig in for the long haul.

Jan 312015
 

So the openjdk in most linux distros has now been upgraded to v1.8. This has a good bug fix regarding the whole SSLv3 Poodle vulnerability.

This has one problem. The Dell DRAC remote management cards installed in a lot of Dell servers relies on SSLv3 to operate. Without this, you can get into the web interface – but when you get an error stating Error when reading from SSL socket connection and no further.

drac-ssl-error

Thankfully, it is simple to re-enable SSLv3 to allow the connection to succeed.

Open up /usr/lib/jvm/*/jre/lib/security/java.security in your favourite editor as root, and change the following line:
jdk.tls.disabledAlgorithms=SSLv3

to

jdk.tls.disabledAlgorithms=

This enables SSLv3 to all java applications – however it exposes yourself to the MITM attack as defined in CVE-2014-3566. I suggest having a read of the CVE to understand if you want to leave this setting as default on your system or disable it again afterwards.

Jan 292015
 

A while ago I wrote about how to do this exact thing but with an older version of openssh.

If you’re running a newer version of SSH, then the command syntax has been updated somewhat.

Firstly, once you’ve got your yubikey, you’ll need to enable EPEL for EL6/7 and install the pam_yubico package.

You’ll then need to modify the sshd pam file /etc/pam.d/sshd. There are two options here.
1) You require just the OTP; or
2) You want the OTP and a password.

If you want just the OTP, you add this just after the #%PAM-1.0 header:
auth sufficient pam_yubico.so id=16 authfile=/etc/yubikey_mappings

If you want both password AND OTP, you add this:
auth required pam_yubico.so id=16 authfile=/etc/yubikey_mappings

Now to create the /etc/yubikey_mappings user to key mapping. The README says:

Create a /etc/yubikey_mappings, the file must contain a user name and the
Yubikey token ID separated by colons (same format as the passwd file) for
each user you want to allow onto the system using a Yubikey.

The mappings should look like this, one per line:

——
first user name:yubikey token ID1:yubikey token ID2:….
second user name:yubikey token ID3:yubikey token ID4:….
——

Now, if you want to go further and require both a ssh key AND an OTP, you can add the following to /etc/ssh/sshd_config:
AuthenticationMethods publickey,password

Now after you supply a valid ssh key you will be asked for your password. If you’ve set this up correctly, this will either be your password + OTP or just OTP.

Enjoy!

Update 21/Jun/2015
One common question I get is how they can allow access without a yubikey while in the office, but force its usage outside of the office. This has a couple of parts – mainly, you’ll probably want to use a public key from inside, but force say a publickey + yubikey outside.

We do this by using a Match block in /etc/ssh/sshd_config as follows:
AuthenticationMethods publickey,keyboard-interactive
 
Match Address 10.1.1.0/24
AuthenticationMethods publickey

In this method, we set that EVERYONE must use a public key and a keyboard-interactive method to authenticate, then we allow exceptions for small address spaces that we trust. I also recommend making the following changes:
PasswordAuthentication no
ChallengeResponseAuthentication yes

This disallows skipping the yubikey auth and just using a password. Although, now we’re using PAM as the auth source, you can *still* use a password via PAM – so we need to disable this in /etc/pam.d/sshd:
#auth substack password-auth
#password include password-auth

Hope this helps.