Windows CE to Raspbian – Pt. 4: PCI Compliance

This is part four of a series of posts: click here for the previous post or here for the first post.

The purpose of this particular post is to cover the issues found when testing for PCI compliance. If you’re wondering whether your device needs to be PCI compliant then ask yourself this question:

Will my device be on a network that will have credit card information passing through it?

If not then it’s unlike you’ll need to be, however if you’re looking to make your device extra secure then this will also be useful.

Samba


The Purpose of Samba

Samba provides the Raspberry Pi with a number of features, but the feature we’re interested in is the ability to route using a hostname on adhoc networks.

As the device will end up residing on networks of all shapes, sizes and configurations this feature will allow us to find the Raspberry Pi much easier by using just the hostname and letting samba deal with rest.

Users have come to expect a plug and play scenario for devices, therefore reducing the amount of set-up required is essential.

The Problem

When testing PCI compliance the Raspberry Pi 2 raised the following two issues related to samba:

Samba does not enforce the password-guessing protection mechanism for all interfaces, which makes it easier for remote attackers to obtain access via brute-force ChangePasswordUser2 via SAMR or RAP attempts. Update to Samba 3.6.23, 4.0.16, 4.1.6, or later.

The version of Samba detected running on the system is vulnerable to an information disclosure vulnerability. This vulnerability was patched in Samba versions 4.1.1, 4.0.11, and 3.6.20. Upgrade to the latest stable version of Samba.

Essentially there are vulnerabilities with the version of samba in use, but the fix appears straight forward: update samba to the latest version. Unfortunately the latest version available by default for the Raspberry Pi 2 is 3.6.6.

The Solution

By modifying the apt sources list we can access packages not available by default. In this case we’re going to add the wheezy-backports apt repository. This is where packages are backported to a previous version of debian, in this case Wheezy.

The first step is to add the wheezy-backports to your apt sources.list file, located in:

/etc/apt/sources.list

This can be done by running the following command as sudo:

echo "deb http://http.debian.net/debian wheezy-backports main" >> "/etc/apt/sources.list"

This will append the line “deb http://http.debian.net/debian wheezy-backports main” to the bottom of your sources.list file. Alternatively you can edit the file using a text editor and append it that way.

Second we need to add the pgp keys. This will help ensure the connection the repository is secure and stop us getting errors when we update apt. We need to add two keys, which can be done executing the following commands:

gpg --keyserver pgpkeys.mit.edu --recv-key  8B48AD6246925553
gpg -a --export 8B48AD6246925553 | apt-key add -
gpg --keyserver pgpkeys.mit.edu --recv-key  7638D0442B90D010
gpg -a --export 7638D0442B90D010 | apt-key add -

If the connection to the server times out this may be due to your firewall, try using port 80 like so:

hkp://pgpkeys.mit.edu:80

Once these keys have been added we can update apt and everything should be fine. You can update apt using apt-get, although some people prefer aptitude. To update apt execute the following as sudo:

apt-get update

Now we have access to the wheezy-backports we can install the newer version of samba. If you already have samba installed it’s recommend to purge the installation and reboot before installing this new version. This can be achieved like so, again executing as sudo:

apt-get --purge remove samba
reboot

To install the new version we want to install samba from the wheezy-backports, which can be done by executing the following command as sudo:

apt-get install -t wheezy-backports install samba

This may take some time and may ask you a few questions as it installs. After run the following command:

smbd --version

You should be presented with Version 4.1.17-Debian. This version is compatible with PCI compliance, at this time, as it is beyond 4.1.6 and 4.1.1 as specified above.

OpenSSH


The Purpose of OpenSSH

OpenSSH is used in a lot of places, however in this context we are using as part of the ssh server which allows us to remotely access the Raspberry Pi 2.

The Problem

When tested for PCI compliance the Raspberry Pi 2 raised the following two issues related to openssh:

