CompSec: Plug those gaps
Make things a bit harder for cybercriminals by getting rid of your ‘low-hanging fruit’ before it’s too late
Fix the more obvious threats to your system and that includes printers
Hacking into a system does not necessarily require computer-savvy people, well versed in software exploitation. More often than not it’s a case of leaving bread crumbs and ‘low-hanging fruit’ directly exposed to the internet for all the bad guys to see (and, of course, take advantage of).
Whether it’s an old unpatched system or an easyto-guess password, that’s all they need in order to get their first foothold into the system and start their lateral movement and system pivoting. The media is full of such cases, like the hacked GitHub account of Gentoo Linux (see http://bit.ly/lud_gentoo). Having guessable passwords, and not using public key authentication or 2FA authentication mechanisms, is a terrible mistake that typically ends up in a data breach. Running old software (sometimes even on modern OSes) poses a security threat too.
So this tutorial will guide you through some real cases where the bad guys were successful in hacking into some systems by spotting, and then exploiting, some very tasty low-hanging fruit. No advanced skills are needed, just some Bash or Python scripting and some tool or another. From old DES-encrypted passwords to leaked NTLM hashes on an LDAP schema, all the bad guys had to do was reach out…
Rehash old hashes
Think about all those servers and workstations you’ve been upgrading since the very first time you installed them. Like, say, the very first web server your company had running, on a flamboyant Debian Sarge with Apache Server 1.X. Since those old heady days a lot of things have changed, of course, and you’ve been upgrading that old web server to this day. But what about the hashes? Unless you force your users to change their passwords regularly (in case you are still using password authentication, that is), by upgrading a system you won’t be upgrading those old hashes algorithms at all.
On some occasions I’ve seen DES-encrypted passwords happily coexisting with salted SHA512 hashes on modern Debian Stretch servers – no kidding. Why? Because the system manager did not think to make their
users change their passwords and, let’s be frank here, because users tend not to change them at all unless forced to. Unless it’s after a data breach, of course.
One thing you can do right now is to make sure all your servers and workstations do not have old DES-encrypted passwords or MD5 hashes. Log in to these computers and have a look at the /etc/shadow file. Current GNU/ Linux systems use salted SHA512 hashes. If you spot any non-SHA512 hash, run the following command to force those particular users to change their passwords the next time they log in:
chage -d 0 <USER>
Get the file 01-hashes.txt from the coverdisc. This is a recreation of an /etc/shadow file found on a real email server running Debian Stretch. This server was originally running Debian Sarge, and the system admin upgraded it following the obvious path: Lenny > Squeeze > Wheezy > Jessie > Stretch. Some users, though, hadn’t changed their passwords since the very first time, not even the system admin himself! Brute-forcing DES with John The Ripper (see Resources) is more than feasible, so clone its repository and have fun cracking these passwords!
Get rid of the usual suspects
Every single GNU/Linux system ships with some wellknown users, such as www-data, git, root and so on.
For those servers with password-based authentication mechanisms, if users’ passwords are easy to guess, it might as well be game over. We have found on a bunch of servers that some of these users, in charge of running some network services (like the Apache web server), were allowed to execute a shell. On one such occasion this was because the server was running an OwnCloud instance and they needed the www-data user to perform some administrative tasks running the occ PHP script via an SSH connection.
The www-data user had a guessable password and the SSH server was using password-based authentication. So it came as no surprise that one day the system admin noticed that the web server was having some serious trouble in servicing pages to clients. It turned out that someone had been able to gain a non-privileged shell as www-data by guessing the password, and they had started running brute-force attacks against other computers and networks.
Whenever possible, don’t allow valid shells to daemon accounts and make sure to rename them. Allow access to those users who really need to use SSH by editing /etc/ ssh/sshd_config and adding an AllowUsers entry, in the following way:
On some occasions I’ve seen DESencrypted passwords coexisting with salted SHA512 hashes
AllowUsers <user1@IPADDR> <user2@IPADDR>
Of course the IP address can be spoofed, but if you combine public key authentication with AllowUsers entries, you should probably be fine. You can even increase your security by combining 2FA mechanisms, public key authentication and LUKS.
Carrying around a non-encrypted laptop is a perilous business. On one occasion, someone stole a laptop that had no encryption at all. They then bypassed the entire INIT process and got access to the user’s home directory. There they found a public/private key pair in the ~./ssh/ directory. Running the following command, they got a list of valid hosts to which the user regularly connected:
cat /home/<USER>/.bash_history\ > |egrep --color=yes "ssh|scp|sftp"
Finally, they tried to connect to those hosts by running:
ssh -i <ID_RSA_KEY> <USER>@host
The user did not have his private key encrypted, so no pass-phrase was needed in order to use it, and so the bad guys were able to hack into a bunch of servers.
Now, imagine this happens to you. Do you have, at least, a strong pass-phrase protecting your private keys? Do you have encryption at all on the volume where you store your private keys? You can use John The Ripper to brute-force private keys just as easily, of course. Generate a new RSA public/private key-pair, and when asked for a pass-phrase, type something dictionarybased such as mariobros:
ssh-keygen -t rsa -f id_my_weak_rsa
Install John The Ripper JUMBO version on your computer and then execute the following:
./ssh2john.py id_my_weak_rsa > id_rsa.hash
From this point on, it’s just a matter of running John with a good dictionary and wait for the best (or the worst):
./john –wordlist=/path/to/dictionary.txt \ > id_rsa.hash mariobros (id_rsa)
Feel free to crack the private key included on the coverdisc (03-id_rsa).
On the other hand, let’s imagine you did have your entire file system encrypted with LUKS. Unfortunately, if your chosen pass-phrase is weak, you are still doomed. To demonstrate this, grab a spare USB stick, create a new VFAT partition on it and then run the following commands to create a new LUKS-encrypted volume. In this case when asked for a pass-phrase, choose a weak, dictionary-based one:
cryptsetup luksFormat /dev/<DEVICE> cryptsetup luksOpen /dev/<DEVICE> MYLUKS mkfs.vfat /dev/mapper/MYLUKS -n dataencrypted cryptsetup luksClose MYLUKS
Now you’ve got yourself a fancy VFAT LUKS-encrypted device. Better, right? Well, trying to perform password guessing on LUKS devices is admittedly slow, but you can always dump the LUKS header with all its keys to a file and work against this file to speed up the process. Bruteforce-luks (see Resources) is perfect for this purpose; first install it:
git clone https://github.com/glv2/bruteforceluks.git
apt-get install dh-autoreconf libcryptsetupdev cd bruteforce-luks
./configure && make
Next, dump the LUKS header from your USB stick and run bruteforce-luks against it with a good dictionary:
sudo dd if=/dev/<DEVICE> of=luks-header bs=1M count=10
./bruteforce-luks -t 2 -f <DICTIONARY> luks_ header
When the only way to access your SSH servers is by means of public key authentication, any attempt at password brute-forcing will irremediably fail. However, attackers will inevitably keep on trying. That’s why it’s important to install a tool like fail2ban, to ban those annoying attempts.
There’s also the possibility of a private key brute-force attack by using, for example, Crowbar (see Resources). When a non-valid public key is offered, the /var/log/ auth.log file will have entries like the following: Jul 22 08:28:42 server1 sshd: Connection closed by <IPATTACKER> [preauth]. It’s easy to track these attempts and ban them with fail2ban. Just edit /etc/fail2ban/ filter.d/sshd.conf and append the following line to failregex:
Printers can pose a tremendous threat because they can be exploited and used as a pivot
^%(__prefix_line)sConnection closed by
Once the new rule is added, use fail2ban-regex to make sure it’s working:
fail2ban-regex /var/log/auth.log \ > /etc/fail2ban/filter.d/sshd.conf
Do RSA weak keys ring any bells? It’s something from the past (see https:// jblevins.org/log/ssh-vulnkey) but it’s still pestering our present. Old embedded SSH devices with no firmware upgrades are still affected by this issue. And guess what – some of those weak RSA2048 keys are still found in ./ssh/authorized_keys2 files!
Make sure you do not have any old embedded device (router, IoT or whatever) running a vulnerable OpenSSL version and, in case you do, make sure all the vulnerable keys have been removed.
Otherwise, an attacker could download pre-calculated RSA2048 private keys and use them to gain illegal access to one of these devices. Try it; download precalculated RSA2048 private keys from http://bit.ly/lud_rsakeys. Then download and install the aforementioned Crowbar to brute-force these devices using the downloaded keys: git clone https:// github.com/galkan/crowbar.git. Install its dependency first: apt-get install python-paramiko and try your luck with:
./crowbar.py -b sshkey -s <IP_ DEVICE/32> \
> -u <USER> -k /path/to/rsa/2048/
Does that seem unlikely? We’ve seen it happen. Twice.
Pen-test your printers
You probably have some printers on your network. Hopefully, these printers won’t be accessible from the internet but they pose a tremendous threat nonetheless because they can be exploited and used as a pivot. PRET (see Resources) is an amazing pen-testing tool for printers. It allows you to perform some pen-testing tests and exploitation of PS, PCL and PJL printers.
What sort of attacks can be possible on a printer, you may be thinking? Browse to http://hacking-printers.net/wiki/index. php/Main_Page to find out. Are your printers updated to their latest firmware?
Are they exposed to the internet? One of our engagements took place some time ago when we spotted some odd connections from a remote IP address to an HP OfficeJet 8210 printer on an unusual TCP port. It turned out the printer had been hacked and someone had been able to spawn a netcat listener on TCP port 1210. They basically exploited the vulnerability reported at http://bit.ly/ lud_hpexploit, by following, step-by-step, the post on HP’s own website at http://bit. ly/lud_rootprinter. See? Even if they were not well-versed in printer hacking, they did it anyway. But of course you can even do it quicker using PRET!
Let’s find out which printers you can see on your network. First, install PRET dependencies: pip install colorama pysnmp; apt-get install imagemagick ghostscript. Next, execute PRET to get a list of your printers: cd PRET/; ./pret.py (for this command to succeed you need to allow UDP packets to your computer). Pick one and re-run PRET with the language that your printer supports (ps, pcl or pjl):
./pret.py <IP> ps Some printers may support more than one of these languages, and some vulnerabilities may be successfully exploited by using one but not the others. Bear in mind that by using PRET your printer may well be gushing out a lot of pages with odd PS/PCL/PJL codes printed on them. Trying to perform path traversal is a good starting point whenever assessing the security of your printers. If you can do it, the chances are that you may have a potential attack vector to investigate:
traversal ../../../bin Path traversal set.
Sometimes you won’t be able to do that, but maybe you will be able to use the printer as a sort of covert repository for spreading malware, illegal content storage and so on. A bunch of printers are vulnerable to this particular flaw although some vendors do not categorise it as a proper vulnerability. It’s easy to test for that; using PRET, try to upload to and then download a file:
./pret.py <PRINTER> pcl put <FILE> ls get <FILE>
Feel free to explore all of the possibilities of PRET and read more about printer exploitation at http://bit.ly/lud_rootprint2.
You won’t be upgrading old password hashes just by upgrading the system
Above Teach yourself a bit of the PS, PCL and PJL languages. Too daunting a task? No fret – use PRET!
Right Whenever you set up pass-phrases for your LUKSencrypted devices, go for the Snowden approach: it deliversFigure 1
Above MFPs are multi-functional devices indeed: here you are about to gain a remote shell. Smashing!Figure 2