OpenSSH does not properly support wildcards on AcceptEnv lines in sshd_config, which allows remote attackers to bypass intended environment restrictions by using a substring located before a wildcard character. Update to OpenSSH 6.6 or higher.

The version of OpenSSH on this host is prone to a weakness that could allow a remote attacker bypass the look up of SSHFP DNS resource record, which is used to check the fingerprint of the server public key. This vulnerability was fixed with the release of OpenSSH 6.7 and 6.7p1, however it is recommended that you upgrade to the latest supported release.

Much like the issues with samba, there are vulnerabilities which can be resolved by updating to the latest openssh, however the latest version of openssh available by default is 6.0p1.

The Solution

This resolution was a little more difficult. Using the openssh available in the wheezy-backports only took us to 6.6. However there was a fairly quick resolution described in this youtube video.

The first change is to add the Jessie apt repository for Raspbian. Now we need to be careful using this because the version of Raspbian we’re using is based on Wheezy, the predecessor to Jessie. We don’t want to accidentally install packages from Jessie as they may not work on Wheezy.

Adding this apt repository can be done exactly the same as the wheezy-backports repository:

echo "deb http://mirrordirector.raspbian.org/raspbian/ jessie main " >> "/etc/apt/sources.list"

The next step is to add some pinning to the preferences file for apt. This file may not exist, however the following commands executed as sudo will append the file and create it if necessary:

echo "Package: *" >> "/etc/apt/preferences"
echo "Pin: release n=wheezy" >> "/etc/apt/preferences"
echo "Pin-Priority: 900" >> "/etc/apt/preferences"
echo "" >> "/etc/apt/preferences"

echo "Package: *" >> "/etc/apt/preferences"
echo "Pin: release n=jessie" >> "/etc/apt/preferences"
echo "Pin-Priority: 300" >> "/etc/apt/preferences"
echo "" >> "/etc/apt/preferences"

echo "Package: *" >> "/etc/apt/preferences"
echo "Pin: release o=Raspbian" >> "/etc/apt/preferences"
echo "Pin-Priority: -10" >> "/etc/apt/preferences"
echo "" >> "/etc/apt/preferences"

Essentially what this does is allow us to pull packages from another distribution without upgrading our entire system. For more information on pinning check out the debian wiki.

After this if we update apt we should be able to upgrade our packages. Run the following as sudo:

apt-get update
apt-get -t jessie install openssl libssl1.0.0 openssh-client openssh-server ssh

This is similar to the command we previously used when installing samba. We’re specifying we want to use the jessie repository, as opposed to the wheezy-backports, then we’re installing several different packages associated with openssh.

During this installation you’ll be asked a number of questions: one important question is related to replacing the way root is access through ssh. Unless this will break the way you access your device it’s recommended to make this change. After you’ll be asked whether the update can restart services without asking you.

After the update run the following command:

ssh -V

You should receive the following output: OpenSSH_6.7p1 Raspbian-5, OpenSSL 1.0.1k 8 Jan 2015. This version is compatible with PCI compliance, at this time, as it is beyond or equal to 6.6 and equal to 6.7p1.

The Future


Future Vulnerabilities

There are always new vulnerabilities being found in packages. In order to keep in compliance with PCI packages will need to be updated as time goes on to keep up-to-date with fixes.

For an embedded device such as this automating package updates to keep in line with PCI compliance is necessary as the alternative is manually updating numerous devices.

Keeping Up-to-Date

Keeping up to date with what new package vulnerabilities s important to stay ahead and not just wait until the PCI audit to realise your device has failed compliance.

Debian has a number of mailing subscriptions announcing changes, one of which is entirely about security. Every time a vulnerability is discovered in a debian package an e-mail is sent out detailing the issue.

It’s highly recommended to be on this mailing list as it’s a very easy way to stay apprised of issues.

Advertisements

One thought on “Windows CE to Raspbian – Pt. 4: PCI Compliance

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s